Tag Archives: Schedule Management

Schedule Management: Exceptions to the 0-50-100 Method

I realized I hadn’t been posting much about producing and project management this year, so here’s a series of short posts going over some of the concepts I cover in the project management training I do.

Previously, I has talked about a method for managing your schedule: the 0-50-100 method of reporting and tracking completion percentage.

Again, for context, this is all about how to report completion percentage for a (presumably baselined) schedule. In other words, first you do your work breakdown and have all your tasks. Next, you use your personal experience, historical information, and knowledgeable people to figure out how long this is all going to take. In go all the durations for all the tasks. Painfully, you get sign-off and agreement that the tasks will take that long — and all of a sudden you’re off and running with the project.

Are you 0n track? How do you stay on track? If you’re using a tool like Microsoft Project, your tasks can be marked by percent complete. My recommendation is to use three –and only three– percentages:

  • 0% (Not Started)
  • 50% (In-Progress, whether it’s just started or almost complete)
  • 100% (Unequivocally complete)

I still believe this is one of the best ways to manage a schedule — especially for those of you using Microsoft Project. No project is ever so unique that it can’t benefit from any management (despite what some stakeholders may insist)… and the 0-50-100 method allows you to focus on pragmatically solving roadblocks rather than obsessing about reporting minutiae.

However, even though projects aren’t so insanely unique to preclude managing them, they also don’t all fit into one mold. The 0-50-100 method may not work for all tasks, so I wanted to share two other major ways to calculate ‘percent complete.’ Depending on your given project, you might use them a lot, a little, or not at all. In most cases when I use them, I use them in conjunction with 0-50-100 (in other words, my ‘percent complete’ reporting methods are task specific with 0-50-100 as the default).

Percent Complete by Unit
This method is where you mark the percent complete based on a number of units. For example, if you’re in the testing phase of a software development project and your testers need to complete 100 test scripts, that’s 100 units. If they’ve completed 15 test scripts of the 100, you’re 15% done. You have your overall duration of the task within which you estimated all 100 scripts will be completed, but for reporting purposes, you’re being more granular than 0-50-100.

The key variable to keep as unvaried as possible is the nature of your given units. As much as possible, you want your apples to correspond to apples, or at least similarly sized oranges (assuming size is the logical criterion for comparison). You don’t want to compare apples to watermelons in one task. If you do have a watermelon unit amidst a bunch of apple units, that’s where you’ll want to break down your schedule further. Have a separate watermelon task if you can (which will probably be tracked as 0-10-100) and you can have the remaining apples be tracked by unit.

Remember, there are no hard and fast rules. It’s all about the level of granularity by which you want to manage the project… balanced with how much bandwidth you have to manage the project.

I’ve often tracked the workflow of change requests or articles by unit — knowing full well that some requests are more complicated than others or some articles are longer than others. However, collectively, tracking their completion by unit averages out and is easier to manage.

For example, back when I did project management for a publishing company, it was not uncommon to have tasks pertaining to proofreaders, copy editors, and so on. Tracking tasks per page was a natural fit for this kind of work. However, between dense scientific articles and annual reports replete with flashy graphics, any given pages were not going to take the same amount of time.

This goes back to your work in estimating the duration of your tasks. You always want to ask yourself and your team how long a given task will take, as it may vary from project to project. Maybe you can save time proofreading the pages for this particular repot because it’s an annual report with lots of graphics. But then, so you need to increase the per-page duration of the design and layout tasks? And bear in mind, after you’ve done a few annual reports or scientific journals, you should get some good per-page estimates or other estimated durations.

Likewise, for articles in the magazine realm, all articles are not created equal. Maybe I have a separate “per unit” task for feature articles and one for columns. OR, I might go ahead and have a task for each column, knowing that different columnists have different foibles and are best managed by the 0-50-100 method (“Okay, Frank: have you even started yet?”).

Remember, you should be dividing up the tasks to best be able to monitor and manage those pesky humans responsible for the tasks. Reporting on completion should be the same way.

Level of Effort (i.e. Percent Complete by Time Elapsed)
For purely schedule management, this may not come up as much, but this can be very important in overall project management as it makes it easier to tie the schedule to cost.

(Please note, several project managers who could never perceive a world where you didn’t tie schedule to cost to do nice, crunchy Estimated Time to Completion and Actual Cost just had their heads explode. That’s okay. Manager head explosions are a known risk.)

Because it’s good for overall project management, I like this method for tasks in two main instances: for executive reporting and where cost control is paramount.

As an overlay or executive view of the overall schedule, looking at the percent complete by time elapsed is a good way to judge progress from the “50,000 foot view.” In my experience, executives are most concerned about a project’s end date and what the project’s objective is more so than minutiae anyway. If you combine “percent complete by time elapsed” with the cost assigned to the task or overyou can get a good idea of what start-ups and contractors love to term “burn rate” (how fast you’re using up your funding).

