Then you go back to the actual project.

I use AI in my work. I want to be specific about what that looks like, because the specific version is more useful than the general one and the general one is mostly what gets written about.

The things it does well are real but unglamorous. Meeting notes turned into a clean memo in ten minutes instead of forty-five. A status update rewritten three ways so the version that goes to the client says something different from the version that goes to the internal team, without me having to draft both from scratch. A technical document template that would have taken an afternoon to structure from a blank page built in twenty minutes, ready to fill. These are not small things. Time is the resource I run out of first, and AI gives some of it back on the work that was always straightforward but always took longer than it should have.

That’s the honest version of transformation. Not a new kind of project management. The same project management, with some of the friction removed from the parts that were never really the job.

Here is where it stops.

A supplier misses a delivery. The original plan assumed that part would be on site by Monday. It is Wednesday and it isn’t coming. Someone has to decide:

1. Do you hold the dependent work and absorb the delay.

2. Do you find a workaround that costs more and carries its own risks.

3. Do you go back to the client and have a conversation nobody wants to have.

That decision involves the supplier relationship, the client’s tolerance, the downstream knock-on to three other workstreams, and the judgement call about which risk is actually smaller. It involves knowing which client stakeholder will be angrier about the delay versus the cost overrun, and what they said in a meeting six weeks ago that tells you something about how they’ll respond.

No tool has sat in those meetings. No tool knows what that stakeholder said. No tool carries the consequence of getting it wrong.

I asked AI to help me with a situation like this once. It gave me a structured framework for supplier delay management. The framework was correct. It was also completely useless for the specific decision I was standing in front of, because the specific decision required everything the tool didn’t have: context, history, the political texture of the room, and the willingness to own the outcome.

This is the boundary, and it’s worth naming clearly. AI handles the parts of the job that were already well-defined. The work that was always about turning a clear input into a formatted output. It does not handle the parts that were never well-defined, the ones where the input is ambiguous, the stakeholders are in conflict, and someone has to make a call and put their name on it.

The job of a project manager is mostly the second kind of work. That’s the job. Not the documentation, not the templates, not the memos, even though those things matter. The job is the room where nobody agrees and a decision has to come out of it anyway.

What that means for the role is not what the anxious version of this conversation suggests. AI is not replacing the judgment. It is, slowly and usefully, clearing the surface of the job so the judgment is what’s left. Less time on the memo. More time on the decision the memo is about. That’s not a threat to the role. It’s a clarification of what the role always was underneath the paperwork.

The practitioners who will do well with these tools are the ones who use them to buy back time for the work that matters and don’t mistake the output for the thinking. The memo is faster now. The thinking behind it is still entirely manual and it always will be.

That’s fine. The thinking is the part worth doing.

I run projects, and I can tell you the plan is maybe a fifth of the job. The rest is crisis. Lately it’s more than a fifth.

By crisis I don’t mean drama. I mean the steady arrival of things the plan didn’t account for. A part that was meant to ship doesn’t. A test that was meant to pass doesn’t. Someone holding half the knowledge in their head is suddenly unavailable. A decision made three months ago turns out to have been wrong, and the cost of it lands today, on your desk, with your name on it. None of that is in the chart. All of it is the job.

The work I care about puts software and control systems into industrial assets, the kind where a bad release isn’t an inconvenience, it’s a physical event. Something stops working in a place where people are working. That changes how a delay feels. A slipped deadline on a marketing campaign is a missed deadline. A slipped deadline on a system that something heavy and dangerous depends on is a real question: do you ship the not-quite-finished thing, or hold the line and absorb the cost of waiting. You make that call often, with incomplete information, usually before lunch.

So I’ve stopped thinking of myself as a project manager and started thinking of myself as a crisis manager who happens to keep a schedule. The schedule still matters. It’s the thing I protect, not the thing I do. What I actually do all day is triage. What’s on fire, what looks like it’s on fire but isn’t, what isn’t on fire yet but will be by Thursday if nobody touches it. The plan is the map. The job is everything happening to the territory.

And the territory is not holding still right now. This is the part that has changed. For a long time you could treat the wider environment as background, stable enough to plan against. You can’t at the moment. Supply chains move under you. Costs move under you. Whole regions get harder or easier to operate in for reasons that have nothing to do with your project and everything to do with it. Anyone delivering work into this part of the world right now is feeling it. I’m not going to pretend to clear opinions about the events behind that, and this isn’t the place for them. The operational point is simple, and it isn’t political: the assumption that the world will sit still long enough for your plan to play out is no longer safe. Maybe it never was. It’s just harder to pretend now.

If you don’t run projects, this still lands, because it’s really about plans. A plan is a story you tell about the future. It’s useful right up until the future declines to cooperate, and then its only remaining value is as a baseline, a fixed line you measure the chaos against, so you can see how far you’ve drifted and decide what to do about it. The people who are good at delivering are not the ones whose plans survive. They’re the ones who spot the drift early and act on it without flinching.

So I’ve made a kind of peace with it. I don’t expect the plan to hold. I expect to spend most of my week managing the distance between the plan and the day. That isn’t the job going wrong. That, it turns out, is the job.

Imagine a recruiter who has ninety seconds with your profile. They are not going to read your role descriptions. They are going to read your titles, your employers, your tenure at each, and the shape of the trajectory those things draw. That’s it. That’s the read most of your profile gets, most of the time.

Now ask: what does that ninety-second read conclude about you? What level does it put you at? What does it think you do? And — the harder question — how far is that conclusion from what you actually did?

For some people the gap is small. Their titles tracked their work, their trajectory reads cleanly, the ninety-second version and the real version are close. For a lot of practitioners with non-linear careers, cross-disciplinary work, or roles that outgrew their titles, the gap is wide. The ninety-second read concludes something meaningfully smaller than the truth. This post is for the people in the second group.

There are a few specific patterns that produce a damaging ninety-second read. Worth checking your own record against each.

The first is the lagging title. Where your scope expanded but the title didn’t follow. You took over a larger portfolio, absorbed a function, started carrying responsibilities a level up, and the title stayed where it was for a year or more. The work was senior; the title says it wasn’t.

The second is the contract-title artefact i.e. where the title on your record was set for reasons that had nothing to do with the work. Tax structure, legal classification, a company’s internal banding. The title is administratively accurate and descriptively false, and a recruiter reading it fast has no way to know which.

The third is the small-employer translation problem, you held a title at a smaller organisation that doesn’t translate cleanly to how larger organisations use the same word. “Project Manager” at a ten-person firm and “Project Manager” at a multinational can describe very different scopes. The ninety-second read benchmarks against the reader’s frame, not yours.

