The Art of Project Management

2.3. What schedules look like

There is one basic rule of thumb for all schedules: the rule of thirds. It's an extremely rough estimation and back-of-the-envelope kind of thing, but it's the simplest way to approach and understand schedules. If you are experienced with scheduling, prepare to cringe—I'm going to oversimplify the entire process. I'm doing this to provide the simplest footing possible to talk about what tends to go wrong, why this happens, and what can be done about it.

Here's how the ultrasimplified model for scheduling works: for any project, break the available time into three parts—one for design, one for implementation, and one for testing. Depending on the methodologies you use, these phases will be called different things, or they may overlap with each other in certain ways, but all methodologies have time dedicated to these three activities. On any given day, you're either figuring out what should be done (designing), actually doing it (implementing production code), or verifying, analyzing, and refining what's been done (testing).

2.3.1. Applying the rule of thirds

As the general rule goes, for every day you expect to write production code, a day should have been spent planning and designing the work, and a day should be planned to test and refine that work (see Figure 2-1). It's the simplest thing in the world, and it's an easy way to examine any existing schedule or to start a new one from scratch. If the total amount of time isn't roughly divided into ...