Project Scope is King
By Cindy Vandersleen | minute read
In PMI's (Project Management Institute's) Project Management Body of Knowledge or PMBOK, which is the bible of project management, there are nine knowledge areas discussed; Integration, Scope, Time, Cost, Quality, Human Resources, Communications, Risk and Procurement. Anyone who has studied for their PMP certification knows these well, ad nauseam even, and knows that the PMBOK discusses these with equal weight. Indeed, PMI loves all of her knowledge area "children" equally, but out in the real world there is one that I believe deserves your extra undivided attention and that is scope.
Most people who have worked on a project in any capacity are familiar with the notion that projects are controlled constantly by what's known as the triple constraint - time, cost and scope. You can control any two of those factors and the third one will be defined for you. Never do projects that begin with a fixed amount of time or budget and an organisation saying "Gee, I wonder what work we could go do with all this time and money?" Projects begin because there is a specific need to address, problem to solve, or opportunity to realise - i.e. scope. It must be the first thing defined and boundarised in a well formed scope statement. After that you determine the amount of time and cost to adequately deliver the scope of work of the project. While I will concede that neglecting schedule, budget, quality, communications, human resource issues or risk management can certainly hurt a project badly, neglecting scope management will kill a project. This is because it is the very essence of what defines success for the project. It is the "what you are doing" on the project. You can work very fast and inexpensively, but if you have worked on the wrong things, you will not be declared successful.
From a public relations perspective, scope can be one of the areas that generates the greatest potential for confusion so project managers should begin communicating what is in and out of scope early and often to wide audiences of stakeholders, within and beyond the project team. One of the worst morale killers on a project is when a high level stakeholder says late in the game "but I thought I was getting 'X'". The project charter and high level scope statement documents serve as good tools to aid in these types of presentations. Once the detailed baseline scope statement is developed, it should be formally approved by the project sponsor, communicated widely, and constantly controlled. To control the scope, we advocate adopting a form for use in capturing scope change requests from the outset and setting up a committee of sponsoring stakeholders (not including the project manager) responsible for approving changes. Change requestors should document the change and presumed benefits, and the implementation team should have a chance to document the impact to the current project schedule and budget. This package is then presented to the change committee for decision. The project manager must communicate the final decision to all stakeholders and factor the impact back into the project plan. This allows sponsors to remain in control of the resources, and keeps the project manager from being the "bad guy" if the decision is no. It also provides a mechanism for protecting the team against taking on extra work without the benefit of the time or extra resources to accomplish it.
So it behooves project managers to seek out opportunities to communicate scope as often as possible. Let's review some of the typical venues and aids for scope communications:
|Charter Review Meeting||General Interested Stakeholder||Project Charter|
|Scope Statement Development Meeting||Project Team||Scope Statement|
|WBS Development Meeting||Project Team||WBS|
|Estimation Meeting||Project Team||WBS|
|Project Kick-off Meeting||Project Team||Project Charter; Scope Statement; Roles & Responsibility Matrix; Project Org Chart|
|Executive Sponsor Meetings||Executive Sponsors||Scope Statement; Project Schedule; Roles & Responsibility Matrix; Project Org Chart; Change Requests|
|Stakeholder Meetings||General Interested Stakeholder||Project Schedule; Roles & Responsibility Matrix; Project Org Chart; Change Requests|
|Change Control Meetings||Change Board||Change Requests; Project Schedule|
|Project Team Meetings||Project Team||Scope Statement; WBS; Project Schedule; Change Requests|
Keeping all interested parties aware from the outset of the approved scope and any subsequent changes, so that there are no surprises downstream is in the best interests of the project team.
Cindy Vandersleen is a certified project management professional and has held positions as an executive IT leader with progressive experience in information technology and project management disciplines. She is proficient at improving business processes through analysis and facilitated group redesign. Cindy is an approachable business partner and compelling team leader, guiding teams to successful outcomes through problematic environments. She has led teams successfully through mergers, acquisitions, and offshore outsourcing initiatives.