**7. Governance and oversight**

The IBM proposal [28] included four solution components: SAP ECC5, Recruit ASP, Workbrain and SABA. From the witness statements it is apparent that contention arose as to the transparency and appropriateness of the selection process for these products. For example, Mr. Waite, the head of the government agency tasked with implementing these solutions, stated that 'to the best of my recollection, no choice about Workbrain had been made by the State before the November 2005 contract' [28]. In the memorandum [29] dated 28th May 2007, it was noted that Workbrain was going to be implemented in 2008 as the replacement rostering solution. It is therefore clear that the intended use of Workbrain predates the IBM proposal and ultimate

The choice of solutions architecture for the Queensland Health Payroll project does not appear to have been determined with consideration of the business or technical needs of the Department. According KPMG [30], 'as of 2005, the Whole-of-Government system for payroll had been identified as SAP ECC5 and Workbrain. As a result, it was decided that QH would replace the Lattice/ESP system with SAP ECC5/Workbrain as part of the Whole-of-Government Shared Services Initiative' [40]. Other eyewitness accounts placed the decision to adopt a combination of SAP ECC5 and Workbrain at a much later date (during the 2007 proposals and presentations). 'The presentation provided by IBM indicated that the Workbrain system would become the award interpreter (in lieu of SAP) …. the presentation was potentially a game changer' [39]. The issue of product selection would become an issue as the project progressed. Integration between SAP and Workbrain became a significant constraint on the project [38]. As these two accounts indicate, even on what should have been a clear and uncontroversial issue; who made the choice of products and when that decision was made is open to many interpretations. One that does not seem to have been resolved by the end of the

Towards the end of 2008 the 'IBM team, working in collaboration with the CorpTech Enterprise Architect, obtained and reviewed the documentation for relevance to clarifying the business drivers underpinning the SSI' [39]. This document, created several years after the commencement of the project, appears to be the first and only document to address the business drivers

At the point of issuing the invitation to offer, having already been to market with a request for information and a request for proposal, the Queensland Health/CorpTech team did not have an 'Initial Statement of Work'. The Government sought [28, 30], and the vendors responded with, fixed price commitments to a project that was devoid of even the most basic of project components—a statement of requirements! In essence, IBM had agreed to undertake a project, at a fixed price, for which no statement of work existed and no detailed planning of any

While no explicit business case appears to exist for the project, and none could be sourced either from the Witness Statements or via Freedom of Information requests, various memoranda [31–35] collectively cite various justifications that could be retrospectively viewed as business case-like rationales, such as the risks facing the existing LATTICE system, and the need to replace it [28]. In May of 2007, the Manager of HR Operations wrote to the Executive Director of Queensland Health Shared Services [29] to outline these risks and make recommendation

contract in December 2007.

34 Dark Sides of Organizational Behavior and Leadership

Commission of Inquiry.

and explicit requirements of the project.

description had been undertaken.

Why did senior management of the Department appear to simply ignore the findings of the report(s) that they had commissioned? Did they not believe the findings? Did senior management trust the promises of the vendor to produce an outcome despite what they were being told by the external review? It is not immediately obvious why this situation was allowed to unfold in the manner in which it did. The project appeared to comply with all the appropriate governance structures and reporting requirements, yet an historical or retrospective view would allow that the project was never managed effectively. Indeed, the findings of the Commission of Inquiry [28] state that 'Its (Queensland Health payroll) failure, attended by enormous cost, damage to government and impact on workforce, may be the most spectacular example of all the unsuccessful attempts to impose a uniform solution on a highly complicated and individualised agency'. The Commissions conclusion was that there were two primary causes for the failure of the payroll project (1) 'unwarranted urgency' and (2) a 'lack of diligence on behalf of State officials' [28]. The Commissions report elaborated further on lack of diligence, describing it as 'poor decisions made in scoping the Interim Solution, in their Governance of the project, and in failing to hold IBM to account' [28]. The Commissioner further reported that 'the problems are systemic to government and to the natural commercial self-interest of vendors' [28] which supports the observation that Normalisation of Deviance was at play throughout the conduct of this project. However, these findings by the Commission do not explain what motivated senior management to ignore the lessons learned from immediately preceding projects, to ignore the warnings and advice of their own personnel. It is unclear, from the Commissions report, what specific steps a subsequent project might implement to ensure that they too did not all into these traps.

