“Put your appendage on the block” – or so some of the comments I received on my recent NPfIT posts have suggested – and say how the NHS should have managed the procurement of the National Project for IT. OK - so here goes......
Firstly, I need to put my approach into context – I come from a background of software application package development, roll-out and support – and from a market where multiple software houses compete against each other to supply their products and services. I do not come from a Central Government services background which, I believe, is focussed on big bespoke solutions for single departments with large end-user counts. I believe that the NHS fits better into the former market rather than the latter “big bespoke project” market.
Unfortunately, the current NPfIT has tried to treat the procurements as big bespoke projects (yes, those procurements are planned to use software products – but in a manner totally different to the normal way that software packages are developed and sold in a competitive environment).
One of the aims of NPfIT should have been to develop a competitive environment where software houses compete with each other the basis of price, quality and innovation – a self-managing environment where success is driven by meeting end-users needs accurately, introducing innovation, delivering quality products on time, and implementing projects to budget.
The Central Government services approach discourages suppliers to innovate, but encourages the identification of opportunities for changed requirements to justify price increases – effectively stifling innovation by both supplier and end user – and leading to drawn-out change control procedures, demands for increased funds and even more delay – let alone the deterioration in relationships between customers and suppliers.
No – the NHS should have adopted a totally different approach to procurement. On the back of realistic budgets and timescales for development, testing, implementation and roll-out, there should have been a central body responsible for the setting of common standards for security, data storage and interoperability between systems, and the coordination of the production of baseline statements of requirements for individual applications – to include the areas that must be capable of customisation, without programming changes – i.e. where additional charges are not due from multiple customers in the future.
The NHS should have procured/funded demonstrator projects from at least three separate suppliers in each application area. (I would also state that I think they should have given preference to smaller, more innovative suppliers - ideally with track records in both the UK NHS market and the development of package software– rather than bigger, more established software developers with little or no track record in the development of application packages for the health market). Where necessary, this should have extended to providing support to the best developers through consultancy or the promotion of partnerships with other suppliers. Above all else – although difficult in a Government environment – the selection of suppliers for the demonstrators should not be decided on price, but on quality and value, and on the likelihood of getting quality solutions that would meet end user requirements.
The suppliers of those demonstrator projects should have been encouraged, within reason, to respond to the changing requirements identified during the development (and subsequent) phases through the availability of limited contingency funding, available to all suppliers, that could be drawn down quickly without high levels of bureaucracy to cover significant changes to the requirements identified initially (although with some controls to avoid excessive requirements creep). To a certain extent, the projects would become self-managing – suppliers would recognise that the true value of each project would not be the profitability of the demonstrator, but the opportunity to build the best product that would be sold to multiple trusts later during the roll-out – and would look to self-fund some of the innovations to ensure that they maintained a competitive edge over the other suppliers.
With the NHS managing standards and interoperability centrally, final acceptance tests would include confirmation of adherence to those standards, through the use of published test plans. There would be the need to manage changes to those standards – and where necessary in the early stages, through the provision of limited funding to suppliers to make the necessary changes. (Although, hopefully, by the end of the demonstrator projects, further significant changes would not be necessary, and the detailed changes required on a year-by-year basis would be funded by the suppliers themselves and supplied to all customers under software maintenance agreements).
After completion of the demonstrator projects, the NHS would have a centralised library of baseline requirements for individual trusts to use in their own individual procurements of new systems. Each competitive procurement would be decided locally, based on the relevance (commercial and functional) of each supplier’s offering to each Trust/department – although the NHS would have to manage the adherence to standards through mandated phases of acceptance test – possibly once per supplier/release rather than per Trust/customer.
Major infrastructure projects could still be let centrally or regionally against the standards laid down centrally, allowing for subsequent individual trust/departmental procurements to bring in servers, specialist hardware, and possibly communications requirements.
This approach does at first sight to have many drawbacks – timetable (although I would argue that this approach would at least succeed in delivering a solution for the whole of the UK – and most probably in a shorter time than the current project – if were ever to succeed), and the perceived extra costs of multiple procurements (and here I would point out that this additional cost could be mitigated through good centralised support, and even then is most probably significantly less that the current cost of the existing projects’ management infrastructure).
Going forward though, the potential is dramatic. A strong UK software industry in the health market, possibly leading the world and opening up the export market for us, motivated by competition to embrace innovation and keep its products up-to-date both functionally and technically. And an NHS that has systems that meet the varying needs of its many users, who are able to have their systems customised easily to reflect local requirements and working practices.
Meanwhile, the NHS retains control and polices centrally adherence to standards in all the major areas, including security and interoperability. In the end, a true partnership – between local departments, trust managers and centralised NHS directors, working with the software industry, (rather than in a combative environment where each seeks to get the best financial deal out of the current procurement), to implement a set of systems that will yield real benefits for the NHS generally, and end users locally.
No comments:
Post a Comment