Initiating Is Not Just Something You Do Once
The five Focus Areas are usually drawn as a line running from left to right, with initiating at the left-hand end. A charter is signed, a kick-off is held, and the project moves on to planning. Anyone who has run a project for more than a few months knows the experience does not match the diagram. The question of whether the team is authorised to do the work now in front of it, and whether anyone still agrees on why that work matters, keeps coming back.
It comes back at a phase boundary. It comes back when a funding tranche is released, when a new workstream opens, when a sponsor moves on, and when the business reason for the project quietly changes shape while delivery carries on regardless. Initiating is something you return to, and what it looks like when you return to it depends on how your project delivers.
What initiating is actually for
The Initiating Focus Area at Section 4.5.1 of The Standard for Project Management covers the authority to carry work on as well as the authority to start it, and the second of those gets far less attention. Initiating settles four things: why the work matters enough to spend money and people on it, who can say yes to it, who is affected and needs to be in the conversation early, and what direction, assumptions and constraints everyone is working under. None of those four stays settled for the life of a project.
A charter is the usual artefact, and it is worth being precise about what it does. A business case argues that the investment is worth making. A charter authorises the work and frames it, naming the person who can commit resources, setting the boundaries, and giving the project manager standing to act. When the boundaries move, the standing does not automatically move with them.
Early governance belongs here too, and it amounts to more than deciding who chairs a board. It is the agreement about what the team can decide on its own, what needs the sponsor, what needs to go higher, and at what threshold. Teams that never have that conversation tend to discover the thresholds by breaching one.
Why a phase gate is an initiating decision
In predictive delivery the recurrence is built into the structure, which is convenient, and also easy to treat as a formality. Gate reviews are often run as reporting exercises: the stage is presented, the pack is approved, the project carries on. What a gate does underneath the reporting is release authority and funding for a stage that has not started yet, on the strength of evidence from a stage that has.
That makes the gate an initiating act as much as a closing one. Assumptions recorded at the outset may be two years old by the time the third stage begins, and some of them will have been overtaken by a supplier changing hands, a regulation being redrafted or a service moving into a different building. The stakeholder picture will have moved as well, and the operations manager who was consulted at the start may have been replaced twice since. A gate that only asks whether the previous stage finished on plan has answered the easier question.
The practical work at a gate boundary is unglamorous. Re-test only the assumptions the next stage depends on. Confirm the business case still holds against the forecast you have now. Establish who signs at the next level of spend, because it is often not the same person as before. Then hold the review.
Initiating on a cadence in adaptive delivery
Teams working iteratively do this far more often than predictive ones, and far more lightly. A release boundary, an increment boundary or the opening of a new product area all raise the same questions in a smaller form: what outcome is this next piece of work for, who cares whether it lands, what can the team decide for itself, and what still needs someone else's signature. In a mature product team the answers take twenty minutes and end up visible on the board rather than written into a document.
Mistakes here fall either side of the useful position. One is treating authority as permanent because the team was empowered at some point in the past, so it moves into a new domain carrying new regulatory exposure without anyone checking whether the empowerment stretched that far. The other is importing the predictive apparatus wholesale and producing a charter for every increment, which buries a useful habit under paperwork nobody reads. Adaptive delivery involves real planning, forecasting and control. It does not involve running a stage gate every fortnight.
Hybrid work is where this gets interesting, because the boundaries rarely line up. The infrastructure workstream is at a stage gate while the software workstream is three increments into a release, and the funding decision covers both. Working out which mandate applies to which part of the work, and who is entitled to change it, is most of the job in a hybrid environment. Recognising a boundary while there is still time to act on it comes from having seen a great many of them, which is why a structured PMP exam preparation course puts candidates through one of these situations after another until the pattern becomes familiar.
Noticing when the mandate has run out
The signal is usually practical rather than procedural. Someone asks the team to do something adjacent to what it was set up to do, and it sounds like a continuation.
A manufacturing project had automated one assembly cell, delivered it, and was three weeks from closing the stage. The sponsor asked the team to carry straight on into the second bay, on the reasonable grounds that it was the same work with a different serial number. It was not quite the same work. The second bay ran a different shift pattern, which changed the access windows for installation. It sat under a different operations manager, who had not been party to any of the earlier agreements. The safety case had been written for one cell and one set of guarding. The project manager could have absorbed all of that as scope and pressed on, and the request would have been satisfied inside a fortnight.
She spent half a day instead. She wrote down what the second bay actually committed the organisation to, established that the shift access she needed was the new operations manager's to grant, and got the safety case extension started before any installation was scheduled. The work she did was initiating work, on a project that had been running for eighteen months. Nobody signed a second charter, and nobody needed to. What changed was that the team knew whose yes it was operating on.
The habit that makes this reliable is small. When something arrives that was not in the original picture, ask what it commits the organisation to and who is entitled to commit it. Where both answers match what you already hold, carry on. Where either one does not, you are at the front of something new, whatever the plan says about which stage you are in.
For a PMP® candidate, what helps is a shift away from remembering where initiating sits in a sequence and towards recognising the situation when it appears in a scenario: a new party, a new commitment, a boundary that has moved. That reading habit is a good deal closer to the job than memorising a diagram of five boxes.
Checking what has been committed, and by whom, at the moment the work changes shape buys something unspectacular and worth having. Teams that re-establish their mandate at each boundary spend less time in retrospective arguments about who approved what, and they find out sooner when the business reason behind the work has changed. Teams that treat initiating as a box ticked in week one tend to find out both of those things at the point where acting on them costs the most.
Interested in going further?
Knowing when a project has crossed into work your existing authority does not cover is a judgement that improves with exposure to other people's projects as well as your own. Omega's PMP® Exam Preparation works through situations of this kind across predictive, adaptive and hybrid delivery.
The Focus Areas, including the initiating material described here, are set out in The Standard for Project Management inside the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A072: Planning in Predictive and Agile Projects
A073: Executing in an Adaptive Project
A075: Closing a Project Properly Still Matters
A007: The Standard for Project Management vs the PMBOK Guide
A074: Monitoring and Controlling Without Micromanaging
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
