Technology projects have a people problem. This is easy to say and consistently difficult for organisations to absorb, because it runs counter to the instinct that technology failures must have technological causes. However, the evidence, accumulated over decades and across tens of thousands of projects, tells a different story.
The Standish Group's CHAOS database remains the most comprehensive study of software project outcomes ever conducted – over 50,000 projects across 1,000 organisations, tracked between 1994 and 2020. Its final report identified three factors that most significantly correlate with project success:
- a good team;
- a good sponsor; and
- a good place (the cultural and organisational environment in which the project operates)
With skills, tooling, and completeness of requirements being poor indicators of success.
More recently, PMI's 2025 Pulse of the Profession, surveying nearly 3,000 project professionals globally, found that organisations prioritising interpersonal capabilities – collaborative leadership, communication, and empathy – achieve 72% business goal success rates, compared to 65% for those that do not.
A further study found that 86% of employees and executives blame workplace failures on poor collaboration or ineffective communication, and 97% believe that a lack of alignment within a team directly impacts task and project outcomes.
And McKinsey's 2024 survey data found that companies prioritising cross-functional collaboration achieve 35% higher project success rates and 20% faster decision cycles.
These are consistent findings with the same message: the primary determinant of whether a technology project succeeds is how well the people involved work together. Everything else, such as the programming language, the cloud provider, the framework and the architecture pattern, is secondary.
This article looks at why alignment failures are so prevalent, what the evidence says about the specific mechanisms through which they damage projects, and how engineering leaders can build the single-team model that is the strongest predictor of success.
The Alignment Problem
The default structure of most technology projects creates alignment problems by design. An organisation commissions work from a delivery team, whether internal or external. Requirements are documented and handed over. The delivery team estimates the work, commits to a plan, and begins building. Progress is reported through status updates, while stakeholders review deliverables at predetermined milestones.
This structure feels orderly. It provides clear accountability (the delivery team is responsible for building what was specified) and clear governance (the client reviews progress against the plan). The problem is that it introduces a structural gap between the people who understand the business problem and the people who are solving it technically. Every interaction across that gap can introduce delay, interpretation error, and the potential for misalignment.
PMI data shows that 52% of all projects experience scope creep, with the figure rising above 70% for software development projects specifically. This is overwhelmingly a communication and alignment failure. Scope does not creep because engineers add features spontaneously, it creeps because the original specification did not capture what stakeholders actually needed, because stakeholders' understanding of their own needs evolved during the project, or because assumptions made early in the process turned out to be wrong. These discoveries arrive late, at milestone reviews, during user acceptance testing, or after deployment, when the cost of correction is highest.
The Standish Group's foundational research quantified this through their Decision Latency Theory, introduced in the 2018 CHAOS Report. Across their dataset of 50,000 projects, they found that the root cause of project performance problems is slow decision-making. Projects generate approximately one decision for every £1,000 in labour costs – a £1 million project requires roughly 1,000 decisions. When decisions are made quickly (averaging about one hour each), they consume approximately 10% of the project budget. When decisions drag (averaging four hours), decision-making alone can consume as much time and money as the actual development work. Improving decision latency alone was shown to increase project success rates from 21% to 75% - a 3.5x improvement.
Decision latency is a direct function of team structure. When the people with business authority sit in a different room, a different building, or a different organisation from the people building the product, every decision requires a handoff. Someone must formulate a question, communicate it through the appropriate channel, wait for the right person to be available, explain sufficient context for them to understand the question, receive an answer, and translate that answer into technical action. In a well-integrated, focused single team, most of these decisions happen in as close to real time as possible.
How Alignment Erodes
Alignment problems are not unique to any particular engagement model. They occur on internal projects, outsourced projects, and projects where the entire team sits in the same building. The mechanism is consistent: as a project grows in duration and complexity, the people closest to the business problem and the people closest to the technical solution gradually drift apart. This can happen on every project unless it is actively prevented.
This drift can take different forms:
Specification as proxy for conversation
Requirements are documented in detail, and the document becomes the primary interface between business and technical thinking. This feels efficient – write it down once, reference it throughout – however written requirements cannot capture context, intent, or the reasoning behind trade-off decisions. The team building the product ends up making reasonable interpretations that differ from what the stakeholder intended, and the gap is only discovered weeks or months later during review.
Information loss through layering
As projects scale, communication passes through intermediaries – project managers relay messages between stakeholders and engineers, business analysts translate requirements into user stories, and architects interpret technical constraints back to the business. Each layer is well-intentioned and each introduces the potential for meaning to shift. The engineer who hears a requirement third-hand has a subtly different understanding from the stakeholder who originated it.
Decision congestion
Every technology project generates hundreds of small decisions, for example, how to handle an edge case, which of two valid approaches to take, whether a feature is in scope. When the people with business authority and the people with technical context are separated by reporting lines, meeting cadences, or simply by habit, these decisions queue up. Research indicates that 85% of collaboration failures are caused by poor communication management, such as unclear ownership, message overload, misaligned expectations, and information scattered across channels.
These patterns emerge regardless of whether the team is internal or involves an external partner. What matters is whether the project has been deliberately structured to counteract them through factors such as shared rituals, embedded decision-making authority, and a working culture where business and technical perspectives are present in the same conversations daily. This is what the single-team model provides, and it is why establishing that culture from day one is so critical.
What Single-Team Working Looks Like in Practice
The single-team model dissolves the boundary between client and delivery partner. Both sides work as one unit, with shared rituals, shared tools, shared accountability, and a shared definition of success.
This is straightforward to describe and genuinely difficult to implement, because it requires both organisations to relinquish some of the structures they rely on for comfort and control. The client must accept that governance happens through continuous participation, not through milestone reviews. The delivery partner must accept that the client's voice is present daily, shaping priorities and challenging decisions in real time.
The baseline mechanisms that make single-team working function include:
- Joint daily standups where both client and delivery participants discuss progress, blockers, and priorities.
- A shared backlog that is visible and editable by everyone, where the product owner (ideally from the client side) prioritises work based on business value, and the delivery team provides input on technical feasibility and effort.
- Sprint planning sessions where both sides collaborate on what to build next and why.
- Sprint reviews where working software is demonstrated to stakeholders who can provide meaningful, timely feedback.
- Retrospectives that include participants from both sides, creating shared accountability for how the team works together.
The embedded product owner is the most critical element. This is a person from the client organisation who has sufficient authority to make day-to-day decisions about priorities, scope, and trade-offs without requiring escalation. They work alongside the delivery team daily, answering questions in real time, providing context when requirements are ambiguous, and making the small, continuous decisions that keep the project moving. Without this role, the single-team model can collapse back into a handoff-based dynamic, because every decision that requires business input becomes a bottleneck.
McKinsey's research found that companies with cross-functional collaboration achieve 35% higher project success rates as teams make decisions faster because the relevant expertise is present in every conversation.
The Agile Connection and Its Limits
PMI's 2025 research found that teams perform equally well across predictive, agile, and hybrid approaches when properly trained and supported — with hybrid approaches increasing 57% since 2020. This finding aligns with the foundational Standish Group data, which showed that Agile projects are three times more likely to succeed than waterfall projects, but with an important caveat: only 40% of projects labelled "Agile" are successful. The methodology alone is insufficient. The human factors, such as team quality, sponsor engagement, cultural environment, are more predictive than the process framework.
The Standish Group was equally emphatic about a specific risk. Dressing waterfall up as Agile, in running sprints and standups while the overall project follows a sequential plan with predetermined milestones and a fixed scope, actually reduces the chance of success. The CHAOS data showed that Agile projects without a skilled, aligned team performed no better (and sometimes worse) than waterfall projects with good governance.
This is an important insight for engineering leaders who have adopted Agile ceremonies without transforming the underlying dynamics of how their teams work. If sprint planning is a negotiation between client and supplier about what can be delivered for an agreed price, the project is operating in a waterfall paradigm with Agile terminology. Genuine agility requires the entire project, including the governance and decision-making layers, to operate collaboratively.
The Sponsor's Role
PMI's 2025 research found that projects led by professionals with high business acumen, so those who engage early with stakeholders, align closely with business priorities, and assess long-term value, meet their business goals 83% of the time, compared to 78% for projects without that strategic engagement. They also experience a failure rate of just 8%, compared to 11% for others. The Standish Group's foundational research explains that sponsor quality was identified as the easiest factor to improve, because each project has only one sponsor. The CHAOS report described the good sponsor as "the soul of the project" – the person who breathes life into it, provides clear direction, removes organisational obstacles, and ensures that decisions are made quickly.
The skills that define a good sponsor, according to the CHAOS research, are:
- ensuring quick and timely decisions;
- providing a clear and inspiring vision;
- demonstrating imagination and big-picture thinking;
- and understanding what good progress looks like.
PMI's 2025 data states that projects with a clear vision of success score +41 on PMI's Net Project Success Score, compared to -18 for those without one. The difference between a project with a mature sponsor and one with a highly mature sponsor is substantial, producing a significant jump in success rates.
For engineering leaders, the implication is that investing in the sponsor's capability and engagement may deliver a higher return than investing in any technical aspect of the project. A highly skilled sponsor who is deeply engaged in the project's progress, who makes decisions quickly and removes blockers proactively, creates the conditions in which good teams can do their best work. A disengaged or unskilled sponsor, regardless of how talented the engineering team may be, creates the conditions for drift, delay, and potential failure.
Organisations should be as rigorous in assessing and developing sponsor capability as they are in assessing technical architecture. Before a project begins, the sponsor should be identified, their level of engagement agreed, and their authority to make decisions confirmed. During the project, the sponsor's engagement should be monitored as a leading indicator of project health, because by the time a disengaged sponsor's impact manifests in delivery metrics, significant damage can have already been done. The Standish Group finds that sponsor quality is the easiest factor to improve, proving that one of the highest-leverage interventions available to any organisation is also one of the most practical to implement.
Building the Culture from Day One
Single-team working is a cultural commitment, and culture is established in the first days of a project. The patterns set in the initial weeks, such as how decisions are made, how conflicts are resolved, how information flows, and how problems are escalated, tend to persist throughout the engagement. Changing a dysfunctional team dynamic mid-project is possible, but it is significantly harder and more disruptive than establishing the right dynamic from the start.
The most effective approach is to invest the first days of the project in building the team, before building the product. This means a shared kickoff that includes participants from both organisations, aligned around a common understanding of what the project is trying to achieve and why. It means agreeing on working practices in how the team will communicate, how decisions will be made, what tools will be used and how conflicts will be handled, before the first sprint begins. It also means establishing psychological safety: the confidence that team members can raise concerns, challenge assumptions, and admit mistakes without fear of blame or retribution.
Gallup's research has consistently found that connected teams show a 21% increase in profitability compared to disconnected teams, driven by faster decision-making, better alignment with organisational goals, and reduced turnover. PMI's Pulse of the Profession report found that teams with transparent metrics achieve 19% higher trust scores and 23% lower rework rates.
Maintaining alignment over the life of a project requires ongoing attention. The initial shared understanding can degrade over time as new team members join, as the product evolves, and as business priorities shift. The ceremonies of Agile, such as daily standups, sprint reviews, retrospectives, serve as alignment maintenance mechanisms, but they only work when they are genuinely used for alignment, as opposed to becoming routine reporting exercises that participants attend without engaging.
The retrospective deserves particular focus because it is the primary mechanism for the team to improve how it works together. A retrospective that includes participants from both the client and delivery sides, where honest feedback is welcomed and acted upon, is one of the most valuable practices in the delivery toolkit. A retrospective that only includes one side, or where participants are reluctant to raise difficult issues, is a warning sign that the single-team model has eroded.
The 97% of employees who believe that team misalignment impacts project outcomes are describing something they experience daily. The single-team model is the response to that experience. It is a deliberate design choice to remove the organisational boundary that creates the misalignment in the first place.
The Practical Test
There is a simple diagnostic for whether a technology project is operating as a single team. Ask how long it takes to get a business decision made when the team encounters an ambiguity in the requirements. If the answer is "a few minutes", the project is operating as a single team. If the answer involves emails, meeting requests, escalation chains, and a turnaround time measured in days, the project has an alignment problem.
PMI's 2025 research concluded that project success requires professionals who go beyond managing scope, budget, and schedule to become strategic partners who understand the business context surrounding their projects. The Standish Group reached a similar conclusion years earlier, recommending that the industry stop thinking about software delivery as "projects" and start simply developing software that is continuous, incremental and team-owned.
The single-team model is how both recommendations translate into practice. It is the structural foundation on which every other good delivery practice depends, including prototyping, Agile ceremonies, user focus, data-first engineering and AI readiness. All of these require fast decisions, shared understanding, collaborative ownership, and overall one team, working toward one shared mission.
