Decently and In Order
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:
Get a project charter.
Create the project scope statement.
Create the WBS with the project team.
Create the activity list from the WBS.
Sequence the activities in the order in which they must—or should—happen.
Estimate the time of the activities based on which resources you have to complete the activities.
Assign the needed resources to the activities.
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.
This takes time.
Whether you're managing the creation of software or building a new four-bedroom home, there is usually a window of opportunity for the customer and the project team to continue to work together to ensure that the deliverables are good and working as planned. This can be through a service agreement or a warranty. The bottom line is that most major projects have a certain amount of time allotted for the customer to use the deliverable and to report any problem to the project manager for corrections or support.
This business needs to be defined upfront; it cannot be left to assumptions. It's no fun when the customer assumes that you and your project team would be supporting the deliverable for eternity when you assume that you'll be supporting the deliverable for the next three months. No fun at all. A clearly defined Operational Transfer Plan, warranty, or agreed level of service must be defined early in the project. And then stick to it.
If only I had known all this business back when I was sweating out lawn work for Ms. Rite. Scope management, big or small, boils down to agreeing on what the project will and will not deliver. Then both parties must live by the agreement. After all, a deal's a deal.