Some articles are written out of a compelling and emotional need to communicate a point and not necessarily garner support or interest. Some things need to be said and often many are thankful for the ones saying it. This is such an article. Our current economic crisis has highlighted the need for change within IT organizations that are pressured to deliver. Crisis often leads to correction and gets us tuning and pruning so that we make necessary changes to how we behave and operate.
Without hesitation I’d say that most enterprises I know have taken major steps towards introducing change into IT. This has come in the form of newer technology but more importantly it has meant drastic shifts in attention to culture, process and newer practices that mean less waste, better use of money and higher quality. Yet despite these trends, which will prove to be super effective and positive in the coming years, there are other organizations that have stuck to their old ways, going through the motions and in many cases being led by suppliers whose leveraged models have them paralyzed and unable to become nimble and address market conditions. The result is an increase in IT project failures across the board and a blame culture that will try blaming almost anything, including agile for their inability to change.
Just look at the following 12 month period. In March 2011 an article was published by ZDNet covering a CIO analysis study claiming that 37% of IT projects fail and over a year later another article by ZDNet indicated that 70% of IT projects fail affecting three billion dollars or 4.7% of global GDP. The truth is there are numerous articles on IT project failure with percentages that vary from the 30% – 80% range and money spent edging into the trillion mark.
All the studies have a common theme; they cite mismatched expectations, lack of skill and competencies present in the workforce, traditional culture that isn’t interested in change but rather continues to support a blame culture and conflicts between clients and their vendors on contractual expectations and working models. What these studies don’t have in common is blaming a methodology or process for their failure, yet in recent history many large scale public and private sector projects are finding it convenient to blame agile when things go awry.
It’s true that the introduction of any new approach typically causes some form of disruption, especially when you introduce agile practices into a traditional IT organization. Yet the evidence of success with new ways of working is overwhelming and it is simply not acceptable to blame an inanimate object (or rather process) for why something has failed to deliver.
Agile isn’t the answer to all things either but it surely isn’t the problem. The point is that unlike a physical product that may not be functioning correctly and therefore breaks down and fails, a process or methodology like agile is people dependent. We are responsible for executing the process correctly as it applies to our respective organizations. We, as people, need to configure it so it works, tweak it when it’s not working well and ultimately refine it so it hums like a well-oiled machine. We need to incorporate new processes and practices, like agile, into our existing environments and then ensure our people have the learning to properly use them.
If things aren’t working can we really blame the process if we are not focused enough to make it work? I would challenge organizations to take a hard look at what’s not working and instead of just assuming that a process is to blame, how about we assess our ability to execute it, the capability of our suppliers to support it and the probability that we might not understand it well enough to make it successful.
Organizations also have the challenge of working with large suppliers whose business models are what we call “leveraged” – meaning that their revenue is derived from operating in a specific manner that allows them to spread the costs and upside across several clients or several client teams. I’m not suggesting that this is a bad model but I do challenge the model when the result is an ongoing failure to deliver on the client’s behalf.
So how do we avoid failure and ultimately the need to blame? In this article the only counsel I can offer is to say that relationships matter or to say it more precisely, let’s look back over a decade to the agile manifesto: Individuals and Interactions over Processes and Tools. For that matter, the rest of the manifesto is appropriate as well. As is stated under the manifesto, there is value on the items on the right but there is more value on those on the left.
In such an economic climate that shows little hope of recovering soon can we really continue to do away with personal responsibility and transparency?