The Importance of Confidence and Estimates

As a project leader, it's critically important to be earnest - have an intense conviction and confidence in the plan. Staying calm and confident is reassuring to the team, sponsor,  and stakeholders alike.  The team will take their cues from you, follow your lead, and rise to meet any challenges or setbacks positively.  Whether you are looking at the Inc. list, the Forbes list, or anyone's list of leadership traits, confidence is usually on the shortlist of important leadership traits (or a part of the description of another trait).

So given its importance, how can you build this confidence in the plan?  It comes from having a solid, believable plan that stakeholders, including you and the project team, buy into.  And how do you get that solid, believable plan stakeholders will buy into? It comes from having solid steps and estimates for completing the project.  This puts planning and estimating, in particular, in the "hot seat."  Better estimates make for better plans that can be completed.

Unfortunately, the seat in the PMBOK® Guide is only warm.  The Fifth Edition states: "...a project in the initiation phase may have a rough order of magnitude (ROM) estimate in the range of -25% to 75%.  Later in the project, as more information is known, definitive estimates could narrow the range of accuracy to -5% to 10%."  That leaves you, the PM, with a potentially big gap (75% down to 10%) to close.

Fortunately, the follow on sentence is: "In some organizations, there are guidelines for when such refinements can be made and the degree of confidence or accuracy that is expected."  My personal experience is that most good (or better) companies have or strive for (e.g., unstated policy) tighter goals upfront because it helps with portfolio management.  My estimation invention, for example, helps create better estimates and schedules upfront. While one of the invention's key goals is to have an initiation estimate rooted in explainable units and documented assumptions, using all the features will help the PM by producing an initial high-level plan with estimates, resources, and time-boxed project phases.  Timeboxing is another great tool for containing scope creep and keeping time in the forefront when it's important.

Another issue to watch out for when following the PMBOK® Guide is the recommendation of duration estimating.  If you are following the sequence of putting your WBS and estimates into a schedule network (e.g., AON or Activity on Node), that makes sense.  But most PMs today don't draw those networks.  Instead, they use tools like MS Project, Primavera, or FastTrack, which take care of that for you.  And project team members seem to always have an issue with duration estimating.  They are worried about what may or may not happen, adding large amounts of padding which only get padded further in risk management and other planning processes.  Or worse yet, as they are distracted by duration, they forget the steps needed in the task, and the estimate is too small. 

I've found it easier and far more effective to coach team members to think about effort estimates.  What would it take to complete the task if they could do so uninterrupted? Entering the effort into the software, the scheduling algorithms will add work calendars (e.g., 8 hour days, 30 day months) to get a duration.  I will also make sure I don't schedule a resource as more than 80-85% applied -- if you do the math, you will find that accommodates the average vacation, training, and sick time, and some time for "professional courtesy" (e.g., helping project team members with issues).  This has a further benefit of easing the burden of asking everyone to precisely plan their time off months in advance for projects with less critical deadlines.

Having a framework or process for estimating is also important.  Some items to include are:

• ensuring the business problem is well articulated and understood
• promoting an understanding of the proposed solution, especially the deliverables, to stakeholders
• documenting key risks and assumptions
• understanding the external dependencies that might impact your project

In addition to following a process, and reviewing the outcomes, estimating critical success factors include:

• getting input from relevant sources and SMEs with a high level of industry/work knowledge
• using historical data (if you don't have it in your company, find someone who does)
• performing estimates at least 2x; consider using multi-point estimates such as PERT
• validating estimates by using both top-down and bottom-up techniques (or a tool that applies both)
• getting buy-in from all stakeholders
• allocating resources properly - get the best people possible for each task
• modifying the plan by looking at fast-tracking and crashing, before changing the level of effort
• including the person doing the work in any effort-change discussion

Managing expectations is equally important.  Depending on company policy, I usually let team members know that any project "savings" on non-critical path tasks belong to them.  They can use this time for professional development, pet projects, contributing to other projects, etc.  If they are willing, they can also take on other tasks which will assist in bringing the project to a successful conclusion.  On the other hand, overruns, especially those that occur on the critical path, are unacceptable.  They will be expected to put in the time necessary (within reason) to bring these tasks back on track. Once the project is completed, the overruns and how they were handled usually become valuable additions to the "lessons learned".

In conclusion, it's important to be earnest! By developing estimates using a process, bringing in all the right elements, and setting expectations for team behaviors around time, it's very possible to have a project that completes within the triple constraints. The project manager, project team, and other stakeholders will be confident in meeting their goals.

[This article was originally posted 21 July 2014]

Want to learn more about how to integrate these practices into a project methodology?  Check out our Micro Guide to the PROJECT Methodology.