"If it's what the client's asking for..."

Scope Change, allow it at your peril!

Last week, in my article ‘Project Overspend, don’t worry about it’ , I focused on budgetary control, but this week an intervention with a new project manager at my client’s site, got me thinking.

There is very little more risky for an interim or project manager than having a project under control, i.e. running on time and within budget. Sooner or later a team member is going to get bored and with boredom comes the number one enemy to any project, Scope creep.

In fact scope creep is born out of three circumstances, one (as mentioned above) boredom, and the other two arrogance and laziness (the total absence of, or, a poorly written scoping document).

Boredom:
An under utilized engineer, is a potentially serious risk for scope creep. Engineers need something to do, problems to solve, their world is complexity. Thus a bored engineer, in the absence of a challenge, needs to create one. I have witnessed several occasions where an engineer has 'created' (thought up) a problem for themselves to solve. Coming up with a soliution to a problem that might not exist is a great past-time and is often born at the coffee machine, in a heated debate with another engineer. It gives the engineer new purpous and the chance to shine and be noticed.

The first thing the project manager knows about the 'problem' is when he finds himself in copy of a plethora of e-mails, flying around, warning of impending doom unless an urgent issue is tackled immediately. Crisis meetings are set up by the engineering team, and e-mails are often sent over the head of the PM, directly to the project sponsors.

Even when the ‘issue’ is analized as being quickly resolvable, the founding engineer can take the claim for having saved the project from immanent disaster – even though many other engineers, would have just solved the minor problem, without even bringing it to the attention of his or her entire community. Now to be fair, it has to be said that, this phenomonum is not restricted to only engineers, it can be any under utilized team member, sometimes it can even be the project manager himself!

Arrogance:
Arrogance shows its ugly face, often when a new team member comes on board. Rather than reading the scope document (assuming there is one), they make a few quick observations, notice something that is ‘obviously missing’ or overlooked and immediately act in much the same way as the bored engineer above.

It is an unfortunate aspect of human nature that we always believe that we are somehow better, cleverer than most other people. And nothing demonstrates this better than a project manager or consultant during their first few weeks with a new client; “how is it possible that you can run without X or Y” or “In my last company we always did it this way or that…”

The Scope Document:
The most important part of any project has to be the definition of the scope, get this wrong and disaster sooner or later takes hold.
Imagine that your client asked you to put together a team to produce a device that allowed people to speak with one other anywhere in the world (for the sake of this metaphor, we’ll assume that the mobile phone has not yet been invented, but the network is there). The scope will need to be pretty strict to ensure the project meets its objective and we will only know if the project meets its objective if we know, in advance, what the fixed criteria are by which it will be measured. In the case of the mobile phone, it needs to broadcast and receive spoken conversation, nowhere in our imaginary scope document, does it say anything about short message texting, playing games, surfing the internet, buying buss tickets, paying for parking, playing music, watching TV or adult content channels or whatever else today’s mobile telephones can do.

Consequently, a project without a very strong and clearly written scoping document, signed off by all the stakeholders, is on the road to disaster before it even starts. The project will end up being ‘designed’ in the BREQ (Business requirements document). I have noticed that it is at BREQ stage that everyone comes out of the woodwork to have their say on what they want included and what is needed, especially those who are not paying for the project! These people will tell us why our mobile phone can not just be a phone but needs to be a PDA and computer as well. Six months go buy, instead of six days, and still the project is not ready for pricing estimates. And when the estimates finally come in, it is more often than not, a shopping list of nice to have’s that the timeframes and budgets simply can not support.

So my advice to any new project manager is; 'ignore the scoping document at your peril, otherwise throughout the project people will invent important new features and functionality that ‘somehow must have been overlooked’ and the next thing you know, you (the PM) are going back to the sponsors announcing delays and the need for more cash'.

I believe that it is the personal responsibility of the project manager to get the scope under control from the beginning and defend it rigorously until the end of the project. The scope document also needs to clearly state what the project won't deliver, expectations need to be measured and controlled.

If your client decides they don’t want the project, or its deliverables, after all – then obviously you simply need to stop and cut your loses. On the other hand if your client keeps changing their minds about exactly what is required, then you had better put the project on hold and force the client to taking seriously exactly waht their requirements are before another day or Euro is wasted. Putting a project into ‘pause’ mode is very handy, it’s not as dramatic as 'on hold' or 'stop'. Pausing a project is about creating a brief time out to go back to basics and to be sure that what was originally asked for is actually what we need and going to be delivered.