Most Post-mortems in IT Projects vs ICMG Stage 2–7 Problem Analysis Framework?
- Sunil Dutt Jha
- Jun 10
- 2 min read
What Is the Stage 2–7 Problem Analysis Framework?
The Stage 2–7 Problem Analysis framework is ICMG’s deep diagnostic method — designed to evaluate structural health across an enterprise or a subfunction, much like a modern medical diagnosis.
Most post-mortems in IT focus on surface symptoms:
Why did this project fail?
Why was the timeline missed?
Why didn’t the vendor deliver?
But Stage 2–7 is different. It doesn’t just ask “what failed?” — it asks what was never architected?
It uncovers misalignments, absences, and hidden gaps across all architectural layers — from strategy to operations.
Enterprise Diagnosis Is Like Medical Diagnosis
Just as medicine evaluates the whole system — organs, processes, vitals, daily function — this framework assesses an enterprise across multiple structural perspectives:
Strategy (What was the intended goal?)
Process (What flows should deliver it?)
Systems (Do our tools enable the flow?)
Components (Have we built the right assets?)
Implementation (Did we deploy correctly?)
Operations (Are we working as expected?)
Whether applied to a single subfunction (like boarding) or to entire departments (like Passenger Services), Stage 2–7 can detect both micro-level breakdowns and enterprise-wide misalignment.
The Stages of Diagnosis — One by One
Stage | Focus Area | What It Reveals |
Stage 2: Strategy Analysis | P1 – Strategy | Strategic misalignments. Were goals defined, decomposed, and architected — or just stated? |
Stage 3: Process Analysis | P2 – Process | Flow bottlenecks. Do the operational processes support the intended outcome — or are they fragmented? |
Stage 4: System Analysis | P3 – System Logic | Logic conflicts. Are business rules orchestrated — or buried in code and configs? |
Stage 5: Component Analysis | P4 – Component Specs | Localized design flaws. Do components align with enterprise rules — or operate in isolation? |
Stage 6: Implementation Analysis | P5 – Implementation | Deployment realism. Were projects delivered structurally — or only technically? |
Stage 7: Operational Analysis | P6 – Operations | Behavioral fallout. What are the real-world symptoms? Are we fixing root issues or firefighting visible ones? |
Flexible Application: Subfunctions or Enterprise-Wide
One of the unique strengths of Stage 2–7 is its scalability.
You can apply it:
To a micro-function like “Upgrade Eligibility Logic” inside Boarding
Or to an entire flow — like Passenger Disruption Handling
Or across the entire Passenger Services architecture
It doesn’t assume success or failure. It simply reveals what was expected, what was actually delivered, and what was never architected at all.
Summary
Stage 2–7 is not a report. It is a structural anatomy scan.
It allows Airport Passenger Services to ask:
Which strategies were supposed to be served by this system?
Which processes were supposed to work together?
Which rules govern this behavior — and where do they live?
Which components broke the chain?
Which deployments failed to deliver enterprise change?
And most importantly:
What part of the architecture was never built — and is still missing?
