Home
Readiness assessment

Readiness assessment

Twenty questions about how the work actually runs.

Pick the area you want looked at. You get four scores, the order to fix things in, a 90 day plan and the stack decisions that sit under it. Free, whether or not we ever speak.

1Choose a focus
2Answer the questions
3Read the report

Step 1. Choose a focus

Step 1 What should we assess?

Each of the four capabilities asks twenty questions about one area in depth, including what the weakness is costing the business. The last option asks twenty questions across all four.

AI & Digital Transformation 20 questions For operations leaders whose work still stops and waits for a person to move it along. Product Engineering 20 questions For teams that build software and want to know why releases take as long as they do. Data, Analytics & Insights 20 questions For anyone who cannot settle an internal argument with a number everybody trusts. Enterprise Modernization 20 questions For estates running on core systems that still work but resist every change. Full digital transformation 20 questions For a view across all four at once, when you are not sure which one is hurting most.

Section 1 of 5 Process visibility and cycle time

AI-A1 Your highest volume internal process, from the request arriving to the work being finished, takes:

We could not say, it varies and nobody tracks it Somebody could work it out from a few systems over a day or two We report it monthly It is on a live dashboard with the slow stages visible

AI-A2 A request is sitting in a queue right now. Finding out which stage it is at takes:

We would have to ask several people and might still be wrong An email to the team that owns it A report someone runs on request Under a minute, on a view anyone can open

AI-A3 When volume doubles for a month, the process:

Falls behind, and we find out from complaints Falls behind until we move people onto it Holds, with overtime Holds, because most of it does not need a person

AI-A4 Of the total time a request spends in your process, the share spent waiting rather than being worked on:

We have never separated the two We assume most of it is being worked on We know roughly, from a sample Every stage is timestamped, so the waiting is visible

Section 2 of 5 Manual handling and exception load

AI-B1 When a document needs checking, whether that is KYC, compliance, invoices or credentials:

A person opens every one and nobody knows the queue length A person opens every one Partly automated, most still checked by hand Extraction and checks run automatically, people handle exceptions

AI-B2 Of the items your team handles by hand each week, the share that are routine and never raise a question:

We have never looked at it that way We think most of it is routine but have not sampled it We know roughly, and route some of it differently We know, and the routine path is already separate

AI-B3 Data gets typed into a system from another system or a document:

Every day, in several teams Weekly, in one or two places Rarely, only for exceptions Not at all, it moves through integrations

AI-B4 When something entered or checked by hand is wrong, the mistake is caught:

Downstream, by a customer or a partner At a later checking step, days afterwards The same day, by a second pair of eyes At the point of entry, by a validation rule

Section 3 of 5 AI in production and governance

AI-C1 AI in a workflow real users depend on:

None Pilots that never reached production Yes, in production, with a thin audit trail Yes, with decision logging and human sign-off

AI-C2 If an AI-assisted decision were challenged by a regulator, an auditor or a customer:

We would have no way to show how it was reached We could reconstruct it with effort We keep logs but have not tested them against a challenge Inputs, model version and the reviewer are recorded per decision

AI-C3 Rules for what staff may put into public AI tools:

No rule, and we do not know what is being used An informal understanding A written policy, not enforced technically A written policy with approved tools and controls behind it

AI-C4 What happens to company data sent to an AI service is:

Not something anyone has checked Covered by a vendor statement nobody has read closely Set out in a contract with the main vendor Set out in a contract, with retention and training terms agreed per use case

Section 4 of 5 Data and systems readiness for automation

AI-D1 The systems a new automation would need to read from and write to expose:

We do not know what they expose File exports only Some APIs, some file exports Documented APIs for the systems that matter

AI-D2 Records that describe the same customer, partner or product in two systems:

Often disagree, and there is no rule for which one wins Disagree, and people know which system to trust by habit Mostly agree, with a reconciliation step One system owns each record and the others follow it

AI-D3 Who decides that a process is allowed to run without a person checking every case:

