Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

Project Managers: Don’t List Assumptions, Test Them

April 5th, 2007 · 2 Comments

If you take any sort of PMBOK-based project management training, one of the things you will learn is how to create a list of assumptions and then identify the bad stuff that could happen if the assumptions turn out to be wrong. I’ve observed a couple of things about assumptions I’d like to share.

Don’t Use “Boiler-Plate” Assumptions
I’ve seen it a million times. The project manager is expected to have an assumptions list, and it’s expected to have some content. So, a lot of project managers re-use assumptions from project to project. Let me give you an example or two:

  • Development team resources will be available as needed by the project plan
  • Business sponsor support for this project will continue through the duration of the project
  • Enterprise level technology strategies for relevant technologies will not change the technological direction of this project
  • Don’t reuse assumptions. These assumptions might be good in a particular context, but the minute you start reusing the same assumptions over and over they lose all relevance and value.

    Assumption Lists, in and of Themselves, Are Not Valuable
    There’s nothing intrinsically useful about assumption lists, even when the assumptions are carefully worded and totally relevant to the success of the project. Don’t believe me? Try selling one on eBay. Okay, some sicko might buy it, so forget about it. Instead, think about a project you’ve been on that was cancelled. Then imagine yourself going up to the disappointed project sponsor and consoling him or her with these words: “Boy, I’m just glad we got this assumptions list finished. You’ll want to hang on to this.” If you can imagine this scene and it doesn’t result in your business sponsor vomiting, punching, flipping you off, etc, maybe I’m wrong.

    The Only Good Assumption is A Dead Assumption
    A dead assumption is one that has been tested and confirmed right or wrong. Project teams should not be satisfied to simply list assumptions and identify the damage they can do if they turn out to be wrong. Assumptions should be tested as soon as possible. Every assumption should turn into an action plan – testing the assumption should be an assigned task.

    You Can Test Assumptions Without Creating “the List”
    I like project tools that are easy to manage. Having a list for risks, a list for issues, a list for assumptions, a list for bugs, a list for tasks, etc. makes me crazy. I don’t need all that stuff to build working software. So let me tell you how I deal with assumptions.

    As soon as someone identifies an assumption (which is really just a fancy word for a question), I add an item to my sprint or product backlog. Let’s take the first assumption I listed in the opening of this post, that the development team will be full-time on my project. I create a task in my sprint backlog, something like this: “Work with the resource managers to get a full-time development team.” Then, I start doing my thing, finding out what I have to do to get full-time help. If I need to bring in contractors, do something to free up people’s time (like take other activities off their plate), I do it. Trying to get full-time help tests my assumption that I’ll be able to, and right away I start to find out whether I can pull it off or not.

    In this particular case, I’ll probably have to re-test my assumption periodically throughout the project. It isn’t always this way though. Some assumptions are one and done, like “MQ Series will work in our technology stack.” Test it once, assumption closed.

    Just Plan
    Sometimes creating semantic frameworks for concepts makes life easier. For instance, the classification system of elements is incredibly powerful and makes the interaction of chemicals easier to understand. So does the classification of words as verbs, nouns, participles, etc. It isn’t always true though – there is a point at which defining activities in a particular way simply creates overhead that muddies the process and makes life more difficult.

    I believe the concepts of assumptions, risks, and issues fall solidly into this category. When someone says “what if MQ series doesn’t work in our environment, then what will we do?”, it doesn’t really add any value to say: “Gee, you just identified an assumption we’ll have to make” (if you decide it’s an assumption – the same is true whether you see it as a risk or issue). It doesn’t matter what it is. The only thing that matters is that you plan some way of figuring it out.

    So, here’s my last lesson. Don’t waste your time with assumptions, risks, and issues. Just plan your project, a little bit every day. Spend the bulk of your time executing your project, and know what could cause problems. Then fix those things. That’s what you need to do.

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Uncategorized

    2 responses so far ↓

    • 1 » Project Managers: Don’t List Assumptions, Test Them // Apr 6, 2007 at 1:25 pm

      […] gio wrote an interesting post today onHere’s a quick excerptDevelopment team resources will be available as needed by the project plan; Business sponsor support for this project will continue through the duration of the project; Enterprise level technology strategies for relevant technologies … […]

    • 2 Wayne M. // May 2, 2007 at 12:58 pm

      Some of the best advice I ever got was to turn every assumption into a risk. Assumptions are great at the proposal level because then you can concentrate on the highest probability approach. When the project gets underway, however, turn all of those assumptions around into the risk that the assumption is not met. Then all assumptions can be handled with your current risk management approach.

    Leave a Comment