Strategies for Successful Development

Process and technology for small teams building real software

Archive for July, 2009

The No-Spec Spec: Assumptions

Posted by S4SD (Seth Morris) on 2009/07/05

This is part 5 in the series The No-Spec Spec

Most likely, the first time you write an Assumptions piece, it will seem easy. The second time, it will seem very hard. And the first time you have to apply it, it will take courage and make a lot of people angry.

It’s worth it. Especially the making people angry.

The Assumptions document is a place to write down what should make you rethink the project: what things outside of the project could change the requirements, change the deadlines, or even suggest cancelling the project. You want to start this list early, before you are in the day-to-day give-and-take that makes everything seem more—or less—fluid than it really is.

Assumptions come in a variety of categories, but they all represent something that has to stay true for the project to proceed as planned. For each assumption, identify what will be affected and what process or work is invalidated if the assumption proves false1.

Common areas of assumptions:

  • Technology
    • The 3rd party dependencies are available on time
    • The 3rd party dependencies work as planned
    • Internal dependencies (libraries, hardware design, etc.) are available and work
    • New versions of tools and libraries integrate smoothly
  • Team
    • The team can focus on the new project as planned (rather than being pulled onto other work)
    • Key personnel remain available
    • New hires can be filled on schedule
    • Outside contractors perform as expected
  • Corporate
    • The corporate structure continues to support the project
    • Necessary resources are available to support the project (no emergency or suddenly-critical project consumes all IT support or asset creation, for example)
  • Business
    • Competitors behave as expected (with respect to the project)
    • Business partners remain committed (and in business)
    • No unexpected developments that affect the project (e.g., new entries into the project space)
    • The regulatory environment remains as expected
    • Company legal issues (patent claims, etc.) resolve as (and when) expected

When you write your assumption list, don’t be general. Don’t say "3rd party tools work as expected." List them, list when and where you expect to apply them, and list what they impact. When they’re written most usefully, assumptions are digital: they are either true or not. Don’t accept "well, it’s mostly true, so we don’t have to consider changes." Down that road lies failure.

An assumption comprises:

  1. A statement about the project’s environment that you can test as true or not
  2. A list of disciplines that should re-evaluate the project and what they need to re-evaluate. This can be as complete as "is this still the right project to do."

Here are some examples:

Assumption If this Assumption changes, re-evaluate these:
Congress will authorize <specific regulatory change expected>2 – Legal: List of likely implications
– Sales: Begin managing customer expectations and bring the results back to Business
– Business: re-evaluate if the project is still viable
– Product: review and sign off on the entire functional requirement
Ad sales will be remain our main source of revenue – Product: re-evaluate the design
– Business: re-evaluate if the project still makes business sense
Hardware development and production will occur on-schedule – Product: Features dependent on the hardware
– Sales: Commitments and schedules
– Product: Relative priority and urgency of other projects
Legal issues with design <whatever> will resolve by the time we ship – Legal: Advisability of shipping while in litigation
– Product: Can features based on that design be removed?
– Development: Other designs
– Business: Schedule vs. Features vs. Risk
Existing codebase supports the features with minimal maintenance – Development: Estimates
– Development: Maintain or rewrite
– Product: Schedule
– Business: Importance of new features
Products in production continue to function with minimal intervention …etc.
…etc.  

It is important to note: "re-evaluate" is not the same as "check that what we said is still valid." Looking at the old plans and seeing if they can be made to work is how projects spiral slowly into failure, always chasing one more fix to react to the world. Re-evaluate is just that. Look at the product, the project, and the business goals and decide what is needed; then compare that to existing plans. The whole point of the term "assumption" is that it indicates a surprise. Whatever you did before could not have been based on the current conditions.

An assumptions list is very much like a risk list. It is similar, but neither completely replaces the other. The risk list identifies things that might happen to affect a project and lists amelioration plans; it focuses on the things you most want to prepare for—the things you most expect and which you can tweak back under control. A risk list is an attempt to create a proactive situation; assumptions stay reactive. The assumptions list calls out things you do not expect to surprise you. These are generally things you cannot control. You put something on a risk list to make sure you pay attention to it. An assumption is something you don’t pay attention to every day, but when it calls for your attention you have to respond fully.

  Risk Assumption

Changes:  

Often Occasionally, maybe never

Respond With:   

Small changes Complete re-evaluation

Control:   

Internal External

Scope:   

Usually smaller Usually larger

When one of the assumptions changes, you don’t expect to make a subtle change. You get people together, demonstrate what’s happened, and ask, "From the current plan, what is now wrong? Not how to fix it, but what needs to be replaced?" You can work out a new plan when you know if the project is still worth doing.

So what do you gain? Clearly, most assumptions wouldn’t go unnoticed during a project (although some do). The assumption list gives two direct benefits and one powerful indirect one.

  1. It serves as a commitment to respond fully when circumstances change. Because many assumptions are large and pervasive, it is common to try and keep moving while reacting. The team keeps working on something they know isn’t right and the project drifts while plans are half-made and tried on top of each other. Often, no one wants to call something broken and recommit4. The assumption list provides a visible, binary test for when to withdraw and re-evaluate.
  2. It reminds the team that the whole project is affected. It is very easy for one discipline to believe that a problem doesn’t affect them5. Often, a faulty assumption isn’t fully visible to every discipline, and it’s as easy for the discipline most directly affected to overlook it as it is for a discipline very remote to the assumption. Pulling out the assumptions list and showing someone how many groups are affected and how significant an impact is can help you get people to give up a problem to the group or to agree to devote their time to a situation they didn’t think was important.

    …and…

  3. Thinking about assumptions makes for writing better requirements, designs, and code.

1. This is where the dependencies between the elements of the No-Spec Spec can help you, if you’re using all the parts. Often an assumption supports one piece of the process: the behavior, the mission, etc. If that needs to change, it’s relatively easy to see what other pieces are affected.

2. I worked for E-Stamp back in ’99. Being in a business where business plans (and technical plans that follow) are dependent on congressional action is incredibly difficult.  My heart goes out to those who try and my hat goes off to those who succeed3.

3. Obviously, E-Stamp didn’t succeed.

4. Engineering is usually the last to admit that something isn’t worth fixing. Consider a broken third-party tool or library. Most engineering groups will muddle along with it for months, causing delays and introducing quality risk, rather than announce that they won’t make it work and choose another route. Doing so turns a technical problem into one affecting every part of the project, but the problems often creep up in small increments and engineers never like to throw out something they might be able to fix.

5. Again, it’s as common for Marketing to decide to ignore a problem as being "Engineering’s responsibility" as it is for Engineering to try and convince Marketing to do so. I’m amazed at how often major problems in development groups are overlooked because non-technical people saw it first.


Listening to: Herb Alpert & the Tijuana Brass – Classics, Vol. 1 – The Lonely Bull

 

Advertisements

Posted in Dev Process | Leave a Comment »