Estimating Based on a Model of Project Execution

I initiated and managed a lot of projects over my career of 30 years or so. Along the way, I observed some common mistakes, both my own and others, that impact the quality of estimates for cost and schedule. Much of this comes down to the way these estimates are prepared. I’ve got a few thoughts to share on managing the preparation of preliminary estimates, so that proposed projects can be approved based on information that the decision makers can believe reflect an understanding of both the problems and the solutions, and how to achieve them.

An Estimate is Based on a Model

Any estimate of the labor and non-labor costs of planned work must be based on an understanding of what work needs to be done, how it will be accomplished, and who will perform the work. In other words, a project plan. A good estimate should reflect a range of possible values, with a confidence level, and should document identified risks and related assumptions, including an assumed start date.

A Schedule, Not A Plan

A project plan is not merely a schedule, depicted in a Gantt chart. It reflects a number of decisions, from scope and high-level requirements to how the transition from the current state to the end state will occur. It takes constraints, non-functional requirements, and relevant organizational processes into consideration. In addition to direct work on deliverables and supporting activities in the Work Breakdown Structure (WBS), it includes plans for activities such as acquisition, staffing, cost reporting and budget management, risk management, security, and likely others. All of these plans are combined in what is known as integration management. Taken together, they constitute a model of how the project will be executed, which can be used as a basis for meaningful estimates.

What, How, and Who

The matter of what work is to be done is reflected in the WBS. The most meaningful estimate of project costs is rolled up from estimates for each work package. Note that initial work package estimates should assume that all inputs and other resources will be available. Dependencies must be planned for, but work on that when scheduling, rather than when when estimating. There are usually few completely new tasks in most projects, and past experience should drive estimates, even if different people will perform the work. Three-point estimates should be prepared for each work package—most optimistic, most likely, and most pessimistic. These parametric estimates can then be used in Monte Carlo simulations of the project.

 

 

How the work will be accomplished is a technical matter. An architecture or technical approach document, based on the high-level capabilities required for the delivered product, is a practical minimum. A more detailed design document is better, if available for an initial estimate. Either way, know how you’re going to skin this cat! Make any necessary assumptions and document them to be delivered as part of the overall estimate model.

Note that the who doesn’t usually need to be a specific, named person. It’s helpful to have an assigned team before any estimates are required, but that isn’t usually the case, unless it’s a purely internal project to be performed by an established team. It is conventional wisdom that those who will perform the work provide the most accurate estimates, but that isn’t always the case.  For projects where some of the work will be performed under contracts or by contingent workers, you may have to make estimates with a lower confidence level, but that doesn’t mean that they can’t be useful.

Reducing Uncertainty

The goal of estimating should be to reduce uncertainty to a level where decisions and commitments can be made. Not commitments to a precise cost or schedule, but simply to proceed, in pursuit of specific benefits. And that decision to proceed must always be contingent on evidence of progress commensurate with expectations. As the project progresses, actual cost and labor figures can be used to update the estimate, further reducing uncertainty, so that decision makers can re-commit to continuing the project. As the project plan and schedule evolve, the estimate model should track that evolution. A baseline estimate is necessary, but so is a current estimate.

The best estimates open a dialog. You wouldn’t seriously support the Hashtag, “#NoCommunicating,” would you?

In Closing

We should not manage on a ballistic trajectory, where nothing can change between pulling the trigger and impact on the target. Like modern guided missiles, continuous corrections must be made, in order to optimize the effects of scarce resources—human, financial, and calendar. Agile methods are commonly used these days, but there are others, such as stage gates. Whatever governance model is used, a detailed estimate model, updated throughout project execution, will provide much better decision support than a round number.

 

 

 

The RAID Log: Right Topics, Wrong Sequence

If you were to poll project managers on which software tool (aside from email) they use most often, for the largest number of tasks, I imagine that Excel would predominate. From complex calculator to data analyzer to zero-effort database and factoid organizer, I doubt there is a more ubiquitous multi-tool. And yet, we sometimes use it in ways that inhibit our understanding of the problems we’re trying to solve. One example that comes to mind is a spreadsheet template we used in a former life, called a “RAID log.”

The spreadsheet had four tabs: Risks, Assumptions, Issues, and Decisions. Each tab had columns defined that would drive identification and management of their namesakes. In and of itself, it was an excellent starting point. But the sequencing that made the template name pronounceable hid the complex relationships among the four objects. And that probably caused more than a few problems along the way.

Assumptions

Most projects begin with a limited number of facts, or “knowns,” and a by-product of the project is to expand that knowledge base. But at the beginning, a lot of assumptions are needed to fill in the gaps. These assumptions help us better visualize the current state, the desired future state, and the space between. With assumptions, we can make plans and estimates, communicate and collaborate, and otherwise act on those things we know to be facts. Consequently, all projects begin with a set of assumptions.

That said: every assumption carries some amount of uncertainty. Because we depend on assumptions to proceed with our work, and that uncertainty is present, each assumption represents a source of risk. Of course, not all assumptions are foundational, and few will be purely wild-assed guesses, but one of our process goals in every project should be to verify every assumption. To do this, every assumption should be documented and referenced when used in estimates, plans, schedules, budgets, and any other project activity.

Issues