The fourth is the title-down industry; you worked in a sector that systematically titles roles lower than equivalent work is titled elsewhere. Engineering does this. The title accurately reflects the industry’s convention and undersells the work to anyone outside that convention.

If one or more of these describes your record, the ninety-second read of your profile is working against you, and it’s worth knowing that clearly rather than vaguely.

Some of this is addressable. Not by lying, but by translating.

The role description is yours to write. The title is fixed, but the bullets underneath it are where the actual work gets described, and most practitioners under-write them. They list responsibilities in the language their old company used internally, which is often narrower and more modest than the work deserves. Rewriting role descriptions in clear, externally-legible language — what you actually owned, what scale, what outcomes — is the single highest-leverage thing most people can do. It doesn’t change the title. It changes what the reader finds when the title earns a second look.

The framing of the trajectory is also yours. A career that looks scattered at title resolution often has a coherent through-line at work resolution, a consistent kind of problem you’ve been solving, a capability that compounded across roles even as the titles varied. Naming that through-line, explicitly, gives the reader a frame that the titles alone don’t provide.

And the language you use about your own work, in conversations and cover letters and interviews, is yours to calibrate. Most practitioners describe their work in the register of their most modest title. Describing it in the register of the actual work — without inflation, just accuracy — is allowed, and most people don’t do it.

It’s worth being honest about the limits, because pretending everything is fixable is its own kind of unhelpful.

Past titles are past titles. You cannot retroactively rewrite what your contract said in 2021. The lagging title, the contract artefact, those are part of your record now, and the most you can do is contextualise them, not erase them.

Market evaluation postures won’t shift to suit you. If a market reads credentials skeptically or weights titles heavily, that’s the market’s framework, and one practitioner translating their CV well doesn’t change it. You can navigate the framework. You can’t reform it from inside a job application.

And the ninety-second read itself isn’t going away. Fast triage is structural — it exists because the volume of hiring demands it. You can make your ninety-second read better. You can’t make recruiters stop doing ninety-second reads.

The honest position is that you have real agency over how your record is written and described, and very little agency over the systems that read it. Most of the useful work is on the first part, because it’s the only part you control.

There’s a harder discipline underneath all of this, and it’s not a CV-editing trick.

The fixable problems are mostly retrospective by better describing work you’ve already done. The deeper move is prospective: choosing roles, going forward, where the title and the work will match. Where you don’t accept a title two levels below the responsibility because the salary is right and the title can “come later.” Where you weigh, as part of evaluating any role, whether the title it carries will read accurately to the next reader, in the next market, in three years.

This is slower and it requires turning down some things that look fine in the moment. But it’s the only move that stops the gap from compounding. The retrospective fixes manage a problem you already have. The prospective discipline is what prevents you from having it again.

The market reads you fast, and it reads you through artefacts that don't always tell the truth about the work. You can't change that it reads fast. You can change what it finds when it does. That's a smaller lever than you'd want, but a real one, and it's the one in your hand.

It rarely arrives as an accusation. Nobody says “I don’t believe your credential.” What arrives instead is a particular texture of question. Walk me through how you qualified for the hours. What was your actual role on that project? Who did you report to? What was the project value? Each question is reasonable in isolation — a diligent recruiter should ask some of these. It’s the accumulation that reveals the underlying posture. The questions aren’t gathering information. They’re testing a claim the recruiter has already decided to be skeptical of.

This is a different problem from the one in the last post. The title-counting problem is about a system that reads fast and misses depth. The validity problem is about a system that reads your evidence and decides, before you’ve had a chance to respond, that the evidence might not be trustworthy.

The skepticism isn’t irrational, and it’s worth being honest about where it comes from before treating it as purely a problem.

Credentials in project management are genuinely variable in what they represent. The PMP requires logged hours, but the hours are self-reported and audited only at random. Two people with the same credential can have arrived there through very different actual experience. A recruiter who has interviewed enough credential-holders has learned, correctly, that the credential alone doesn’t tell them much. Some skepticism is just accumulated experience.

There’s also a market-history component. In regions that went through rapid professionalisation, where PM as a formal discipline arrived relatively recently and credential-holding expanded quickly, there’s a memory of credentials being acquired faster than competence. The skepticism is a response to a real pattern from a particular period. It’s a generation of hiring behaviour shaped by having been burned.

And there’s a verification problem. A recruiter looking at a credential from an unfamiliar issuing body, obtained in an unfamiliar market, attached to an unfamiliar employer, has genuinely limited ability to assess it. Skepticism, in that situation, is a rational response to low information. It’s not fair to the candidate, but it’s not malicious either.

None of this makes the experience of being doubted any better. But it matters for the diagnosis: credential skepticism isn’t usually personal, and it isn’t usually about you specifically. It’s a posture the recruiter brought to the conversation before you arrived.

The skepticism shapes the conversation in ways that are hard to push back against, precisely because it never declares itself.

The questions come in a sequence designed to find the gap. Not the gap in your knowledge — the gap in your story. The recruiter is looking for the inconsistency that would confirm the doubt: the role that doesn’t quite match the title, the project value that seems high for the responsibility described, the hours that don’t add up against the timeline. They’re not trying to understand your experience. They’re trying to find the seam.

If they don’t find a seam, the skepticism doesn’t usually resolve into belief. It resolves into a kind of suspended judgement — the candidate wasn’t disproven, but wasn’t trusted either. The conversation ends politely and the candidate is filed somewhere below the candidates who didn’t trigger the doubt in the first place.

And here’s the part that makes it genuinely hard to navigate: you usually can’t tell it’s happening. The recruiter who undercounts your titles tells you their conclusion — “two years tops.” The recruiter who doubts your validity doesn’t tell you anything. They just ask their questions, thank you for your time, and don’t move you forward. The skepticism is invisible from your side of the table. You can’t address a doubt that was never spoken.

A practitioner who triggers validity skepticism is starting every relevant interaction from a deficit, and paying for it in a currency they can’t see.

The visible cost is the conversations that don’t progress. But the deeper cost is structural. A candidate being evaluated from a baseline of trust gets the benefit of the doubt on ambiguous parts of their record, and the recruiter fills the gaps with reasonable assumptions. A candidate being evaluated from a baseline of skepticism gets the opposite: the ambiguous parts get filled with doubt. Same record, same evidence, two different readings, and the practitioner doesn’t choose which reading they get. The market does, often before the conversation starts.

There’s also a confidence cost that’s worth naming, because it compounds. A practitioner who has been doubted enough times starts pre-defending. They over-explain their credentials before being asked. They volunteer the project values and the reporting lines unprompted. The pre-defence is a rational response to having been doubted before — but it reads, to a fresh recruiter, as someone who expects not to be believed, which itself becomes a small reason for doubt. The skepticism, once it’s been experienced enough, becomes partly self-sustaining.

