103 lines
4.1 KiB
Markdown
103 lines
4.1 KiB
Markdown
|
# Planning Model Reference
|
|||
|
|
|
|||
|
|
## Adaptive PM Model
|
|||
|
|
|
|||
|
|
Use an adaptive project management model: start with the lightest structure that can safely coordinate the work, then add rigor only when complexity, risk, or stakeholder needs require it. The plan should make ownership, sequence, decisions, and status visible without creating unnecessary process.
|
|||
|
|
|
|||
|
|
## Lightweight Default
|
|||
|
|
|
|||
|
|
Default to a simple plan when scope is familiar, team size is small, risks are low, and decisions are straightforward.
|
|||
|
|
|
|||
|
|
A lightweight plan usually includes:
|
|||
|
|
|
|||
|
|
- Goal and success criteria
|
|||
|
|
- Short milestone or phase list
|
|||
|
|
- To-dos grouped by workstream or deliverable
|
|||
|
|
- Owners and due dates for near-term work
|
|||
|
|
- Key dependencies and assumptions
|
|||
|
|
- Basic status cadence
|
|||
|
|
|
|||
|
|
## Complexity Triggers
|
|||
|
|
|
|||
|
|
Increase planning structure when any of these are present:
|
|||
|
|
|
|||
|
|
- Hard external deadline or launch date
|
|||
|
|
- Multiple teams, vendors, clients, or executive stakeholders
|
|||
|
|
- Significant budget, legal, compliance, security, or reputational exposure
|
|||
|
|
- Unclear scope or high likelihood of change
|
|||
|
|
- Many dependencies or long lead-time items
|
|||
|
|
- Approval-heavy workflow
|
|||
|
|
- High impact if work is delayed or incorrect
|
|||
|
|
- Remote, cross-time-zone, or capacity-constrained team
|
|||
|
|
- Public-facing or client-facing deliverables
|
|||
|
|
|
|||
|
|
Added structure may include milestone gates, risk register, decision log, approval tasks, status reports, dependency tracking, or staged rollout.
|
|||
|
|
|
|||
|
|
## Feasibility Status
|
|||
|
|
|
|||
|
|
Use Green, Yellow, or Red to communicate whether the current plan can meet the stated goal within the known constraints.
|
|||
|
|
|
|||
|
|
### Green
|
|||
|
|
|
|||
|
|
The goal appears achievable with current scope, timeline, capacity, and risk level. Continue with the plan and monitor normal dependencies.
|
|||
|
|
|
|||
|
|
### Yellow
|
|||
|
|
|
|||
|
|
The goal may be achievable, but there are meaningful risks, unclear decisions, tight constraints, or dependency concerns. Name the issues and recommend corrective action.
|
|||
|
|
|
|||
|
|
### Red
|
|||
|
|
|
|||
|
|
The goal is not realistically achievable under current scope, timeline, capacity, or constraints. Do not present the plan as viable without explicit changes or risk acceptance.
|
|||
|
|
|
|||
|
|
## Scope Narrowing Options
|
|||
|
|
|
|||
|
|
When feasibility is Yellow or Red, present practical options in this order:
|
|||
|
|
|
|||
|
|
1. MVP cut: reduce scope to the smallest useful outcome that still meets the core goal.
|
|||
|
|
2. Timeline extension: move dates or split delivery into phases.
|
|||
|
|
3. Capacity increase: add people, budget, vendors, automation, or dedicated decision-maker time.
|
|||
|
|
4. Explicit risk acceptance: proceed despite known risk only if the user insists and the risk is recorded clearly.
|
|||
|
|
|
|||
|
|
Describe the tradeoff for each option and ask which path the requester wants to take.
|
|||
|
|
|
|||
|
|
## Approval Handling
|
|||
|
|
|
|||
|
|
Use hybrid approval handling so minor sign-offs do not block the whole project, while major decisions remain visible.
|
|||
|
|
|
|||
|
|
### Approval Tasks for Minor Sign-Offs
|
|||
|
|
|
|||
|
|
Use individual approval tasks for low-impact reviews, routine content checks, asset confirmations, small budget confirmations, or stakeholder acknowledgements. Assign one owner and a due date.
|
|||
|
|
|
|||
|
|
### Milestone Gates for Major Decisions
|
|||
|
|
|
|||
|
|
Use milestone gates for decisions that affect scope, timeline, budget, launch readiness, public visibility, legal exposure, or executive commitment. A milestone gate should state the decision needed, approver, due date, required inputs, and consequence of delay.
|
|||
|
|
|
|||
|
|
## Moderate Risk Handling
|
|||
|
|
|
|||
|
|
For moderate-risk projects, track the top 3–7 risks. Avoid long risk lists that no one maintains.
|
|||
|
|
|
|||
|
|
For each risk, record:
|
|||
|
|
|
|||
|
|
- Risk statement
|
|||
|
|
- Owner
|
|||
|
|
- Mitigation plan
|
|||
|
|
- Contingency plan
|
|||
|
|
- Current status
|
|||
|
|
- Status update trigger
|
|||
|
|
|
|||
|
|
A status update trigger is the condition that requires escalation or a project update, such as a missed dependency date, unavailable reviewer, budget variance, failed test, unresolved approval, vendor delay, or scope change request.
|
|||
|
|
|
|||
|
|
Review moderate risks at each major status update or milestone gate, and close risks when they are no longer relevant.
|
|||
|
|
|
|||
|
|
## Plan Output Expectations
|
|||
|
|
|
|||
|
|
A practical plan should clearly show:
|
|||
|
|
|
|||
|
|
- What outcome the project is pursuing
|
|||
|
|
- What is in and out of scope
|
|||
|
|
- Who owns the work and decisions
|
|||
|
|
- What happens first, next, and later
|
|||
|
|
- Which approvals or gates matter
|
|||
|
|
- What could threaten delivery
|
|||
|
|
- Whether the plan is Green, Yellow, or Red
|