Do we fully understand Scope Management?

The record of how information technology projects fail has been studied and documented in numerous reports, such as the CHAOS, McKinsey, etc. 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 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 less known aspects of scope – the boundary of what controls what the project should deliver!

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

Scope Creep: This is a popular terminology even among agile practitioners that despises 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 viewing scope creep as change orders 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 must 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 that also impacts 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.

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 the scrum master 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.

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 may also have its significance for the product and project managers.

The biggest challenge comes 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 revalidate ourselves before moving forward.

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 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!