HomeKnowledge CenterWhy Do Organisations Fail to Build Sustainable Practices?

Why Do Organisations Fail to Build Sustainable Practices?

Most initiatives end when the project ends, because the organisation treats a practice as an event with a closing date. How do we build it as a living system that outlasts the team, the consultant and the champion?

22 May 2026RAISO Experts Team

Why Do Organisations Fail to Build Sustainable Practices?

At the project closing ceremony Layan stands in front of the audience, with a big screen behind her reading: «The risk management practice is complete.» A few months ago she was given the job of leading this project in her organisation. She delivered the procedures manual, designed the templates, trained eighty employees, and handed over the indicators dashboard on time and within budget. Everyone applauds. The chief executive takes a souvenir photo with the team. Six months later Layan happens to pass by the practice folder on the server and finds that its last edit was on the day of the ceremony.

Layan's story repeats in many organisations and in many practices: risk management, customer experience, operational excellence, data governance. The project is delivered on schedule, and then the practice quietly withers. This article takes a clear position: a practice is not a project, it is a sustainable system. A project has a beginning and an end. A practice is a living capability that repeats, learns and renews itself, and does not end as long as the organisation exists.

We will follow Layan's case from the day of the ceremony to the day she finds the abandoned folder. We start by separating a project from a practice. Then we look at five patterns that kill practices after hand-over: no owner, no embedding in roles and systems, dependence on a single champion, no renewal loop, and measurement that ends with the project. After that we uncover the root they share, and what it takes to build a practice that lives. In each section we return to Layan to see what changed in her situation, then leave you a short exercise to try on a practice in your own organisation. This follows Kolb's learning cycle: an experience we live, a reflection on it, a concept we name, and an application we try.

“Layan, her organisation and the figures in this article are imaginary, written for illustration only, and do not refer to any particular organisation.”

— A hypothetical case

A project ends, a practice lives

We begin with a simple distinction that changes everything. A project is a temporary effort to produce a defined output and then stop: building a building, launching a system, organising an event. Its success is judged by delivering the output on time, on budget and to specification. A practice is a repeated capability the organisation performs continuously: how it manages its risks every day, how it listens to its customers, how it improves its operations without pause. Its success is judged not by a moment of delivery but by survival and improvement over time.

Layan made no mistake in her work, but she managed the project with the wrong question. She kept asking: «When do we finish?» The right question is: «How do we make this carry on with no end?» A project seeks closure and a practice seeks continuity. Whoever designs for closure gets closure: a practice that stops the moment the push behind the project stops.

There is another difference that often goes unnoticed: the final product of a practice is not a document, it is repeated behaviour. The manual Layan delivered is a document. The practice only really starts when that manual is followed with nobody reminding people of it. So the moment the organisation celebrated was in truth the starting point, not the finish. The practice had not yet been tested without the team that built it.

Project vs practice: two different questions - What works for running a project is not enough to build a practice that lives.

“A project asks: when do we finish? A practice asks: how do we make sure we never do?”

Where the case stands now: Layan knows the closing ceremony was not the end of the road. In front of her is a practice delivered on paper, and a question she never asked while planning: who will practise it on the Monday after the ceremony?

“Apply it now: Choose a practice launched in your organisation in the past three years. Write two sentences: what was delivered at closure? And what is actually being done today without anyone asking for it? The gap between the two sentences is the size of the problem.”

— A short exercise

Pattern one: nobody owns the practice after go-live

Layan's project has a clear team: a project lead, four members, an outside consultant and an executive sponsor. Everyone knows who is responsible for what until the closing date. But the question that was never asked seriously is: who owns the practice once the project closes and its team disperses? In most cases the silent answer is: nobody.

This gap in ownership after go-live is the first killer of practices. A project team is temporary by definition, and its mission ends with hand-over. Layan returns to the planning department, the members go back to their original jobs, and the consultant leaves when the contract ends. If a permanent owner has not formed by then, meaning a unit or a fixed role in the structure responsible for operating, developing and measuring the practice, the practice is left without a guardian at its most delicate moment: the moment it passes from «a project being built» to «daily work that must be practised».

