The IT Credibility Crunch

Originally published 2 December 2009

In Theory

Financial headlines across the world have been dominated by talk of the credit crunch, caused by the failure of banks to lend money due to a lack of trust. Driven by general concerns over the ability of customers to repay new and existing loans, sources of funding dried up. Businesses that needed to take on more debt to support existing debts were forced to file for bankruptcy. This affected a whole range of organisations including many well run businesses, caught out by cash flow problems with late payers.

Working in IPL’s Business Consulting practice affords me the privilege of meeting with senior IT managers across a broad range of industries. Many of these conversations have highlighted an interesting parallel between the credit crunch and the situation faced by a number of IT Departments. The term I use to describe these circumstances is the IT credibility crunch.

In 1992, Ward Cunningham1 first drew the comparison between debt and technical complexity. Putting a suboptimal solution live to meet a deadline is like going into debt, the short term productivity boost makes future change more complex and expensive. Unless this design debt2 is tackled, subsequent initiatives ratchet up more debt making the cost of change increasingly prohibitive.

Eventually this leads to the IT credibility crunch: Business stakeholders lose faith in the ability of their IT department to deliver strategic changes and just like the credit crunch, funding evaporates.

The Reality

When presented with challenging project costs and timescales, IT managers often compromise on quality and introduce suboptimal solutions. Over time, the increasing suboptimal state of the IT estate degrades the ability to deliver change effectively. The IT credibility crunch strikes when important changes to the business are constantly stifled by the IT department’s apparent inability to deliver within required timescales. Inevitably, tech-savvy business stakeholders pull the plug on the IT department and seek help from external providers.

Irritatingly, external IT contractors can then cut corners to get quick wins without being accountable for exacerbating design debts. The marginalised IT department is later left to pick up the pieces and forced into providing highly priced support services, making it a noticeably expensive cost centre. Then the final insult comes. Requests for important business changes are replaced by requests to productionise the IT contractors’ morass of poorly written3, siloed applications.
Coming Your Way Soon?

You may not have hit the IT credibility crunch yet, but if the following scenario resonates in your IT department then beware.

As a senior IT manager, your operations director regularly asks for advice about the following issues:

  • There’s a lucrative opportunity in the marketplace, winnable with relatively small changes to how the business operates – the business needs to respond quickly.
  • A competitor is about to launch an upgrade to their service which will attract your customers and dent profitability – the business needs to respond quickly.
  • Significant legislative penalties will hit in the near future unless there are changes to how you deal with customers – the business needs to respond quickly.

The CEO wants an impact assessment pack and you’ve been asked to coordinate a response from IT. As you workshop through the options with design, development, test and support you hear depressingly familiar messages:

  •  “More effort designing last time would have made changes easier this time.”
  • “Previous tactical initiatives means that changing the code is more complex this time.”
  • “We’re changing this code for our new high priority Product X, there will be dependencies.”
  • “Deadlines don’t allow enough time to properly test the changes; it’s risky.”
  • “Systems are at full capacity and won’t be able to handle these new volumetrics.”

Even your most basic options don’t meet the commercial deadlines, or worse still there is no solution. If you regularly come across this situation then read on, or you too may soon become another victim of the IT credibility crunch.

Other warning signs that this condition is about to strike include:

  • A colleague asks you in the corridor for progress on an IT initiative you never heard of;
  • External IT consultants appear in other departments without your knowledge;
  • You stop getting asked for impact assessments;
  • An organisational change programme starts, focused on bringing IT closer to the business;
  • The operations director resigns resulting in IT provisionally reporting in to finance.

Remember, a key feature of the IT credibility crunch is the breakdown of trust between business stakeholders and their IT department.

Don’t Panic!

So what’s the equivalent of quantitative easing in the IT domain?
As stated earlier, over the years I’ve discovered that many organisations face this situation to a greater or lesser degree. In all cases my advice is the same, model and measure. This requires a three pronged approach to:

  • Understand the IT estate;
  • Uncover legacy debts; 
  • Make incurring future debts more transparently accountable.

Start by modelling the business4 to understand how important information assets are treated by your organisation. Remember, you can’t start measuring effectively until you have a vision of how the business functions. Otherwise how can you judge what’s suboptimal? This should also provide useful insights into the competitive pressures driving business stakeholder behaviours.

Next, instead of another change workshop surprise your colleagues in design, development, test and support with a review workshop. Get the assembled group to identify the major pain points in the delivery lifecycle and help determine their cost. Then sit back and let them give you a history lesson about why it was done that way and which projects were to blame. Believe me this therapeutic group exercise will provide huge amounts of information. Use the most costly and obtuse examples to develop “legacy design debt case studies” outlining why they were incurred, their impact and what it would cost to refactor.

Finally, augment the project delivery process to capture design debts and future refactoring costs for all solution options. To maximise the benefits of this approach you must ensure that business stakeholders sign off the design debt incurred by their chosen solution. This change will require challenging negotiations so make sure you leverage your business model and the legacy design debt case studies to demonstrate value.

This three-pronged approach to handling debt will not guarantee that the most efficacious technical solution will be chosen. However the IT department will be engaged in a credible dialogue with key stakeholders when tough decisions need to be taken about the future of the business. Inevitably this builds confidence in the IT department’s ability to deliver change and mitigates being caught by a future IT credibility crunch.

And Finally …

Don’t stop when you’ve convinced the business about the value of transparently handling design debt. With a little more persuasion you should be able to get a debt management plan in place to tackle those legacy issues too. This is sure to put a smile back on the faces of your design, development, test and support teams. You are also likely to start finding copies of your models and measures in use around the business.

References:

  1. Ward Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report (Ward Cunningham. “The WyCash Portfolio Management System.” 1992).
  2. In his influential 2004 text, “Refactoring to Patterns”, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as "design debt" (Kerievsky, Joshua. “Refactoring to Patterns”. ISBN 0321213351. 2004).
  3. See Adman’s description of spreadsheet Cottage Industries (Adman, James. “Drowning in Spreadsheets.” http://www.b-eye-network.co.uk/channels/1554/view/11482/. 2009).
  4. Read “Data Modelling for the Business” to learn about High-Level Data Models and master techniques for building one on your own (Hoberman, Burbank and Bradley. Data Modelling for the Business. ISBN 0977140075. 2009).

 

  • Tim FranklinTim Franklin
    Tim Franklin is a Principal Business Consultant at IPL, a leading UK IT services company, specialising in the delivery of intelligent business solutions. He has more than 20 years of experience spent in a range of roles working at a number of leading organisations, including Virgin Mobile, EDS and HP. Tim's latest interests have been focused on enterprise architecture, and Tim has demonstrated his expertise in delivering complex and diverse technologies that have contributed toward the success of many businesses. Since joining IPL’s Business Consulting practice, he has continued to develop his expertise in this field through working with major clients to successfully deliver an assortment of information management, BPM and SOA solutions. He can be contacted using tim.franklin@ipl.com.

Recent articles by Tim Franklin



 

Comments

Want to post a comment? Login or become a member today!

Be the first to comment!