Why Projects Succeed: Minimize Scope & Requirements

Slalom Consultant Roger Kastner

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

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

Slalom Consulting’s Seattle office Slalom Consulting's Project & Program Management focus
Learn more about our Seattle office Learn more about Slalom Consulting Project Management

subscribe by emailSubscribe to follow new Project Management posts

About Roger Kastner
As a member of the Organizational Effectiveness practice at Slalom Consulting, I'm excited to share my perspectives and experiences with Change and Project Management to help clients and practitioners achieve their goals and objectives.

4 Responses to Why Projects Succeed: Minimize Scope & Requirements

  1. John Fisher says:

    Great article Roger. Came here through your comment on another blog and find your thoughts on the Standish Report very interesting. The idea of asking which of the requirements are part of the 64% is interesting, but how does that work in practice? In many cases I believe people actually think theywill be used, so they will be reluctant to wipe them out. I’m actually working on a project right now where the client and the SI are having lengthy debates on requirements, and I wonder how many of them are really going to be used. The “do we need everything we have?” question is a great one, but it requires strong leadership and determination to actually execute.

    • Roger Kastner says:

      Hi John,

      Glad you liked the article, and thank you for the question. When starting the requirements gathering phase/session, I pull out a pie graph that illustrates the results of the Standish Group’s “Feature Usage on typical software” study:
      — 7% Always Used
      — 13% Frequently Used
      — 16% Sometimes Used
      — 19% Rarely Used
      — 45% Never Used

      (Note: 20% of the features are Always or Frequently Used, thank you, Pareto.)

      …and then I give the usual caveats:
      — I explain that while the air bags in my car are in the 45% category, they do hold value for me and I’m willing to pay more to have 6 of them in my car and I never plan to use them.
      — Few MS Excel users know about the Concatenate feature but those who do probably “LOVE” that feature

      …combine this study with the Standish Group benchmark study on project success factors (roughly 30% of projects are successful, 40% are challenges, 30% outright failures), building too much stuff puts you at greater odds of not hitting the 30% golden circle of success.

      The lesson of the study and my purpose for sharing it is, after reviewing thousands of examples, teams attempt to build too much stuff. Our goal is to determine what is the bare-minimum, critical, priority 0 features necessary to having a valueable product, and which features are debateable, and then focus on delivering the Pri 0 features in the first release as quickly as possible.

      Here’s are a couple things I would try if my stakeholders were in a logjam, of course, after showing my pie chart:

      1) Ask the End User
      End users are great at being able to describe painpoints and quantify the value of the solution, (however, they are not always so great at identifying requirements for the solution). The litmus test for any requirement or feature is does it contribute to solving the end users’ problem. If not, it gets prioritized lower (I’m always surprised at how many requirements will fall out at this phase).

      2) Force Rank the Features
      Use a weighted scorecard based on the goals and objectives of the project to to force rank the features. Facilitate the stakeholders in creating the weighted-scorecard by asking the stakeholders to participate in defining the weights, and once defined and agreed to, then ask them to independently score each requirement. At the end of the scoring process, a ranking will emerge.

      3) Prototype Options
      Once the features are ranked and shades of grey emerge between version 1.0 and beyond, then prototype a couple solutions and ask a small number of end users to comment. Jakob Nielsen, the UI and Web guru, once wrote that while large sample-sized usability studies are great for academics, he got the same value from asking 5 people for their opinions then sampling a 1,000.

      4) ROI Calculations
      Using ROM estimates, you can quickly identify value difference between your options, and when combined with schedule and risk esitmates, the simpler solution will usually stand out as being more attractive.

      Using an iterative development methodology like Agile allows you to build and deploy faster and thus allows you to test which features continue to move the value needle for customers. And, in my experience, using the Waterfall methodology caters to this “but wait, there’s more” mentality of packing in as much as possible, usually because there never is funding for version 2.0.

      I hope this has been helpful. I appreciate the opportunity to respond to the question. Good luck and let me know how it works out for you!


  2. Pingback: Why Projects Succeed: Organizational Change Management « The Slalom Blog

  3. Pingback: Change Is Good: Keep It Super Simple | The Slalom Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: