Shared Purpose Before Shared Schedule

Around the world, large capital projects bring together owners, designers, contractors, suppliers, regulators and financiers who have never worked as one organisation and will never do so again. In the first months of such a project, a great deal of effort goes into one artefact in particular: the integrated schedule. It is negotiated, levelled, baselined and signed. Every party's milestones appear on it, and its approval is often celebrated as the moment the project became a team. Yet a signed schedule records only that many parties agreed to dates. It says nothing about whether they agree on what those dates are for. This comprehensive blog will explore why shared purpose has to come before a shared schedule on large capital projects, how purpose works at different levels of a project, why so many project "teams" turn out to be pseudo-teams, how commercial structure either supports or undermines a common purpose, and how owners can build and protect purpose before dates harden into the only thing everyone agrees on.

1. The Schedule Everyone Signed and Nobody Shared

Consider a familiar pattern. An owner launches a major facility. The engineering contractor, the civil works contractor, the mechanical and electrical packages and the systems integrator each submit their programmes. A planning team stitches them into an integrated master schedule, and after weeks of workshops the baseline is approved. Every company's logo sits on the cover page. The steering committee declares the project aligned.

Within months, the alignment begins to show its limits. One package protects its own float by holding back information about a late design input. Another pursues an early milestone that earns a payment but leaves an interface half-finished for the next trade. A third treats every change as a commercial opportunity. Interface meetings turn into negotiations about whose delay caused whose. Each firm is, by its own measure, performing. The project as a whole is drifting.

Nothing in this pattern requires bad faith. Each party is doing what its own contract, its own incentives and its own internal scorecard reward. The problem is that the project never established, before the dates were fixed, what result all of those dates were supposed to serve and why that result mattered more than each party's local success. The schedule became a coordination device among parties who did not share a purpose. Coordination without purpose is fragile: it holds while plans go well and dissolves as soon as the plan comes under pressure.

The central claim of this blog is simple. On large capital projects, a shared schedule is the last thing a team should agree, not the first. Purpose — the result the project exists to deliver, the specific contribution each team owes to that result, and the collective outcome everyone will be judged by — has to be built first. A schedule built on that foundation is defended by the people who carry it out. A schedule built without it is merely tolerated.

2. A Schedule Is a Means, Not a Purpose

A useful discipline for project leaders is to think from right to left. Picture a sequence of boxes. The box on the far right holds the ultimate goal: the result the project exists to produce. The boxes to its left hold the means — the design, the contracts, the resources, the milestones and finally the schedule. Planning should begin by asking why the project is being undertaken and deciding carefully what belongs in the right-hand box. Only then should the boxes to the left be filled in, working backwards from the result.

This is the logic behind approaches such as backcasting, theories of change and "working backwards" from the customer experience. It sounds obvious. In practice, large capital projects often reverse it. A preferred solution — a particular building, rail line, plant or terminal — appears early, and the schedule for delivering that solution becomes the de facto goal. The asset itself is treated as the right-hand box, when in fact it is usually a means to something else: mobility, capacity, access, safety or service to a community or customer.

The failure mode has a name in this way of thinking: losing sight of the right. Projects that lose sight of the right can execute brilliantly against their own plan and still fail to deliver what the sponsor needed. Leaders who keep asking "why?" throughout delivery — checking constantly whether present actions contribute to the result on the right — are far better placed to notice when the plan and the purpose have come apart.

The same idea appears in front-end practice. Before significant work begins, the goals and objectives of a project should be made explicit and tested to confirm that, if they are achieved, they will further the sponsor's strategy and overall goals. Skipping this step leads to projects that underperform against expectations even when they are delivered. The prescription is not only a sound business case but also a deliberate programme of engagement: meetings designed and facilitated to bring stakeholders with different worldviews to a genuine understanding of what the project is for.

Organisations that push decisions down to the people closest to the work make a related point. Delegation only works when people understand what the organisation is trying to achieve; otherwise local decisions drift away from the organisation's interests. The remedy is to be honest about intent and to communicate it constantly, at every level, beginning with the end in mind.

Figure 1: Plan from right to left. The right-hand box — the purpose or result the project exists to deliver — is decided first; means, milestones and finally the schedule are filled in backwards from it.

Seen this way, a schedule is an important instrument but a subordinate one. It answers the question "when?" for a set of means. It cannot answer "why?", and a team that agrees on "when" without agreeing on "why" has agreed on far less than it thinks.

3. Three Layers of Purpose That Get Confused

One reason purpose is so often missing is that the word covers at least three different things on a large capital project, and they are easily confused.

The sponsor's or organisation's purpose. This is the strategic reason the owner is investing: growth, compliance, service to the public, a change in market position. It sets the frame within which the project should create value, and front-end alignment is about testing that the project genuinely serves it.

