Deconstructing ITSM

12 February 2009

10 Reasons Why Strategic IT Management Initiatives Fail

Dennis Drogseth has published an article 10 Reasons Why Strategic IT Management Initiatives Fail on CIO Update.

Now, I agree with every one of his ten reasons, but I immediately thought of some different angles on the approaches he recommends …

  • Insufficiently detailed requirements – This may be pretty self evident, but the rush to get started on a tactical basis often overpowers better intentions. Take a little more time and make adequate, detailed plans.
    • Rushing into initiatives with no planning is obviously a bad thing, yet all too common. But more planning does not always help, unless you have a fairly stable business environment (who has?) and excellent business analysts.
    • A bigger reason for failure is believing that initially defined requirements are accurate; adding more time and detail to plans is unlikely to fix this. Better solution: understanding that requirements have to evolve.
  • Insufficient attention to process – While almost everyone recognizes the need to pay attention to best practices, such as ITIL, in a very large number of strategic initiatives, process education is dealt with in an ad-hoc manner; often after the initial planning is done. On the other hand, problems can arise when a religious approach is taken and ITIL, for instance, is treated as more gospel than departure point.
    • … Can’t disagree there. ITIL is not gospel – but on the other process culture is not ad ad hoc thing.
    • There are often reasons other than ignorance for not paying attention to process … like wanting quick results. IT leaders should feed desire for quick results by implementing in short iterations, while paying attention to quality and management of process by, for example, refactoring out the inefficiencies, and continued training. These are some of the Agile Software Development principles that I think are more widely applicable.
  • Executive support – Just in case you didn’t realize it, you’re all important in the success of strategic initiatives. The lack of firm commitment from executives can seriously disrupt strategic initiatives.
    • Very true.
    • … Our rule of thumb is that you, as executives, will need to see documented results no less frequently than every six-month. This can put constraints on project planning, but it can and should be achievable with the right detailed approach.
    • Wait. Every six months? In Agile initiatives, that would be for ever. Can we aim for working results every month?
  • Inadequate or waffling budgets
    • OK, budgets are hard (guesswork is easy but pretending it’s real is hard). I would rather see departments building as much of the budget as possible against an agile “backlog”, with costs earmarked against features. After operational / core budgets, tied to already-established services, that just leaves the “waffle” for requirements that haven’t emerged yet (not yet on the backlog).
  • Staff buy-in” – nothing to add
  • Resistance to change” – it’s a major issue; but requiring small amounts of change at a time for tangible benefit (through agile iterations) has got to help.
  • Managing expectations” – also important. And delivering change in small, frequent packages helps. In fact, user expectations become your friend: by discovering them more quickly and in more detail, and by including users in the development teams, you’re going to get better long-term value.
  • Lack of follow through
    • A culture of frequent iterations helps enormously in creating a culture of momentum. ITIL’s emphasis on continual improvement can become a reality!
  • Lack of integration and Lack of automation
    • Again, it’s a major issue. Continued attention is important to streamlining the systems and support. And this seems to me exactly like the Agile principle of refactoring.

It may sound like I’m just promoting short iterations, but other Agile principles have to be included as well: open communication, including the customer throughout the cycle; unit testing / acceptance testing to prove quality.

Big Requirements Up Front is not the only approach.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: