Requirements, tests, training, help files – the connection?

Part one What would you like sir

Part two Requirements,tests, training, help files

Part three Why no project exists onin isolation-whwat should be done

Part four Business rules, Process rules, Process, Data, different viewpoints

Part five Testing requirements is not optional

Part six Requirements strategy can make or break your project

 Really! – Have you seen this new stuff? 

This could easily have been Mick Jagger and Keith Richards after their first successful gig. In the modern world, it is more likely to be a hard working CTO talking to a COO about his systems needs.

Systems are not like any other purchase. You can go to a tailor today and he will do almost the identical things that a tailor did for Julius Ceaser.  You can call an architect and his approach will differ little from that of Hiram Abif apart from the time taken to produce drawings.  When it comes to systems though, it is more like medicine. Patients differ, you only hear what they tell you and you don’t really understand anything you have not personally experienced, you have to tease it out using your instinct and experience and play the numbers game.

There are techniques for flushing out the problems and verifying them and for getting the medicine accepted, but ultimately every doctor likes to deal with life threatening situations. If he succeeds for whatever reason, he’s a hero and if not, well, he did his best.
Apart from a lucky few, most of us in the software industry have to earn a living by delivering value in the real world through cost savings, or competitive advantage and that’s a tall order.
It calls for a mixture of calculated risk taking and good fall back positions and it requires an insight that combines real understanding of the business domain with leading edge technological ability. It doesn’t matter whether this is done by a committee or a genius as long as it gets done

The requirements challenge

So how do you meet a business person, listen to his/her needs and six, nine or thirty six months later get a well done, thank you response?

There isn’t a really good answer to this. If it is six months, you are in with a chance. If it is nine you are still in there, at thirty six, the likelihood is that before you deliver this, a much better solution will have been invented, or the problem will have been replaced by a new one.

There is a considerable number of methodologies out there, most of them geared up to coax you into paying for expensive training courses and few aimed at really bridging the divide between what a business needs and what technology can deliver with reasonable reliability.   A methodology that really works has to be able to understand business needs, translate it into process and match this with the best possible technical solution.

Defining the problem

This is not as simple as it sounds. If you read my business case blogs, you will probably remember the way I recommend tying corporate objectives in a direct and accountable way to the benefits delivered by the business case.  That makes perfect sense of course, because a good business sets a plan and then works to deliver on it.
There are other scenarios however that need to be taken into account, this example will hopefully help to illustrate the point.
Suppose we approach an Amazon tribe still living in the traditional way, tell them that we would like to give them some gifts and ask them about the problems they would most like to solve and the things that might give them the most satisfaction.  Problems and exciters. The likelihood is that having seen bright steel machetes amongst the crew, they might suggest a steel spear to make fishing more productive. We might then suggest that rather than give them a spear, we can give them a monofilament net. This way they can catch enough for the whole tribe in an hour instead of having to fish all day.Here we have seen a classic example of the two cardinal sins of analysis:

 1.       Asking a question that the object of the question can’t possibly be expected to answer well.

2.       Answering with a solution rather than a problem.

The interviewee in this example can’t be expected to know how to manage this process, so the entire responsibility lies with the interviewer. By the way, that includes the many occasions when the interviewee believes she knows exactly what she wants and is driving.
The responsibility of the analyst extends to making sure that the interviewee has explored and understood the problem and has a sufficient understanding of it and of the desired outcomes to start either designing or verifying the solution.
I include verifying here, because an increasing number of business people believe themselves to be tech wizards and arrive with fait accomplis and a budget wanting a technically trained fellow to make her vision happen.  In these cases, instead of designing a solution, the analyst goes through a process of verifying the problem, the requirements and the solution.  If these three don’t match and the sponsor doesn’t see it then it is up to the individual analyst’s conscience  and professional intergityas to what he/she should do next.

In Summary

In this part we have talked about three key issues:

1.       The unique challenge facing a systems professional in getting to the real problem before starting on the solution.

2.       Educating the client about possibilities in order to truly understand what the problem is.