The project's Why. This is the right-hand box: the specific result the project must produce, stated as an outcome rather than as an asset. It is narrower than corporate strategy and broader than any single package.

Each team's specific purpose. A real team needs a clear, specific purpose of its own, and that purpose must be distinct from the purpose of the larger organisation. The owner's project team, the design team, an interface team between two packages, a commissioning team — each needs to know what it uniquely contributes and how it will know it has succeeded. Great teams spend substantial time articulating and agreeing on that purpose, and stronger motivation tends to emerge from the process of agreeing it.

The most common confusion runs between the first and third layers. Senior teams in particular often assume that the organisation's purpose is their purpose, and so never define what they, as a team, are for. The result is a group of capable individuals who share a corporate mission statement but have no common task. At project level, the same mistake appears when the project Why is simply repeated to every team. An interface team told that the project exists to "deliver world-class capacity" has learned nothing about what it must achieve this quarter or how it will hold itself accountable.

The layers need to cascade. The organisation's purpose should be clear enough that the project Why can be tested against it. The project Why should be clear enough that each team can derive a purpose of its own from it. And each team's purpose should be translated into specific performance goals along the way — goals that are team-specific, not restatements of the organisation's goals. Clear goals keep teams focused on results, make communication easier, create a level playing field among members and nudge behaviour toward a shared norm.

Figure 2: The purpose stack. Sponsor purpose, project Why and team-specific purpose are nested layers, each with its own test question. The schedule is derived from the stack, not the source of it.

Only once these layers are clear does the schedule have something to express. Dates then become the timing of contributions to a known result, rather than a substitute for knowing what the result is.

4. Pseudo-Teams: Coordination Without Commitment

There is a well-established way of describing what happens when groups are labelled teams without the substance of one. Imagine a curve shaped like the letter J.

At the starting point sits the working group. Its members' contributions are simply added together; no collective effort is needed and individual efforts do not build on one another. Working groups are perfectly respectable. They flourish under hierarchy and individual accountability, and many project functions are best run this way.

Below the working group, at the bottom of the curve, sits the pseudo-team. A pseudo-team has an opportunity to perform collectively but never focuses on collective performance. There is plenty of team talk and very little team action. Pseudo-teams perform worse than honest working groups, because they carry the overhead of teaming without its benefits.

Above them sits the potential team, which is trying to improve but still lacks clear goals, discipline and a shared approach. Then comes the real team, which holds itself responsible for a shared purpose, shared standards and a shared approach, and which clearly outperforms the working group. At the peak, rarely reached, is the high-performance team, whose members also care deeply about one another's growth and success.

On large capital projects, the pseudo-team is extremely common, and the signed integrated schedule is one of its favourite disguises. The logos on the cover page, the shared baseline and the steering committee photograph all signal teamwork. Underneath, each firm continues to optimise for its own outcome. The project has paid for the ceremonies of a team without getting one.

Figure 3: The team performance curve on a large capital project. A pseudo-team — "logos on the schedule" — performs below an honest working group; only collective purpose, clear goals and mutual discipline lift a project toward a real team with one result on the right.

The curve has a further lesson. What moves a group up it is not team-building activity but a genuine performance challenge combined with a purpose worth committing to. The fundamental obstacle to real teams is a lack of purpose or the absence of a serious performance challenge; both are needed. A project that wants real teams must be clear about what collective result is at stake and must make that result matter.

A complementary lens explains why individuals in a pseudo-team drift toward local goals. The most damaging dysfunction in a team is inattention to results: members caring about something other than the collective goals of the group. Two distractions dominate. The first is team status — the sense that simply belonging to a prestigious project is enough, so that achieving specific results is desirable but not worth great sacrifice. The second is individual status — enhancing one's own position, career or department at the expense of the team. On large capital projects, the equivalents are easy to recognise: the pride of working on a landmark scheme, and the pull of a firm's own margin, a manager's own milestone or a discipline's own reputation.

Results in this sense are not only financial. They are the outcome-based goals a team sets for itself, and they ultimately drive the financial results. A team that is not focused on such results stagnates, loses its most achievement-oriented members and is easily distracted. A team that is focused on them subordinates individual goals to the collective one and feels both success and failure acutely.

The same lens explains why a schedule can be "agreed" without being committed to. Commitment requires both clarity and buy-in. When dates are accepted without clarity about the result they serve, and without a real chance to debate the plan, what looks like buy-in is often compliance. People nod at the baseline and keep their reservations — and their own priorities — to themselves. Without trust, conflict, commitment and accountability, results suffer; but no amount of those qualities can compensate for a lack of desire to achieve the collective result. Purpose is what gives that desire an object.

5. Aligning Firms, Not Just Feelings

Teams inside a single organisation can build shared purpose largely through leadership and dialogue. Large capital projects are different, because the "team" spans many firms with separate balance sheets, contracts and incentives. On such projects, purpose that is not reflected in commercial structure tends not to survive the first serious dispute.

