“The proof is in the pudding”, I had half expected my customer to recite these words to me in response to the discussion I had just had with the project steering group.
Always wonderful to hear the old adage being uttered again (though it is a corruption of the old saying “the proof of the pudding is in the eating”). Basically the saying refers to the viability (or quality in many cases) of something whose outcome is uncertain until it has been directly tested.
In this case, just had endorsement of my decision to proceed with the proof of concept (POC) in the first place.
For those of you new to the term, a POC tests key elements of a solution in a simulated environment that mirrors a proposed operational environment.
The problem faced for the project was that certain assumptions had been made at the outset of the project (and formed a key factor in the business case). Specifically that software identified as a critical component of the final solution was fit for purpose. Obviously the third party vendor sales team promoting this ludicrously expensive pre-built Commercial-Off-The-Shelf (COTS) software claimed that it met all the customers’ requirements. This was substantiated by experts within my organisation, albeit with a few minor concerns.
Alas as the project unfolded, the planned investigation activities (via a POC) steered the technical and business Subject Matter Experts (SMEs) to conclude that this was not the case. The unique mix of software, hardware and other infrastructure resulted in issues that the various SMEs could not overcome during the time-constrained analysis of the POC.
Unfortunately in the world of project management these things happen! That is why we have risk management.
The risk had been identified and mitigation plans formulated and evaluated ahead of time.
The POC had served the project well. It had been used to test key elements of the solution to validate that the requirements are met by the new solution. In this case, the findings of the POC could not support the continued use of the software (without resolution of the issues raised).
Although this had previously been identified as a risk (as there was uncertainty to the outcome, albeit the likelihood was low, the potential impact has high). This risk had now been realised, it now had the potential to become an issue. Something needed to be done to keep the project on track.
The purpose of risk management in a nutshell, is to either 1) prevent the realisation of a risk, or 2) minimise/neutralise/manage the impact of a risk once it has been realised.
In this case, the risk had been identified and activities had been performed to prevent the realisation of the risk. The investigation activities in the POC were a way of averting this risk.
As these activities were conducted early on in the project life-cycle it meant that we had early realisation of the risk and there was ample opportunity to find a resolution.
Had these investigations by the SMEs been left to later in the project life-cycle (as many project managers would done) or assumptions made that the software would work, then the severity of the realised risk would have been more impactful. The resulting issue certainly would not have left enough “room to manoeuvre” and may have brought the project to a halt.
There are times you very reassured at the decisions you make. In this case, by not succumbing to the coercion of experts into skipping an activity you deem beneficial.
Have you witnessed similar experiences where the project manager has been strong-armed into skipping valid activities?