Looking Back

Keep on-scope.

When I recently asked a selection of readers and listeners of the Software Process and Measurement podcast and blog what they perceived as the single most important attribute that determines project success. Everyone that answered had and expressed an opinion on the topic. In order to focus those opinions, I constrained the respondents by asking them to choose from between the classic on-budget, on-scope and on-schedule triangle. In Project Success: An Overview went through the results at a high-level, and on-scope was clear, but strenuously argued second place finisher (far ahead of on-budget). Respondents rationalized the importance of being on on-scope as a connecting/satisfying their customers and as an attribute they had influence over given their span of control.

One respondent stated the augment for on-scope in a very straightforward manner, “I try to remind myself that the business requirements are most important, even if it results in a less-than-technically elegant solution.” The value of any project is tied closely to functionality being delivered. In a similar vein, another respondent suggested that cutting scope hurts the people that need to use the system (paraphrased). If the software or the interface between users of all types does not address the need of the business, it has little value. Scope, whether documented as requirements or user stories, represents a common understanding between customer and developer.

As projects evolve, the scope changes, whether through the adding stories and reprioritization of the project backlog or via change requests in classic project management methods. The processes of accepting change and determining how that change is implemented is usually a negotiation between the team and stakeholders. One of the respondents put it succinctly: “a clear definition of scope and a transparent understanding between our business customers and IT is what makes a project successful.” Involvement in the discussion of what is in scope and how the implicit business discussion is required for transparency and confers importance to the on-scope attribute. If we compare the perceived level of importance of on-scope to on-budget we see the impact of involvement. Budgets are set typically from outside the team’s span of control and act as a constraint for the project team, therefore practitioners see the attribute of on-budget as less important than on-scope.

One response suggested that being on-scope infers meeting functional and performance requirements. While this might not be exactly true, in the hard light of a project the connection between scope and requirements establishes a link between the development team and their customers. The linkage between the team and the customer’s needs makes the relationship between the two groups more intimate and provides the team with motivation therefore the perceived importance of the on-scope attribute.