Do you periodically find yourself estimating complex projects? Over the last year, I’ve spent a lot of time working with a state agency on a complex change project. Fortunately, I was able to convince them that spending time creating a schedule based on “guesstimates” wasn’t worth the effort. Rather than wasting time creating guesstimates, we focused our time on scoping and estimating the project.
The problem with estimating complex projects is that complex projects are not like complicated projects. Complicated projects are typically linear and logically predictable. Complex projects have too many factors (and people) involved to be predictable. They often evolve in response to real-time decision-making. Building a bridge is a complicated project. Designing and testing a new drug is a complex project.
There is a vocal movement about this subject that is referred to on Twitter as #noestimates. For those unfamiliar with this movement, it is an ongoing conversation on the value of providing estimates. The basic idea is that estimates are rarely reliable, have limited value, and waste time that could be better spent on creating products. Presently, the conversation is pretty restricted to the software development world. As this blog outlines, there are some meaningful debates occurring. Some of these good conversations can be applied to other types of projects. In this two part blog, I am going to lay out six conversations to have when you are estimating complex projects.
Why are you estimating the project?
Depending on where you start reading, the conversation begins with the question, “Why are we estimating this project?” It’s a good question.
If you’re the customer who is paying for the work and you have limited resources, time spent estimating the work has great value to you. It tells you whether you can afford the project. The conversation on estimating can help ensure that the scope is well understood. It may also be valuable to know when your time or money is going to be needed for testing, inspections, or material purchases.
If you’re managing a large and diversified portfolio of projects, knowing when your projects are going to be completed is pretty important. A client or management’s request to know when a project can be completed, or what it’s going to cost is always valid.
That said, it’s important to have a conversation with your client (or your management team) about why you are estimating the project, and about the efficacy of your estimates. Some activities are simply more predictable than others. When your estimate is nothing more than an educated guess, any schedule that is developed from those estimates is hardly reliable. Find out whether your client wants a worst-case scenario or a most likely outcome.
Begin by knowing why you’re doing the estimation. If there’s not a good reason to spend time estimating the project, here is an approach that might work for you.
Start small and iterate: This approach works well on projects that have a set of independent work packages, which each add value for the client. Set up your project by defining the independent work packages that will deliver the most value to the client. Working in two or three week time blocks, select the initial group of activities that you wish to finish. Finish those activities and demonstrate them to the client at the end of the time block. Have a conversation with the team and your client about what went well, and what could be improved. If the client is happy, repeat the process.
What are you estimating?
Another part of early discussions is the notion of whether you are talking about cost estimates or duration estimates. They aren’t the same. Proponents of the #noestimates movement often advocate the creation of a budget but not a schedule. One helpful question to ask is whether anyone can reliably estimate progress.
For example, take an activity to install windows in a building. It’s pretty straightforward to walk around and count the number of windows that have been installed and do the math for a reliable estimate. If you’re working on a training manual, it can be quite difficult to estimate progress. This is especially true if there is a large group of people who have to approve the manual. When you’re working on this type of activity, you really aren’t done, until you’re done.
What is the recipient of the estimate planning to do with that estimate?
Quite frequently, particularly in the government world, the estimate, perhaps with some padding, becomes the budget. Finishing the project over budget can be a blemish on the record of the project manager. And the budget becomes the basis for a contractual relationship between the government agency and the outside consulting firm. We’ve all heard the horror stories.
Estimating for the purpose of creating a schedule is quite flawed. I’ve argued this point for years. Many people have tried to convince me that creating a schedule was a worthy endeavor. And many people still do it. I’m not saying that it isn’t important to have a general understanding of the way the project might unfold, or some deadlines.
I’m simply saying that Gantt charts take a lot of time, and when the activities cannot be logically estimated, the resulting schedule is not reliable. To complicate matters, project managers often spend a lot of time using complex techniques to manage to that schedule. And, they often use earned value analysis to correlate the amount of money spent and the value received to date. When estimates are seriously flawed, this is a waste of time. Surely there is a better way.
#Gantt Charts take time. When activities can’t be logically estimated, the plan isn’t reliable. Click To Tweet
In part 2 of this blog we cover who should be doing the estimating, what processes might be used, and how complexity impacts estimations. Read it here.
