Schedule Creation: Know The Difference Between A Picture And A Schedule

Schedule Creation/Validation Checklists

Most commercially available scheduling tools support creating what are called “well-formed schedules” in the trade.  These are schedules that can predict project outcomes, monitor project progress, and recalculate task times based on status updates.  Because some organizations use schedules as pretty pictures rather than project management tools, these same commercial tools have what I call “Art Mode,” – which allows users to do pretty much whatever they want to create the pretty picture, unencumbered by validation rules.

The problem is that some project manager’s first exposure to scheduling software is in art mode.  It isn’t that they don’t want to create valuable schedules. They don’t know how. I’ve coached several project managers through this process and finally got smart enough to write down the basic steps to share.  I offer what follows as suggestions for improved scheduling.  What I present stridently, such as “Only use ‘Finish to Start’ relationships,” may offend some experts who are aware of circumstances that occur every other leap year that in rare cases warrant exceptions, but I’m trying to keep the list simple. 

Getting Ready

I’ve been teaching project management for 30 years.  Before they go near a computer to start scheduling, my standard suggestion to project managers is to make sure there is a solid written definition of what you believe you have been asked to do.  Paraphrasing the Cheshire Cat from Alice in Wonderland, “If you don’t know where you’re going, any road will do.”

Assuming a project manager is clear on the desired outcome, I’m a firm believer that none of us are individually clever enough to build a decent task list for a non-trivial project alone.  Even planning a 4-year-old’s birthday party can benefit from a second set of eyes.  Gather people with the skills to do the work and brainstorm all the work they can imagine must be done.  I like to do this with 3×3 Post-its™.  Large enough to capture task ideas and notes, small enough no one gets too grumpy if they have to rewrite them.

Pro tip: When identifying tasks, use verbs and nouns that imply action and output.

“Paint” is a terrible task label.  Are you buying paint, applying paint, choosing paint?

“Paint the chair” suggests the action of painting, and completion criteria would be producing a painted chair.

When a post-it shows up that appears ambiguous, I ask the originator, “How would I know this task was completed successfully?” That usually helps to clarify the intent and sometimes leads to a discussion of other tasks that are being overlooked.

Once we have many tasks on yellow sticky notes, put some butcher paper or flip chart paper on the wall, walk over to the left edge and add a sticky called “Start.” This is the start milestone.  Usually, it is associated with project approval.  All tasks you have identified should come after the start milestone.  This means “build the project schedule” is NOT a task in the project plan. That’s all part of exploring the cost and schedule of a project to support the go/no-go decision that causes the project to start.

Now the project manager walks to the start milestone and asks the team, “If we said ‘Go’ right now, which tasks could start because they are not dependent upon any other tasks?” Put those tasks a few inches to the right of the Start milestone and draw a pencil arrow from the Start milestone to those tasks, confirming that they are not dependent on any other tasks in the plan.  Now go to the tasks just added and repeat the process, “Which tasks can begin once this task has begun?” Be on the lookout for tasks that have multiple predecessors.  Before you can cook the burgers at your BBQ, you need fire AND meat.  The cooking task would have two predecessors.

When all task stickies have been placed (expanding your task network to the right and adding any additional sheets of paper needed to avoid marking on the walls), add a last sticky called “Finish” to represent the finish milestone and end of the project, then draw lines from any tasks that don’t have successors to finish.

Next, walk through the network from start to finish with the team to look for logical consistency, duplicated tasks, and missing tasks.  It is fair to add, delete, split, merge, and modify tasks to better represent what the team believes needs to occur.

When you are done, you should have a valid task network. 

Tests for a Valid Task Network

• There is one Start milestone
• There is one Finish milestone 
• The Start milestone has no predecessors
• The Finish milestone has no successors
• All tasks in the network have at least one predecessor
• All tasks in the network have at least one successor
• All arrows are drawn from one task to another task and mean “When this task is finished the next tasks have what this task contributes to start” (this is called a “Finish to Start” relationship – it is the most common, the easiest to understand, and all that is needed to build a basic schedule.  Until you have sufficient experience to argue the point, always use Finish to Start relationships)

