#004 - Project Aegis – When Risk Management Exists Only on Paper
Background
Project Aegis is a two-year, €95M transformation for NordSecure Insurance, a mid-size European insurer.
Goal: replace their legacy policy administration and claims systems with a modern, cloud-based platform, integrating:
• Policy admin
• Claims
• Document management
• Data warehouse
• Customer portals
• Regulatory reporting
Delivery model:
• Prime integrator: BlueRidge Consulting
• Core SaaS platform vendor: CoreSure
• Data migration vendor: DataBridge
• Internal teams: security, infrastructure, operations, actuarial, compliance
Aegis sits under a wider Group Change Portfolio that currently runs 18 active programs.
Because NordSecure’s board has been burned by failed projects before, they insisted on: “A strong, formal risk management framework based on PMI best practices.”
On paper, it looks solid:
• A Risk Management Plan (RMP) was written and approved.
• A risk register exists in the PMO tool.
• Monthly Risk & Issues Committee meetings happen.
• The program has a Risk Manager appointed (half-time role, shared across 3 programs).
Everyone feels reassured - “We have RISK MANAGEMENT in place, all is good!”
How the Aegis Risk Management “Works” in Practice
In the first steering committee, the program manager (PM) proudly presents:
• A neat risk heat map with red/amber/green dots
• Top 10 risk slide with short descriptions and RAG statuses
• A “mature process” diagram: identify → analyze → respond → monitor
The CIO smiles: “Good. Last time risk was our blind spot. This time we’re doing it properly.”
But on the ground, things are a bit different.
1. Risk workshops became a one-off event
At the start of the program, BlueRidge ran a half-day risk workshop with key stakeholders:
• They filled a lot of sticky notes.
• They produced a long list of risks.
• They ranked them qualitatively (High/Med/Low).
• The PMO loaded them into the tool.
Everyone felt good.
But after that:
• No regular risk workshops by workstream.
• No refresh when scope changed.
• No new risks added for months, except “compliance risk” and “timeline pressure” in generic words.
Risk management became something done at the start, then lightly maintained by the PMO.
2. The risk register is large—but not useful
The risk register grows to 87 entries over time. Examples:
• “Vendor delay”
• “Data migration complexity”
• “Performance issues”
• “Scope creep”
• “Stakeholder misalignment”
Most entries:
• have vague descriptions,
• generic impacts (time, cost, quality),
• owners that don’t remember they are owners,
• target dates that are never updated.
Many risks are marked:
• Probability: Medium
• Impact: Medium
• Response: “Monitor” or “Mitigate – detailed plan TBD”
Nobody ever writes these plans. It’s an empty shell.
The Risk Manager spends hours each month reconciling the register and chasing updates via email. Risk reviews become PMO administration, not real management.
3. No clear link between risks, schedule, and budget
The integrated schedule is built without explicit risk adjustments:
• No risk-based contingency on critical path tasks
• No explicit link between high-impact risks and schedule buffers
• No risk-adjusted forecasting
• Risk exposure is not translated into contingency budget
The CFO approved a 5% generic contingency for the program: “We can’t ask for more, it will look like we don’t know what we’re doing.”
But this number wasn’t derived from any structured risk analysis..…it just “felt reasonable.”
4. Cultural issue: bad news = poor performance
In NordSecure’s culture, the unspoken rule is: “If your project is red, your competence is questioned.”
The portfolio dashboards go to the board monthly.
No one wants to be the first red program after the board’s “transformation excellence” campaign.
So risks are:
• downplayed (“Medium for now, we’ll re-evaluate later”),
• rephrased in softer terms (“schedule pressure” instead of “unachievable date”),
• sometimes not logged at all until they’re very close to becoming issues.
Risk management slowly turns into image management.
The Emerging Problem
Nine months in, you start seeing worrying signs:
1. Data migration is behind. DataBridge is privately struggling with complex legacy data models and poor data quality.
• In risk reviews, they keep saying: “We’re tight, but still manageable.”
• Their main risk in the log: “Data mapping effort may be under-estimated – Mitigation: ongoing validation.”
2. Performance testing is slipping. Environments are late and test data sets are incomplete.
• Risk in the log: “Performance testing late start risk – Mitigation: TBC.”
• Nobody owns the mitigation.
3. Regulatory reporting requirements evolve mid-program. Compliance warns that: “If the new system cannot generate all required reports reliably by Q4, we’ll have to run parallel systems longer than planned.”
4. The go-live date is externally committed:
• Announced in investor presentations
• Referenced in a central bank communication
• Tied to stopping support contracts for the old platform
You, as the PM, see a pattern:
• High-impact risks are known
• No concrete response plans are developed, nor funded
• The program is still officially “Amber; trending Green”
The Trigger: Migration Reality Hits
At the end of the first integrated migration rehearsal, reality blows up.
Results:
• Only 62% of policies migrated correctly
• Several data domains (claims history, reinsurance treaties) incomplete
• Many “to be confirmed” transformations left unresolved
• DataBridge estimates at least three more full cycles needed
The rehearsal report states: “Given current capacity and defect rates, we cannot achieve acceptable migration quality in time for the planned dress rehearsal.”
This is the moment when a risk becomes a hard issue.
You do a quick impact analysis with the team:
• Dress rehearsal was planned in 4 months.
• Each full migration cycle + fix window takes ~6–7 weeks.
• That alone pushes the dress rehearsal beyond the planned date.
• If dress rehearsal slips, the go-live must either slip or the bank goes live with unproven migration.
You bring this to the next internal governance meeting.
The Governance Conversation
Participants:
Program Manager (you) / Risk Manager / Head of Data (client) / DataBridge Delivery Lead / BlueRidge Account Director / NordSecure CIO / Portfolio Director
You present: “Our first full migration trial shows we’re significantly behind where we need to be. Based on the current trajectory, the dress rehearsal in September is not achievable without additional capacity or relaxing quality criteria.”
CIO: “We knew data was tricky. Is this a firm conclusion or worst-case?”
DataBridge Lead (with a shaking voice): “We underestimated some dependencies with upstream systems. With extra focus and longer days, we can improve throughput. I’d keep it as a high risk, but I’m not ready to say the date is impossible.”
Portfolio Director: “Let’s not jump to extending timelines yet. The board is very committed to the date we’ve communicated.”
You point to the risk register:
• The risk “Data migration complexity” has been there since month 1.
• Probability: Medium → High
• Impact: High
• Mitigation: “Detailed mapping validation and early trial runs” (never fully resourced).
Risk Manager: “We’ve raised this several times in the Risk & Issues Committee, but we never had a funded mitigation plan. We just tracked it.”
Silence. And some more silence. Then:
Account Director: “We should avoid calling the September dress rehearsal ‘unachievable’ at this point. Let’s frame it as ‘significant risk under active mitigation.’ The client expects us to be solution-oriented, not pessimistic.”
CIO: “What do you suggest as next steps then? I don’t want red statuses triggering panic at the board.”
Where this leaves you
You are the Program Manager and are now dealing with:
• a migration rehearsal failure
• a high-visibility regulatory deadline
• vendors soft-pedaling reality
• portfolio leadership reluctant to escalate
• a risk process that exists, but doesn’t actually help you
• and a client who, for the moment, still trusts you
The question now isn’t academic. It is practical, urgent, and uncomfortable.
Pause here. Don’t rush. Think like you’re actually accountable. Digest this. Then reflect on the following:
1) What went wrong in the way risk management was implemented in Project Aegis?
Consider:
• process vs behavior
• risk ownership
• culture and incentives
• generic vs specific risks
• link between risks, schedule and budget
2) Which failures must be addressed now, not just in hindsight?
If you could realistically fix only two or three things in the short term:
• what would they be?
• why those?
• what would you leave for later?
3) How would you classify and handle the migration situation right now?
Ask yourself:
• is this still a risk, or already an issue?
• who needs to know?
• how does status reporting change?
• do you re-baseline immediately, or wait?
4) What actions would you take in the next 2–4 weeks as the PM?
What do you actually do? And why? With what expected outcome?
5) What would you change in the risk management approach going forward?
Consider:
• governance changes
• frequency and type of risk workshops
• escalation culture
• thresholds for red/amber/green
• contingency and buffers
• linking risk to planning and decision-making
Take your time. This is deliberately not solved for you.
You’re meant to sit with it, argue with yourself, sketch options, reorder priorities, and think like someone whose name is on the front page when it goes wrong. I hope you have fun with this one! :)