Necessary system migrations become, openly, the occasion to redesign workflows and roles, so the organizational changes ride the program's momentum and deadlines.
Borderline: whether this move is justified depends on the situation, and only the person in it can judge.
An example
Sponsoring the move to a new ERP, the chief financial officer of a frozen-foods manufacturer wanted something more from it: one central procurement office and a single scheduling model for all six plants. At the first steering committee, the chief financial officer put two lists on the table. One was what the platform required. The other, titled our choices, held the organizational changes: plant scheduling centralized, purchases above $5,000 routed to central procurement, eleven scheduler roles retired over eighteen months. Each choice had its own business case and went to the executive committee for approval. Plant managers argued against the scheduling change in three workshops and won a two-year transition and a local planning role at each plant. The rest passed with the blueprint, and the program hit its go-live date.
Why it works
Bundling the organizational choices into an approved technical program lets them ride its momentum: the blueprint has deadlines, the steering committee meets anyway, and each change is decided once, which makes it easier to pass. The migration also exposes how much the old workflows depend on workarounds, which makes defending them harder. Opposing a specific change means slowing a program the company needs, which is costlier, and after go-live the choices are fixed in the system. It works best when the program is genuinely necessary, blueprint deadlines are real, and the sponsor can put the choices before the people who approve such changes.
The thinking behind it
Erving Goffman Erving Goffman's Frame Analysis: An Essay on the Organization of Experience (1974) describes frames, the organizing principles people use to answer the question of what is going on here. A system migration is usually framed as a technical project, and decisions inside that frame are read as configuration, which is why organizational choices travel easily with it. The clean form's second, labeled list tells everyone which frame each decision belongs to. Presenting a chosen change as a platform requirement would be what Goffman calls a fabrication.
Thomas C. Schelling Thomas Schelling's The Strategy of Conflict (1960) argues that the power to bind oneself can be a source of strength: a party that visibly removes its option to retreat forces others to adjust. A blueprint with a go-live date, a signed vendor contract, and a board-approved budget is that kind of binding. Choices made inside it become hard to reopen, which is why opponents need to contest them during design and why the sponsor gains by deciding them there.
When it fits
Right when a system migration is genuinely necessary and the organizational changes you want are ones you would defend on their own merits. It needs sponsorship of the program, a seat on its steering committee, and authority, or a route to the people with authority, to approve role and reporting changes.
How to use it well
Separate the two lists from the first meeting: what the platform requires and what you are choosing.
- Write a business case for each organizational choice and take it through the approvals it would need on its own.
- Use the blueprint calendar as the decision calendar, so choices are made when the design needs them.
- Bring affected managers into the design workshops early and give them real points to win.
- Fund transition support, such as retraining and phased role changes, inside the program budget.
Say plainly, in every forum, that the choices are yours.
What it costs and where it backfires
Tying contested changes to the program can slow or endanger the program itself if the fights get bitter, and people may blame the platform for every grievance for years. The clean form depends on one thing: never saying the system requires what you chose. Once a choice is presented as a technical requirement it is not, or the vendor is asked to say so, the move rests on a false statement, and it will come out the first time someone asks the vendor directly.
When it is used on you
Before blueprint sign-off, ask the vendor for a written statement of what the platform requires and what the sponsor chose. Request that organizational changes go through their own approvals, and organize affected managers while requirements are still open, because after go-live the choices are fixed.