Nobody has that authority, so it has never happened It would need a case made to several leaders A named owner, with a risk review A named owner, with agreed thresholds already written down

AI-D4 History for the process you would automate, far enough back to tune anything against:

Not kept beyond the current records Inside a system, but nobody has ever got it out Extractable with effort, without the outcomes attached Available, with the outcome of each case attached

Section 5 of 5 Business impact and constraints

AI-E1 The cost of handling this work by hand, as a number you could put in a paper:

Nobody has put a number to it A guess, from headcount The headcount cost, without the error and delay cost The loaded cost, including rework and delay

AI-E2 Pressure to automate this is coming from:

Nowhere in particular, it is an idea we keep returning to The team doing the work, who hold no budget An operations or finance leader with a target A named executive sponsor, with a target and a date

AI-E3 Money and a date for this in the current plan:

Neither is allocated A date exists, with no budget behind it Budget exists, inside a larger program Budget and a date, with a named owner

AI-E4 The last attempt to automate something here:

Stopped, and nobody is sure why Stopped on something we would meet again Stopped for a reason we have since removed Finished, and we know what it returned and what it did not

Section 1 of 5 Discovery and validation

PE-A1 Before a feature is built, the people who will use it are spoken to:

Not at all, requirements come down as a document Once, at requirements gathering At the start and at a review Through the build, on a prototype they can use

PE-A2 The last significant feature you shipped was used by:

We do not know Fewer people than expected, we think About as many as expected We set a target before build and compared against it

PE-A3 From a validated idea to something a real user can touch:

Over six months, or it does not reach users Three to six months Six to twelve weeks Under six weeks

PE-A4 Before build starts, what gets written down is:

A description of the solution somebody asked for A list of features A problem statement, agreed with the requester A problem statement with the measure that would show it solved

Section 2 of 5 Delivery speed and release practice

PE-B1 Software reaches your users:

When a project finishes Quarterly Monthly Every two weeks or faster

PE-B2 A release goes out:

Manually, and only one or two people can do it Through a partly scripted process with manual steps Through a pipeline, with a manual approval Through a pipeline, with automated tests and a rollback path

PE-B3 After a release, a problem in production is noticed:

When a user reports it, sometimes days later When someone checks the logs Within the hour, by alerting on errors Within minutes, with alerts tied to user-facing behavior

PE-B4 From a change being finished by an engineer to it running in production:

Weeks, it waits for a release window Several days About a day Under an hour, it goes out on its own

Section 3 of 5 Architecture and quality

PE-C1 Automated tests covering your main application:

None, testing is manual A few, written after incidents Reasonable coverage of the core paths Core paths covered and running on every change

PE-C2 Changing one part of the system without affecting others:

Almost never possible, everything is connected Possible, but we cannot be sure until it is live Usually possible, with a few known hotspots Yes, boundaries are clear and enforced

PE-C3 Bringing a new engineer to a first useful change takes:

We could not say, it has been painful Over a month Two to four weeks Under two weeks, the setup is documented

PE-C4 The frameworks and libraries your application depends on are:

Several major versions behind, and we avoid upgrading Behind, upgraded only when something forces it Close to current, on an occasional cycle Current, with automated checks and tests behind each upgrade

Section 4 of 5 Product analytics and feedback

PE-D1 You find out a feature is not working for users because:

Usually we do not find out Someone senior complains Users tell support and support tells us It is instrumented and we see it in the data

PE-D2 For your most important user journey, you can say how many people start it and how many finish:

No We could estimate from a database query Yes, from a report we run Yes, on a dashboard, broken down by step

PE-D3 What gets built next is decided by:

Whoever escalates hardest A long backlog worked through in order A prioritized roadmap reviewed each quarter Expected outcome per item, checked after release

PE-D4 What support and sales hear from users reaches the people deciding what gets built:

Not in any organized way Only as escalations As a summary, reviewed each month As tagged themes, reviewed beside usage data

Section 5 of 5 Business impact and constraints

