How do you assess your organisation’s digital maturity?

A digital maturity assessment is a structured, evidence-based review of how capable your organisation actually is across seven domains: strategy and leadership, processes and operations, data and information, technology and infrastructure, people and capability, customer or member experience, and security, privacy and governance. Each domain is scored on a five-level scale from ad hoc to optimising, using documents, system records, process walkthroughs and staff interviews rather than opinion. The output is a baseline, a set of prioritised gaps and a sequenced roadmap you can budget against.

This guide is for executives, operations managers, association secretariats and public-sector managers who need to know where they stand before they spend money. It covers what an assessment is and is not, when to run one, the domains and scoring scale, how to gather evidence, how to score honestly, the findings that recur in almost every organisation we review, and how to turn the result into a roadmap. It is written so that you can run the assessment yourself.

What a digital maturity assessment is, and what it is not

It is a diagnostic. It tells you, in a form a board or a funder can read, what exists today, how well it works, what is missing and what should be done first. Its value lies entirely in the honesty of the evidence behind it, so it is not a scorecard to be gamed: an assessment that returns flattering numbers has cost you money and told you nothing.

It is not a technology audit, although it contains one: an inventory of servers and licences tells you what you own, not whether your organisation can use it. It is not a vendor’s discovery call, which is scoped to what that supplier sells and finds problems of the type that supplier can fix. Nor is it a strategy document. Strategy answers what the organisation should become; the assessment tells you what you are currently capable of, which is the constraint every strategy has to respect.

Who should run one, and when

Someone with enough authority to ask uncomfortable questions and no stake in the answer: an operations director, a chief operating officer, a competent internal project manager, or an independent third party. It should not be the person responsible for the systems being assessed, nor the supplier who sold them.

The moments when an assessment repays its cost most clearly:

• Before a major purchase. A six-figure system decision made without knowing the current process is a gamble. The assessment usually costs a small fraction of the licence.
• After a merger, acquisition or a growth spurt. Two organisations mean two of everything, and rapid growth breaks the informal arrangements that worked at half the size.
• When systems keep needing workarounds. A recurring manual step, an export-and-reimport habit, a spreadsheet that reconciles two systems: each one is a symptom of a structural gap.
• When the board asks for a technology plan. A plan without a baseline is a wish list. The assessment is what makes the plan defensible.
• Before a grant or funding application. Development partners and funders increasingly require evidence of institutional capacity. An assessment is that evidence, and it is far more persuasive than assertion.

The seven domains to assess

Strategy and leadership

Is there a written digital plan, is it linked to the organisation’s objectives, and is there a named executive accountable for it? Is there a budget line, or is technology funded from whatever is left?

Processes and operations

Are core processes documented, consistent between people, and measured? Where does work wait, and where is information retyped from one system into another?

Data and information

Is there a single authoritative source for each important dataset? Can you answer a basic question about volumes, members or customers without a week of collation? Is the same figure the same in every system?

Technology and infrastructure

What is in use, what is paid for, what is supported, what is out of support, and what is business critical with no redundancy? Include what staff use unofficially, because that is where real work happens.

People and capability

Who can actually operate and administer each system? Where does capability depend on a single individual? Is there any training beyond somebody showing a colleague once?

Customer and member experience

What does it take for an outsider to join, pay, renew, request or complain? Count the steps and the handoffs. For associations, the renewal journey is usually the most revealing test of all.

Security, privacy and governance

Access control, password practice, backup and tested restore, incident response, data retention, and obligations under the Data Protection Act. Governance questions are where the most serious findings usually sit, and they are the ones organisations most often skip. Compliance and organisational support work typically starts here.

The five maturity levels

Score each domain on the same five-level scale. The descriptions below are written so that you can place your organisation honestly rather than aspirationally. Most organisations that have never assessed themselves sit at level one or two in at least three domains, and that is a normal starting point, not a failure.

