Project management policy: scope, reporting, change requests and closure

A client asks for one more report during the final week of a build. The developer says yes to be helpful. The tester finds out at acceptance, the delivery date slips by nine working days, and finance learns about the extra effort only when the team asks for overtime approval. Nobody was careless. The company simply had no written route for a change. A project management policy provides that route.

Its purpose is to standardise how projects are planned, run, monitored and delivered, so that customers and staff meet the same process on every job. It applies to client projects and to internal ones, and to anyone who owns, works on or reviews them. It works with the customer communication policy for what is said to the client and the performance appraisal policy for how delivery feeds goals.

• Project charter: the one-page approval stating the objective, owner, budget and target date.
• Scope statement: what is included, and just as important, what is excluded.
• Milestone: a checkable point with a deliverable, not a date on a calendar.
• Change request: a written ask to alter scope, cost or time, with its impact assessed.
• Acceptance: the customer's recorded agreement that a deliverable meets the agreed criteria.

Decide who can approve a new project and at what size. A small job might need only the department head; a larger one might need the director and finance. The charter prevents projects that begin on enthusiasm and end with no one sure what was promised. Requirements are gathered in writing and read back to the customer before sign-off, and roles are listed: project manager, delivery lead, reviewer and customer contact.

Break the work into tasks with owners and estimates. Decide how estimates are made and who challenges them; a second pair of eyes catches optimism. Record the budget in effort and, where relevant, spend. Resource allocation is a trade-off between utilisation and slack: people planned at every hour have no room for a defect or a sick day. Decide how much buffer a plan must carry.

Choose a cadence. Many teams use a short daily stand-up, a weekly status report and a monthly review for the sponsor. The status report should show milestones against plan, risks, open issues, change requests and the next step. Use a simple colour status, but define each colour, so green does not mean hopeful.

1. 1

   Raise

   Anyone proposing a change fills in the change request form: what, why, and who asked.

2. 2

   Assess

   The project manager estimates the effect on effort, cost, date and quality, and records the assessment.

3. 3

   Decide

   The approver named in the policy accepts, rejects or defers. Larger changes go to the sponsor and, if the customer pays, to the customer.

4. 4

   Update

   Plan, budget and scope statement are revised and the version number changes.

5. 5

   Communicate

   The team and customer receive the updated plan in writing.

6. 6

   Log

   The change is entered in the change register with its decision date.

Risks and issues have separate logs. A risk is something that might happen, with a likelihood, an owner and a response. An issue has already happened and needs a fix and a date. Blockers that last more than the agreed number of days move up to the department head.

State who reviews a deliverable before it goes to the customer. Define test steps and acceptance criteria while writing the scope, not after the build. The customer receives a demo, a test summary and an acceptance form to sign. If they reject a deliverable, the reason is recorded against the criteria.

Closure criteria must be written in advance: all milestones accepted, open issues resolved or handed over, documents delivered, access and accounts closed, final invoice raised and effort data entered. Hold a short review where the team writes what worked and what did not. A lessons-learned register, read before the next charter is written, is the cheapest improvement most companies can make.

Keep the charter, scope statement, plan, weekly reports, risk and issue logs, change register, acceptance form and closure note. Starting work without a charter, hiding a delay or accepting scope changes outside the process are breaches. The company decides how these are handled, usually through coaching first and the formal HR policies and governance route if they repeat. Staff acknowledge the policy with name, date and version, and the document is reviewed yearly or after a project fails.

1. Purpose and scope: client and internal projects above [size].
2. Definitions: charter, scope, milestone, change request, acceptance.
3. Initiation: approver [role]; charter template [name].
4. Roles: project manager, delivery lead, reviewer, sponsor.
5. Planning: tasks, estimates reviewed by [role]; buffer of [number] in plan.
6. Reporting: stand-up [frequency]; status report every [number] days; sponsor review [frequency].
7. Risks and issues: separate logs; escalate after [number] days.
8. Change control: form, assessment, approver by size [limits], register.
9. Quality and acceptance: reviewer, test summary, acceptance form.
10. Closure: criteria [list], review within [number] days, lessons register.
11. Records and breaches: [list]; consequences [ladder].
12. Acknowledgement and version: name, date, version [number].