Technical readiness in project management is an assessment, with a day and time and backed by evidence, that a particular group of staff can perform a defined piece of work in the setting where that work will actually happen, using tools, information and support already available to them.
A distribution programme in the Midlands shows the shape of that failure. The technology had a clean history: pilot cycles had passed, the vendor had signed off, and the test warehouse reproduced the pick rates the business needed. The board sat a fortnight from cutover. No one in the room had tested whether a shift supervisor on a chilled aisle, wearing gloves, at the end of a night shift, could scan a damaged pallet and reconcile it in the system without calling a colleague. The platform met its specification; the job it had to support did not. Every tool in the programme pack had answered a question the board was not asking, and none of those tools was badly built. They had been pointed at the incorrect noun.
What the term covers, and the three parts of a decision
Readiness attaches to a specific group of people facing a decision. A platform, a production line, a model and a delivery team have no readiness in isolation, because readiness is always readiness for a goal, at a time, before a user who has to authorise it. The model that Errida and Lotfi built and applied at a Moroccan construction firm, reported in the Academy of Strategic Management Journal, rests on four dimensions: organisational readiness, individual readiness, project management maturity and change management maturity. All four reside with the organisation and its personnel, and the study demonstrates how unevenly they develop. The site managers and the support functions in that firm reported that they lacked the knowledge the incoming methodology demanded, and the researchers recorded weakly defined processes, thin documentation and no formal approach to managing the human side of the change. Each of those is a separate readiness question with a separate owner.
The organisation facing a decision is the unit under assessment, and that decision has three parts which must be documented before measurement begins: The work to do, the individual responsible for doing it, and the deadline by which it happens. Until those three exist, an assessment has no target to hit, and a favourable score proves only that the tool was pointed somewhere.
The threshold determines which tool may communicate
A readiness check applies to a scope with a limit, and users define that limit. The Aerospace Technology Institute, which funds work that shifts technology through the maturity levels, is unusually direct about how soft the edge can be. The guidance on technology readiness levels records that the definitions can be subjective and the scale imprecise, so the institute uses them as a guideline when it evaluates projects. The guidance then supplies the useful part of the reasoning: whether a demonstration counts at a particular level depends on the technology being tested, the system it forms part of, and the objectives of that demonstration. Two competent assessors can examine identical evidence, place it at different levels, and both placements can be defensible.
That is a characteristic of any tool which evaluates a subject whose limit its users define. The consequence is a sequence. Before a tool is selected, the scope of the item being assessed must be defined and a label assigned to it. Where does the platform stop and the surrounding estate begin? Which version of the configuration is in scope? Which site, which shift pattern, which regulator? A readiness check with no stated limit is not verifiable, and an unverified check has no weight for the individual who signs the approval.
Four tools are compared based on what they assess and what is used as evidence
Each of these covers a different noun, has its own evidence standard and expires at its own time.
- Technology readiness levels. Grade the maturity of a technology from first principles observed through to a system qualified in operational service, across the nine levels published by the Aerospace Technology Institute. The evidence is the object and its test log. This truth lapses when the configuration or the operating environment changes.
- Project team readiness questioning. Grades the staffing position against work which has already been defined. ITtoolkit's twelve questions cover resource levels, technical, management and administrative skills, single-person dependencies, role clarity, schedule realism and the manager's authority to assign people. The evidence is the schedule and the resource plan. The right expires at the first resignation or reassignment.
- Operational readiness assessment. Grades the receiving operation. The guide at project-management.com says the test relies on staff, processes and technology to check if all parts are ready and working as expected before operations begin. The evidence is test, training and validation records. This declaration is used at go-live.
- Change readiness for a methodology grades the organisation and its individuals. The model Errida and Lotfi applied weighs organisational readiness, individual readiness, project management maturity and change management maturity, gathering evidence through interviews and focus groups with project managers, site managers and support staff. The evidence is testimony from the people who run the work. This premise fails when the processes, the staff or the sponsorship change.
The four levels together assess a tool, a team, an operation and an organisation. The distribution programme needed the third and bought the first.
Evidence differs across the tools
Two of the tools above will accept a well-composed pack as proof. A third requires live output from a working environment. ITtoolkit makes the distinction explicit by requiring two assumptions to be cleared before team readiness can be judged at all: that the project has been defined well enough for organisational capability to be evaluated against scope and work effort, and that the work has been broken into components against which assignments and scheduling commitments can be checked. Where either assumption fails, the twelve questions produce confident answers to no actual data.
The guide at project-management.com makes a related point from the other end of the life cycle, placing operational readiness late in delivery while insisting that its foundations were laid much earlier. Programme packs most often fail because of that timing. The readiness verdict has the day of issue, and the work it details continues to change afterwards.
The vendor argument about self-assessment then earns its keep. iMocha's write-up on project readiness assessments says that assessments conducted within an organisation are exposed to internal politics, organisational perception and assessor bias, and that hands-on skill is not evaluable from knowledge questions. The firm places candidates in a simulated working environment and scores their output automatically. iMocha owns the commercial conclusion, but the diagnosis applies to tools far cheaper than the one being sold.
The tools in the hands of the assessed group
The opening definition identifies tools, information and support, and those three are the part of readiness which most often goes unassessed. A project manager's technical fluency covers the platforms that support the workflow and the frameworks that guide planning, execution and delivery, and icagile's six technical skills list identifies Jira, Asana, Trello and Microsoft Project among the tools, with delivery frameworks and methodologies alongside them. The same expectation now applies to the people the work lands on, which is why a readiness question about tooling is a question about the shift supervisor as much as about the programme office.
Provek, which trains project managers in the United Kingdom, sets out a formal pathway through the Association for Project Management qualifications and reports that an additional 25 million project professionals will be needed worldwide by 2030. The demand figure matters less than the shape of that pathway, which goes through knowledge, then applied competence, then experience. Readiness examines which of the three a particular worker possesses on the day in question, and no course certificate closes that gap on its own.
Analyse a readiness proposal against the choice
The test of any of the four tools is whether its decision survives long enough to be useful. Compare the tool's expiry with the day listed in the first section. A technology readiness level that lapses on a configuration change helps little when the configuration is due to change before the decision meeting. An assessment of team readiness that fails at the first resignation provides little help when the project lasts for two years on contractors. An operational readiness assessment consumed at go-live is worth a great deal when go-live is the decision, and has no value when the decision is a funding gate nine months earlier.
There is a second test, and it concerns the edge. Whoever signs the approval should be able to read the request and answer three questions: The assessment subject, the conditions, and the day of the test. A premise unable to answer all three is a premise about some other object, or about an object with no limit at all. That is the whole comparison in miniature. Tools differ in the noun they grade, the evidence they accept and the time their verdict decays, and the choice before the board fixes which of those differences matters.
Sources
- Technology Readiness Levels (TRL)
- Measuring Change Readiness for Implementing a Project Management Methodology: an Action Research Study
- Project Readiness Assessments - A Must-Have On Your Readiness Checklist
- Operational Readiness in Project Management: An Ultimate Guide
- How to Evaluate Project Team Readiness
- 6 Technical Skills for Project Managers & How to Develop Them
- Planning a Career in Project Management in the UK