Level	Name	What it looks like in practice	Typical evidence
1	Ad hoc	Nothing is written down. Outcomes depend on who happens to be doing the work. Problems are discovered by customers.	No documentation. Different answers from different staff about the same process.
2	Repeatable	It works because experienced people know how it goes. It survives a normal week but not an absence or a peak.	Informal notes, personal spreadsheets, one person everybody asks.
3	Defined	The process is documented, followed and taught. A new employee can be trained from the document.	Current written procedures, induction material, an owner with a name.
4	Managed	The process is measured and the numbers are reviewed by management. Exceptions are visible before the customer reports them.	Reports with targets, meeting minutes acting on them, tested backups, access reviews.
5	Optimising	Measurement drives deliberate change. Improvements are planned, tested and rolled back if they do not work.	A change log, before and after measures, improvements traceable to data.

How to gather the evidence

The quality of the assessment is the quality of the evidence. Six methods, used together, will cover almost everything.

• Document review. Policies, procedures, contracts, licence agreements, the organisational chart and any previous technology plan. Note which documents are current and which were last touched years ago.
• System inventory. Every system in use, its owner, its cost, its renewal date, who administers it, whether it is supported, and what it holds. Reconcile this against the finance ledger; the ledger reliably reveals subscriptions nobody remembers.
• Process walkthroughs. Follow a real case end to end, at the desk where it happens. Not a description of the process, the process itself. This is the single most productive method and it consistently contradicts the documented version.
• Staff interviews. Short, confidential, and asked in the right way. “What takes longer than it should?” and “What do you do outside the system?” produce more than any questionnaire.
• Data audit. Take one dataset and count it in every place it exists. The member count from the database, the finance system and the mailing list will rarely match, and the size of the gap is your data maturity score.
• Security baseline check. Who has administrator access and why; whether accounts of departed staff are closed; whether multi-factor authentication is on; when a restore was last tested; where personal data is stored and for how long.

How to score without deceiving yourself

Three rules keep a self-assessment honest.

Score the evidence, not the intention. A draft policy, a backup that is configured but never restored, a procedure nobody follows: none of these earn the level. If you cannot produce the artefact, the level is not reached.

Score the weakest link in the domain, not the average. An organisation with a modern accounting system and an unprotected member database is not at level three in data; it is at the level of the database, because that is where the risk lives.

Have someone else check the uncomfortable ones. The domains people inflate are almost always security and processes, because a low score feels like a personal judgement. It is not. It is a statement about the organisation, and a level one that is accurately recorded is worth far more than a level three that is not. An independent view, whether from a colleague in another department or through a Digital Ecosystem Assessment, exists mainly to remove this bias.

A four-week assessment process

Four weeks is enough for an organisation of up to a few hundred staff without stopping normal work. Run it in this order.

1. Week one: scope and gather. Agree the domains, name the sponsor, and tell staff what is happening and why, explicitly stating that it is not a performance review. Collect documents, build the system inventory, and pull the finance ledger for every technology line item.
2. Week two: observe. Run the process walkthroughs for three to five core processes and conduct staff interviews. Do the data audit on one important dataset and the security baseline check. Record what you see, not what you are told.
3. Week three: score and validate. Score each domain against the five levels, writing the supporting evidence beside every score. Take the draft back to the people you interviewed and ask them where you are wrong. Expect at least two scores to change.
4. Week four: prioritise and report. Plot the gaps on impact against effort, build the sequenced roadmap, cost the first stage properly and the later stages indicatively, and present it to the board or executive with a decision required, not merely information.

Turning findings into a prioritised roadmap

Sort every gap by impact against effort. High impact and low effort goes first, and that band is usually larger than people expect: closing dormant accounts, enabling multi-factor authentication, cancelling unused subscriptions, testing a restore, writing down the one process that lives in one person’s head. These cost little, reduce real risk and demonstrate progress within weeks, which is what buys you the mandate for the larger work.

High impact and high effort goes second, and only once the dependencies below it are in place. Low impact and high effort should be written down and deliberately declined, because an item that is never formally rejected keeps returning.

Then apply the sequencing rule, which matters more than ambition: no stage should depend on a capability you have scored below three. A customer portal built on a member database that contradicts itself will publish the contradictions. Automation applied to an undocumented process will automate the wrong process at speed. Fix the foundation first, even though the foundation is never the exciting part of the plan. This is why digitisation work generally has to precede operational automation.