is that senior executives of the Department, the Governance and steering committees, the Executive Director did not know what specific actions were available to them, or what they specifically needed to do in order to be effective. The Management and oversight of this project were at a complete loss as to how to effectively manage an information technology project. To examine the case study from the perspective of a timeline of events, of data and the advice that was available at the time to the participants, the researcher has reconstructed the project from the information sourced by FoI. This method of investigation is referred to as being 'inside the tunnel'; 'this is the point of view of people in the unfolding situation. To them, the outcome was not known (or they would have done something else). They contributed to the direction of the sequence of events on the basis of what they saw on the inside of the unfolding situation. To understand human error, you need to attain this perspective' [41]. In examining this case, and in identifying the contributory factors to project failure the researcher has set aside any preconceived notions or ideas as to why the project failed. The contributory factors explained in greater detail below are drawn from the perspective of what was occurring in the project at the time. What did the management of the project know, and why they were motivated to pursue the decisions that ultimately led this project to a disastrous outcome.

Situational Incompetence: An Investigation into the Causes of Failure of a Large-Scale IT Project

http://dx.doi.org/10.5772/intechopen.76791

37

'Organisational artefacts such as mission statements, goals and objectives, strategic plans and the like function as tools to reduce choice, not to guide it' [42]. In the same manner, the specification of requirements, the business case, the architecture and solution design of the project are all intended to constrain choice to deliver 'order'. In the QH project 'order' should have been represented by a defined scope of work, a defined project plan which sets out not only what work will be done, but also what work will not be done, and by an agreed contract. None of these things existed on the QH payroll project, and any efforts to enforce them were resisted by the vendor with the support (tacit or otherwise) of Departmental executives.

The issue of transparent flows of information between parties, of experts being able to make informed decisions utilising tacit information compared to less experienced people needing to 'follow the script' [43], of actors controlling the release of information, and of stakeholders presenting different versions of themselves across multiple stages becomes critical when one considers both the makeup of the governance and management of the QH project and the individuals involved. 'The involvement of non-IT stakeholders can actually work detrimentally and confound and confuse proceedings, even causing error' [15]. Non-IT experienced management, placed in a position of authority 'may be influenced by some suppliers or colleagues to whose IT knowledge they had access, and insist on a certain course of action' [15] which may result in confusion, delay or inappropriate decision-making, and contribute to the risk of IT project failure. An appropriate lens through which to view this performance construct is referred to as the Dunning-Kruger Effect [44]. This effect is where the less competent an individual is with respect to a particular domain then the more they are likely to overstate their perceived knowledge and ability. This may be referred to as a 'confidence/competence dissonance'. Individuals that lack competence in a particular domain (incompetent) but are not self-aware

**9. Project executives lacked domain expertise**

## **8. The big question … WHY?**

These are the clear and obvious failures of the project: project management failed, there was a lack of requirements definition, management was in conflict. All of the issues which appear in the literature on failed projects—nothing new or unexpected!

Of potential significance is that the evidence provided by witness statements mapped to the project chronology showed that issues related to the identified themes were raised by staff and consultants throughout the project phases, and yet they still they remained as issues that were not resolved nor remediated at the time they were raised. The evidence is that management was made aware of these failures. So it was not a lack of awareness of the failure risks, and therefore highlighting these as the contributory factors of project failure lacks explanatory completeness.

As was evident from the analysis of the witness statements - management was regularly informed of what was going on with their project by both staff and external consultants [37]. Management knew that the project was facing problems (or at least should have known). The reports on the 2005 Whole-of-Government initiative [38], the KPMG Report [30], the KJ Ross report on testing [39], the IBM and CorpTech report to 'reconstruct' the business requirements [31] and the 2009 Queensland Audit Office report [40] all provided clear statements identifying where the project was failing and what needed to be done to remedy the situation. Yet the problems persisted until the total project costs had blown out to beyond A\$1 billion. Faced with the clear and certain statement that the project was performing badly, and with specific statements of where the project was failing, successive managements failed to act appropriately to stem the problems. The only conclusion that can be drawn from this failure to act is that senior executives of the Department, the Governance and steering committees, the Executive Director did not know what specific actions were available to them, or what they specifically needed to do in order to be effective. The Management and oversight of this project were at a complete loss as to how to effectively manage an information technology project.

To examine the case study from the perspective of a timeline of events, of data and the advice that was available at the time to the participants, the researcher has reconstructed the project from the information sourced by FoI. This method of investigation is referred to as being 'inside the tunnel'; 'this is the point of view of people in the unfolding situation. To them, the outcome was not known (or they would have done something else). They contributed to the direction of the sequence of events on the basis of what they saw on the inside of the unfolding situation. To understand human error, you need to attain this perspective' [41]. In examining this case, and in identifying the contributory factors to project failure the researcher has set aside any preconceived notions or ideas as to why the project failed. The contributory factors explained in greater detail below are drawn from the perspective of what was occurring in the project at the time. What did the management of the project know, and why they were motivated to pursue the decisions that ultimately led this project to a disastrous outcome.
