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:
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 its 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 theyd been given another 6 months, so much re-work wouldnt 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 dont see why we cant 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. Youll just have to wait until were 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. "Im 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 didnt 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
Sign Up for Our Free
Return to top | Home |
Project Management Basics | Project Management Life Cycle | Project Management Documents |
Writing a Project Initiation Document (PID) | Project Management Report | Project Management Plans | Project Risk Management
| Project Management Scope | Project Costs and Budget | Project Resource Management |
Project Communications | Project Software Development | Sitemap | Contact Us |
Original Content Copyright © 2009 My-Project-Management-Expert.com
All other content is in the public domain or is copyright by the credited author.