Enterprise Services
Showing results for 
Search instead for 
Do you mean 

Working the Magic through Scope Management

‎05-20-2014 05:49 AM - edited ‎09-30-2015 07:03 AM

By: James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company


Author’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.


creeping vine - compressed.jpgIn a previous posting (The Three Primary Causes of Project Failures) we noted that one of the primary reasons that projects fail is because they start out with poorly defined scope or project managers allow scope-creep to derail them.


Even if projects are launched with reasonable scope definitions and effort estimates, many seem to wander off track and eventually end up late and with significant cost overruns. There are a number of possible reasons for this, but the primary reason is improperly managed scope.


Scope management involves controlling apparently small incremental changes and the addition of unspecified functionality. But it also includes inadequate attention to change management discipline. For example, an end user may request a change to a proposed Web-page layout. There may not be any additional functionality or data associated with the page—and thus the functionality is within scope—but the change nevertheless adds effort and cost to the production of the system.


Scope management potholes which Project Managers and Business Analysts need to avoid include the following:

  1. Ignorance of Context – It is a standing principle that projects experience personnel turnover. The teams that prepared the initial scope definition, estimates and plans are often not the same ones who begin delivery and rarely the same ones who finally deliver the solution. Even Project Managers and Business Analysts who remain with long-duration projects from beginning to end forget details. Thus, it is often difficult for the current members of a project team to assess a requested change or addition and determine if it is within scope for the project.
  2. “The Customer is Always Right Syndrome”– Project Managers and Business Analysts want to please their stakeholders and the potential end-users of the systems they are delivering. This is a good thing. It is often ‘pounded’ into them, so that the organization can maintain good stakeholder relations. However, short-term stakeholder appeasement will soon be forgotten if the system is delayed or costs begin to escalate out of control.
  3. Avoiding Conflict – Project Managers and Business Analysts are often in customer-facing roles because of their perceived people management skills. Often this means that they are not confrontational and get along well with other people. However, this strength can also be their weakness. They don’t like confrontation, don’t want to say ‘no’, and want to avoid creating issues which might need to be escalated. Sometimes, the problem is made worse because of an inherent desire to be liked. At other times, customers will use their ‘trump card’ and say, “If we don’t get that functionality added (or this change made) then we will not sign off!” This drives the team to give in, rather than to face the customer’s presumed wrath.
  4. False Optimism – Many requested changes or additions can appear to be deceptively small and easy to absorbed within the current schedule and staffing complement. Even when the proposed changes are more significant, Project Managers and Business Analysts often still feel that they can absorb the additional effort—particularly on long-duration projects when the end deliverable dates are far off in the future.
  5. Laziness– A lack of discipline is the bane of well-run projects—whether it is ill-defined task assignments, sloppy estimate-to-complete tracking, incomplete tracing of requirements to derived work products, undefined baselines for releases, or undocumented scope additions or changes. A long chain of comments in e-mail messages is not the correct place to document change. Even using change request forms does not solve the issue from a scope management perspective because details are spread among various documents and often not introduced into the definitive set of requirements which drive software development, testing, and the production of end-user documentation.

How can we better manage project scope? Here are a few suggestions:

  1. Maintain a single source of truth – Document all requirements in one place and keep them current.
  2. Maintain traceability – Trace everything (every artifact produced by the project) to the approved requirements.
  3. Conduct impact assessments – For every change, no matter how small it may appear, document the impact of the change—to every configuration item (requirement, code module, test case, training module, etc.) and to the schedule, cost, and effort for the project. Keep reminding everyone associated with the project that every change has a cost.
  4. Re-orient regularly – On a regular basis—e.g., before each release, phase, or sprint, review the approved and budgeted scope.
  5. Apply discipline – Implement and follow a process for managing change. Ensure that the change management process is simple and focuses on essentials. For example, there may be a simplified form or process for modifications which do not change functionality, but more documentation may be required for functional additions. Project Managers and Business Analysts must lead by example and apply the process.

If we become better at managing scope we can avoid the potholes. If we don’t manage scope the potholes will soon turn into sinkholes, and eventually the project will drive off the cliff!


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



Blogs in the Producing Quality Software series by Jim Hughes


Other blogs by Jim Hughes:

About the Author


Jim Hughes - new.jpgJames (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He currently lives in Toronto, Canada.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He lives in Toronto, Canada.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all