# Project Management Tools and Documentation

> Chapter 16 of the Courseiva PROJECT-PLUS curriculum — https://courseiva.com/learn/project-plus/project-management-tools-and-documentation

**Official objective:** 4.1 — Identify common project management tools and types of project documentation used throughout the lifecycle.

## Introduction

Project management tools and documentation are the blueprints and record-keeping system that keep a project from spiralling into confusion. Without them, teams forget who approved what or miss critical deadlines. For the PK0-005 exam, knowing which document to use in which phase of the project is a key differentiator that can earn you easy marks.

## The Dream Holiday Planning Analogy

You decide to plan a two-week dream holiday to Japan with three friends. First, you create a 'charter' document stating the goal (visit four cities), the budget (£5,000 each), and who decides on hotels. That is your project charter. 

 Next, you write a detailed plan: day-by-day itineraries, flight bookings, rail pass purchases, and a risk log for lost passports or typhoon season. This is your project management plan. As you travel, you keep a 'daily log' of actual spending versus budget, photos of receipts, and notes on which shrines were crowded. That is your issue log and status report rolled into one. 

 After the trip, you write a summary: what went well, what you would skip, and how much you actually spent. That is the lessons learned document. Without these documents, you would argue about who picked the wrong hotel or lose track of who paid for dinner. In IT, project tools and documentation serve the same purpose: they turn chaos into a clear, auditable, repeatable process.

## Core explanation

Project management tools and documentation are the structured set of forms, logs, and software that project managers use to plan, track, and close projects. Think of them as the official paper trail for every decision, action, and change. 

 There are two broad categories: tools and documentation. Tools are the software or templates you use to create documents (e.g., Microsoft Project, Jira, Trello, or even a shared spreadsheet). Documentation refers to the actual outputs — the files and reports that capture information about the project. 

 **Why do we need them?** 

 Before formal documentation existed, projects relied on memory and verbal agreements. This caused frequent misunderstandings, scope creep (uncontrolled changes to the project), and finger-pointing when something went wrong. Documentation creates a single source of truth. It answers questions like: What was the original deadline? Who approved a budget increase? Why was a feature cut? 

 **The lifecycle connection** 

 Projects move through phases: initiation, planning, execution, monitoring and controlling, and closure. Each phase has its own documents. 

 **Initiation** 

 During initiation, the key document is the *project charter*. This formal document authorises the project and gives the project manager the authority to spend resources. It includes the business case (why the project exists), key stakeholders (people with an interest in the project), and high-level risks. 

 **Planning** 

 Planning produces the *project management plan* — the master document that governs how the project will be executed, monitored, and closed. It contains sub-plans for scope, schedule, cost, quality, communication, risk, and procurement. Also created here: the *work breakdown structure (WBS)*, which breaks the project into small, manageable tasks; the *schedule baseline* (the approved timeline); and the *cost baseline* (the approved budget). 

 **Execution** 

 Execution is where the actual work gets done. The project manager uses *status reports* to communicate progress, *issue logs* to track problems that need resolution, and *meeting minutes* to record decisions. Change requests are formally documented on a *change request form*. 

 **Monitoring and controlling** 

 This phase overlaps with execution. The project manager compares actual performance against the baselines using *variance reports*. If the schedule is slipping, the team may submit a *corrective action request*. The *risk register* is updated with new risks and their status. 

 **Closure** 

 At closure, the team produces the *lessons learned document* (what went well and what could be improved), the *project closure report* (formal sign-offs), and a *handover document* (instructions for the operations team). 

 **Common types of project documentation you need to know for PK0-005** 

 - Business case: justifies why the project is worth doing 
 - Project charter: authorises the project and names the project manager 
 - Scope statement: defines exactly what is included and excluded from the project 
 - Requirements documentation: lists functional and non-functional needs of stakeholders 
 - Work breakdown structure (WBS): hierarchical decomposition of work into tasks 
 - Schedule: timeline with start and end dates for each activity 
 - Budget/cost baseline: approved spending plan 
 - Risk register: list of identified risks, their probability, impact, and response plan 
 - Issue log: list of current problems and who is responsible for solving them 
 - Change log: record of all change requests and their status (approved, rejected, pending) 
 - Status report: periodic update on progress, often weekly or monthly 
 - Lessons learned: insights gained during the project for future use 
 - Project closure report: final sign-off confirming all deliverables are accepted 
 
 **Tools that help manage these** 
 
 Tools range from simple spreadsheets (Google Sheets, Excel) to dedicated project management software like Jira, Asana, Microsoft Project, Trello, and Monday.com. The tool is not the document; the tool helps you create and maintain the document. The exam tests your understanding of the documents themselves, not the software.