Two practices from large-project experience make this concrete.

The first is shaping. Before the scope is fixed, the parties with a stake in the project — partners, governments, communities and the owner itself — have to settle how the value the project creates will be allocated. That allocation determines who will support which scope. Shaping is therefore a political and economic alignment process, not stakeholder communication. When it is done poorly, the consequences show up later as misalignment among joint-venture partners, weak project controls and funding delays. Stakeholder alignment achieved at the front end is a leading indicator of whether later practices, including front-end loading and controls, will actually hold.

The second is the idea of turning a delivery network into a single, determined organism. After the slow thinking — the goal, the plan and the forecasts — fast delivery requires a capable delivery team in which many firms and thousands of people come to see themselves as one "us," all pulling toward delivery. Where possible, that means hiring an experienced master builder and the team that already knows how to work with them. Where a team must be created from scratch, it means designing the commercial and organisational conditions for unity.

Heathrow Terminal 5 is the most cited example. The owner led and shared risk rather than pushing it all onto contractors. Contracts were structured so that firms were not set against one another. Experience was valued over the lowest bid. People were encouraged to see themselves as working for the project rather than for their employer, and a shared sense of purpose was cultivated around the idea of making history. The terminal was delivered on budget and on time. Wembley Stadium, by contrast, became a story of conflict and a cost that doubled.

The lesson is not that one contract form guarantees success. It is that purpose and commercial structure have to point the same way. A team cannot be asked to share a purpose while its contracts reward each member for defeating the others. Mission statements and identity campaigns are useful only when the incentives behind them are aligned. On large capital projects, aligning firms means aligning value allocation, risk and reward as well as aligning feelings.

There is a useful distinction to keep in mind here. Owner-team integration — bringing the owner's own functions together under a capable project director — is one important condition for success. Building a shared purpose across a multi-firm delivery organisation is a different one. Both matter, but they are not the same, and a well-integrated owner team can still preside over a fragmented delivery network if purpose and contracts are not aligned across firms.

6. Building Purpose Before Dates: The Charter Sequence

If purpose must come before the schedule, owners need a practical way to build it. The practices below form a sequence that can be run at project launch, at each major phase transition and whenever new parties join.

Step 1: Agree the Why. Begin with the right-hand box. The sponsor, owner team and principal delivery partners should articulate the result the project exists to produce, stated as an outcome. They should test it against the sponsor's strategy and against the question "is the asset the goal, or the means?" This is the stage at which a well-designed engagement programme matters: different parties hold different worldviews, and a single facilitated conversation rarely resolves them.

Step 2: Set team goals — both task and process. Each team should then set two kinds of goals. Task goals describe what the outcome must look like: the actions, checkpoints and sign-offs; the deadlines, worked backwards from the final date with buffers for external dependencies; and the metrics, specific enough that members cannot interpret them differently. Process goals describe how the team will work together: whether it will be inclusive or directive, open or closed, and how it will handle disagreement, information and requests for help. Setting both up front makes decisions clearer, makes conflicts easier to resolve ("which option moves us closer to our goals?"), keeps autonomous decisions consistent and gives the team a fair basis for feedback. Team culture develops whether or not it is discussed; it is better to define it deliberately.

Step 3: Surface personal and firm agendas. Every member brings personal goals and every firm brings commercial ones. Left unspoken, they quietly work against the group goal, for example when someone leaks work in progress to gain individual visibility. Part of chartering is to make these agendas explicit and fold them into the group's goals where possible, so that individuals do not need to act against the team to meet their own aims.

Step 4: Check goals before roles, process and relationships. A long-standing diagnostic for team problems works through four elements in order: goals, roles, processes and interpersonal relationships. When conflict flares, the first questions concern whether goals are clear and roles well bounded, not whether personalities clash. On multi-party programmes, that means checking sponsor outcomes against package milestones, clarifying the roles of client, project manager and contractors, and agreeing interface processes and decision rights — and only then turning to trust and relationships. The diagnostic is a snapshot rather than a full account of a team's life, but as a launch and reset tool it reliably puts purpose ahead of personalities.

Step 5: Declare the collective results. Once goals are clear, make the collective results public. A public declaration of results raises commitment, because members are less willing to let down peers in front of others. Rewards, where used, should be tied to collective outcomes rather than to effort alone. Rewarding effort without results signals that results do not really matter, and relying on financial incentives alone assumes that money is the only motivator. Leaders set the tone here more than anywhere else: if the leader visibly values anything above the collective result, the team takes that as permission to do the same.

Step 6: Only then baseline the schedule. With a shared Why, team-specific goals, surfaced agendas, clear roles and declared results, the integrated schedule becomes the expression of an agreement rather than the agreement itself. Dates are still argued over, as they should be, but the arguments are now about how best to achieve a shared result rather than about whose result wins.

