One day a
Project Manager was given a new project.
told the name of the project, the budget and the deadline.
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
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
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
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.
all, users are employed to do what users do. They aren’t experts in business
analysis, system architecture/design or in system development.
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?
the steering committee asked for a project review. This is what they were told:
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.
to this story:
There is more to defining a system than gathering requirements.
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
Robertson-Dunn, June 2010