PE-E1 What your current delivery pace costs the business, stated commercially:

We have never framed it that way We discuss it as frustration rather than money We can name launches or deals it has delayed We can name them, with the revenue or cost attached

PE-E2 The people asking for this product or system to get better are:

Mostly the engineering team One internal department, informally Customers, through sales and support Customers, and a named executive who owns the outcome

PE-E3 Funding and a date for the next phase of this product:

Neither is agreed A date has been announced, with no budget behind it Budget approved for a phase, timing open Budget and date approved, with scope allowed to move

PE-E4 The last attempt to change how you build and release:

We have discussed it more than once and nothing changed Started, then stopped when delivery pressure returned Partly done, and what landed has held Done, and we know which change made the difference

Section 1 of 5 Data foundation and pipelines

DA-A1 Reporting data is pulled from:

Exports that people keep on their own machines Each source system separately, then joined in a spreadsheet A warehouse for some sources, exports for the rest One warehouse or lakehouse that all reporting reads from

DA-A2 Data moves from source systems into reporting:

When someone remembers to run it On a manual schedule someone operates Automatically, with failures found the next morning Automatically, with alerting when a load fails

DA-A3 Data quality problems, such as duplicates, gaps or bad values, are found:

By whoever is reading the report During month end, when things do not add up By periodic manual checks By automated checks that run with every load

DA-A4 History in your reporting data goes back:

As far as the current system, older data was left behind in a migration A year or two, with gaps nobody has mapped Several years, with a known break in the middle Several years, consistent, with any breaks documented

Section 2 of 5 Definitions, ownership and trust

DA-B1 Two teams present the same KPI in the same meeting. The numbers match:

We have stopped presenting the same metric twice Often not, and we spend the meeting reconciling Usually Always, there is one agreed definition

DA-B2 Your most quoted metric has a written definition:

No, and people calculate it differently It lives in a query somebody wrote Written down, in a document people have to find Written down, with an owner, and shown beside the number

DA-B3 Who is allowed to see which data:

Anyone with the link can open most of it Set per report, by whoever built it Managed by role, with some exceptions Managed by role, with sensitive fields restricted and logged

DA-B4 When a published number turns out to be wrong and gets corrected:

Nobody is told, the report simply changes People notice and ask A note goes out to the people who saw it Versions are kept, with the reason for the change recorded

Section 3 of 5 Reporting speed and access

DA-C1 From month end to a report leadership actually trusts:

Longer than three weeks, or it arrives and gets questioned Two to three weeks Under a week It is live and always available

DA-C2 Time spent assembling reports by hand each week:

More than half of someone’s role Two to three days Under a day Almost none, it is automated

DA-C3 A manager who wants a number that is not on an existing report:

Usually gives up Raises a request and waits weeks Asks the analytics team and gets it in days Answers it themselves from a governed dataset

DA-C4 Of the reports your team maintains, the share anyone still opens:

We do not know which reports are used We suspect most are not, but have never looked We know, and retire one occasionally Usage is tracked and unused reports are retired on a cycle

Section 4 of 5 Decisions and advanced analytics

DA-D1 The last significant decision made against the numbers rather than opinion was:

We cannot think of one Over a year ago In the last quarter This month, and it is normal practice

DA-D2 When a customer or partner is about to leave, you find out:

When the revenue stops When they tell us Early, from behavioral signals Before it happens, we model it

DA-D3 Forecasting for the next quarter is produced by:

Last year plus a percentage Each team’s own judgment, added together A model, adjusted by the business A model, with accuracy reviewed against outcome each quarter

DA-D4 When you change pricing, a process or a campaign, the effect is:

Never isolated, we look at the total afterwards Judged by whether the overall number moved Compared against the same period last year Compared against a control group or a holdout

Section 5 of 5 Business impact and constraints

DA-E1 What your reporting gaps cost, stated as a number:

We have not tried to put a cost on it We describe it as wasted analyst time and nothing more We can name decisions it has delayed We can name them, with the value at stake on each

