Why requirements and design workshops decide the outcome.

Most asset-management programs that fail in year two were already failing in week six. The decisions that shaped the outcome, what the program would actually do, who it would serve, what the system would have to look like to support it, were made (or quietly skipped) in the requirements and design workshops at the front of the engagement. The technology came later. The change management came later. The fight over scope and budget came later. But the seeds were planted in those early rooms, and what got planted determined what grew.

This piece is about how to run those rooms. Specifically: what a requirements workshop is for and how it’s different from a design workshop, why the sequence matters, what the steering team and senior leadership have to actually do (not just attend), and how the workshops anchor the scope and budget conversations that follow.

The two workshops are not the same workshop

Plenty of programs run something called a “workshop” that blends requirements and design into one event. Sometimes that’s a deliberate compression because the schedule is tight. More often it’s because nobody on the team has clearly separated the two in their own head, and the agenda drifts wherever the loudest voice in the room wants it to go.

The two workshops answer two different questions:

• Requirements workshops answer: what does the organization actually need this program to do, for whom, and why? The output is a prioritized statement of needs, written in the language of the business, not the language of the system.
• Design workshops answer: given those needs, what does the program have to look like (process, data, roles, technology) to deliver them? The output is a concrete enough picture that a vendor, an integrator, or an internal team can build to it.

Blend them and one of two things happens. Either the design conversation drowns out the requirements conversation (the loudest technical voice anchors the whole engagement around their preferred solution before anyone has agreed on the problem), or the requirements conversation never ends and the design phase becomes a six-month exercise in stakeholder management. Both outcomes are expensive. Both are common.

If you can’t state your top five requirements in business language without mentioning a software product or a module name, you haven’t finished the requirements workshop. You’ve started the design workshop early.

A familiar comparison: building a house

The cleanest analogy I know for the requirements-versus-design distinction is building a house. Anyone who has lived through a custom build, or even watched a friend live through one, has seen the same patterns play out at smaller stakes.

The requirements conversation is the one you have with your spouse before you ever talk to a builder. How many people live here. Do you cook every night or twice a week. Do you have kids, in-laws, a home office, a dog. How long do you plan to stay. What’s the budget envelope. What absolutely cannot be compromised, and what would be nice if it fits. None of that conversation mentions framing, electrical, or which countertop material you prefer. It’s about how the family actually lives.

The design conversation is the one you have once those requirements are settled. Now you sit with an architect and a contractor and figure out: where the load-bearing walls go, where the kitchen lands relative to the dining area, how the bathrooms plumb together for cost, what the roofline does, how the budget allocates across rooms. The decisions are concrete, the trade-offs are visible, and the builder can finally give you a real number.

Skip the requirements conversation and you get a beautiful four-bedroom house with no home office in it, and you’re tearing out walls in year two. Skip the design conversation and you signed off on “open concept with a primary suite” without anybody drawing the plans, and now you’re picking finishes with no idea where the load-bearing walls live. Both are expensive. Both are recoverable, but only at a cost most people would not have agreed to up front.

Asset-management programs work the same way. The requirements workshop is the family conversation about how the organization actually lives. The design workshop is the architect-and-contractor conversation about how to build it. And the steering team plays the role of the homeowners: the only people who can commit, who have to defend the boundaries when the in-laws suggest adding a wing, and who are the ones writing the check when the budget conversation finally happens.

Requirements workshops: purpose, method, and the people who must be there

The purpose of a requirements workshop is unglamorous: surface what the organization actually needs the asset-management program to accomplish, ranked by importance, framed in language that survives the project team turning over. That’s it. It’s not a vendor demo. It’s not a process map. It’s not a wish list. It’s a working agreement about what the program is for.

What a good requirements workshop produces

• A prioritized list of business requirements, usually 15 to 40 items, expressed as outcomes the business needs (“we need to defend the capital plan to a board on a 90-day cycle,” not “we need a dashboard”).
• Explicit must-have versus nice-to-have ranking, agreed by the people in the room with the authority to make that call.
• A named owner for each requirement, the person who will sign off later that the design actually delivers it.
• A short list of out-of-scope items, with the reasoning recorded. Future leadership turnover will want to know why something was excluded.

Method

