Delivery Capability Is Built-in the Work, Not the Classroom

Executive summary – for delivery leaders and executives

• Training builds knowledge, but delivery capability is an operating result, not a course outcome.

• When incentives, standards, tools and leadership behaviour contradict “good practice,” even highly trained people will revert to old habits.

• Capability is built in real work: through clearer standards, aligned workflows, coaching at the point of need, and leaders who reinforce the expected behaviour under pressure.

• Measure delivery performance (predictability, estimate accuracy, RAIDD quality), not just learning activity (courses, certifications, attendance).

• A practical six‑month sequence—diagnose, define standards, align tools, coach in live work, scale via communities of practice, then measure and adjust—can shift capability without a full methodology overhaul.

Why training alone cannot overcome weak standards, contradictory incentives and delivery systems that make good practice difficult

Steven Gabris

Gabris Group | August 2026

Training builds knowledge. Delivery capability develops when organisations make good practice possible, expected and repeatable in real work.

There is a familiar response when an organisation loses confidence in delivery: provide more training.

The instinct is understandable. Project and program delivery require skilled people, and training and certification give practitioners useful concepts, methods and a shared language. I have benefited from them, and I continue to support them.

But training is often asked to solve a problem it did not create.

The Association for Project Management's 2025/26 Business Leader Index found that confidence among 500 CEOs and managing directors in the UK and Channel Islands in their organisations' ability to deliver projects fell to 46% in January 2026. Confidence in finding people with the right skills fell to 38%. The findings point to a real capability concern.

The easy conclusion is that organisations need to train more people. Sometimes they do. The harder question is whether trained people are returning to a delivery environment that allows them to use what they have learned.

If the organisation rewards the wrong behaviour, has no clear standard for acceptable delivery, relies on poorly configured tools and provides inconsistent leadership reinforcement, another course will have limited effect.

My position is simple:

Organisations cannot train their way out of a delivery environment that rewards the wrong behaviour, tolerates inconsistent standards and makes good practice unnecessarily difficult.

The unit of delivery capability is not the individual. It is the delivery system around them.

Training is valuable, but it is the most convenient intervention

Training is visible. It can be purchased, scheduled and counted. Leaders can report the number of people who attended, completed a module or achieved a certification.

Those measures show learning activity. They do not show that delivery has improved.

A project manager may understand how to write a risk but still work in an environment where material risks are softened before a governance forum. A delivery lead may understand estimation but be pressed to commit to a date before work has been decomposed. A team may learn dependency management but have no common mechanism for recording whether another team has actually accepted the commitment.

In each case, the individual knows the expected practice. The delivery environment discourages or obstructs it.

CIPD describes learning transfer as applying newly acquired knowledge and skills to real workplace situations. Its research has found that only a small minority of learning and development teams prioritise that transfer or evaluate wider impact. That is the gap leaders should pay attention to: not whether learning was delivered, but whether work changed as a result.

Training can introduce a better method. It cannot, by itself, resolve contradictory performance measures, redesign a Jira workflow, establish decision rights, improve the quality of governance conversations or make leaders reinforce the new expectation.

That work must happen inside delivery.

The delivery environment can overrule the classroom

When organisations say they want one behaviour but reward another, the reward usually wins.

Consider some common contradictions:

Leaders ask for realistic estimates but reward teams for confirming a preferred date.

Governance asks for transparent risks but treats the appearance of risk as evidence of poor management.

Teams are told to manage dependencies, yet no standard requires an owner, an accepted commitment or a required-by date.

Project managers are expected to produce consistent reporting, while tools allow every team to use different fields, definitions and workflows.

People are encouraged to plan iteratively, but funding, approvals and reporting still assume certainty at the beginning.

They also explain why some organisations experience a brief improvement after a capability initiative and then regress. People comply while the coach, transformation team or senior sponsor is watching. Once the intervention moves on, the surrounding system pulls behaviour back to its previous state.

If performance falls away when the coach leaves, the organisation has built dependence, not capability.

What capability building looks like in real work

The strongest capability interventions I have seen did not begin by asking, "Which course should we buy?" They began by asking, "Where is delivery breaking down, and what does good need to look like here?"

AP+: coaching against live delivery problems

In my current enterprise delivery coaching work at Australian Payments Plus, the most useful capability building has been horizontal: working across delivery teams, participating in communities of practice and helping solve problems in the work itself.

That has included improving workflows, discussing how work should be decomposed and reviewing the quality of real plans, estimates and RAIDD items. The point is not to tell experienced practitioners that risks need owners or that plans need estimates. It is to work through what sufficient quality looks like in their environment and why the information matters to downstream decisions.

Tools also matter. Standardised Jira workflows and mandatory fields can reduce avoidable variation, support consistent reporting and reinforce the expected path of work. Poor configuration, by contrast, makes good practice reliant on memory and manual intervention.

