Why Technology Absorbs Blame It Does Not Always Deserve
When a program underperforms, the post-mortem reaches familiar conclusions: the platform was too rigid, the vendor overstated its capability, the data was more disorganized than expected, the integrations were more complex than scoped. These observations may be accurate and are rarely causal.
The platform appears rigid because no one governed the process decisions that created pressure for customization. The data appears unexpectedly poor because no standing function owned its quality before implementation began. Integrations exceeded the original estimate because process owners were absent when the architecture was designed. Technology absorbs the blame because it is the most visible artifact, while governance failures remain distributed across business units, decision structures, incentives, and longstanding operating practices. A more capable platform deployed into an organization without the governance capability to sustain it produces a larger and more expensive failure, automating more activity and embedding more operating assumptions before anyone determines whether those assumptions are sound.
The Delivery Accountability Stack
The Stack is built around six layers of organizational capability: governed data, sound business processes, cross-functional accountability, controlled customization, outcome-based testing, and accountability beyond go-live. Each layer depends on the integrity of the layers beneath it. Poor data compromises process execution. Weak process design creates pressure for customization. Fragmented ownership prevents consistent decisions. Uncontrolled customization increases testing complexity. Inadequate testing allows operational failures into production. Weak post-launch accountability ensures those failures persist after the delivery team departs, and weakness across several layers compounds into program failure regardless of technical quality.
Layer One: Data Treated as a Governed Asset
Critical data is treated as administrative input rather than a governed organizational asset, with ownership distributed, validation rules incomplete, and duplicate records accumulating unchecked. Programs discover the actual condition of the data after architecture decisions have been made and go-live dates committed.
Data migration begins after solution design and runs in parallel with configuration and testing, with cleansing compressed into a temporary activity under schedule pressure. The implementation team corrects enough records to complete migration, but the organization never builds the controls required to keep the data clean after the project closes. A customer record can pass technical validation while remaining operationally wrong: two legal entities consolidated incorrectly, obsolete payment terms attached to active accounts, revenue assigned to the wrong parent. Six months after go-live, reporting is unreliable, duplicate records reappear, and users develop manual reconciliation processes. The platform absorbs blame for conditions created by absent governance.
Diagnostic question: does the organization have a standing data governance function with defined ownership and validation standards that will remain accountable after the program ends?
Layer Two: Process Integrity Before Platform Configuration
Broken processes get automated and platforms are configured around workflows that should have been simplified or eliminated. A procurement process with twelve approval steps can be fully automated with every handoff routed correctly and a complete audit trail maintained, while seven of those approvals add no meaningful control value. The technology has improved the execution of an unsound process.
Business analysts compound this failure when they transcribe stakeholder preferences without interrogating their validity, producing requirements that encode the organization’s dysfunction into the system. In design workshops, a business unit requests an exception because that is how it has always been done, no one asks how often the exception occurs or whether the underlying policy remains valid, and the exception enters the backlog, gets configured, and becomes permanent.
Diagnostic question: were the processes encoded in the platform examined for soundness before configuration began, and did the analysts shaping the requirements have authority to challenge and redesign them?
Layer Three: Cross-Functional Accountability
A sound process still fails when no one owns its end-to-end execution. Each function optimizes its own performance while degrading the overall result: sales optimizes for rapid onboarding, finance for credit control, operations for handle time. Each objective is legitimate, and the end-to-end customer outcome deteriorates because no one has authority to resolve tradeoffs across the full process.
Assigning a process owner and documenting a RACI is insufficient when the process owner lacks decision rights. When the platform’s standard process conflicts with how a business unit has historically operated, the process owner recommends standardization, a peer leader with equal authority objects, the matter escalates, and the program team introduces a customization to avoid delay. The technical debt originates in an unresolved accountability conflict.
Diagnostic question: what happens when the process owner’s decision is challenged by a peer with equal organizational authority? An unclear answer means accountability exists on paper but not in operation.
Layer Four: Customization as a Governed Decision
Uncontrolled customization produces delayed failure. Custom workflows function and the program delivers on schedule, while the failure waits for the next upgrade cycle, when custom code is incompatible with the new release, or when an acquisition must be onboarded onto a platform so heavily modified that standard processes no longer apply.
Customization becomes the default because refusing it creates a conflict the delivery team lacks authority to resolve. A formal decision framework must govern every requirement the standard platform cannot meet, evaluated against criteria including regulatory necessity, frequency of use, upgrade impact, support burden, and total lifecycle cost. A requirement affecting a small transaction volume but creating permanent upgrade complexity warrants different treatment than a legally required control.
Diagnostic question: what decision authority and approval criteria govern any requirement that standard configuration cannot meet? A committee that approves nearly every request is documenting customization, not governing it.
Layer Five: Testing That Validates Outcomes
Enterprise testing is weighted toward the happy path, confirming that components function, data exchanges occur, and configured workflows match approved requirements, while leaving two critical questions unanswered. Can the platform handle realistic operating conditions including exceptions, reversals, failed approvals, volume spikes, and dependency failures? And does the delivered capability actually improve the business measure used to justify the investment?
A financial close program should demonstrate that the close completes within the required window with fewer manual reconciliations. A procurement program should demonstrate reduced cycle time and improved policy compliance. The system can perform exactly as designed and still fail this second test because the design itself does not support the intended outcome. Test cases must include end-to-end business scenarios written with the owners who will operate the process after go-live.
Diagnostic question: do the test cases validate both operational resilience and the end-to-end business outcome, using scenarios developed with the owners who will remain accountable after go-live?
Layer Six: Delivery Accountability That Extends Beyond Go-Live
Delivery teams are measured on what they ship, and steering committees track scope, schedule, budget, and milestone achievement, leaving the more consequential question unanswered: did the program produce value? Go-live is a handoff. Programs that treat it as completion leave stabilization criteria undefined, support ownership unassigned, adoption unmeasured, and benefit realization untracked. A program can launch on time while adoption remains low, and a platform can achieve high availability while transaction completion deteriorates.
Diagnostic question: what metrics define delivery success after go-live, and do they include operational adoption, business performance, and benefit realization?
What the Stack Reveals That Individual Workstreams Cannot
The Stack exposes compounding. A program carrying ungoverned data, broken processes, and uncontrolled customization has more than three problems. Ungoverned data enters a platform configured around processes that were never redesigned. Weak cross-functional authority prevents the organization from enforcing common standards. Customization embeds data anomalies into application logic. Testing validates that customized logic against migrated data and confirms the system performs consistently what the organization should not have designed in the first place.
A customer-service platform implemented to reduce customer effort illustrates the cascade. Duplicate profiles and inconsistent account hierarchies corrupt the data layer. Unnecessary transfers between departments survive into the process layer. No single leader holds authority over the complete customer journey. Local routing rules are replicated inside the platform. Testing confirms that calls follow the configured routes without validating peak-volume behavior or end-to-end resolution. Twelve months after go-live, average handling time has increased, transfer rates remain high, agents continue using manual notes, and customer complaints have not declined. The implementation succeeded technically. The program failed against the outcome that justified the investment.
The Program Leader’s Obligation
Program leaders who manage delivery activity without accountability for the business outcome are managing only part of the investment. The conventional scope covers scope, schedule, budget, and technical delivery quality, and those responsibilities, while necessary, leave the most consequential risks unaddressed.
Program leaders do not own data quality, process design, or benefit realization. The business owns those.
What program leaders own is the obligation to tell the steering committee when those things are broken, in plain language, before the program closes. For example, unresolved process conflicts do not disappear when the platform goes live. Customizations that exist because two business units didn’t agree on a standard become permanent the moment they are configured. A go-live with no post-launch ownership and no benefit metrics is, functionally, a plan to never know whether the program worked.
Steering committees are accustomed to schedule updates and defect counts. They are less accustomed to hearing that the investment is at risk for reasons that have nothing to do with the technology.
The Delivery Accountability Stack gives program leaders the diagnostic language to surface those conditions while there is still time to resolve them.
This article is part of an ongoing series on delivery operating models, accountability structures, mismanaged enterprises, and the organizational conditions that determine whether technology programs produce the outcomes they were funded to achieve.
Nabeil Sarhan, MBA, is a dynamic technology delivery manager with over 15 years of experience in tech, cybersecurity, and computing scalability. He excels in leading diverse teams and delivering enterprise-class systems across industries such as healthcare, finance, and retail. Nabeil’s passion for solution design, systems architecture, and performance optimization makes him a sought-after consultant. He holds degrees from Harvard, MIT, and Bryant University. Connect with Nabeil on LinkedIn