« The Simplified Project Management Process
Projects And Anger Management »

Creating The Project Scope - Decently and In Order

May 14, 2008 | Author: admin | Filed under: Scope Management, Project Scope Management

Creating the Project Scope - Decently and In Order (#10 in the series Creating The Project Scope)
By Joseph Phillips

Sometimes new project managers get frustrated at all these processes and extra procedures, and just want to get to work. Rookie mistake. Projects, well…successful projects, follow a proven system to get to the execution of the project plan. If there were a Robert’s Rules of Order for Project Management, the precedence of all this activity would go something like this:

  1. Get a project charter.
  2. Create the project scope statement.
  3. Create the WBS with the project team.
  4. Create the activity list from the WBS.
  5. Sequence the activities in the order in which they must—or should—happen.
  6. Estimate the time of the activities based on which resources you have to complete the activities.
  7. Assign the needed resources to the activities.
  8. Get it done.

Of course, that’s a quick summation of how the project team gets to work in a perfect world. I realize that it doesn’t always go this way; in the real world, projects often fail.

Once the scope has been defined, the WBS has been created, and the customers sign off on both documents, the project manager wants to lock down any additions or changes. This is scope change control. How many projects have you worked on where the customer bangs on your door every day with a few hundred changes for the project deliverable? Okay, maybe they don’t bang on your door every day, but I bet they pop in with some “oh-yeah moments.” Or they’re so impressed with the good job your team is doing that they realize you could easily work in a few more details for them. Right?

Oh the horrors.

Once a project scope and WBS have been agreed upon, it’s up to the project manager to ensure that the project team and the customer that changes won’t easily be allowed into the project. The only way this is going to work is if the project manager communicates to the customer the documented and tightly followed Change Control System (CCS). A CCS serves as a shield from unnecessary and bloated changes. It requires the requestor to document the change request, why the change is needed, and the ramifications of the project deliverable if the change is denied.

From the requestor, the change is promoted to the manager, project sponsor, or directly to the project manager. Eventually the change may be promoted to a Change Control Board (CCB) where some cheery folks will debate the value and worthiness of the proposed change, and can elect to decline or approve the proposed change.

Any change that is seriously considered must have plenty of research to determine the influence of the change request on the rest of the project. At a minimum, the change must be evaluated for the following attributes:

  • Ramifications of declining the change request.
  • Risk of accepting the change.
  • Cost and time to include the requested change.
  • Effect of the change on the project quality.
  • Effect of the change on any procurement decisions, contracts, and financials.
  • Effect of the change or series of changes on the project team’s ability to complete the project on schedule.
  • Effect of the change on the project team’s morale.
  • Effect of the change on the project manager’s chances of a promotion or bonus. Kidding.

Like it or not, some changes are great for the project deliverable, and it just makes sense to include them in the project scope. Other changes—again like it or not—will not be good for the project. All changes, good or bad, need to be documented and researched. This takes time. A flurry of change requests, even if they are all declined, will usually pull the project manager and/or the project team away from their focus of getting the project work done. A documented and working CCS is mandatory for any organization.

So how do you know when the project is done? Some would say when you run out of money or out of time. To some extent, that’s true—if the planning has been done accurately, the project should end on time and with no remaining funds. But this is supposed to be a realistic discussion on project management.

Projects are finished when the project scope has been completed. A project is complete when the project scope equates to the present state. A project is complete when the project manager and the project customer can take the WBS and check off each item like last week’s shopping list. This is scope verification.

Scope verification is simply the project manager and the project customer inspecting the project deliverables to ensure that all the promises in the project plan exist in the project deliverable. There may be some rework, corrective actions, or last-minute change requests to complete the project; if all goes according to plan, the project manager and the customer are in agreement that the deliverables equate to the project scope.

Joseph Phillips is the author of five books on project management and is a, PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. For more information about Project Management Training, please visit Project Seminars.

Share this article:
  • StumbleUpon
  • Digg
  • del.icio.us
  • Technorati
  • Reddit
  • YahooMyWeb
  • blogmarks

Related Articles

This entry was posted on Wednesday, May 14th, 2008 and is filed under Scope Management, Project Scope Management. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories