Large transformation programs rarely fail all at once. More often, they keep moving while gradually losing coherence. Meetings continue, dashboards stay active, plans are updated, and risks are logged, but unresolved decisions, weak assumptions, false closure, integration gaps, and tolerated exceptions begin to travel quietly through the program.
Designed to Drift gives this pattern a name: Program Drift.
Written by a practitioner with nearly three decades of experience in SAP, ERP, and large-scale IT transformation delivery, the book explores how major programs can appear controlled while becoming structurally misaligned beneath the surface. It looks beyond traditional status reporting and asks whether governance is preserving decision quality, execution alignment, integration discipline, and readiness for go-live.
The book introduces practical concepts such as decision latency, false closure, drift premium, execution anchoring, and Program Integrity. It shows how drift emerges in planning, governance, testing, data migration, cutover, executive reporting, and multi-party delivery environments.
This is not a generic project management methodology book. It is a practitioner lens for executives, program managers, PMO leaders, delivery executives, transformation advisors, architects, and workstream leads who need to recognize early warning signals before drift becomes recovery.
Large transformation programs rarely fail all at once. More often, they keep moving while gradually losing coherence. Meetings continue, dashboards stay active, plans are updated, and risks are logged, but unresolved decisions, weak assumptions, false closure, integration gaps, and tolerated exceptions begin to travel quietly through the program.
Designed to Drift gives this pattern a name: Program Drift.
Written by a practitioner with nearly three decades of experience in SAP, ERP, and large-scale IT transformation delivery, the book explores how major programs can appear controlled while becoming structurally misaligned beneath the surface. It looks beyond traditional status reporting and asks whether governance is preserving decision quality, execution alignment, integration discipline, and readiness for go-live.
The book introduces practical concepts such as decision latency, false closure, drift premium, execution anchoring, and Program Integrity. It shows how drift emerges in planning, governance, testing, data migration, cutover, executive reporting, and multi-party delivery environments.
This is not a generic project management methodology book. It is a practitioner lens for executives, program managers, PMO leaders, delivery executives, transformation advisors, architects, and workstream leads who need to recognize early warning signals before drift becomes recovery.
Motion is not Control
Mariners have long understood something that program leaders often rediscover too late: a vessel can move with confidence and still drift off course. The ship may be making speed, the crew may be active, and the instruments may still suggest a disciplined voyage. Yet wind, current, and small course errors can gradually separate the vessel from where it believes it is. The danger is not stillness. The danger is movement without enough correction.
Large SAP programs behave in a similar way. Their motion can be impressive. Design workshops continue, sprint plans are adjusted, dependencies are chased, risks are updated, test readiness is discussed, and the leadership cadence keeps running. The program looks alive because it is alive. People are working hard. But work is not the same thing as control, and one of the easiest mistakes leaders make is to confuse the amount of motion in the system with whether the program is still being steered.
At first, drift often looks like normal program life. A decision slips from one governance meeting to the next. A fit-to-standard question becomes a design exception, then a custom development discussion. A data ownership issue is logged as a risk because nobody is ready to own the cleanup. A clean-core concern becomes a temporary workaround so the sprint can move. One unresolved integration dependency becomes three local assumptions, each reasonable locally and risky at program level.
None of this feels like failure at the time. It feels like normal program life. That is precisely why drift is dangerous. It does not require one catastrophic decision.[1] It can be built from small adjustments that are defensible on their own and damaging in combination.
The SAP-specific version is especially tricky because the familiar Activate and governance artifacts can create a strong illusion of discipline. A program can have fit-to-standard outputs, design decisions, a solution backlog, RICEFW governance, architecture review, change control, dependency logs, sprint ceremonies, test plans, cutover planning, and executive governance. Those mechanisms are all useful, but they do not prove that the program is in control.
A program can be surrounded by control artifacts and still be drifting. The deck may be beautiful, the RAID log may be current, and the meeting cadence may be impressive. None of that proves the ship is still answering the helm. They only prove that the program has structures that could support control if they are converting signal into decision and decision into coordinated action.
The aerospace customer plant carveout showed what this looks like when the structures are present but the proof of control is weak. The program had plans, dashboards, risks, cutover meetings, mock runs, and go/no-go checkpoints. It was not unmanaged in the obvious sense. The problem was that the visible control structure was not backed by enough diagnostic evidence. The project had started late, the methodology had compressed, key carveout definitions were still not strong enough as control artifacts, and testing did not prove that the carved-out plant could actually run after separation.
The control system was weakening underneath the visible machinery. Mock cycles were compressed, testing had not proved operational readiness, open decisions stayed active too close to execution, and the cutover plan increasingly had to absorb unresolved assumptions from earlier phases.
The question is not whether the forums exist. The question is whether they still change the course of the program in time.
That distinction leads to a second one: the difference between movement and coherence.
Motion Without Coherence
Program motion and program coherence are not the same thing. Motion is visible. Coherence is harder to see. Motion appears in workshops, task closure, sprint progress, design documents, test execution, steering decks, and issue logs. Coherence appears when those activities still fit together as one working program system.
A program can have strong motion and weak coherence at the same time. The project manager may be keeping the plan moving. The delivery manager may be protecting team throughput. The delivery executive may be maintaining client confidence and senior escalation paths. The PMO may be maintaining governance discipline. Each role may be doing useful work. The drift question is whether the program still holds together as one coherent operating reality.
Coherence weakens when teams use different definitions of complete, when closed decisions are still disputed operationally, when local plans diverge from the integrated plan, when assumptions replace decisions, or when status reporting becomes cleaner than the facts underneath it. None of these conditions necessarily stops program motion. That is the problem.
This distinction matters because many interventions are aimed at motion. They accelerate tasks, increase reporting frequency, tighten meeting cadence, or ask PMO to chase harder. Those actions may help, but they do not restore coherence unless they reconnect decisions, assumptions, plans, and execution across the program.
In the multi-release S/4HANA transformation, this showed up only around release and test readiness. The official view could show progress through design, build, sprint completion, and test-entry preparation, while downstream teams were working with caveats. Some build work was still moving. Some change requests were still being assessed. Some dependencies were not fully understood. Some readiness activities depended on design and build outputs that were still changing. A milestone could therefore look directionally complete in the governance view while testing, training, controls, deployment, and business readiness were still absorbing open assumptions. The issue was not one missing task. The issue was that “complete” did not mean the same thing across the program.
When motion remains high while coherence weakens, the program has entered the territory this book calls program drift.
What is Program Drift?
Program drift is the gradual erosion of control while execution continues. In practical terms, it is the condition in which delivery activity remains high, governance remains formally intact, and reporting continues, but the program’s ability to convert escalation into decision and decision into coordinated action begins to weaken.
That definition matters because it separates drift from ordinary delay. Every large program has delay. Every large program has issues. Every large program has moments where leadership needs more information before deciding. Drift is different because the control mechanism itself begins to degrade. The program does not merely have unresolved issues. It becomes less able to resolve the issues that matter. Risks remain open, assumptions start doing the work of decisions, and plans begin to differ from how teams are actually working.
In SAP transformation, this often shows up when the official program view and the working delivery view begin to separate. The official plan may still show a coherent path through design, build, test, cutover, and stabilization. At the same time, workstreams may already be operating from private assumptions: that certain data will not be ready, that certain RICEFWs will be pushed, that certain process decisions will be accepted because too much work has already been done, or that a future test cycle will absorb the ambiguity left unresolved today.
A global template rollout makes this separation especially visible, because the whole model depends on the belief that what was proven once can now be repeated safely. In the automotive example, the official story was repeatable template deployment: one country would validate the model, and the next country would inherit a stable template. The working reality was different.
Spain exposed defects in the template, EDI and VDA mapping gaps, hard-coded country-specific elements, user readiness weakness, and data-quality problems after go-live. Those were not minor rollout wrinkles. They were signs that the supposed template still contained unresolved design and localization debt. The lessons were recognized, but the rollout model did not materially change before Mexico moved deeper into execution. That is how drift often starts: the program learns something serious, records it, and then continues as if the operating model can absorb it later.
Figure 1. Official Plan vs. Working Reality. Formal governance artifacts can continue to show control while teams operate through workarounds, assumptions, side decisions, and parallel plans.
Once the program starts working that way, governance is no longer fully steering. It is increasingly reconciling with decisions that have already been made informally by time, pressure, and local necessity.
This is why program drift is not mainly a failure of attention. Senior leaders may be paying attention. They may read the reports, attend the steering committees, ask hard questions, and demand transparency. The problem is that the signals reaching them may no longer describe the program’s true control position. Status reporting is often better at describing completed activity than current decision readiness. A dashboard can tell leaders that a design document was approved, but it may not tell them whether the assumptions underneath that approval are stable enough to survive build and test.
Research on complex systems and escalation of commitment helps explain why organizations often keep investing, executing, and defending a path even when the evidence is deteriorating.[2] In a large transformation, that tendency is reinforced by the cost of stopping. A pause is visible. A missed milestone is visible. A reset requires explanation. Continuing, even under uncertainty, can feel more responsible than slowing down to recover control.
But drift punishes that instinct. The longer a program continues without correction, the more expensive correction becomes.
Drift Begins as a Decision Capacity Problem
The simplest way to understand drift is to start with decision capacity. A transformation needs decisions constantly, but those decisions are not evenly distributed. As the program moves from early planning into design, build, integration testing, cutover, and stabilization, the volume and consequence of decisions increase. More issues become connected. More trade-offs have downstream effects. More choices involve business ownership, not just delivery coordination.
In the early phase, the program may survive with broad direction and optimistic assumptions. Later, those assumptions must become decisions. Who owns the master data? Which local process variants are retained? Which custom developments are accepted, challenged, or deferred? Which integrations are mandatory for go-live and which can be worked around? Which reporting gaps are operationally tolerable? Which defects block progress and which become known issues? Each decision closes one part of the option space and exposes another.
Drift begins when the program needs more decisions than the governance system can close. The demand for direction rises, but the supply of clear decisions does not keep up. At that point, the program keeps moving by borrowing against the future: teams proceed on assumptions, defer hard trade-offs, and leave later phases to absorb decisions that should have been made earlier.
It rarely does.
When decision demand exceeds decision capacity, the program does not stop. It keeps moving through assumptions, delays, and local interpretation.
Figure 2. Decision Throughput Bottleneck. Drift begins when the volume and consequence of required decisions exceed the program’s ability to close them in time.
This is not because people are foolish. It is because large programs put people into decision environments that are genuinely difficult. The information is incomplete, the consequences are distributed, incentives differ by party, and the people asked to decide may not control all the levers affected by the decision.
This is why the lazy version of the story, “leadership just needs to decide faster,” is not enough. Sometimes they do. Sometimes the program has not made the decision safe, clear, or bounded enough to be made at all.
A customer executive may own the business outcome but depend on an SI for delivery truth. The SI may understand the implementation consequence but worry about commercial exposure. SAP can advise against a design direction and make the consequences clear, but the customer owns the final decision. The PMO can see the pattern, track the aging, and escalate the issue, but it cannot close a decision that belongs to business or executive governance.
Decision capacity is more than meeting cadence. A program can have many forums and still lack decision capacity if the forums do not have the right authority, evidence, ownership, timing, and consequence. Herbert Simon’s work on bounded rationality remains relevant because real decisions are made under limits of information, attention, time, and organizational capacity.[3] In large SAP programs, those limits are not academic abstractions. They show up as delayed design calls, reopened decisions, extended alignment cycles, and governance meetings that confirm concern without changing direction.
Once decision capacity is exceeded, the program often reaches for activity that looks like control. It asks for more analysis when the real need is a trade-off. It asks for more reporting when the real need is ownership. It escalates again when the real need is a clear decision right. It schedules another meeting when the real need is closure. Those responses can look productive, but they do not restore control unless they reduce ambiguity and change execution.
Why the Usual Fixes Fail
The instinct is understandable. When leaders feel they are losing visibility, they ask for more information. When decisions are not landing, they add more forums. When execution feels inconsistent, they add more process. The problem is that drift is not usually caused by a lack of material. It is caused by weak conversion. The program already has signals; it is not converting them quickly enough into decisions and coordinated action.
At that point, adding more reporting is often just decorating the ambiguity. The topic gets a slide, a status color, an owner, a due date, and still no decision. That is not control. That is issue curation.
Adding more information can even make the problem worse. It increases cognitive load, widens the decision surface, and gives leaders more ways to postpone the call. A steering committee that receives a dense pack of unresolved items may leave with the impression that the program is being rigorously managed, even though no meaningful trade-off has been made. The appearance of seriousness increases while the decision debt remains.
This is the reporting trap: the program creates more control material, but the extra material does not reduce ambiguity or change what happens next.
Figure 3. The Reporting Trap. More reporting can create the appearance of stronger control while increasing cognitive load and leaving the underlying decisions unresolved.
In SAP programs, the danger is particularly strong because the technical detail can overwhelm the governance purpose. A topic may arrive as a RICEFW count, a defect aging report, a test readiness dashboard, a data conversion metric, or a clean-core exception table. Each artifact may be accurate. But the leadership question is often much simpler: what decision is needed, who must make it, by when, and what changes once that decision is made?
If the program cannot answer that, the artifact has not restored control.
This is why the usual fixes fail. They often expand the material presented to leadership without making the required decision clearer. They also allow leaders to mistake evidence accumulation for progress. There are moments when more analysis is necessary, but there are also moments when additional analysis becomes a socially acceptable way of not choosing.
Effective intervention works in the opposite direction. It narrows the issue, identifies the decision, names the owner, defines the consequence of delay, and translates the decision into operational instruction. It does not ask governance to admire the complexity. It asks governance to reduce it.
That is the first discipline of fighting drift: stop confusing more information with more control.
That confusion is important because information usually increases attention, but attention alone does not steer the program.
The Difference Between Attention and Control
Attention is necessary, but it is weaker than control. A leadership team can pay close attention to a program and still fail to change its trajectory. This happens when attention is not connected to a mechanism that can force a decision, change ownership, remove scope, adjust sequence, or stop work that is proceeding on unsafe assumptions. Many programs confuse the seriousness of the conversation with the strength of the control system. The room feels serious, the questions are sharp, and the minutes are accurate, but execution outside the room continues as before.
In SAP transformations, this distinction is easy to miss because leaders are often surrounded by evidence of activity. There are design readouts, decision logs, RAID logs, architecture forums, sprint reviews, testing dashboards, data conversion reports, and cutover readiness trackers. Each one can be valid, and each one can still fail to answer the control question. The issue is not whether leaders have enough to look at. The issue is whether what they are looking at can change the program before the next dependency locks in.
The split becomes obvious when the formal control view is placed next to how teams are actually keeping the work moving.
A useful leadership question is therefore not, “Was this discussed?” The better question is, “What changed in the program because it was discussed?”
That question is uncomfortable because it tests whether governance did anything beyond acknowledging the issue. A topic can be discussed professionally, captured accurately in the minutes, and still leave the work outside the room unchanged.
If the answer is that another analysis was requested, another owner was asked to validate, or another meeting was scheduled, then the program may have increased attention without increasing control. Sometimes that is necessary. Often it is just delay wearing a suit.
The practical discipline is to connect every major governance discussion to an expected change in the operating system of the program. A decision should change a plan, a scope item, a funding assumption, a workstream instruction, a readiness condition, a risk posture, or an accountability line. If no such change follows, the program should be honest that it has discussed the issue rather than controlled it.
The Customer, SI, and SAP Split
The multi-party structure of SAP programs makes drift harder to detect because no single party owns the whole causal chain. The customer owns the business outcome and the decisions about operating model, process standardization, data ownership, and readiness. The system integrator owns much of the delivery machinery and often controls the day-to-day truth of build, test, integration, and defect resolution. SAP may provide product expertise, advisory input, clean-core guidance, design assurance, or executive oversight, but it does not usually own the customer’s governance or the SI’s delivery model.
That split is normal. It is also a drift risk. A problem can sit between the parties long enough that everyone can describe their part correctly while the program as a whole remains unresolved. The customer may say the SI has not provided a clear recommendation. The SI may say the business has not made the decision. SAP may say the design direction creates risk but cannot force the customer to accept the advice. The PMO may track the issue, but tracking does not create authority.
The result is not necessarily conflict. Often the result is polite ambiguity.
Polite ambiguity is expensive. It costs almost nothing in the meeting and a fortune once teams start building around it.
Everyone remains professional, and the issue remains open. This is one reason drift can be so quiet. It does not need open dysfunction. It only needs enough distributed accountability that the program can continue without one owner being forced to close the loop.
A drift-aware governance model makes these boundaries explicit. For every material issue, it asks which party owns the decision, which party owns the evidence, which party owns the delivery consequence, and which forum has the right to force closure. Without that clarity, the program will repeatedly discover that everyone was involved and nobody was accountable.
The same boundary problem explains why Program Integrity should normally be customer-owned, jointly informed, and independently empowered. The customer owns the business outcome, the operating model consequence, the risk acceptance, the process ownership, the data ownership, and the benefit case. SAP can support the function with solution assurance, clean-core challenge, product-pattern recognition, and transformation advisory. The SI must provide evidence, options, impact analysis, and corrective action. But the SI should not own the integrity function, because the SI is too close to delivery momentum and commercial exposure.
That does not make the SI untrustworthy. It simply recognizes structural position. In the same way, SAP can be a valuable independent input, especially where SAP is not the primary implementer, but SAP should be careful not to appear to substitute for customer governance unless that independence is explicitly contracted and understood. The cleaner model is simple: the customer owns Program Integrity, SAP helps make it real, and the SI is subject to it rather than owner of it.
[1] Dekker and Pruchnicki (2013) frame failure as emerging from normal work in complex systems rather than from a single broken component.
[2] See Dekker (2011), Dekker and Pruchnicki (2013), and Staw (1981) for related treatments of drift, complex-system failure, and escalation of commitment.
[3] Simon (1957) remains foundational for understanding bounded rationality, particularly where decisions are made under incomplete information and organizational constraint.
Cornelius Grayling has a huge wealth of experience in the IT sector, particularly with regards to program management. He addresses problems that can arise in projects with Designed To Drift.
The book is based in the field of SAP (Systems, Applications & Products) and ERP (Enterprise Resource Planning) and it aims to be a simple primer on drift as a concept. Designed To Drift includes analysis from many different angles; economics, practicality in planning and structural considerations. All of these concepts are woven through the different stages of a major IT project.
We open with a rundown of what drift is, how to spot it and the fixes that don't always work successfully. From here, the author branches out into various angles including measuring and designing around drift while progressing to the end stages of development. The language used is very precise, homing in on each point without becoming too wordy. The most advanced section comes towards the end with SAP Transformation Drift Questions; this delves into more quantitative elements including data and testing.
From start to finish, every chapter and every section is very technical and the book is targeted at a very narrow niche. Newcomers to the IT sector should brush up on the basics first as this title has been designed for intermediate to advanced operators who are looking to improve their approach to programme management. The appendix at the end of the book is very useful here as it includes a checklist of all the questions to consider at each stage.
You will need to be a fully-qualified IT professional to get the most out of it, but Designed To Drift is an effective guide that will keep your project on track while clueing you into all the potential risks. The author has poured all of his knowledge into less than 150 pages, making it an effective pocketbook for those who work in the sector.