Roger Session at ObjectWatch Inc. recently published a report on the cost IT project failure. He estimates the annual cost of failed IT projects at an astronomical $6.2 trillion.
The document titled "The IT Complexity Crisis: Danger and Opportunity" is a 22 page white paper that according to the author:
"...analyzes the scope of the problem, diagnoses the cause of the problem, and describes a cure to the problem."
He goes on to state:
"...while the cost of ignoring this problem is frighteningly high, the opportunities that can be realized by addressing this problem are extremely compelling."
There has been a very vocal reaction from various folks who do not agree with the numbers and all the comments can be found on his website. Personally, I am not that interested in the figures themselves. They they are bound to be HUGE by any measure. Consider some of these numbers:
I am more interested in the message that underpins the numbers.
So what is the cause?
According to the author, the largest contributor is IT complexty and basis this on the following:
"Some have suggested the culprit is increased functionality. There are numerous arguments against functionality being the problem. And there is no evidence that functionality has increased at the same rate as IT failures have increased.
The almost certain culprit is complexity. Actually, complexity is indirectly related to functionality, in that a 25% increase in functionality increases complexity by 100% (Glass's Law, see [06]). However complexity is even more impacted by system organization. So complexity goes up as functionality increases, goes down as functionality is partitioned, but then goes up again as connections are made between systems. The overall complexity of a system is a delicate balance between all three of these factors.
Complexity seems to track nicely to system failure. The more complex a system is, the harder and more costly it is to work on that system. And while complexity can correlate with functionality, there are many examples of highly functional systems that are organized much simpler than other systems with much less functionality. Empirically, we have all experienced that the difficulty of maintaining a system is much more related to how functions are organized than to the number of functions."
Does a solution exist?
I think the complexity premise is a very valid and logical position to take. More importantly, how can the risk be mitigated to ensure that costs are not excesive in the eraly stages and therefore spin out of control as more scale and complexity is introduced?
The author suggests using a software design process called Simple Iterative Partitions, which "partitions business functions into subsystems" in a way that makes the overall system as simple and reliable as possible.
This 'simplicity in design' approach is process based and therefore measureable and consists of the following phases:
- Preperation
- Partitioning
- Simplification
- Prioritisation
- Delivery
More detail on this approach can be found in the whitepaper but I would say it is largely based on an itterative design and development approach.
In summary...
I can testify to the fact that an itterative approach can be very beneficial and when adopted correctly can deliver positive results. A key factor that has to be managed however is scope and scale of an initiative. Good communication and governance is also crucial.
In my experience however many organisations do not have the skills, apptitude or patience to adopt this approach in a consitent manner. This is largely due to the fact that on large projects and programmes there are very few people who can really grasp the details of the complexity that form part of Enterprise scale IT solutions.
A contributing factor to this is that the variety of Stakeholders (SI's, Vendors, Management Consultants etc.) typically found on these initiatives in many cases come from different backgrounds, with different methods and frames of reference. This inevitabley can cause all kinds of issues that result in miscommunication, delays and ultimately increased costs.
Until this type of communication, governance and itterative approach is adopted, I can can't see that excessive costs will ever be taken out IT projects.
In my opinion, BPM initiatives are ideal candidates for adopting and intitutionalising this type of itterative approach.
What do you think?
Leave a comment