## Real-world context

Imagine you work as a junior project coordinator at a medium-sized IT services company. Your company is building a new mobile app for a retail client. Here is what you actually do with project management tools and documentation: 

 **Week 1: Initiation** 

 Your senior project manager hands you a draft *business case* that explains the app will increase customer engagement by 20%. You help format the *project charter*. You identify the client's CIO (chief information officer) as the sponsor and list the initial budget of £150,000. Once the charter is approved, you store it in a shared folder. 

 **Week 2–4: Planning** 

 You hold a meeting with the developer team to create the *work breakdown structure*. You break down the app into: sign-in screen, product catalogue, shopping cart, payment gateway, and order history. Under payment gateway, you list sub-tasks like 'integrate Stripe API' and 'test refund flow'. You enter all tasks into Jira, a project tracking tool. Next, you help build the *schedule* in Microsoft Project, linking dependencies (payment cannot be tested until the shopping cart is built). You also draft the *risk register*. One risk: the third-party payment provider could change its API during development. You assign a response: monitor the provider's blog and have a backup plan using PayPal. 
 
 **Week 5–12: Execution and monitoring** 
 
 Every Monday morning, you run a report from Jira showing which tasks are overdue. You update the *status report* with a green/yellow/red traffic-light indicator. This week, the shopping cart is delayed because a developer was sick. You mark the schedule as yellow. You create an *issue log* entry: 'Shopping cart development behind schedule by 3 days. Mitigation: ask developer to work overtime next weekend.' 
 
 When the client requests an extra feature—a 'wish list'—you do not just say yes. You create a *change request form* describing the change, the reason (client wants to increase user retention), and the impact on schedule and cost. Your manager reviews it with the client. Once approved, you update the *scope statement* and *baselines*. 
 
 **Week 13: Closure** 
 
 The app goes live. You hold a lessons learned meeting. The team says the API monitoring was effective. They also say the initial estimate for payment integration was too optimistic. You write the *lessons learned document* so the next project does not make the same mistake. You prepare the *closure report*, get the client to sign it, and hand over the administrative credentials to the IT operations team. 
 
 Without these documents and tools, the team would have no way to track progress, manage the client's changing requests, or learn from mistakes. The documentation becomes a permanent record that can be audited or revisited if questions arise months later.

## Exam focus

The PK0-005 exam tests your ability to match the correct documentation to the correct project lifecycle phase. This is one of the most straightforward areas of the exam — do not lose marks here. 

 **Concepts the exam loves to test** 

 - The difference between a *project charter* and a *project management plan*. Trap: the charter is created during initiation; the plan is created during planning. They are not the same thing. 
 - The difference between a *risk register* and an *issue log*. Trap: risks are potential future problems; issues are problems that have already occurred. The exam will give you a scenario where a problem happens and you must choose the correct log to update. 
 - The purpose of a *change request* and the *change log*. Trap: a change request is a proposal; the change log is a record of all proposals and their outcomes. 
 - Which documents are created in *closure*: lessons learned, closure report, handover documentation. 
 - The definition of a *work breakdown structure (WBS)*: it decomposes the work, not the team or the timeline. 
 
 **Question types that appear** 
 
 Multiple-choice questions: 
 - Given a scenario, select the document the project manager should use. Example: 'The project is being initiated. Which document authorises the project?' Answer: Project charter. 
 - Ordering/sequencing: 'Put the following documents in the correct lifecycle order.' 
 - Definition matching: 'Which document defines the hierarchy of tasks?' 
 
 **Traps to watch for** 
 
 - The exam may offer 'statement of work' as a distractor. The statement of work (SOW) is a procurement document that describes the work to be done by an external vendor; the project charter is the internal authorisation document. 
 - They might call the 'project management plan' the 'project plan' — same thing. But do not confuse it with the 'schedule plan' or 'scope plan', which are sub-components. 
 - They may list 'status report' as an option when the scenario clearly describes an issue that has occurred. In that case, the correct answer is 'issue log'. 
 - Pay attention to tense in the scenario. If the problem has already happened, it is an issue. If it might happen, it is a risk. 
 
 **Key definitions to memorise** 
 
 - Business case: justification for the project 
 - Project charter: authorisation document 
 - Scope statement: boundaries of the project 
 - WBS: task breakdown 
 - Risk register: future uncertain events 
 - Issue log: current problems 
 - Change log: record of change requests 
 - Lessons learned: post-project insights 
 - Closure report: final sign-off 
 
 **Common exam scenario** 
 
 Scenario: A developer discovers a security vulnerability in the code. The team needs to spend extra time fixing it. The project manager must document this. What document do they update? Answer: Issue log (the vulnerability is a current problem that has occurred). Then they may also submit a change request if the fix affects the schedule or budget.

