Why Projects Succeed: Minimize Scope and Requirements
By Roger Kastner
Whether measured by schedule and budget, scope attainment, stakeholder expectation management, end user adoption, or market success, leading a project to a successful conclusion is challenging. What might be surprising to know is sometimes the challenges are self-inflicted, and one of the leading causes of self-inflicted project failure is attempting to do too much.
The Standish Group, a technology research and consulting firm, studies IT projects and annually produces their “chaos” report which includes statistics on rates of project success, as defined as being on-time and on-budget. In 2009, the Standish Group found that 32% of the IT projects they surveyed were “successful” as defined by on-time and on-scope. Additionally, since some projects successfully hit their on-budget and on-schedule targets but fail to hit the mark with consumers or are not adopted by end-users, the Standish Group might have these in the win/success column however they will never be called a success by stakeholders because they did not deliver on ROI. With this second category of projects there is probably an even smaller number of projects that meet stakeholder expectations which I argue is the true measure of project success in a previous article Articulating the Value of Project Management.
All projects are attempts to resolve a problem for a target audience, and too often, projects attempt to resolve all symptoms of that problem, and therefore the scope for the project is needlessly too large.
In attempting to solve a problem for a target audience, teams can become overzealous in addressing all the symptoms of the problem, or attempt to go beyond what is necessary to solve the problem (aka gold plating). The Standish Group can shed some light on this practice of projects building too much. A 2002 Standish Group study on Feature Usage on Typical Software Packages (e.g., the Print function in Microsoft Excel would be a “feature”) quantifies this self-inflicted problem. They found that 64% of features are rarely or never used, and only 7% of features being “always” used and 13% being “often” used. Hmm, the majority of the value is derived from 20% of the work; that sounds familiar right?
Now, I recognize that not all “rarely” or “never” used features are “non-value add” features. When I bought my last car, I placed value on the six airbags and the reinforced cage surrounding the passenger compartment, but I sure hope that I “never” use them, and if I do, than I will probably only use them once (i.e., “rarely”). That all said, the Concatenate feature in MS Excel is not the equivalent of saving me from imprinting my facial features on my dashboard, and nobody is paying extra for MS Excel because of that feature. When I refer to the “64% of features,” I realize that this is a generalization and that there are exceptions, but there’s still a significant amount of features being produced on our projects that do not add value.
So, if 64% of the features we’re building add zero value for our end users, and since every feature and requirement adds cost, time, complexity, and risk for the project with no measureable benefits, it is simply crazy to accept those 64% of features into scope, right?
To resolve this, the successful Project Manager must simply ask the stakeholders to identify the 64% of requirements that add zero value to the product and then remove them. (HA!)
OK, so the solution is not that easy. I’m sure every one of those features in the 64% category seemed like a great idea to someone on those teams. So how do we identify those zero-value features?
By asking the right questions.
“Entities must not be multiplied beyond necessity.” –Father William of Occam
The concept of the 64% zero-value features and the inherent costs, complexities, and risks should lead the successful Project Manager to a logical extension of the claim in Occam’s Razor that “simpler [solutions] are, other things being equal, generally better than more complex ones,” or to go with the more colloquial “less is more” approach during requirements gathering.
The best way to identify that ‘simpler solution’ is to first ask what is the minimum amount of scope required to produce the desired result, and second, be ruthless in the pursuit of minimizing scope and requirements on the project. The tie does not go to the runner: if you cannot prove the feature is necessary in order to attain an acceptable positive return on investment, then that requirement goes into a lower prioritization category and is not committed to or delivered in the first release.
“Do we have everything we need?”
How many times have you heard the “Do we have everything we need?” question while gathering project requirements? Be honest, how many times have you even asked this question? This is the equivalent of the “Wafer thin mint?” question posed in Monty Python’s The Meaning of Life. It’s the invitation to having the project ‘explode’ later down the road when the confluence of too many requirements and the exponential impact of costs, time, complexity and risks all contributes to missed expectations. It also invariably produces the wise hindsight that comes up in the post-launch Lessons Learned session of “maybe we attempted to do too much.”
Instead of asking “Do we have everything we need?” the successful Project Manager will ask a similar question, with a much different result.
Q: How do you eat an elephant?
A: One bite at a time.
Back in the internet bubble version 1.0 days, I was managing a project team that, after a 50% reduction in force, was struggling with how to accomplish everything in our plans with only half the people now in the room. We had identified all the reasons why it was impossible to accomplish all of the in-scope requirements, but as part of a scrappy start-up, and one that just showed half the employees the door, we didn’t want to disappoint our sponsor. When we presented our challenge and misguided options for getting all the work done to our sponsor, she laughed and said, “Of course you can’t get all this done. I mean, hey, you do know how to eat an elephant, right?”
The sponsor then went on to explain that by attempting to “bite off more than we can chew,” we were doomed for failure. Instead, she said, “let’s roll up our sleeves and determine what are the minimal amount of features we need for a marketable product.” She then introduced another concept I still employ today:
“The question we need to ask is ‘do we need everything we have?’ not ‘do we have everything we need?’”
Simple, beautiful, and spot on. We then spent the next couple of hours crafting and debating the right feature list and the new requirements for our product. We didn’t know about the Standish Group study highlighting that 64% of features were zero-value add, but it was clear that our sponsor intuitively knew and embraced the concept. She knew that every requirement can exponentially increase the amount of complexity, risks, time, and costs to a project and if the requirement does not have the same level of impact on value (i.e., Return on Investment), then the team should attempt to defer it to a later release.
Two months later, our first release nailed our acceptance criteria for launch and was customer ready. We had built a solid product that met all requirements we hit our schedule and budget, and exceeded our stakeholders’ expectations.
Agile Methodology Embraces the Simpler Solution
Although I’ve never actually heard anyone else argue this, from my experience the delivery of a “simpler solution” is one of the primary benefits of the Agile Methodology. Rather than the All-You-Can-Eat approach witnessed in projects that follow the Waterfall Methodology, an Agile project will start with the “bare necessities” feature list and incrementally build a shippable product. In doing so, it is more likely for a Product Owner to say “this is good enough to give to customers” even when there are many more requirements and features yet to be built.
The Agile experience contrasts with a Waterfall project where Product Owners are more likely to stuff more features and requirements into the requirements because 1) they may perceive it will be a long time before the end users see the final product, and 2) cost and time are the key (only?) forcing-functions for limiting scope and requirements, but those are constraints and not a mentality that embraces the “simpler solution.” Waterfall is much more a top-down model whereas Agile builds from the bottom-up and will produce that discernible ‘simpler solution’ and bare minimum feature set sooner.
I have always taken this “path of least resistance” approach to work and intentionally chosen to do the least amount of work in order to attain the desired objectives and not it’s not because I’m lazy. It’s because I’ve seen that each additional piece of scope seemingly adds complexity and risk exponentially and definitely adds time and cost without having clear benefits. With the time and energy I save by forcing the “simpler solution,” I now have more bandwidth to prepare for the inevitable unknown-unknown that I know from experience will be knocking my project sideways soon.
If you have ever packed the car for a road trip with kids, the “do we need everything we have?” question should be very familiar. The road trip is a great analogy for minimizing scope and requirements, because of the fixed constraints between size of space and the goal of having satisfied stakeholders (or a desire to avoid unhappy stakeholders). And just as with explaining to a 4 year old why you can’t bring his 4-foot tall stuffed animal along for the trip, the conversation with sponsors and stakeholders might be a little surreal at times. But the successful Project Manager will know that driving toward a “simpler solution” will more likely contribute to success than an “all abroad” approach. And yes, the promise of ice cream can work well in both cases.
Reprinted with permission from Slalom Consulting - © 2012 Slalom Consulting
Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.