The last 20% of the work takes 80% of the schedule. How many times have you heard of this happening?

The project is cruising along. Work is getting done. The percent complete steadily rises until it hits about 80-90% and then it stalls. It just sits there at 90%. Days go by. The team is working, but every time they’re asked for an update the answer comes back the same, “We’re almost done, just another couple of days.”

Ignoring the problem of chronic underestimation, why does this happen?

One reason is using percent complete to record progress. Let’s take a closer look at percent complete.

Suppose we have a project that has 10 team members with 10 days of work each. This gives us a total project size of 100 days of effort (making our calculations super simple).

On day 9 of the project the project manager reports that the team is 85% complete. How late is the project going to be?

Well, it is tempting to say that the team has been knocking off just over 9% of the project work per day so tomorrow (the scheduled end of the project) they should be 94% complete and then the project should end just one day late.

Sure enough, the next day the team is 94% complete. Great! But the next day it is 95% and the day after it is 96% and…

The project comes in 5 days late. Fully 50% behind schedule. What happened?

What happened was that Larry (known as “Late Larry” to the rest of the team) started on his 10 day task 5 days late. So by day 10 Larry still had 5 days left to work. Tracking percent complete made this impossible to see from the project level.

So, what to do?

I think the best way to avoid this kind of thing is to always ask, “How much work is left?” And ask for it in a range. By asking how much is left instead of how much got done you allow for the fact that people learn more about the task as work on it progresses. It is extremely unlikely that the original estimate is right on target and asking how much is left is a good, non-confrontational way to get this important schedule information. Asking for a range reinforces the idea that we expect that estimates change as the work gets done.

Be bold! Toss out percent complete and focus your project team on looking forward to what is coming up by monitoring the work in front of you rather than focusing on the past.

Cross posted from TechRepublic

At most companies, we have to deliver or lose our paychecks. Yet, we are so focused on results that we sometimes fool ourselves into thinking that, if we just wish hard enough, it will become a reality. This wishful thinking (plus the bad habit of single point estimation) creates major political stress between project teams, their stakeholders, and those people that orbit around them (a.k.a. customers). Even worse, old school project management tools do us no favors in this regard.

The politics part is something I’m sure most readers will recognize. At the heart of it is a process often led by the same people week in and week out debating if something will take four weeks or five weeks and what change is needed to get people somehow working harder and hitting more of their milestones. It feels like continuous real-estate negotiation where nobody seems to win.

To be fair, the dynamic tension is real. On the one hand, you don’t want your people sandbagging and slacking off; on the other hand, you want realistic estimates that you can make commitments against. The good news is that there is a simple cure for much of the politics: stop using single-point estimates. These evil little half-truths cause plans to go sideways all the time. Nothing illustrates this more than the estimation game.

The single-point estimation game with Steve and Bob

Steve is a grizzled hardball stakeholder. Bob, who is not grizzled, is a hard worker and eager to please. They use single-point estimation, which leads to a negotiation cycle that invokes the politics of self-preservation if you play it long enough.

Steve: I need you to add an API to the accounts receivable module.

Bob: Huh?

Steve: Look, the business depends on this. How long will it take?

Bob: Ummm, 8 weeks.

Steve: That’s insane. What’s the best case?

Bob: Well, if the stars align, maybe 4 weeks.

Steve: Great, let’s assume 4 weeks in the plan.

Bob: I can’t promise it any earlier than 6 weeks.

Steve: Ok, 6 weeks.

Bob: #&$^%!

Bob has done stuff like this before, and he’s 80% confident he can get it done somewhere between four and eight weeks. Foolishly, he’s settled for the midpoint of six weeks as a promise since he wants to please Steve.

Mathematically, there is a 50% chance he’ll run late and then take heat for that from Steve. If this game gets played multiple times, he’ll quickly start quoting eight weeks to protect his own paycheck. The game itself forces Bob to start sandbagging. How does Bob get Steve to agree to eight weeks? You guessed it –he starts his next negotiation at 12 weeks. Where Bob comes from, that’s called a lie, and he feels bad about it, but what’s a worker bee to do?

Sandbagging is toxic to plans, especially when you can’t see the buffering. Bob’s project manager will probably pad things as well by goosing his number by 40% because “developers always underestimate,” but I digress.

Fortunately, you don’t have to settle for this.

The ranged estimation game with Steve and Liz

Liz is savvier than Bob. She knows single number estimates are a lie. She estimates everything in ranges to capture the realistic uncertainty that exists in predictions.

Steve: I need you to add an API to the accounts receivable module.

Liz: That’s pretty vague, but I feel 80% confident it can be done in 4 to 8 weeks.

Steve: Look, the business depends on this. What are the odds of 4 weeks?

Liz: 10%, best case. Let’s spend this afternoon talking about requirements, and I can narrow that range for you for sure.