Figure 4: A purpose-before-schedule gate. The Why is agreed, team task and process goals are set, agendas are surfaced, goals and roles are checked, collective results are declared — and only then is the schedule baselined. When dates and purpose conflict, the loop returns to the Why before re-sequencing.

Research on team effectiveness supports this emphasis on design. A compelling purpose — a clear reason for the team's existence, an engaging challenge and meaningful impact on others — is one of the core conditions that can be designed into a team, alongside a real, bounded team, the right composition, sound structure, organisational support and timely coaching. Design conditions explain more of the variation in team effectiveness than coaching does. In other words, purpose is not a pep talk delivered after the plan is set. It is part of the team's architecture, and it is cheaper to build in at launch than to retrofit during a crisis.

7. Keeping Purpose Alive When the Schedule Bites

Purpose built at launch erodes under delivery pressure. Late drawings, failed tests, weather, supply problems and claims all pull attention back toward local survival. Several habits help keep purpose alive.

Keep asking "why?" Leaders who keep asking whether present actions contribute to the result on the right stay oriented amid the noise of delivery. At Terminal 5, the project's leadership was known for checking constantly whether what was happening now served the final result. The question is simple, and asking it repeatedly is what gives it force.

Use purpose as the tiebreaker. When two packages disagree about a sequence, a design choice or the use of float, the first question should be which option moves the project closer to its shared result. Teams that set clear task and process goals at launch find these conversations easier, because they have already agreed the criteria. Teams without such goals fall back on contract positions.

Make briefings interactive, not theatrical. Shared purpose depends on shared understanding of the situation. Organisations operating in complex environments have found value in extreme transparency: regular cross-team briefings that start with short updates and open into genuine conversation, broad information sharing and a culture in which questions are not threatening. When people see problems being solved in real time and understand how their own work fits the whole, they are more likely to act for the whole. Status meetings in which each party performs its progress for an audience do the opposite.

Celebrate small collective wins. Meeting smaller shared goals builds unity through difficult periods. A project that marks the completion of a critical interface, a joint commissioning milestone or a problem solved by two packages working together reinforces the idea that success is collective. A project that celebrates only individual package milestones teaches the reverse.

Revisit the Why when the facts change. Sometimes delivery pressure reveals that the original right-hand box needs re-examination. When dates and purpose conflict, the right response is to return to the Why openly — confirming it, adjusting it or making a deliberate trade-off — rather than letting the schedule quietly redefine what the project is for.

Teams, finally, have a life span defined by their purpose; all teams come to an end when their goals are achieved. On large capital projects, where many teams are formed for a phase and then disbanded, that is a reason to define each team's purpose explicitly at its start, so that its members know not only what they must do but when they have done it.

8. Closing: A Shared Date Is the Last Thing to Agree

Large capital projects will always need integrated schedules, and they will always be negotiated hard. The argument here is not against schedules but about sequence. A schedule agreed among parties who share a purpose is a commitment. A schedule agreed among parties who share only dates is a truce, and truces break under pressure.

Owners who want real teams should therefore invert the usual launch sequence. Decide what belongs in the right-hand box. Distinguish the sponsor's purpose, the project's Why and each team's specific purpose. Watch for the pseudo-team hiding behind the logos on the schedule. Align commercial structures so that firms are rewarded for the shared result rather than for defeating each other. Charter teams with task and process goals, surfaced agendas, clear roles and publicly declared results. Then, and only then, fix the dates — and keep asking why for as long as the project runs.

References

• Katzenbach, J. R., & Smith, D. K. (1993). The Wisdom of Teams: Creating the High-Performance Organization. Harvard Business School Press (summary edition, getAbstract, 2007).
• Flyvbjerg, B., & Gardner, D. (2023). How Big Things Get Done. Currency.
• Lencioni, P. (2002). The Five Dysfunctions of a Team. Jossey-Bass / Wiley.
• Shapiro, M. (2015). HBR Guide to Leading Teams. Harvard Business Review Press.
• Marquet, L. D. (2012). Turn the Ship Around! Portfolio.
• Merrow, E. W., & Nandurdikar, N. (2018). Leading Complex Projects. Wiley.
• Williams, T. M., Samset, K., & Sunnevåg, K. J. (Eds.). (2009). Making Essential Choices with Scant Information: Front-End Decision Making in Major Projects. Palgrave Macmillan (Cooke-Davies chapter on front-end alignment).
• Hackman, J. R., & Wageman, R. — research on the conditions for team effectiveness.
• Beckhard, R. — GRPI model of team effectiveness (secondary summaries).
• McChrystal, S., Collins, T., Silverman, D., & Fussell, C. (2015). Team of Teams. Portfolio.