The findings that come up again and again

Across assessments in Jamaica and the wider Caribbean, in businesses, associations and public bodies alike, the same findings recur. Look for these first; you will almost certainly find several.

• Undocumented processes that live in one person’s head. Usually a long-serving, highly capable employee. The organisation is one resignation away from a serious problem and nobody has named the risk.
• Spreadsheets that contradict each other. Three counts of the same membership, all different, all in active use, each one defended by whoever maintains it.
• Paid software nobody uses. Licences renewing annually for a tool abandoned after a failed rollout. The finance ledger finds these in an afternoon.
• A backup that has never been tested. Configured, green, reporting success, and never once restored. An untested backup is a belief, not a control.
• Shared administrator passwords. One account used by several people, often including former staff and a previous supplier, with no record of who did what.
• No owner for the website. Nobody can say who holds the domain registration, who has the hosting login, when the platform was last updated, or who approves content. This is why managed website arrangements exist.
• Data held without a retention rule. Personal data kept indefinitely because nobody decided otherwise, which is a growing obligation under the Data Protection Act.

What this means for your organisation

An assessment is only worth the money if it changes a decision. Before you start, agree what decision it will inform: the next budget, a system purchase, a funding application, a board paper. Afterwards, do four things. Publish the scores internally, because a shared baseline prevents the argument being reopened every quarter. Assign an owner and a date to every item in the first band. Put the roadmap into the budget cycle rather than treating it as a separate exercise. And reassess in twelve months against the same scale, since the movement between scores is the real measure of progress.

If you would rather have this done independently, our Digital Ecosystem Assessment covers the same seven domains and produces the scored baseline and prioritised roadmap described here, and digital transformation consulting takes it into delivery. If you run it yourself, the method above is the whole of it: evidence over opinion, the weakest link over the average, and sequencing over ambition. You can request an assessment or work through it internally, but do not skip it and then buy a system.

Frequently asked questions

What is a digital maturity assessment?

A digital maturity assessment is a structured, evidence-based review of how capable an organisation is across seven domains: strategy and leadership, processes and operations, data and information, technology and infrastructure, people and capability, customer or member experience, and security, privacy and governance. Each domain is scored from one to five. The output is a baseline, a list of prioritised gaps and a sequenced roadmap you can budget against.

How long does a digital maturity assessment take?

For an organisation of up to a few hundred staff, four weeks is realistic without disrupting normal work. Week one is scoping and gathering documents and the system inventory. Week two is process walkthroughs, staff interviews, a data audit and a security baseline check. Week three is scoring and validating the draft with the people interviewed. Week four is prioritisation, roadmap and reporting.

What are the five levels of digital maturity?

Level one is ad hoc: nothing written down and outcomes depend on who is doing the work. Level two is repeatable: it works because experienced people know how. Level three is defined: documented, followed and teachable from the document. Level four is managed: measured, with numbers reviewed by management. Level five is optimising: measurement drives deliberate, tested change.

When should an organisation run a digital maturity assessment?

Before a major system purchase, after a merger or a rapid growth period, when systems keep needing manual workarounds, when the board asks for a technology plan, or before a grant or funding application where a partner requires evidence of institutional capacity. In each case the assessment supplies the baseline that makes the resulting plan defensible rather than aspirational.

What findings are most common in digital maturity assessments?

Undocumented processes that live in one person's head; spreadsheets holding the same dataset with different totals; paid software licences nobody uses; backups that are configured but have never been restored in a test; administrator passwords shared between several people, sometimes including former staff or suppliers; no named owner for the website, domain or hosting; and personal data held with no retention rule.

Can we run a digital maturity assessment ourselves?

Yes, provided the person running it has authority to ask uncomfortable questions and no stake in the answer. It should not be the person responsible for the systems being reviewed, nor the supplier who sold them. Score evidence rather than intention, score the weakest link in each domain rather than the average, and have someone independent check the security and process scores, which are the ones most often inflated.