Repeat after me: The quality of a project and its schedule are directly related to the quality of estimates.

Of course, there isn’t a problem with this. There are many problems with it. For example:

• Projects are too big to estimate;
• Workers can’t give solid estimates, because they don’t have experience doing so;
• Even when they can, workers won’t give solid estimates, because it’s more comfortable to tell people what they like to hear; and
• Even when they can and will, estimates will often be wrong because, well, nobody thought of that.

Regardless of why, the result is that we learn we can’t trust the schedule.

No big deal, except that somebody made a commitment based on the schedule, turning it into a deadline. No matter what your field, you have experienced this. However, if you’re in software, you have a name for it, thanks to Ed Yourdon’s book: It’s a Death March.

Sidenote #1: If you work in software, and probably even if you don’t, give the book a try. It supplies good insight into where these projects come from and where they end up.

Sidenote #2: As Yourdon himself points out, this is not to compare a couple of weeks of staying late at work to the Prisoner of War march during the Second World War. It’s pretty rare that releasing a product involves war crimes and thousands of deaths.

So, how do we avoid this?

First, if you can answer immediately, then you have a guess, not an estimate. Stop and rethink, because a guess is very probably wrong. For everybody involved in a project, it’s better to be disappointing and right than people-pleasing and wrong…especially when your part of the project has gone careening off the rails.

Second, have a model. If you have done similar work before, that’s a good start. If you haven’t, you need to build the model, which leads us to…

Third, work small to large. How long does it take to build a seven story office complex? How long does it take to design a truck engine? I certainly don’t know, and I doubt that many people do. However, at some point, you need to fasten sheetrock into place or decide on the placement of fuel or power lines, and those are tasks we can estimate. If you can divide a task into smaller parts, then do so.

Fourth, do it again. People are optimists. Unfortunately, an optimistic schedule ends with missed deadlines. So once you have your estimate, introduce Mr. Optimist to Mr. Murphy. For each of your tiny little tasks, what can go wrong? If those things go wrong, now how long will the task take? Look at the difference between the best case and the worst case. Guess which one is more likely.

Fifth, bulk up. Remember that you don’t work in isolation. Even in the sheetrock example above, you don’t just drop into position and start hammering. You need to retrieve the sheet and the nails and be extra careful on placement. That means every task needs a little extra time built in for “warm up” or “context switching.”

Sixth, remember the lifecycle. While there are certainly exceptions, most tasks become less reliable when someone “Just Does It,” to paraphrase the ad campaign. Instead, every task is actually three. You need:

• A plan of action,
• The work, and
• Verification that the work is right.

If they’re honest, most people will tell you that the actual work is the fastest part and good testing is both vital and time-consuming. The numbers that I’ve seen kicked around are 2:1:3. That’s right. The enlarged number you just got is probably only a mere sixth of the actual time to completion.

Seventh, track your credibility. Look, we’re all wrong. Always. The reason that some of us look right is that those people learn how wrong they are and compensate. The railroads understand this: If it’s discovered that most trains are five minutes late, there are two solutions. First, you can declare “on or close” to include those five minutes. Second, you can change the schedule so that the riders don’t expect anything for those five minutes.

So, if you always overrun your schedule by ten percent, add ten percent to your estimates.

Eighth, vote early and often. In other words, don’t be afraid to change your estimate (and notify the project’s stakeholders about it) when you learn new information that changes the schedule. The earlier you can make a change, the easier it is for the team to keep on track overall.

Here’s where we get to the hard sell, because I can actually say, “you could do all that…or you can use eManagr.” Our task and estimate system is designed around these very principles.

Our model is to build an estimate from the smallest parts possible. In fact, eManagr will encourage you to split up any task taking more than a few hours, because that’s around the point where estimates become less reliable. We don’t (yet) have a “worst case” feature, but do feel that, when encouraged to look at work in terms of smaller tasks, the optimism will fade.

We silently add a small percentage of time to handle switching between tasks, so you don’t need to worry about it. We also impose a Plan-Do-Test lifecycle on every single task.

Likewise, the time you spend on tasks is saved and statistics generated. Those statistics then feed back on your estimates, allowing even unreliable people to have solid schedules. Additionally, you can change your estimate at any time until completing the task. This doesn’t actually change your statistics, however; we track both the initial estimate and final estimate in comparison to the actual time spent.

Hopefully, this gives a feel for the eManagr schedule model, and if you’re just passing through and not an eManagr user, I hope it helps you plan out a project without us (though we’re free for a single project and only six bucks a month for full access). “It’ll be done when it’s done” isn’t good enough for the corporate world (especially today), so a good estimate and a good schedule will take you as far as good skills in your field.

Two down, one to go. Next time, we’ll talk about the eManagr profile, including what it does today and what it will do in the near future.

What’s the big deal?

Teams fluctuate. Organizational charts change frequently. Workload is shouldered through various outsourcing firms. People come and go. In other words, your team is very likely fluid, and if we can help you form and organize your team faster and better, then that’s one distraction we’re happy won’t worry you.

The Hollywood model is about precisely this. Rather than attack a problem in terms of “resources” to be used, eManagr thinks in terms of tasks to complete and the people qualified to complete the task.

When a producer creates a movie, she starts with a writer’s script. Often, she has directors with whom she enjoys working, and brings one in who has the time. The roles in the script may also suggest actors these managers have already worked with, and so the cast and crew is built from relationships. Where there isn’t a relationship, the producer wants people with the best reputations.

And that’s all there is to our model. Relationships come first and foremost–you already know how to get in contact with your associates on eManagr. If your circumstances don’t permit any further recruitment, that’s it. If they do, though, you can search for someone with the skill you need and get the people who have the best objective records for getting their projects done reliably.

But that’s a story for the next post.

Meanwhile, today is Memorial Day in the United States. Whatever your politics or belief in any particular war, remember that those who give their lives for their respective countries do so with honorable intentions. Take the opportunity to remember their sacrifices and, as importantly, take time to comfort those who have lost loved ones to wars.