Whether the goal is to correct a problem, develop a new capability, or comply with some external requirement, projects are approved to address issues. If the status quo were acceptable, no one would spend money to change it. On many projects, the project is an umbrella for the resolution of all sorts of issues. As you explore the project scope for details, more issues will emerge, and some of your assumptions will be challenged. This is a good thing: solving the wrong problem won’t get you any points. You might discover some issues can be resolved along the way, while others depend on the outcome of the project. Persistent issues frequently have roots in an earlier solution, and it’s common for them to be well-documented. So capture that content in your project issue log.

Once you transition to the execution of your project, more issues will manifest, especially as you make changes or consume scarce resources (like the time and attention of your stakeholders). On some projects, tracking and resolving issues becomes the key to making progress. The old adage about being up to your ass in alligators speaks volumes about the potential for creating new problems while trying to solve old ones.

Risks

A risk is an uncertainty that matters. As noted, every assumption has an element of uncertainty, and every issue matters. Consequently, a review of assumptions and issues logs should give you a starting point in identifying risks. If an assumption is incorrect, what are the consequences? What is the likelihood of resolving one issue, only to create a new one? In reviewing the plan, identifying risks isn’t just about understanding the proposed solution, but the current state.

As Tim Lister so famously said, “Risk management is how adults manage projects.” Tracking risks, from identification to analysis to action to retirement, is one of the keys to a successful project. Once you understand both the risks and the issues, you can select better risk responses. Being able to link risks to assumptions, and to both the issues that made them worth taking and the issues that they might become, will help you keep preventive and corrective actions from falling through the cracks.

Decisions

The most expensive part of any project is indecision. Many decisions are the leverage needed to resolve issues; others drive risk responses. Still others change or confirm assumptions. Many schedule delays can be attributed to the failure to make a timely decision, or the failure to communicate a decision once made. Once the need for a decision is identified, whether to resolve an issue, manage a risk, or just eliminate alternatives, it should be logged. Allowing a pending decision to drag on too long is an impediment to the project, and to the business of the organization. A review of the decision log for pending items should be part of every steering committee meeting.

The relationships among assumptions, issues, risks, and decisions are complex, and somewhat recursive. Tracking them is not a chore to be done once and then checked off the to-do list. Taken together, they are the background (and sometimes foreground) of every project. Understanding how they interact can be critical to keeping your project on track. So if you use a spreadsheet like our old RAID log, be sure to use it wisely.

Managing Globally Distributed Project Teams

I started managing projects that included team members or customers outside the US in the mid-90’s. In the beginning, it was one other country. Then two, and so on. As I progressed in my career, working with globally distributed project teams became my norm. A typical project would include people spread across five to thirty countries, three to five continents, and from three to seven time zones. As you would expect, it’s very different from managing a few folks clustered together in a cube farm. Preparations must begin before the first team meeting.

Working Calendars

It is important to be cognizant of the non-working days for the people in your team. Set up the holidays for each country in your project planning system—here is a list of commonly observed national and religious holidays in several countries for 2020, and here are instructions for updating the working calendar in Microsoft Project. In addition, ask your team members to record their planned vacation dates in a shared location—I usually just use an Excel spreadsheet, to keep the technical overhead down. Also, find a culturally sensitive way to inquire about maternity leave!

Time Zones

One of the biggest problems with working across oceans is the impact of time zones and the international date line on available windows for team meetings. Even if the organization adjusts working hours to get some alignment, it can be a burden for those who are always either getting up early or staying up late. Try to schedule meetings in a way that shares the burden.

Also recognize that not everyone observes daylight savings time, and those that do, don’t all change their clocks on the same day—Europe and North America are a week apart. And the Northern and Southern hemispheres are on completely different schedules. Here is an excellent resource for finding the current time and time zones of most of the large cities in the world, and here is their daylight savings time page.

Visibility into Workload Conflicts

Most globally distributed, cross-functional project teams include some number of people who have additional work responsibilities. The project will always be in competition with that other work, and you won’t necessarily know when priorities change. To avoid delays, maintain contact with your team member’s manager, or a proxy—someone who can act as a remote source of information and as a person of influence, should that be necessary. Not all cultures will openly discuss doubts and conflicts, especially with a distant colleague. It is vital to have a way to identify and resolve conflicts, and getting a periodic pulse check from someone on site can make a huge difference.

A Common, Bland English

For most global organizations, English is the common language. That doesn’t mean everyone speaks or understands it fluently, and it certainly doesn’t mean that everyone is familiar with all the local idioms, slang, and cultural references. When on the phone, speak deliberately (but not too slowly), as it can be difficult to parse out similar-sounding words. Work to avoid misunderstanding by keeping your spoken communications as jargon-free and non-colloquial as possible. And try to take the edge off your regional accent – I work at sounding as much as possible like a “generic American,” without the drawl. I tried to raise this with a colleague from Houston a few years ago, who replied, “What accent?” Note that British, Australian, Canadian, Scottish, Irish, and New Zealand accents and idioms are just as real and just as hard on the ears as Indian or Texas English. Speak to be understood by your audience.

There are many resources available online that can help you build your Cultural Intelligence, and even if you aren’t managing global teams right now, you almost certainly will be before long. I learn more about how cultural differences impact work and communication with every project, but I generally find that if I assume people are doing their best until I have reason to doubt it, my life is a lot happier.