We built our first custom software platform in 2009. Since then, we’ve delivered across healthcare, financial services, insurance, manufacturing, logistics, and other complex domains. The team has grown to over 800 engineers. Through all of it, one thing has remained consistent: the way software projects go off track follows a predictable pattern.
Early on, when a project overran or a client escalated in QA, the causes always seemed straightforward. Requirements were incomplete. Environment access was delayed. Stakeholders changed mid-project. These were real issues, but they were rarely the root cause.
Over time, a different pattern became clear. Most problems were structural, not situational. They were created by the way delivery was set up long before execution began the distance from real users, the reliance on documents instead of systems, and the absence of direct visibility into how work actually happened on the ground.
It took multiple engagements to see this consistently. But once it became visible, the same underlying drivers kept repeating. These five areas are what fifteen years of delivery experience consistently points to.
McKinsey and the University of Oxford, across a study of more than 5,400 IT projects, found that large initiatives run 45% over budget and deliver 56% less value than forecast on average, with one in six becoming critical to enterprise viability. The Standish Group’s CHAOS dataset, spanning 50,000+ projects over three decades, consistently points to two dominant causes: incomplete requirements and lack of user involvement.
Both datasets point to the same conclusion: what is later labeled a delivery failure is most often a scoping failure. The gap between what was assumed and what was real exists before sprint 1 begins; it only becomes visible much later in execution.
In practice, scoping failures consistently show up in three forms.
A mid-market healthcare system engaged us to build a rules-based patient routing platform. The requirements were documented against a detailed product vision.
By week eight of QA, 140 change requests surfaced. Each one reflected an operational rule that had never been captured, logic held in the heads of three clinical coordinators who had refined it over years of manual work, never documented because it was “just how things are done.”
The project ultimately ran 60% over budget. More critically, the go-live delay pushed the organization into a payer contract window they were not prepared for creating commercial impact far beyond the engineering overrun.
What fixes it: structured business rules workshops during discovery, involving the people who actually run the workflow,. Two additional weeks in discovery typically removes months of QA rework.
A lending platform was being built for a payments processing company with multiple third-party integrations. API documentation was available and treated as the source of truth during scoping.
Once development reached sprint 3, integrations began to diverge from expectations. Not because documentation was incorrect, but because production systems had evolved independently through patches, configuration changes, and undocumented behavior.
By sprint 5, multiple inconsistencies had surfaced. Work from earlier sprints had to be reworked. The project eventually ran 11 weeks over schedule, with significant erosion of delivery trust after the go-live date had already been committed internally.
What fixes it: technical spikes for every critical integration before sprint planning begins, validated in real environments . One to two weeks of upfront validation typically prevents double-digit weeks of rework.
A regional insurer commissioned a claims triage automation system. The project was delivered on time and within scope and technically correct against documented requirements.
The workflow owner, who had run claims triage operations for seven years, was only involved at UAT. She surfaced 30+ change requests. At that point, the system was functionally complete but operationally misaligned.
For the next four months, manual and system-based workflows ran in parallel, as the organization tried to reconcile the gap between design assumptions and operational reality.
What fixes it: formal workflow-owner sign-off before sprint 1. The person executing the process daily must validate that the system reflects real operational conditions. This is rarely contractual but its absence is one of the most expensive omissions in delivery.
PMI’s Pulse of the Profession 2025 reinforces this pattern, finding that teams with strong business acumen achieve 27% lower failure rates. In practice, this comes down to one thing: whether the people who actually run the workflow are present during scoping.
Here is how each sub-problem surfaces, and when:
The next category focuses on those structural issues.
This is the kind of problem that rarely shows up early in a project. It doesn’t collapse delivery in the first few months. It builds quietly and becomes visible only after scale, complexity, and ownership have shifted.
By the time it surfaces, the original decision-makers are often no longer close to the system. What the client sees is slowing delivery, rising complexity, and reduced confidence in changes usually attributed to current execution rather than earlier architectural choices.
A system designed for 200 concurrent users is expected to support 2,000 within the same growth cycle. A monolithic architecture chosen for speed during delivery later becomes difficult to evolve when the product needs independent deployment cycles.
These decisions are usually made during discovery, when the system is still being defined through documents and assumptions rather than real usage patterns or scale behavior. What gets built is accurate to the brief but not always to where the business is heading.
Every sprint operates under delivery pressure. Under that pressure, certain decisions feel reasonable in isolation like deferring refactors, reducing test coverage, skipping documentation to meet timelines. Individually, they are defensible. But over time, they accumulate.
Twelve months later, the symptom is no longer obvious technical debt it is structural slowdown. Bug-fix effort begins to exceed feature delivery. A system that once shipped steadily starts producing diminishing output, even if team size and effort remain unchanged.
At that point, the interpretation is usually people-related. In reality, it is the compounding effect of earlier trade-offs.
Gartner estimates that each developer departure can set a team back four to eight weeks in delivery time. But the deeper cost is in the context loss.
Why a system was designed a certain way. What edge cases were intentionally handled. Which parts of the codebase are sensitive to change.
When that context is not captured, the system becomes harder to modify safely. New engineers end up working around unknown constraints rather than understanding them. Those workarounds become the next layer of complexity.
We now treat architecture documentation as a continuous delivery artifact because it preserves the reasoning behind decisions long after the people who made them move on.
Architecture-related slowdowns rarely appear suddenly. They show up as patterns:
If delivery velocity on your current project has been declining for two or more consecutive quarters, the cause is almost certainly Category 2 debt rather than team performance.
A codebase assessment maps what debt exists, where it is concentrated, what it costs per sprint, and what a remediation sequence looks like. Our team can run that assessment as a standalone two-week engagement before any broader commitment is made.
Book a Scoping Session
Governance failures do not cause projects to fail on their own. They ensure that when Category 1 or 2 problems surface, the project has no mechanism to absorb them without damage.
The undefined vendor-client interface: Most software contracts specify what will be built, by when, for how much. They almost never specify:
Without this structure, the relationship works when things go well and collapses under pressure. Each side defaults to informal communication that produces inconsistent decisions and unresolved conflicts, which compound across sprints.
We standardized a governance document as a required pre-sprint deliverable after watching a well-scoped project collapse because neither side had a clear escalation path when the client's CTO changed roles in sprint 4. That document has prevented more client escalations than any other single change we have made to our delivery process.
Executive sponsorship that fades mid-project: Projects start with a sponsor who is engaged and making decisions. By sprint 4 or 5, that sponsor has moved on to the next priority. Cross-functional decisions that require sponsor authority begin to stall. According to PMI's Pulse of the Profession 2025, projects without a formal change management process are 35 percent more likely to run over budget or schedule. The change management failure is usually a governance failure in disguise: nobody maintained the accountability structure after the kickoff energy dissipated.
Priority instability inside the sprint: A sprint that starts with five priorities and ends with nine is not a planning problem. It is a governance problem. When there is no formal change request process, no scope freeze point, and no authority hierarchy, engineers spend time clarifying direction rather than building. Decision-making latency compounds across every sprint. By QA, the team has been operating in reactive mode for months, and the accumulated cost of that latency shows up as a schedule overrun that nobody can trace to a single decision.
This category is uncomfortable to discuss honestly, because the failures look like performance problems from the outside. They are not.
Skill misalignment with the domain: A technically strong backend engineer assigned to a healthcare claims processing project without prior exposure to claims logic will write code that passes unit tests and fails operational review. The failure is the assumption that technical skill generalizes across domains without additional context.
We experienced this directly in our initial large healthcare engagement. The engineers were strong. The system was built correctly against the requirements. The requirements did not fully capture the compliance and operational nuance of healthcare workflows because none of the engineers had seen one before. We now run explicit domain orientation sessions before sprint 1 on every regulated vertical engagement.
Scaling without adjusting the structure: A team of four engineers builds effective working patterns with minimal overhead. The same patterns applied to a team of fourteen produce coordination failures. Communication paths multiply. Code review becomes a bottleneck. Architecture decisions made informally at four require a formal process at fourteen or they fragment across the team. Teams that scale by adding engineers without adjusting governance, communication, and review structure will see delivery velocity decrease as headcount increases.
The proximity deficit: A vendor team working from a requirements document is at a fixed distance from the client's system, operations team, and decision-makers. That distance is the common thread through every failure in Categories 1 through 3. The scoping gaps that a requirements document cannot surface, the architectural context that only becomes visible inside the client's environment, the governance breakdowns that only occur when vendor and client communicate through formal channels rather than daily working proximity: all of them are access problems as much as process problems.
A team embedded inside a client's environment from day one catches Category 1, 2, and 3 problems before they become projects. A team working from a requirements document finds them in QA.
This is the most expensive category and the least likely to be attributed to its actual cause. The project closes on time and then the go-live happens. The team disbands. Quietly, the system stops being used.
User adoption treated as a training task: A Gartner survey across 169 IT implementations found that companies allocate on average only 5 percent of the overall system implementation budget to change management. The same Gartner research attributes 17 percent of IT project success to organizational change management. That gap, between what change management receives and what it contributes to project success, is the widest misallocation in software delivery.
The pattern plays out consistently: the system gets deployed, a training session runs, the operations team reverts to spreadsheets within six weeks because the spreadsheet is faster. We have seen clients report a system as a project success in the closure meeting and replace it eighteen months later. The replacement is attributed to the system being "outdated." In most cases, it was a 24-month-old system that was never fully adopted.
Go-live as the finish line: When the project team disbands, the knowledge that was never documented leaves with them. The engineer who understood why the integration was built the way it was has moved to the next engagement. The architect who made the data model decision is no longer reachable. The client's internal team inherits a system they did not build and cannot fully explain.
The first major bug reveals the knowledge gap. The first required change to meet a new business requirement reveals it completely.
No operational ownership after delivery: Feature requests have nowhere to go and performance degrades as usage scales past the original architecture's load assumptions. Security patches fall behind, while the system accumulates operational debt at the same rate the original codebase accumulated technical debt, and for the same reason: no structural owner.
The most expensive version of this failure is the one that never gets reported as a project failure at all: a system delivered on time, closed out cleanly, replaced two years later because the business grew past it. That replacement appears in the next budget cycle as a new initiative. The same structural decisions run again on the replacement.
What a structured post-launch plan includes versus what most engagements produce:
If your team is within ninety days of go-live or has recently gone live, the adoption and operational ownership decisions made in this window determine whether the system delivers its projected ROI within twelve months or becomes a replacement candidate within eighteen. Most organizations do not find out they are in the second scenario until the replacement discussion is already happening.
A post-launch readiness review from our team assesses the current adoption plan, documentation state, and operational ownership structure against what the system will actually need to operate and evolve at scale. It is a standalone engagement with no broader commitment required.
Schedule a Scoping Session
Most failure categories give visible signals before they collapse the project. The problem is knowing what each signal indicates and how much time remains to act on it.
Every one of these signals has a response. None of them are fatal if caught at the signal stage. They become fatal when they are attributed to the wrong cause: when architecture debt is blamed on team performance, when a governance breakdown is called scope creep, when a post-launch failure is called a requirements change.
When organizations reach us after a project that has collapsed in one of these five categories, the question they are usually asking is whether they need a different vendor. Sometimes the answer is yes. More often, the answer is that they need a delivery model built to catch the failures before they become projects. Different vendors running the same delivery model produce the same failures.
Here is what the five-category map produced in terms of how we build and deliver software today. The changes below are not process additions layered on top of a standard delivery model. They are replacements: the original process generated the failures, so the process was rebuilt. Each change below traces directly to a failure category above and was added after we had seen that category cost a client money. The framing matters: this is not a list of differentiators assembled for a sales deck. It is the list of interventions that, individually, stopped a specific category from recurring.
The model changes are listed below, each one mapped to the failure category it was built to address. None of them are theoretical. Every one of them was added after a real engagement produced a real failure.
Six specific model changes. Each one traces directly to a failure category above.
Embedded Proximity: Engineers Inside Your Client's Environment
Addresses: Category 1 scoping failures, Category 3 governance breakdowns
Our engineers embed inside the client's environment from day one. Not assigned to it. Inside it. This is the Forward Deployed Engineer (FDE) model.
An FDE owns delivery outcomes the way an internal engineer does. The proximity is not a preference: it is what makes Category 1 and 3 failures visible before they become change requests.
Anticlock: AI-driven SDLC Platform
Addresses: Category 2 architecture debt, team-level AI adoption consistency
Every engineering team is now using AI coding tools. The problem is not whether to use them. The problem is that every engineer is using them differently: different tools, different prompting patterns, different documentation habits, different security assumptions. In an enterprise environment, that inconsistency creates architectural divergence, undocumented decisions, and security gaps that multiply across the team.
Stripe recognised this problem and started building internal tooling to industrialise AI-driven development for their own engineering organisation. Anticlock is that platform, available to any company without building it from scratch.
Anticlock makes the hard decisions upfront so teams do not have to:
The result: at least 50 percent faster sprint velocity at the team level. Not individual productivity. Team-level velocity is the number that determines whether the client's delivery schedule holds.
Vertical domain expertise
Addresses: Category 4 team failures
Ideas2IT holds AWS GenAI Specialist Partner status and AWS Healthcare Competency. AWS Healthcare Competency requires demonstrated, audited capability building and deploying solutions in regulated healthcare environments.
Enterprise software project failures in regulated verticals follow a consistent pattern: technically strong teams without domain exposure building systems that pass code review and fail operational review.
What our engineers bring to healthcare and life sciences engagements before sprint 1:
The same depth applies to financial services engagements: payment processing architecture, loan origination logic, and regulatory compliance requirements. Vertical knowledge is what prevents technically correct systems from failing operational review.
AI-upskilled engineering organization
Addresses: delivery velocity and enterprise AI adoption
Every engineer on our team operates inside an AI-augmented development environment. This is not a policy statement about tool access. It is the operational baseline that makes our velocity claims credible.
As an AWS GenAI Specialist Partner, we build and deploy GenAI solutions in production environments with the implementation record that the certification requires. Anticlock exists because we needed to institutionalize AI-driven development at the team level with the security guardrails and compliance constraints that enterprise environments require. That need came from doing it, not theorizing about it.
Fifteen years of lived delivery experience
Addresses: all five failure categories
The five failure categories in this article were not derived from reading research. They were derived from running the same projects that produced the research findings.
The process gates we run today came from asking what we would have needed to know before each failure happened. The business rules workshop, the integration spike, the governance document, the growth scenario session, the 90-day adoption plan: each one was added after a specific engagement made the gap visible.
Compliance posture: SOC 2 Type II, ISO 27001, HIPAA-compliant delivery
Addresses: regulated vertical engagements across all five categories
For healthcare, financial services, and insurance engagements, compliance certification is not a marketing credential. It is evidence of process maturity across the delivery lifecycle, the same lifecycle where Categories 1 through 5 originate.
A delivery process that cannot document its own security posture cannot be trusted to document a client's business rules, integration behavior, or architecture decisions.
How the five failure categories map to what the delivery model addresses:
The starting point for any new engagement is a two-week scoping sprint: tested integration map, documented business rules inventory, workflow owner sign-offs, growth scenario assessment, governance document, post-launch adoption plan. That output becomes the SOW. If any element cannot be completed during the scoping sprint, the sprint surfaces why before budget is committed.
Learn more about how we structure the custom software development process that was rebuilt from the five failure categories above.
McKinsey and BT Centre for Major Programme Management, University of Oxford. "Delivering large-scale IT projects on time, on budget, and on value." McKinsey Digital. October 2012. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value
Standish Group. "CHAOS Report 2020: Beyond Infinity." Standish Group International. 2020. https://www.standishgroup.com
Project Management Institute. "Pulse of the Profession 2025." PMI. 2025. https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse_of_the_profession_2025-1.pdf
Gartner. "Organizational Change Is Centric to IT Projects' Success." 2015. https://www.gartner.com/en/documents/3025520/organizational-change-is-centric-to-it-projects-success. Also cited in: Emergent Consultants. "Gartner Study Finds Companies Under-Invest in Change Management." https://blog.emergentconsultants.com/gartner-study-finds-companies-under-invest-in-change-management/
Didn't find what you were looking for?