Run it in two to three working sessions, not one. The first session collects raw needs from each represented function (operations, maintenance, capital planning, finance, IT, executive sponsor) without challenge or filtering. The second session consolidates duplicates, surfaces conflicts, and forces ranking. The third, if needed, resolves the contested items with the steering team in the room.

Use the same prioritization framework throughout. The cleanest one I’ve seen is a simple two-axis call: business value (how much does delivering this move the program forward) and regret cost (how much pain do we wear if we don’t deliver this in the first release). Most teams find that what’s low-value-and-low-regret is genuinely deferrable, what’s high-value-and-high-regret is non-negotiable, and what’s contested is almost always in the high-value-but-low-regret quadrant, where the conversation belongs.

Who has to be in the room

Three groups, and missing any one of them quietly kills the workshop:

• The frontline people who will use the program day-to-day. Supervisors, planners, field technicians, reliability engineers. They surface the requirements that consultants and executives consistently miss, the small daily frictions that compound across a year.
• The functional decision-makers who own the budget for their part of the work. Finance, IT, the heads of operations and maintenance. They’re the ones who will be asked to fund the design that flows from the requirements; if they aren’t in the room, the design will be unaffordable when it lands on their desk in six weeks.
• The executive sponsor or steering team chair. Not for every working session, but for the prioritization moments. Their job in the room is to make the trade-offs the working group can’t make on its own, and to commit to them publicly so the design phase doesn’t spend its first month relitigating the requirements.

What goes wrong

The recurring failure modes:

• Vendor or technology talk leaks in early. Somebody starts a sentence with “in our current Maximo configuration” or “the SAP world calls this” and the conversation drifts toward what the existing tool can do instead of what the business needs. The facilitator’s job is to redirect, politely but consistently, every single time.
• Nobody ranks. The group surfaces 47 needs, agrees they’re all important, and leaves. Now you have a wish list, not a requirements list. Ranking is the only step that actually constrains the design phase. Don’t skip it.
• The senior person dominates. Same pattern as steering teams. The most senior voice in the room anchors the ranking, the quieter functional experts adjust their stated needs to match, and the workshop captures the most senior person’s opinion rather than the organization’s actual requirements. Active facilitation, including direct invitations to the quieter participants, is the only known fix.
• The requirements never close. The team keeps “refining” the list for weeks. At some point somebody with authority has to declare the list finished and move on. That’s usually the steering team’s call.

Design workshops: turning requirements into something buildable

Design workshops can only start after the requirements workshop has closed. The closure doesn’t have to be elaborate, a signed two-page summary works fine, but it has to exist. Without it, every design decision is open to re-litigation against a moving requirements target, and the design phase will balloon.

The purpose of a design workshop is to translate the prioritized requirements into a concrete picture of the program: the processes, the data model, the roles, the integrations, the cadence, and the technology footprint required to deliver what the business agreed to in the requirements phase. The output should be detailed enough that a budget can be built against it and a vendor or integrator can scope against it.

What a good design workshop produces

• Future-state process maps for the handful of workflows the program actually touches. Not every process. Just the ones in scope.
• A target data model, at least at the level of: what are the master objects (asset, location, work order, plan), what are the key attributes, and how do they relate. The asset hierarchy decision belongs here.
• A clear role and responsibility map for who does what in the future state. RACI, swim lanes, or a similar artifact. Vague role definitions are the most reliable predictor of post-launch confusion.
• An integration and reporting picture at a level of detail sufficient to scope the work. Which systems exchange which data, how often, and who owns each integration end.
• An implementation sequencing recommendation: which capabilities go live first, which follow, and what dependencies link them.

Method

Design workshops are denser and longer than requirements workshops. Four to eight working sessions is typical for a mid-sized program, scheduled close enough together that context isn’t lost between them but with enough gap to let the team validate decisions against real operational reality. Each session has a defined slice of the design as its agenda: process one session, data model the next, roles after that, integrations and reporting toward the end.

The discipline that separates a good design workshop from a bad one is the explicit traceback to a requirement. Every design decision should be answerable to the question “which prioritized requirement does this serve, and how?” If the answer is “none, but it’d be nice,” the decision belongs on the deferred list, not in the design.

The fastest way to wreck a design phase is to allow design decisions that don’t map to a documented requirement. They sound harmless. They’re the budget overrun you’ll be explaining in nine months.

The dependency on requirements

