Ten Steps for Project Estimating

Project estimating is challenging.  Since a project is a temporary endeavour, the specific project activities are often done infrequently.  The company is not able to rely upon a statistically significant set of projects to create estimating standards.  Most projects rely heavily on analogous estimates that are set by team members.  However, analogous estimates depend upon project team member’s experience which is significantly different for each person.  In this environment, estimating is difficult.  So here are ten steps for creating project estimates . 

1. Divide the project into tasks and activities.  It is easier to estimate small “bite-sized” chunks of project work than to estimate large complex activities with many moving parts.   The project leader and the core team members should start with the project goal and deliverables and create a list of tasks and activities necessary to accomplish the goal and complete the deliverables.   


2. Estimate effort first; then convert it to duration.  Estimate the amount of work in each task or activity – not the duration of the activity.  Duration estimates are far more inaccurate than the actual work estimates.  Start with effort.  These estimates will typically be created with the units of hours or days of effort.  


3. Estimate the tasks you know.  The project leader should go through the list of activities and tasks and identify those for which a reliable estimate can be created.  For those cases where standards exist or for which the project management office has a parametric estimating algorithm, the estimate is created.   


4. Estimate the tasks the project leader and core team members know.  Of the remaining tasks, the project leader and each core team member should review them to identify ones for which they can create a reliable estimate based upon their personal experience on other projects.  


5. Make “reasonable” assumptions.  Of the remaining tasks, determine which ones are dependent tasks.  By dependent task, I mean a task for which the effort estimate is highly dependent upon some factor that is not known with certainty at the beginning of the project.  For the tasks that fit that category, make a reasonable assumption about project conditions, and create an estimate based upon that assumption.  The assumption should be added to the risk register.  


6. Assume 75% condition for remaining tasks. For the remaining tasks, the project leader and project team should create a best case and worst case effort estimate for each task.  These may be wild guesses, but they form the starting point for setting the effort estimate.  At this time I average the best case and worst case estimates; then select a value at the 75% point.  These tasks should also be added to the risk register. 


7. Add “unknown” tasks.  If there are any aspects of the project for which the project leader and core team members have no experience, this will be a high risk area for both estimates and execution and should be prominent on the risk register.  Several tasks or task groups are placed into the project in these areas.  These tasks are “place-holders” to ensure that resources and time are allocated to these areas.  Check online sources or other networks to create an effort estimate for these tasks.  The values will probably be wrong, but they at least ensure that the high-risk area is recognized. 


8. Create a network diagram.  It is finally time to convert the effort estimates into duration estimates.  A network diagram or flowchart of the tasks and activities is created.  The network diagram is needed to determine sequence of activities and to identify potential parallel paths of project work that could shorten the overall project duration without reducing the duration estimate of any individual task or activity.  If there are numerous parallel paths, use the critical path analysis method to determine the longest and monitor it closely.  I often will place any tasks on the critical path that have uncertain estimates onto the risk register.   


9. Assign resources to determine duration estimate.  Assign resources based upon resource availability.  Start with the most constrained resource and assign that resource first to the tasks and activities where the resource is required.  Then work through the remaining resources from most constrained to least constrained, assigning them to tasks based upon the network diagram and resource availability.  Based upon the skill set of the resources that are actually assigned to each task, the effort estimate may need to be modified.   Once the assignments are complete, the task duration estimates and project duration estimate is easy to calculate. 


10. Calculate the cost estimate.  Use the cost rate of each resource and the assignment of the resources to the tasks to determine the cost for each task and activity.  Ensure that any other cost factors that must be applied are included.  Also, include the estimated costs of any purchased tasks or activities.   Include a management reserve cost estimate based upon the number and severity of risks on the risk register.

Project Management Software: Help or Hindrance?

I was recently checking out a project management software package and looked at reviews to see how this application compared to others.  What I found was that on the day that I checked, there were 460 software applications that were advertising themselves as project management software.  That is a lot of choices!

It brought me back to a question that I have often been asked, “Do we need project management software?”  I have come to the conclusion that for most projects and project teams the answer is, “No.” 

The Purpose of Project Management Software

Let’s step back and consider the purpose of project management software.  The software is to assist the project manager and project team with planning and tracking of project progress.  If it doesn’t provide timely and accurate information, it is not meeting its purpose.

