Introduction
Leading a project eventually comes down to three questions. "What could go wrong?", "Who influences and is influenced by this work?", and "When can we finish?". These map to risk management, stakeholder management, and schedule management. The three areas may look independent, but in practice they constantly shake one another. When a risk fires, the schedule slips. When the schedule slips, stakeholders get nervous. When stakeholder demands change, new risks appear.
In this post we will walk through the three battlefields a PM faces daily, then tie them together with the change control and reporting systems that sit at the center. This is not theory for theory's sake. It includes frameworks and diagrams you can pull out in a meeting, along with real-world cases.
Let us first see the relationship between the three battlefields as a picture.
+-------------------------------------------+
| PM's control zone |
+-------------------------------------------+
[RISK] ---shakes--> [SCHEDULE] ---unsettles--> [STAKEHOLDERS]
^ |
| |
+-------------- new demands create <---------------+
Change Control acts as the valve of this loop.
Reporting transparently relays each area's state outward.
The three areas form a closed loop, and at its center change control and reporting act as the valve and the window that regulate pressure.
Risk Management
A risk is "an uncertain event that has not happened yet but will affect the goal if it does." It differs from a problem that has already occurred, which is an issue. The heart of risk management is not cleaning up after a problem fires, but seeing it and preparing before it fires.
The Four Steps of Risk Management
Following the PMI framework, risk management cycles through identify, analyze, respond, and monitor. It is not a one-time act but repeats throughout the project.
+----------+ +----------+ +----------+ +----------+
| Identify | ---> | Analyze | ---> | Respond | ---> | Monitor |
| | | | | | | |
+----------+ +----------+ +----------+ +----+-----+
^ |
| |
+----------- re-enter when a new risk appears <-------+
- Identify: Gather risk candidates through brainstorming, checklists, retrospectives of past projects, and interviews. The goal of this step is to surface everything.
- Analyze: Assess each risk's probability and impact. Qualitative (high/medium/low) assessment is most common, with quantitative (money, days) assessment added when needed.
- Respond: Decide a concrete response strategy for high-priority risks.
- Monitor: Track risk states and send newly found risks back to the identify step.
The Probability-Impact Matrix
The core tool of the analyze step is the probability-impact grid. Place impact on the horizontal axis and probability on the vertical axis, then plot each risk. The further toward the upper right, the more dangerous.
Probability
High | Medium High Very High
| (Watch) (Manage) (Act Now)
|
Medium | Low Medium High
| (Monitor) (Watch) (Manage)
|
Low | Very Low Low Medium
| (Accept) (Monitor) (Watch)
+--------------------------------------->
Low Medium High Impact
The upper-right zone (high probability plus large impact) holds the key risks that demand immediate response. The lower-left zone (low probability plus small impact) is usually simply accepted. It is a map for deciding where to spend limited time and resources.
Risk Response Strategies
Response strategies split into negative risks (threats) and positive risks (opportunities). In practice threat responses dominate, but it helps to know opportunity strategies too.
| Type | Strategy | Description | Example |
| --- | --- | --- | --- |
| Threat | Avoid | Remove the cause of the risk | Adopt a proven tech over an unproven one |
| Threat | Transfer | Shift responsibility to a third party | Insurance, outsourcing, warranty clauses |
| Threat | Mitigate | Reduce probability or impact | Prototype core modules early |
| Threat | Accept | Take it on and reserve contingency | Assign only a buffer to low-impact risks |
| Opportunity | Exploit | Make sure to seize the chance | Put top talent on core features |
| Opportunity | Enhance | Raise the chance of occurrence | Boost response with extra marketing |
| Opportunity | Share | Pursue it together with a partner | Combine strengths via joint work |
The Risk Register
Identified risks are managed in a risk register. They must live in a document, not in someone's head, so they can be tracked and reported.
| ID | Risk | Prob. | Impact | Level | Response Strategy | Owner | Status |
| --- | --- | --- | --- | --- | --- | --- | --- |
| R-01 | Key API vendor delay | Med | High | High | Mitigate: pre-vet an alternate API | PM Kim | Active |
| R-02 | Key developer leaves | Low | High | Med | Mitigate: document knowledge, pair | Lead Lee | Watch |
| R-03 | Frequent requirement changes | High | Med | High | Avoid: strengthen change control | PM Kim | Active |
| R-04 | External security audit delay | Med | Med | Med | Transfer: contract the schedule duty | Ops Park | Watch |
| R-05 | Unprepared for traffic spikes | Low | High | Med | Mitigate: run load tests early | Infra Choi | Active |
Stakeholder Management
A stakeholder is any person or group that influences or is influenced by the project. This includes executives, customers, users, partner teams, external vendors, and even regulators. A good PM manages not just features but people. Many projects collapse not over technology but over a failure of alignment between people.
The Power-Interest Grid
The starting point of stakeholder management is classification. The most widely used tool is the power-interest grid. Using power (the force one exerts on decisions) and interest (how much one cares about the project) as two axes, it forms a 2x2 of quadrants.
Power
High | Keep Satisfied Manage Closely
| Low interest, high power High power and interest
| e.g., executive sponsor e.g., key decision-maker
|
| --------------------------------------------------
|
Low | Monitor Keep Informed
| Low power and interest High interest, low power
| e.g., peripheral team e.g., end-user group
+-------------------------------------------------->
Low High Interest
- Manage Closely: The group that deserves the most of your time. Involve them deeply in decisions and communicate often.
- Keep Satisfied: High power but usually low interest. Engage them concisely only at key decisions and milestones. Satisfy them without over-bothering them.
- Keep Informed: High interest but little direct authority. Build trust with regular updates. User communities are a classic example.
- Monitor: Watch lightly. But quadrants can move as situations change, so reassess periodically.
The Stakeholder Register
Like risks, stakeholders are managed in a register. Record who wants what, which quadrant they sit in, and how to handle them.
| Stakeholder | Role | Power | Interest | Quadrant | Expectation/Concern | Strategy |
| --- | --- | --- | --- | --- | --- | --- |
| Business head | Sponsor | High | Med | Keep Satisfied | ROI, launch date | Milestone reports |
| Product owner | Decision | High | High | Manage Closely | Feature priority | Weekly one-on-one |
| Key customer | Ext. customer | High | High | Manage Closely | Stability, SLA | Biweekly review |
| End-user group | End user | Low | High | Keep Informed | Usability | Release notes |
| Legal team | Review | Med | Low | Monitor | Compliance | Consult as needed |
The Communication Plan
Once per-stakeholder strategies are set, they become concrete in a communication plan. Specify to whom, what, how often, and through which channel. Communication is a thing to be designed, not improvised.
| Audience | Content | Cadence | Channel | Format |
| --- | --- | --- | --- | --- |
| Exec sponsor | Progress, risks, decision asks | Monthly | In-person meeting | One-page summary |
| Product owner | Sprint progress, backlog | Weekly | Video call | Board review |
| Dev team | Daily progress, blockers | Daily | Standup | Verbal sync |
| Key customer | Major changes, upcoming launch | Biweekly | Email | Newsletter |
| Whole company | Milestone achieved | Quarterly | Intranet board | Announcement |
Schedule Management
Schedule is the area a PM is grilled on most often. To answer "When will it be done?", you must be able to handle four things: estimation, buffer, critical path, and delay response.
Estimation
Estimation predicts how long each task will take. Because estimation is inherently uncertain, it is healthier to treat it as a range rather than a single number.
- Analogous: Base it on the actuals of a similar past task. Fast but low accuracy.
- Parametric: Multiply time-per-unit by quantity. For example, if one screen takes 3 days, then 10 screens take 30 days.
- Three-Point: Use optimistic (O), pessimistic (P), and most likely (M). The expected value is (O plus 4M plus P) divided by 6. It bakes uncertainty into the number.
Here is a three-point estimation example.
Task: Integrate the payment module
Optimistic(O) = 5d, Most likely(M) = 8d, Pessimistic(P) = 17d
Expected = (5 + 4*8 + 17) / 6
= (5 + 32 + 17) / 6
= 54 / 6
= 9 days
-> Saying "9 days, high variance" is more honest than just "8 days".
Buffer
No matter how good the estimate, variation happens. That is why we set a buffer. The key principle is not to scatter buffers across each task but to gather them in one place. Buffers hidden in every task evaporate through student syndrome (delaying until just before the deadline) and Parkinson's law (work expands to fill the time given).
Bad way: hide a buffer in each task
[TaskA+buf][TaskB+buf][TaskC+buf] -> buffers get consumed separately
Good way: pool the buffer at the end (project buffer)
[TaskA][TaskB][TaskC][===project buffer===]
managed as a shared resource
Critical Path
The critical path is the longest chain of tasks that determines the minimum time to finish the project. If a task on the critical path slips by a day, the whole project slips by a day. Conversely, tasks off the critical path have some slack (float).
Below is a simple network diagram. Each node is a task, and the number in parentheses is the duration in days.
+----------+
+--->| B (4) |----+
| +----------+ |
+--------+ v +----------+
| A (2) | +----------+| E (3) |
+--------+ | D (5) || |
| +----------+ |+----+-----+
+--->| C (6) |-------->| |
+----------+ v v
+----------+
| F (2) | -- end
+----------+
Path 1: A -> B -> D -> F = 2 + 4 + 5 + 2 = 13 days
Path 2: A -> C -> D -> F = 2 + 6 + 5 + 2 = 15 days <- critical path
Path 3: A -> C -> E -> F = 2 + 6 + 3 + 2 = 13 days
The longest, Path 2 (15 days), is the critical path.
B and E carry some slack (float).
Knowing the critical path makes it clear where to focus. To pull the schedule in, you must shorten a task on the critical path. No matter how fast you finish a task off the critical path, the overall schedule does not shrink.
Delay Response
When a delay is detected, two compression techniques are common.
| Technique | Method | Pro | Con |
| --- | --- | --- | --- |
| Crashing | Add resources to critical-path tasks | Shortens schedule | Higher cost, inefficiency |
| Fast Tracking | Run sequential tasks in parallel | Little added cost | More risk and rework |
Neither is free. Crashing spends more money, and fast tracking carries more risk. When a delay appears, first re-check the critical path, then agree with stakeholders on which cost to bear. Quietly papering over it with overtime only grows a larger risk: burnout.
Change Management
The valve that connects the three battlefields is change management. Requirements will change, guaranteed. The problem is not change itself but uncontrolled change. Quietly granting small requests piles up until scope creep sets in, and schedule and quality collapse together.
The change control process flows like this.
+-------------+
| Change | (anyone may submit)
| request log |
+------+------+
v
+-------------+
| Impact | assess effect on scope,
| analysis | schedule, cost, risk, quality
+------+------+
v
+-------------+ reject
| Change |---------------> [notify requester of reason]
| Control |
| Board (CCB) |
+------+------+
| approve
v
+-------------+
| Update | reflect into schedule, scope,
| baselines | budget baselines; share widely
+------+------+
v
+-------------+
| Execute and |
| track |
+-------------+
The key is that every change must pass through the same gate. Routing even a trivial-looking request through impact analysis makes the cumulative cost visible. The goal is not to block change itself but to make the price of change transparent.
Reporting and Communication
The window that relays the state of risk, stakeholders, and schedule outward is reporting. The golden rule of reporting is simple: the worse the news, the faster and more honestly you deliver it. Bad news delivered late steals response time and breaks trust on top of it.
A good status report usually carries the following elements.
| Item | Content |
| --- | --- |
| Overall status | At a glance via traffic light (green/yellow/red) |
| Progress | Completed this week, planned next week |
| Schedule | Status against milestones, critical-path shifts |
| Risks/issues | Top risks and their response status |
| Decision asks | Decisions needed from stakeholders |
Traffic-light colors are intuitive but become meaningless if the criteria are vague. It helps to define them in advance.
Green = On plan. No help needed.
Yellow = Warning sign. Watching it; can self-manage.
Red = Intervention needed. Schedule, scope, or budget is threatened.
Note: a "green-only PM" loses trust.
The PM who turns yellow and red on time earns trust.
Cases
Case 1: An Unidentified Risk Hits the Critical Path
In a payment-integration project, an external vendor's certification process was missing from the register. A risk skipped at the identify step became real, and the integration task, which happened to sit on the critical path, slipped by two weeks. There are two lessons. First, external dependencies must be registered as risks from the start. Second, externally dependent tasks should be pulled off the critical path or started early to secure slack.
Case 2: A Misclassified Stakeholder
In another project, the PM placed the legal team in the "Monitor" quadrant. But just before launch, a regulatory review surfaced major change requests, revealing that legal was effectively a "Manage Closely" stakeholder. Quadrants are not fixed values; they move with time. Regular reassessment prevents this kind of accident.
Case 3: The Pile-Up of Uncontrolled Change
The third case is the weight of small changes. Dozens of requests like "just change the button color" came in without impact analysis. Each was trivial alone, but together they evaporated a sprint's worth of work. After introducing change control, every request went through impact analysis, and requesters began adjusting their own priorities, saying "Oh, that was a two-day job."
Closing
Risk, stakeholders, and schedule are not separate subjects but one living system. See risks well and the schedule stabilizes. Share the schedule honestly and stakeholder trust accumulates. Accumulate trust and you gain the authority to control change.
Remember just three things. First, put risks in the register before they fire. Second, classify people with the power-interest grid and communicate accordingly. Third, focus the schedule on the critical path, pool the buffer, and deliver bad news fast. More than flashy tools, the PM who steadily keeps these fundamentals is the one who carries the project to the finish.
References
- [Project Management Institute (PMI)](https://www.pmi.org/)
- [Atlassian: Project Management Guide](https://www.atlassian.com/work-management/project-management)
- [Scrum.org Resources](https://www.scrum.org/resources)
- [ProjectManagement.com](https://www.projectmanagement.com/)
- [PMI: Risk Management](https://www.pmi.org/learning/featured-topics/risk)
현재 단락 (1/190)
Leading a project eventually comes down to three questions. "What could go wrong?", "Who influences ...