Threshold of Success

When I was a kid, my brother and I played a game called Make Believe. My favorite variant of the game involved building some kind of fortress that one person would defend while the other invaded. In theory, the game ends when the fort has been overtaken by the invader. What made the game fun was that the rules of the game always changed.  Once one of us was "killed" in battle we'd invent respawning.  Next came invincibility. Before long, someone becomes invisible. Sometimes someone gained super strength or super speed. We almost always created super weapons (such as a handheld Death Star or a slow motion laser).  Nearly every game ended in tragedy, someone crying or upset: "That's not fair! You can't do that! I'm invisible! You can't do that!"

Kid's stuff right?

A lot of software projects with teams made up of working adults still play this game. The scenario goes something like this. A team is put together to build some software. Neither the clients nor the team talk about the objectives of the project other than building "some software." After a few months, something goes wrong or someone doesn't like what's happening the rules get changed. Before long, one side or the other is upset that they can't win, somebody throws a fit, and goes home. Instead of summoning invisible armor, software projects change the rules by cutting features, adding requirements, moving due dates, wasting resources, and things like that.

We make believe that we're software engineers.

Make Believe was a fun game as a kid. Changing the rules when real money is on the line isn't as fun. My brother and I ran into problems as kids because we got the objectives of the game wrong. Actually, there were no common objects, which is why we could change the rules so easily. The same thing happens on a software project when the objectives aren't well known.

Defining and committing to a clear picture of success establishes the common ground rules for a project by making the basic project goals explicit. The technique is known as Threshold of Success.

Defining What Success Looks Like

The Threshold of Success for a project is the minimum set of conditions that must be met for the project to be considered successful. If the team fails to meet even one of the conditions then the project is a failure. A good Threshold of Success is made up of about 3-4 SMART goals (no more than a few bullets on a single PowerPoint slide). SMART is a mnemonic which stands for Short/Specific, Measurable, Achievable, Relevant, and Time bound.

Some other pointers for defining a Threshold of Success:
  • The Threshold of Success should be built as a team. Since this is the measure by which you will define success or failure, everyone on the team must buy into it. If you can include your client that's even better.
  • Threshold of Success goals should be challenging, but it's important that they are achievable. If the goals are too easy, victory will be meaningless, too difficult, elusive.
  • Once the Threshold is established, don't change it! The only reason to modify the Threshold of Success is if the project has changed so drastically that the Threshold no longer makes sense (for example if someone leaves the project).
  • Revisit the Threshold of Success regularly (a good time is when planning iterations) so everyone remembers what success looks like. Put it on your team wiki so that it's readily accessible.
  • Be sure that the goals in your Threshold are SMART! The point of defining a Threshold of Success is to take away the wiggle room for defining what it means to succeed or fail. The goals you define should make this black and white. The more specific the goal is the better.
Building a Threshold of Success

The easiest way to create a Threshold of Success is to first create a minimum picture of failure, then convert failure into success. Here's an example:

Failure for my current project might look something like this.
  • Essential features are not ready by the end of the second quarter.
  • Team members are dissatisfied or bored with their jobs.
  • Newly hired team members don't feel like they're part of the team by March 31.
  • There isn't enough money to continue development after this fiscal year and we have to fire people.
Now that I know what failure looks like, seeing success is easy. I don't want any of these things to happen. The threshold of success for my current project might look something like this.
  • By the end of the second quarter, all "Must Have" features are implemented and pass acceptance tests with no known critical defects.
  • All team members give average score of 5 or better on a job satisfaction survey taken quarterly.
  • By March 31, the team has successfully executed at least three team building activities with all team members present.
  • Funds of at least $1 million are secured by December 31 to allow for future development without a reduction in team size.
Notice that only 1/4 of the success goals in this example are related to software functionality. While goals might come from anywhere, teams traditionally focus on goals related to people and relationships, process, resources (such as budget or schedule), and product (software functionality and quality).

As this technique originated with the Software Engineering Institute (pdf), nearly every studio team in the Carnegie Mellon Master of Software Engineering program creates a Threshold of Success for their projects. The MSE Studio Archive has extensive examples of both good and bad pictures of success that teams have created. The Square Root Team's threshold (my team) is a good place to start, but there are plenty of other examples.

There might be many goals for a project. In the Team Software Process you actually identify at least three different kinds! But there is only one threshold of success for a project. Knowing what success looks like gives you a better chance of actually achieving it.  Without it, you're just pretending that you know what's really important.


Popular posts from this blog

Dealing with Constraints in Software Architecture Design

If you aren't Agile… Then what are you?

Managing Multiple Ruby Versions with uru on Windows