3.       Tempering the part time inventor with a little pragmatism without dampening his/her enthusiasm.

The next part will get much deeper into the language and culture of requirements and and discuss different methods of achieving a reliable result.




Reblog this post [with Zemanta]

The IT guy and the balloonist

“A man in a hot air balloon is lost. He sees a man on the ground and reduces height to speak to him.
“Excuse me, can you tell me where I am?”
“You’re in a hot air balloon hovering thirty feet above this field,” comes the reply.
“You must work in Information Technology,” says the balloonist.
“I do,” says the man, “How did you know?”
“Well,” says the balloonist, “Everything you told me is technically correct, but it’s no use to anyone.”
“You must be in business,” says the man.
“I am,” says the balloonist, “How did you know?”
“Well,” says the man, “You don’t know where you are, you don’t know where you’re going, but you expect me to be able to help. You’re in the same position you were before we met, but now it’s my fault.”
We have all been in that field or hovering above it, or even both at different times and I expect we can all sympathise immediately with at least one of these characters. The sobering thought in all of this however, is that the man in the field won’t survive very long unless the balloonist finds his way home and the balloonist stands little chance of surviving without the help of the man in the field.

The baloonist talks turkey

 Did I mention that your salary and bonus are in this baloon, but I won’t be able to deliver it said the balloonist, looking rather smug.

He went on, do you remember when you came to me for more budget so you could hire balloon analysts, to understand my needs and provide a better service, well that was when it became your problem, so maybe we should start again.

Can you tell me where I am?

The IT guy replies

Actually no, it became my problem when you got lost with my salary on board, but unfortunately, I am only able to understand how your balloon works and help make it work better, that’s what my analyst helps with, but deciding where you are, where you want to be and how to get there, is still your responsibility and incidentally, one that I am not qualified to advise on.

I ask, you tell, I provide the supporting technology.

By the way, I take it your salary is in there too?

Baloonist replies

 Yes, I believe we have had a misunderstanding and I see we have a shared problem.

You have the option to find a more reasonable employer and I wouldn’t blame you.
I on the other hand, have the option to outsource to someone who will shoulder full responsibility.   I had an Indian team here last month who know our industry intimately and are working with some of our biggest competitors. They will advise strategically, partner with our SMT and provide us with thought leaders and presentaions, provide all the business analysis and deliver the end results and they will do it at offshore rates.

What do you think we should do?

 The IT guy ponders and then replies.

 If I look for a new employer, there are indeed many options, but I expect all of them will be much like you or have other equally difficult issues, so I see the solution as more important than the geography.

 My gut feeling is that if you really believed in Santa Clause, we wouldn’t even be having this conversation because your Indian pals would already be sitting in my office.

Once you begin to outsource, getting out of that is the most painful and most expensive experiences you are ever likely to have. You will have mission critical systems that nobody understands, or can maintain and you will be forced to accept any amount of price rises or reduced service levels. The path to extricating and uncoupling your systems will look so impossible as to not even warrant consideration.
Controlled outsourcing may well bring benefits, but you will need me more than ever if you go down that route.

If you pay for the champagne I’ll happily take you and your other directors to the races, I will be more than pleased to keep you up to date on the changing face of IT and it’s implications for you, but I don’t believe it is appropriate for anybody but yourself to make strategic balloon decisions because they are ultimately your responsibility .


 Maybe we need to have a rethink and start putting the relationship on a more realistic footing

 It guy


Business analysts: a bridge between IT and business

 Role of business analysts
Business analysts intervene at the project management stage in information technology. Working with the project manager, their role is specifically to analyze business requirements before the start of a project. Their work involves identifying, defining, analyzing then documenting the underlying needs of a project. They guarantee the compliance of a project with business requirements and help determine which projects have priority.
The work of business analysts differs from that of traditional information systems analysts because they focus exclusively on the benefits of the project for the company’s business. It is also different than that of project managers and functional analysts because their role is to show what the product will be required to do, and not how it will do it. The analysis of needs is carried out with no commitment toward a specific product.