Real ownership is not a name in a box. It is three things together. First, a body with authority to decide and to amend the practice when reality changes. Second, time genuinely set aside to run it, not carved out of an empty corner of the diary. Third, explicit accountability for its continuity and improvement, visible in performance evaluation. When any of the three is missing, ownership becomes a title without content.

The price of this pattern is that the practice enters a silent decline as soon as it is handed over. Nobody updates the procedures when the system changes, nobody follows up whether they are applied, and nobody has authority to repair them when they break. No one decided to stop the practice, but no one remained responsible for keeping it alive. A practice without an owner is like a plant without anyone to water it: it does not die in a day, but it wilts steadily.

Where the case stands now: Layan is back at her desk in the planning department, and the risk register she built with the departments has not been opened by anyone for three months. Nobody is at fault. No one in the structure has it written in their job description that they are responsible for this register.

“Apply it now: For one practice in your organisation, write the name of its owning role (not a person), then answer: does it have decision authority? Has time been set aside in its diary? Is its accountability measured on the practice continuing? If any answer is no, ownership is incomplete.”

— A short exercise

Pattern two: a practice never embedded in roles and systems

When a project hands over a new practice, it usually hands over a set of separate outputs: a manual, templates, a training deck and an indicators dashboard. These outputs are treated as if they were the practice itself. They are not. They are tools for the practice. The real practice lives in the roles people perform every day and the systems they work through. When it is left hanging above daily work instead of being embedded in its core, it stays foreign to it: performed with effort while someone is watching, and abandoned as soon as the gaze lifts.

Embedding in roles means the practice becomes part of the job description, not an addition to it. Layan looks at the department manager's job description in her organisation and finds not a single word about risk. When risk management is asked for as a parallel activity performed «in addition to» the original work, it is the first thing sacrificed under pressure. When it is built into the heart of the role, so that a manager's work is not complete without managing risks and her performance is not assessed apart from them, it is part of the definition of the work, not a burden on it.

Embedding in systems matters just as much. A practice that depends on individual discipline and memory is fragile by nature, because individuals forget, get busy and leave. A practice embedded in systems becomes a route that is hard to bypass: a mandatory field without which a request cannot be completed, an approval step built into the workflow, an automatic alert when a limit is crossed. When performing the practice becomes the easiest path, even the only possible path, compliance becomes the default and not a daily decision that needs willpower.

The price of neglect is that two practices live side by side: one documented on paper for show, and one real, on the ground. The procedures are written and filed, the training was held and forgotten, while people carry on with the old way because the system does not oblige them otherwise and the role does not hold them to account. The gap between the two is exactly the distance where we neglected to embed.

Where the case stands now: Layan realises her templates were attachments sent by email, with no link to the approvals system every new project passes through. Had the risk assessment been a mandatory field in the project request itself, nobody would have needed to remember it.

“Apply it now: Take one practice and look for two places: where does it appear in the job description of the person who performs it? And where does it appear in a system or form without which the work cannot be completed? If you find it in neither, it is hanging above the work.”

— A short exercise

Pattern three: dependence on a single champion

Behind most emerging practices there is a champion: a passionate employee or a believing leader who carried the idea on their shoulders and pushed it with personal persistence until it became real. In Layan's project that champion was Nasser, the operations manager. He reminded everyone about the register, phoned those who were late, and presented the practice at every meeting. A blessing at launch, but a curse in the long run, because the practice takes shape around his person and not around the system. Risk management becomes «Nasser's practice».

When Nasser was promoted to another branch two months after the ceremony, the practice left with him. It had never been the organisation's practice, only a person's practice inside it. This danger is called «champion dependency», and it is hidden because it disguises itself as success. As long as the champion is present the practice looks alive and thriving, and everyone feels reassured. But that thriving depends on the presence of one person. An organisation that builds its capabilities on named individuals builds on shifting sand.

The difference between a champion and a system is the difference between a capability tied to a person and an institutionalised one. The champion knows how the practice works because he built it himself, but his knowledge is in his head, not in the system. An institutionalised system makes the practice performable by any qualified person who fills the role, because it is documented, embedded, taught and measured, regardless of who performs it.

