Software Project Scope Alignment: An Outcome-Based Approach

Decades of evidence reveal a shockingly low success rate for software projects. In their first CHAOS report in 1994, The Standish Group reported that 16% of IT projects were successful, 31% were failed, and the remaining 53% were challenged. In their 2004, reported ratios improved to 29% (successful), 18% (failed) and 53% (challenged). Although the record is slowly improving, much work remains before software project success becomes the norm rather than the exception.

Glass² and Field,¹ among others, cite inadequate project scoping as a major contributing factor to project failure. Scoping is a project initiation activity that defines the project’s boundary, by identifying the problem domain needs to be met and the software elements expected to be delivered. In addition to identifying the product (problem domain needs and software elements), scoping also sets out the project’s value and quality metrics and resource (such as schedule and budget) requirements.⁷

This article is grounded on the premise that effective scope definition will reduce the impact of scope changes and increase the resource estimate accuracy, thus reducing the likelihood of scoping-caused project failure. The Outcome-Based Scoping (OBS) model is proposed to reduce the likelihood of scoping-caused failure. Using OBS, project leaders develop a more complete understanding of how to meet the problem domain objectives, not just deliver a working software solution. OBS recognizes, as did Vessey and Glass (1998), that much of the software engineering process is better characterized as domain problem solving. Thus, OBS first defines the problem domain scope model; from that foundation, the software domain scope model is then developed. The OBS model further structures the scoping effort by decomposing the concept of scope into two dimensions: intent (representing the goal) and blueprint (representing the resources required to meet a specified goal). The remainder of this article develops the OBS model and provides a case study illustrating its use.

OBS defines the relationships within and between the problem and software domains to include (as shown in Figure 1):

• The Problem Domain Intent (PDI) defines the intended problem-domain outcomes that provide the boundary for the following model component (the Problem Domain Blueprint).
• The Problem Domain Blueprint (PDB) identifies the stakeholder-specific changes and resources required to enable the PDI-expressed intent and drive the following model component (the Software Project Intent).
• The Software Project Intent (SPI) translates the PDB candidate solutions into software scope elements that provide the boundary for the final model component (the Software Project Blueprint).

The Software Project Blueprint (SPB) identifies the project-specific resources that will deliver the required software scope elements that will then ultimately enable the first model component (the Problem Domain Intent).

Through these four successively generated models. OBS defines the software project scope by mapping software scope elements that will directly enable the original problem domain intent defined in the PDI.

Back to Top

OBS Field Study

The OBS model is illustrated through field data collected during a software development project at a mid-cap firm, whose pseudonym is Market Maker (MM). The project was selected by convenience, but with no pre-conceived notions concerning the efficacy of the OBS approach. Called MM-MBO in this article, the case study project focused on MM’s Management By Objective (MBO) initiative, which identifies and aligns MM strategic plan objectives to departmental objectives to quarterly employee objectives.

MM was relying solely on a paper-based MBO process; the original MM-MBO goal, prior to use of the OBS model, was to automate MM’s current manual employee-level objective process. The software project’s sponsor was the Human Resources Director, whose responsibilities included employee objectives, incentives, and compensation. This project was initiated based on its tactical / operational value to the sponsoring HR function, without regard to the cross-functional or strategic implications and opportunities. The OBS approach was used after the original project scope statement had been completed; as we describe later, the OBS-scoped project resulted in increased accountability and traceability to the planning problem domain.

Back to Top

Problem Domain Intent (PDI)

The PDI model, shown for the MM-MBO project in Figure 2, sets the project’s context and expectations using a hierarchy^3,5 to structure intended problem-domain outcomes and success measure targets. Within the hierarchy, subordinate problem-domain outcomes are identified, which must be achieved in order to satisfy a superior outcome. Essential to this approach is specifying the problem domain outcomes unambiguously and in terms of a concept that has achieved a desired state. No mention is given to the software deliverables. The PDI also specifies a parallel measurement hierarchy with measures that are quantifiable and achievable. The identification of these measures is critical to validate correct and complete outcome identification and to judge outcome completion. The measures are shown separately to explicitly link a given high-level outcome to its subordinate outcomes. In the final project scope statement, this measurement hierarchy becomes the metric to judge project success.

The left pane of Figure 2 details the MM-MBO project PDI. Consistent with the prescribed PDI hierarchy, Annual Plan is Implemented is achieved only when the firm-level plan is approved, departmental plans are created and plans and action items from individuals are aligned with the department plan. In parallel, a measurement hierarchy is specified to validate accomplishment of planning intent. For the MM-MBO project this encompasses Annual Plan measures that are quantifiable and achievable; department measures that are quantifiable and achievable with full firm-level annual plan coverage and alignment. This measurement structure becomes the metric to judge project success. An example of a MM-MBO project outcome and measurement description can be found in Table 1.

