Archives from month » January, 2010

Guest Blogger on Project Management

Guest Blogger – Rick Wyatt

This is the first part of an 8-part series which looks at how IT and Business Leaders and Stakeholders can avoid common project pitfalls.

The first date you hear is not “the date”

How many times have you been in meetings where the Business has asked IT to deliver a project of some sort and the question is casually posed to IT, “So, when do you think you can get this done?”  At that point, the best thing you could do would be to plug your ears and not hear their answer.  Why?  Because anything they say at that point in a project lifecycle is just an unqualified best guess.  But what happens time after time is the whole room hears IT say they think they might be able to deliver the project by around a certain date, and from that moment forward, everyone thinks that’s “the date”, and nothing could be further from the truth.

Let’s look at the reality of this situation.  At conception, a project is simply an idea – pure vapor.  Here are some of the components of project initiation and planning that will need to be fleshed out to move that idea from vapor to reality:

  • Documented, detailed requirements.  Everyone, the Sponsor, project team and the project stakeholders, need to understand and agree upon what is to be delivered.  This establishes the scope and drives the understanding and creation of the tasks needed to turn vapor into a tangible, expected outcome.  Until this is done, we don’t know what we’re being asked to deliver, so how can we provide more than a ball-park estimate for delivery?
  • Priority.  How important is this piece of work?  On one hand, if this is the most important thing to company profit or growth, it might need at the top of the project list and take precedence over all other discretionary work.  On the other hand, if it’s a nice-to-have item, it might be low on the list and would need to compete for resources with the other less critical projects.  At one end of the spectrum, the project could have a dedicated team and executive help clearing roadblocks, and at the other end, the project could be delayed by higher priority projects that consume the resources and cause your project work to be sporadic.
  • Capacity.  How much discretionary work can IT successfully take on?  What skill sets are needed for your project tasks and when will those resources be available?  You can create a beautiful project plan with all the tasks and dependencies well thought out and documented, but until you have a good understanding of the specific resource that will perform each of those tasks and when they’ll be available to do so, how can expected task completion dates be determined?  And don’t forget the biggest capacity planning pitfall – production support.  Unless you have the ability to dedicate resources 100% to the project, you run the risk of losing some of their time to unplanned “lights-on” activities such as resolving production problems.  This can be difficult to avoid in relatively lean IT shops and equally difficult to manage for project planning purposes.
  • Buy versus build.  Do you have the skills internally to deliver the requirements or will you need to rent some expertise from contractors?  Do you have the capacity to do the work yourself or will you need to outsource some of all of the work because your internal resource won’t be available to meet time requirements?  Do you have a hard stop date and need to do “right-to-left planning” to meet your date but internal capacity is inadequate for the job?  Is there an off-the-shelf solution available that would be more cost effective, less risky or faster to market?  All of these unknowns need to be considered and decisions made in order to begin to understand the project timeline.
  • Risk.  Is this new technology with high risk associated to it because “you don’t know what you don’t know”, or has your team done this a ton of times before, it’s a core competency and it’s low risk?  Is the complexity of the project relatively high with multiple opportunities for time consuming issues to arise, or is it straight forward and easy?  Generally, time estimates for high risk projects are themselves more risky than the lower risk projects which can more accurately be estimated.
  • Project Plan.  The typical waterfall project lifecycle moves through seven basic phases:  Initiation, Requirements, Design, Development, Testing, Deployment and Close.  The first six, Initiation through Deployment, comprise the delivery estimate.  In the Initiation phase, all you have is a concept with no tasks to hang on it that would lead to delivery of the desired outcome.  Until you document the requirements (the “what”), you don’t really know what you’re delivering.  Until you create the design (the “how”), you have no real idea how the requirements will be met.  And there’s no way to understand the development and testing efforts until you’ve gone through the requirements and design process so you know what to code and test.  But here’s the kicker – tasks on a project plan, by best practice and common sense, need to be identified and estimated by the people who will actually be doing the work – not the Subject Matter Experts or the Managers who tend to underestimate based on how long it would take for them to do it (not their lower level resource with emerging skills) or tend to be optimistic in their estimates due to pressure from above or a desire to please.

All of this gives credence to the basic premise at the beginning of this article:  The first date you hear is not “the date”.   OK, let’s assume that’s a given.  But we can’t wait until delivery of the project is imminent to communicate to the Sponsor and stakeholders when they can expect to receive their deliverables, so here’s what we can do.

As we move through the project lifecycle, more and more becomes known about all of the items discussed above, and as our knowledge in these areas increases, the accuracy of our estimates also increases.  That’s why the more mature IT shops and their business stakeholders adopt a model of increasing estimate accuracy based on project phases.  At the completion of each phase, the components of project estimates are reviewed and updated so that estimates can be refined and restated to reflect what we’ve learned to that point.

A model used by some IT organizations is as follows:

At Completion  of Project Phase:

Accuracy of Estimates:


+100% or -50%


+50% or -25%


+25% or -10%


+10% or -5%


Using this model in an example, let’s say we have a project that involves developing a new accounting system.  When IT reviews the concept and provides their experience estimate based solely on a high level understanding of what might be involved, the estimates at that point are accurate to a range of +100% or -50%.  Let’s say their estimate at project initiation calls for the project to take 12 months to deliver.  What this is actually telling you is the true delivery effort will take somewhere between a high of 24 months down to a low of 6 months, twice as long or half as long as their best guess at that point.  Not quite the first date you heard!  As the project progresses and unknowns become known, the team re-estimates at the end of each phase with an ever reducing range of accuracy, as indicated in the model.

What are the impacts if IT and Business Leaders and Stakeholders ignore the reality of estimate accuracy described above?  This is what their project experiences could look like:

  • IT rarely delivers projects “on time”, defined as in keeping with their initial high level estimate which is just a guess.
  • Confidence in IT project capabilities suffers due to their track record of never delivering “on time”.
  • Project teams are constantly under pressure to reduce timelines so they can deliver “on time”, resulting in too much overtime, too much distraction and stress, burn-out for key resources and turnover.
  • In order to get delivery closer to the fictional “on time” date, projects can wind up with quality issues since testing is the last phase in the project lifecycle and is the usual target for cutting time to meet dates.  This leads to higher project costs due to rework.

The next article will focus on project requirements and their importance to over-all project success.

Copyright 2009, Rick Wyatt, IPT Concepts, LLC