When project management software is being used correctly it is great.  It is a consolidate repository of project information.  Depending upon the software application, it can analyse the project plan from a cost or schedule perspective.  It often can be used to do “what if” sensitivity studies of various project scenarios and options.  It will generate reports and analysis on a variety of important project attributes.  It can be emailed or shared with team members anywhere around the world and instantaneously updated to show current status.  Good grief, what’s not to like?

Well, all of this capability comes with a burden on the project team.  They must actually use the software for it to do any of those things.  And that is the problem.  Despite the claims of the software developers and their marketing organizations, most of these applications are not so intuitive that you can just immediately start using it with no training or orientation.  And the more powerful the software, the more training it takes to know how to use it well.

The Burden of Project Management Software

That is where the problem comes in.  The software must be used by everyone on the project.  Team members must use the features correctly and they must be disciplined enough to use it continuously for the information in the software to be complete and accurate.  If the team members do not keep the information current, or worse yet, don’t even initialize a project plan with an accurate representation of all the activities, the information coming out of the software will be worthless.  In fact, making decisions based upon what is in the software will often create project problems that would not have otherwise existed.

So why doesn’t the project manager mandate that everyone use the software?  The characteristics of a project and project team make that a virtually impossible task.  A project is a temporary endeavour.  Many project team members are not permanently assigned to a project team; rather they are working part-time on the project with responsibilities in other areas.  Even if they go to the training program for the project management software, they will only use the software with a portion of their day-to-day work and only for a short time.  Within a few months they have probably forgotten almost all of the training.  So when assigned to another project, it is back through training again.  This takes time and money.

In addition, for most team members, maintaining the project information in the software is not seen as being value-added effort.  As far as they can see, it is only used to make pretty charts for management.  The time they spend keeping the information in the software current is time they do not have available to do the actual project work.

The bottom line for many team members is that working with the software is difficult, awkward, unfamiliar and a waste of time.   And it only takes one team member that does not keep the information accurate and current to destroy the validity of the entire project plan and status.

How to Use Project Management Software

So what is the answer?  I believe that there are actually two answers; based upon the characteristics of the project. 

On large complex projects, the project management software is an absolute necessity.  I managed large complex defense projects thirty years ago.  Back then I needed a project management team of five to eight individuals just to keep track of what was happening, maintaining the budgets, tracking the schedules, doing risk analysis, and preparing project status reports.  Today, all of that could be done in the software.

This is a tremendous savings in effort and improvement in accuracy.  And the benefits grow with the project complexity. The key is that all the project information is accurately entered and maintained in the software.  Therefore, I recommend that on large complex projects, the project manager, and maybe one or two others on the core team, should be trained and competent users of the software.  But don’t annoy and irritate the rest of the team.  Many project management software programs have excellent import functions to bring information into the project file.  Give your project team simple forms or templates and have them use those.  Then import the information.  The project file will be much more accurate.  Yes, it is a little more work for the project manager, but accuracy and completeness is well worth the extra effort.

For small simple projects, don’t waste everyone’s time trying to get things into project management software.   Otherwise you soon find that maintaining the software is a bigger project than the actual project work.  Run your projects with post-it notes on a whiteboard (similar to an Agile Scrum Board) or with a simple spread sheet being used as a repository of project information. A project manager on a small project is free to use a software application.  But don’t burden the rest of the team with it.  They have lots of other work and learning a new software application is low on their priority list.   

A Definition of Customer Value?

There is a business axiom, “You can’t manage what you can’t measure.”  Managers need to know if their decisions are having the desired effect.  Otherwise, they are flying blind.  This means they need data, and the closer that data can be to real-time, the better.  Otherwise, they are making business decisions based upon hopes and fears.

A concept gaining traction is to manage and maximize Customer Value within the offered products and services.  By providing a high level of Customer Value, customers will be more successful.  This increased success by customers will then lead to loyal customers and increased customer demand.   Everyone wins. This concept makes good business sense, but it has a weakness.  That is the measure of Customer Value.    

The weakness starts with the precise definition of Customer Value.  It remains murky.  There are numerous perspectives on the definition of Customer Value.  I have been conducting a non-scientific survey on the definition of Customer Value with executives and managers from a number of companies in the USA (that means I have talked with them about this over lunch). I have found that the practical definition for the measure of Customer Value is often based upon the individual’s functional discipline.  For instance:

