SkarpChapter 7 of 11
Managing Risk, Issues and Change Without Losing Control
Look at how projects anticipate uncertainty, respond to problems and manage change requests so that control is maintained without stopping progress.
Step 1: Why Risk, Issues and Change Matter for Control
Reality vs The Plan
Your beautiful plan will collide with reality: suppliers slip, requirements evolve, and people make mistakes. Risk, issues and change management help you stay in control without freezing progress.
PFQ Expectations
At PFQ level you should: use a simple risk management process, distinguish risks from issues, and apply basic change control and configuration management to protect scope, quality and baselines.
Car Journey Analogy
Project plan = route. Risks = things that might happen (traffic). Issues = things that have happened (flat tyre). Change requests = passenger wants new destination. Configuration = tracking the latest route and documents.
What Control Really Means
Good control is not saying no to everything. It is seeing trouble early, responding proportionately, and changing the plan on purpose, not by accident.
Step 2: Defining Risk vs Issue (PFQ-Aligned)
What Is a Risk?
A project risk is an uncertain event or set of events that, if it occurs, will have a positive or negative effect on project objectives. Negative = threat, positive = opportunity.
What Is an Issue?
An issue is a current problem, query or concern that is already affecting the project or needs a decision now. There is no uncertainty about whether it has happened.
Core Difference
Risk may happen in the future; you can influence probability and impact. Issue has happened or is present now; you focus on resolution and damage limitation.
Timeline View
Before an event: it is a risk. When it happens: it becomes an issue. After resolution: it becomes a lesson for future projects.
Step 3: Risk vs Issue – Quick Sorting Exercise
Student Website Scenario
You are building a student society website. Classify each statement as a risk or an issue to practice the distinction.
Statements to Classify
- Our only web developer might get sick during the exam period.
- The client cannot access the test site today.
- There is a 40% chance IT will delay server access.
- The hosting bill is overdue and the site has been taken offline.
Suggested Classifications
- Risk (threat). 2. Issue. 3. Risk (threat). 4. Issue. Risks describe future uncertainty; issues describe current problems.
Language Clues
Words like might, chance signal risk. Words like cannot, has been, already signal issues. Train yourself to listen for these clues in real projects.
Step 4: A Simple PFQ-Aligned Risk Management Process
The Risk Loop
A simple PFQ-aligned risk process: 1) Identify risks, 2) Analyse probability and impact, 3) Plan responses, 4) Implement and monitor. Repeat throughout the project.
Identify Risks
Use brainstorming, checklists, lessons learned, WBS and schedule. Scan technical, schedule, cost, resource, legal, safety and reputation categories to find uncertainties.
Analyse Risks
Estimate probability (Low/Medium/High) and impact on time, cost, scope, quality, benefits. Use a simple risk matrix to prioritise which risks need action.
Plan Responses
Threats: avoid, reduce, transfer, accept. Opportunities: exploit, enhance, share, accept. Choose a strategy that fits the importance and cost of action.
Implement and Monitor
Assign an owner for each risk, add responses as real tasks and allowances, and review the risk register regularly. Risks may close, turn into issues, or new ones appear.
Step 5: Build a Mini Risk Register
Now apply the process to a simple case.
Imagine you are managing a 6-week group project to deliver a prototype mobile app for a local business.
- Identify 3 risks
- Write down three realistic uncertainties (threats or opportunities).
- Rate probability and impact
- For each risk, rate probability (L/M/H) and impact on schedule and quality (L/M/H).
- Choose a response
- Decide on one response strategy per risk (avoid, reduce, transfer, accept, exploit, enhance, share).
Use this simple table format in your notes:
Risk | Threat or Opportunity? | Probability (L/M/H) | Impact on Schedule (L/M/H) | Impact on Quality (L/M/H) | Response Strategy | Owner
---- | ---------------------- | -------------------- | -------------------------- | ------------------------- | ----------------- | -----
... | ... | ... | ... | ... | ... | ...
Reflection questions:
- Which risk did you rate highest overall? Why?
- How would this affect your schedule from the previous module (dependencies, critical path)?
- Which responses need to be visible in your project plan, not just in the risk register?
Step 6: Managing Issues – When Risks Become Real
What Is an Issue Log?
An issue log is a central list where you record and track all project issues: description, impact, priority, owner, target resolution date, status and actions.
Issue Management Steps
1) Capture the issue, 2) Assess impact and urgency, 3) Decide action or escalate, 4) Implement the action, 5) Review and close, recording the outcome.
Risk vs Issue Records
Risk register is forward-looking, about uncertainty. Issue log is now-focused, about concrete problems and decisions. Both are needed for control.
Tools in Practice
Modern tools like Jira or Azure DevOps often track risks and issues together but use different fields or tags so you can report them separately.
Step 7: Change Control – Protecting Scope and Baselines
Why Change Control?
Change is normal; uncontrolled change is scope creep. Change control is the formal process for handling requests to change scope, requirements, schedule, cost or quality baselines.
Why It Matters
Change control protects your scope statement and baseline plan, ensures changes are visible, evaluated and approved, and prevents silent erosion of time, budget and quality.
Simple Change Process
1) Request, 2) Record, 3) Assess impact, 4) Decide (approve/reject/defer), 5) Implement updates, 6) Review benefits. Keep a change log throughout.
Key Governance Rule
No change to scope, time or cost should be made without being recorded and approved at the right authority level. This is central to modern project governance.
Step 8: Configuration Management – Keeping Versions Under Control
What Is Configuration Management?
Change control decides what changes; configuration management controls which version of each item is official. It keeps documents, code and plans under version control.
Configuration Items
Configuration items include requirements, designs, source code, test plans, user manuals, and baseline schedules and budgets that must be versioned and tracked.
Why It Matters
Configuration management ensures everyone uses the same version, links changes to updated items, and supports auditability of what changed, when, and who approved it.
Core Activities
Plan and identify CIs, control changes to them, record status and history, and verify that actual items match documented versions. Tools like Git support these principles.
Step 9: Quick Knowledge Check
Test your understanding of risks, issues and change control.
A supplier emails to confirm they will deliver key components two weeks later than agreed. What is this primarily, and which process do you use first?
- It is a risk; update the risk register only.
- It is an issue; log it in the issue log and assess impact on the plan.
- It is a change request; approve it immediately to keep the supplier happy.
- It is configuration management; create a new version of the schedule without approval.
Show Answer
Answer: B) It is an issue; log it in the issue log and assess impact on the plan.
The delay is now certain, so it is an issue, not a risk. You log it in the issue log, assess impact on time and cost, and then may raise a formal change request if the baselines need to change.
Step 10: Flashcard Review
Use these flashcards to review key terms before you move on.
- Project risk
- An uncertain event or set of events that, if it occurs, will have a positive or negative effect on one or more project objectives.
- Issue
- A current problem, query or concern that is already affecting the project or needs a decision now; there is no uncertainty about whether it has happened.
- Risk management process (PFQ-level)
- A continuous loop of identifying risks, analysing probability and impact, planning responses, and implementing and monitoring those responses.
- Threat vs opportunity
- A threat is a negative risk that could harm objectives; an opportunity is a positive risk that could improve them.
- Change control
- The formal process for requesting, evaluating, approving or rejecting, and implementing changes to project baselines such as scope, time, cost and quality.
- Configuration management
- The discipline of identifying configuration items, controlling their versions, recording status, and verifying that actual items match approved versions.
- Change request (CR)
- A formal proposal to modify a project document, deliverable, baseline or requirement, usually logged and assessed through change control.
- Issue log
- A central register where project issues are recorded, prioritised, assigned, tracked and closed.
- Risk register
- A central document or tool where identified risks, their analysis, responses, owners and status are recorded and tracked.
Key Terms
- Issue
- A current problem, query or concern that is already affecting the project or needs a decision now.
- Threat
- A negative form of risk that, if it occurs, would have a harmful effect on project objectives.
- Baseline
- The approved version of a work product (such as scope, schedule or cost) that can be changed only through formal change control.
- Issue log
- A central record of project issues, including description, impact, priority, owner, actions and status.
- Opportunity
- A positive form of risk that, if it occurs, would have a beneficial effect on project objectives.
- Project risk
- An uncertain event or set of events that, if it occurs, will have a positive or negative effect on one or more project objectives.
- Risk register
- A central record of identified risks, their analysis, planned responses, owners and current status.
- Change control
- The formal process used to manage changes to project baselines such as scope, schedule, cost and quality.
- Change request (CR)
- A formal proposal to modify a project document, deliverable, baseline or requirement.
- Configuration item (CI)
- An item that is placed under configuration management, such as a document, piece of code, or baseline plan, whose version must be controlled.
- Risk management process
- A structured approach to managing risk, typically including identification, analysis, response planning, and implementation and monitoring.
- Configuration management
- The discipline of identifying configuration items, controlling changes to them, recording and reporting their status, and verifying their correctness.