The rate of ICT project failure around the world remains high so anything that tackles common problem areas such as an ill-conceived program (for example, one that is too big or overly complex and therefore more likely to fail) or scope creep (a project killer if not picked up and addressed at an early stage) should be encouraged.
By way of background, the government is seeking to strengthen the existing assurance regime by asking the Government Chief Information Officer (GCIO) to assume responsibility for: “giving Ministers system-wide assurance that ICT risks are being identified and well managed by agencies and across government as a whole, and that the benefits of ICT investments are being delivered.”
This mandate includes the formation of independent assurance panels as summarised by the Department of Internal Affairs in a recent update.
“The Government Chief Information Officer (GCIO), as the functional leader for Government ICT, is mandated to establish an independent panel of Independent Quality Assurance (IQA) and Technical Quality Assurance (TQA) providers. The objective of the GCIO Assurance Services Panel is to improve the quality, consistency and independence of Assurance Services. This will provide greater confidence to Ministers and the public that investments are well managed and will deliver the expected benefits.”
The rate of ICT project failure around the world remains high so anything that tackles common problem areas such as an ill-conceived program or scope creep should be encouraged
This is intended to form part of and compliment the government’s existing approach to assurance generally which includes processes such as Major Projects Monitoring and Gateway reviews.
The Cabinet paper on this subject (June 2013) was quick to point out that: “Improving system-wide ICT assurance is intended to provide stakeholders with confidence that ICT risks and processes within the State Services are identified and effectively managed. While no assurance model can guarantee there will never be security or privacy breaches or service delivery failures, it can ensure risks are identified and managed [my emphasis added].”
I agree with this sentiment. As we know, even the best laid plans can come unstuck at some point during the planning, procurement and delivery of ICT projects. These projects carry inherent risk and it is therefore impossible to “assure” them to the point that a success rate equal to 100 per cent can be guaranteed.
I nonetheless expect the government’s increased focus on assurance to result in material improvements provided of course that:
• the assurance work is properly performed; and
• any recommendations made are in fact adopted.
It would also be useful to get clarity around what “success” means on an ICT project in order that, over time, the government’s initiatives in the assurance area can be properly measured. For example does success mean on time, on budget with all the required features, functions and benefits (a high standard, particularly on larger, more complex programs) or something short of that?
What then are the likely challenges (or pitfalls to avoid) when it comes to implementing the government’s assurance model?
For present purposes I have selected the following: ensuring true independence; working with incomplete information; failure to follow recommendations from assurance reviewers; and risks associated with “smoking gun” documents.
Ensuring true independence
Ensuring true independence (of review teams) may be a challenge, particularly in a relatively small market like ours. In some situations there may be a case for involving reviewers from outside New Zealand in order to avoid any actual or perceived conflicts of interest.
Independence is fundamental to the effectiveness or otherwise of assurance work. Without independence, any assurance work is likely to be undermined or of limited value.
In this context, the “principles” published by the UK’s Major Projects Authority (set up in 2011 to undertake assurance work) provide useful guidance on what independence means:
“The Major Projects Authority works with HM Treasury and other government departments to provide independent assurance on major projects.
The ... Review team must be independent [my emphasis added] of the programme/project, its management and associated support activities and is responsible for the content of the final report.”
The objectives behind this principle are described as follows:
• “objective assessment of projects by teams with no association with [the] project or its line management
• avoids [leadership] influencing review outcomes and team conflicts of interest
• encourages open and candid reporting
• ownership of [the] report rests with [the Review Team] until [the] final version is delivered to [leadership].”
But what does this principle mean in practice?Read more: Future Focus: Getting IT project governance right
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.