Technical ReadinessTechnical Readiness
Choosing Technical Readiness Checklist
Technical Readiness

Choosing Technical Readiness Checklist

Holly WatsonWritten by Holly Watson

Log the decision first, then seek the checklist. A checklist chosen before the decision is formalised will be filled in honestly and used poorly, which is worse than leaving it in the drawer.

Two years ago a billing platform migration at a water utility put three tools side by side. One vendor security questionnaire was thorough in its own scope. One was a production readiness review lifted almost intact from a hyperscaler's site reliability practice. One was a gap analysis against an information security standard. Each was a competent document. No one answered the board's actual question about whether the migration could be reversed during the overnight outage window. Three weeks of form filling produced a thick file and no answer, and the review slipped by a fortnight while somebody wrote the question down properly.

The checks below are grouped by the stage each one becomes useful: Use this checklist before you shortlist, while you compare published tools, at the point of adoption, on the first use, and after the decision is made. You can answer each line yes or no by looking at the material you already have.

The choice, who owns it and when it happened

  • The decision is a single line that does not contain the word readiness.
  • The decision has a set owner, a single individual who answers for it, and a deadline by which it must be made.
  • You can specify the cost of an incorrect answer, whether that is money, lost service, regulatory exposure or a delayed funding round, and let that cost determine the depth of evidence you will demand.
  • The item under review has a limit: one service, one release, one environment, one policy document, one capability.
  • A checklist that covers all areas verifies no specific detail.
  • You have separated the arguments you make from the evidence you have for them.
  • A premise with no evidence behind it is a hope with a heading.
  • You know which requirements may not be waived in your setting, typically personal data, safety and recovery, and which may have a limited exception with a risk owner and an end time.
  • You have agreed who collects the evidence, who reads it, and who is entitled to say no.
  • The checklist results occupy a space in the meeting agenda where the decision is made.

Complete this header before you compare any tool. If you are unable to finish every line, the checklist will fill them in using its own terms.

scope or service ID:
release or revision:
target environment:
review revision and as-of time:
decision:
decision owner:
decision date:
in-scope change:
excluded change:

The published documents describe the scope of the guides

The usual failure is one of fit, and the stated audience and the stated unit of review show it at a glance.

The GOV.UK Digital Readiness Check is written for policymakers and multidisciplinary teams working on new policies or initiatives in government. The checklist contains four sets of queries regarding clear and unambiguous guidelines, digital delivery by default, interoperability and reuse of data, and use of existing common infrastructure, and it expects the digital leadership of a department to have signed off the policy advice. Its first question shows the register it works in:

Has policy and legislation been drafted so as to minimise discretionary assessments and maximise the use of logical rules, using clear, simple, unambiguous and consistent terms?

The TRL 1 to 9 explainer from DefProc works at the other end of the scale of things. Its unit is a single device or technology, and it identifies the artefacts that mark each stage of progress: an in-house proof of concept, a laboratory test with a third party supervising it, a testing rig that resembles the final installation, a certified product with a technical file behind it. A question set built around one service release and a question set built around one device's journey to market can both be sold as readiness checklists, and neither will answer the other's questions.

ATI's guidance on technology readiness levels specifies nine levels from TRL 1 to TRL 9, provides funding primarily for work between TRL 3 and TRL 6, and acknowledges that the definitions are subjective and the scale imprecise, so it employs them as guidance when evaluating projects. If you need a maturity ladder that has been tested for agreement between raters, the TRL-IS work from Salvador-Carulla and colleagues is the one to read: The TRL-IS checklist reports an intraclass correlation of 0.90 for inter-rater reliability, removes laboratory testing altogether, and clarifies the distinction between a pilot in a relevant environment and a demonstration in the real world.

CyberOne's UK guide to ISO 27001 readiness positions its assessment as a pre-audit diagnostic against the Annex A controls and management system requirements of ISO/IEC 27001:2022, with the stated purpose of finding non-conformities ahead of the Stage 1 and Stage 2 audits. The ransomware readiness checklist from samuraisecurity scores each control from 0 to 3 for maturity and tags every one with priority, impact, resource cost and owner, spread across work to finish in thirty days, in sixty to ninety days, and in ninety to one hundred and eighty days. The technical guide from the cross-border paperless trade readiness project splits its self-assessment into the national paperless trade system and the country's status towards cross-border data exchange, with governance, automation, network availability, disaster recovery, security, business process re-engineering, data harmonisation and capacity building sitting under the first half. The technical readiness report described by WireApps is a fixed-scope audit of a codebase and system health, covering architecture, infrastructure, security posture, test coverage and operational readiness, and it is explicit that its product is a set of findings, with remediation handled as a separate engagement scoped from those findings.

Read those together and the pattern is plain. Each tool is competent within its own scope, and that scope determines whether it can inform your decision.

Checks at the point of adoption

  • Every row has a set owner, and the owner is a role that outlives the individual currently filling it.
  • A not applicable entry is a decision, recorded with a written reason and the name of whoever took it.
  • Each piece of evidence has a time and an expiry. Evidence without an expiry becomes folklore.
  • Exceptions are bounded. An exception needs a risk owner, an independent approver, a compensating control, a finite expiry and a defined scope.
  • A blocked item has a next action, an owner and a deadline, so that not ready reads as a state of work with a route out of it.
  • Security, privacy, data integrity and recovery are marked non-waivable if your choice can cause harm, and the exception mechanism does not apply to them.
  • The scoring scale is defined at the point of use. A 0 to 3 scale lacks meaning until you define what a 2 looks like in your environment.
  • The tool explains its limitations. If a checklist claims to prove reliability, capacity or compliance, it has stopped being a checklist and started selling.

Checks on the first run

  • Two people score the same item independently, and the two scores are compared before either sees the other's.
  • A disputed row is settled by returning to the evidence, and the reason for the agreed score is written into the row.
  • Every piece of evidence listed in a row can be opened by a user who was not present when it was gathered.
  • The review specifies the environment it ran in and the revision it ran against, so that a second reader can repeat it.
  • Any item the review failed to test is listed as untested, with the reason and the name of the individual who chose to omit it.
  • An outsider who did not help create the output can read it.
  • The first run is timed, and the time is kept, because the next run will be quoted against it.
  • Blockers are tallied once and that total travels into the decision paper unchanged.

After the decision is made

  • The report is filed with the decision it served, in the same place, so that the reasoning can be reconstructed a year later.
  • Every accepted exception has an owner and a log entry, and the log is checked at the time it lists.
  • Specific events trigger re-validation: A change of scale, a change of environment, a change of owner, or a material change to the item under review.
  • A user maintains a calendar of when evidence expires.
  • Accepted gaps are re-tested when the job is filled, which is usually when a new release or a new funding round is proposed.
  • A short list details what the checklist missed, and that list is reviewed before the same tool is bought again.

Sources