DA-E2 The push for better reporting is coming from:

The analytics or reporting team itself Individual managers, one request at a time A leadership team that has asked for one view A named sponsor with a decision waiting on it

DA-E3 Budget and timing for data or reporting work this year:

Nothing is set aside Whatever another project can absorb A line in the plan, sized from a guess A line in the plan, sized against a scoped first phase

DA-E4 The last attempt at one agreed source for reporting:

Ended with everyone back on their own spreadsheets Delivered a tool, without agreed definitions Worked for one domain and stalled on the rest Worked, and we know why it held

Section 1 of 5 Core system age and change cost

EM-A1 Your most business-critical system was last substantially rebuilt:

Longer than ten years ago, or nobody is certain Seven to ten years ago Three to six years ago Within the last three years

EM-A2 A small change to that system, such as a new field or a new rule, takes:

We avoid changing it Months, and it needs a vendor Weeks, with our own team Days

EM-A3 The version or platform your core system runs on is:

Out of support, or we do not know Supported, but several versions behind Current, with upgrades done late Current, with a planned upgrade cycle

EM-A4 Customizations made to that system over the years are:

Extensive, and nobody has a list Extensive, with a partial list Listed, with some already retired Few, with the rest handled by configuration

Section 2 of 5 Integration and data movement

EM-B1 Your main systems exchange data through:

Someone downloads a file and uploads it somewhere else Scheduled exports and imports APIs, with some manual gaps APIs, with monitoring

EM-B2 When an integration between two systems fails:

We find out from the business, later Someone checks a folder or a log An alert goes to the team An alert goes to the team, with retry and a replay path

EM-B3 Adding a new system to your estate means connecting it to:

Every other system, one by one, and we dread it Several systems through hand-built point-to-point links A small number of shared interfaces An integration layer that the new system plugs into

EM-B4 That the data on both sides of a transfer agrees afterwards is checked:

Not at all, differences turn up by accident At month end, by hand By a reconciliation report someone reviews Automatically, with differences raised as they happen

Section 3 of 5 Infrastructure and operations

EM-C1 Your core business systems run:

On hardware we own, in an office or a room In a data center, on machines dedicated to us On cloud virtual machines we manage On managed cloud services with defined scaling

EM-C2 Restoring a core system from backup was last tested:

Never, or we could not say Over a year ago In the last year In the last quarter, with a recorded recovery time

EM-C3 Environments for development and testing:

We test in production One shared environment teams queue for Separate environments, manually maintained Environments created from code, close to production

EM-C4 Security patches on the systems that run your business are applied:

When something forces it A few times a year, by hand On a monthly cycle, tracked On a cycle, with an inventory that shows what is still outstanding

Section 4 of 5 Knowledge, documentation and continuity

EM-D1 If the person who understands your core system best left tomorrow:

We would be in real trouble A serious problem for a quarter or more Painful for about a month It is documented, others can operate it

EM-D2 A current diagram of which systems exist and what they exchange:

Does not exist Exists, from a project two or more years ago Exists and is broadly current Current, owned, and updated when anything changes

EM-D3 The business rules inside your core system are:

Only in the code, and partly in people’s heads In the code, with scattered notes Documented for the main processes Documented, with owners, and checked against the code

EM-D4 If the vendor who supports that system stopped working with you tomorrow:

We could neither run it nor change it We could run it, but not change it Another vendor could take it on, after a long handover The code and the documentation are ours, handover is weeks

Section 5 of 5 Business impact and constraints

EM-E1 What that system costs beyond license and support, in delay and workaround:

Nobody has added it up We know the license line and nothing else We know the license and the support effort We know both, plus the cost of the work done around it

EM-E2 The case for modernizing is being made by:

Nobody, it comes up when something breaks The technology team, to a board that hears cost Technology and one business function together A business sponsor whose own target depends on it

EM-E3 Budget and timing for replacing or modernizing this:

