It has been the bane of my existence as a project manager to be brought into projects long after the ‘scope’ has been set, the Requirements established and the Project Charter agreed only to find none of these critical steps reflect the ‘Truth’.
Projects start without the requisite documentation and clear understandings between business and project team, who would have thought.
It would be simple to reference the PMBOK (Project Management Body of Knowledge), the project management bible produced by the Project Management Institute. There is an entire chapter dedicated to Scope Management within its hallowed pages. Rather than provide the pat answer I would like to wrap around PBMOK some of my own experiences, I hope that this will be helpful and illuminating.
Scope is one of the triple constraints of any project; I have found there are other constraints when executing projects that we should spend some extra time on during planning and execution. The surrounding constraints that affect Time, Budget and Scope (Triple Constraint) are Organization (Change Appetite and Resistance), Process (Constraints and Integration), Technology and finally external drivers such as customers or vendors (Supply Chain Impact). While it is true that each of the surrounding constraints might affect only one of the primary constraints, they are separate and all too often ignored entirely until the project comes to a dead stand still, frequently during a critical stage such as testing or even cutover.
So starting with the basics of scope management the five distinct functions are:
1) Scope Planning. This in my opinion is where it gets fun! It is rare the PM is involved in the early stages of Scope Planning; in fact, usually the PM isn’t identified until long after the organization has identified a need, blue-sky designs of the desired result have been documented and even potential solutions identified. Oh boy, if you are that project manager you have been handed the pipe dream to make miracles!
2) Scope Definition. Depending on the timing of the PM’s introduction to the project this may either be treated as a unified process with Planning or be quite separate from Planning. As the PM you will need to determine what actions you need to take to ensure Scope is defined fully and properly. If you are lucky you were brought in early, it might be a seamless Transition from Planning through Definition to Management, otherwise this is a critical stage to kicking the project off and should be treated with due deference! The desired outcome of Definition is the much vaunted and all to rarely produced Statement of Scope, not just the high-level wish list your business users handed you early on (Requirements) but enough of the specification to define the boundaries of the project.
Depending upon size and complexity organizations may decide to seek outside assistance. In these cases the organization will write a document, sometimes called a Project or Technical Specification that will be part of a Request for Proposal (RFP). At times Scope definition can be as simple as a description of the desired outcome, at others the scope is much broader or can be defined in much greater detail such as the implementation of specific software. Scope Statements at this stage should be as detailed as possible.
The goal of the PM is to ensure the scope is achievable, clearly understood by all stakeholders, and not bound by unreasonable constraints. Where there are Risks to achieving the scope due to other constraints, explore and explode them, now is the only time you will have to say there is something wrong, you won’t get another chance. Lay your cards on the table, document your concerns and known risks. This is the single point in time that a PM can influence the organization to a more reasonable scope, one that is achievable. Establishing a reasonable and achievable scope now, one that will meet the goals of the organization without maybe the bells and whistles is better than a project that fails utterly.
3. WBS (Work Breakdown Structure), the graphical presentation of the scope. So many PM’s today skip this step, me included if enough pressure is applied. In my early years of project management I can remember a heated argument with a person regarding this very subject. He demanded I create a WBS for a complex project, I had never seen scope presented before in that form and told him that I saw no point in wasting time creating an “organizational chart” for a project when I could just jump right into creating the schedule. Many years later and many lessons learned I can honestly say that he was right and I was wrong; ouch, that hurt. But I digress from the subject at hand. The WBS, for all but the simplest projects is a fabulous way to represent the entire scope of the project in a form that makes sense and ensures all the necessary elements have been captured.
4. Scope Verification, another step that in reality is a sub-step rather than a stand-alone activity in most organizations and for most PM’s that I know. Although PMBOK has defined this as a separate and independent activity, I have always included it as part of step 3. At the end of the WBS creation, the most important boxes on the chart will be the project Deliverable(s). I personally have a rule of thumb, limit Deliverables to a maximum of three (3) per Phase whenever possible. Focus on the work not the development of Deliverables. Projects with too many Deliverables will begin to focus on these to the exclusion of delivering a quality project. I use a very simple format to validate the final Scope of any project. The approach is simple document for each Deliverable as follows:
Section 1: Deliverable Name, Goals & Objectives of Deliverable and Inclusions, which include any work-products.
Section 2: Scope Exclusions or Out-of-Scope. This is a critical part of Scope Verification and ignoring it will bite you as a project manager later. If you do not specifically call something out-of-scope than the nature of most organizations will be to consider it In-Scope. Don’t fall into this trap.
The overall product of Scope Verification should be the description of each Deliverable. In addition to the individual Deliverable descriptions there should be a Master Project Description defining the project, listing functions and features, inclusions, Deliverables and the master list of exclusions from scope. Leave nothing to chance when it comes to Scope.
5. Scope Control, finally project approval and execution has begun. Everything you and the organization agreed to is out the window! No not really, however the curse of every project manager is scope management or as I fondly refer to it as – – – expectation and exception management. During the entire process of Scope planning and verification there was a small team, usually stakeholders and a few key users if you were lucky. Now the project is underway and there are others, business managers who were not involved in the definition of scope but will be directly affected by the outcome of the project, they would like a few tweaks, a few added bells and by the way that whistle over there could you please make it a louder. Then there are the users who were never asked at all, did you consider organizational resistance in your scope? How does this change your planning? How will you manage these questions through the life of the project?
Scope Control like any other challenge is a matter of discipline and humor. Some problems, such as the business manager who would like to add more features is simply a matter of processing a Change Request and placing it before the Steering Committee for agreement or not. As the PM, it is your job to define the scope of the change and the overall impact on the project, it is not your role to tell the organization whether they should undertake this change or not. I have frequently been in this situation and the one lesson I have learned is to keep emotion and even my opinion out of the mix. Just the facts!
Scope Development and ongoing management like any other element of project management can be a straightforward exercise in common sense if approached logically. The project manager’s first job is to tell the organization what is within the realm of reality with available resources and given all known constraints. The second job of the project manager is to deliver what was agreed to.
I hope this has been helpful, questions, thoughts and comments are always welcome!
(c) Linda Valentine-Dean 2012