The same practitioner, with the same credentials and the same record, triggers different amounts of this depending on where they’re being evaluated.

In markets where credential skepticism is low — where the issuing bodies are familiar, the credential is common, the verification infrastructure is trusted — the practitioner is read from a baseline of acceptance. The credential does what the credential is supposed to do: it establishes a floor, and the conversation moves on to the work.

In markets where credential skepticism is high — for the historical and structural reasons described earlier — the same practitioner spends the first part of every conversation establishing that their floor is real. They don’t get to start from the floor. They have to build it, in front of the recruiter, every time.

This is the structural unfairness the arc has been circling. It isn’t that one practitioner is better than another. It’s that the same practitioner is read as more or less credible depending entirely on which market’s evaluation posture they happen to be standing inside. The practitioner didn’t change. The reading did. And the practitioner usually can’t choose the reading — they can only choose, over a longer horizon, which markets they spend their time being read by.

The recruiter in the last post was wrong about what the evidence meant. The recruiters in this one aren't sure the evidence is real. Different doubts, same result: the practitioner gets read at a discount they didn't earn and can't see. The next post turns the question around — not what the market does to you, but what you can actually see about your own record, and what you can do with it.

Subscribe now

That was the message. Not a question. A summary, delivered with some confidence, in a tone that didn’t really invite negotiation. He’d done the read, the read had produced a number, and the number disqualified me from whatever role he was filling.

The number was wrong, and I’ll get to why. But I want to start with what was right about it, because the most useful thing about this encounter wasn’t that the recruiter was wrong. It was the way he reached his conclusion.

If you scan my LinkedIn at title resolution, the way fast-triage hiring asks recruiters to scan profiles, you don’t see “Project Manager” anywhere prominently. You see Technical Project Manager. You see Project Engineer. You see Team Lead and Team Coordinator across earlier roles. You see freelance work that’s titled by deliverable rather than by role and you see a PMP certification.

A recruiter under time pressure, scanning that for the keyword “Project Manager,” sees the phrase appear in two places, both qualified. The functional designation. The Project Engineer designation, which reads as junior. The other roles, depending on how aggressively you read titles, may or may not register as PM at all. If the recruiter is sourcing for a senior PM role and scanning for unambiguous senior PM titles, my profile fails the scan.

His “two years tops” reading was a count of how much unambiguously-titled PM work appears at title resolution. By that count, the number isn’t far off. The earlier roles, at title resolution, don’t read cleanly as PM. So his read of the profile, as a fast-triage scan, was internally consistent. He was doing what fast-triage hiring asks recruiters to do.

He was also wrong about what the profile actually showed.

What’s underneath the titles, in the bullet points, is a different career.

The Technical Project Manager role describes managing concurrent T&M programmes for international clients, owning the risk register, holding sign-off authority for software releases to active offshore drilling assets, conducting peer review across six engineering disciplines, and recovering a project that was four months behind schedule. The Project Engineer role describes acting as interim team lead, conducting backlog reviews and KPI tracking, attending FAT events as primary engineer, and leading hardware delivery on automation programmes. The Team Lead and Team Coordinator roles describe scoped management responsibilities that, in another company’s titling system, would have been titled differently.

That’s PM work. That’s PM work that, summed across the roles, runs to substantially more than two years. But none of it appears at title resolution. All of it appears in the bullets the recruiter didn’t read.

This isn’t unique to my profile. Practitioners with cross-disciplinary careers, growth-faster-than-promotion careers, and careers in industries that title down all face the same gap. The work is in the bullets; the titles describe something narrower; the recruiter scans titles and reaches a conclusion that doesn’t match the work.

The encounter isn’t really about me, or about this specific recruiter. The point of writing about it is what it shows about the system around it.

A system where recruiters under time pressure scan titles produces conclusions that the underlying work doesn’t support. This isn’t a failure of any individual recruiter — it’s a structural feature of fast-triage hiring. The system asks recruiters to screen 200 profiles for one role. The math doesn’t allow careful reading. Recruiters who read carefully are slower than recruiters who scan, and slower recruiters get fewer shortlists, and fewer shortlists is what their employer’s metrics punish.

The system has internal logic. It’s defensible from inside the system. From outside the system or from the practitioner’s side, it produces a particular kind of injustice: practitioners whose titles compress their work poorly get systematically undercounted, year after year, for reasons that have nothing to do with how good they are at the work.

This is the structural pattern the previous posts in this series have been pointing at. Credentials are read fast, often by people without context to interpret them. Titles are read fast, often by people who don’t have time to look beneath them. Markets apply different evaluation frameworks. Recruiters scan rather than read. Each layer compresses the practitioner differently. By the time the conclusions reach the hiring manager, the practitioner has been translated through three or four lossy filters, and the version of them that arrives may not resemble the practitioner at all.

The two-years-tops conclusion is one instance. The system produces these conclusions every day, for thousands of practitioners, and most of them never see the conclusion that was reached about them. Most of them just don’t get the call.

I replied to the message. I described what was actually in the role descriptions, summarised the cross-functional work, mentioned the schedule recovery story briefly. The recruiter read the reply and didn’t change his read of the profile. The role he was sourcing wasn’t filled by me.

I’m not telling that part to complain about the outcome. I’m telling it because the outcome is the most important part of the encounter. Even after I’d explained the gap between titles and work, the read didn’t update. The system that produced the original conclusion was strong enough to maintain it through clarification.

This is what makes title-scanning a structural problem rather than an individual one. It isn’t fixed by the practitioner explaining themselves. The system processes profiles too fast for that explanation to land. The conclusion was reached in the first ninety seconds of scanning the profile, and the next ninety seconds of explanation didn’t dislodge it.

The recruiter wasn't wrong about what my LinkedIn said. He was wrong about what it meant. That's the gap, and it isn't getting smaller.

In one market, the CV reads as a strong senior candidate with deep technical depth, deserving of a programme management role at the top of the salary band. In another market, the same CV reads as mid-career, with a credential that needs explaining and a title trajectory that doesn’t quite fit the local expectations. In a third market, the CV reads as overqualified for some roles and underqualified for others, depending on which industries the recruiter is hiring for.

This is not market inefficiency. It’s three markets that have built different evaluation frameworks around different assumptions about what project management is, what credentials prove, and what counts as relevant experience. The frameworks aren’t wrong. They reflect what each market actually values. But the same practitioner will be read at three different levels by them, and the practitioner needs to understand which framework they’re being read by to navigate any of them.

What gets weighted in Western European markets — particularly Germanic, Nordic, and to a lesser extent the Netherlands and Belgium — is technical depth and evidence of cross-functional integration.

