An interviewer says - we have about 300 applications, a board that wants a modernisation roadmap, and six weeks. What do you actually deliver at the end of week six?

What the interviewer is testing

Whether you know that a 300-application assessment cannot be done to uniform depth in six weeks, and whether you will say so and propose something better instead of producing a spreadsheet with 300 rows of equal shallowness. They are testing triage, not thoroughness.

The clarifying questions that change the answer

• What decision does the board need to make? A funding envelope, a data-centre exit date, a regulatory commitment and "we should modernise" produce four different documents.
• Is there a hard external date? A lease ending, a vendor end-of-support, a mandate. If so, the roadmap is organised around that date and everything else is secondary.
• What already exists? A CMDB, a licence inventory, a cost centre breakdown, last year's incident data. Six weeks of elapsed time is mostly spent waiting for information that often already exists in finance.
• Who can say yes to retiring something? If the answer is nobody, the retire disposition is unavailable and the roadmap will be more expensive.

What a strong answer delivers

Three tiers of depth, not one.

1. All 300, shallow, from data you do not have to gather by interview: run cost, licence renewal dates, end-of-support dates, user count, change volume from the ticket system, incident count. This is a week of work if finance and the service desk co-operate, and it is enough to sort.
2. The 30 that matter, assessed properly: the ones carrying most of the cost, the risk or the business capability. Behaviour inventory, change-cost measurement, data ownership, integration map, a disposition with a reason.
3. The 3 to 5 that start now, each with a named owner, a first milestone inside 90 days and a decommissioning condition written down at the start.

Plus two things the board will actually use: the retire list - usually 15% to 30% of a 300-app estate has no users or a successor already live, and it is the only part of the roadmap that saves money inside a year - and a cost of delay per quarter for the top risks, so deferral has a price.

Common weak answers

• The 300-row disposition spreadsheet. Every row has a Six Rs letter assigned by a consultant who spent 40 minutes on it. It is confidently wrong in the places that matter and nobody can tell which.
• Starting with the hardest system because it is the most important. It is also the one that will consume the six weeks and produce no roadmap.
• A target architecture. It is not what was asked for, it will be wrong before it is used, and it hides the fact that no sequencing decision has been made.
• Refusing on the grounds that six weeks is not enough. The constraint is real; the answer is to change what is delivered, not to decline.

What a strong answer adds

The organisational layer. Say which decisions the roadmap needs from the board rather than from the architects - who owns retirement, whether a feature freeze during migration is acceptable, whether the legacy run cost moves into the programme budget. Those three answers change the sequencing more than any technical finding, and asking for them in week six is how a roadmap survives contact with the next budget cycle.