Delivery Excellence: Seven Habits of Organisations That Deliver

Organisations that deliver reliably share seven habits that a maturity model lets you assess and build step by step. They define outcomes before activities and limit work in progress. They deliver in small steps and decide close to the knowledge. They resolve dependencies early, measure flow and learn on a fixed rhythm. Delivery excellence is therefore a matter of daily ways of working.

This article describes the seven habits with rationale, check question and metric, and ends with a maturity model that managing directors and heads of function can use to assess their organisation. It is written for decision-makers whose plans often look good while delivery still arrives later than promised.

What does delivery excellence mean?

Delivery excellence means that an organisation brings initiatives into operation repeatably and predictably, with time and quality under control. The term describes a capability of the whole organisation. A team can work excellently and still deliver late when decisions wait, dependencies are unresolved and ten other initiatives compete for the same specialists.

Research on software delivery provides a sound basis. In their book “Accelerate” (2018), Nicole Forsgren, Jez Humble and Gene Kim analysed multi-year surveys of thousands of professionals. High-performing organisations deliver both more often and more stably: high delivery frequency goes together with shorter lead time, a lower failure rate and faster recovery. Speed and quality appear together in these data. The evidence comes from software development, while the habits apply to any delivery in which work flows through several stations.

The seven habits

Habit 1: Define outcomes before activities

Organisations that deliver describe each initiative first as an outcome with a metric and only afterwards as a list of tasks. The check question is: which metric changes, and how do we know the work is done? An initiative without this answer runs without anyone being able to judge whether it succeeds. The definition of done belongs here, and it covers operations, not just acceptance. The article on the definition of done shows why done in a company is rarely done.

Habit 2: Limit work in progress

They limit the number of initiatives running at once per team. By Little's law, the average lead time equals the number of open items divided by throughput. Every additional initiative lengthens the time to completion of all the others. The Kanban Guide (2020) makes limiting work in progress a core practice. The check question is: how many initiatives does each team run at once, and who may raise that number? A deeper look is in the article on limiting work in progress.

Habit 3: Deliver in small steps

Work is cut into pieces that each have an effect or create knowledge. Small deliveries shorten the feedback time, lower the risk per release and expose errors early. The Scrum Guide (2020) describes an increment that is usable in every sprint. The check question is: how long is the path from idea to first use by a real user, and how can it be halved?

Habit 4: Decide close to the knowledge

Decisions are made where the information sits, within clear limits set by leadership. If every decision waits for a higher level, work stands still that could long since have been done. The check question is: which decisions travel upwards today that a team with authority and criteria could take itself? One framework for this is the allocation of responsibilities by flow of work, as Matthew Skelton and Manuel Pais describe in “Team Topologies” (2019).

Habit 5: Resolve dependencies early

Dependencies between teams and departments are made visible in planning and given a named owner and a date. A large share of lead time consists of waiting at handovers. The check question is: which initiatives are waiting for other teams, and since when? A format that clarifies dependencies in a single day is described in the article on big room planning.

Habit 6: Measure flow

The organisation measures a few metrics on the flow of work and discusses them regularly. The research programme DevOps Research and Assessment (DORA) established four metrics for software delivery: deployment frequency, lead time for changes, change failure rate and time to restore service. For work outside software development, lead time and throughput are the basic building blocks. The check question is: which two delivery figures does the executive team see every week? The article on metrics for agile teams deepens the choice.

Habit 7: Learn and stop on a fixed rhythm

The organisation reviews at fixed intervals what works and stops what does not. This includes retrospectives in the teams and a portfolio review by leadership. Learning requires that mistakes may be raised. In a 1999 study of work teams, Amy Edmondson showed that psychological safety, the shared belief that raising problems carries no penalty, shapes the learning behaviour of teams. The check question is: which initiative or practice did we stop last quarter?

How mature is your organisation?

You determine the maturity of an organisation with a model of three levels per habit: occasional, agreed, embedded. Occasional means a few individuals keep the practice alive. Agreed means a rule exists but is often bypassed. Embedded means the rule appears in planning, and a breach is noticed. Rate each habit using examples from the last two months.

The assessment shows where the biggest gap lies. Begin with the habit whose effect arrives fastest. In delivery practice these are often the limit on work in progress and the visibility of dependencies, because both work without technology and without reorganisation. Habits 4 and 7 need leaders who model the behaviour, and they change more slowly.

How do you build the habits?

You build the habits by introducing one at a time, proving its effect in a metric and then moving to the next. A programme that tries to change all seven at once creates the same overload it is meant to cure. A period of 90 days per habit gives the organisation time to practise and leadership time to model it.

Leadership shapes each of these habits more strongly than any method. If management decides on a limit for running initiatives and breaks it itself the following week, the rule no longer applies. Anyone who wants an organisation to deliver therefore needs someone who keeps the rules and makes deviations visible. This task belongs to delivery management. How the role differs from project management and the Scrum Master is described in the article on the delivery manager.

Delivery excellence with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, in projects ranging from VC-funded scale-ups to DAX 40 corporations, with assignments in more than 20 countries on six continents. In the service area of delivery management and organisation design, he takes the role of delivery manager, project manager or product owner and designs the organisation around it.

The approach follows the Niehues Delivery Model with its three phases. Three of its checking questions matter for delivery excellence: Who decides, who delivers, who uses? Which roles, decision paths and interfaces does operations need? Who is responsible for operations from day one? The entry point is a free initial consultation of 30 minutes, which you can book via the contact form.