Bjorn Ovar Johansson - Is it really easier to build a skyscraper than deliver an IT project as planned?

Pitfalls to avoid and IT project delivery best practice to improve the chances of successful management of IT investments

Successful IT project delivery could benefit from an analogy so CIOs, CTOs and senior IT leaders can communicate with the Board of Directors and executive management the best approaches to managing major IT investments.

There are currently about 100 tall buildings being constructed in London, in addition to 55 existing skyscrapers. Globally, during the last century some 9.000 skyscrapers have successfully been constructed in 100 cities with London currently listed as number 54. At the same time there are a number of IT programmes run and many more being planned. Why do construction programmes normally succeed and why do many IT programmes fail to do so?

In fairness, not all proposed large building projects succeed - quite a few planned initiatives are not approved by local authorities and some are cancelled by the investors before actual construction begins.

However, very few infrastructure construction projects fail completely - it is unusual to read about a bridge that couldn't be opened, a large building that could not be used as intended or a skyscraper that collapsed? Unlike IT programmes, most large constructions are finished on plan (time, money and specification), albeit some might be more expensive than expected and some might run for a little longer - or indeed shorter - than planned.

IT project delivery - Challenges

Why is so difficult for businesses and organisations to successfully manage IT programmes? The same goes for family homes versus IT and software development projects. The success rate of building a private home exceeds by far IT projects across most of Europe.

What are the success factors building a skyscraper (and what are the issues running an IT programme or project)?

  • Experience - the first 'high rise' built in London was the White Tower (part of Tower of London) in 1098.
  • Procurement - unlike organisations in general, an infrastructure project is handled by specialist 'buyers' and planners - still mistakes are made (e.g. the new Karolinska Hospital in Stockholm, Sweden will allegedly be much more expensive that expected as it was largely handled by politicians).
  • Skills - 'builders' do nothing else, they are specialists and have a vested interest in success whilst most IT management consultancies are not committed to the same extent.
  • Planning and specifications - when constructing a building, a complete blueprint and exact specification are always completed and approved before work begins. Both are pivotal for the project manager in successfully completing the project and changes are not done unless absolutely necessary and changes are always analysed and approved.
  • Senior management engagement and commitment - as I see it, this is the most important aspect - if the board and executive management only took the same approach to an IT programme as they would do when it comes to strategic business decisions most success factors would fall into place - this is where my analogy comes in.

IT project delivery - The house building analogy

I agree with those who argue successful CIOs are good storytellers. When advising a business on how to turn around a 'failed' IT transformation I often begin by speaking about building a house and not the programme as such. My analogy could be something along the following;

Imagine you are about to build a house! You and your spouse have agreed you want a bigger home and you have secured a nice piece of land. You have discussed what you want to build - let's say a three-bedroom house with two bathrooms, two stories, a large open kitchen and a veranda facing the south as well as a garage. Essentially you have a high level specification - you know what you would like to build, or buy.

You have also spoken with your bank about a mortgage and know what sort of money you can afford to invest - i.e. you have a budget.

As for options you know you could either go for a prefab home, an architect designed house or you could hire an architect to design a unique home for you - all are feasible, however, the latter is more expensive and require more of your engagement.

Once you have decided on the type of house you would look for an experienced architect and a project manager. Together you will agree the overall design and the architect will produce the blue-print (unless you decided on prefab in which case the house supplier and you will agree on final specifications of your home).

Next step would be to contact builders who can actually construct the house - this is where the project manager comes into play - unless you have an endless amount of free time you need someone to coordinate and manage the construction. Together with the project manager (and architect) you will sit down with the shortlisted builder and make an overall time plan as well as a detailed project plan including all aspects such as interior design, pluming, electricity, kitchen, bathrooms, garden, security, wifi, materials such as wallpapers, paint and colours and so forth and so on. You know that this is the only way to make sure you get what you want and that the budget can be met. Of course there are many decisions to be made at this point and a lot of arbitration unless you have an unlimited budget.   

