IT risk – Vireloup Pty Ltd

June 25, 2014April 16, 2016

What they don’t know

Have you ever been to a dinner and known that one of the guests is about to get a surprise? The tingling excitement seeing their normal carry on persona until “it” happens and everyone shrieks in laughter. Well I sometimes feel IT / Business meetings are a bit like that – each side sharing what they think is important and when problems happen they ask “how could they have not known about that?”

The big IT decisions are taken in leadership governance forums, structured to get the right level of input about the opportunities and threats from the business, and likewise from technology. The trouble is that they don’t know everything that we know (on either side of the table). In fact often we don’t think they have sufficient understanding of the realities of the world we live in (again common to both sides).

People have to take decisions based on their understanding of the relevance and quality of the information in front of them. And if you want to get good outcomes, you have to take good decisions. So how do you develop effective governance in the organization. I have a few tips:

The business side needs to see technology literacy as a core development requirement of its leaders. This is not about giving them an i-pad, but teaching them about the value of frameworks, the role of enterprise architecture and service models. Formal courses are required here and an increased technology focus in MBA courses would be a good start.
There just has to be less optimism around IT solutions and more realism. Yes they are the free lunch that accounting firms drool over (while the IT folk work through lunch); but miracles don’t happen, they are dragged out by strong leadership teams steering a steady course and holding to realistic business outcomes – just like the team did with the Collins Class improvements.
The people mix has to be right. You need governance teams with perceptive insight. These may not be the operationally focussed IT staff who have been promoted for brilliantly resolving the ceaseless IT outages. More likely it is the analysts or architects who will develop to GOVN7 competencies.
The information that is shared has to be just right! The governance meetings may take up only a few percentage of the working week. What information to share and what to leave under the covers becomes very important. For project governance, this is reasonably well understood. As you move to programme, portfolio and business process governance, it comes down to having the right leaders with the perceptive insights of what is really important.

I have been a member of a State Government programme board for one of the largest IT projects in the country. We used to receive 300 page board packs, supplemented with consultants’ reports that ran to 100 pages each. Fortunately we had perspicacious board members who knew where the really important information was – and it was very rarely in the executive summary!

So how do you think we can improve knowledge on both sides of the table?

March 26, 2014April 16, 2016

Gregory House for CIO?

Being in a household full of teenage kids, it is hard to find TV programs that everyone wants to watch. One series that we all agree is intriguing and entertaining is House – the story of a brilliant doctor saving his patient’s lives through his intellect. Along the way he struggles with drug addiction, dysfunctional personal relationships and, most intriguingly, managing a high performing team.

I see all sorts of similarities between this evidently contrived medical environment and my experiences as CIO trying to get the best out of my team for their own sakes and to deliver to the organization.

So how does Dr House stack up against my principles of what makes a good leader and especially a good CIO?

Integrity. For me this trait stands above all others in importance (as it does for any executive). On the face of it, House lacks integrity – he lies consistently, is always taking money off Wilson and almost always avoids answering questions. Behind this somewhat dispiriting façade, you know that House holds certain values with incredibly high integrity. He puts his patients first in front of his career or image. He is open and honest about the life that he leads, even if it doesn’t fit society’s norms; and he bases his decisions on fact and not prejudice.
Strategic thinking – CIOs need strategic bones in their bodies (see The Reluctant CIO!) and this takes a certain thought process. They have to be comfortable “in the fug”, not having the full picture but still being confident enough to move in one direction. This is House’s life: a patient presents with lots of data, but insufficient information to diagnose. He has to weigh up the risks of each test or treatment against the risk of inaction (usually the patient will die). He never just sits and holds his head; he always picks a path and follows it.
Domain expertise – This is a tricky area for CIOs; they need domain expertise but it needs to be in the right area. They should not be experts in configuring routers or writing code. They do need to be great at managing risk, optimizing architecture, process management and governance functions. House is the ultimate domain expert in managing risk. He doesn’t know the diagnosis any more than his team (until the last 5 minutes), but he can weigh up the risks of various options and tells the team to “Go!”
Communications – A core requirement of a CIO is to communicate the opportunities, challenges, risks and achievements of information technology. In this area you would have to say that House fails dismally, at least at face value. He interacts rudely with his patients (he would rather not talk to them) and prefers to hang out in the morgue or with coma guy. To counteract this perspective, we know that House is the best asset of the hospital, so somehow the word has got out. Maybe he really does know how to communicate – just in unconventional ways.
Relationship building – I have always thought that the relationship web that a CIO weaves is his or her biggest asset. The CIO must work up, down and across developing trust and enthusiasm. House has a strange set of relationships with Cuddy (up), his team (down) and Wilson (across). The recurring challenge with his team is to let them make their own decisions (and mistakes) but not let them kill the patient (which sometimes happens). This is like any CIO challenge – let the Operations Manager manage operations, but know when you have to step in to save a disaster.

So how would you like to be in Houses’ team? A mixed blessing I think!

March 19, 2013April 16, 2016

How do CIOs befriend the miners?

I have worked as a CIO in a number of industries and each has their peculiarities. One segment where the CIO has to be particularly nimble is in the mining sector. There are a few top tips that I have learned from working for a contract miner, producing ore from working mines.

I’ll try to frame up the key requirements in this industry

1. The mining industry is cyclical and when it is hot, it is hot. They need solutions quickly and run high profit margins in the good times. As the cycle turns there is a focus on cost control. In many cases IT is delivering projects late in the cycle and appears out of step with reality.

2. The equipment used in the mines has become technologically complex. There are management systems on the trucks, the crushers have IT components and there are a myriad of complex systems such as slope stability monitoring. The vast majority of this equipment is purchased without IT involvement, but these days most of the systems connect to the internet via the corporate LAN.

3. Many in the mining workforce are engineers or technicians and technologically literate. They often source their own technology solutions and have the skills to make them effective in the workplace. Examples are collaboration systems and mobile enabled ordering systems. These are nearly always disconnected from the corporate IT systems.

As CIO, I was keen to get onto the front foot with these issues. I wanted to understand why the IT department could not deliver the solutions as quickly and cheaply as business units buying it themselves. I succeeded in providing solutions quickly, cheaply and properly supported (my perspective), but I don’t think I won the business over for the following reasons:

1. Acceptance of risk. The business had a higher tolerance of risk than that practiced in IT. When the business implemented their own technology there was no business continuity planning, security was dealt with in a superficial manner and there was often a complete loss of capability when a key staff member left (key man risk). The truth was that these systems would fail, but as different systems were used on different sites the impact would not be catastrophic.

2. Opaque costing. The actual costs of these systems were not well understood. There was no aggregated cost (as you would find in an IT budget) and the costs were often wrapped into other high value contracts. The costs benefits were calculated simplistically by referring to the punitive expenses of having plant not working.

3. Inconsistent expectations. Business provided solutions would fail and they often had poor maintenance arrangements. The business was surprisingly accepting of these issues (given the costs of down time) and much more accepting than for corporate provided IT systems. I put the inconsistency down to the extra control that the business had over the issue. They would deal directly with the supplier and often leverage a relationship to accelerate resolution.

So here are my 3 top tips for success (or at least avoiding disaster)

1. Know when to get out of the way – you may not have the capability or resources to deliver. Ensure that you engage the key stakeholders in this decision.

2. Map the risk – ensure that you have a holistic view of technology risk, not just IT risk. The Audit and Risk committee should be thankful for such a perspective.

3. Be excellent at project management – if you are providing solutions apply a professional, agile project management technique. Good people, a strong methodology and business involvement is a recipe for success.

What are your experiences with IT and the mining industry?