What a schedule is made of.

This is the most common way a good schedule quietly turns into a picture of a schedule. And it comes from not knowing one thing: which fields belong to you, and which belong to the engine.

A schedule isn't a pile of dates. It's a set of components, each with its own rules. This week we open the toolbox.

You type. The engine calculates.

Every field in your schedule is one of two kinds.

Manual fields are inputs. You type them: the duration, the logic links, the calendar, the actual dates from site. These are your judgments about how the job will be built.

Calculated fields are outputs. The engine produces them: early dates, late dates, total float, the critical path flag. They are the answer the model gives you when it runs your inputs through the logic.

Here's the rule, and it's absolute: never type into a calculated field.

The moment you hand-type a finish date, you've overridden the maths. The activity stops responding to its predecessors. Delay something upstream and this activity just sits there, serenely reporting the date you typed. It has been unplugged from reality.

Do that in a dozen places and you no longer have a model. You have a drawing that updates when you drag it.

Don't like the date the engine gives you? Then change an input. Shorten a duration and justify it. Change the logic and defend it. Add resources. Those are honest moves — and they leave a trail. Typing over the answer is not a move. It's a lie with a timestamp.

Actuals beat logic

There's one moment when the engine steps aside — and it's important you understand it.

When you enter an actual start date, the engine stops forecasting that activity's start. Why would it guess? It happened. History beats prediction.

That's exactly right, and it's also a trap. Type an actual date carelessly — the wrong week, a date before its predecessor even finished — and you've now anchored the schedule to something that never happened. The model will believe you. It always believes you.

Actuals are the one place where sloppy data does permanent damage. Get them from the site records, not from memory.

What is a "day", exactly?

Now the component that ruins more schedules than any other — and the one nobody checks.

The calendar.

Ask your schedule to run a ten-day activity. Ten days of what? Ten working days on a five-day week? A six-day week with Sundays off? Seven days straight, because the concrete doesn't care that it's Sunday?

Same work. Same duration. Four days apart on the end date — and the only thing that changed was a dropdown.

Now multiply that across a few hundred activities. Your float is wrong. Your critical path may be running through the wrong chain entirely. And nothing on screen looks broken.

This is why a good model uses different calendars for different work. Concrete curing runs on a 7-day calendar — it cures on Sunday whether you're there or not. Your excavation crew runs on a 6-day calendar. Noisy piling near a hospital may run on a restricted day-shift calendar only. A single project calendar applied to everything is a beginner's tell.

One more, while we're here: don't fake a wait with a lag. A ten-day lag for concrete curing is fine — it's physics, and it belongs to nobody. A ten-day lag for "client review" is not. That's someone's work, and burying it in a link makes it invisible and ownerless. Give it an activity with a name on it.

Not every activity is work

A quick word on the types you'll actually use.

Most of your model is ordinary task activities — real work, real duration, real crews.

Milestones are moments, not work: zero duration, no resources.

And then there's level of effort — the support work that just runs alongside everything else. Site management. The tower crane standing by. Quality supervision. It has duration, but it doesn't drive anything; its length is simply however long the real work takes.

Which brings a rule worth tattooing somewhere: level of effort must never appear on your critical path. If your critical path runs through "site management," your model is telling you that the project finishes when the site manager goes home. It doesn't. Something is wired wrong — go and find it.

Build the core. Then add.

There are over a hundred fields in a tool like P6. You don't need most of them.

Start with the core — durations, logic, calendars, dates, float. Without these there is no schedule. Then add exactly three things, and only if you'll actually use them.

Tracking money? Add the cost and earned-value fields. Tracking crews and plant? Add resources and availability. Tracking uncertainty? Add three-point durations.

If you're not doing one of those, leave those fields alone. A resource field that nobody updates isn't neutral — it's a lie waiting to be believed by whoever opens the file next year.

Your schedule is only ever as honest as the components underneath it. The engine doesn't judge your inputs. It just calculates them, perfectly, and hands you back exactly what you put in.

Practical insight

Open a schedule you've inherited and run four checks.

How many calendars does it use? If the answer is one, ask how concrete cures on a weekend. Are any finish dates hard-typed rather than calculated? Does the critical path run through anything that isn't real work? And do the actual dates match what the site records actually say?

You'll find something in the first ten minutes. You always do.

Key takeaways

✔ Every field is either manual (you type it) or calculated (the engine owns it).
✔ Never type into a calculated field — it unplugs the activity from the logic.
✔ Don't like the answer? Change an input, not the output.
✔ Actual dates override the forecast — so they must come from records, not memory.
✔ The calendar decides what a "day" means; the same work can finish days apart.
✔ Use different calendars for different work — curing is 7-day, crews are not.
✔ Level of effort must never sit on the critical path.
✔ Build the core, then add money, resource or risk fields only if you'll maintain them.

What's coming next

This week we learned what a schedule is made of, and which parts you're allowed to touch.

Next week we connect the model to the work itself — how scope is coded into the schedule, and how that coding lets you measure real performance. It's what turns a network of bars into something that can tell you whether you're actually ahead or behind.

Because a schedule that can't measure progress is just a plan you're hoping comes true.