We, Jenrick IT, are delighted to feature another guest blog from Gary Lloyd, Double Loop Consulting. When working with clients, we often experience projects that run into difficulty. Gary looks at how to mitigate against IT project failure and reaches some very interesting conclusions. We hope you both enjoy the article and gain value from it. Why do so many projects fail? The track record of IT projects is poor. Less than a third of IT projects deliver what they said they would, on schedule and on budget. The major cause of IT project ‘failure’ is not, however, poor IT leadership or difficult-to-use technology; it is poor business leadership. The Standish Group has surveyed the performance of over 70,000 IT projects Their conclusion is that “a skilled executive sponsor” is the number one determinant of success. There seems, however, to be an implicit assumption that a business manager who has reached senior management level should somehow know what do when confronted with an IT project, as if it were an innate skill. It’s a bit like expecting someone to sit behind the wheel of a car for the first time and to be able to drive, just because they happen to be an adult. At least in a car, the driver will quickly become aware of his or her lack of competence. But in the complex world of IT projects, the results of bad driving may not manifest themselves for many months or years. What practical steps can a business manager take? My book, to be published by Gower in September 2013, entitled Business Leadership for IT Projects - a value-based approach defines six key touchpoints where leadership can make a critical contribution to an IT project’s outcome:

  1. Create a clear unambiguous definition of the problem, need or mission.
  2. Define a shared, richly described project vision to serve at the project’s ‘true north’.
  3. Demand a delivery strategy and solution design that deliver regular business value throughout the project, not just at the end.
  4. Use constraints to generate a range of genuinely different solution options.
  5. Create a one-page business case summary, including key business case assumptions, to be reviewed monthly.
  6. Be a driver not a passenger during project delivery, evaluating value deliveries versus expectations and personally driving regular reviews.

As there isn’t space to expand on each of these in this article, I’ll pick out the three most important pieces of advice I have for those contemplating an IT project, to achieve their business goals. sections. 1. Don’t do IT The first piece of advice is a little paradoxical, given the title of this article but is serious and sincere. IT projects are slow to deliver and expensive, relative to other business changes and operational costs. More often than not, they fail to deliver their expected value at anything close to the estimated budget and schedule. Don’t embark on an IT project as a first resort. Make a genuine effort to identify alternative ways of realising your business outcomes, such as changing processes or buying a service that already exists. The benefits from IT projects often flow from business process changes prompted by the project, not the IT changes. Consider these statistics from over 70,000 projects. Projects that cost:

  • less than $750,000 have a 71 per cent chance of coming in on time and on budget;
  • between $750,000 and $3 million have a 38 per cent of coming in on time and on budget;
  • over $10 million have a two per cent chance of coming in on time and on budget.

If you are like most people, you will fall into one of two camps, depending on whether you are observing someone else’s project or whether it is your own project. When it’s not our own project, we tend to be very pessimistic about the chances of success. When it’s our own project, we are transformed. This is what psychologists call ‘optimism bias’. It’s prehistoric survival mechanism that gets out of bed each morning and is particularly strong in top echelon managers and entrepreneurs. Like most car drivers, we believe that accidents will not happen to us because we are better than average drivers. Accidents happen to other people because they are careless and, let’s be honest, not as smart as we are. The same thinking applies to IT projects, even if our own track record of success is limited or non-existent. So, before you set out on an IT project, with it’s project cost, opportunity cost and risks, ask yourself what basis you have for your optimism? Is there any other way to achieve your business goal? If you conclude that you really do need an IT project to achieve your business goal, the next two sections will help you increase the probability of success. 2. Step up to the plate and lead If your organisation or IT supplier has a development or project management methodology, you might be asked to take on a project role with the title of something like ‘Business Owner’ or ‘Project Sponsor’. There is nothing wrong with taking on one of these roles for the sake of good project governance. However, I have often seen is that when business managers assume one of these titles, they lose sight of their broader role: that of customer. Busy with their day jobs, they fall into a thinking trap that says:

these guys seem to know what they are doing, they have a process and I have a role within it which has a description. I’ll climb into that comfy seat, do what is asked of me and attend these regular meetings they have set up that let me know how it’s going. If they need me, I’m sure they’ll let me know.

