Why Public IT projects Fail – Continued

Yesterday I commented on the status for the Property Registration System and mentioned, that another major IT failure seemed to have been hiding from the public eye – namely the wreckage of the Danish Emergency Management System. Normally I don't claim to possess a crystal ball, but today the news hit the World: Under the heading: ' The Prime Minister knew that the Emergency Management System was high risc', a paper from the Ministry of Finance dated May 16 2007 documented that the Minister of Finance, the current Prime Minister knew that the Emergency Management Project, a Dkr. 2 B + project, was evaluated at high risk, 4 out of a scale 1 to 5.

This document was originally confidential, confidentiality raised in August 2007, when the contract with the consortium led by Motorola was signed. But the contract – although a major investment – did not cover the 'control room SW', which was out for tender and not signed before 2008.

This contract was won by Terma, a Danish company until then only known for it's supply of high tech military systems, radar controlled defense systems and firearms control systems for helicopters, fighters and ships. The contract value was at the time estimated to be a mere 200 – 250 mio Dkr. For the Control Room SW including 4 years of operation, as opposed to a total budget for the entire emergency management system at 2.718 Mio Dkr.

At the time of the evaluation, the Ministry of Finance could not include Terma and the contracted solution (that also included Intergraph and a couple of smaller, Danish companies) in the risk evaluation. So the reason a '4' was the result, was a combination of 4 for organizational complexity, 4 for technical solutions, 3 for vendor risk and 5 for complexity of stakeholder interest.

As a contingency plan to reduce/meet the risk, 193 Mio was set aside as a buffer, and the conclusion was, that if any of risks materialized, the consequences were thought only to impact the project plan and the budget.

At this point in time it is clear beyond any doubt, that although the control room SW contract only covered a mere 10% of the total project cost, this part of the project has failed completely, Terma's Staff for has been fired, and the department Public Safety, created for the occasion, has been dismantled. The Government Attorney is currently handling the case.

But as I mentioned in a blog, the Government Attorney is no programmer, and this will not create anything but a financial resolution of the conflict between Terma and the Government.

The secretariat set up to handle the emergency system – SINE – has been radio dead around this.

See their homepage at http://www.sikkerhedsnet.dk/om+sine.

So how can we determine what went wrong? If you look at the SINE homepage you will find a link to European Tetra-net projects that more or less all seem to have succeeded. What went wrong in Denmark? What is different and why couldn't we just adopt this seemingly uninteresting piece of technology and enable the fire brigade to talk to the police and the rescuing service to the civil defense units? There are several answers to this question:

1. Underestimation of the importance of the 'control room SW'.

2. A very complicated and partly conflicting group of stakeholders

3. A lack of a systemic overview of both tenders before call for tender

4. An steering committee consisting of gatekeepers instead of decision makers

5. Lack of understanding of the competence level of the winning company (Terma)

6. Lack of understanding of technological improvements in the emergency mgmt arena

As is clear from the international references, the Tetra net is not a very complicated technology – it has a rather small bandwidth, but in case of emergency you could deal with only limited amount of data and voice interchange. Also Motorola is known to have skills and competence in this area, but the exchange between different organizations was explicitly placed in the second call – 'control room SW' – that also covered integration with GIS (Intergraph) as well as links to all the different organizations variety of communication media – plus an integration layer to back end systems like the Central Personal Registration system, interface to local office systems, hospital exchange, and interfaces to privately operated ambulance services and in some areas also fire brigades.

The complicated mixture of stakeholders were supposed to be coordinated by the Police, that although in practice more than 80% of all cases of (day-to-day) emergency management calls do not involve the police. And the police was in the middle of a major reorganisation, where this system was just another brick in the wall. The tender was headed by the Agency of Economy, part of the ministry of Finance, and the Emergency Management organization was merged with the Ministry of Defense a few years earlier and was probably looked upon as a sort of step child here. The complication also included the above mentioned private ambulances and fire brigades, covering about 50% or more of the local Government emergency services.

The lack of systemic overview before the 2 tenders calls for a reevaluation of how and why Gartner Group, hired as a consultant company to prepare the tender, could overlook the key role of 'Control Room SW' and underplay the importance of technical interoperability between the different stakeholders and not least the level and complexity of change management to ensure the take-up of the solution by all major players.

It seemed that the steering committee probably covered the right institutions: Ministry of Justice (which includes the Police) acting as chairman, Ministry of Finance, Ministry of Defense, Ministry of Welfare, Ministry of Science and Technology, Association of Municipalities and Danish Regions Association. Until proven wrong it is my hypothesis that the steering committee meetings concentrated more on status of progress, spending of money rather than risk management and change management like acceptance and enacting of the various groups 'in the fire' literally speaking. If stakeholder committees act as gatekeepers, it is at best an advisory committee, not a steering committee. In stead the head of this group should have been a dedicated 'CZAR' with sufficient decision power to change events – if possible by changing the contract.

Lack of understanding on the proper level of competencies and vendor capabilities. Terma had never before worked in the field of Public Safety; nor had they ever participated in major SW integration tasks with administrative stakeholders – their use of standard systems was and is 'Java'. When the contract negotiations squeezed Terma, they skipped partners that could have provided the skills and muscle, that Terma obviously did not possess when the signals of crisis were raised. And because of the nature of public tenders, they were allowed by a steering committee to continue for too long.

The lack of understanding of concurrent technological development was another reason, why the course was not changed; over the last few years the terminology 'Unified Communications' and 'Collaboration Services' has been greatly improved, mainly led by the defense forces, but using standard SW components and basing communication of the Internet. To day at least 2 vendors offer SW capability for multi-platform same-time support of communication systems supporting both Tetra Net (Motorola), standard mobile communication channels as well as highly sophisticated and encrypted VPN tools for same-time video conferencing, exchange and overlay of Geographic information. ( See CISCO Solution, IBM solution )But nobody was allocated to watch this field while the hand coding of Terma progressed. This could actually have saved the project – if attention to the acceptance of the solution by all stakeholders also had been in focus.

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

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

4. 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!)