Finance: Uses cost and price as surrogates for value – the ration of the money a customer pays for the product or service divided by the cost to create and deliver the product or service is the measure of Customer Value. But this is an internal measure that does not consider how the customer uses the product.  The actual value to the customer is unknown.

Operations: Focuses on internal efficiency measures – especially those associated with manufacturing cycle time and quality.  They measure Customer Value use measures such as on-time delivery and P_pk or an equivalent quality measure.  But these are also internal measures that do not consider how the customer uses the product.  Again the actual value to the customer is unknown.   

Research & Development: Sees value in features and technology that are “presumed” to be of benefit to the customer.  Essentially “more” of whatever features is being considered is presumed to have value.  They measure Customer Value in terms of product benchmark comparisons. But often these measures are not correlated with customer applications that increase customer success.  Some of these measures may be irrelevant, or even worse, may detract from actual Customer Value.

Marketing: Focuses on brand awareness and brand affinity. They see products as commodities and the Customer Value is based upon the confidence that the customer has in the product brand.  Brand positioning in the minds of the customers is the primary driver of value.  But this approach ignores the internal cost and effort required to develop and sustain the image associated with the brand.  And to the customer, the brand is a promise.  If the actual product or service does not live up to the promise, the value of the brand is lost and may actually become a strong negative value in the mind of the customer.     

Sales: Focuses on customer behavior in the market and infers Customer Value based upon that behavior.  Measures include market price, market share, customer retention and customer conversion.  But these are lagging measures.  This information reflects the result of the customer’s actions.  Managers can’t proactively manage from these measures; they can only manage reactively.   

Each function’s perspective is limited and out of balance, yet each function has something important to contribute to a comprehensive solution. For something to be valuable, it must provide some type of benefit.   The Operations and Research and Development perspectives definitely provide some insight on the potential benefits of the product or service.  And if something is valuable, there is presumed to be some price or valuation of that value.  Finance and Sales are attempting to capture that perspective.  However, Marketing rightly acknowledges that until a real customer is aware of the benefits and the price and has confidence in both, an expression of Customer Value is presumptuous. 

If all of those can be combined into a comprehensive set of measures, then the managers can begin to make the trade-offs between maximizing the Customer Value and minimizing internal costs.  They can proactively manage the business to select a specific Customer Value level that is aligned with their product line strategy and then becomes a business target.  The managers will then optimize the business processes and systems to deliver that value in an efficient and effective manner.

An obvious challenge when creating the comprehensive set of measures is that many of these attributes are customer attributes, not company attributes.  It is highly unlikely that a customer will be able to set up a measurement system inside their customer’s operations or that the customers will voluntarily agree to setup the measurement systems and provide data to their suppliers. A company must then infer these measures based upon a customer’s actions, or non-actions.  To do this, a company must focus on customer relationship management and apply metrics to customer actions and activities.

Measure Customer Relationship

So the first step in measuring customer value is to measure the customer relationship.  What is the frequency of interaction?  What types of interactions are occurring? What levels in each organization are involved in these interactions?  Is there a pattern of interactions that represent those customers who place a high Customer Value on our products and services?  Is there a pattern of interactions that represent those customers who place a low Customer Value on our products and services? Is this interaction data available real-time, or near real-time? What is the customer saying about this relationship on social media and industry forums?  Are we capturing all of the interactions between the company and customer, at all levels and with all interaction media?

There are some efforts to begin to understand customer interactions and measure them.  The Customer Experience movement is a step in the right direction.  The proliferation of “big data” applications makes this collection of information much more practical.  One organization that I am familiar with, Religence, has proposed an interaction management framework that I think holds lots of promise.  This is an area and technology that is rapidly maturing.

The addition of this interaction metric with the existing internal cost, price, and efficiency metrics should provide the comprehensive set of measures needed to proactively manage Customer Value.  

How To Become A Project Management Expert

In his book, Outliers, Malcom Gladwell states that it takes roughly 10,000 hours of deliberate practice to fully master a subject or skill.  Does this mean that a project manager who has been working full time in the profession for more than five years can be considered an expert?  The answer is, “Definitely maybe.”  Experience is beneficial for improving project management skills, but experience will only take you so far.  There is another very important factors.  Let’s start by understanding what Gladwell is saying, and some of his assumptions and constraints.

   

