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-50-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 over, you 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.