For the financial managers among you, this can give you a diagnostic or monitoring tool. If a team has spent 60% of their budget, but only 30% of your schedule has elapsed, perhaps they ran into some complications they’re not reporting. Likewise, a team that has spent 20% of their budget, but 50% of their scheduled tasks are done, did they overestimate? Are they not reporting all their costs? When you are operating at the program or portfolio level, this can be very useful, because while you’re still concerned about making your schedule, you’re looking at a bigger picture (presumably, you have project managers for each project, working in the weeds).

For example, instead of knowing every task for requirements, design, build, testing, and deployment of several software projects, you, as a program manager, might know the start and end dates for those projects and have the percentage of budget assigned to each phase (e.g. 20% of budget for requirements, 40% for build, etc.). Now you can use the level-of-effort cross-matched with your financial reporting to see if any of your projects are under-burning or over-burning. In this way, you’re still using the project schedule as a way to learn if you’re going to make your date, but you have the cost tied to the schedule in such a way that it can be an early-warning tool of projects going off track. And at the program and portfolio level, you often need to deal with funding and supply issues more than an in-the-trenches project manager.

That cuts to the heart of this method. For me, tying the percent complete to the time elapsed works best at a phase or output level vs. a task level — because I’ll tie it to the cost and “burn rate.” Checking percentage this way at too low a level gets back into the silliness I described last time, where people quibble about 37% vs. 39%. Absent of whether you’ve spent 37% or 39% of your money and absent any other attempt at objective criteria, who cares? Nevertheless, this type of view is probably more useful to many managers and executives, so it’s worth figuring out how and where you’ll use it.

Overall, for project managers, I’d suggest looking into using the 0-50-100 percent complete method for your tasks except where doing percent complete by unit will allow for better management. Then, look at the overall project or program, and see how to apply percent complete by schedule elapsed tied to cost in order to give good reporting for the program and portfolio level.

Schedule Management: The 0-50-100 Method for Tasks

I realized I haven’t been posting much about producing and project management this year, so I’ve decided to do a series of short posts for a few weeks going over some of the concepts I cover in the project management training I do.

If you want to spend more time managing your schedule and less time staring at it, at one time or another, you’re going to hear about the 0-50-100 method for managing tasks.

In my case, I was first introduced to it by a program manager where we were working on an integrated project plan that ran over 1,700 lines. There was no way we’d spend every status meeting figuring out the exact percentage of each task – nor what we needed to monitor to make sure we’re on track.

This is where the program manager let me in on a time-saving, sanity-saving trick, especially when using a schedule management tool like Microsoft Project.

I should probably back up a bit and clarify that this schedule management tactic is for when you have created your project schedule. Hopefully, you have broken down the work into logical tasks — and you have used your acumen, other people’s acumen, and historical information to give those tasks reasonable durations.

Now, to make sure your project schedule is not merely decorative shelfware, you’re using the schedule as a living document, getting updates as to whether tasks are complete or not — and by what percentage.

When you think about asking for the percent complete of a given task, that’s where this method makes so much sense. That’s because most, if not all, tasks can be expressed as one of three states:

  • 0% – The task has not been started.
  • 50% – The task is in process. Maybe it started yesterday. Maybe it’s about to be finished tomorrow. It doesn’t matter. For reporting purposes, any “in-process” task is always 50%
  • 100% – The task has been completed (and the people who need to confirm it’s completed have said it’s completed).

There are exceptions, which I can talk about in another post, but consider this: how valuable is knowing completion percentage anyway?

Do you really need to spend a single precious meeting minute on whether something is 37% or 42%?


Anyone who is obsessing about that either falsely believes those abstract numbers will help OR is trying to evade the real question you or any other project manager wants to know:

Can we make our schedule?

It’s rare that I’ve been at an organization where schedule is not, ultimately, king. The 0-50-100 method allows you to zero in on risks and impacts to your schedule.

Here’s how those three simple statuses above help you do that:

0%, the Task hasn’t started.
Is it past the start date?

No? Good. Is there any reason to expect why this task won’t start on time? If the start date is within two weeks, does the task owner know they’re expected to start soon?

Yes, it is past the start date? Okay, how do we get started? What date should it start now — and how does that affect the project being completed on time? (aka, the critical path).

50%, the Task is in-progress
Cool. Did it start on time or did it start late?

If it started late, is there anything we’re doing to make sure it still completes on time? Are those efforts working? Do you need any help to make sure it gets completed on time? At all?

If it started on time, is it going to be completed when we scheduled? How confident are you? Are there any risks popping up that would stop you? Do you need any help to make sure it gets completed?

100%, the Task has been completed
Wonderful. Does everyone agree (who needs to agree) that task has been completed? Are the subsequent tasks starting on time? Does anything need to be communicated?

Is this task like any other tasks still being worked in this project? Were there any risks or lessons learned we should communicate right now about how this task went down?


In other words, as a project manager, you’re using the 0-50-100 method to focus on solutions and support. The more time you spend debating and delineating exactly what the status of a task is during project status meetings, the less time you have to try and make sure things are on track or get back on track.

In other words, it saves time — and it focuses what management really wants to know: will the project be completed on time?