The 10,000 Hour Rule

Gladwell reached this conclusion by studying the lives of extremely successful people to determine the keys to their success.  He studied concert violinists in Berlin, the Beatles, Bill Gates, and sports figures.  He found that “natural talent” was not the crucial factor.  Rather, it was that the elite in a profession had spent at least 10,000 hours of deliberate practice to get there. 

Now what does deliberate practice mean?  Deliberate practice, as used in this context, is practice in ways that push or stretch the skill level of the individual.  It is not enough just to be doing activity within the profession or specialty, the individual must be striving to add to or deepen their skill set.  So an athlete needs to be working on improving strength, skills, or endurance; not just playing the game.  A musician is adding techniques and mastering more complex music; not just sitting around the campfire singing songs.  A computer programmer is learning new computer languages and creating more complex functionality in their code; not just playing zap-a-zoids on their computer.

Through deliberate practice, an individual builds the skills and knowledge needed to be able to perform at the highest level in their profession.  Gladwell found that the people who were proficient had at least 4,000 of deliberate practice, but the true experts had gone far beyond that number.

Limitations with the 10,000 Hour Rule

But further research conducted by Princeton has undermined the 10,000 rule.  The Princeton research showed that the deliberate practice was very important for music, sports and games.  In those areas it had nearly a 20% or greater impact on individual performance.   However, it had very little impact in the areas of education and business professions.  In those domains, deliberate practice had less than a 5% effect on performance. 

So what is the cause for the difference?  The Princeton researchers determine that deliberate practice is a big help in professions where there are stable rules and a rigid structure.  The rules of tennis are specific and stable.  The rules of classical music are well understood and accepted.  However, in professions where the rules are dynamic and structures are evolving, deliberate practice beyond the levels needed to achieve proficiency does not lead to an appreciable increase in performance. Something else is required.    

Expertise in Project Management

So where does that leave project management?  There are standards and structures within the domain of project management.  However, there are also changes occurring as new technologies and new structures are being applied.  Ten years ago, if you were part of a “scrum,” you were on a rugby team.  Now it is more likely you are involved in a fast-paced product development project. Twenty years ago, project teams that were not co-located relied heavily on regularly scheduled conference calls.  Now, team members tweet, Skype, and instant message at all hours of the day and night.  Thirty years ago, all project records were paper records stored at one location in file cabinets.  Now, they are instantly available anywhere because they are stored in the cloud.  These are illustrations of how the rules and structures of project management are constantly changing.  I don’t know what will be different ten years from now, but I am sure it will be something that changes how we plan and manage project work.

What then is needed to create expertise in project management? Well, I do agree that it will take 3,000 to 4,000 hours of “deliberate practice” in the profession to become fully adept.  This is consistent with the experience requirement for PMP. By the time an individual has that much experience, he or she has probably been on several projects – or at least on several subprojects within a program.  They have had a chance to experience the full lifecycle of a project.  They have had the opportunity to make some mistakes and have some successes.  They should have the technical skills needed to become an expert project manager.

Crisis Thinking

However, there is one more key skill that cannot be easily learned through deliberate practice.  That is the ability to rapidly diagnose a crisis situation, quickly assess the magnitude and urgency of the risks that the project faces, and begin to take appropriate action.  This is not a skill that is learned by practicing critical path calculations or earned value forecasts.  For lack of a better term, this is the skill of crisis thinking.

This skill is developed through experience and retrospective learning.  Doing lessons learned and after action reviews.  I don’t mean the lessons learned session that is done months after a project is over when everyone has forgotten what happened; I mean a review of the situation the day after the crisis is quelled to understand what happened, what was done, what worked and what didn’t work.  Sports teams do this with game film on the day after the game.  The various branches of the USA military do this immediately after each mission.  This type of regular review, when added to the skills from deliberate practice, will develop project management experts.  However, too often, we just run from one crisis to another and never stop to learn.

So definitely spend the 3,000 to 4,000 hours needed to develop full proficiency in project management.  But also, start a disciplined process of frequent evaluations of what went wrong – or right – as you go from project crisis to crisis.  You won’t be a true project management expert until you have mastered this skill.