Project definition
- Project name
- Problem being solved
- The business problem, not the chosen approach.
- Proposed approach, in two sentences
Projects fail on scope, and scope fails on what was never written down. The most valuable section of a charter is the out-of-scope list, because that is what gets argued about in month three.
Write the out-of-scope list first. Easier to write and far more useful than the in-scope list. It is the section that resolves disagreements later, and writing it surfaces mismatched expectations immediately.
Make success measurable and dated. 'Improve efficiency' cannot be assessed. 'Reduce average onboarding setup from 3 days to 4 hours by the end of Q2' can. If you cannot measure it, you cannot tell whether the project worked.
Record decision rights, not the stakeholder list. Name who approves scope changes, who signs off acceptance, and who can halt the project. Projects stall on unclear authority far more often than on technical difficulty.
Here's a preview. Unlock the free download to get all 5 sections (4 more below).
More free templates IT teams use alongside this one.
IT roadmaps become wish lists because they list initiatives without capacity. Showing what the team can actually deliver alongside what has been requested is what turns the roadmap into a prioritisation conversation.
Status reports stay green until the week they turn red, because amber invites scrutiny nobody wants. Defining RAG by objective criteria rather than by judgement is the only reliable fix.
RACI matrices fail in one predictable way: multiple people marked accountable for the same activity, which means nobody is. One A per row is the rule that makes the whole exercise worthwhile.
The business problem, proposed approach, sponsor and project manager, scope with an explicit out-of-scope list, measurable dated success measures, stakeholders with decision rights, assumptions, constraints, risks, and the conditions under which the project would stop.
Because scope disputes in month three are almost always about something never written down. The exclusions list resolves them, and drafting it at the start surfaces mismatched expectations while they are still cheap to correct.
Whoever is accountable for the business benefit, which is usually not IT. If IT sponsors a project intended to improve a business process, there is nobody with the authority to make the process changes the benefit depends on.