How to become a planning engineer

Last reviewed 16 September 202610 min read

The four entry routes, what the week actually looks like, and what gets tested at interview

🟩 In one line A planning engineer builds and maintains the programme that says when things will happen, reports what is actually happening against it, and explains the difference in a way people can act on. The job is not driving Primavera — it is knowing enough about how buildings get built to tell whether a date is true, and being willing to say so early.

👤 Who this is for Site engineers and graduates considering the move. QSs and document controllers wondering whether their background transfers. Anyone three months into a first planning role who suspects they are doing it wrong.

e / c

First, let's be honest about why this page exists

Because most advice about becoming a planner is advice about learning software, and software is the smallest part of the job.

Two weeks makes you functional in P6. A year makes you fluent. Neither makes you a planner, because the thing being tested is not whether you can build a network — it is whether the dates in it are true. That judgement comes from knowing how work actually goes together, and there is no course for it.

The second honest point: a large share of the week is spent chasing information from people who have no incentive to give it to you. Nobody mentions this at the interview. The programme's credibility depends more on your relationships with the section engineers than on anything in the file, and a planner who is good at P6 and bad at people produces a beautiful schedule nobody believes.

So this page spends most of its length on the two things that are actually hard: getting in without a planning title, and the first ninety days once you have one.

🟨 The standard — what "good" looks like

A competent planning engineer produces a programme that is logically complete (no open ends, no unexplained constraints), achievable (durations traceable to quantities and crews), maintained (statused on a fixed cycle from real progress) and explained (a narrative that says what moved, why, and what it costs the end date).

Those four words are, in practice, the job description. Everything else is detail.

Source	What it defines
AACE RP 11R-88, Required Skills and Knowledge of Cost Engineering	The competency areas expected of planning and scheduling practitioners — the closest thing to a formal job specification
PMI Practice Standard for Scheduling, 3rd ed.	The scope of scheduling as a defined discipline, and the components a schedule model must contain
AACE RP 37R-06, Schedule Levels of Detail	The range of output a planner produces, from level 1 executive summary to level 4/5 working detail
GAO-16-89G, Schedule Assessment Guide	Ten best practices for a reliable schedule — a practical statement of what the role has to deliver

🟢 Rule: get site time before you get a planning title. Six months watching sequences fail is worth more than a year of software training, and the credibility it buys with foremen is what makes a programme achievable rather than theoretical. If you cannot get site time, get as close to production as the organisation allows.

How it actually works

The four realistic entry routes

Route	Typical background	What you bring	What you have to learn
Site engineer → planner	2–4 years on site, engineering degree	Knows how work actually sequences	CPM theory, P6, reporting
Graduate direct entry	Civil, mechanical or construction management degree	Analytical ability, no bad habits	Everything about construction reality
QS → planner	Commercial background	Quantities, contracts, claims literacy	Logic, sequencing, software
Document control / project support	Administrative route into controls	Systems, discipline, reporting	Technical foundation

The site engineer route produces the strongest planners, consistently. The reason is simple: they have watched a sequence fail. Somebody who has stood on a slab waiting for a crane that was committed elsewhere does not write a programme assuming two gangs can share one crane.

The uncomfortable truth about entry. Most people get their first planning role by doing planning work in a job that was not a planning job — building the look-ahead nobody else wanted to build, taking over the progress report, keeping the two-week programme for their section. Do the work first, then apply for the title. An interviewer with two candidates, one certified and one who has been quietly producing the section look-ahead for eight months, hires the second.

What the week actually looks like

Collect progress against the same activity list, every period, from people who would rather be doing something else.
Status the programme — actuals in, remaining durations updated, reschedule once. The discipline is on statusing a schedule.
Analyse what moved — the driving path, float on the near-critical paths, missed activities, and why.
Write the narrative. The part most planners do worst and the part that gets read.
Produce look-aheads for site, usually three to six weeks, in a format foremen will actually use.
Answer the Consultant's comments on last month's submission.
Flag what is coming — the only part of the job that changes outcomes rather than recording them.

The skills, in order of how much they matter

Construction knowledge. How the work goes together, what precedes what, how long things really take. Not learnable from a manual.
CPM fundamentals. Forward and backward pass, float, the driving path, logic and open ends. The theory is small and worth knowing properly.
Quantities and productivity. Where a duration comes from and how to defend it — see how to justify a duration.
Primavera P6. Setup, coding, updating, reporting, baselines. Two weeks to be functional, a year to be fluent.
Excel. More of the job than anyone admits. Lookups, pivots, clean data handling.
Written English. The narrative, the delay notice, the response to comments. Weak writing caps a planning career earlier than weak technical skill.
Contract literacy. Enough to know what a notice period is and why the programme clause matters.
Reporting and visualisation. Power BI and similar are increasingly expected on larger projects.

The first ninety days in a new role

Read the contract's programme clause and the delay notice provisions. Before anything else.
Run a health check on the current programme and understand every failure before commenting on any of them.
Establish which revision is the baseline and what its approval status actually is — see baseline approval and control.
Walk the site. Compare what you see with what the programme says.
Meet every section engineer and subcontractor planner individually.
Change nothing structural in the first month. Understand why it is the way it is first.