Once the specifications, the blueprint and time plan is agreed you can move on to a final contract stage. Obviously you want to know when the house will be ready for moving in and ideally put a cap on the overall costs. The builder would most likely want to have a more flexible contract. However, most people would never go for a contract allowing the builder to invoice time and material only nor have a contract without some kind of penalty clause regarding quality and moving in date.

As sponsor (the person paying the bills) you want to visit the build site on a regular basis. Once the foundation is in place you want to visit the construction more and more frequent and have weekly meetings with the project manager and builder in order to make needed decisions and stay in control. Once the house is in place and the project is about interior design and fitting e.g. kitchen and bathrooms, you may want to have daily meetings on site.

Regardless of how well you have planned the project there will be unforeseen issues and things you may want to change or adjust, but you will not hopefully have decide on any major changes such as moving the kitchen from one side of the house to the other or decide to install open fireplaces just because you forgot to plan for them in the first place. Nor would you ask the producer of a prefab house to implement any major changes that lie outside the agreed 'configurations' (like kitchen appliances, floors, tiles and colours).

The house should be ready to move in to on the date planned. However, before you approve the end product you will have an independent firm inspect that everything is satisfactory and up to standard, and, you will also have the builder do any final adjustments if needed. Then, you will pay the remaining invoices and move in.

IT project delivery - Pitfalls and solutions to IT programmes

Now, let us apply the same approach and methodology to IT programmes. In my world, most IT programmes that fail do so because we as CIOs have failed to convince management about certain pillars that need to be in place to improve chances of success.

Here are some examples of avoidable mistakes that I have come across during the last 15 years when engaged turning around 'failed' IT programmes - these are easily prevented on forehand and sometimes possible to correct, albeit at an often significant cost:

  • Poor planning and vague requirement specifications - It is imperative that the sponsor and end-user organisation takes full ownership of the requirement specifications - imagine building a house and not engaging in the detailed design or starting construction until blue prints and specifications are approved and a contract is signed?
  • Off the shelf ERP/CRM software that are modified rather than staying with the offered standard solution and focusing on modifying your processes - would you ever 'rebuild' a prefab house? I have seen ERP projects with thousands of change requests. Combined with a time and material contract and you are likely to fail and the system will be expensive to maintain.
  • Too many or no IT architects - There are programmes that have too many architects and no architectural principles or a lead architect - it is like using several architects planning your house without speaking with another. IT integrations are one example - without integration standards you cannot effectively implement an ERP system, it would be like building a house using 110 volts in part of the house and 220 in other parts or installing fireplaces without a chimney.
  • Sponsor engagement is insufficient - A sponsor should be a senior executive representing the end-user organisation, however it is too common that the sponsor does not spend enough time managing the programme - in theory you can delegate the programme management (just like the home owner and the project manager), but a commitment and daily engagement are critical success factors.
  • Not enough testing - I have rescued an ERP programme that went live as a 'big bang' without proper testing and helped a system provide that delivered software that was shipped without system integration testing - would you have you family move in to a house that wasn't finished or would you host a house-warming party without having tried the kitchen first?
  • Time and material versus fixed price - Management consultancies obviously prefer to engage in large transformations on a time and material basis rather than agreeing to a fixed price or a shared risk type of contract - who would build a family home at time and material?
  • Wrong development methodology - Books can be written on this topic - my point is that Waterfall methodology is often more suitable for some parts of projects and Agile or Scrum for other parts. For example, the foundation and the main construction could be Waterfall and the interior design (like user interfaces in an IT project) would benefit from using a more Agile methodology.

IT project delivery - Conclusion

Hopefully this article inspires CIOs to be more proactive and educate their peers on executive level on some of the pitfalls before embarking on major IT initiatives. By constantly asking the same question; "How would I go about this programme if building a house?" will help you and your organisation to avoid some common mistakes and improve the chances of delivering a truly successful IT and business transformation programme.

 

This article was originally posted on the CIO website. The article can be found here: http://www.cio.co.uk/it-strategy/it-project-delivery-pitfalls-avoid-best-practice-for-it-projects-3642322/

Add new comment

By submitting this form, you accept the Mollom privacy policy.