Starting a Project: What Should Be Decided Before the Work Begins?

Most projects begin twice. There is the moment when work actually starts, when someone begins drafting requirements or asks a supplier for indicative pricing, and there is the later moment when a charter is signed and a kick-off appears in diaries. The gap between the two is where a good deal of later trouble is created, because effort is being spent against assumptions nobody has tested and authority nobody has confirmed.

Initiation is the point at which someone with the authority to do so decides that a defined piece of work may begin, on stated terms and within stated limits. Everything else at a kick-off is either preparation for that decision or communication of it. The practical question is what has to be settled before people can sensibly spend money and effort, and what can be left open without creating risk.

Enough clarity to begin, without pretending to a finished plan

The first thing that has to exist is the purpose of the work, expressed as a change rather than a description of what will be built. A new repairs scheduling system is an output. Fewer missed appointments, and a contact centre that can answer "when" without ringing back, is the reason anyone released funding. Stated as a change, the purpose can be tested later against what the project is actually doing; stated as a deliverable, it only tells you whether the thing was built.

The second is a boundary that says what is included, what is explicitly excluded, and what the work depends on that it does not control. Exclusions matter more than inclusions at this stage, because they are the statements people remember when someone later asks whether the project could also handle the contractor portal. Alongside them sit the assumptions the estimate rests on, each of which is really a risk that has not been recognised yet.

The third is authority, meaning who has authorised the work, who may decide what within it, and what has to go back to someone else. This is the part that gets abbreviated to a name in a sponsor box.

The fourth is enough of a development approach to start, together with how the money will arrive. Predictive, adaptive and hybrid delivery all need initiation, and they all need re-authorisation, but they differ in how much definition is useful up front and in how funding is released. A single approved budget and a series of release-based funding decisions place very different demands on the initiating conversation. Section 2.1.6 of the PMBOK® Guide Eighth Edition sets Initiate Project or Phase within the Governance Performance Domain, which puts the emphasis on authority, direction and the conditions for proceeding rather than on completing a form.

Deciding too much at initiation is its own failure mode. Detailed estimates built before anyone has spoken to operations, a full risk register assembled from a template, and requirements written to a level of precision the organisation cannot yet justify all create commitments that later have to be unpicked. The test is whether a decision can be made better with a fortnight's work than it can today. If it can, initiation should record that it is open, note who will close it and by when, and move on.

Decision rights are the part most often left vague

Authorisation is usually clear at the top and fuzzy underneath. A board approves an investment, a sponsor is named, and nobody agrees what the project manager may settle without going back. The result is not a dramatic governance failure. It is a slow one, where decisions that could be made in an afternoon wait for a monthly meeting, and where decisions that genuinely needed a wider view get made informally because waiting felt disproportionate.

Consider a housing association replacing repairs scheduling across three regions. The business case was approved, a sponsor appointed, and delivery began at pace. Six weeks in, the team found that historic job data could be migrated in full, partially, or left in the old system with read-only access. The three options differed by about eighty thousand pounds and by six weeks on the go-live date. The project manager had no stated limit, so the question went to the investment board, which met monthly and deferred it once for more analysis. Three months of contractor time was spent working around a decision that a sponsor could have taken in a week, had anyone agreed at the outset that the sponsor could take it.

What would have prevented that is unglamorous: a threshold expressed in money and in impact, agreed before it was needed. Below a stated figure and with no effect on the committed date, the project manager decides and records it. Above either line, the sponsor decides. Above a second line, or where the change touches customer commitments or regulatory obligations, it returns to the board. Thresholds set in advance are also the only ones that can be set calmly, because nobody yet knows which decision will fall on which side of them.

The 2026 PMP Examination Content Outline puts this in its Business Environment domain, where establishing project governance includes defining success metrics and outlining escalation paths and thresholds. For a candidate, the useful habit is to read an initiation scenario for authority before reading it for activity: who authorised this work, what were they authorised to decide, and has anything since then taken it beyond that limit. Situations that look like scheduling problems or stakeholder problems very often turn out to be decisions being taken at the wrong level.

Assumptions, boundaries and the conditions for stopping

Assumptions recorded at initiation are only useful if someone owns them and a date is attached. "Assumes regional operations managers are available for two days of workshops in July" is a sentence that either gets validated in the first fortnight or becomes the reason the schedule slips in August. The value comes from the follow-up, not from the log, which is why an assumption without an owner is closer to a wish.

The harder conversation is about the conditions under which the work should stop or change shape. Most initiation discussions concentrate entirely on how to succeed, which leaves the organisation with no agreed language for the moment when the justification weakens. If the regulatory deadline that drove the timing moves, or the operational saving that justified the investment turns out to depend on a restructure that has been shelved, someone should be able to raise that without it sounding like a loss of nerve. Naming those conditions early makes the later conversation a governance discussion rather than an accusation, and it is a genuine protection against spending continuing simply because it has already started.

Success criteria belong in the same conversation, and they need an owner beyond the project. If the measure is missed appointments, someone in operations has to agree that the measure is fair, that the baseline is real, and that they will still be looking at it six months after handover. A benefit with no owner after delivery is a benefit nobody will report on.

Starting again, and starting late

Initiation is not a single event at the front of a project. Phases are initiated, releases are initiated, and any significant change in the basis of the work is a reason to re-establish purpose, boundary and authority. Adaptive delivery does this more visibly, because funding and prioritisation decisions recur around releases, but a predictive project moving from design into construction faces exactly the same questions with more at stake. Re-initiation is also the natural moment to tighten decision thresholds that proved wrong, or to widen them where every escalation ended with the sponsor agreeing what the project manager had already recommended.

Most project managers, at some point, inherit work that was never properly initiated. A retrospective kick-off helps nobody. What does help is writing a short statement of what the work is for, what it includes and excludes, what it assumes, and who decides what, then circulating it with a request for correction rather than approval. People who would never attend a workshop will readily tell you that your document is wrong, and the corrections are the information you were missing. Once the statement stops attracting objections, take the decision thresholds to the sponsor as a proposal. It is a great deal easier to agree a limit against a concrete example than in the abstract.

Much of what we work through in Omega's PMP® Exam Preparation course is this kind of reading, where a scenario looks like a scheduling or stakeholder problem until you ask who was authorised to agree the date in the first place.

The underlying discipline is modest. Before work begins, establish why it matters, where it ends, what it assumes, who may decide what, and what would cause the organisation to think again. Everything else can be built as the project learns, and most of it will be better for the delay.

Andre Malowney

Interested in going further?

Initiation questions are easy to state and difficult to apply, because real projects present them as scheduling pressure, supplier frustration or an awkward stakeholder rather than as a question about authority. Structured preparation gives you practice at reading those situations back to the decision that should have been made, and at recognising when a project has quietly moved beyond the terms it was authorised on.

For the fuller treatment of initiation as a governance activity, and how it sits alongside the other processes in the Governance Performance Domain, the PMBOK® Guide Eighth Edition is the reference to work from.

Ad · Amazon affiliate link.

References

A090: Project Governance Explained: Who Decides What, and Why
A091: Project Governance vs Organisational Governance: What's the Difference?
A092: How Projects Create Value Through Governance
A093: Choosing a Project Governance Model
A094: Governance Metrics That Actually Tell You Something

PMP and PMBOK are registered marks of the Project Management Institute, Inc.