The Problem with Project Management Scope
by jed simms on August 11, 2009
Project management contributes to project success, but does not guarantee it. Project management can efficiently deliver the wrong result as well as a high-value result; it is content agnostic. You, therefore, need effective project management to increase the efficiency of your project’s delivery. But you cannot rely on project management to increase the quality of your project’s outcomes if they’re not set up correctly in the first place.
PMBOK , for example, does not include either a requirements definition stage or benefits management process; these are value delivery processes and therefore not part of the project management stream (even though they are often assumed to be). As project management is about organizing the delivery of “something” a project manager is naturally pulled towards getting to the delivery stage as soon as possible. The time required to define the desired outcomes and business requirements can be as a frustration to the project manager — which is why so many projects rush off with vague scope definitions and no, inadequate or inappropriate measures of success.
Which leads us to ask whether “Scope” is a project management or a value delivery tool. Traditionally, scope and its management is seen as a key project management control mechanism with strict change controls asserted over proposed scope changes. This appears to make sense when you see most scope change proposals discuss their potential impact on the project’s resources — time, effort and cost.
However, this is a mistake; as the impacts on the business outcomes, benefits and value are usually not considered. This can lead to massive value loss.
In once recent case a project under financial pressure ‘de-scoped’ one segment to save costs and keep within the original timeline. However, our value analysis showed that this one segment delivered over 60% of the business value and without it the project was not viable. This value-destroying decision was made because no one had considered the impact of the de-scoping on the benefits. Indeed, as they had used conventional business case approaches, they could not link the components of the project with the prospective benefits!
Our view is that scope management is an integral part of the value delivery stream as it establishes the value to be delivered (through what’s in and out) and should only be changed after full consideration of the resultant business benefits and value impact. It is, therefore, a value management tool.
What do you think?
4 comments
The question of whether or not changes to project scope are part of project management or value delivery management only appears to be confusing because we fail to accept that it is part of both.
I agree wholeheartedly that changes to scope are part of value delivery management and must always be assessed in terms of their impact on the business benefits delivered. Significant changes to scope should trigger an revision and re-approval of the business case.
However, changes to scope may also affect the project logistics – experience, expertise, equipment, prioritisation, interdependencies, scheduling, etc. Determining the most appropriate way to accommodate the revised scope within the framework of the existing project is part of project management. Importantly, project management’s recommended approach should also be documented and approved in the revised business case.
The control process by which changes in scope are managed – how much documentation, who signs it off, etc. – are part of overall project protocols and procedures. If these are working correctly they should remain part of the support infrastructure and invisible to project management.
by Mark Prior on August 11, 2009 at 11:31 am. #
The secret is to define scope in terms of value.
There are three common ways used to define scope, two of which lead to problems:
1. Undoubtedly the most common way to define scope is as a brief statement of objectives. Such scope cannot help but creep, or gallop, because nobody knows what they’ll get; and yet everyone assumes they know, but each can assume something different and never be aware until disappointing differences start showing up.
2. Vendors have learned to define what they’ll do in terms of tasks they can control. When the customer complains that they haven’t gotten what they need, the vendor avoids liability by showing they’ve performed the promised tasks; and the vendor will be pleased to perform and bill for additional tasks, which still may not end up giving the customer what they need.
3. The least well-known method, which indeed does curtail creep, is to define scope in terms of high-level REAL business requirements—deliverable _whats_ that provide value when delivered (or satisfied or met) by the product/system/software _how_.
by Robin Goldsmith on August 12, 2009 at 8:27 am. #
At Cumberland scope is the fourth section in the project definition and is explicitly specified in terms of inclusions and exclusions. These could be geographic, business unit, product or service, structure, process or whatever else is relevant to the project.
The first three sections are:
1. Outcome: What will be different about the organisation; addressing the, “why” question and pointing to the overall value proposition.
2. Objectives: What the project itself will achieve.
3. Deliverables: What the project will produce that will satisfy the objectives.
Scope is the fourth section because scope, what is in and often more importantly, what is out, must be aligned with the first three. For example, if a project’s intended outcome was to position the organisation to reduce national logistics costs, it
would be doomed if its scope included road transport only and excluded the Eastern Seaboard. A million dollars cannot be saved if the scope only includes 10% of the ten million dollar cost base.
Outcome, objectives deliverables and scope are each different things. Maintaining alignment between them is crucial to delivering value from the project.
by Mark Prior on August 20, 2009 at 8:16 am. #
The time spent on the requirement phase is very important when it comes to determine the exact scope of the project. Vendors are not to be blamed for not deliverying the outcomes as it is the Customer who provided the sign off on the requirments.
Project Manager should insist scope sign off from Business team and should if possible conduct a day long requirement walk through session and explaned their understanding of the project scope.
I agree with Jed that change of scope always comes at the cost of time, cost or efforts. PM while providing solution to the business team should consider the business impact. PM should consult with the business representative to understand what is critical for the upcoming release and what can be pushed in the next release.
by Rahul Bansal on January 21, 2011 at 10:31 pm. #