This is an important distinction. A tool should not attempt to replace professional judgement. It should make the expected behaviour easier to follow, make missing information visible and reduce the amount of effort spent reconciling inconsistent data.

After training, coaching and greater standardisation, I observed more confidence and competence in developing stronger RAIDD items and better-estimated plans. The improvement came from applying the concepts to actual delivery work, receiving feedback and repeating the practice.

BNY: portfolio readiness changed the quality of decisions

At BNY, moving approximately 180 people towards a SAFe portfolio delivery model did not make the underlying work disappear. The work still had to be understood, prioritised, designed, delivered and tested.

What changed was the discipline applied before work entered the pipeline. More time was spent preparing work for delivery, particularly estimating effort and making prioritisation choices. The portfolio view made roadmap relationships and traceability more visible. It also gave leadership better information for deciding what should enter the pipeline, what could realistically be delivered and where competing priorities needed to be resolved.

The lesson was not that adopting a framework creates capability. A framework can provide structure and common language, but capability develops through the repeated decisions and behaviours that make the structure useful.

In this case, stronger readiness led to more confident planning, improved roadmap visibility, better traceability and ultimately better decision-making. The value came from changing how work was prepared and governed, not from renaming meetings or roles.

RBA: generic user-story training could not solve technical decomposition

At the Reserve Bank of Australia, teams moving from waterfall and business-as-usual structures into cross-functional delivery needed more than an explanation of Agile principles or user stories.

They had to determine what good decomposition looked like for their program. The work crossed data, APIs, Python services, React front-end components and testing. A simple UX-centred story model did not answer how those elements should be divided, connected and delivered incrementally. Nor did it solve how test scenarios and automation should be captured, prepared and extended throughout delivery.

Those questions could not be settled in a generic classroom. They had to be worked through with the teams against the architecture, dependencies and delivery constraints they actually faced.

This is where coaching at the point of need becomes valuable. It turns a concept into a practice that fits the work without abandoning the underlying principle.

Organisations need a delivery capability system

Delivery capability does not sit in one team or function. It emerges from several parts of the organisation working together.

1. Aligned goals and measures

The organisation must be clear about the behaviour it wants and ensure KPIs do not contradict it. If realistic planning is expected, leaders cannot punish teams whenever credible estimates challenge a preferred date. If transparent risk management is expected, raising a material risk must lead to a quality conversation rather than blame.

2. Clear standards for acceptable delivery

People need more than broad encouragement to "improve quality". They need a practical definition of acceptable delivery.

What evidence should support a milestone status? What constitutes a credible mitigation? When is work ready to enter the pipeline? What information must a dependency contain? What minimum decomposition is required before an estimate can be trusted?

Standards should create consistency without pretending every project is identical. The aim is to define the minimum level of information and discipline needed for confident decisions.

3. Tools and workflows that reinforce the standard

Expected practice should be reflected in the systems people use every day. Mandatory fields, workflow states, definitions and reporting logic can help prevent critical information from being omitted or interpreted differently across teams.

The workflow should carry the standard into the work. Otherwise, the organisation depends on reminders, spreadsheets and individual diligence to compensate for poor system design.

4. Coaching at the point of need

Training often explains the general case. Coaching helps people solve the specific case in front of them.

That may mean working with a project manager on a weak mitigation, helping a team decompose technical work, challenging an estimate built on assumptions or preparing a delivery leader for a difficult governance conversation.

The coach should not take over the work. The objective is to build the practitioner's judgement and confidence so the quality can be repeated without continued intervention.

5. Communities of practice that spread practical learning

Communities of practice can turn local solutions into organisational learning. They allow delivery leaders to compare approaches, discuss recurring problems and develop shared expectations across teams.

But a community of practice should not become another presentation forum. Its value comes from examining real challenges, sharing reusable solutions and refining standards based on what delivery teams are learning.

6. Leadership reinforcement

Leaders determine whether the new practice survives pressure.

They reinforce capability when they ask for evidence, respect realistic estimates, act on escalated dependencies and make decisions using the standards they have endorsed. They undermine it when they bypass workflows, reward optimistic reporting or accept exceptions without explanation.

Capability building therefore cannot be delegated entirely to learning and development, a PMO or a coaching team. Leaders participate through the decisions they make and the behaviours they reward.

Ownership is distributed, but it must still be explicit

Because delivery capability is systemic, ownership cannot sit in one place.

Delivery leaders should set and model standards. Governance and ePMO teams should translate those standards into proportionate controls, tools and workflows. Coaches should help teams close gaps in live work. Communities of practice should build consistency and share learning across delivery leadership. Executives and functional leaders should align incentives, remove barriers and reinforce the expected behaviour.

Distributed ownership does not mean vague ownership. Each group needs a defined contribution.

