onsdag den 21. april 2010

Why do Public IT-Projects fail?

On May 21. the Danish Technology Council is inviting to a workshop under this heading. They have invited several specialists to present points-of-view on various aspects, and I am invited to comment on the need for standardization and architecture.

As this is central to the eGovernment course I am preparing for the Masters' education at the Danish IT University from this autumn, I welcome the initiative and the opportunity to discuss with some of the victims as well as meeting the people, that are classified either as 'rascals' or at least passive viewers to the mess, that admittedly seem to have happened a number of times.

This is not the first time the Danish Technology Council has focused on the topic; in 2002 a special group was created headed by Erik Bonnerup, a renowned public sector manager with a past track record of CEO also for KMD, the large Danish ICT-company focusing on municipal and regional computing.

The report from this group to a large extent has since been acknowledged as the best of it's kind, but unfortunately 8 years after the recommendations have not seen to have influenced the success rate much; The Govt. Audit Authority recently came to about the same conclusion as the Bonnerup committee, that hardly any public IT project meets it's objective nor sticks to the original project plan nor budget. The auditors point to the point that unforeseen complexities account for the majority of reasons for delays and budget overrun.

Having spent 39.5 years with one of the major suppliers of ICT technology to the Public sector, I recall numerous situations from way back – the Illness Insurance Project in 1972-73, the new Financial Management system for regional and local Govternment in late 70'is, the financial management system for all higher education centers and schools in the 80'is over the so-called Amanda project for the unemployment services in the 90'is, the Procurement Portal supposed to save billions for the public sector purchase agencies, to the original VIRK-project – a portal for all enterprises and their interface to the public - and to todays major flops – some well-known like the current problems with the digitization of the Property Registration System/cadastral System in Denmark – and some very well hidden but real disaster projects like the failure to deliver an emergency management system covering police, rescue services, hospitals, fire brigade and civil defense.

One thing they all seem to have in common is that all projects had a distinct borderline between the IT-project and the organizations, institutions, users and 'customers' = citizens/companies/other Govt. Institutions. Almost in all cases the vast majority of effort in the preparation phase has been allocated to a detailed specification of the functionality of the IT system, often to a degree where 80 % of very detailed requirements are specified as 'mandatory', and only in recent cases the requirements have also covered 'non functional' requirements – such as scalability, response time, security.

At the same time Denmark has been more and more focused on a very strict interpretation of the EU tendering regulations, and this leads to a situation, where innovation during project delivery is forbidden, where the public sector's project managers stick to the contract and not to possible changing realities, new technological development, even new happenings in the market place and environment.

Some of the recent thinking points to the lack of centrally defined mandatory strategic guidelines and a centrally defined IT Architecture for the public sector. The guidelines issued by the Ministry of Science and Technology were issued 3-4 years ago, but they are not mandatory, and to some of the municipal managers they may seem too academic and too far from day-to-day operational need.

Although I do agree that Enterprise Architecture definitely is part of the solution – in as much as the idea of EA is to couple management and ICT capacities according to the strategic business processes – I fear that a request for a centrally defined all-encompassing EA for the entire public sector will hamper innovation even more – and even stress some of the reasons for failure, that in my perspective are much more severe: ICT projects are defined too narrowly, too technically, and hardly never ever try to cover all the aspects of organization theory, social impact and the vast amount of knowledge that we have accumulated from non-IT studies on how technology are able to enable the performance of organizations – and recently even more the behavior of networked agencies and organizations, where the most ambitious ICT projects nowadays are being implemented. I will come back to how I view the possibilities of defining a Danish framework for EA in Government.

The Property registration System (link in Danish) is notorious in several ways: The government notary functions report to the institution called Domstolsstyrelsen, the agency that are controlling the administration and work of all courts in Denmark. The specific Land Registration Notaries are extremely sensitive for buyers and sellers of property, as registration is required to obtain financing, sell mortgages and start building or modifying on the properties sold. It started as a major analysis made by DeLoitte in 2005 with general use cases, project plans, overview of document types, a logical data model, benefits and costs – and a suggestion that the project could be finished end 2007.

To head the project a well known person with ICT background from the IT Task Force was selected – Adam Wolf. A very skilled person but none the less with an ICT background. The project was started based on DeLoittes recommendations.

After some delays the project was delivered by CSC in the autumn 2009. Immediately it created huge problems in the handling of the various document types already somewhere in the process, some of the delays noted were now several months – causing real financial problems for a lot of people. A request has recently be made that the private persons or small companies are reimbursed for their excess costs as a result of the delays. To this the CSC project manager in February responded, that 'The IT project was run according to plan – delivered at the approved time, and has been operating with an uptime of 99,8 since!'.

And today in Berlingske Tidende Adam Wolf states that 'The Property Registration System is an excellent solution that got an unfortunate start'. Adam W points to all the manual processes, that were 'extraordinary' including a 'backlog from the old system' stating that 'It was the (manual) case management system that didn't perform – not the IT system.'

In my opinion this simply underlines my argument that most of the problem is that the modernization project has ONLY been focused on the technical and technological aspects, including coding of the functionalities as stated by the changed legislation. What has NOT been considered has been the process to imbed the technology in the organization, including the handling of interfaces with the suppliers of data and information. Any sociologist will ask questions like how the acceptance, enablement and management of the change project was handled seen from the human and intra-organisational way. The political management behind the reform should have been advised that the change required more skills that ICT project management, and that human process knowledge and management are even more required in situations where processes are changed, where employees get unfamiliar tasks, when demands fluctuate and when traditional bureaucratic controls are used in stead of human motivation, establishment of social networks and encouragement of the new 'super users' as partners and mentors for those in need. This type of failures are common for all the projects, mentioned above – plus some specific blunders in each of them, of course.

So the future solutions are depending on:

1) Framework Enterprise Architecture and mandatory, selectede standards for API's

2) Less strict interpretation of EU tender rules with room for innovation and stepwise improvement of mutual understanding between stakeholders

  1. Review of change management team – including sociological and organisational projekt management emphasis

  2. General acceptance of performance measurement system including employee take-up of new IT projects

I will be back with more comments concerning the wrecked Emergency Management System – SINE – other points of learning can be obtained from this. ( And – as a sort of competition: May I ask by readers to try to google any relationship between Økonomistyrelsen, Terma, Sine and the Tetra Net. Somebody REALLY has a way of making clean ups!)

Ingen kommentarer: