by Daria Kniese
THE FASHION DECISION ECOSYSTEM™
Executive Essay No. 04
The Work You Skip Today Becomes the Cost You Pay Tomorrow. A company can buy precisely the software it requested and still fail to buy the capability it needed.
Why successful transformation begins long before the first sprint—with the right people, an honest diagnosis, and the capacity to deliver.
There is a peculiar optimism surrounding the beginning of a business transformation. The strategy is compelling. The business case has been approved. The roadmap is ambitious. The technology promises to resolve problems the organization has lived with for years. A project team is assembled. And then comes a question that perhaps deserved greater attention before the budget and delivery timeline were approved:
Who is actually going to do the work? Naturally, the organization’s strongest people. The ones who understand the business, know its processes, and somehow keep everything running even when the systems don’t particularly cooperate. An excellent choice. Except those people already have full-time jobs. And the business, understandably, still needs to operate.
This is the first contradiction of transformation: the people most capable of changing the business are often the people the business can least afford to release. The challenge is not a lack of commitment. It is the assumption that organizational capacity, process knowledge and decision-making authority will somehow become available once implementation begins. Unfortunately, none of these appears automatically with an approved business case.
Best People Are Not an Infinite Resource
Daily operations generate the revenue that funds transformation and pays salaries. Protecting business continuity while investing in future capabilities is therefore an entirely rational executive priority. The difficulty arises when the same capacity is committed twice.
Consider a department head or lead appointed as the principal business expert for a major system implementation. The project requires workshops, requirements validation, design decisions, uaser acceptance testing and sign-offs. Meanwhile, the department still requires leadership, prioritization, coaching and operational approvals.
When the transformation takes priority, operational decisions slow down. When daily business demands attention, the project waits. What initially appears to be one individual’s scheduling challenge can become a dependency bottleneck affecting an entire function.
An overcommitted expert is not two resources. It is one resource with two competing priorities. The answer is not necessarily to increase project headcount. Nor is it to remove every expert from their operational responsibilities. It is to make the trade-off explicit before delivery commitments are finalized.
Which capabilities are indispensable? How much dedicated capacity will discovery, design, testing and rollout require? Can responsibilities be redistributed, temporary operational coverage arranged or timelines adjusted? Who will make decisions for the operational team while its manager is occupied?
Capacity requirements should also evolve with the delivery lifecycle. A business expert may be needed intensively during design and acceptance testing but less frequently during technical configuration.
The objective is not to extract every available hour from the organization’s strongest people. It is to protect their ability to deliver change without undermining the business that depends on them.
A marathon runner would hardly prepare for a major race by running another marathon every afternoon and expect to perform at the same speed as the day before. Transformation teams deserve a more realistic training plan.
Don’t Redesign a Business Challenge You Haven’t Fully Understood
Once capacity has been addressed, another question becomes unavoidable. What exactly needs to change? Organizations generally understand their strategic ambitions: greater efficiency, faster decisions, better data, improved integration or higher profitability. But strategic ambition answers the “Why?” but not “What needs to change?” and “How”, this is defined through the business requirement(s).
A technology initiative may begin with a clear vision of the desired future while having only a partial understanding of the processes, responsibilities and system dependencies that support today’s operations.
That gap becomes particularly expensive when existing operational requirements surface during User Acceptance Testing (UAT), after substantial design and development work has already taken place. At that stage, the consequences may include redesign, costly scope extension, delayed rollout and commercial change requests.
New requirements will always emerge as organizations learn. No diagnostic can eliminate uncertainty. The preventable problem is different: discovering established business requirements as late as, when the organization is supposed to be validating the solution.
UAT (User Acceptance Testing) should validate whether the solution works—not become the most expensive requirements workshop in the project.
This is why an operating-model diagnostic belongs before vendor selection and major delivery commitments. Not as an elaborate documentation exercise. As a mechanism for improving investment decisions.
Three Perspectives. One Operating Reality.
A useful diagnostic examines three interconnected dimensions:
- Processes. How does work actually move across functions? Where do handovers fail, decisions stall or manual workarounds compensate for structural weaknesses?
- People. Are capabilities, responsibilities and decision rights sufficiently clear? Where are specialist knowledge, capacity or authority missing?
- Systems and Data. How effectively does the technology landscape support operations? Where do fragmented applications, unreliable integrations or unclear data ownership introduce constraints?
Assessing any dimension in isolation produces an incomplete picture, similar to driving a car at night with the parking lights on instead of high beams. Or similar to standing at the mountain during sundown and trying to descend down the hiking road. You will see glimpses of the road which will make the descent at best rather uncomfortable and worst dangerous.
A slow fabric approval process, for example, might appear to require workflow automation. Yet its underlying cause could be the cumbersome user interface (UI) requiring the user lots of repetitive manual input. Hence, a workaround in Excel is created to keep the work going. The solution would have been to enhance and simplify the user input during swatch or lab dip requests in the system. Automating it would hardly solve the issue.
Listen & Understand Before Designing
A structured diagnostic begins with the people closest to the work. Quantitative maturity assessments (e.g. survey) can reveal recurring bottlenecks, capability gaps and differences between functions. Operational users and team leads are particularly important because they understand the exceptions and informal workarounds that rarely appear in executive process summaries. Confidential interviews then explain what sits behind the numbers and gives the people the freedom to “spill the beans”.
The sailboat retrospective offers a simple but effective structure: identify the wind that moves the business forward, the anchor holding it back, the obstacles ahead and the future beacon capabilities represented by the lighthouse.
This distinction matters. Transformation should preserve what already works, correct what does not and anticipate the demands of the future. Business findings must then be connected to the existing technology architecture, interfaces, data flows and target-state constraints.
A process that looks straightforward to its users may depend on several interconnected applications and a master-data structure nobody wants to disturb. Such dependencies are better discovered before a vendor evaluation.
Finally, map the processes that matter: roles, activities, decisions, handovers, exceptions and systems. Use a collaborative board like Miro, Mural, Microsoft Whiteboard or even PowerPoint – whatever is available at your disposal.
A focused diagnostic can begin with a nominated product manager, supported by an operational expert &/or process owner. It does not need to wait for the entire project team to be assembled.
Nor should it become an endless analysis exercise. Its scope should be proportional to the investment, operational complexity and decisions it must inform. Usually, 1 to 3 months depending on the scope.
Preparation creates value when it reduces uncertainty—not when it postpones every commitment until uncertainty disappears.
Prioritize Business Value, Not the Loudest Request. A diagnostic will almost certainly uncover more potential requirements than the organization can implement immediately. That is not a problem. It is an opportunity to distinguish meaningful business improvements from desirable functionality.
Without an agreed prioritization approach, requirements can become a competition between departments. The strongest case is not necessarily the one supported by the loudest voice or the most impressive presentation.
The more useful questions are related to business value. What financial or operational value will the requirement create? What is the cost of delay? Which risks will it reduce? How closely does it support strategic priorities? What dependencies, delivery effort and ongoing costs does it introduce? Business and technology experts should evaluate these considerations together.
A business-value matrix paired with Eisenhower can establish a consistent basis for prioritization across commercial impact, time criticality, risk reduction, future opportunity and strategic alignment. A simplified urgency-versus-importance view will then help executives discuss sequencing. Mandatory regulatory and business-continuity requirements require explicit treatment rather than being traded away through an average score.
The outcome should be a traceable connection between business problems, requirements, investment decisions and expected benefits. This also creates a stronger basis for vendor selection and solution design. After all, an impressive collection of requirements is of limited value if the organization cannot explain why they matter.
Give the Team the Authority to Use Its Expertise
Once implementation begins, the delivery team’s own operating model becomes just as important as the one it is transforming. An effective arrangement often pairs product management with business expertise.
The product manager contributes product direction, prioritization and delivery coordination. The business expert contributes operational knowledge, process context and the understanding needed to determine whether the solution will work in practice.
These perspectives should work together, not pass decisions between organizational silos. But complementary expertise alone is insufficient. Teams also need clear responsibilities, access to information and authority to make decisions within agreed boundaries.
Operational choices should remain close to those with the necessary knowledge. Decisions involving strategic trade-offs, significant financial commitments or cross-program dependencies should follow appropriate escalation paths.
This is where governance creates value: by clarifying decision rights and accountability, not simply by increasing the number of meetings.
The same pragmatism applies to delivery methodology. Agile ways of working do not eliminate the need to manage budgets, dependencies, risks and commercial commitments. Dedicated project-management expertise may be justified for complex programs, but staffing structures should reflect actual needs rather than an obligation to fill every box in an organizational chart.
„Empowerment without defined decision rights is responsibility with a waiting period attached.“
Daria K.
Change Management Begins Before Change Is Announced
The costs of insufficient preparation rarely disappear. They accumulate.
Unprotected capacity becomes delayed decisions. Incomplete process knowledge becomes late requirements. Weak prioritization becomes low business value. Unclear authority becomes escalation.
Each problem may initially appear manageable in isolation. Together, they consume the resources and management attention intended to deliver the transformation.
This is the economic argument for readiness. The objective is not to eliminate uncertainty through excessive planning. It is to reduce avoidable uncertainty before committing substantial investment—and create a delivery organization capable of responding effectively to what remains unknown.
Change management therefore begins well before the communication campaign, employee training or rollout plan.
It begins when critical people are selected, their capacity is protected, the operating reality is understood, requirements are connected to business value and teams receive the authority to act.
Preparation is not the opposite of execution speed. Done well, it is one of its essential conditions. Because the purpose of doing the work upfront is not to slow down transformation. It is to stop the organization from paying twice for work that should have been done once.
The work you skip today becomes the cost you pay tomorrow. And unlike good preparation, rework rarely comes at a discount.
Kommentar verfassen