## Step by step

1. **Create the business case** — Identify the problem or opportunity, estimate costs and benefits, and present a justification for the project. This document convinces management to allocate resources.
2. **Draft the project charter** — Write the formal authorisation document. Include the project purpose, high-level requirements, budget, key stakeholders, and the assigned project manager. Obtain the sponsor's signature.
3. **Build the project management plan** — Develop the master plan that outlines how the project will be executed, monitored, and closed. Create sub-plans for scope, schedule, cost, quality, communication, risk, and procurement. Include baselines and the WBS.
4. **Track and update documents during execution** — Maintain the issue log, risk register, change log, and status reports. Whenever a risk materialises or an issue arises, update the corresponding log. For every change, submit a change request and update baselines if approved.
5. **Conduct closure and archive lessons learned** — Hold a lessons learned meeting, document insights, and write the project closure report. Obtain final sign-off from the sponsor and hand over deliverables to operations. Store all documents in a shared repository for future reference.

## Comparisons

### Project Charter vs Project Management Plan

**Project Charter:**
- Created during initiation phase
- High-level, short document (2-5 pages)
- Authorises the project and names the project manager

**Project Management Plan:**
- Created during planning phase
- Detailed, comprehensive (can be 50+ pages)
- Describes how the project will be executed, monitored, and closed

### Risk Register vs Issue Log

**Risk Register:**
- Tracks potential future events
- Each risk has probability and impact scores
- Includes planned response strategies

**Issue Log:**
- Tracks problems that have already happened
- Each issue has an owner and resolution deadline
- Focuses on current obstacles that need immediate action

### Work Breakdown Structure (WBS) vs Project Schedule

**Work Breakdown Structure (WBS):**
- Hierarchical list of work packages
- Does not include dates or durations
- Focuses purely on what work needs to be done

**Project Schedule:**
- Sequences tasks on a timeline
- Includes start dates, end dates, and dependencies
- Focuses on when work will be done and by whom

### Change Request vs Change Log

**Change Request:**
- A single proposal to modify scope, schedule, or cost
- Submitted before any change is implemented
- Contains description, reason, impact analysis

**Change Log:**
- A running record of all change requests
- Tracks status of each request (approved, rejected, pending)
- Provides an audit trail of every change over the project life

## Diagram

_A flowchart showing how key project documents map to the five lifecycle phases from initiation through closure._

```mermaid
flowchart TD
    A[Initiation] --> B[Project Charter]
    A --> C[Business Case]
    B --> D[Planning]
    D --> E[Project Management Plan]
    D --> F[Work Breakdown Structure]
    D --> G[Risk Register]
    E --> H[Execution]
    H --> I[Issue Log]
    H --> J[Status Reports]
    H --> K[Change Requests]
    K --> L[Change Log]
    H --> M[Monitoring and Controlling]
    M --> N[Variance Reports]
    N --> O[Closure]
    O --> P[Lessons Learned]
    O --> Q[Closure Report]
```

## Common misconceptions