🟥 Where people go wrong

1. Arriving and immediately restructuring the programme. The fastest way to lose credibility in a new planning role. Whatever is wrong with it, somebody built it for a reason, and that reason is usually a constraint you haven't found yet.

2. Reporting a problem before verifying it. The second fastest. Check twice, then say it plainly and early. A planner who cries wolf once gets ignored for a year.

3. Learning P6 instead of learning construction. The software is the easy part and it shows. A planner who can build a 4,000-activity network but cannot tell you why blockwork can't follow the slab pour by two days is not useful.

4. Treating progress collection as data entry. It is the relationship part of the job. The section engineer who trusts you gives you real numbers; the one who doesn't gives you last month's plus ten percent.

5. Writing narratives nobody reads. Three pages of prose describing what every activity did. The narrative should say what moved on the driving path, why, what it costs completion, and what is being done. Four things. Half a page.

6. Waiting for the planning title before doing planning work. The order is the other way round, every time.

7. Avoiding the uncomfortable conversation. The whole value of the role is telling people a date is not achievable while there is still time to act. A planner who only reports what has already happened is a historian.

⚖️ When you're challenged

"You've never worked on site — how can you plan this?" "That's a fair limitation and I'm fixing it. I walk the areas I'm planning every week and I build durations with the section engineers rather than from a rate book. If you think a sequence is wrong, tell me and I'll change it — I'd rather be corrected now than at month nine."

"The programme says we're fine and the site is clearly behind." "Then one of three things is true: the data date is stale, the actuals haven't been entered properly, or someone has changed logic since the last submission. I'll check all three today and come back with which." That is also the answer interviewers are looking for when they ask this as a scenario question.

"Can you just make the programme show the contract date?" "I can show the contract date if we change something real — sequence, resource, or scope. I can't show it by shortening durations that nothing supports, because that becomes the baseline we're measured against for three years."

"Why do you need so much information from my section?" "Because the alternative is that I estimate it, and then the report has your section's progress wrong and you get asked about it in the meeting. Ten minutes a week from you and the number is yours rather than mine."

"What makes you different from the last planner?" "I'll tell you a date is at risk while there's still time to do something about it, in writing, with the arithmetic attached. That's the whole job."

📄 Related pages

Planning engineer career path — where the role goes next, and what gates each step
PMI-SP vs AACE PSP — the certifications, and whether either is worth it yet
Statusing a schedule — the monthly discipline the job is built around
Justify a duration — where a date comes from, and how to defend it
Total float, free float and negative float — asked at almost every interview
Open ends — the other thing asked at almost every interview
Schedule narrative — the skill that separates senior from mid-level

✏️ Worked example — the interview

Four categories come up. Prepare the first two properly and you are ahead of most candidates.

1. Technical. Expect three or four of these, and expect follow-ups:

Question	What they're testing
What is total float, and how does it differ from free float?	Whether you know float is shared along a chain
What is an open end and why does it matter?	Whether you understand high float is usually a defect
Critical path or longest path — what's the difference?	Whether you've hit multiple calendars in practice
What does a lag hide?	Whether you've inherited somebody else's bad programme
Retained logic or progress override — which, and why?	Whether you check scheduling options before rescheduling

Every one of those is a page on this site.

2. Practical scenario. The standard one: "The programme shows completion on time and the site is visibly behind. What do you check first?"

The expected answer has three parts, in order: the data date (is it current?), the statusing (have actuals and remaining durations really been entered, or just percent complete?), and whether the logic has been changed since the last submission without a record. A candidate who says "I'd run a schedule comparison against last month's file" has answered it well.

3. Software. Often a live exercise — build a small network, apply calendars, status it, produce a look-ahead. Setup speed matters less than whether you open Tools → Schedule → Options before you press F9. Say what you're checking and why while you do it.

4. Behavioural. Two questions, one of which is the real one:

"How do you get progress out of a section engineer who won't respond?" — tests whether you understand the chasing part of the job.
"How do you tell a project manager the date is not achievable?" — this is the real question. The honest answer is the right one: early, in writing, with the arithmetic attached, and with options rather than only a problem.

What to bring. One programme you built, printed or on a laptop, with the client's name removed. One health check you ran on it. One narrative you wrote. Almost nobody does this, and it changes the conversation from hypothetical to concrete within five minutes.

📖 References

AACE International RP 11R-88, Required Skills and Knowledge of Cost Engineering — competency areas expected of planning and scheduling practitioners
PMI, Practice Standard for Scheduling, 3rd ed. (2019) — the scope of scheduling as a defined discipline
AACE International RP 37R-06, Schedule Levels of Detail — As Applied in Engineering, Procurement and Construction — the range of output the role produces
US GAO, Schedule Assessment Guide (GAO-16-89G, 2015) — what a competent schedule looks like, which is a practical statement of what the role has to deliver

From the field

Notes, corrections and additions from people who've done this on a real job. Everything is checked before it appears here.

Loading notes…

Checked before it appears. No client, project or employer names. Your name is shown; your email never is. Terms.