Over the past 10 years, MagmaTec has worked extensively with the IT departments of a number of blue chip companies in the financial services industry. This experience has led us to a number of observations on the relative success of these IT departments within their respective organisations. This series of articles is dedicated to highlighting these findings.
The first article covers the strong correlation between the level of trust between the key stakeholders of the IT environment and the projected success rate of large IT projects. The impact of this variable is often higher than the pure technical or business capabilities that exist in the IT and business areas respectively. In order to properly understand who the key stakeholders of the IT department are, it is necessary to do a proper stakeholder analysis at the outset, acknowledging that the stakeholders will vary from one organisation to another. For the purposes of this article, we will use two generic stakeholders: "IT" (being the IT department), and "business" (being the "client").
Time has taught us that the nature of software implementation is not the same as a typical engineering project (eg, building a bridge). We say this because the requirements of the deliverable usually face major change while the deliverable is still in the process of being built. This results in an environment that requires a close partnership between IT and business on an ongoing basis. And as in any partnership, if one partner does not trust the other, the chance of the partnership succeeding will be severely impacted.
There are a number of factors influencing the levels of trust between IT and business. These include the general culture of the organisation as a whole, and the quality of the personal relationships between individual managers. However, there are three specific factors worth highlighting in this regard:
Firstly, in some cases there is a limited appreciation of the nature of software projects from business stakeholders. These stakeholders operate from a paradigm of fixed specifications and plans, and they get frustrated when delivery cannot be accurately predicted. Initial high-level estimations are often referred to as proof of the incompetence of the IT department, even when they are months out of date and no longer relevant. This situation normally results in a breakdown of trust over time.
Secondly, there can be a structural inconsistency between IT and business. A common example is where the IT structure is centralised (to try and achieve economies of scale), yet the business structure is decentralised. This often results in an environment where, even with the best intentions, the IT department cannot meet all the conflicting requirements of its multiple business clients. There is often no obvious structure governing prioritisation and budgeting conflicts. So-called "steercoms" set up in these situations often struggle to function effectively, owing to inappropriate staffing, or low levels of trust, or even having being established too late in the process.
Finally, there is sometimes a genuine case of non-delivery from the IT department over an extended period of time. In this case the low level of trust from business is unfortunately well justified, and some "structural surgery" may be required to resolve the problem!
So, what can a CIO do to improve the levels of trust with business? There are a number of techniques and actions that can be implemented, which can go a long way to achieving higher levels of trust. These range from accurate stakeholder analysis, improved stakeholder education and engagement methods, structural changes, more appropriate "agile" development methods which recognise the nature of the software development process, and so forth. Each situation may require different interventions in order to improve the levels of trust.
The moral of the story is that the level of trust between IT and business has to be a key variable on every CIO`s dashboard. Monitoring this could mean the difference between the success or failure of strategic IT projects, and in the long run, of the organisation itself.
Share
