Developing a Project Schedule That Works

Schedule planning is an iterative process except for very short projects (a few weeks). In Antonio’s case, his customer is developing a new product and his EMS program team must prepare to bring it into production several months from now.

Start with a whiteboard, or pencils and 11×17-inch or A3 paper, not (yet) with your preferred project management software application.

Even if you already have a program team assigned, do the first cut yourself rather than starting your team planning meetings with a blank sheet of paper. Block out major milestones and project stages without any dates, to convey a sense of the sequence. When you have a plausible project sequence, involve your team members to fill in missing tasks and raise challenges you have not yet considered.

Project tasks should be planned at a high level next, with a granularity of about 2-4% of the total schedule. For example, a total schedule running 260 days (a work year of 5-day weeks) might show individual tasks taking 7 to 14 days. As you execute the project, many of those activities will be broken down into shorter work items, but such detail clutters the schedule at initial planning.

After your high level tasks are blocked out, it’s a good time to open up your project management software and enter the tasks, dates, resources, and dependencies. Save a baseline, and when you make changes later, save a new version of the schedule.

A meaningful project schedule should consider two important contributing factors: resources and risk. Resources are the people, skills, equipment, and facility requirements that underpin the schedule. Risks are events or occurrences that could result in delay or cancellation of the project.

The customer has a planned date for design and testing completion, but there is risk in the date whether that risk is stated or not. So start with the planned date; then in the project schedule, document the fact that the date is customer-provided, and identify any known risk factors.

After the task sequence feels right, take the customer’s wish date for completion and pull it in by 10-15% of the duration, as a trial. (In our hypothetical one-year project, that’s about 5 to 8 weeks.) Why compress the schedule like this? A couple of reasons. It focuses attention on the activity durations, to make sure they are doable. It shows where resource assumptions need to be re-thought, and it puts some emphasis on project risks. You can’t plan for a risk you don’t see coming.

Most likely, the compressed schedule will not work; however, it will give you a sense of whether the wish date is workable or a pipe dream, and lead you to a schedule you can commit to, and defend to your managers or PMO and to your customer.

Coincident with the customer’s completion date, be sure to include a Readiness Review, a formal review meeting with customer, project team, and functional expert participation to thoroughly understand what work has been completed, that all required environmental and regulatory tests have passed, and especially if any critical items remain open.

Lastly, for each milestone in the program, take some time to consider and document the “One Big Thing” which, if it occurred, would cause you as PM to stop and reassess the project continuation. Examples could be a competitor’s early product launch, unexpected DVT or validation test failures, or a regulatory change that would require redesign for compliance. Thinking about these risks ahead of time helps you keep your “PM Radar” tuned to the environment in which your project operates, and increases the likelihood that you will perceive any major risk event early enough to mitigate it effectively.

With this, I wished Antonio good luck, and asked him to stay in touch as his program progresses.