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.

That was a substantial goal for eManagr. If it was to roll out, it absolutely had to be useful. Not content with reporting, a modern management system needs to be a manager. That’s especially true in the current economy, where managers can and should be pressed into service where they can do the most good (most of them in my field want to get their hands dirty, too).

How do we do it? Yes, there are some minor algorithms and formulas that help with dispatching, but we also spread out the burden to where it can be resolved most easily.

The “Web 2.0″ world calls it “crowdsourcing” and then misapplies it. Where the rest of the Internet asks everybody to contribute whatever they like, eManagr asks workers to supply work estimates. More importantly, long estimates are no good–we want to build all schedules from bite-sized units of labor. Likewise, we ask everybody on the team to vote on features. That information available, eManagr then offers decisions to guide the team most efficiently–short, popular tasks give you the most bang for the buck, so to speak.

However, there’s another important issue, here. By looking at your schedule under a microscope–individual rooms rather than an entire house–everybody is set to thinking about the work in detail. Likewise, the smaller the workload, the estimate will be more accurate.

The result, after we apply the aforementioned formulas and algorithms, is that eManagr can give you a more solid schedule and keep your team on track. That leaves your workers to do their work, and your managers to mentor the team. Leave the scheduling to us and let software work for you, for once.

That should explain everything. You want the actual questions? Picky.

Does the world need another project manager? Does the world need another e-something? Does the world need another quirkily misspelled domain name?

When development started on eManagr, I wanted something special. I wanted a system that would work for us rather than become another burden. In other words, eManagr need to actually manage your team, so that your team can, you know, get to work. It also needs to be a good manager and stay out of your way when you’re working. I’m measuring success only on how well it does that, not how many Microsoft Office features got crammed in.

First things first, eManagr doesn’t waste your time with customization. It looks like a legal pad. Verification takes more time than production. Tasks are more important if they’re shorter and more popular. Live with it, because the hours you spend arguing about how, exactly, to determine importance is a complete waste of time. eManagr might not know better than you, but like the best managers, a good enough decision isn’t up for debate until the real work is done.

Second, eManagr tracks your work. Partly, this is to help you eliminate time-sheets (an upcoming feature). But more importantly, it helps you give a better estimate for future work. Most stakeholders don’t care when something gets done. They really care that you get it done when you said you would, so they can plan around it.

Third, eManagr communicates by e-mail. You know, every time management guru tells you to stop checking your inbox. And you know what? Nobody’s stopping. So as long as you have the bad habit, we make it work for you. Once you create your account, you don’t need to go back to the website for every little thing. Fire off a message, even from your phone on the road, and eManagr will update things for you.

Fourth, we think a project runs smoothest when everybody has a say. Therefore, our priority system is semi-democratic. Everybody on the team can vote on project features, and eManagr will schedule those with the most votes first. However, since dictators can get things done quickly, managers can allow some voters to be “more equal than others.”

Lastly, we don’t know you. You might be the CEO of a multinational corporation. You might be an employee of a start-up. You might participate in Open Source projects. You might be an artist. You might even be a student working on a group project. Because of that variety, our teams use the “Hollywood” model. At any time, you can start a new team and staff it with any other eManagr users. You can ask subordinates, coworkers, friends, family, or consultants to join your team, and immediately assign work to them.

In other words, eManagr directs you and makes suggestions, but above all else, lets you do your job. And that is exactly what I wanted to see.

Is there more work to do? Sure. We have a whole bunch of features that we’ll be rolling out in the coming months. It’s exciting. But it’s also too much material for this post, which is already too long by half.