Risks vs. Assumptions

I like working with knowledgeable people.  I learn a lot from them, and then I enjoy passing it along to other people.  This month I learned something profound that I should’ve already known.  I guess it just had to be put into the right words.

Last month, I was asked to put together an estimate for a project.  I used Function Point analysis to give me some accurate numbers.  Afterwards, I was asked why these numbers would work.  Why not larger or maybe smaller numbers?  I had to think about it for a minute.  I realized that my estimates were strongly based on a few important factors.

  1. I will be using the dev tools that I already know
  2. I will be using a process that I know and trust
  3. The team will be comprised of an average spectrum of skilled team members (some mid, senior and junior, but not all junior)
  4. The expectations of management will be reasonable (by my standards)
  5. There will be a moderate level of paperwork and bureaucracy (but nothing excessive and stifling, by typical industry standards)
  6. There will be a reasonable level of testing (not NASA level, for example)

Gosh, if any of these were off just a bit, it would affect the timeline.  If any of these assumptions were way-off, then the whole timeline goes out of the window.  These are some pretty big assumptions on my part.  I realized that I better write them down and attach them to my estimate.

My PM looked at my write-up of assumptions.  He held his chin for a moment and then told me that there is a better way.  I guess the word “assumptions”, is not very likeable.  I guess it sounds a little wishy-washy.  We needed a stronger word.  Something that would convey a clear message about the risk of messing with my process.

The Right Message

The best way to represent these pre-requisites, was to identify them as “risks”.  Every manager is aware of risks, and is required to monitor and mitigate them.  Honestly, if somebody significantly altered any of the dev processes, it would pose a significant risk to the timeline.  Clearly, we can’t allow people to violate the risks within the project without repercussions.  Bingo!

All of these years, I have been using the wrong terms.  To some degree, I have not been accurately identifying what is a horse and what is a cart, and then putting the right one before the other.

Before you start estimating your timeline for a project, be sure to pin-down all of the “risks” (and assumptions) that would kill your estimates.  Put those as a cover-page, before your estimate formulas and numbers.  Your estimation accuracy will be so much easier to gauge, once you manage these “risks” better!

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Methodology and tagged , , , , , , . Bookmark the permalink.

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s