A qualification programme is sometimes commissioned as if its purpose were to confirm a choice that the organisation has already made. The candidate technology has a sponsor, the project has a timetable and the commercial case assumes the equipment will be available. The test programme then appears as the last box before approval. That framing makes an unexpected result harder to use, even when learning about such a result was one of the strongest reasons to undertake the investigation.
I want qualification to earn a recommendation, not decorate one. That requires stating the question before the reassuring traces arrive. What interaction needs examination? Which conditions are represented? What would an unexplained discrepancy change? These questions do not imply a lack of confidence in the supplier or the engineering team. They explain what the business is paying the programme to discover and how its findings will affect the next commitment.
The distinction matters particularly for equipment that interacts with a wider system. A power-conversion device can have a well-described standalone capability while its behaviour in a proposed configuration still requires examination. A model helps represent that configuration, and hardware testing supplies another kind of evidence. Agreement between them is useful. Disagreement is also useful if the programme has the time, authority and funding to investigate it rather than merely record an exception.
A selected test set is not a success probability
In one inverter investigation, our engineers defined eight scenarios for a particular project question. Seven met the stated response criteria. The eighth contained a discrepancy between the expected and measured settling behaviour. It would have been easy to describe the programme as mostly successful and move on. It would also have been wrong to turn seven out of eight into a numerical probability of satisfactory operation. We had not sampled the full range of future operating conditions in a way that supported that interpretation.
The unresolved scenario mattered because of the question it exposed, not because it lowered a score. We needed to understand whether the difference arose from the representation of the network, the controller behaviour, the settings or another part of the test arrangement. The investigation could not be replaced by averaging the discrepancy with the satisfactory cases. Nor did the discrepancy prove that the candidate technology should be rejected in every application.
That distinction allowed a more useful management choice. We could retain the candidate and fund a narrower investigation while withholding a wider recommendation. The project sponsor did not get the original approval date, but the engineering team did not have to defend an unnecessarily absolute rejection. The decision preserved the option to continue on better evidence. It also preserved operations' right to understand the issue before it was transferred to a site.
I find that directors can engage with this reasoning when the recommendation names the unresolved question clearly. A collection of technical traces may be necessary for specialists, but the board needs to understand why the discrepancy changes the commitment. The explanation should connect the test condition with the service or risk being examined. It should not depend on the reassuring proportion of charts that look as expected.
Budget for the explanation as well as the observation
Our initial programme cost €1.3 million and ran for twelve weeks. The additional investigation required €460,000 and six weeks. Those figures were not simply the cost of repeating a test. They covered work on the model, the settings analysis and repetition of the affected scenarios after the team had addressed the mismatch. The extra time created a real project consequence, and I had to explain why it was justified.
The original plan had not made that learning allowance visible enough. Because the programme was described as confirmation, the request for more work could appear to be a departure from its purpose. I would now ask for an explicit account of how disagreement will be handled before the first test begins. That does not mean approving an unlimited contingency. It means identifying who can recommend further investigation, what question the additional work must answer and when the sponsor will reconsider continuation.
The same discipline applies to the people doing the work. Engineers should not feel that reporting an unexplained result automatically damages their programme. They also should not assume that every uncertainty justifies further expenditure. The quality of the recommendation lies in connecting the proposed investigation to a material decision. I expect the team to explain what could change if the question is resolved and what the business would do if it remains open.
This is a leadership responsibility because the incentives around a project can otherwise favour premature closure. Development wants to maintain momentum, commercial colleagues want a usable date and suppliers want a decision. None of those interests is unreasonable. My task is to put the unresolved engineering question into that conversation with a defined consequence, rather than expect technical caution to prevail simply because it is described as caution.
Write the recommendation at the scale of the evidence
By the later review, the team had resolved a modelling mismatch and repeated the original eight scenarios against the agreed criteria. That supported the next project-specific study stage. It did not provide connection approval, establish compliance across all requirements or demonstrate suitability throughout our portfolio. Those boundaries were not an afterthought. They determined what the completed programme could reasonably recommend.
A successful investigation can be overextended just as easily as an unresolved one can be dismissed. Once the difficult question has been answered, the organisation may want to use the result in every related proposal. I ask which parts of the configuration and operating conditions remain comparable before accepting that transfer. A similar product name is not sufficient evidence that the system interaction is the same. The next application may require less work, but it still requires an explanation of why the existing evidence is relevant.
I also want the programme's account to retain the route by which the conclusion was reached. The discrepancy, the revised model and the repeated scenarios explain the confidence we now have. Removing them to produce a smoother success story would make the record less useful for future engineers and directors. The fact that the programme changed course is part of its value, because it shows what the investigation actually taught us.
My standard is therefore neither permanent scepticism nor automatic confidence after a pass. I want a recommendation whose scope can be understood and whose unresolved questions remain visible. Qualification works when the organisation is prepared to use disagreement as information, fund a proportionate response and stop the conclusion where the evidence stops. That approach can delay a particular approval while improving the basis on which the business makes the commitments that follow.