December 11th, 2018 by Adam Sandman
One of the major reasons that software projects are cancelled, fail to deliver the expected value or experience massive cost / budget overruns is due to a failure to grasp the risk and issues associated with managing the scope. This article describes the three most common types of scope management failure with suggestions of how to avoid such a fate.
by
The record of how information technology projects fail has been studied and documented in numerous reports, such as the infamous Standish CHAOS report. The staggering statistics of the percentage of projects failing to meet their schedules, experiencing budget overruns, and failing to deliver the promised business value doesn’t always lead to technology as a failing component. The origins of failure often are not associated with the technology but the people unable to relate to the scope in the big picture and the inadequate controls in the processes. In this blog article, let us focus on requirements on some of the lesser known aspects of scope management
1. Scope Grope
One of the less familiar aspects of scope management that plague the software industry is the team’s inability to articulate the requirements. These requirements manifest themselves as the rough draft of “wish lists.” This may also include some of those “gold-plated” features that are thought to be adding value. However, since these requirements are not solidly grounded in the technical, operational, and economic feasibility, these requirements do not strategically relate to winning more business, streamlining multiple channels of engagement, increasing employee performance, etc. These kinds of requirements become the "scope drifters" and are often a "productivity spoiler" and "promises stealer" because the business team fails to articulate the requirements clearly for subsequent analysis and design.
Occasionally, this challenge may further be passed from the business team to the technology team where the requirements further need to be assessed for technical plausibility within the constraints of human capital knowledge, budget limitations, security and compliance considerations being some of them. This scope grope may further be experienced by delay tactics by execution team members and the agile approaches to time-boxed delivery may be easily be used to consider spikes as a limited experiment.
Among the many techniques available to use, a good technique to consider by both product managers, project managers, and business analysts is the SIPOC model (commonly used in Six Sigma quality processes). Using this model can help understand the relevance and importance of the entire value chain and the business impact of delivering or not delivering these wish-list features! Additional techniques include the benefits register, use case diagram, SWOT, PESTLE analysis, etc.
2. Scope Creep
This is a popular terminology even among agile practitioners that are suspicious of anything plan-driven. Although many relate to these concepts, there is a misconception that scope creep only involves the addition of new features not originally in the scope. Scope creep may also result from removal from scope any requirement and based on the time of the request, there may be rework required to revert some or all the changes done.
Perhaps mistakenly inherited from some of the account managers that view scope creep only as change orders that need to be executed with their client to reconcile financial changes in scope, the need to understand the process used in managing the product, program, or project cannot be emphasized more. Any organizational change control policy or governance framework has to document changes not in the form of scope initiated by the client or product managers due to the market forces in the form of new or modified requirements but also the changes to the environmental context, such as changing from using a No-SQL database to a relational database due to lack of technical support of the old tool, that impact the project’s schedule, cost, risk and quality.
Since the scope may have to reworked to bring the project to the same stability before additional work can be executed or released to the customer, the project manager’s astute awareness of the commercial and non-commercial aspects of the project’s boundary conditions may very well require additional stakeholders to be identified.
Sometimes, people may resort to what is often called “Scope Kill”. It is an attempt to disengage with new ideas because the project’s operating framework doesn’t allow it or the organizational culture doesn’t have an appetite for innovative ideas. There are many reasons for these "scope kill" contributors and some may include scrum masters not parking new ideas to be discussed at a later point and using time-boxing as an excuse to immediately mute the flow of ideas.
Several tools exist to control scope but one of the most critical tools is to have a RACI through which the Stakeholder map can be formed better to build alliances and form bridges to ensure that benefits are aligned, risks are mitigated, and quality is not compromised. The other tools include risk register, communication plan, stakeholder register, risk-adjusted backlog, a documented change control process and blue ocean thinking.
3. Scope Leap
Another uncommon terminology related to scope management is the scope leap, which is a result of a dramatic shift in the strategic focus or tactical direction of the organization altering the backdrop under which the project, product, or program is operating. In such cases, the measurable organizational value (MOV) no longer holds true completely. As a result, the focus of the minimum viable product (MVP) may also its significance for the product and project managers.
(Credit: Kiron Bondale, https://kbondale.wordpress.com/2013/08/25/avoid-scope-leap-with-your-agile-project/)
This can often happen in Agile projects where you are assuming that the original MVP is a good initial representation of the "final" product, and that each iteration is getting closer to the desired end-state, when in fact, the subsequent iterations are diverging from the original concept dramatically, often without people realizing. When this is intentional, it's often called a "pivot", but when not intentional, it is really a "leap" of scope:
(Credit: Kiron Bondale, https://kbondale.wordpress.com/2013/08/25/avoid-scope-leap-with-your-agile-project/)
The biggest challenge comes in when the same techniques for handling the Scope creep are used. Often, scope leap is happening when the project is in-flight and it is understandable why one would resort to these techniques. However, since the project’s assumptions and subsequently the charter have been changed, getting back to the scope grope tools is better to re-validate ourselves before moving forward.
Takeaways
In the end, before any technology can be associated with a project's failure, think of the role played by people, process, and organizations on a product’s and project’s scope and the resulting outcomes. It is possible for an IT project to fail because of technology but not all the technology project's failure come from technology failure!