pmStudent

Please leave a comment with your thoughts.

I have been thinking and writing much about project estimation these days.

It seems to be an area where so much confusion occurs, starting with the guy who is typing right now.

Here are some of the pitfalls of project estimation, several of which I have fallen prey to myself:

Anchoring

This occurs when estimates get biased (deliberately or not) by some influence other than the knowledge and experience to yield a reasonably accurate estimate.  Teams may be asked to give a rough "back of the envelope" estimate just so management can make a decision and then when it comes time to do the real estimates, a bias from a false starting point is already there.  In my experience, these estimates tend to be way off the mark.

Anchoring can also occur by the way you ask for estimates.  I have recently realized that I sometimes prompt team members by venturing a guess myself when I feel fairly confident about the technical aspects of the work.  By doing so, I have been anchoring my teams' estimates unnaturally.

Overconfidence

I was once in the office of a customer discussing my team's estimates and my range estimate was a -5%/+10%.  One person commented that this was way to uncertain, after all, it was for a project only 3 years long working with complexities and lots of unknowns.  In retrospect, I was far too overconfident myself in those estimates.

Another form of overconfidence can come from the tendency to forget about the human factor involved with project estimation and rely too much on tools and fancy math.  If you have lots of well-recorded history then these models can work very well, but plugging in estimates without regard for the human influences (like anchoring) can lead to big deviations and general lack of rigor in your project estimates.

A few of the things I'm working on now include the following:

• Uncovering the best method for acheiving reliable estimates when you are in a dynamic environment with little to no past history to rely on.
• Heading off the anchoring problem, in all it's forms and all the sources where it can be a problem.
• How to accurately reflect the level of confidence and low/high ranges on project estimates.

What are your struggles with project estimation?  Do you have any thoughts to offer by way of extending what I've already said or responding to one or more of the points made?

Image by !!!! scogle via Flickr

Matt sent a particular system engineering document out for peer review. 

The quality assurance analyst on the project sent an email out asking the SE lead which version of the document template should be used to judge Matt's with.

Email chains later, it turns out Matt and the other engineers didn't know about any universal template that was to be used...they started with examples from previous projects that looked applicable.  There was an unofficial "official" version that someone cooked up floating around.

Now Matt is looking forward to reformatting his document into whatever the "official" format finally ends up as.

What is Project Quality Management?

You can find definitions all over the map, but to me it's really about 3 things.

1) Continuous Improvement

This is not a one-time, check the box event.  This is a continuous process throughout the entire project.  You can check a box when you do scope verification, but in the meantime QM is about making sure the activities throughout a project's life span are efficient and effective towards the end goals.

2) Consistency

In the anecdote about Matt, the project had at least one dedicated person who was solely focused on QM.  Or at least they think they are.  QM is more about prevention by optimizing the process than that.  The audit of output should be focused as feedback to optimize the process, not as the only way of managing quality.

The quality role should have ensured the engineers had a consistent template that made sense, had their input and that of the relevant stakeholders, and clearly noted which parts could be customized and which parts are critical to the consistency of the process.

3) Ensure the Project Meets or Exceeds Stakeholder Needs and Expectations

If having a consistent template doesn't add any value by ensuring requirements are met or by optimizing the activities, what good is it?  Are you pigeon-holing everyone into a common template just for the sake of it?  Does it take them twice as long to use your template because they are contorting their content to fit?

That said, I do see great value in having well-defined templates for many project activities that can be used from project to project and different areas within the same project.

I am sure that some of you reading this right now will disagree with my definition of quality.  Perhaps I have left something critical out.  Don't worry, I'm used to people disagreeing with me.  Just leave a comment and let's talk about your views!

I had a conversation today that reminded me about a mistake I see project managers make from time to time.

When creating a Work Breakdown Structure and the subsequent Basis of Estimates, some will use documentation as the key deliverables.

The logic goes something like this:  We don't have anything tangible to deliver except these documents, so hey, let's take all this other work, find which document it most closely relates to, and use that to hang our hat on.

This creates a lot of problems.  

First, it's not accurate.  You didn't take 600 hours to create that document.  Rolling up your work this way gives the illusion that by axing that one document from the scope, it will save that much time and effort.  Wrong!  Most documents, especially in a project with a heavy IT focus, are created only as the 'documentation' of a lot of other time and effort.  In my area, designing and creating build scripts, ERDs, data models, etc. might result in being ABLE to produce a good DBDD (Database Design Document) but all those pieces of scope are separate deliverables in and of themselves.

Second, it confuses your scope and the ability to create and track meaningful tasks for your team.  Creating the document is not the primary goal; the primary goal is delivering all the work (code, designs, etc.) that eventually gets documented in a formal fashion.

Thanks for reading my rant.  A penny for your thoughts?

Everyone makes mistakes. Even if you are supposed to know a lot about a topic, it can be nearly inevitable that you will make a mistake or forget something you should have known.

-Josh
pmStudent e-Learning