Design workshops inherit, and are constrained by, the prioritized requirements list. That’s a feature, not a bug. When the design team hits a contested decision (do we model contractors as users or as a separate object, do we centralize work-order intake or keep regional intake), the requirements list is what resolves it. Pull up the relevant requirement, read it aloud, ask which design option better serves it, and move on.

This is why the requirements workshop has to actually close. If the requirements list is still soft, the design team will spend half its time re-arguing scope every time a hard decision comes up. You’ll watch what should have been a four-week design phase turn into a twelve-week design phase, and the cost will land in the budget conversation that follows.

Scope, budget, and the alignment that holds the program together

The reason requirements and design workshops matter to senior leadership, not just to the project team, is that they’re where scope and budget get fixed. Not formally fixed, you can always rebaseline, but practically fixed, in the sense that every later conversation references back to what was agreed in these rooms.

From requirements to scope

The prioritized requirements list is the foundation of the scope statement. The must-have requirements become the in-scope work. The nice-to-haves become the option list. The explicitly out-of-scope items become the documented exclusions. When somebody six months in says “we should add this,” the team has a written reason to either accept it (as a change with cost and schedule impact) or defer it (with the original requirement decision referenced).

Programs that skip the requirements workshop, or run it sloppily, have no anchor for these conversations. Scope becomes whatever the loudest stakeholder argues for in any given month, and the program team spends more energy defending the work than doing it.

From design to budget

The design workshop is where the budget actually becomes credible. Until the design exists, any budget number is a guess. Vendors will quote against a design they invented, integrators will scope against assumptions they had to make, internal estimates will be based on past projects that may or may not resemble this one. None of those are defensible.

Once the design exists at the level of process, data, roles, integrations, and sequencing, the budget conversation becomes specific. Each capability has a buildable scope. Each integration has a known endpoint count. Each role change has a training and change-management cost. The total is still an estimate, but it’s an estimate the team can defend in front of a CFO, a board, or a public commission. The same way a builder can’t give you a real number until the plans are drawn, the program can’t give finance a real number until the design has happened.

Leadership and the steering team obligation

Both workshops require the steering team and senior leadership to do specific work, not just to lend their attendance. Three obligations matter most:

• Show up for the prioritization moments. Not every working session needs an executive in the room. But the moments where requirements get ranked, where contested items get resolved, and where the design recommendations get endorsed, those are decisions only leadership can make. Sending a delegate without authority is the same as not showing up.
• Commit publicly. When the prioritization is done, leadership has to say so out loud, in the room, in front of the people who will execute the work. Quiet endorsement after the meeting doesn’t carry the same weight. Public commitment is what makes the requirements stick when the inevitable re-litigation attempts come up later.
• Defend the boundaries. Three months in, somebody senior will want to add something the workshop excluded. (In the house analogy: this is the in-laws calling to suggest adding a wing once the framing is up.) That’s when the leadership commitment gets tested. If the steering team holds the boundary, or formally rebaselines with full transparency on cost and schedule, the program survives. If it quietly absorbs the addition without resetting the budget or schedule, the program enters the slow failure mode that ends with a stalled rollout in year two.

This is what separates a steering team that’s actually steering from a steering team that’s just attending. The workshops are where that distinction shows up first.

When it’s been done right

A pair of workshops that did their job leaves the program with a small set of artifacts that earn their keep for years:

• A prioritized requirements list everybody at the table signed off on, written in business language.
• A design that visibly traces back to those requirements, decision by decision.
• A scope statement built from the requirements and design, not from the project team’s assumptions.
• A defensible budget grounded in the design, not in a vendor’s sales template.
• A steering team that has rehearsed making hard calls together, which is itself worth more than the artifacts.

None of those artifacts are dramatic on the day they’re produced. The drama happens later, when the program survives a leadership transition, defends its budget in front of a board, recovers gracefully from a vendor change, or absorbs a new requirement without breaking the existing ones. That’s the return on doing the workshops well. It compounds across the life of the program, and the programs that skipped this work pay the cost on a slower schedule but with interest.

The best practitioners I’ve worked with treat requirements and design workshops as the most leveraged hours of the entire engagement. Two weeks of patient work at the front, run by people who know how to facilitate trade-offs, save twelve months of expensive backtracking later. The math holds up almost every time.