In my experience, most scope creep in enterprise software projects manifests as “feature-itis.” This is the demand for some custom feature to be added to packaged software, by some stakeholder. In many cases, the requested feature / behavior / report is required by some authority, internal or external, and driven by compliance. These generally (but not always) qualify as “Must haves.” In other cases, closer inspection reveals the request to be a variation of “We’ve always done it this way.” These generally (but not always) end up in the business process re-engineering pile. And in still other cases, it’s a desire for something completely new. The stakeholder wants a capability they are currently living without, because they believe this project is an opportunity to get their wishes fulfilled. When asked why they need this new capability, they speculate about what they could do if they had it. Consequently, I refer to them as “If I had” requirements.
“If I had a boat, I’d go out on the ocean.
And if I had a pony, I’d ride him on my boat.
And we would all together go out on the ocean –
Me upon my pony on my boat.” — Lyle Lovett
Now, don’t get me wrong: there are a lot of good innovations in the “If I had” category. But things haven’t changed much since 2002, when Jim Johnson of The Standish Group noted that only 20% of software features are regularly used, and over 60% of features are rarely or never used. Even today, most of the business value derived from any premises-based software or SaaS implementation comes from the most common or high-value-added use cases. So it benefits the organization to focus scarce resources on those high-value cases. That doesn’t mean we should stifle innovation; far from it. We simply need to ensure the selection process is sufficiently rigorous. And one the best tools for driving that rigor is enforcing the use of user stories, so common in Agile methodologies.
“As a <role>, I want <goal/desire> so that <benefit>”
Re-structuring the requirement as a user story forces a more specific articulation. It also makes the proposal less about the person proposing the change than about a role. This allows the proposed requirement to be better (and less emotionally) evaluated for business value.
- Articulating the role helps drive the conversation about who benefits. Will the beneficiaries be the people who will bear the incremental cost and risk? If not, are their interests important to overall success? I remember writing a massive audit report for one project that was run once and never used again, since the stakeholder left the organization and no one else cared.
- Articulating the goal or desire helps drive the conversation about how to achieve it and keep it in operation. The cost of delivering and maintaining the new capability is largely a function of the solution chosen.
- Articulating the benefit drives the conversation about the business value that will be derived from this proposal. Saving ten hours a week is significant, but at what labor cost? If accuracy will be improved, what cost savings will be realized?
As practicing IT project managers, we want to guide our project stakeholders who are practitioners of other arts and sciences to effective solutions. We don’t need to match their level of subject matter knowledge; we simply have to facilitate their ability to articulate their requirements. Of course, I doubt Lyle Lovett could re-phrase his wish for ponies and boats as a user story, and even if he did, I doubt you’d want to sing it. But some desires are better sung about than added to a development backlog.