Project Management Book

...chapter 2 continued

Let us now turn our attention to the software development lifecycle.

IT people love inventing new words and co-opting existing ones into impenetrable jargon in order, some would say, to bedazzle the uninitiated.

Extreme Programming, RAD (Rapid Application Development), DSDM (Dynamic Systems Development Method), Functional Specification, EFBERD, Object Oriented - the list goes on and on. Every few months a new way of doing software development is invented. Except that it isn't.

There are something like 400 activities in the software development lifecycle. Define a data item; write a program; write a test case; design an icon; hold a team meeting; etc. Whatever you call the process into which these activities are slotted, the software development lifecycle remains fundamentally the same. A rose by any other name... But renaming the rose gives the illusion of dynamism, of innovation, of the availability of easy solutions to thorny problems.

If only it were so.

Developing large software applications is tremendously difficult. Witness the number of well publicised software projects that are seen as very expensive disasters. If anyone really had found an easy answer to the software development challenge such disaster projects would surely not still be happening.

Unfortunately, problem projects are not caused by "a problem" which has "a solution". We will examine some of the factors which, if not addressed, lead to software project failure.

We have in a sense already alluded to one of these: the notion that there is such a thing as "an IT project". This conjures up the idea that a commissioning company or public sector organisation can call in a software house and get them to do the project: leave it all to them and let them get on with it. The suggestion that the commissioning organisation should commit significant numbers of their own staff to the project provokes the response "what are we employing the contractors for?" You don't buy a dog and bark yourself, do you?

Underlying this attitude is a fundamental non-understanding of the software development process. Talk to users who are involved in a software development project and you will find they often have no conception of the lifecycle - the manufacturing process - of which they are a key part.

So, let us look at the software development process and see how user and IT - client and supplier - should work together.

Whatever you call the following steps - and everyone and every methodology has their own terminology - you must go through these steps when developing software.

Try this the next time you have a project team meeting. Give the team ten minutes individually to write down what work should be done, and to what level of detail, in each of the six steps above (or your equivalent of these six steps). Then get them to compare notes. (And by the way, "the team" includes the users.)

Will they all have the same opinion of the major activities and outputs of each step? You can bet your house they won't. The IT guys will have strong, but differing, opinions about what they think should happen in each step and many of the users won't even understand the question let alone have a clear view of the answer.

Imagine on Monday morning you're starting a project. At the peak there will be 60 people in the team. 30 IT and 30 business users. They've never worked together before and you ask them the question: what should happen in each lifecycle step. You'll probably get 61 different answers - 60 plus yours. Might this cause a problem in your project? It could cause chaos. What would you do about it?

One solution might be to get all the team members you can identify (at the beginning you won't know who all 60 will be) together for a day and define exactly what your software manufacturing process is going to be. At the end of that day you will have for each step a list of the activities within it and the deliverables from it.

For example, you might conclude that the User Functions Design step will deliver a User Functions Design document (Functional Spec, call it what you will) which will have five chapters and chapter 3 will be screen and web page designs (and you may even have a model from a previous project); a revised Cost Benefit Case; a Test Plan; a Plan/Schedule for the IT Technical Design step; etc.

But, you say, aren't these things all defined in the standards? Surely we don't need to re-invent the wheel for each project? And shouldn't the IT guys know what they're doing anyway? Maybe; yes you do; and probably, respectively.

Nobody reads standards and even if they did they probably wouldn't understand them - and that's assuming the standards actually define the software development process adequately. Every project is different - you at least need to tailor standard processes to meet your project's unique characteristics. Yes, the IT guys may know what they're doing within their own specialist sphere but may lack a clear grasp of the overall development process. How much does your average techie know about gathering user requirements? And those users for whom this is their first project? They won't have a clue what should be done in each step of the software development lifecycle.

So from that one day meeting you emerge with a clear manufacturing process that your project will follow. But far more important, by the end of that day your team will have a common understanding of the manufacturing process you will use. They know what work will be done in each step and to what level of detail and they know precisely what will be delivered from each step.

Requirements Analysis

In that one day session there will be a lot of debate about the level of detail at which the requirements should be defined in the Requirements Analysis (or whatever you choose to call it) step. Some will say they should be defined "at a high level" (which means nothing), others will say "in quite a lot of detail" (which means nothing) and others will say "in as much detail as possible" (which can mean anything you want it to mean), and some won't really know what you mean by "define requirements" anyway.

In how much detail should the requirements be defined in the Requirements Analysis step? By the end of that step you must have defined every item of data (e.g. Invoice Number): how many digits or characters long it is and its valid values (e.g. must be all numeric). And for each business process (e.g. take an order): which data items go in to it, what happens to that data (look ups, calculations, is it to be stored). And for each output (e.g. an Invoice): the data that must appear on it and how that data is calculated or derived.

One way to get across to the team, particularly to the business users, how much detail is needed in the requirements is to say: "imagine the computer has not been invented (which usually raises a cheer) and you have to write a procedure which somebody off the street could follow step by step and thereby run your business - in how much detail would you have to write the procedure?" At which point they will all go "phew" when imagining the huge amount of detail that would be needed.

For example

1. When the phone rings pick it up
2. Ask the customer for their customer number
3. Look it up on the customer number list
4. If they don't know their customer number ask for their name and address...

And so on for many many pages. And even considering the above you can probably think of half a dozen what ifs? that would need to be defined (what if it isn't a customer who is ringing...?)

Holding brutally rigorous requirements definition workshops, which may last for weeks, can be an effective way of extracting from the heads of the business experts exactly what the process is that they want automating. But you will find that when you press an expert in, say, Credit Checking to articulate exactly what the process is he doesn't know. (And if he can't tell you, the programmers have got no chance.) So, you stop the session, tell him to go and find out, and continue when he has the answer.

And you must define all the what ifs. What if the customer changes the order? What if we entered the order incorrectly? Simply defining the basic processes that would be followed in a perfect world where everyone gets everything right first time will leave you with a system completely unable to function in the real world.

Defining requirements thoroughly and fully can be a very painful process - a bit like ice breaking: you ram at the ice, get stuck, back off, ram at it again until finally you break through.

Don't forget the less obvious users like Legal and Internal Audit: they will have requirements too particularly if you're building a new, green field site system. Trying to retrofit things like audit trails can be tricky.

Users are absolutely hopeless at defining their requirements - almost as bad as IT people. So what's the answer? People - business analysts you might call them - who are trained how to extract requirements from users. These people know how to run those hot-house requirements definition sessions and ensure the results are clearly documented. They will be very hard-nosed and insist that no detail is glossed over, that no-one is allowed to get away with anything other than a complete and detailed definition of their part of the business process. This is very difficult as the business process being defined may not exist today - it may be a new business process or a re-engineering of an existing process. Running these requirements definition workshops really is a highly skilled job.

The requirements definition sessions should not just be attended by users and business analysts. Members of the IT design team should attend too. Why? Three reasons: they can point out that the way a business process is being formulated would make it difficult to design and program and perhaps that an equally good way of doing the thing would be much easier to solution. Secondly, these IT designers have a very powerful incentive to make sure the requirements are properly defined because if they aren't they will have great difficulty in the design step. But most important, the IT people get a feel for what the users really want - what's important to them, how things should work. They will pick up a lot of useful insights which would never have come through from a dry business process definition document.

Even try saying this. "Team - users and IT - in the Requirements Analysis step I want you to define all of the requirements such that there would be no need for the IT team to ask any user about anything later in the project."

In a project, whose job is it to make the users define their requirements properly? The project manager's.


...next

Privacy Policy and Cookies