Gather estimates

I’ve written a bunch of articles on estimation.  To keep this short, I’ll assume you have read them or learned about estimation from another source and will reach out to the people who will do the work (if possible) and ask them for their best guess about how long the task will take and the assumptions underlying that guess and document them.  What I will add here as a pro-tip: Choose a granularity scale relevant to your project.  If your project is likely going to take a year, consider having everyone round their initial estimates up to a half-day or full day.  You can refine them later.

Crack Your Knuckles and Build the Preliminary Schedule

Make an assumption about a start date for the project – usually a few days or weeks into the future – and create a Start milestone fixed to that date.  This should be one of the only hard-coded dates in the schedule. The rest should float if you change the start date.

Transcribe your network – Enter the tasks, dependencies, and durations that the team agreed to.  Pro Tip: Schedule all tasks to start as soon as the task logic allows.  This is a good default.  Sometimes there are reasons to defer a task to the last minute, but this adds risk and should be carefully considered.

Review your preliminary schedule with the team before making any changes to it – It can be tempting to start fiddling with dependencies and durations to make the project fit in the box before you consult with the team – don’t do it.  If there are apparent errors or things that need to be re-thought, discuss them with the team to understand how you got from what they created to what you are working with.

Treat optimization and risk management as separate steps and save checkpoint versions of the preliminary schedule as you modify it if you go down a rabbit hole and get lost.  Review the critical path focusing on long-duration tasks and asking appropriate team members whether resources can safely be thrown at the task to speed it up without adding excessive risk.

If the schedule doesn’t meet the project objectives after optimization and risk management, have a conversation with your project sponsor to discuss the challenge – don’t make the mistake of trying to “fit the schedule in the box” in ways that violate the laws of physics.  If it takes one woman nine months to gestate a baby, you can’t get a baby in one month by putting nine women on the task (despite what Microsoft Project will tell you).

Advanced Review Criteria

Avoid “Lags” – When tempted to use a lag (a delay on a dependency arrow), instead add a dummy task that explains what you assume you must wait for.  Rather than “Paint the Chair” being followed by a 48-hour lag to allow the paint to dry before you “Box and Ship Chair,” add a 48-hour task called “Allow 48 hours for Paint on Chair to Dry”.  This makes the rationale visible and may trigger ideas for optimization, such as using faster drying paint or drying the paint with a blow dryer.

Avoid tasks with a duration of more than two weeks or so – Long-duration tasks can often be broken into smaller parts to facilitate optimization and monitoring.  Estimates of long-duration tasks tend to have a more significant margin of error as well.  A good rule of thumb: Don’t have any tasks in your schedule that have a duration longer than you are willing to slip the end date.  This will keep you honest.

Avoid “Leads” – A lead is a negative lag.  Leads are generally sloppy, lazy, illogical, and a terrible idea.  Leads say, “Three days before this task ends, start this other task.”

Avoid fixing dates for other tasks. Pro tip: if you have a meeting that is supposed to occur at a fixed time, create a milestone (a task with duration zero) called “Scheduled time for the XYZ meeting” and fix the milestone’s date, making this a predecessor to your meeting task.  This is better documentation, and if the meeting has other predecessors that slip and cause it to be delayed, it will be more evident to you.  If you schedule the meeting for a certain date, you may not recognize the predecessor isn’t ready.

Ridiculously Advanced Criteria

If you want to become a true scheduling nerd, take a look at the DCMA 14 Point Assessment provided by the Defense Contract Management Agency (DCMA).

 It has everything discussed above, plus some stuff you haven’t thought of yet.  Scheduling nerds debate some of the thresholds, but in general, the 14 points represent solid scheduling practices.

For more information on our Schedule Creation tool, check out Chrono™.