Most operating-model redesigns fail a test they never set. The team gathers, someone sketches a new structure, opinions are traded, a design is chosen, and months later nobody can say why that design rather than another. There was no criterion. Every choice was a matter of taste dressed as judgment, because the one thing that would have made the choices decidable was skipped: a written statement of what the operating model actually had to enable.
That statement is a design parameter, and it's the hinge the whole redesign turns on. Get the parameters right and the design argues itself. Skip them and you're back to redrawing the org chart and hoping.
What a design parameter is
A design parameter is an explicit statement of what the operating model must enable, derived directly from the strategy. Not a goal, not a value, not an aspiration. A criterion you can test a design against.
The distinction between a goal and a parameter is the whole game. "Improve the customer experience" is a goal. It sounds good and decides nothing, because every proposed design can claim to serve it. "Any client can complete this service unassisted, in under ten minutes, from any channel" is a design parameter. It excludes things. A design either meets it or it doesn't, and you can tell which. The test of a parameter is simple: could two smart people disagree about whether a given design satisfies it? If yes, it's still a goal. Sharpen it until the answer is no.
Good operating models are built on ten to fifteen of these, no more. They are the criteria every subsequent choice gets held against: which capabilities to prioritise, which services to stand up, which channels to offer, where to centralise and where to let regions vary. When a design decision comes up, you don't argue taste. You ask which parameter it serves, and whether it serves it better than the alternative.
Where they come from
Design parameters aren't invented in the operating-model workshop. They are derived from the strategic choices, which is what makes them the hinge between strategy and operations rather than a fresh set of opinions.
The Strategic Choice Cascade makes the choices explicit: where the organisation will play, how it will win, and what it will refuse to do. Each of those choices reaches down into the operating model as a parameter. If the how-to-win is "win on speed of access," a parameter is "the front door must resolve the common request without a handoff." If the where-to-play excludes a segment, a parameter is "the model carries no capability dedicated to serving it." The parameters are the strategy, restated as things the machine must do. That is why an operating model built without them is built on an assumed strategy: the choices were never translated into criteria, so the design couldn't have been derived from them.
A real example makes it concrete. A large government human-services transformation set its parameters up front: empower citizens toward self-sufficiency, improve ease of access, use efficient self-serve channels where people have the capacity. Every design decision that followed, the self-service pathway, the channel mix, the integrated front door, traces back to one of those. The parameters did the deciding. The workshops did the drawing.
Why they're conceptual-design work
Here is the part that changes who should be in the room. Translating a strategy into the parameters an operating model must satisfy isn't strategy analysis and it isn't project management. It is conceptual design: taking an intent and expressing it as the criteria a structure must meet. That is precisely what business architecture does. It produces the blueprints and roadmaps that sit between a strategic choice and the thing that gets built.
Which means the business architect doesn't wait downstream to receive the parameters and dutifully design against them. The architect belongs at the table where the parameters are formed, because getting them right is a design task, and a strategy translated into weak or missing parameters will produce a weak operating model no matter how well the later work is done. Leave that translation to chance, and the strategy writes cheques the operating model can't cash: commitments made with no account of what the machine can actually deliver. The parameters are the hinge between the strategist and the machine, and someone has to own drawing them well.
How to write them
Start from the strategic choices, not from a blank org chart. For each how-to-win and each where-to-play choice, ask: what would the operating model have to be able to do for this to be true? Write the answer as a testable statement. Then pressure-test each one against the disagreement test, and against a real stakeholder scenario: take a specific person with a specific need, walk them through the model the parameters imply, and see whether the parameters actually hold up when a human hits them.
Keep the set small. If you have forty parameters, you have a wish list, not a design brief; the point of parameters is to constrain, and a constraint that excludes nothing isn't one. Ten to fifteen sharp ones will decide more than fifty vague ones.
Then use them ruthlessly. Every design choice, every service you stand up, every proposed reorg, gets held against the parameters. The question is never "does this feel right." It is "which parameter does this serve, and does it serve it better than what we have." That is the difference between an operating model you designed and one you reshuffled: the designed one can show its work.
Capture your design parameters at the top of the free Service Operating Model Canvas, then design the rest of the model against them; the full argument is in the operating model pillar. The Closing the Strategy-Execution Gap course teaches how to make the strategic choices that design parameters are derived from.