The Framework Everybody Quotes and Nobody Follows
Technology, people, and process. The trinity appears in almost every enterprise transformation programme brief, usually in the form of a commitment that “this transformation addresses all three dimensions, not just the technology.” The commitment is almost always sincere. The execution almost always fails to deliver it, for reasons that have more to do with how transformations are structured than with the intentions of the people running them.
The reason is sequencing. Technology is the most visible investment and the one with the clearest procurement process: requirements are defined, vendors are evaluated, contracts are signed, implementations begin. People change management and process redesign are less visible, their outputs are harder to specify in advance, and their procurement is structurally disadvantaged: the technology vendor has a clear proposal, a clear deliverable, and a clear implementation methodology. The change management consultant has a framework and a process. The process redesign work has a workshop structure and a set of deliverables that sound less tangible than a software system.
The result is that technology is specified first, contracted first, and implemented first. People and process change begin alongside or after the technology implementation, designed to fit the technology choices that have already been made rather than preceding them.
This sequencing is backwards. And it explains a disproportionate share of transformation failures that are blamed on technology, change resistance, or insufficient training, but are structurally caused by getting the order wrong.
Why Technology Must Come Last
The transformation sequencing that works puts people and process design before technology decisions for a specific reason: the best technology for a given transformation depends on what the people and process are going to be after the transformation, not what they are before it.
Consider an enterprise resource planning implementation. The ERP system is selected based on the business processes it must support. If those processes are designed before the technology is selected, the technology selection can be made against a clear specification of what the system must do in the future state. If the processes are left to be defined after the technology is selected, the implementation team is forced to design future processes around the capabilities of the technology they have already contracted, rather than selecting technology that enables the processes the organisation needs.
The people dimension has the same sequencing implication. If the skills and roles required to operate the future state are understood before technology selection, the technology selection can account for the skill level of the operating team. A highly automated solution that requires specialist skills to operate is the right choice if the operating team will have those skills; it is the wrong choice if the team will not.
The enterprise that sequences technology before people and process is making technology decisions without complete information. The probability of making the right decision with incomplete information is lower than with complete information, which is why the wrong sequencing produces the wrong results more often.
What “People First” Actually Requires
People-first sequencing does not mean delaying technology decisions indefinitely while the people change management programme runs its course. It means completing the people-dimension analysis that should inform technology decisions before technology decisions are locked in.
The people-dimension analysis that precedes technology selection has three components. Skills assessment: what skills does the future state operating model require, and what is the gap from the current population? This assessment determines whether the transformation is feasible with the current team through training, or requires new hiring, or requires a technology choice that minimises the skill requirement. Role redesign: what roles does the future state require, and how are they different from current roles? This redesign determines what the change management programme needs to achieve and provides a clear target for training programmes. Leadership capability: does the management structure have the capability to lead the change that the transformation requires? This assessment determines what leadership development investment the programme needs.
None of this analysis takes months. It takes weeks of structured work with the operational leaders who know their people and processes. The analysis can run in parallel with the early stages of the technology procurement process, as long as the decisions it informs come before the technology contracts that lock in the direction.
What “Process First” Actually Requires
Process-first sequencing means designing the target operating processes before selecting the technology that will support them. This sounds obvious and is consistently not done, for the reason described above: the technology vendor is in the room with a methodology and a proposal before the process redesign work has started.
The process design work that should precede technology selection starts from the business outcome the transformation is designed to achieve. What does the process need to produce? What is the measurement of success? What are the constraints the process must operate within? These questions define the requirements that both the process design and the technology selection must satisfy.
The process design work that is done in this frame produces a future-state process specification that is specific enough to evaluate technology against. The technology evaluation that follows is comparing vendors against a defined specification rather than evaluating which vendor’s existing capabilities are closest to what the organisation might need.
This sequencing requires delaying the technology vendor conversations until the process work is complete enough to inform them. This delay is uncomfortable because it postpones the visible progress that technology procurement represents. But the alternative is technology procurement that produces the wrong system for the future state, because the future state was not defined when the system was selected.
The Transformation Programme Structure That Gets It Right
The programme structure that implements this sequencing has a design phase that precedes the technology procurement phase. The design phase produces the people analysis, the process design, and the operating model specification that together define what the technology must support. The procurement phase uses that specification to evaluate and select technology. The implementation phase deploys the technology against the design.
This structure adds a design phase that many transformation programmes skip. The typical justification for skipping it is time pressure: the implementation needs to begin immediately to hit the deadline. The practical consequence of acting on this justification is a technology implementation that delivers a system which does not match the future state that the transformation was designed to produce, and a change management programme that is fitting people into a technology decision they had no influence over.
The transformations that succeed at this more ambitious sequencing are the ones where the sponsoring executive is willing to take the time required for the design phase, and is willing to hold the technology procurement until the design phase produces the specification that procurement needs. This requires patience that is in short supply in most transformation programmes.
It is also the sequencing that produces the outcomes the transformation was invested in to achieve.