Project Scope Management

A key element of any successful project is how scope is managed. All too often this is where a project succeeds or fails. The reason for this is complex.

Essentially when a project is initiated a detailed PID should have been written and signed off. This should then be followed by a phase of requirements gathering which culminates in detailed requirements being produced and signed off.

However I have worked on few projects where we have been given the luxury of time and resources to make this happen.

This has usually been caused by three factors:

• Shortness of time
• Lack of resources
• Inability of the Business / Commercial stakeholders to know what it is they actually want, which leads to the critical decisions not being made in a timely fashion or being changed at a later stage.

The result of this has been that the wrong Requirements have either been documented or they have not been detailed enough for the development teams. Worse still, there have been occasions where in a rush to get to launch first, there have been no Requirements at all! This I might add is extremely common in the New Media area of the industry.

The knock on effect of this is that it becomes impossible to manage scope in the normal way which is to insist a Change Request form is filled out at which stage the Project Manager conducts an Impact Assessment and then the Project Board makes a decision.

If however the original scope itself was vague, how can you as Project Manager insist that the new Requirement was in fact a change to the project scope?

In these circumstances, and in fact in cases even where there are supposedly detailed Requirements you will find a flood of Change Requests coming into a Project at a critical time. Usually during the latter stages of Development, or during Testing.

Now you could put your foot down and insist from the outset of the project that due to the tight time frames, minimal Change Requests will be allowed, but you will find yourself in difficulties with your Business Stakeholders very fast and be accused of being "dogmatic". The Business hate nothing more than being pressurised into making decisions. By that I mean, being given deadlines by when key decisions must be made in order for the project to meet it’s deadline.

5 Real Life Excuses Heard

1."Numerous Change Requests had to be raised because the Business were forced into making decision before they were ready to make them. If they’d been given another 6 months, so much re-work wouldn’t have had to have been done at a later stage."

Comments given on a New Media project which had a total timeline of 6 months from initiation to launch, insisted upon by the Business where over 80 Change Requests were received.

2."I don’t see why we can’t just add another heading to the drop down list. It looks straightforward to me".

A comment from a non Techie Business Stakeholder who had no understanding on the concept of databases and table set ups.

3. "We cannot possibly decide the functionality of the website until we have a complete understanding of the Brand Vision. You’ll just have to wait until we’re ready".

On pushing a Business Stakeholder for a steer on the functionality the website would need to have. The Project Manager did not push for a decision, with the outcome that the technology teams had just 2 months to document requirements, design, code and test what was required. The result was a severely cut down scope, and extremely limited functionality.

4. "I’m a database expert. I once set up Foxpro in 1992".

A Business Stakeholder in explanation of why his sudden demand that the Search functionality should be a Contained rather than a Start With search and why he didn’t think it was a problem.

5. "Until we run more focus groups I can't make a decision".

A Business Stakeholder in explanation of why he was refusing to make a decision on key functionality. The Focus Groups took another 3 months to run, came back inconclusive and as a result the project launched on time but with significantly reduced functionality including the one researched!

At the sametime, you as the Project Manager cannot plan for these Changes in advance because in that case you are just giving the Business the green light to be indecisive and put in these Changes at a later stage.

However all is not lost. There are a few things which you can do to minimise the amount and impact of Change Requests coming into a Project.

Managing Project Scope and Change Requests - Tips

• Ensure the high level scope documented in the Project Initiation document (PID) is clear.
• Insist on proper Business Stakeholder involvement from day 1 in defining requirements. They will kick up a real fuss when they realise they will have to commit serious time and effort but you need to be persistent. After all if they’re involved it makes it harder for them at a later stage to say the Requirements were wrong or they had no involvement in defining them.
• Emphasise throughout the Initiation Process to everyone ie your boss, the Business Stakeholders etc how tight the timeframes, resources and budget are and that any Changes will cause the Project Status to go Red immediately.
• Raise any major scope disagreements as Risks immediately and the minute they become Issues escalate it upwards for resolution.
• Insist any "nice to have" changes to project scope are formally raised as Change Requests and are then properly impact assessed. Usually when confronted with haing to raise formal documentation these sorts of Change Request tend to miraculously disappear!