What a project charter is
A project charter is a short document that formally authorizes a project and sets out its purpose, boundaries and the authority of the project manager. It is the agreement between the sponsor and the project team about what the project is for. In coursework it demonstrates that you can define a project clearly before you plan it.
| Component | What it contains | Tip |
|---|---|---|
| Project title and background | The name and the business reason for the project | State the problem or opportunity in two or three sentences |
| Objectives | What the project must achieve, in measurable terms | Use SMART wording and link to business goals |
| Scope | What is included and, just as important, excluded | List out-of-scope items to prevent scope creep |
| Deliverables | The tangible outputs the project will produce | Name each deliverable and its acceptance standard |
| Stakeholders | Sponsor, customers, team, and others affected | Include their interest and influence |
| Assumptions and constraints | What you take as true and what limits the project | Time, budget, resources, regulations, technology |
| High-level risks | The biggest threats at the start | Detail comes later in the risk register |
| Budget and timeline | Summary cost and key milestone dates | Estimates at this stage, not final figures |
| Authority and approval | Who the project manager reports to and what they can decide, with sign-off | A signature block shows formal approval |
A worked charter extract
Customer portal upgrade (hypothetical)
Background. Customers currently phone to check order status, which generates 40 percent of support calls. A self-service portal would reduce this load and improve satisfaction.
Objectives. By 30 November: launch a portal allowing customers to view order status and invoices; cut order-status calls by 30 percent within three months of launch; keep the project within $180,000.
In scope. Portal design and build, integration with the order system, user testing, training for support staff.
Out of scope. Mobile app, changes to the order system itself, new payment methods.
Deliverables. Approved design, working portal, test report, user guide, trained support team.
Assumptions and constraints. Order system data is accurate; two developers available full time; launch must avoid the December peak.
Key risks. Integration problems; delayed user testing; staff resistance.
Notice how every objective is measurable and the exclusions are explicit. These two habits prevent most disagreements later.
What a work breakdown structure is
A work breakdown structure (WBS) breaks the total scope of a project into smaller and smaller deliverables until each piece can be estimated, assigned and tracked. It is a hierarchy of what must be produced, not a list of when things happen. Many schedule and cost problems start with a WBS that omits work, so it is worth getting right.
- 100 percent rule The WBS includes all the work defined by the scope, and nothing outside it. The sum of the child elements equals the parent.
- Deliverable-oriented Elements are nouns (Design document, Test report), not verbs (Write, Test). Activities come later.
- Mutually exclusive Elements do not overlap, so work is counted once.
- Right level of detail The lowest level, the work package, can be estimated and assigned. A common guide is 8 to 80 hours of work.
- Numbered Use 1, 1.1, 1.1.1 so each element has a unique code.
There are two usual ways to organize the top level. By deliverable (for example Portal, Integration, Training) or by phase (Initiation, Design, Build, Test, Launch). Choose one at the top and keep it consistent in each branch.
A worked WBS
| WBS code | Element | Type |
|---|---|---|
| 1 | Customer portal upgrade | Project |
| 1.1 | Project management | Deliverable group |
| 1.1.1 | Project plan and status reports | Work package |
| 1.2 | Portal design | Deliverable group |
| 1.2.1 | Requirements document | Work package |
| 1.2.2 | Interface designs | Work package |
| 1.3 | Portal build | Deliverable group |
| 1.3.1 | Front-end pages | Work package |
| 1.3.2 | Order system integration | Work package |
| 1.4 | Testing | Deliverable group |
| 1.4.1 | Test plan and cases | Work package |
| 1.4.2 | User acceptance test report | Work package |
| 1.5 | Launch and training | Deliverable group |
| 1.5.1 | User guide | Work package |
| 1.5.2 | Support staff training | Work package |
A WBS dictionary then describes each work package: its scope, deliverables, owner, estimated effort and cost, and acceptance criteria. Estimating bottom-up from the work packages produces a cost and time estimate you can defend, because it is based on actual work.
From WBS to schedule: a worked critical path
Once you have work packages, list the activities, estimate durations and identify dependencies. The critical path is the longest sequence of dependent activities, and it determines the shortest possible project duration. Any delay on it delays the project.
| Activity | Duration (days) | Depends on |
|---|---|---|
| A: Requirements | 3 | None |
| B: Build front end | 4 | A |
| C: Prepare data feed | 2 | A |
| D: Build integration | 5 | B |
| E: Test data feed | 3 | C |
| F: Final testing | 2 | D and E |
Paths: A-B-D-F takes 3 + 4 + 5 + 2 = 14 days. A-C-E-F takes 3 + 2 + 3 + 2 = 10 days. The longest, A-B-D-F, is the critical path, so the project takes 14 days.
A forward pass gives each activity's earliest start (ES) and finish (EF). A backward pass from day 14 gives the latest start (LS) and finish (LF). Slack is LS minus ES.
| Activity | ES | EF | LS | LF | Slack | Critical? |
|---|---|---|---|---|---|---|
| A | 0 | 3 | 0 | 3 | 0 | Yes |
| B | 3 | 7 | 3 | 7 | 0 | Yes |
| C | 3 | 5 | 7 | 9 | 4 | No |
| D | 7 | 12 | 7 | 12 | 0 | Yes |
| E | 5 | 8 | 9 | 12 | 4 | No |
| F | 12 | 14 | 12 | 14 | 0 | Yes |
Activities C and E each have four days of slack, so they can slip four days without delaying the project, but only if they slip separately, since they are on the same path. Focus management attention on A, B, D and F, and consider crashing (adding resources) or fast-tracking (overlapping) those if the schedule must be shortened.
Working on this assignment now? Get a price for help with your paper.
Get an instant quoteAssigning responsibility with a RACI matrix
A RACI matrix shows who is Responsible (does the work), Accountable (ultimately answers for it, one person only), Consulted (gives input) and Informed (kept updated) for each deliverable.
| Deliverable | Project manager | Developer | Business analyst | Sponsor |
|---|---|---|---|---|
| Requirements document | A | C | R | C |
| Front-end pages | A | R | C | I |
| Order system integration | A | R | C | I |
| User acceptance test report | A | C | R | C |
| Go-live approval | R | C | C | A |
The rule that each row has exactly one A avoids the situation where everyone assumes someone else is accountable.
A stakeholder power and interest grid
| High interest | Low interest | |
|---|---|---|
| High power | Manage closely: sponsor, head of support | Keep satisfied: finance director, IT security |
| Low power | Keep informed: support staff, customers using the portal | Monitor: other departments |
Plan communication by quadrant: weekly updates and decisions for the first, monthly briefings for the second, newsletters for the third and light monitoring for the last.
Change control
- Log every change request Who asked, what, why.
- Assess impact Scope, time, cost, risk and quality.
- Decide at the right level Small changes by the project manager; large ones by the sponsor.
- Update the baseline Charter, WBS, schedule and budget stay in step.
This is how scope creep is controlled without refusing every request: each change is visible and priced.
Common mistakes
- Vague objectives Make them measurable, with numbers and dates.
- No exclusions in scope State what is out of scope to prevent scope creep.
- WBS as a to-do list Use deliverables, not actions, and organize them into a hierarchy.
- Missing work Check the 100 percent rule: do the elements add up to the whole scope, including project management?
- Confusing duration with effort A task of 16 hours of work might take two days with one person or one day with two.
- Ignoring dependencies The critical path only makes sense if dependencies are correct.
- Skipping approval A charter needs sign-off to give the project authority.
If you want help with a project charter, WBS or schedule, you can order project management assignment help.