Prior to applying the OBS model, the MM-MBO project was initially scoped to include only the objectives of Employee Plans Are Approved and Employee Plan Is Executed. Departmental and firm-level outcomes were ignored, as were all metrics that would reveal whether or not the project succeeded in improving planning results.

Back to Top

Problem Domain Blueprint (PDB)

For each defined PDI outcome, a PDB model is defined. Each PDB explicitly defines what is needed from each key stakeholder perspective to accomplish and validate that outcome. The right pane of Figure 2 illustrates the PDB for a subordinate outcome, Employee Plan is Executed and its measurement counterpart, Employee Plan is Measured. Within the PDB, the resources (for example, facilities, tools, processes, and techniques) needed to achieve and measure the outcome are solicited from the:

• Responsible party perspective, the unit responsible for achieving the outcome.
• Internal and external stakeholder perspectives, that constrain or contribute to outcome achievement

Human resources, management, and information systems are described by Kaplan and Norton (2004) as the “ultimate source for creating sustainable value for the organization.” These elements are added in the PDB model to reflect their supporting services necessary for outcome achievement:

• The human resources perspective identifies the people, skills, and training needed to achieve and measure the outcome.
• The management perspective identifies the culture, leadership, motivation and teamwork characteristics needed to achieve and measure the outcome.
• The information systems perspective sets out the software scope elements and technology infrastructure that will be needed to achieve and measure the outcome.

Given the paired outcomes Employee Plan Is Executed and Employee Plan Is Measured from the MM-MBO project’s PDI model, Table 2 illustrates the problem domain scope identified within the associated PDB, revealing what is needed from individual employees (the outcomes’ responsible party), their compensation department (who will be informed of action items achieved for bonus compensation determination), information systems (that must track individual action items and compensation), and other stakeholder perspectives, to accomplish and validate that outcome. This problem-domain scope provides the drivers necessary to initiate the next OBS model, the Software Project Intent, and begins to delineate and link the project’s software and problem domains, as suggested by Vessey and Glass.⁶

Back to Top

Software Project INTENT (SPI)

For each defined PDB outcome, an SPI model is created to identify the software scope elements required by each of the key stakeholders (Responsible Party, Internal Stakeholders, External Stakeholders, Human Resources, and Management) to accomplish their specified problem domain scope. The SPI model will provide a systems-oriented description of capability rather than a list of software artifacts such as user interfaces, classes, and algorithms.

The left pane of Figure 3 illustrates the breadth of software scope elements necessary to accomplish the MM-MBO outcome Employee Plan is Executed and its measurement counterpart. The SPI ensures that the resulting MM-MBO software project scope includes scope elements required for employee plan measurement, shifts in employee work practices, as well as any changes affecting stakeholders such as human resources (process training) and management (action item progress reporting) among others. Each stakeholder perspective thus becomes a separate software project driver that can be tracked and measured against.

Table 3 describes the software scope elements required by each MM-MBO stakeholder perspective to accomplish the planning project’s Employee Plan Is Executed outcome that are defined in the SPI. For example, to enable the required work practice changes, the software should notify employees when action items should be updated. To enable plan measurement, the software should allow employees to mark their action items as achieved, not achieved, or partially achieved. This table also shows the required resource estimates that will eventually result from the SPB, which is described in the next section.

The SPI model provides an invaluable traceability tool, from a desired result within the problem domain (in the PDI model), to the stakeholder-specific changes in the problem domain (represented by the PDB) and the software domain (represented by the SPI) required to accomplish the result. The Software Project Blueprint (SPB), the final step in the OBS model, then maps these required software scope elements to the resources required to deliver them.

Back to Top

Software Project Blueprint (SPB)

For each defined SPI (in the MM-MBO project for example, Employee Plan Software Scope Elements are Implemented and its measurement counterpart), an SPB model identifies what is needed from each key stakeholder to accomplish and measure that software scope element. Within this SPB, the resources needed to achieve and measure the specified software scope element are identified from the:

• Responsible Organization perspective, which is the Software Project Team assigned to deliver the agreed capabilities.
• Internal and External Organizations and Systems perspective, which include:

• Internal Organizations and Systems— internal systems that the new software must interface with and internal organizations that will play a key project role, such as: the user community, database administrators, architecture teams, and infrastructure support teams. These interaction and interface requirements are incorporated into the work breakdown structure.
• External Organizations and Systems— external systems that the new software must interface with and external organizations that will play a key project role, such as: external users or contractors. These interaction and interface requirements are incorporated into the work breakdown structure.

Human Resources perspective, which identifies the required staffing, skills, and training for the project team.