None of this means doing without champions. It means changing their job. A champion's real task is to build, while carrying the practice in its early days, the system that makes the champion dispensable. A successful champion works so the practice will not need him in two years. Whoever the practice hangs on alone is, in good faith, the greatest threat to its sustainability.

Where the case stands now: Layan sits down with Nasser before he leaves and asks him a new question: «What do you do alone that nobody else knows?» He writes seven things. Layan turns each into a documented step, with a role responsible for it and a trained substitute.

“Apply it now: Ask the champion of a practice in your organisation: what do you do alone that nobody else knows? Then ask yourself: if he travelled for a month tomorrow, what would stop? What the practice stops at is what has to become a system.”

— A short exercise

Pattern four: no renewal loop

Even a practice that is well embedded and has a clear owner faces a slow, merciless enemy: time. The reality it was designed for keeps changing. Systems change, new technologies appear, regulations shift, customer expectations evolve, and the organisation's priorities move. A practice designed to be delivered once and stay fixed turns, with time, from a fitting solution into an outdated burden.

What distinguishes a living system from a dead one is the «renewal loop»: a mechanism that makes the practice review itself, learn and update continuously. A dead system is delivered in a final state and left to age. A living one carries within it the ability to watch its own performance, spot where it is going wrong and adjust itself in response to change. Without that loop, every practice starts losing validity from the moment of hand-over, however well it was built.

The absence of the loop produces a nasty kind of failure: a practice that «succeeded» and then became an obstacle. Imagine the risk assessment form Layan designed asks today for five signatures, because the structure was like that when she designed it. The structure then changed, the form stayed as it was, and it is followed by inertia because «that is how we always do it». The practice turns from a tool that serves the organisation into a ritual the organisation serves. And the irony is that the best-established practices are the most exposed to this fate, because their solidity makes reviewing them seem unnecessary.

The renewal loop: how a practice stays alive - A permanent mechanism that makes the practice review, learn and update itself.

A sustainable practice is measured not by its stillness but by its ability to evolve without losing its identity. The renewal loop is not a luxury added after stability but part of the design from the start: who reviews the practice, when, by what criteria, how it is updated, and who approves the change. Whoever fails to answer these questions on day one is designing, without knowing it, a practice for obsolescence.

Where the case stands now: Layan adds a fixed date to the risk practice: a review every six months led by the practice owner, with three questions written in advance, and authority for the owner to amend or cancel a procedure. The date is in the calendar, not in anyone's memory.

“Apply it now: Pick one procedure in an older practice of yours and ask: when did it last change? Why? And what has changed in reality since it was written? If the procedure has not changed though reality has, that is the gap.”

— A short exercise

Pattern five: measurement that ends with the project

During the project phase everything is measured with care: progress against plan, completion of outputs, the share who attended training, and stakeholder satisfaction. But this measurement is designed to serve the project, to answer the question «did we deliver?», not to serve the practice. So when the project closes, measurement closes with it, and the practice is left running in the dark, with no indicators to show whether it is still practised, practised well, or making any difference.

This temporary measurement creates a dangerous illusion at closure. Layan's dashboard on ceremony day was perfect: every output delivered, all eighty employees trained, stakeholders signed off. So success was announced and the budget closed. But these indicators measure the project's achievement, not the practice's vitality. Between «the practice was delivered» and «the practice is practised» lies a gap that project measurement cannot reveal.

The five patterns: what is missing and the cure
#PatternWhat is missingThe cure
1Nobody owns the practiceA body with authority, set-aside time and clear accountabilityAppoint a permanent owner before the team leaves
2Not embedded in roles and systemsA practice inside the job and the workflowWrite it into job descriptions and systems
3Dependence on a single championA capability that is institutional, not personalDocument what the champion knows and teach others
4No renewal loopA mechanism that reviews and updates the practiceDefine who reviews, when and by what criteria
5Measurement ends with the projectPermanent operational measures and early warningIndicators that accompany the practice for life

