Search Site
01606 871332 | info@percipient.co.uk Search
31 July 2015

Validation and the Curse of Short Term Thinking

Validation and the Curse of Short Term Thinking

I’ve just come back from a fantastic two and a half week trip to Japan – nothing to do with work and all to do with my volunteer role in the Scout movement. I was honoured to lead a Unit of 36 young people to the World Scout Jamboree, where 35,000 Scouts from all over the world came together to learn from one another and focus on what we have in common rather than what is different.

It was also a chance to spend some time with a Japanese family and spend time getting under the skin of Japanese culture – much more than I’ve been able to do on previous business trips.

There’s certainly a lot to admire about Japanese culture. While I was sitting on the Jamboree site in Yamaguchi Prefecture (see picture) and in Yoyogi Park in Tokyo, reviewing the draft of the second edition of the GAMP IT Infrastructure Compliance and Control Good Practice Guide (I guess that it wasn’t all ‘holiday’), I got to thinking about the short termism that most of our industry exhibits, how that runs contrary to much of Japanese culture and how much of a problem it is for those of us involved in validation and compliance.

I work on so many projects where cost and time are the only things that can effectively be measured and where project teams are focused solely on the ‘go-live’ date, with little real thought as to how a computerised system will be operated, how cost effective it will be to use and whether the ‘validation’ that has been delivered is sustainable in any real sense.

While it is right and proper to think of validation as proving that a system is fit for purpose, because we struggle to make ‘operational’ requirements specific, measurable, achievable, realistic and timely (SMART), we often focus requirements solely on business processes and system functionality i.e. what the system does rather than how it will be used, maintained and supported.

The result is often that a system can be successfully validated against stated requirements, but still be costly and time consuming to operate, deliver limited business benefit and fail to achieve the desired return on investment.

That’s understandable given that Project Managers tend to focus on what can most easily be measured (time and budget) and project teams focus on meeting requirements that have been stated, often purely in functional terms. This is often a result of validating systems purely because of regulatory requirements and not because ‘right first time’ really does costs less in the long term.

However, to deliver real benefit a system must provide a real return on investment, must be easy to maintain in a cost effective manner and must continue to meet the changing needs of the business as business strategy and objectives change, regulations are updated and technology moves on.
This long term view often often fails to be considered because the project spend is on someone’s capital budget (capex) and the operational spend is on someone else’s operational budget (opex). A failure to recognise this (often driven by financial constraints on capex and rules on Return on Investment which consider artificially short timescales) often means that project teams deliver validated systems that are not really ‘fit for purpose’ as far as the business is concerned.

So what can we as validation and compliance practitioners do about it? Since our discipline often crosses the line between the project and operational phases of the system, perhaps when reviewing requirements we need to ask questions about more that the stated business/functional requirements. Perhaps we need to use our experience of supporting (and often trouble shooting) systems in the operation phase to ask sensible questions about operational and support requirements, ensure that these are captured and then verified as part of the validation process.

Experience is that this is not always easy to do e.g. to argue with a project team for a more complex requirements traceability, because we know it will better support the change control and configuration management processes in the operational phase of the system life cycle.

I have however worked with some clients long enough to see the ‘Eureka!’ moment when people understand why I’ve been pushing these things. This is usually when members of the project team also become responsible for supporting the same system and they then understand that what I’ve been pushing for wasn’t just more complex project phases processes, but for the establishment of processes and records that truly reduce the cost of system ownership in the operational phase (not just during the 12 – 24 months during which ROI is often calculated, but through the entire operational life of the system).

Having seen some of the benefits of longer term thinking and planning in Japanese society I’m certainly going to continue asking the right questions and making sensible suggestions in the project phase. I may not always win the argument, but understanding the curse of short term thinking means that at least I know I’m doing my job to the best of my ability by making the right input, rather than waiting until short term thinking jeopardises the real success of yet another system.

Back to Blog

Keep up to date