My personal high horse
16 Aug
… Primarily because of articles like this one by CIO Magazine. I found this article through Ameel’s website, so hat tip to Ameel for that one.
Every once in a while someone publishes a “nn reasons why your IT project fails” article. Every time it leaves me with some longing for something insightful. In this CIO Magazine article, every one of the 14 tips provided are logical and rational. Each one of them is actionable. Each one of them is also useless.
The only tip which comes close to dealing with the true underlying problem is tip no. 14 on communicating with project sponsors and stakeholders. Even this only addresses it in a very rudimentary way.
Firstly, the points made in these articles are practical and useful. I believe they have some value. The problem is that they simply don’t go far enough.
As IT people and project managers, we are trained to be operational, logical, planned, rational and ultimately to solve problems. We read material which reinforces this world view of ourselves. In this instance, the article hands us a platter full of 14 problems to solve and some very palatable solutions. In fails in addressing the real hard questions we need to deal with in order to be effective leaders of IT projects.
This article, and others like it, provide us with a convenient scape goat. As long as we do these things (e.g. select the right project team, use repeatable processes, track changes), then we can avoid the real issues.
Agile deals with this partly by making it easier to “go with the flow” and safely absorb the changing nature of projects. Most of the documentation I have read on the subject focuses on creating processes to control and manage. Don’t get me wrong, these are really really important processes to put in place.
Where I fear we trip up is when we implement the processes expecting them to solve or at least help with our people issues. Again, there isn’t much focus on engaging with real people. How do we better relate to them? How do we learn to understand them and their own pressures and needs? How do we “do communication better?”
In my mind, the real issue is a lack of dialogue. Not talking. Not listening. Not communicating. But real dialogue. The ability to put your own needs aside and engage on a deeper level with those you are working for. Only when we get to this space will we begin to see significant gains in IT project successes and real positive outcomes.
Often we need to hear things that we don’t want to hear. Often we need to say things others may not want to hear. As leaders of projects, we need to create a space where this can occur. An open, respectful and reflective space.
This is an area that I am only just begining to explore for myself. Because of this, I still find it difficult to explain in words. The area is one studied by Ronald Heifetz and is known as Adaptive Leadership or Adaptive Change. As I find the words and have the experiences, I hope to write and share more about this.
Until then, some of the following articles might help provide some insights for you:
2 Responses for "Really, why do IT projects fail?"
I agree with you completely: numbered lists will never delve into a topic deeply enough to do it justice…but that’s okay because they’re not meant to. They’re like those signs next to staircases that say: “For your safety, please use the handrail at all times”. That is, their advice is mostly obvious but it’s nice to be reminded of it every now and again :) I think magazines publish them every few years because there’s always a batch of new managers who have just entered the workforce and really do need to have the basics of project management explained to them.
On the other hand, lists such as these have the potential to be downright dangerous because bad managers look at them, tick their points off one by one, and then lull themselves into a false sense of security and accomplishment of a project well-managed. The results of that are often catastrophic. Decent managers learn from this while the bad ones go buy next year’s edition of “management” books and repeat the process all over again.
Meanwhile, thanks for taking the discussion to the next level. Heifetz is awesome (we read some of this stuff in our ‘Leadership’ course) and those links are really useful.
Adaptive Leadership is particularly important for the IT department, I think, because IT is often seen as a service and support function instead of an enabler and implementer of business strategy. If you manage to move the IT department (of a non-tech company) from the former to the latter category — both in the eyes of the IT department as well as the rest of the company — then you really doing a good job as a leader :)
Thanks for the comments Ameel. I agree, these lists are just part of the learning stages for new managers. They are important, but certainly not the most important thing (in my opinion!)
The problem I have is that most IT managers are recruited from the technical areas and therefore have already been trained to be process and rational driven.
You’re right Ameel, they can be dangerous and cause people to feel safe that they’ve ticked the right boxes. It’s the reinforcing your world view mentality.
I feel that it’s time these publications begin to move into the real issues affecting our industry.
We’ll have to talk more about your “Leadership” course. I picked all this up from the Mt Eliza Senior Leadership Program I did the other week. It was insanely enlightening and insightful. Certainly not easy though.
There’s definitely scope to change the way our industry works and is viewed. That is what is so exciting for me at the moment! :-)
Leave a reply