Each pattern lets the practice decline silently after hand-over.

A sustainable practice needs a different kind of measurement: permanent operational measurement that accompanies it throughout its life. It does not measure whether the manual was delivered but whether it is followed. It does not measure how many were trained but whether behaviour has changed. It does not measure stakeholder satisfaction at launch but the impact the practice has month after month. This permanent measurement is what feeds the renewal loop and lets the owner manage the practice by numbers rather than impressions.

When permanent measurement is missing, the early warning is missing too. The practice deteriorates without anyone noticing, because nobody measures its deterioration. Years may pass before the organisation finds that a practice it spent heavily to build died long ago, and that what is left is an empty ritual. A practice that is not continuously measured does not die suddenly. It dies without its death being recorded.

Where the case stands now: Layan replaces the project indicators with three permanent operational ones: the share of new projects given a risk assessment before approval, the number of high risks that have a recorded action and owner, and the number of times a risk assessment actually changed a decision. And the job of reading these indicators every month passes to the practice owner.

“Apply it now: For a practice in your organisation, write one indicator showing whether it is practised, another showing whether behaviour has changed, and a third showing its impact. Then ask: who reads these indicators a year after its project closed?”

— A short exercise

The shared root: we managed the practice as an event, not a capability

The five patterns may look separate: an ownership gap, no embedding, champion dependency, no renewal, and measurement that ends with the project. But they are not five illnesses. They are one symptom appearing in five forms. The underlying illness is an error of classification from the start: treating the building of a practice as a temporary project when it is in truth the building of a permanent capability.

One root behind five patterns - The five patterns are one symptom: a classification error at the start.

Notice how each pattern branches from this root. The ownership gap arises because a project hands over and leaves, and was never designed to bequeath the practice to a permanent owner. The lack of embedding arises because a project produces outputs to hand over, not changes in roles and systems that remain. Champion dependency arises because a project relies on someone to push it, not on a system that removes the need for a pusher. The lack of renewal arises because a project seeks a final state to deliver and close. The lack of permanent measurement arises because project measurement serves closure, not continuity. One root: a project mindset applied to what is by nature a capability.

This diagnosis changes the cure. Instead of treating each symptom separately, appointing an owner here and improving embedding there, we see that the cure starts with reclassification: we stop managing the building of a practice as a project with a closing date, and begin managing it as the building of a capability designed to last. Treat the root and the five symptoms recede together.

None of this means a project has no role. Building a practice may well start as a project with a beginning and an end, but its mission is not to deliver documents. It is to establish a system that continues after it closes. The difference is subtle but decisive. The wrong project asks: «What do we hand over before we close?» The right one asks: «What must we leave behind so that it stays alive without us?»

Where the case stands now: Layan writes one word on a sheet of paper: «capability». And she changes the title of what she built from «the risk management project» to «the risk management practice». Then she asks herself: if the ceremony were two years away rather than six months, what would I have built differently?

“Apply it now: Draw a table with five rows named after the five patterns, and mark which ones you see in a practice you launched. Then, beside each mark, write: was the cause that the project was designed for closure?”

— A short exercise
Checklist: is your practice sustainable?
#PrincipleThe question to answerCompliantPartly compliantNot compliant
1Design for continuityDid we ask from day one how it survives after the project closes?
2Hand down ownershipDoes it have a permanent owner with authority, time and accountability?
3Embed in roles and systemsIs it part of job descriptions and the workflow?
4Turn the champion into a systemCan another qualified person perform it without the champion?
5An explicit renewal loopDo we know who reviews it, when and by what criteria?
6Measure continuityDo we measure that it is really practised, not just delivered?

Assess one practice in your organisation against the six principles.

What it takes to build a sustainable practice

If the original mistake was managing the practice as a temporary event, the cure is to build it from the start as a system designed to last. That is the purpose for which RAISO developed the Practice+™ concept and the Practice Builder™ model: an approach that does not merely launch the practice but builds it to take root as an institutional capability that outlives any project or person. The core idea is that a practice is not complete when its outputs are handed over, but when it is able to continue and renew itself without those who built it.

