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 were made (or skipped) in the requirements and design workshops at the front of the engagement: what the program would do, who it would serve, and what the system would have to look like to support it. The technology, the change management, and the fight over scope and budget all came later. The seeds were planted in those early rooms.

Here’s how to run those rooms: what a requirements workshop is for and how it differs from a design workshop, why the sequence matters, what the steering team and senior leadership have to do besides show up, and how the workshops anchor the scope and budget conversations that follow.

Requirements and design are two separate workshops

I see a lot of programs run something called a “workshop” that mashes requirements and design into one event. Sometimes the schedule is tight and they compress it on purpose. More often nobody on the team has separated the two in their own head, and the agenda goes wherever the loudest voice in the room takes it.

The two workshops answer two different questions:

• Requirements workshops answer: what does the organization need this program to do, for whom, and why? The output is a prioritized statement of needs, written in business language rather than system language.
• 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, and 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 best way I know to explain the difference is building a house. If you’ve lived through a custom build, or watched a friend go through one, you’ve seen the same patterns 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 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. Either way you can recover, but only at a cost you never would have agreed to up front.

Asset-management programs work the same way. The requirements workshop is the family conversation about how the organization 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 requirements workshop has one job: get what the organization needs the asset-management program to accomplish out on the table, ranked by importance, in language that survives the project team turning over. You walk out with a working agreement about what the program is for. A vendor demo, a process map, or a wish list doesn’t count.

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 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 one prioritization framework the whole way through. The cleanest one I’ve seen is a 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 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 have to be there. Miss any one of them and the workshop is dead:

• 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 add up 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. They don’t need to attend every working session, only 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 instead of a requirements list. Ranking is the only step that constrains the design phase, so 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. The only fix I know is active facilitation, including calling on the quieter participants by name.
• 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

Don’t start design workshops until the requirements workshop has closed. Closing it doesn’t have to be elaborate; a signed two-page summary works fine. It has to exist. Without it, every design decision gets re-argued against a moving target, and the design phase balloons.

The design workshop turns 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 touches: the ones in scope, not every process.
• 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 nobody loses the thread, with enough of a gap to check decisions against what really happens in operations. 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.

What separates a good design workshop from a bad one is tracing every decision back 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, but they’re the budget overrun you’ll be explaining in nine months.

The dependency on requirements

The design workshop is boxed in by the prioritized requirements list. That’s a good thing. 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 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

Senior leadership should care about these workshops as much as the project team does. This is where scope and budget get fixed in practice. You can always rebaseline formally, but every later conversation refers 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 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 need real work from the steering team and senior leadership. Sitting in the room is not enough. 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 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.

That’s the difference between a steering team that steers and one that just attends. The workshops are where you’ll see it 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. Skip this work and you pay for it later, with interest.

The best practitioners I’ve worked with treat requirements and design workshops as the highest-value 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. So can your team state its top five requirements without naming a software product? And if a senior leader asked to add a wing tomorrow, who would tell them no?