Neither, and it is not in the plan A date set by an end-of-support notice, with no budget Budget for a first phase, timing open Budget and a phased plan, with the first slice scoped

EM-E4 A previous attempt to replace or upgrade this system:

Was abandoned, and the subject is now hard to raise Overran, and finished smaller than planned Finished late, and is in use Finished, and we know which part was underestimated

Section 1 of 5 AI and digital transformation

AI-A1 Your highest volume internal process, from the request arriving to the work being finished, takes:

We could not say, it varies and nobody tracks it Somebody could work it out from a few systems over a day or two We report it monthly It is on a live dashboard with the slow stages visible

AI-B1 When a document needs checking, whether that is KYC, compliance, invoices or credentials:

A person opens every one and nobody knows the queue length A person opens every one Partly automated, most still checked by hand Extraction and checks run automatically, people handle exceptions

AI-C1 AI in a workflow real users depend on:

None Pilots that never reached production Yes, in production, with a thin audit trail Yes, with decision logging and human sign-off

AI-D1 The systems a new automation would need to read from and write to expose:

We do not know what they expose File exports only Some APIs, some file exports Documented APIs for the systems that matter

Section 2 of 5 Product engineering

PE-A1 Before a feature is built, the people who will use it are spoken to:

Not at all, requirements come down as a document Once, at requirements gathering At the start and at a review Through the build, on a prototype they can use

PE-B1 Software reaches your users:

When a project finishes Quarterly Monthly Every two weeks or faster

PE-C1 Automated tests covering your main application:

None, testing is manual A few, written after incidents Reasonable coverage of the core paths Core paths covered and running on every change

PE-D1 You find out a feature is not working for users because:

Usually we do not find out Someone senior complains Users tell support and support tells us It is instrumented and we see it in the data

Section 3 of 5 Data, analytics and insights

DA-A1 Reporting data is pulled from:

DA-B1 Two teams present the same KPI in the same meeting. The numbers match:

We have stopped presenting the same metric twice Often not, and we spend the meeting reconciling Usually Always, there is one agreed definition

DA-C1 From month end to a report leadership actually trusts:

Longer than three weeks, or it arrives and gets questioned Two to three weeks Under a week It is live and always available

DA-D1 The last significant decision made against the numbers rather than opinion was:

We cannot think of one Over a year ago In the last quarter This month, and it is normal practice

Section 4 of 5 Enterprise modernization

EM-A1 Your most business-critical system was last substantially rebuilt:

Longer than ten years ago, or nobody is certain Seven to ten years ago Three to six years ago Within the last three years

EM-B1 Your main systems exchange data through:

Someone downloads a file and uploads it somewhere else Scheduled exports and imports APIs, with some manual gaps APIs, with monitoring

EM-C1 Your core business systems run:

On hardware we own, in an office or a room In a data center, on machines dedicated to us On cloud virtual machines we manage On managed cloud services with defined scaling

EM-D1 If the person who understands your core system best left tomorrow:

We would be in real trouble A serious problem for a quarter or more Painful for about a month It is documented, others can operate it

Section 5 of 5 Business and operating context

F-E1 The problem you are trying to fix has a cost the business has stated:

No, it is discussed as frustration A rough number one person carries in their head A figure agreed between finance and the team affected A figure, with the revenue or decisions it is holding up named

F-E2 A change of this size would be decided by:

Nobody is clear, which is part of why it has not been decided A committee that meets quarterly One executive, after a business case One executive, who has already asked for the proposal

F-E3 Money and a date for a first phase:

Neither exists A date, driven by an outside deadline, with no budget Budget for a first phase, timing open Budget and a date, with an owner named

F-E4 Work of this kind that was started before:

Stalled, and nobody reviewed why Stalled on a constraint that is still in place Delivered partly, and what landed is still in use Delivered, and we know what made it work

Last step Where should we send your report?

Your report opens straight away and we email you a link to keep for a year.

Name

Work email

Company

Your role

Website

Dezigndia may store my answers and details to prepare the report and follow up once about it. See the privacy policy.