Project Management Scope

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 Project Scope Statement has to be completed. This is contained within the Project Initiation Document (PID) which is the essential reference guide to the Project and what it is delivering. Once this has been formally approved it is usually 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.

Project Management Scope Tips

• Ensure the Project Scope Statement 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.