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]

Management is about common sense, methodology is just a reminder

p class=”MsoNormal” style=”margin: 0cm 0cm 0pt;”>“So you don’t know what you want and you’ll be upset if you don’t get it. OK I’ll do my best?”

Where to sir?

Every journey begins with a vision of where the destination is. Sometimes you just have a good idea and expect to do a little exploration along the way, sort of watching for the signs, but without a very strong indication of where it is. Your’re runing a few extra risks here, you need to know when to recognise that you are lost and cut your losses. You do have an exit strategy I hope.

How long do you expect it will take driver?

Once you have a good definition of where the destination is you need a strong indication of what the journey is going to be like, how long it might take, whether it is dangerous, if you will need public transport and how you will recognise your destination when you arrive. If you assume that you can cover say 300 miles a day but you find out later that every city and bridge takes several hours to pass through, you may run out of food or fuel and the best thing to do is put your feet up and cancel the trip.

Speka the english por favor

Then of course there’s a different culture to contend with both on the journey and on arrival. Can I speak the language? Will they understand mine? Will I be able to find my way around? Will I be safe? Where will I get all the new skills from and will I be comfortable with this new experience?

Of course your future livelihood may depend on making this trip, what will you do then? Well here are a few suggestions:

  1. Find someone who’s been there and ask them to give you clear instructions so that you know exactly what to expect and are confident that it is where you want to go.
  2. Find someone who knows the way and ask them to travel with you.
  3. Find a service which will take you there safely all in one go and drop you in the city centre.

In everyday life we have little problem understanding these simple dilemmas and making the right choices. It is really easy to see how these issues interlink and the importance of getting it right. We weave different combinations of all these strategies with consummate ease on a day to day basis because we are seasoned and sophisticated travellers, children of the low-cost revolution, broadband and the set-top box.

Some of our friends and neighbours left far flung lands in difficult circumstances and completed journeys like this with spectacular success. Why then do some of the smartest people in government and business fail so miserably to plan simple journeys in business, neglect to identify their aims and requirements, fail to plan sensibly, ignore the risks and shy away from help lest they look weak or go over budget?

Yes you read it right, poor planning and failure to seek help is usually blamed on wanting to save money.