Fever Chart Regions

Posted by Rob Newbold in Critical Chain on October 16th, 2011.

I was recently asked how one should decide where the red, yellow, and green regions for a fever chart should go. I regretted not having a concise explanation at the tip of my tongue. So here are the basics:

There are really four points whose vertical positions we have to decide on in order to define the regions: A and B, which are the start and finish of the yellow/red boundary; and C and D, the start and finish of the green/yellow boundary. A and B are the most important, because the red region implies a need for serious management attention. B must be enough below the 100% point to allow a reasonable chance to bring the project in on time, even if there’s a last-minute delay. A must be enough above the 0% point to accommodate reasonable startup delays, without being so high that serious startup problems may go unattended. Depending on the environment, point A could be anywhere from 10% to 40%.

Points C and D define the yellow region, where we start to say, “this project’s status may not be ok.” This is where senior management may start to pay attention. Generally point C will be at the origin, because any startup delay should provoke some concern. Point D is the fuzziest. It could be close to B, if lateness is your biggest concern and by this time there’s you have little concern that the project will be late. It could be much farther down, say at 50%, if you want to minimize delays and get the project done as quickly as possible. Ultimately, it depends on what kinds of attention and actions you want the yellow region to trigger.

There is another way of looking at this. Suppose we explicitly define the green region to be the area in which you have a 90% or greater chance of finishing on time without significant management intervention, and the yellow region the area that gives (say) a 50% or greater chance of finishing on time. If we had perfect knowledge of all the probabilities in play, those regions would not be bounded by straight lines. Without perfect knowledge, we can still estimate positions for the AB and CD lines to approximate our sense of where those regions are. We do that by making the tradeoff between the wasted management attention if the fever chart says the project is in trouble, and it really isn’t; versus the increased chance of being late if the fever chart says the project isn’t in trouble, and it really is.

A related question is, should all projects for an organization have the same fever chart regions? The answer, as usual, is: “It depends.” If, in thinking through the placement of points A through D, the answers are very similar for different projects (especially for points A, B, and C), then you should use the same fever chart regions. If there are groups of projects that have significant differences, you might want to use different region definitions depending on the group. The more uniform the fever chart regions across projects, the simpler they will be for people to understand. And keep in mind that any given multi-project fever chart can only display one set of regions.

Tags: , | 2 Comments »

Introduction to Critical Chain

Posted by Rob Newbold in Critical Chain,Project Management on September 23rd, 2011.

I’ve finally gotten around to putting together a brief video Introduction to Critical Chain, please let me know what you think. (I recommend using the YouTube “expand” button, it gives better resolution.)

Tags: , | No Comments »

Jackie Gleason Multitasking

Posted by Rob Newbold in Task Management on September 5th, 2011.

Need an illustration of multitasking? This Jackie Gleason video could fill the bill.

Tags: | No Comments »

More on Deadline Management

Posted by Rob Newbold in Critical Chain,Enterprise Software,Project Management,Task Management on August 27th, 2011.

We have been very busy over the last few months, but I do pledge to start posting regularly to the blog. I have a few items already fleshed out, so please stay tuned.

We continue to think about and promote a move away from deadline and milestone management, towards the relay race. The following quote from an Earned Value list on LinkedIn triggered a few more thoughts:

The words I’ve learned to use to “speak about EV,” is to ask “what is your budget for producing this widget?” Both money and time? Then the “value” part of EV is [to] “earn” that budget in the planned time. That gets them thinking about the planned budget (BCWS) and absorbing that budget over the planned period of performance. When the pre-defined measure of “done” is achieved on the planned day for the planned budget, then everyone is in the “happy place.” BCWP=BCWS x 100% complete.

Does this bother you? It should. Lines for time and money have been drawn in the sand, and as long as we’re not late everything is ok. Would you rather finish earlier? Too bad. “Not late” is the goal.

Dates are necessary when multiple things have to come together at the same time. For example, if a number of people need to have a meeting to coordinate activities, they pick a date and time. It happens all the time in the business world, but it’s necessary less often than you might think. We think of train schedules as fixed in time, but subway trains operate frequently enough that we don’t usually need to know the schedule. A client apparently needs to know when we are delivering a product to them, but if we asked we might well find that they’d prefer it as soon as possible, with a good picture of the likely range of times.

Dates can be desirable when you want to promote a sense of urgency. If I know I have to submit an article in a week, I become much more focused than if there is no date. So, for example, the simplest way to provide a sense of urgency for project tasks is to give people dates and deadlines. Unfortunately, deadlines also give people incentives to add safety time and to multitask. Look at it this way: even if you have a “successful” project that hits all its dates, chances are there was significant safety time included in those dates; and that meant people likely took on other simultaneous work; and that meant multitasking. The project could have been completed much more quickly and efficiently.

There are other ways to provide a sense of urgency. A critical chain schedule with buffer management is one.

Most project management tools available today support date cultures. Enterprise Project Management (EPM) systems provide unparalleled means of managing and reporting on dates. Unfortunately, in doing that they support rather than change the deadline paradigm. I believe this is why we frequently see companies spend years and millions of dollars implementing EPM systems, without getting significant benefits in return. It’s why multitasking is an epidemic.

Here is a simple way to evaluate a project management system:

  • Does it help make safety time more visible and easier to manage?
  • Does it help set and manage credible priorities within and across projects?
  • Does it help change from a “train schedule” (deadline) paradigm to a “relay race” (as fast as possible) paradigm?

If the answer to any of these questions is “no,” your new system probably isn’t fully helping you to get the benefits you want. If the answer to all is “no,” your company too could spend years and millions of dollars getting nowhere.

Tags: , , , | No Comments »