With the assignment of a project role title, Business managers transform from demanding drivers into passive passengers. Whatever formal role you take in the project’s governance structure, always think of yourself as the customer. When you attend a meeting or read some documentation, try to remind yourself that you are a customer. This is important because the language that we use to describe things has an impact on how we think and act. The reason for this is because when we use a particular term, it instantly fires up a network of subconscious associations. So, if you say to yourself ‘I am the customer’ and believe it, your will subconsciously take on the characteristics and behaviours that you exhibit when you buy more mundane products. Think about buying a computer or a car:

  • The supplier is providing you with a product.
  • You want to ensure you get what you want
  • You want get value for money.
  • You want to ask questions about what you are getting.
  • You don’t want to go away with the wrong thing.
  • You consider some different options before choosing.
  • You try out options whenever possible.
  • You are responsible for the choice, not the supplier.

These are the sorts of things that customers do. Of course, buying a car is not the same as initiating an IT project, but the customer mindset should be the same. Be a demanding customer. Don’t be like the diner who doesn't want to send back their over-salted soup because they ‘don’t want to make a fuss’. Being a demanding customer for an IT project means taking the lead and asking questions about what you are going to get. Ask your supplier the following questions:

  • How can I help you and your team understand the problem we are trying to solve?
  • How can I help you and your team understand the way in which the project creates value?
  • How can I be sure that I am going to get what we agreed?
  • How are you going to ensure that it works the way I want it to?
  • How can I avoid leaving it until the last minute to find out whether it meets my expectations?
  • How can I help reduce the risk of cost and schedule overruns?
  • How can I understand progress in order to know whether we are on target?

But don’t forget that the role of leader is not done once the ship set sail. That’s when the hard work starts. You need to be a demanding customer throughout the project delivery. To enable you to do this I recommend that you demand that your supplier adopts a strategy that delivers regular chunks of business value. 3. Value-based delivery Insist that your IT supplier adopts a strategy that delivers regular business value to customers and stakeholders throughout the project. Don’t accept a strategy that means you to wait until the end of the project to get all of the value. Making this clear to your team and your suppliers at the start of the project enables them to create and design a solution that is structured for regular value delivery. In addition to early value delivery, this strategy will enable you to evaluate regularly:

  • the value delivered versus expectations;
  • the actual cost compared to the forecast;
  • the actual duration compared to the forecast;
  • the actual solution delivered versus what you thought you would get;
  • the quality of what was delivered;
  • how well the supplier/customer relationship is working.

The delivery of each increment of the project’s overall value provides an opportunity for the project team to learn and adjust course, rather than waiting until the end of the journey and discover that the project has arrived at the wrong place. Consider a big home refurbishment project. If you have ever seen the television programmeGrand Designs, you'll get the picture. A couple decide to take on a huge refurbishment project, vowing to be in by Christmas. Cut to snow covered building site and the disconsolate couple, who are still living in a temporary home on the side of site. Alternatively, they could taken a value-based approach. To do so, they would have collaborated with their builder to identify chunks of value. For example, having identified a functioning toilet as having particularly high value, they could then have asked for it to be delivered first. Then this might be followed by a shower room, followed by a kitchen, a bedroom and so on. The total value could have been delivered in chunks. The builder might argue that this approach would make the overall project more expensive. But then the estimate is only a guess anyway, given the novelty of the project. A value-based approach is better because it enables you calibrate the supplier’s productivity and improve the estimate with each delivery. And, in any event, wouldn't it be better to have a four-bedroomed home with a roof, rather than an uninhabitable eight-bedroomed home without one? Note that taking a value-based approach requires the customer and builder to design solutions that allow for incremental delivery of value. You don't design a solid oak wardrobe for Ikea and then try to figure out how to flat pack it. Ikea furniture is designed to be flat packed. Summary IT projects are risky and expensive. Avoid them if you can. If you decide that you need to pursue an IT project to achieve your goal, there are lots of practical things you can do. The most important of these is to have a clear, richly imagined, shared vision and value-based delivery strategy. But the key is to take on the mantle of driver rather than passenger. Lead as you would for any other project of importance. When you add the opportunity cost to the project cost and benefits forgone, there is a lot of money at stake. You really should be giving it your close attention throughout. Be a demanding customer. Image sources: Thanks to clearvisiondesign.co.uk for the original image that appears at the top of this article. The other two images in this article have been taken from the Double Loop Limited website. FURTHER INFORMATION AND RESOURCES

  • If you would like to discuss this topic further, please contact Jenrick IT on 01932 245 500.
  • Please click here to visit the Double Loop Limited website