One day a Project Manager was given a new project.

He was told the name of the project, the budget and the deadline.

The name of the project seemed to cover all the Project Manager needed to know about the system he was to deliver, that and a business case that had a few additional details.

The first thing the Project Manager did was to make a plan. He knew he needed some requirements so he scheduled some requirements gathering workshops, then a development phase, equipment acquisition, a testing phase and a cutover date.

The Project Manager was happy, he had everything under control, the steering committee was happy - the Project Manager was reporting that things looked good.

Everything went well until the application developers started writing code.  It was only then that the Project Manager had to start making small adjustments to his plan. The odd module wasn't delivered on time, new modules were identified, requirements that hadn't emerged in the workshops had to be gathered, additional resources were needed and allocated. The plan needed a few changes. But what didn't change was the cutover date. The Project Manager did what all Project Manager's do, assumed that additional resources, longer hours and more effort would see the project team "push through".

And, like all Project Managers, he was wrong.

Every time new requirements were identified, more and more re-work was needed. Old modules had to be changed. Database schema had to be changed, changes that impacted all the modules that used the database. The test plan had to be extended because of all the new modules.

When testing started, users didn't like what they saw and they didn't like the way the system worked. So they did what all users do - they changed their minds. Well it wasn’t really a case of changing their minds, it was more a case of they couldn’t describe what they wanted, but they knew it wasn’t what they wanted when the saw it.

 After all, users are employed to do what users do. They aren’t experts in business analysis, system architecture/design or in system development.

 So they asked for modifications and they uncovered more requirements.

Once again the Project Manager did what all Project Managers do. They de-scoped the project. De-scope is a technical term, but essentially it means they decided, without consulting the users, that the system would do less than what the business case said it should do. The things that were left out could be added later - by another Project Manager on a different project, probably, possibly, if anyone realised.

But more testing uncovered a bigger problem. The users had been asked about how the system should work. They had never been asked what should happen when things go wrong. And things will often go wrong in computerised systems. Records don't match, people change addresses; billing and accounting systems sometime get the wrong data. Customers move, they give wrong addresses, goods get returned, payments are refused because the wrong credit card details are supplied, customers forget or are not aware of credit limits. Lots of things can go wrong with business processes. Business analysts spend much of their time worrying about "error conditions". Users don't. they just describe what they expect the system to do - if all things work properly.

Once more everyone put in more effort and got the system almost ready. Only one step was left - performance testing. This is when the final system is tested for things like response time and the number of concurrent users.

Now the Project Manager started to get really worried. The system was very, very, slow. And that was with just a few users. When more and more users tried to use the system it, unbelievably so, got slower and slower.

It wasn't just the Project Manager who got worried. The steering committee started to put the Project Manager under more and more pressure. Why were things late, why did the tests fail, why were there requests for more and more servers? Why has the project suddenly become late?

Finally the steering committee asked for a project review. This is what they were told:

• The system will never meet the objectives of the business case,
• The system has only implemented some of the expected functionality,
  
• The design of the system can never meet the performance requirements,
• Performance needs to be designed in from the start and in this case - it wasn't.

The moral to this story:
There is more to defining a system than gathering requirements.

And whatever you do, don't let a Project Manager anywhere near requirements. Get an architect, that’s what they do. That, and make sure the project delivers what users really need. 

Bernard Robertson-Dunn, June 2010