A candidate applying for a senior PM role in Germany or Denmark is being evaluated on whether they can speak credibly to engineers about engineering, to commercial teams about commercial, and to clients about both. The evaluation is depth-first. A PM who has done five years of generalist work across six industries reads, in this market, as less senior than a PM who has done four years of deep work in one industry. Specialisation isn’t a weakness; it’s what defines seniority.

Credentials matter, but they don’t dominate. PMP is recognised, Prince2 is recognised, IPMA is often preferred locally. None of them is decisive. What’s decisive is the evidence in the role descriptions: what was actually delivered, with what scope, in what kind of organisation. The reader spends more time on the bullet points than on the title. The body of the CV does more work than the header.

Title trajectory matters less in this market than in others. A practitioner who held the same title for four years while their scope tripled is read as someone who delivered, not as someone who didn’t get promoted. The work is the signal. The title is administrative.

This is the most forgiving market for practitioners with non-linear careers, and it’s the most punishing market for practitioners whose CVs are heavy on credentials but light on substance. The mismatch goes the opposite way from most other markets.

What gets weighted in MENA markets — particularly the GCC states, with the UAE and Saudi Arabia as the largest by hiring volume — is a different combination: brand-name employers, GCC track record, credentials in good standing, and the ability to operate within the region’s specific business culture.

The brand-name component is unusually strong. A candidate who has worked for ADNOC, Saudi Aramco, Petrofac, Worley, McDermott, or any of the recognised regional employers reads with a halo that practitioners from outside the region don’t get, regardless of the underlying work. The market trusts the screen these employers have already applied. A candidate who hasn’t been through that screen has to prove competence the regional employers would have proven for them.

Credentials matter more in MENA than in Western Europe, partly because PMP and Prince2 function as portable signals across a market with high turnover and a lot of cross-border movement. A candidate without one of the major credentials is starting from a deficit. With one, they have a baseline that recruiters and hiring managers across the region recognise consistently.

GCC track record matters separately. A candidate with five years of work in the region reads differently from a candidate with five years of comparable work elsewhere, even if the work itself is identical. The local track record signals that the candidate has navigated the region’s specific business culture, its expectations around hierarchy, its regulatory environment, its operating tempo. Without it, the candidate has to demonstrate, often against scepticism, that they can do this.

The cumulative effect: candidates from outside the region have to overcome a higher initial bar than candidates from inside it, but once over the bar, the market reads them as senior with relatively less ambiguity than other markets. The evaluation is binary in a way that Western Europe’s isn’t.

What gets weighted in CEE markets — Romania, Poland, Hungary, the Czech Republic, and the broader region — is title and tenure, often more strongly than the work itself.

This is partly a function of how local hiring has historically operated. Western multinationals hiring into CEE have, for years, used title as a proxy for seniority because the volume of hiring required fast triage and titles were the fastest signal. Local firms inherited the pattern. The result is a market where the title on your most recent CV does disproportionate work in determining what roles you’re considered for.

Tenure compounds this. A practitioner with seven years at one employer reads as more senior than a practitioner with seven years across three employers, even if the second practitioner’s scope and responsibilities have grown faster. Stability is read as competence; mobility is read as instability. This is changing slowly, particularly in tech-influenced sectors, but the pattern is still dominant in industrial, engineering, and traditional corporate hiring.

Credential scepticism is a feature of this market in a way it isn’t in others. A candidate with PMP, particularly one who obtained it relatively recently or while at a non-Western employer, can encounter recruiters and hiring managers who treat the credential as something that needs verification rather than something that confers it. How did you qualify for the hours? What was your role? Walk me through your project values. The questions are reasonable in isolation. Their accumulation reveals a starting position of scepticism rather than recognition.

I want to be careful with this section, because the description risks sounding like a critique of CEE markets specifically, and that isn’t the point. Every market has its own evaluation framework, and CEE’s framework is internally coherent. It’s adapted to a market with high credential variability, fast turnover during the post-2000s growth period, and relatively recent professionalisation of PM as a discipline. The framework makes sense given its history. It just produces different reads of the same candidate than other markets do, and practitioners working in or being recruited from CEE markets need to understand the framework to navigate it.

Most practitioners do nothing. They get read as the market they’re in reads them, and they accept the resulting roles, salaries, and trajectories.

The practitioners who navigate this well do something specific: they translate themselves into each market’s evaluation framework. Different CV emphasis for different markets. Different LinkedIn framing depending on which audience is most likely to read the profile. Different language about the same work: emphasising depth and integration for Western European audiences, emphasising employer brand and credentials for MENA audiences, emphasising title progression for CEE audiences. The work is the same; the description shifts.

This is exhausting and most practitioners don’t have the energy for it, particularly while doing the actual work. The translation requires understanding three or four markets well enough to know what each one weights, watching how recruiters in each market respond to different framings, and adjusting deliberately. It’s a parallel job to project management itself.

The alternative is to commit to one market and let that market’s framework shape you. This is also a defensible strategy. A practitioner who builds their entire career inside MENA, optimising explicitly for what that market values, will out-compete a generalist who tries to navigate three markets at once. Specialisation has a price elsewhere; commitment has rewards locally.

What doesn’t work is being read by markets you haven’t translated yourself for. A practitioner trained in CEE evaluation logic, applying for senior roles in Western Europe without adjusting their CV emphasis, reads as light on substance even when they aren’t. A Western European practitioner applying into MENA without strengthening the credential-and-employer-brand signals reads as undercredentialled even when they have the work. The translation is what closes the gap.

This is what markets do at scale. The next question is what happens when a single recruiter, in a single market, reads a single practitioner — and what one encounter reveals about the system around it.

Subscribe now

A PMP holder has demonstrated knowledge of an integrated body of project management concepts — initiating, planning, executing, monitoring, closing — across ten knowledge areas, with an emphasis on professional judgement applied across them. A Prince2 holder has demonstrated familiarity with a defined methodology — seven principles, seven themes, seven processes — applied through a specific procedural framework. These are not the same skill. The two credentials produce two different kinds of practitioner.

That both credentials sell to the same market, that practitioners often hold both, that hiring managers list either as acceptable for the same role — none of this should make sense if project management were a single discipline with a settled body of knowledge. The fact that it makes sense anyway is what the comparison reveals.

PMP comes from the Project Management Institute, a US-based body whose framing of the discipline reflects American project management culture: knowledge-based, generalist, judgement-driven.

The PMBOK — the body of knowledge PMP is anchored to — is structured around concepts rather than procedures. It tells you what a risk register is, what earned value management is, what scope creep is, why critical path matters. It doesn’t tell you, in much detail, how to run any of these things on a Tuesday morning. The application is left to the practitioner, who is assumed to read the body of knowledge as a foundation and then apply judgement to whatever situation arises.

