Big Bang, Fixed Date, Low Trust
A regional bank’s CIO has committed to replacing its IT service management tool across five countries in 90 days to cut licence costs by 20%. The budget is fixed and there is no contingency. The current tool is heavily customized; two countries have local regulatory reporting that depends on those customizations. Staff morale is low after a previous failed ERP rollout, and the service desk manager warns that a big-bang cutover during quarter-end will risk payment processing. The CIO cites “progress iteratively with feedback” but insists on a single go-live date to satisfy the board.
1. Which ITIL guiding principles are in tension here? Explain the tension rather than just naming the principles.
Read the worked answer
Several principles pull against each other:
- Progress iteratively with feedback versus a single go-live date. Iteration requires room to learn and adjust. A single fixed date turns learning into a pass/fail event and discourages early feedback.
- Start where you are versus the replacement mandate. The existing customizations and regulatory reports are assets, not merely legacy. Ignoring them discards what already works.
- Collaborate and promote visibility versus a top-down cost decision. The service desk manager’s warning about quarter-end is data about risk, not resistance. If it is not made visible, the decision is made blind.
- Keep it simple and practical versus five-country scope at once. A single big-bang across all five countries multiplies complexity at the worst possible moment.
The core tension is between cost control and operational risk. Naming principles does not resolve it; the trade-off must be made explicit.
2. Recommend a course of action that respects both the board’s cost target and the operational risk. Justify using at least two guiding principles.
Read the worked answer
Recommend a phased approach that still attacks the cost target:
- Segment by country. Move the three low-customization countries first within 90 days. Keep the two countries with regulatory reporting on the current tool until their requirements are proven in the new one.
- Start where you are. Reuse existing regulatory reports and interfaces where possible instead of rebuilding everything.
- Progress iteratively with feedback. Define a minimum viable migration for one country, with explicit exit criteria and a review before the next country.
- Protect quarter-end. Freeze cutover during payment processing and schedule around it.
- Fund contingency by descoping non-critical customizations, not by cutting testing.
Justification: the savings remain achievable because the majority of licences can still be retired, while the highest-risk countries are not forced into an unsafe cutover. The board gets a credible date and the service desk gets protection for payment processing.
3. What would you advise the CIO to do first, and what would you advise against?
Read the worked answer
First, convene a short risk-and-value workshop with the CIO, the service desk manager, and representatives from the two regulated countries. Agree the phased scope and the quarter-end freeze, and make the trade-off visible with a simple option comparison: big bang versus phased.
Advise against:
- A single big-bang cutover across all five countries.
- Cutting testing or contingency to hit the original date.
- Treating local regulatory requirements as “customization to remove” without validation.
- Using the language of iteration while refusing to change the plan when feedback arrives.
The CIO needs a defensible plan, not a heroic one.