- **Misconception:** The project charter and the project management plan are essentially the same document, just written at different times. **Reality:** The project charter is a short authorisation document created during initiation. The project management plan is a detailed, comprehensive document created during planning that contains baselines, sub-plans, and methodologies. (Beginners see both as 'the project document' and do not distinguish their distinct purposes and timing in the lifecycle.)
- **Misconception:** The risk register and issue log are interchangeable because both track problems. **Reality:** The risk register tracks potential future events that could impact the project. The issue log tracks problems that have already occurred and need resolution. (The words 'risk' and 'issue' are used loosely in everyday conversation, making it hard to remember the strict project management definitions.)
- **Misconception:** Once a change request is approved, you simply implement the change and do not update any other documents. **Reality:** An approved change request triggers updates to multiple documents: the scope statement, schedule, budget, and any affected baselines. The change is also recorded in the change log. (Beginners underestimate the ripple effect of changes. They think of documentation as static rather than as a living system that must be kept consistent.)
- **Misconception:** Lessons learned are only for the project manager's personal reference and are rarely shared. **Reality:** Lessons learned are formal, documented reports that are stored in the organisational process assets and shared with the entire organisation to improve future projects. (Many people view lessons learned as informal 'notes to self', not as a professional archive that feeds into continuous improvement.)
- **Misconception:** The work breakdown structure (WBS) is the same as the project schedule. **Reality:** The WBS is a hierarchical decomposition of all work into tasks, without durations or dates. The schedule builds on the WBS by adding start/end dates, dependencies, and resources. (Beginners conflate the two because both break down the project, but the WBS is purely about work content, not timing.)

## Key takeaways

- The project charter authorises the project and names the project manager during the initiation phase.
- The project management plan is the master plan created in the planning phase that includes baselines, sub-plans, and a WBS.
- The risk register tracks potential future problems; the issue log tracks problems that have already occurred.
- All change requests must be formally documented, approved or rejected, and recorded in the change log.
- Lessons learned are documented during project closure and become part of organisational process assets for future projects.
- The work breakdown structure (WBS) is a hierarchical list of tasks, not a schedule with dates.
- The business case justifies the project; the project charter gives it official approval to proceed.
- Status reports provide periodic snapshots of progress, while variance reports compare actual performance against baselines.

## FAQ

**What is the difference between a project charter and a statement of work?**

A project charter authorises the project internally within your organisation. A statement of work (SOW) is a procurement document that describes the work a vendor will do for you. The SOW is part of the contract, while the charter is internal governance.

**Do I need to create all these documents for every small project?**

You should create at least the core documents: charter, project management plan (or a simplified version), issue log, risk register, change log, and closure report. The level of detail scales with the project size and complexity, but the discipline of documentation remains important.

**Can I use a spreadsheet instead of special project management software?**

Yes. Many small teams use spreadsheets for status reports, issue logs, and risk registers. The tool does not matter as long as the documentation is accurate, accessible, and maintained. The exam tests your knowledge of the documents, not the software.

**What happens if I do not update the documentation during the project?**

Without updated documentation, you lose the single source of truth. Team members may work from outdated requirements, stakeholders may be misinformed about progress, and you will have no audit trail for decisions. This leads to scope creep, missed deadlines, and disputes.

**How often should I update the risk register?**

The risk register should be reviewed and updated at every status meeting or at least weekly during active execution. New risks can emerge at any time, and existing risks may change in probability or impact. The project manager owns this update.

**What is the difference between a baseline and a plan?**

A baseline is the approved version of a plan (e.g., the schedule baseline, cost baseline). Once baselined, any change must go through formal change control. A plan is the working document before it is approved. After approval, it becomes the baseline.

## Check your understanding

1. **During which project phase is the project charter created?**

   Answer: The project charter is created during the initiation phase.

2. **What is the difference between a risk and an issue?**

   Answer: A risk is a potential future event that could affect the project; an issue is a problem that has already occurred.

3. **Which document should you update when a team member finds a bug in the code that must be fixed immediately?**

   Answer: You should update the issue log, because a bug that has been discovered is a current problem.

4. **What is the purpose of the work breakdown structure (WBS)?**

   Answer: The WBS breaks the project work into small, manageable tasks or work packages, but it does not include dates or durations.

5. **Where are documented insights from the project stored for use by future projects?**

   Answer: They are stored in the lessons learned document, which becomes part of the organisational process assets.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/project-plus/project-management-tools-and-documentation