The exam reflects this. Most questions are scenario-based: a situation is described, four possible responses are offered, and the candidate has to pick the response a competent PM would make. The “competent PM” implied by the exam is someone who knows the framework well enough to apply it intelligently, not someone who follows a fixed procedure.

This is the credential’s strength and its weakness. The strength is that it produces practitioners who can think across knowledge areas, who can integrate, who can make judgement calls in situations the body of knowledge doesn’t directly address. The weakness is that the credential’s standard for “competence” is vague enough that two PMPs of equal certification can produce wildly different work. The exam tests the framework; the framework asks the practitioner to bring the rest.

Prince2 comes from a different tradition. Its origin is the UK government’s procurement methodology — a procedural framework built to standardise how public sector projects are run, with later commercial adaptation.

The methodology is structured around process, not knowledge. It tells you, in detail, what documents to produce, what roles to staff, what stages to pass through, what gates to clear. The “Project Initiation Document,” the “Stage Plan,” the “Exception Plan” — these are named artefacts with prescribed contents. A Prince2-run project produces a particular shape of paper trail, regardless of who’s running it.

The exam reflects this. Many questions test whether the candidate knows what artefact belongs in what stage, what role is responsible for what decision, what the methodology says to do when a particular event occurs. The “competent PM” implied by Prince2 is someone who follows the procedure correctly. The procedure is the discipline.

The strength of this approach is consistency. A Prince2 project run by a junior PM and a Prince2 project run by a senior PM produce the same documentation, follow the same stages, escalate the same way. For organisations that need predictable project governance — government departments, regulated industries, large public-sector contractors — this is genuinely valuable. The methodology compensates for variation in practitioner skill by standardising the work.

The weakness is rigidity. A practitioner trained primarily in Prince2 can struggle when the methodology doesn’t fit the project — when speed matters more than documentation, when the team is too small for the role structure, when the work doesn’t break cleanly into stages. The methodology is the discipline, which means departing from the methodology can read as departing from project management itself.

The two credentials sell to the same market because the market itself can’t decide what project management is.

If project management were principally a body of knowledge, PMP would be the dominant credential and Prince2 would be a niche specialism within procurement-heavy industries. If project management were principally a methodology, Prince2 would be the dominant credential and PMP would read as too vague to be useful. Neither has happened. Both credentials hold meaningful market share. Some practitioners hold both. Hiring managers list either as acceptable.

What this means is that the field hasn’t agreed on its own foundations. Project management is, depending on who’s asked, a discipline of knowledge applied with judgement (PMP’s frame), a methodology applied with discipline (Prince2’s frame), or — in the most honest answer — both, depending on the project, the organisation, and the practitioner.

The honest answer doesn’t help with credentialing. Credentialing requires a definition of what’s being certified. PMP defines it one way, Prince2 defines it another, and the field has tacitly agreed that both definitions are valid, which is the same as saying neither definition is decisive.

This isn’t unique to project management. Other professional fields have similar fragmentation — software engineering has multiple competing frameworks; finance has multiple competing certifications. But it does explain why a practitioner can’t simply hold “the credential” and be done. There isn’t one. There are several, and which one matters depends on where you’re working.

The split is partly a tradition split. US-influenced markets — the United States itself, much of Latin America, parts of Asia — default to PMP. UK-influenced markets — the UK itself, parts of MENA shaped by British colonial-era institutions, much of the Commonwealth, some northern European markets — default to Prince2. The boundary isn’t clean; many markets accept both. But the default frequently sits with one or the other based on which professional tradition shaped the market’s institutions.

A practitioner with PMP only, applying for a role in a Prince2-defaulted market, reads as partially qualified. The credential isn’t rejected — most hiring managers in those markets will accept it — but it’s read as the foreign credential, the one that needs explaining. The reverse is also true. A Prince2 holder applying in a PMP-defaulted market reads similarly.

Practitioners who work across markets often end up holding both. This is sometimes framed as “stacking credentials” but the underlying reason is that the credentials operate as passports — each one grants access to a particular market, and a practitioner planning to work across markets needs the ones that match their geography. Holding both is less about competence and more about market access. The work behind both credentials is the same; the credential is what unlocks the market.

The cost of this is straightforward: practitioners working across markets pay twice for credentialing the field can’t decide is one thing or two.

This is one face of how credentialing varies geographically. Markets read credentials through their own assumptions, and the same credential can mean different things in different places. The next post broadens the question: not just credentials, but how markets read project managers more generally.

Subscribe now

Subscribe now

The previous post looked at credentials — what they certify and what they don't. This one looks at titles, the other major artefact recruiters and hiring systems use to read your career. Titles work differently from credentials, and they fail differently. They also matter more in fast-triage hiring than credentials do, because they're what gets read first.

A title is supposed to summarise what you do. In most cases, it doesn’t.

What it summarises is what your contract said you did at the moment you signed it. Those two things drift apart almost immediately. The work expands; the title doesn’t. Responsibilities shift sideways into territory the title was never built to cover. Companies promote in scope before they promote in name. Some companies don’t promote in name at all, because changing titles forces salary band reviews they’d rather not run. Whatever the reason, a year into most jobs, the title and the work have already separated.

This isn’t unique to project management. It’s how titles work in any complex role. But in PM-adjacent careers, the gap is wider than usual, because PM work itself is hard to title cleanly. Are you a Project Manager, a Programme Manager, a Project Controls Lead, a Delivery Manager, a Technical PM, a Project Engineer who runs projects, an Engineering Lead with PM responsibilities? The same person, doing the same work, can hold any of these titles depending on the company, the industry, and the country. The work is one thing. The title is administrative.

The gap matters because the system that reads your career doesn’t know the difference.

There are several structural reasons titles drift away from the work, and most of them aren’t anyone’s fault.

Contract titles get negotiated for legal and tax purposes. In some jurisdictions, certain titles trigger different tax brackets, regulatory regimes, or labour-law protections. The title on the contract reflects the optimisation, not the work. This is particularly common in CEE countries with IT-tax-bracket regimes — engineers and project managers carrying contract titles like “Software Engineer” or “Systems Specialist” because the title qualifies the company for a more favourable tax structure. The title isn’t a description; it’s a fiscal instrument.

Functional titles emerge as work shifts. A junior PM who takes over a more senior PM’s portfolio when that person leaves is functionally doing senior PM work, but the title hasn’t caught up. Sometimes the title catches up months later, sometimes never. The functional title — the one used in conversations, in internal documents, in handover notes — is real, but it doesn’t appear on the CV unless the practitioner volunteers it.

