Project Management Articles

The 5 Steps to Writing a Project Scope Statement Which Eliminates Scope Creep

Having to write an unambiguous and accurate project scope statement can be one of the most difficulty tasks in getting a project initiated. It may not seem so at the time. In fact on the surface it appears to be one of the more simple tasks required. But if you think this then you are in for a nasty surprise. Get this section wrong in the project initiation document (PID) - scope or project charter and you will be heading for either scope creep, or worse still, a failed project.

So why is this section so problematic? After all it only consists of three sections in which the Project Manager has to define project scope made up of; Proposed Solution, In Scope and Out of Scope.

Now too many Project Managers think that the “woollier” the project scope they write the better. After all one can never be 100% clear on project scope at this stage simply because often the business requirements documentation (BRS) hasn’t been signed off yet. But by following this strategy all you are doing is storing up huge problems later on in the project management life cycle for yourself.

For example, well meaning project management stakeholders (specifically those in the business area) have an unfortunate knack of changing their minds once the project commences. By this I mean that they will keep insisting that more functionality is delivered. This in itself wouldn’t be so much of problem if they also didn’t expect this increased scope to be delivered for the same project budget and in the same timeframe.

The problem is that if the project scope statement has been kept deliberately vague, the project manager can’t push back by insisting that the project deliverables have changed, because it is “open to interpretation”. This soon becomes an ongoing battle to fight against the constant scope creep. To stop you getting into that position there are 5 steps you should need to follow. These are:

1. Insist on adequate project sponsor input from Day 1. Yes this will be easier said than done, particularly on smaller projects, but if the project doesn’t deliver it is your reputation which will suffer, not the project sponsor’s.

2. Ask the project sponsor’s to tell you what they think the project is delivering. Speak to them individually as it will highlight whether everyone has the same understanding.

3. Once you have gathered the “big picture” information on the scope and gained a consensus of opinion, move down into the nuts and bolts of the deliverables. At this stage, by getting the input of the business analysts, developers and testers you can quickly clarify what can be delivered within the timeframes set.

4. Remember that what is Out of Scope for the project is possibly even more important than what is In Scope. So don’t overlook this section.

5. When you have completed writing the project scope statement, pass it by the project sponsor’s and key project management stakeholders first, for their comments and feedback. Once you have their buy in, your project stands a good chance of delivering what is required.

And Finally...........

Personally I hate writing project initiation documents and find the project scope statement section a real chore. However I have learned from experience that time spent at this stage in really nailing down the scope and in gaining a consensus is always well spent, as later on you will be able to spend your time actually delivering the project, rather than having ongoing battles about scope.

Plus it should reduce the amount of project change requests raised, which can only be a good thing!

---