Management perspective, which identifies the culture, leadership, motivation, and teamwork characteristics needed for the project.

IT Infrastructure, the hardware and software tools needed to deliver the project.

The SPB completes the final component of the full software project scope: the resources required to deliver the software scope elements that will accomplish the problem-domain outcomes originally specified in the first PDI model.

Back to Top

Software Project Scope Statement

After the four OBS models are completed, project leaders understand both the problem and software domain scope required to meet project objectives. Collectively, the OBS models map from the desired results within the problem domain (in the PDI model), to the problem-domain stakeholder resources (represented by the PDB), to the software scope elements (represented by the SPI) required to accomplish the result. The Software Project Blueprint (SPB), the final step in the OBS scoping model, then maps these required software scope elements to the resources required to deliver them.

The OBS approach serves to identify potential conflicting objectives that otherwise may remain hidden. Initial OBS scoping models may have more than one PDI hierarchy representing multiple high-level outcomes that may be in conflict. The PDB stakeholder perspectives may also identify conflicting or sub-optimal stakeholder needs. SPI scope elements may contain sub-optimal choices and the SPB may identify conflicting resource utilization or tasking.

The OBS models are reviewed by project leadership both incrementally during development and upon completion in order to eliminate conflicts, ensure validity, and negotiate the final scope of the software project. Resource constraints may dictate an incremental or prioritized delivery approach, as shown in the right pane of Figure 3. Using the OBS approach, MM-MBO project leaders broke the project into multiple releases, with each release addressing a subset of stakeholder perspectives.

Back to Top

Postmortem

An MM-MBO project postmortem established the impacts and perceived benefits of the Outcome-Based Scoping (OBS) model. Prior to applying the OBS model, the stated project intent was to reduce the hours required to create, update, approve, measure, and compensate for employee objectives. These employee-level objectives were to be aligned with department plans that in turn aligned with the firm’s annual plan, but these broader alignments were not in scope. No validation was performed to ensure that the employee-level focus would deliver the most value, or that employee-level automation was the only issue that should be in scope.

According to project leaders, use of the OBS model broadened their perspective to a strategic view, directed them to create a phased release plan, and provided a clear path to achieving the annual plan objectives. Specifically, the postmortem identified five key differences in the project, attributed by project leaders to the use of the OBS model.

1. Identified a previously-incomplete Executive Sponsor intent

• The OBS model identified five additional desired planning outcomes that were not included in the initial executive sponsor definition, but deemed critical by project leaders once recognized.
• The OBS model identified measurement goals for the outcomes that were not identified in the initial definition.

Identified, traced, and integrated business needs for all stakeholders that were not defined using the original approach.

• The OBS model identified and integrated diverse stakeholder perspectives within a consistent business outcome architecture during the project scoping phase, allowing project leadership to recognize the importance of several previously ignored stakeholders.
• The OBS model identified need for stakeholder training, deemed critical to project success once recognized.
• The OBS model identified a phased delivery of business capabilities based on stakeholder needs, deemed valuable by project leaders.

Identified distinct system scope elements linked to the business needs.

• The OBS model identified distinct system scope elements which were originally co-mingled with problem domain needs prior to use of the OBS approach. This allowed project leaders to place responsibility for software scope elements and problem domain needs with the most capable manager.
• The OBS model identified a more complete software scope than was available using the original approach.

Prioritized and defined project releases to permit a phased implementation of business strategy.

• Project leaders concluded that the OBS-driven release definition ensured that each release provided significant stakeholder value with “clean release boundaries.”
• The OBS model provided project leaders with a more complete understanding of the interactions and dependencies between the planning and software domains.

Improved project estimation

• The OBS model identified system scope elements early enough in the project to permit a more accurate estimation of project duration, effort, and cost.
• Despite the project’s revised scope being significantly larger than the one originally proposed by the executive sponsor, the project was delivered on time and within budget.

Back to Top

Conclusion

MM-MBO project leaders examined the likely project results absent the OBS model re-scoping, concluding that one of the following would have occurred:

• The project would have been delivered as originally requested, but would have failed to deliver the intended value.
• The project scope would have expanded during the course of the project and delivered the intended value at the expense of schedule, budget, and resource estimates.
• The project would have been identified as a runaway project and either cancelled or stopped for restructuring before completion.

The benefits to MM of the OBS scoping approach were sizable as illustrated in this case study. The explicit link from the software project scope to the problem domain provides a more holistic view and critical problem domain trace-ability. The explicit link from the project scope to problem-domain based assessment metrics provides value accountability. Future research will explore how the OBS model can be seamlessly integrated into software development frameworks and commercially available software development and project management methodologies.

Back to Top

Back to Top

Back to Top

Back to Top

Back to Top

Back to top