Chapter 4 - Project Predictability

A great project manager will seem, to many, to be a fortune teller. You will seem like a magician.

Like a magician, to pull this off, you need the right knowledge and techniques.

Everyone wants to know when a project will be finished, how much it will cost, and what will be in the finished project.

I will teach you how to perfectly pull this trick off every time!

Seeing The Future Through Synthesis

Remember how, in the first chapter, I said that your job as a project manager is to bring a project to completion successfully?

Do you recall that the key risks to a project are going off the rails in one of the key input dimensions of time, scope, and costs?

Furthermore, do you remember that a project’s momentum is the key metric of its health?

These three key ideas are what gives us perfect future vision. The synthesis of these three ideas can be used to arrive at the perfect means of predicting a project’s future.

Before we get to that beautiful synthesis, we must take a brief look at estimation and its key challenge.

The Estimation Dilemma

People hate uncertainty. That is why they love estimates. An estimate plants itself in someone’s mind and replaces uncertainty. It feels really good to have certainty instead of uncertainty.

If you want to have a perfect estimate, what do you need to know?

Going back to the Iron Triangle, an estimate is a predicted cost, timeframe, and scope of work.

When you order a hamburger at a restaurant, they say, “That will be $8.99. We’re pretty busy today. Your burger should be ready in 15 minutes.” You know how much the burger costs, how long it will take before you get your burger, and what the burger is made with before paying anything. A project is no different, in concept, than this estimate for a hamburger. The key difference is that your project is usually more complex than a hamburger, more unique than a hamburger. You have less historical experience at this kind of project than the restaurant has at delivering burgers. Unless, you are some insane rock star who effortlessly delivers hundreds of projects every day. If so, hats off to you!. A perfect estimate is one that is right more than 99% of the time. There are no truly perfect estimates in our world. A perfect estimate requires trickery. Everyone wants a perfect estimate. It doesn’t bother them if you provide an estimate that’s a trick, since it still accomplishes the same thing. Three Estimating Tricks 1. The first type of trick is historical statistics. If you have observed enough similar projects, you will be able to nail a number with strong probability. If your confidence interval is greater than 95%, then, by definition, the cost and timeline are known. Most of us haven’t done a large enough number of similar projects to be able to use this trick. This technique works best for repetitive tasks and more standardized work. If you build the same thing all the time for different clients, this is a great approach. If you are building CRUD apps, UI components, or static websites, you can definitely use this technique. Statistical knowledge is its own deep rabbit hole. I wanted to mention it, but we’re not going to explore this one more deeply. In short, the more you track your team’s project costs, scopes, and timeframes for similar projects, the more perfect your estimates will be. 2. The second type of trick is to provide an estimate after the work is finished. It’s very easy to estimate how long something will take and what it will cost when the final costs and work duration have already been measured. This is hard to do in practice since it means that you have to have already finished some of the work. The trick is to do a large portion of the project work before giving your estimate. The downside of this approach is the chance that after your provide an estimate the client won’t want to go forward with the project. That will mean you have completed some work that will be unbillable. But, it’s also possible that you may be able to carry over pieces of work from another similar project. Since that work is effectively done, you can factor it into the current project, and you know that it can’t take any longer, even if some changes or porting is needed. 3. The third type of trick is a moving range or worst-case estimate. If you provide an estimate in the form of a range (9-12 weeks), it sounds to most people like a concrete answer; even though, obviously, it is not. The tighter the range, the more it sounds like a perfect estimate. If you provide an estimate for the worst-case scenario, then you can’t be wrong. Suppose you know that a task will typically take 2 weeks and that if things go wrong, maybe it will take 4. Suppose you know that no matter how badly things go, it will be finished in 8 weeks. Then, by providing a bounded estimate, you provide certainty. Say, “This project will be finished in 8 weeks.” In the best case scenario, you end up looking like a rock star when you deliver significantly ahead of the estimate. Perfect Project Predictability How do you provide perfect project predictability? The answer is simple: Control two of the three input dimensions and continuously update the third dimension’s estimate using the project’s momentum as the predictor. That’s the magic trick that will make you a Master Project Manager! • Do you want the cost estimate to be correct? Don’t spend a penny more than the estimated amount. • Do you want the time estimate to be correct? Ship the product when the deadline hits, no matter what state it’s in. • Do you want the scope estimate to be correct? Don’t ship the project until it has every feature on the list. As we learned from the Iron Triangle, you can lock in any two constraints for the project. The third dimension is IMPOSSIBLE to lock in, and so you provide certainty by using the estimation tricks to make it seem as if it’s certain, even though it really isn’t. By using excellent reporting skills, it will never seem like there is any project uncertainty. Masterful Project Reporting Let’s looks at an example of what masterful project reporting looks like, in practice. I’ll go into more detail on reporting in Chapter 11. The key things to observe here is how reporting can make a project appear highly predictable. First, at the very start of the project, you express the project constraints (2 fixed and 1 estimated) and put them in writing: “The project will cost$240K, take 4 weeks, and deliver at least 5 out of these 10 desired features.”

Next, at regular intervals, you provide a progress summary along with a new estimate.

“So far, we are 1 week into the project, with 1 feature finished and another one halfway finished. We have spent $60K. Everything is on track for project completion in the 4-week timeline.” “We just wrapped up week 2 of the project. 4 features are fully finished. We have spent$120K. Everything is on track for project completion in the 4-week timeline.”

“Week 3 Update. 5 features are now live, and we’re halfway done with a sixth feature. We have spent $180K. Everything is on track for project completion in the 4-week timeline.” Finally, once the project reaches the end of its timebox, you present the final summary. “Project Summary. Our initial estimate was that this project would cost$240K, take 4 weeks, and deliver at least 5 out of these 10 desired features. We have successfully delivered 7 out of the 10 desired features in 4 weeks for a total of \$240K.”

As you can see from this reporting, it seems that everything is fully in control and predictable the entire time. As you can also see, this was A TRICK. 10 features were initially requested, and only 7 were delivered. But, due to providing an estimate range, it feels like 2 BONUS FEATURES were delivered since only 5 were promised in the initial estimate.

In addition, notice that due to the way the summary is presented, it sounds as if the timeline is the factor that could vary. In reality, the timeline is fixed. Only the scope of the project (number of features) actually varies. The expenses and timeline were set in stone before the project began.

As a practice exercise, imagine yourself providing an initial project estimate and 4 project reports using the other two constraints as the ranged variable. The example shows us having a variable scope. It is just as simple to do the same with a cost or timeline variable. I have done these with projects countless times, depending on which constraints are most important for the projects I manage.

This is the magic that you must work to be a great project manager! You can provide perfect predictability as long as you know this trick.

Once again, the trick to perfect project predictability is:

Chapter Review Questions

1. Is perfect project predictability actually possible?
2. Can a good project manager make perfect predictability seem possible?
3. What are the three estimating tricks that lead to the best estimates?
4. How does the Iron Triangle inform how you can provide the illusion of perfect project predictability?