Every enterprise technology programme I've ever been involved with has a technical readiness checklist. Infrastructure provisioned. Environments tested. Data migrated. Security reviewed. And every one of those programmes treated organisational readiness as an afterthought. If they addressed it at all, it was a two-page change management plan written three weeks before go-live. Then they wondered why adoption was 30% after six months.
What You Need to Know
- Technical readiness and organisational readiness are equally important, but most programmes spend 95% of their effort on the technical side
- Organisational readiness means the people, processes, and culture are prepared to absorb and sustain the change
- Assessing readiness before you build prevents the most common adoption failures
- The assessment isn't complicated. Five dimensions, honest scoring, and a willingness to act on what you find
33%
of enterprise software is underused or unused within 12 months of deployment
Source: Gartner, 2020
3.5x
higher adoption rates when organisational readiness is assessed before build
Source: Prosci, 2020
The Readiness Gap
Technical readiness is well understood because it's concrete. You can test whether the server handles the load, whether the API returns the right response, whether the database schema is correct. These things are verifiable.
Organisational readiness is harder to measure, so it gets ignored. But the data is clear: the majority of technology programmes that underperform do so because of organisational factors, not technical ones.
The gap looks like this:
Before go-live, the team asks: "Is the system ready?"
They should also ask: "Is the organisation ready?"
- Do the people who'll use this system understand why it exists?
- Have their workflows been redesigned to incorporate it, or are we layering new technology on top of old processes?
- Do their managers support the change, or are they quietly undermining it?
- Is there capacity for people to learn the new system while still doing their jobs?
- Have we identified the informal leaders whose adoption will influence everyone else?
Five Dimensions of Organisational Readiness
1. Leadership Alignment
Not just "the CEO approved the budget." Real alignment means: the leadership team agrees on why this change is happening, what success looks like, and what they're willing to sacrifice to get there. If the executive team isn't visibly committed, their teams won't be either.
Red flag: Different executives describe the project's purpose differently. One says "cost reduction." Another says "better customer experience." A third says "we need to modernise." These aren't the same thing, and the team will feel the confusion.
2. Workforce Capacity
Change requires time and energy from the people absorbing it. If those people are already at 110% capacity, adding a system change on top is a recipe for resistance. Not because they don't want the new system, but because they literally don't have the bandwidth to learn it while maintaining their current workload.
Red flag: The go-live date is set during the organisation's busiest quarter. Or the team is already dealing with another major change. Change fatigue is real and cumulative.
3. Process Readiness
The new system assumes certain processes. Those processes may not exist yet, or they may conflict with how things actually work today. If the system requires a manager to approve requests within 24 hours, but the current culture is that approvals take a week, the system will work technically but fail practically.
Red flag: The business process documentation describes how things should work, not how they actually work. The gap between designed process and actual practice is where adoption dies.
4. Cultural Fit
Some organisations embrace change. Others resist it structurally. This isn't about individual attitudes. It's about the organisation's history with change, its tolerance for disruption, and the trust level between leadership and staff.
An organisation that's been through three failed technology programmes in five years has a cultural readiness problem. The staff have learned that new systems mean disruption followed by abandonment. Their resistance isn't irrational. It's informed.
Red flag: When you ask staff about previous technology changes, the stories are overwhelmingly negative. "They promised it would make things easier. It made things worse and then they moved on to the next thing."
5. Support Infrastructure
After go-live, who helps when something doesn't work? If the answer is "submit a ticket to IT," adoption will suffer. Users need accessible, responsive support during the transition period. Ideally from people they know and trust, not a helpdesk they've never interacted with.
Red flag: No dedicated support plan for the transition period. The assumption is that training will be sufficient and users will figure it out.
How to Assess
The assessment doesn't need to be complicated. For each dimension, score the organisation honestly on a simple scale:
- Green: Ready. The conditions exist to support adoption.
- Amber: Risks. Specific issues that need attention before or during rollout.
- Red: Not ready. Significant barriers that will prevent adoption unless addressed.
Be honest. The point of the assessment isn't to produce a green dashboard. It's to surface the real risks so you can address them.
I've never seen a readiness assessment that came back all green. If yours does, you're not being honest enough.
Tim Hatherley-Greene
Chief Operating Officer
What to Do With the Results
A readiness assessment that sits in a document is worthless. The assessment should drive action:
For red dimensions: These need to be resolved before go-live or the rollout plan needs to be adjusted. If leadership alignment is red, no amount of training will fix adoption. Fix the leadership alignment first.
For amber dimensions: These need mitigation plans. If workforce capacity is amber, build a transition plan that reduces operational load during the change period. If cultural fit is amber, invest in engagement and communication well before go-live.
For green dimensions: These are your strengths. Leverage them. If support infrastructure is strong, use it as a vehicle for building confidence during the transition.
The Canterbury Lesson
During the earthquake recovery in Christchurch, we had to deploy technology systems into organisations that were under extraordinary pressure. There was no luxury of waiting for "perfect readiness." But we still assessed it. Quickly, honestly, and with a focus on the dimensions that would make or break adoption.
What I learned: readiness doesn't mean everything is perfect. It means you understand the gaps and you have a plan for each one. The organisations that acknowledged their readiness gaps and addressed them directly had significantly higher adoption than the ones that assumed readiness would sort itself out.
Technical readiness ensures the system works. Organisational readiness ensures people use it. If you're spending 95% of your programme effort on the first and 5% on the second, you're building a system that will technically succeed and practically fail. The assessment takes a week. The cost of skipping it shows up for years.