Nobody decides to abandon the values a project was built on. It happens one reasonable decision at a time.
Picture a public-sector project to rebuild an online application service. At kickoff, everyone agrees on what matters. Citizens should be able to complete an application in one go, without calling for help. Caseworkers should spend less time chasing missing information. The values are discussed, written down and signed off.
Eighteen months later, the service goes live. Call volumes barely move. Caseworkers still chase the same documents. Nobody made a bad decision along the way. The sponsor who championed the citizen perspective moved to another role. A legal review added a confirmation step. A deadline pushed the guided flow into "phase two". The chosen platform couldn't handle the interactive eligibility check, so it became a static page. The team was measured on features delivered and a go-live date. Each choice was defensible on its own. Together, they produced something that no longer served what the project set out to do.
We call this value drift: project and design decisions gradually losing touch with the values that were agreed at the start.
“This is about going beyond project management success to simply project success. We must take accountability beyond the technical side of our work. The research shows that what truly matters is how stakeholders perceive the value of a project relative to what it took to get there.” - Pierre Le Manh, President and CEO of PMI
A bigger problem than it looks
Value drift rarely shows up in project reports, because those track time and budget. But the gap between promised and delivered value is well documented in overall efforts. In 2024, PMI redefined project success as delivering value that justifies the effort and expense. Measured that way, only 48 percent of projects succeed, 40 percent land in a grey zone and 12 percent fail outright, with government projects scoring below average. McKinsey's research on digital and AI transformations points the same way: large companies capture on average only 31 percent of the revenue lift and 25 percent of the cost savings they expected.
Not all of that is drift. But much of the distance between what was intended and what was delivered is covered in small steps nobody noticed taking.
Drift is not the same as change
Projects should learn. New insight, changed policy or a shifting market can and should change direction. That is not drift.
The difference is awareness. Change is deliberate: it is discussed, decided by the right people and recorded, and the shared reference is updated to match. Drift is unnoticed: the reference stays the same while the work quietly moves away from it. A simple test: can you point to the moment the direction changed, and the people who decided it? If you can, it was change. If you can't, it was drift.
Why it happens
People change. Sponsors, product owners and team members come and go. Newcomers inherit the work but not the conversations that shaped it.
Delivery pressure. Deadlines, budget cuts and scope negotiations push values aside, usually with the promise of "later".
Technical constraints. During implementation, the development stack or the team's expertise can force a change to the solution. A component library doesn't support the agreed interaction, or a platform limits the flow. The change gets made because it is technically necessary, but nobody asks what it costs in value.
Long timelines. The longer a project runs, the more small decisions accumulate. Each one shifts the course by a degree or two.
The reference goes out of sight. Values agreed at kickoff end up in a document nobody opens again. What is not looked at cannot be checked against.
How to recognise it
Drift is quiet, but it leaves traces. Settled debates reopen, because nobody remembers why they were settled. The team cannot link a design decision back to a value or goal. Metrics shift towards what is easy to count, such as output, velocity or launch dates, rather than the outcomes that were agreed. And most painfully, a launch or review reveals that the result does not deliver what was intended. By then, correcting course is expensive.
Preventing it: value needs its own assurance
Every serious project has quality assurance. Nobody ships without testing whether the product works as specified. Yet whether it still serves what everyone agreed matters is usually checked only twice: at kickoff and at the post-mortem.
PMI's research shows what changes when that gap is closed: projects with clear goals and metrics tracked over their whole life were nearly twice as likely to succeed. In practice, that comes down to a few habits. Make the agreed values specific enough to check against. Keep them visible in every review. Check recent decisions against them at every stage, not just at the end. And when the direction should change, change the reference on purpose.
At Keen, we formalise this in Value Driven Design. Where quality assurance checks that we built things right, Value Assurance checks that we are still building the right thing: a recurring step in every stage that tests design, product and technical decisions against the agreed values in a Value Brief.
Start tomorrow
Take the most recent significant decision in your current project and ask: which agreed value does this serve? If the answer takes longer than a minute, or nobody can find where the values are written down, you have found your starting point.
References
-
Project Management Institute Champions a New Era of "Project Success" - PMI, 19 September 2024 (new success definition; 48% / 40% / 12%; clear goals and tracked metrics nearly twice as likely to succeed)
-
Rewired for value: Digital and AI transformations that work - McKinsey, July 2023 (31% of expected revenue lift, 25% of expected cost savings; from McKinsey's 2022 global survey)