When this is unclear, organisations tend to overburden one function. The PMO becomes responsible for chasing compliance. Coaches become permanent quality-control resources. Practitioners are told capability is their personal responsibility while the organisation leaves structural obstacles untouched.

None of those arrangements is sustainable.

Measure delivery performance, not learning activity

Course completions, certifications and attendance have a place. They tell leaders whether an input was provided. They do not tell leaders whether organisational delivery capability improved.

I would focus on three groups of measures.

Predictability

Are teams delivering milestones and increments with greater consistency? Are changes identified early enough for leaders to act? Is the portfolio gaining a more reliable view of what can be delivered and when?

Predictability does not mean forcing teams to meet an unrealistic baseline. It means reducing avoidable surprise through better preparation, evidence and management.

Accuracy

Are estimates becoming more credible? Are forecasts improving as more information becomes available? Are teams explaining variance and using it to improve future planning?

Accuracy should be measured as a learning signal, not used to punish honesty. Otherwise, teams will simply protect themselves by manipulating estimates or delaying escalation.

RAIDD hygiene and quality

Are risks, assumptions, issues, dependencies and decisions current, owned and useful? Do mitigations describe credible action? Have dependencies been accepted by the party expected to deliver them? Are decisions recorded with their consequences?

The objective is not a tidy register. It is management information that supports intervention and decision-making.

These measures should be considered together. A project can have a complete RAIDD register and remain unpredictable. It can appear predictable because a date has not moved while underlying estimates and dependencies are weak. Capability is demonstrated through the quality and consistency of the whole delivery system.

A practical six-month capability-building sequence

An organisation does not need to redesign everything at once. It does need to work in a deliberate sequence.

Month 1: diagnose the delivery environment

Review a representative sample of projects, plans, estimates, RAIDD items, governance packs and tool workflows. Interview practitioners and leaders. Identify where expected behaviours are unclear, unsupported or contradicted by incentives and governance.

The output should be a small number of evidenced capability problems, not a generic maturity score.

Month 2: define acceptable delivery

Set practical minimum standards for the priority areas. Show examples of sufficient and insufficient quality. Agree who owns each standard, where it applies and when tailoring is appropriate.

Keep the first version usable. An exhaustive methodology that nobody can apply will add administration rather than capability.

Months 2 to 3: align tools and workflows

Configure systems to support the agreed practice. Standardise essential fields, definitions and workflow states. Remove duplicate reporting and unnecessary manual reconciliation where possible. Test the changes with practitioners before scaling them.

Months 2 to 5: coach against live work

Work directly with teams and delivery leaders on current plans, estimates, dependencies, RAIDD items and governance conversations. Use the standard as the basis for feedback, while adapting the coaching to the specific delivery problem.

The goal is not for coaches to produce better artefacts. It is for teams to develop the judgement to produce them.

Months 3 to 6: use communities of practice to scale learning

Bring recurring problems and successful solutions into communities of practice. Update examples, guidance and standards as the organisation learns. Encourage practitioners to challenge and support one another, rather than routing every question back to a central team.

Months 4 to 6: measure and adjust

Track predictability, accuracy and RAIDD quality. Look for improvement across multiple reporting cycles. Where the expected behaviour still does not hold, examine the environment before assuming another knowledge gap.

The answer may be further coaching. It may also be an approval bottleneck, a contradictory KPI, unclear decision rights, poor workflow design or a leader who is not reinforcing the agreed standard.

The test is what happens when the intervention steps back

Organisations have built delivery capability when good practice continues under the pressure of real work.

Teams can explain what acceptable delivery looks like. They can adapt the standard without abandoning it. Leaders use the resulting information to make decisions.

Communities solve recurring problems. Tools support rather than obstruct the workflow.

Coaches can step back because practitioners are applying judgement independently and supporting one another.

Training remains part of the answer. It builds conceptual knowledge, creates common language and exposes people to useful methods. But it cannot carry the full burden of organisational change.

If leaders want better delivery, they should certainly invest in their people. They must also invest in the standards, systems, coaching, governance and leadership behaviours that allow those people to perform.

Delivery capability is built in the work because that is where knowledge meets pressure, judgement and consequence. It is also where the organisation proves whether it genuinely wants the behaviour it says it values.

About Steven Gabris

Steven Gabris is an enterprise delivery and transformation leader with experience across payments, financial services, central banking and consulting. He writes about enterprise delivery, governance, operating models and the practical application of AI in delivery through Gabris Group.

Sources

Association for Project Management, Business Leader Index Survey 2025/26 findings, 18 May 2026.

Chartered Institute of Personnel and Development, Evidence-based L&D: measuring learning transfer, 8 March 2022.

Chartered Institute of Personnel and Development, How L&D can create value through social and collaborative learning, 3 December 2024.

Project Management Institute, Organizational Project Management.

Page