Steve: Ok. When can I promise the customer?

Liz: Right now, 8 weeks if you want a 90% chance of keeping that promise. If you want higher confidence, add a week. Even odds, we’ll get it done in 6 weeks. I’m sure our customers appreciate predictability, so you probably should promise 8 or 9 weeks.

Steve: Good point. I’ll come back after lunch with more info.

Liz: Great, I’ll look through our past plans to see how long similar projects took.

This game is completely different because it’s not a negotiation — it’s a dialogue. Liz can stand her ground because she is an expert on the issues that are driving the uncertainty. It’s also clear she can’t resolve the uncertainty until Steve does his part.

Does Liz worry about her paycheck? No, she has a strong track record of delivering inside the estimate range and managing away the uncertainly via collaboration.

Conclusion

Forcing people to ignore undeniable uncertainty injects mistrust into the social network and invokes the politics of self-preservation, which creates a lot of bad mojo for today’s organizations. Moving the social dynamic away from negotiation towards collaborative dialogue can have a profound impact on delivering results in a predictable and productive way.

Estimation and negotiation have nothing in common so keep them separate. You can easily achieve this by estimating in realistic ranges instead of using a single number.

---

Author’s Note:

This post was originally written for TechRepublic, a great source for commentary and analysis on all things relating to technology and IT.

---

Cross posted from Cloud Ave.

A brief history of typists

Back before the 1980s there used to be these people called “typists” and they often worked in a “typing pool”. What did they do? Well, when someone had a document that they needed typed they would give the handwritten draft to the typist and she would type it up.

So, where did these typists and typing pools go?

In the early 1980s WordPerfect and WordStar became available for PCs and with the rise of PCs in the 80s suddenly anyone could enter, edit, and format text. Maybe not as quickly as a good typist, but you did have control over the ultimate output. You got exactly what you wanted. Everyone was now their own typist.

Typists and their pools disappeared.

A brief history of calculators

There also used to be these folks called (I kid you not) calculators. What did they do? Well, when someone had a bunch of numbers and formulae that they wanted calculated they’d hand them over to the calculators and they’d “run the numbers”. The calculations were done one at a time, often on hand calculators, and written down on paper “spreadsheets”.

So, where did these calculators go?

In the early 1980s VisiCalc and Lotus 1-2-3 became available for PCs and with the rise of PCs in the 80s suddenly anyone could enter, edit, and recalculate spreadsheets. Unlike typing, this was faster than a good calculator, and you had the control to do “what-if analysis” as well. Everyone was now their own calculator.

Calculators and their paper spreadsheets disappeared.

Are you detecting a pattern here?

What about Project Management?

Obviously the same thing happened with work breakdown structures, Gantt charts, scheduling and all the other project management stuff. But somehow the project manager didn’t go away. Why? And what’s so “2.0″ about this?

Project managers didn’t go away because project management is different in a fundamental way from word processing and spreadsheets. The activity of project management is inherently social whereas both typing and calculating can be done by a single person. Project management 1.0 was about using software to calculate a schedule. But a project is much more than a WBS and a schedule, and that “much more” is what project management 2.0 is all about.

It is not about turning everyone into a project manager in the way word processors turned everyone into a typist. It is about taking the functions of communication, organization, estimation, scheduling, and status updating and facilitating them via the software. It is a task that is impossible to do using stand alone software but for which web based SaaS products are the bomb!

This shift to a more bottoms up collaborative method of project management is empowering project managers rather than obsoleting them. With the new breed of collaborative software the project manager is freed from the tyranny of the status update to do other critical tasks; tasks like maintaining executive sponsorship, clearing roadblocks for the project team, maybe even contributing more to the project execution itself.

More than just empowering project managers, the project management 2.0 tools build complete pictures of what is actually going on inside your projects in real time. In a very real sense you are getting the most up-to-date information about your project. The fact that all this information is distributed in real time to your entire project team empowers the team to respond very quickly to changes in the project status or plan.

Beyond status and schedule, collaboration between stake holders, the project manager and project teams is enhanced by the integration of document attachment, commenting, and wiki-like authoring in some of these tools. Project team members are hungry for a single source of truth about the project status and all of the associated collateral.  Ideally this integration should extend down to the individual task level.

As more of this free form collaboration is encouraged in companies, the tools to facilitate and organize it into an easily understood whole will become more important. With the help of the new generation of tools healthy communication and flexibility can improve your project performance.

---

Author’s Note:

This post was originally written for Cloud Ave, a great source for commentary and analysis on all things relating to Cloud computing and SaaS.  It was written at the behest of Zoli Erdos, to whom I owe a debt of gratitude for his excellent advice and feedback and for moderating two excellent panels of which I was honored to be a part.  Thanks Zoli!