Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Focus on Fundamentals (#21) – Working the Magic through Scope Management

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

 

Author’s note: The Focus on Fundamentals blog series addresses the challenges that limit applications solution delivery success.

 

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!

 

Previous Focus on Fundamental blogs by Jim Hughes:

Previous 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.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Ana...
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.