Published on the 14/09/2012 | Written by iStart

With around half of all IT projects fail to deliver on expectations it’s safe to say that there’s something seriously wrong with the way IT projects are being both planned and executed. iStart cornered Simpl founder and CEO Bennett Medary to find out just what’s behind such a dire statistic…

iStart: What’s the difference between success and failure when it comes to IT projects?

Medary: First of all you need to look at success in terms of the business outcomes as opposed to the technical ones.

One of the biggest differences in IT governance and IT projects is around being very clear on what success looks like in business terms. You have to ask: what’s different about how the company will be doing business? What will be different about the results? What will be different about how people work? About how the business engages with its customers? You have to consistently drive the project at that business level and not allow it to become a technology project, unless it truly is technical.

In other words, you need to be very, very clear about what the project is trying to deliver. You can’t allow the project to run off into its own world and forget about its real mission and purpose. One of the big things that goes wrong with corporate and government projects is that once the business makes a commitment to go ahead with an IT project, they then go into procurement mode. Once they go into procurement mode the business takes a back seat and procurement takes over.

Procurement people have a very different specialisation, that’s not about using technology, it’s about buying ‘stuff’ well and contracting powerfully. It’s about risk management and best price and sometimes that culture then becomes enshrined in the contract and takes over how it is set up and run. The project then gets into a contract management/ contract fulfilment mode, rather than a success pursuit mode.

One of the biggest failings in IT projects is poor governance and that starts with the wrong people leading the project. If you’ve got a rigid, contract-led, legally-led, risk-managed, audit-led, procurement-led type of governance structure, then you deny yourself the opportunity do what actually makes sense, once you discover what that actually is.

Another lost opportunity is when you go into procurement mode and there’s a blocking of engagement with the vendor community and supply-side that have IP and knowledge about the solution possibilities, about different ways you can do it, about governance and management and how to create a successful project. All those things are blocked off, all that interaction is limited and squelched in order to protect procurement and to protect probity. And it’s not necessary. You can have transparency and openness and probity, but also maximum engagement and encouragement of ideas, so that you have the best chance of choosing the right thing to do and then setting it up to be done well. Often we block that exchange of knowledge in the procurement process and that’s a shame.

Is there just too much risk in IT projects? How does one minimise this risk?

I think sometimes the way we go about IT projects creates unnecessary risks. For example, if you’re going for a monolithic $100 million project in one big bang, as opposed to doing it in bite-size chunks of $100,000 or a million each, those are two different risks. It’s not the technology that’s creating the risk, it’s how were going about the project and how we’re setting it up, how we’re undertaking it that creates the risk.

The biggest risks in IT projects are human risks. The risks are around whether we have the competency from governance and management, through to implementation. Do we have the right people doing the right things? Do we have the right capability, the wherewithal? Quite often the biggest risk to the project isn’t the technical risk, but that we don’t have the appropriate wherewithal to embark on the project the way we need to.

We need to look at the risks up front and then structure and manage the project in a way that mitigates and reduces those risks. They need not be there, but we carry them with us by failing to take the most intelligent steps in our approach to the project.

Is there a misalignment between what people think they can buy IT for and what it actually costs?

I think there are two sides to that. Quite often people pay far too much for what they’re doing, and other times people simply end up with budget blowouts, so both can be true. Sometimes we’re not that clever in finding very cost effective ways to deploy technology in order to progress business, and on the other hand, in our business case work, we don’t look at all the elements that are necessary to achieve successful projects.

Quite often the biggest risk to the project isn’t the technical risk, but that we don’t have the appropriate wherewithal to embark on the project the way we need to.

Again, a lot of times in procurement we’re forcing people to try to win on price, so they think they have to bid low. You see it in building – people will go in and bid a price to win and then hope to somehow recover it through change controls, through variations and so on. It’s a terrible system. My advice would be to look at processes which better enable the buyer and the seller to discover truly what the cost is likely to be, together, and to set contractor prices that are more realistic, that are more knowledgeable and more aware of what is truly involved on both sides.

There’s this fixed-price game of risk, where the customer doesn’t really know what they want, but they’re going out to market anyway. They want the best price, they get everyone to compete on price, and the seller doesn’t really know what’s involved because they don’t really have a chance to discover that. They don’t have a chance to go through proper analysis and exploration and discover with the customer, so they have to build a whole heap of risk factors into their price and away they go, both sides hoping they can actually get the job done for the price they’ve agreed in the contract, when in reality neither party really knew enough to set the budget at the time.

If you look at the model for how you set your estimates in these conditions you’d be looking at something between plus 150 per cent and minus 25 per cent, in terms of the budget. When you’re doing procurement you want certainty, so you don’t want a budget that could be 1.5 out, but that’s what we get, because we’re trying to contract the price as though it was certain at a phase when it couldn’t possibly be because nobody’s done the work.

It’s so much better to go along in modules and say “okay let’s do the concept, do the feasibility study and let’s be honest with the board about what we do know and we don’t know. Then let’s go and contract the discovery and design work and then the development, and be flexible about how we get that done”. That way you discover clever ways of doing things, you’re less likely to have budget blowouts and you’re more likely to discover the best way to meet the business goals at the end of the day.