Promotion lags expansion of responsibility. This is universal. Companies promote on review cycles, not on the day the work changes. A practitioner whose scope doubles in the first quarter of the year may not see the promotion until the following January, if at all. For twelve months, they’re doing the bigger job under the smaller title.

Industries title differently. Engineering firms tend to title down — what a consultancy would call a Senior Project Manager, a heavy-engineering firm calls a Project Engineer with PM responsibilities. Consulting firms tend to title up — what an EPC firm would call a Lead Planner, a consultancy calls a Senior Manager. Same work; different titles; different reads in the market.

Companies in different jurisdictions title differently. A “Project Manager” in the UK is often more senior than a “Project Manager” in Germany, where the equivalent role is usually called “Projektleiter” and sits one rung higher in the hierarchy. A “Senior PM” in Romania often translates to a “PM” in Western Europe, because Romanian markets compress more seniority into the senior label. None of this is broken; it’s just how titling works across markets.

None of these reasons are individual failure. They’re how the system produces titles. The system is doing what the system does. The cost gets borne by the practitioner.
Recruiters in fast triage read titles. They do not read role descriptions.

This isn’t laziness, although it can look like it. It’s how fast-triage hiring works at scale. A recruiter screening 200 LinkedIn profiles for one role cannot read each role description. The math doesn’t work. They scan titles, build a shortlist of profiles whose titles match the requirement, then read descriptions on the shortlist. Anyone whose title doesn’t match the requirement, regardless of what they actually did, never makes the shortlist.

The system has internal logic. Recruiters who read every description take longer per profile and screen fewer candidates per day. The recruiters who scan titles screen more candidates and produce more shortlists, which is what their employers reward. The fast-scanning recruiter isn’t doing a worse job by their own performance metrics; they’re doing the job the system asks them to do.

The result, from the practitioner’s side, is that your title isn’t a description of your work — it’s a search query. If your title doesn’t match the keywords the recruiter is searching, you don’t exist for that role. The role description below the title, which contains the actual evidence of your competence, is read only after the title has already qualified you for consideration.

This applies less to senior recruiters working on retained searches — those people read more carefully, because the cost of missing a candidate is higher. But for the volume end of the market, where most early-career and mid-career hiring happens, fast title-scanning is the dominant pattern. It’s what most practitioners are getting read by, most of the time.

The title you hold today shapes the title you can negotiate tomorrow.

Recruiters look at title trajectory. A practitioner whose title hasn’t changed in five years reads as someone who hasn’t grown, even if their scope has tripled in that time. A practitioner whose titles have moved cleanly from Junior to Senior to Lead reads as someone on a trajectory, even if the work behind those titles is unremarkable. The trajectory is what gets weighted, not the substance.

Promotion committees look at title trajectory. When you’re being considered for a senior role at a new firm, the committee asks not just “can this person do this job” but “is the next title up consistent with what the market expects.” A practitioner whose previous title was lower than their work warrants will struggle to negotiate a title that reflects what they actually did, because the previous title is the anchor. They get offered the next step up from where they were, not the next step up from where they should have been.

Salary benchmarking is anchored to title. HR systems and compensation surveys index salary bands to titles. A practitioner whose title undercounts their work has been earning below their market value, sometimes for years, without realising it. When they move to a new firm, the new firm benchmarks against the old title. The undercount compounds.

This is the harder problem with titles. The misread isn’t a one-time event. It’s a multi-year drag. A practitioner who took a title that didn’t reflect their work three years ago is still being read through that title today, and the work they’re doing now will be read through this year’s title in three years’ time. The system is path-dependent.
Practitioners with non-linear careers, cross-disciplinary work, or roles that grew faster than their titles get systematically undercounted.

The system isn’t broken. It’s working as designed. The design rewards legibility — careers that fit the standard progression, titles that follow the standard nomenclature, role transitions that map cleanly onto recognisable patterns. Complex careers aren’t legible at title resolution. Someone who moved between project engineering, technical leadership, and PM work — whose title at any given time reflected the contractual frame more than the functional reality — is illegible to fast-scanning hiring systems.

The illegibility doesn’t mean the career isn’t valuable. It means the career has to be translated for each market it encounters, and the translation is the practitioner’s job. No one else does it for you. The recruiter doesn’t ask what your title meant; they read what it says. The hiring manager may eventually see past the title, but only if you’ve made it onto the shortlist that the recruiter built from titles alone.

This is the cost of complex work. The practitioners who navigate it well learn to write CVs and LinkedIn profiles that translate their work into title-legible language without exaggerating. The practitioners who don’t get read as the system reads them — at title resolution, regardless of what’s underneath.

This is what titles do, in any single market. The next question is what happens when the same work, with the same title, gets read by different markets.

Subscribe now

This is the first post in a series on credentials, titles, and how they shape what other people see when they look at your career. Most of what’s in this series is about the gap between the formal artefacts — what your CV says, what your LinkedIn shows, what your certifications certify — and the actual work underneath them. The next eight weeks of posts will work through that gap from different angles. This one starts with the most common artefact in the field: the credential.

A credential certifies that you passed a test. It does not certify that you can do the work the test was designed to predict.

These are not the same thing, and most of the time we treat them as if they were. The PMP says you understand the project management body of knowledge well enough to score above the line on a four-hour exam. It says you logged the required hours of project work to qualify to sit for the exam in the first place. It says you’ve signed the PMI code of ethics. Beyond that, it says nothing about whether you can actually run a project.

This isn’t a complaint about PMP specifically. It’s true of every credential in the field — Prince2, CAPM, PMI-ACP, the AACE certifications, IPMA, the rest. Each one certifies a particular kind of knowledge and a particular kind of process compliance. None of them certify the work itself, because the work is too situational to certify. What gets done on a Tuesday morning when a hardware vendor misses delivery isn’t in any body of knowledge.

The gap between what the credential certifies and what the credential gets read as is where most of the misunderstanding sits.

Credentials aren’t nothing. I want to be careful about this, because the easy move in a post like this is to dismiss credentials entirely, and that would be wrong.

A credential certifies that the holder has been exposed to a body of knowledge. The exam may not test whether they can apply it well, but it does test whether they’ve read it, understood it, and can recognise its concepts when presented in different forms. That’s real. Someone with a PMP has read about earned value management, even if they’ve never used it on a project. Someone with Prince2 has been walked through the methodology’s process model, even if they’ve never run a project under it. The exposure isn’t trivial.

Credentials also impose a baseline. The hours requirement for PMP — the qualifying experience you have to log to sit for the exam — filters out people who haven’t been near the work at all. It’s not a high bar, but it’s a bar. Same for PMI-ACP, same for AACE PSP. Credentials aren’t a guarantee of competence, but they’re a screen against complete unfamiliarity, and that screen has value to the people doing the hiring.

