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.
Jump to a section
A simple way to picture Project Management Tools and Documentation
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
These come up on the exam all the time. Here's how to tell them apart.
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
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)
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
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
Mistake
The project charter and the project management plan are essentially the same document, just written at different times.
Correct
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.
Mistake
The risk register and issue log are interchangeable because both track problems.
Correct
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.
Mistake
Once a change request is approved, you simply implement the change and do not update any other documents.
Correct
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.
Mistake
Lessons learned are only for the project manager's personal reference and are rarely shared.
Correct
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.
Mistake
The work breakdown structure (WBS) is the same as the project schedule.
Correct
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.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
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.
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.
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.
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.
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.
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.
You've finished Project Management Tools and Documentation. Continue through the PK0-005 study guide to build a complete picture of the exam.
Done with this chapter?