Developing a Schedule: More Than Putting Dates Against Tasks
Ask where a date came from and you learn most of what you need to know about a plan. On a schedule that was developed, the answer is a chain: this activity takes eleven days because of how the last three like it went, it cannot start until the environment is available, and the environment is available on the fourteenth. On a schedule that was typed, the answer is that the date works, which is another way of saying somebody arranged the numbers to arrive where the sponsor wanted them to arrive.
Developing a schedule is a calculation. The dates are an output, produced from the work, the order it has to happen in, who is available to do it and how long each piece takes. Section 2.3.2 of the PMBOK® Guide Eighth Edition sets out that development as a process with defined inputs, which matters because the inputs are where a plan is either made honest or quietly compromised.
The order the work has to be done in
Four things are established before a date means anything, and they are established in this order because each one depends on the last.
The pieces of work come first, taken from whatever structure holds the scope. Activities that appear in a schedule but nowhere in the scope are either missing from the scope or not really the project's work, and both are worth knowing early.
Sequence follows. What genuinely cannot start until something else finishes, and why: a physical constraint, a contractual gate, a safety requirement, a dependency on another team. The discipline here is separating hard logic from preference. A great deal of what gets drawn as a dependency is somebody's preferred running order, and preferences dressed as constraints remove options you may need later.
Resources come next, with their real availability. Not the assumption that a named specialist exists, but the number of days per month that specialist is actually free once their support duties, their other project and their leave are counted. Duration is a function of that availability as much as of the work itself.
Durations come last, estimated by a method somebody can describe: what similar work took, a rate applied to a quantity, or a considered range with an optimistic, likely and pessimistic figure. A single number produced without a method is a guess, and it will be defended as though it were a measurement.
Only then does the network get calculated, and the calculation produces the dates. The longest path through it sets the completion, and everything else has a measure of float. That is the point where a schedule begins to be useful, because it can now answer what happens if a particular activity slips.
Where the credibility leaks out
Durations set by the target. The most common failure, and the least visible, because the plan still looks like a plan. Somebody has a fixed end date, subtracts the work, and adjusts the durations until the arithmetic closes. Nothing in the file records that testing was shortened from six periods to three, so the plan carries a compression nobody agreed to and nobody can see.
Dependencies drawn for tidiness. Links added so the bars form a clean staircase, or omitted because the connection crosses into another team's plan and is awkward to raise. The first produces false constraints and hides genuine parallel opportunity. The second produces a critical path that is not the real one.
Availability assumed at full time. Plans built as though people work on one project, five days a week, with no support load and no absence. On shared service teams this single assumption accounts for more slippage than any other, and it is the easiest to correct, because the resource managers already know the real figure and are rarely asked.
Three periods of testing that used to be six
A university replaced its admissions system, with a go-live fixed by the clearing cycle, which does not move for anybody. The programme built its plan backwards from that date. Configuration and data migration were estimated properly. Testing was the last block to be placed, and it was placed in the space that remained, which was half of what the test manager had estimated.
The compression was never a decision. No paper recorded that the test window had been halved, no assumption was logged, and the sponsor's pack showed a complete plan finishing on time. The test manager raised it twice in a working meeting and was told the dates were fixed, which was true and unhelpful.
Testing ran to its original estimate, as tests generally do. The system went live having completed roughly two thirds of the planned test coverage, with a defect in the fee calculation that reached three hundred applicants before it was caught, and the recovery consumed the admissions team through the busiest fortnight of their year. The fixed date was met and the cost moved somewhere it was not being counted. Learning to see that pattern early, and to raise it in a way a sponsor can act on, is something Omega's PMP® Exam Preparation gives room to.
What makes a plan believable
It can be explained backwards. Pick any date in it and the owner can say what duration, what dependency and whose availability produced it. Where the answer is that it has always been that date, you have found the part of the plan that will move first.
It shows the consequence of slippage. A schedule that cannot tell you what a five-day delay to one activity does to the end date is a picture of intentions. One that can is a decision tool, and it changes the quality of the conversation with a sponsor, because the discussion becomes about which of two real options to take.
Compression belongs in the open where it is used. Running things in parallel or adding people to shorten a path are legitimate responses, and both carry a cost: rework risk in the first case, and a period of reduced output while new people learn in the second. Recorded with its cost, compression is a decision. Applied silently to make the arithmetic work, it is the mechanism described in the story above.
For a PMP® candidate, the question to put to any scenario that presents a plan is where the dates came from. A description in which the completion date was set first and the work fitted around it is describing a project with a hidden problem, whatever else the situation appears to be about.
On a live project the quickest test takes ten minutes. Take the three longest activities in the plan and ask their owners how the duration was arrived at and what the person doing the work is committed to elsewhere. The answers tell you whether you are holding a schedule or a layout.
Interested in going further?
Building a plan whose dates can be defended, and knowing what to do when a sponsor's date and the calculated date disagree, is one of the more exposed parts of the role. Omega's PMP® Exam Preparation covers sequencing, estimating, network calculation and compression as one connected chain.
The PMBOK® Guide Eighth Edition is the reference for how sequence, resources and duration combine into a calculated schedule.
Ad · Amazon affiliate link.
References
A110: The PMBOK 8 Schedule Performance Domain: What It Really Covers
A111: Dates Are Not a Schedule
A112: Critical Path Explained Without the Mystique
A113: Float Explained: How Much Delay Can You Really Absorb?
A114: Milestones vs Activities: Stop Treating Them as the Same Thing
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