The other thing credentials do, less often discussed, is give holders shared vocabulary. Two PMPs from different countries and different industries can talk about a critical path or a risk register or change control without first having to define the terms. The credential creates a common language. That language is mostly what makes the credential portable across geographies and sectors.

These are real benefits. They’re just not the same as certifying that someone can run a project.

What credentials don’t certify is the harder list, because most of what makes a project succeed or fail sits on it.

They don’t certify judgement. The exam can’t tell you whether the holder will make the right call when the schedule slips, the client is unhappy, and the cost department wants a recovery plan by Friday. Judgement is built from doing the work and being wrong sometimes. No exam tests for it.

They don’t certify the ability to read a room. Project management is, more than the credential frameworks acknowledge, a political activity. Knowing when to push, when to escalate, when to let a senior engineer save face, when to make a junior engineer’s contribution visible — none of this is in the body of knowledge. A practitioner who can do all of it and a practitioner who can do none of it can both hold the same credential.

They don’t certify managerial competence. The PMP doesn’t test whether you can run a difficult one-to-one. It doesn’t test whether you can hold the line on scope when the client is being insistent. It doesn’t test whether you can make a team feel safe enough to surface bad news early instead of hiding it.

The gap matters because different readers extract different things from the same credential.

A recruiter scanning a CV reads PMP and parses it as “qualified to do the job we’re hiring for.” That’s a fast read, and it’s structurally wrong — the credential doesn’t certify qualification for any specific role — but it’s the read recruiters make under time pressure. The credential becomes a proxy for fit, which it isn’t.

A hiring manager reads PMP differently. They’ve worked with PMP holders before, and they’ve learned that the credential certifies exposure but not competence. Their read is closer to “this candidate has the framework; whether they can do the job is something the interview has to establish.” The credential is a starting point, not an endpoint.

A senior PM reading another senior PM’s CV reads the credential differently again. They know what PMP costs in time and money; they know what the qualifying hours requirement asks for; they know the exam isn’t trivial but isn’t decisive. They tend to give credentials less weight than recruiters do and more weight than hiring managers do — they read it as a signal that the holder is serious about the discipline, not as evidence of capability.

The credential’s meaning isn’t fixed. It’s negotiated by whoever is reading it, and the negotiation produces wildly different values depending on the reader’s context.
Practitioners who treat credentials as endpoints stop developing the work. The credential becomes a conclusion — I’m a PMP now, the box is ticked — and the underlying skills stop building. I’ve seen this happen. The practitioner becomes someone with a credential rather than someone whose credential is one feature of a larger competence.

Practitioners who treat credentials as starting points keep building. The credential becomes a foundation — I have the framework, now the work is to apply it well — and the practitioner uses the body of knowledge as scaffolding for actual decisions. The same credential, in two different practitioners’ hands, becomes two different things.

This matters for hiring, but it also matters for your own career. Holding a credential isn’t an achievement that compounds on its own. It’s a starting condition. What compounds is what you do with it.

The recruiter scanning credentials can’t tell which kind of holder you are. The hiring manager can sometimes. The senior PM you’ll work for can almost always — but only after watching you for a while.

Credentials are one of the artefacts that other people use to read your career. Titles are another, and they work differently.

I’d cleared the morning. I thought it might take three hours.

It took most of the day, and somewhere around the middle of it I stopped being able to pretend the project was where the reports said it was. The deliverables I was reviewing were drafts. Some of them were structured drafts with the right sections; others were placeholders that had been carried forward from previous revision cycles unchanged. The progress reports said the documentation was 70% complete. What I was looking at was, generously, 30% — and the gap wasn’t a reporting error. The work hadn’t been done.

I kept reading. I wanted to be wrong. I went back to documents I’d already reviewed to check whether I’d been too harsh, and each second pass confirmed the first. By late afternoon I had a separate document open with a list of every deliverable I’d looked at and what I thought it actually was, and the list was much longer than I’d expected it to be when I started.

The project was four months behind schedule. Nobody had said it so out loud yet.

The slip wasn’t tactical. That was the thing the peer review made clear.

A tactical slip is the kind of slip you can recover from with the existing approach — work harder, work longer, sequence more aggressively. The schedule has been optimistic, but the underlying plan is sound. You can pull a tactical slip back by leaning on it. What I was looking at wasn’t that. The schedule existed, and it had been updated faithfully every reporting cycle, but the plan that should have produced the schedule hadn’t been built in the first place. The deliverables had been treated as sequential because the schedule said they were sequential — and the schedule said they were sequential because that’s how the template had been set up at the start of the programme, before anyone had really sat with the work.

Recovering by leaning harder on the existing approach was not going to close a four-month gap. The approach was the problem. The recovery couldn’t start with the schedule. It had to start with rebuilding the plan from scratch.

The recovery came down to a question I had to answer about every dependency in the project: was it real, or was it a convention?

Real dependencies are the ones where you genuinely cannot start work on B until A is finished, because B’s inputs come from A. Conventional dependencies are the ones where the schedule shows B starting after A because that’s how it’s always been done, or because the template assumed a sequential flow, or because nobody had taken the time to ask whether B could actually start earlier with partial inputs. Most projects have more conventional dependencies than real ones. The trick is being honest about which is which.

I sat with the leads from each of the three disciplines that mattered most — documentation, hardware lab setup, and software implementation — and we went through the work item by item. Some dependencies were genuinely fixed. The hardware needed to be in the lab before integration testing could run on it; that wasn’t going to change. But a lot of what the schedule was treating as fixed wasn’t. The documentation could be drafted in parallel with the software development as long as the design intent was stable, which it was. The hardware lab setup didn’t actually have to wait for the documentation to be approved; it had to wait for the design to be frozen, which was a different milestone. And the software implementation could begin against draft documentation as long as we kept the version control discipline tight enough to absorb the late edits.

What I ended up running was three tracks in parallel, with controlled handoff points instead of full sequential gates. It wasn’t a textbook recovery. There were trade-offs, and I knew there were trade-offs at the time. If the design intent had shifted, the documentation team would have lost rework; if the hardware lab setup had hit a problem we hadn’t anticipated, we’d have had software being written against a target that no longer existed. I accepted those risks because the alternative — staying sequential and trying to close the gap by speed alone — wasn’t going to work.

The three leads agreed to it. That mattered. I could have imposed the structure, but I didn’t want to run a recovery against people who thought it was reckless. Each of them pushed back on specific items, and I conceded several of them. The plan we ended up with was negotiated, not designed.

The first sign the approach was working came about six weeks in, on the documentation track.

