Fourteen days before a transformation board meets, technical readiness ceases to be a report and begins limiting what the board can approve. This page is a checklist for that time. Each item is a detail you can settle against your own estate, one way or the other. The order follows the life of a programme: The process involves the case for funding, the choice of tool, the assessment itself, the report, and the months after the decision. You do not need a maturity model to begin. You need to be able to answer, in writing, for the specific configuration you are about to approve.
The subject here is technical readiness: Proof that a specific configuration, in a specific environment, can perform the required task. Digital transformation is the programme, the budget line, the change narrative, and the two get conflated in steering papers every week. Svitla Systems reports that only about a third of transformation efforts deliver measurable business growth, and that two-thirds of large-scale technology programmes run past their original timelines, scope and budget. A readiness declaration that no individual is able to verify privately is one of the reasons.
Before the programme is called or funded
The decision the programme serves is written down, with an accountable executive's name beside it. A decision that only makes sense when it identifies a product indicates the technical work is not yet defined.
The scope of the readiness assessment is limited to the task to be completed. The board needs to know whether the service will work on the first Monday after go-live, and a premise about a platform answers a different question.
An inventory of every system the change will touch exists, including those that have not been opened in three years, and it records the interfaces between them. A slide of logos with lines across it is a diagram.
Velosio's account of a readiness assessment works through people, processes and technology in that order, on the argument that technology readiness can be defined only in the context of the transformation goals and the maturity already in place. A technical team must answer questions about data quality, mapped processes and ownership for the configuration they are using.
Every data set the change depends on has an identified owner and a documented refresh interval. A data set with no owner comes with its defects intact.
The funding request covers integration, training and support alongside licences. A budget that ends at the software purchase funds the first month of the programme and no further costs.
Sopra Steria lists a digital transformation readiness assessment on the Digital Marketplace at £530 a unit a day, which puts a market price against work that many organisations assume they can absorb into existing staff time.
The system environment is documented in a text: the network, the identity provider, the browser estate, the device mix, the data residency rules and the load pattern. The readiness assessment lacks a basis if any of these factors are yet to be confirmed.
Before you choose the assessment tool
The instrument's evidence rules are published before any evidence is collected. When the rules are written after the first scores are seen, the exercise turns into a negotiation over scores.
The tool tests at the level of the job the technology has to do. The UK government's technology code of practice is a set of criteria for designing, building and buying technology, and it expects services to rest on open standards and to meet accessibility requirements. A tool that ignores those criteria will approve a system the public is unable to use.
The document identifies the individual responsible for the readiness status. A committee is unable to sign, and a request without a signature has no owner.
The tool has already been used for a real decision that was waiting for it. If its first outing is the programme you care about, you are piloting it in production.
The cost of operating the tool is known before you start. The marketplace rate for the commercial option above is one benchmark; the internal effort of gathering evidence from live work is the figure you have to place beside it.
During the assessment
Evidence comes from live work. A log line from the active system is more valuable than a screenshot of a configuration screen, and a completed transaction is more valuable than a process diagram.
The team can show the configuration that is actually deployed. When the design document and the running system disagree, the running system wins.
Every gap is logged with a designated owner and a deadline for that owner's response. A gap with no owner and no time remains on the list and effects no change.
The assessment covers people and process alongside technology. Cflow's breakdown of digital readiness into technology infrastructure, employee skillsets, processes and data management is a reminder that a technically sound system still fails when the people expected to run it have had no preparation.
The assessment tests the system under the load pattern it will face in service. Where the load pattern is unknown, the report says so.
Before the board accepts the report
The report lists the tested items, the version, the environment, and the time. Without those four items, a view that the system is ready is an opinion.
The report separates tested claims from assumed claims. A report that uses the same typeface for assumptions and test results misleads the audience, even when every individual phrase is accurate.
The report identifies the individual who signed the readiness declaration, and that individual has the authority to halt the programme. A signature from a user who is unable to halt the work is decoration.
The report includes the conditions under which the premise would no longer be true. A declaration of readiness without a withdrawal condition is never falsifiable.
The board has seen the cost of closing each gap. TSA publishes digital readiness guidance for providers of technology enabled care, covering how they move equipment onto digital broadband networks and what an IP connected service requires of them. Work of that kind is an infrastructure programme with its own budget, and a board that approves a transformation with an unfunded gap list is approving a second transformation to fix the first.
After the decision: keep the fact current
Reassessment triggers are written down. A change of network provider, a change of identity provider, a major version upgrade, a change in the load pattern and a change in the data residency regulations each trigger a review of the readiness assessment.
The owner remains identified after go-live, and the readiness status changes as the estate changes. X-Shift sets out an assessment cycle in which organisations repeat the evaluation periodically and, in its account of where the practice is heading, watch maturity through live dashboards between reviews.
The evidence pack is versioned and stored where the people who need it can find it. If the folder is in a shared drive that no one can find, the next assessment starts from zero.
The readiness status is cancelled in a document when the conditions it depended on are no longer valid. A premise that outlives its evidence is worse than no premise, because users will keep relying on it.
A commercial checklist covering data accuracy, integration, reporting and organisational readiness earns its place by prompting questions a team would otherwise skip. The answers still have to come from your own estate, from the configuration that is deployed, and from the people who run it. The checks above are the ones that decide whether the system will run.
Sources
- Government technology standards and guidance
- Digital Transformation Readiness Assessment, Sopra Steria on the Digital Marketplace
- Is Your Organization Prepared For Digital Transformation?
- Digital Transformation Readiness Assessment: Key Steps and Approaches
- Digital Readiness Guidance
- Digital Readiness Assessment: 3 Steps to Avoid Tech Risk