LEARN. PRACTICE. GROW.Concept and mechanism
A risk describes an uncertain condition and its possible effect on objectives. An issue that has already occurred needs action, ownership, and a deadline. Keep both visible, with indicators and a proportionate response. When a change arises, assess scope, effort, schedule, operations, security, and dependency impacts before promising implementation. An architecture decision should preserve context, alternatives, and consequences in an appropriate record. If context changes, link the new decision to the earlier one while retaining history. The project manager coordinates decision and execution but does not automatically replace architecture, security, business, or operations authority.
Guided application
In a fictional scenario, a supplier proposes a managed service to accelerate migration. The team should revisit responsibility distribution: in AWS, the boundary changes with the selected service; data and permissions still require customer decisions. Avoid assuming cloud removes maintenance, risk, or access requirements. For resilience, distinguish RTO from RPO and require evidence covering the complete workflow. An exercise can meet recovery time while missing the tolerated data-loss window. Bring options with consequences and residual risk to the appropriate forum instead of presenting one solution as inevitable. An exception needs ownership, validity, and resolution criteria.
RTO and RPO are separate criteria; meeting one does not demonstrate the other.
Common pitfalls
Materialized risk without action; informal request as approval; cloud as transfer of all responsibility.
Related topics: Mandate, scope, and acceptance · Capacity, dependencies, and forecasting · Governance, suppliers, and communication
Record alternatives, impacts, and authority before committing to change.
Reference: Maintain an architecture decision record · PM² reference practices and cloud operational governance; primary guidance reviewed 2026-09-30