Root cause analysis: getting past the first plausible answer
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.
A project charter names the objective, the boundaries, the sponsor and the person authorised to run the work. Its main use comes months later, when people disagree about what was agreed.
A project charter is a short document, agreed at the start, stating what a project is meant to achieve, what is inside and outside its scope, who is accountable for it, and who has authority to run it. In a large organisation it is a formal artefact with signatures. In a company of twenty it can be one page — and the one page is worth far more than the formality suggests.
The reason is unglamorous. Four months in, two people will remember the objective differently, and the version that gets acted on will be whichever is asserted more confidently. A charter replaces that with a sentence everybody agreed to when nobody was under pressure.
The out of scope list is the section that earns its keep. In-scope statements are usually agreed easily because everyone reads their own hopes into them. Naming three or four things the project will not do exposes the disagreement immediately — which is uncomfortable in week one and cheap compared with week twenty.
A charter that describes the work but not who may decide things produces a project that stops every time a choice appears. State plainly what the project lead can settle alone, what needs the sponsor, and what needs a wider group. It is the difference between a two-hour delay and a two-week one, repeated every time.
The sponsor should be one person. Shared accountability sounds collaborative and functions as an escalation path to nobody, which is the failure that shows up as a project quietly losing momentum without anyone deciding to stop it.
These three get confused, and the distinction is practical rather than academic. The business case argues that the project is worth doing and belongs to the decision about whether to start. The charter authorises it and names who runs it. The scope statement, written later, details the deliverables and acceptance criteria in a way the charter deliberately does not.
For a small company the business case and the charter often merge into one document, which is fine as long as the authorisation half is not lost. What should not merge is the charter and the plan: a charter that includes a task list becomes obsolete the first time the plan changes, and then nobody trusts any of it.
Ettex Docs suits this: one document, version history kept so the objective as agreed in March is still readable in September, comments for collecting disagreement during the draft, and a single shared link rather than a copy in several inboxes. Duplicating the last charter is usually the fastest way to start the next one.
There is no charter template built in, no approval workflow and no signature capture — agreement is a comment or a reply, not a recorded sign-off. For work where formal authorisation has to be evidenced, that gap is worth knowing about before you rely on it.
A short document agreed at the start that states the objective, scope boundaries, sponsor, project lead, decision rights, success criteria and main risks.
One page for small projects, two for large ones. Length is not what makes it authoritative.
The out-of-scope list. It surfaces disagreement in week one rather than week twenty.
The business case argues whether to do the project. The charter authorises it and names who runs it and with what authority.
Better not. Shared accountability functions as an escalation path to nobody.
Reviewed at phase boundaries, with any change recorded deliberately. A charter that drifts silently is worse than none.
One page: the objective in a sentence, what is explicitly out of scope, one named sponsor, and who may decide what. Then keep the version you all agreed to.
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.
A code of conduct says how people here are expected to behave and what happens when they do not. Its value is not aspiration — it is having decided the hard cases before one arrives.
Most HR policy lists are written for organisations with an HR department. A company of fifteen needs a much shorter set — and needs each one to be short enough that people read it.