Building Capability

Tool: The People Readiness Audit

Chapter: 9 — Your People Are Not Obstacles. They’re the Point.
Purpose: Assess how ready your people are to engage with, adopt, and ultimately own a new capability — and identify the gaps before they become problems.

How to Use This Tool

Complete this before the build starts — ideally during or just after the initial consultation phase. It helps you identify where the people dimension needs attention, so you can design for adoption, not just functionality.

Before you begin: Open your Business Landscape Map from Chapter 2 and look at the centre zone — the roles in your operation. Which roles appear on the most process overlays? Those are the people with the highest change exposure. Which roles appear on only one overlay, held by a single person? Those are your single points of failure. Which roles sit closest to the customer on the map? Those are the people whose buy-in matters most for adoption. Use the map as your starting point rather than working from memory.

Allow 45 minutes. This should be completed by someone who genuinely knows the team — not just the org chart.

Part 1: Map the People

1. Who will be affected by this capability build?
List every person or team whose working life will change when the new system is in place. Include people who will use it directly, people whose outputs feed into it, and people whose processes depend on its outputs.

Role / team:
How affected:
Likely initial reaction (enthusiastic / neutral / resistant):

2. Who holds the most relevant operational knowledge?
These people are critical to building it right. They’re also often the most at risk of feeling bypassed if they’re not actively involved.

Name / role:
Knowledge they hold:
How they'll be involved in the build:

3. Who has the most to gain — and who has the most to lose?
Be honest. If someone’s role is likely to change significantly, name that now.

Most to gain (and why):
Most to lose (and why):
How you'll manage the "most to lose" conversation:

Part 2: The Consultation Check

4. Have the people who will use this system been asked what they want from it?

[ ] Not yet
[ ] In progress
[ ] Done — and their input has shaped the design

5. What did they ask for that you’ve committed to including?
If you can’t answer this, the consultation may have been information-gathering rather than genuine input.

Requests that are going into the build:
Requests that are going onto the backlog:
Requests that can't be accommodated — and whether those people have been told why:

6. Is there a clear feedback loop throughout the build?
People need to see that their input matters — not just at the beginning.

How feedback will be gathered during the build:
How people will be kept informed of progress:
How suggestions will be tracked and responded to:

Part 3: Adoption Risk

Rate each of the following adoption risk factors on a scale of 1–5 (1 = low risk, 5 = high risk):

[ ] Team is very busy — limited capacity to absorb change alongside normal work
[ ] Previous technology projects have gone badly — low trust in the process
[ ] Senior advocates of the old way — people with authority who prefer the current system
[ ] Consultation has been minimal — people don't feel ownership of what's being built
[ ] Training and documentation plan is unclear or underfunded
[ ] No internal champion — no one person who will drive adoption from the inside
[ ] The change is large — significant workflow changes rather than incremental improvements

Total risk score: _____ / 35

If your score is above 20, adoption risk is high. Consider slowing the build slightly to invest more in the people dimension before go-live.

Part 4: The Training and Documentation Plan

7. Who will own training and documentation for this capability?
Note: This should be an internal person, not the development team.

Owner:
Why this person:
Support they'll need from the development team:

8. What format will training take?

[ ] Written documentation (step-by-step guides)
[ ] Video walkthroughs
[ ] Live training sessions
[ ] Peer-to-peer (experienced users training colleagues)
[ ] Embedded help within the system itself
[ ] Other:

9. Is there a user acceptance testing plan?
UAT is not just a QA step — it’s the moment users become familiar with the system in a safe environment.

Who will participate in UAT:
When it's scheduled relative to go-live:
How feedback from UAT will be acted on:

Part 5: The Role Change Conversation

10. Are there any roles that will change significantly as a result of this build?
If yes, these conversations need to happen before go-live — not after.

Role affected:
How it changes:
Whether this has been discussed openly:
Plan for supporting the person through the change:

Online Version

Want to go deeper?
The online version of this tool includes a full stakeholder engagement plan template, a consultation workshop guide, a user acceptance testing checklist, and a guide for handling role-change conversations constructively.
Available in the members area at [website]