We’d rebaselined the documentation milestones around the parallel-track structure, and the first internal review point hit on the rebuilt date. Not ahead of it; on it. That sounds like a small thing, but in a project that had been silently slipping for the better part of a year, a milestone hitting its date for the first time was a structural change in how the team was working. People started trusting the new schedule because the new schedule was telling the truth.

The compounding effect from there was faster than I’d expected. As the documentation track stayed on its rebuilt cadence, the software implementation track had stable inputs to work against, which meant the software milestones started landing closer to their dates as well. The hardware lab setup proceeded against a frozen design, which meant integration testing started on time when it could have started a month later. None of these were heroic outcomes. Each was just a track running on a plan that matched the work, instead of a schedule that didn’t.

There was a meeting about one week in — I don’t remember exactly which review it was — where someone said the project was going to land within a month of original baseline. I remember thinking that was optimistic. It wasn’t.

The project closed at the end of the original delivery quarter, three weeks past the original baseline date. From a four-month gap discovered in the middle of a Wednesday afternoon to three weeks of slip at delivery, across roughly one month of recovery.

I don’t remember the final acceptance test as a dramatic moment. The remarkable thing about it, by the time we got there, was how unremarkable it felt. The work had been done. The deliverables matched the documentation. The integration ran. We closed the project against a rebaseline that we’d agreed early in the recovery, and the rebaseline matched the plan, and the plan matched the work.

The recommendation letter I got out of the project listed me as a software engineer. That was the contract title, and it was correct in the strict sense. The role I’d been doing for those five months was something else.

The project closed in March. Three weeks late.

Most distressed projects I’ve seen didn’t have a bad schedule. They had a schedule that everyone treated as the plan, until reality forced the gap into the open — usually three or four months in, usually after the slip had already compounded into something that couldn’t be quietly recovered. The schedule was fine. The plan had stopped existing somewhere along the way, and nobody noticed because the schedule was still being updated.

This is a piece about that gap. What a schedule actually is, what a plan actually is, how the two come apart, and what to do about it before the steering committee starts asking why the curves are flat.

A schedule is a document. Dates, dependencies, milestones, durations, the critical path mapped across the work breakdown structure. It lives in Primavera or MS Project. It tells you what was agreed at a point in time.

What that flat description leaves out is that a schedule is also a contract. It encodes commitments — to clients, to internal teams, to the cost department, sometimes to legal counsel. It has reporting weight. It’s the artefact that gets reviewed at steering committees, exported into status decks, referenced in dispute correspondence, and audited when things go wrong. The weight is the point. Schedules ossify because that’s their job; they’re supposed to be the stable reference that everything else moves around.

The same weight is also why they go stale. Once a baseline is set, changing the schedule is politically expensive even when the underlying work has clearly moved. Re-baselining is a conversation, sometimes a difficult one, and most teams will defer it longer than they should.

The schedule is the artefact. It’s not the work.

A plan is the team’s shared understanding of how the work actually gets done. It’s a different thing from the schedule, and it lives in a different place — in the engineers and leads who know what’s happening this week, in the working sessions where sequencing actually gets decided, in the conversations between disciplines about what’s blocked and what isn’t.

The plan covers things the schedule can’t carry at its level of resolution. Who’s actually doing what, on what equipment, with what dependencies on whom else. The order the work flows in, including the small handoffs and parallel tracks that don’t appear at a milestone level. Where the slack genuinely is, versus where the schedule shows it — and these are usually different. Which dependencies are real, and which are conventions that can be relaxed under pressure.

The plan is what a senior engineer means when they say we can probably get Stage 3 starting before Stage 2 finishes if we sequence the deliverables right. None of that is in the schedule. It’s never going to be in the schedule. The schedule is a representation of the plan, deliberately compressed for reporting and contractual purposes — and the compression is lossy.

A plan can survive a missing document. A schedule cannot survive a missing plan.

In my experience there are three patterns. They look the same from the outside — schedule slipping, project drifting, milestones quietly moving — but they’re different failures, and they have different fixes.

The first is when the plan changes faster than the schedule. The team adapts to a delay, an early delivery, a client request, or a discovery in the work itself, and the working plan shifts within a week. The schedule reflects the change at the next monthly update, if at all. By the time the schedule catches up, the plan has shifted again. The schedule is now permanently a step or two behind the actual work, and the gap keeps widening.

The second is when the plan was never built. The schedule was constructed from a template, a sales commitment, or an estimate from a comparable project — but the team that has to deliver it never sat down to build a real understanding of the sequence. There’s no plan. There’s only a schedule and the assumption that the plan will materialise as the work progresses. It usually doesn’t.

The third is the one I see most often, and it’s the most damaging. The schedule is being used as the plan. The team treats milestones as instructions instead of as targets. People do work because the schedule says so, not because the work makes sense to do now. The schedule has stopped being a measuring instrument and become a script — and once that happens, the team’s ability to think for itself about the sequence quietly degrades.

When the schedule and the plan diverge, the project controls function gets slowly hollowed out, even if nobody notices for a while.

Status reports become accurate but useless. The schedule reflects what happened, not what should happen next. Steering committees read the report, see the slip, ask why, and the only honest answer is it just slipped — because the document doesn’t carry enough resolution to expose the lever. Nobody can intervene because nobody can see what to intervene on.

The risk register goes quiet at the same time. The risks the team is actually navigating — the ones the working plan is built around — never make it into the formal log, because the formal log is keyed to the schedule, and the schedule has stopped being where the real plan lives. The team is managing risk. The project controls function isn’t seeing it.

And recovery becomes much harder when you finally need it. You can’t recover a project to its schedule if the plan that produced the schedule no longer exists. You’re recovering to a document, not to a delivery path. By the time someone tries to pull the project back, half the work has to be reconstructed before any meaningful recovery plan can be written.

The discipline isn’t complicated. It’s just unglamorous, and it has to be done at moments when there’s pressure to do almost anything else.

Build the plan first, schedule second. Sit with the leads who will actually deliver the work and map the real sequence — the real dependencies, the real slack, the real handoffs. The schedule is the artefact you produce from the plan, not the input to it. If you find yourself building the schedule before the plan exists, the project is already at risk, regardless of what the dates say.

Re-baseline when the plan moves, not when the schedule slips. The most common discipline failure I’ve seen is updating the schedule to reflect slippage instead of updating it to reflect that the underlying plan has changed. The first is reporting. The second is project controls. They produce the same numbers in the short term and very different outcomes over six months.

Accept that the plan will live partly in conversation, and that this is fine. You can’t write down everything that’s in the team’s shared understanding, and it’s not the project controls function’s job to try. The job is to make sure the schedule remains a faithful enough representation of the plan that decisions made from it are good decisions.

The schedule keeps the plan honest, only if you keep the plan first.

Subscribe now