RESOURCES / RESOURCE LIBRARY
Copyable project planning templates and checklists
Use these on-page templates to prepare a project brief, map a workflow, define an acceptance test and record a decision. Copy the text into your own document and replace bracketed prompts. These are planning aids, not downloadable files, completed specifications or compliance certifications.
Template 1: one-page project brief
Project name: [working title]. Business owner: [person or role]. Decision-maker: [person or role]. Prepared on: [date]. Version: [reference].
Problem: [who cannot complete which task, and what causes the difficulty]. Desired outcome: [observable change]. Current evidence: [source and period, or not measured].
Users and roles: [who reads, creates, changes and approves]. Records: [main objects and required fields]. Source systems: [where authoritative information lives].
First-release scope: [required capabilities]. Exclusions: [work not included]. Constraints: [verified access, systems, timing or operating requirements].
Acceptance: [how the outcome will be checked]. Dependencies: [item, owner, status]. Open questions: [question, decision owner, needed-by date]. Next review: [participants and date].
Template 2: workflow and exception map
Workflow name: [name]. Trigger: [event that begins work]. Completion: [observable end condition]. Record identifier: [how one item is tracked].
Step: [number and action]. Responsible role: [role]. Required input: [information and version]. Starting status: [state]. Decision rule: [condition]. Resulting status: [state]. Output: [record or notification].
Handoff: [recipient and information transferred]. Permission: [who may perform this action]. Exception: [failure or missing input]. Recovery owner: [role]. Recovery action: [authorized next step].
Repeat the step block for each handoff. Then check whether an item can be left without an owner, whether a notification is mistaken for a saved record, and whether a changed input invalidates a previous decision.
Template 3: acceptance test record
Test ID: [reference]. Requirement: [linked requirement]. Reviewer: [role]. Environment: [test environment]. Data: [synthetic or approved test data].
Given: [starting state and permissions]. When: [one action]. Then: [observable expected result]. Must not happen: [unwanted change or access].
Actual result: [observation]. Evidence: [record, screenshot or log reference without secrets]. Outcome: [pass, fail or blocked]. Issue owner: [role]. Retest result: [date and outcome].
Example: Given R-104 is Under Review and the user is its requester, when that user attempts approval, then the action is denied and the status remains Under Review. Must not happen: a decision recorded under another person’s identity. This is an illustrative test case, not proof of an implemented control.
Template 4: decision and change log
Decision ID: [reference]. Question or proposed change: [specific choice]. Reason: [problem or new information]. Options considered: [options and relevant trade-offs].
Impact: [scope, records, permissions, dependencies and acceptance tests affected]. Decision owner: [authorized role]. Outcome: [approved, rejected or pending]. Rationale: [why].
Effective version: [reference]. Follow-up actions: [action and owner]. Evidence: [supporting reference]. Review trigger: [what new condition would require reconsideration].
Keep a pending decision visibly pending. Do not write “approved” merely because a recommendation appears in meeting notes; record the actual authorized decision.
Before sharing your working copy
Remove passwords, tokens, personal data and unnecessary customer details. Replace examples with information you are authorized to share. Check that every open question has an owner and that every Must requirement has a testable outcome.
These templates organize discussion; they do not establish project acceptance, legal obligations or support coverage. Keep engagement terms and operational authority in the applicable approved documents.
Technology Solutions & Business Services