The aim of the model is not to produce a bigger bundle of outputs but to turn a practice from a project delivered into a capability established. By design, not by luck, it addresses every failure point we have seen: it establishes permanent ownership before the project team leaves, embeds the practice in roles and systems, turns champion dependency into a system, builds a renewal loop so that the practice learns, and sets up permanent measurement that accompanies it after hand-over.

The approach rests on six principles any serious organisation can adopt, whatever the named model:

  • Design for continuity from day one: ask from the start «how does this practice survive after the project closes?» not «when do we finish?». Sustainability is an early design decision, not a later repair.
  • Hand down ownership before leaving: appoint a permanent owner, a fixed role in the structure with authority, time and accountability, and move leadership to it in practice before the project team disperses.
  • Embed the practice in roles and systems: make it part of the job description and the workflow, not a parallel activity done «in addition» and sacrificed first.
  • Turn the champion into a system: invest the champion's passion in building what makes the champion dispensable, namely documentation, teaching and integration, so any qualified person can perform the practice.
  • Build an explicit renewal loop: define who reviews the practice, when, by what criteria, and how it is updated, so it evolves as reality changes instead of ageing.
  • Measure its continuity, not its delivery: monitor constantly whether it is really practised, whether behaviour has changed, and what the impact is, not merely whether outputs were delivered.

Let us return to Layan and replay the ceremony with these principles. Two weeks before the event the owning role is announced, and it has already taken over leadership and chaired the last two meetings. The risk assessment form is a field in the approvals system. The list of what Nasser alone knows has been handed to three employees trained on it. The first renewal review is waiting in the calendar six months out, and the permanent measurement dashboard has been open to the owner since closing day. In this version, when the consultant leaves and Nasser is promoted, the practice carries on as it is. And nobody in the ceremony applauds because the manual was delivered, but because everyone knows who will practise it on Monday morning.

“A successful practice is not the one whose delivery was celebrated, but the one still practised and improving after everyone has forgotten it was ever a project.”

Where the case stands now: Layan's ceremony turns from a celebration of delivery into a test of survival. And her questions change from «have we completed the outputs?» to «what will stay alive if we all disappear?»

“Apply it now: Before your next project closes, write a six-point list titled «what we leave behind», one point for each principle. And do not close the project until each point has a name or a date written beside it.”

— A closing exercise

What you carry with you

Organisations fail to build practices when they manage them as projects that end when their term ends. They succeed when they see them for what they are: sustainable systems built to live and renew themselves. We saw five patterns that kill a practice after hand-over: no owner to receive it, no embedding in roles and systems, no renewal loop, no permanent measurement, and a single champion carrying it on his shoulders. Their common root is that we treated a capability like an event.

In the wide institutional capability-building that Saudi organisations are living through under Vision 2030, this argument matters even more. The Vision pushes organisations, public and private, into an unprecedented wave of practice building: in operational excellence, customer experience, risk management, governance and digital transformation. That momentum is a blessing if matched by an ability to make what is built take root, and a source of heavy waste if every practice is built with a project mindset and dies when the project does. The real difference between organisations will not be in how many initiatives they launch, but in how many practices they manage to keep alive.

Perhaps the hardest part of this argument is that it asks leaders to postpone the moment of celebration. The natural tendency is to celebrate the closing of a project and the delivery of its outputs, because it is a tangible moment that can be shown. A sustainable practice asks for a different patience: not to celebrate delivery but survival, and not to measure success by what we achieved at closure but by what is still alive years after those who built it have gone.

The most important question in any initiative to build a practice is therefore not «when do we finish?» but «what will stay alive after we finish?» Whoever dares ask it from the start builds practices that last. Whoever postpones it until after closure discovers they never built a practice at all, only a project that ended.

Take one step this week: choose a practice in your organisation and answer the three ownership questions. And if you want to build your practices to last with an orderly method, explore RAISO's Practice+™ approach and Practice Builder™ model, and the courses that train your teams in establishing ownership, permanent measurement and the renewal loop.