A Study in contrasts
In the last few weeks I have read two contrasting articles in Computer Weekly (11th and 12th January).In the first I learnt that the Cloud would be the saviour of IT, enabling costs to be reduced for maintenance and speeding up delivery of new systems. Developers simply call in the cloud when they need to start development giving them a tremendous speed and capacity advantage over developers using traditional methods.Â In the second I learnt from Gartner that about 30% of Business Intelligence Projects fail to deliver on business objectives. This gives rise to a fascinating dichotomy. Â We marry truly rapid development methods available in Agile, with development capacity on demand from Pay-for-Use Cloud services and time to market becomes incredibly short.The dichotomy is that this makes it imperative for client teams to work out what they want their business change to look like before the IT project is launched, that is, business users have to stop making it up as they go along.
In other words new methods and technological advances take IT development off the critical path for business change.This should not be new and radical, but it is.Since the 1970s when IT took off, we've become inured to the idea that the pace of software development limits the pace of business development.If the Cloud gurus are right then this is no longer the case. Now business will hold back IT.
Getting your act together
Every new development methodology, Iterative, RAD, RUP etc. has been hailed as a new dawn, and each has indeed increased the speed of development up to a point.Agile increases it even further - potentially. Marry agile to the cloud and start-up times and time to market for software development become much shorter, but will this speed deliver the goods?
I have had blazing rows with clients who claimed that the new methods didn't work. Â The substance of the arguments was that clients thought that these new methods meant that they didn't have to understand their requirements anymore. They couldn't understand that not knowing what their business would look like at the end of the project guaranteed failure.They couldn't differentiate between the technical requirements governing the look, feel and performance of applications and the underlying business change that the new system would support.They entered the fray unprepared except in the vaguest terms, resulting in dissatisfaction with what was delivered. Â My guess is that many of the failed BI projects suffered from the "But that's not what I wanted," comment upon delivery, whatever methodology was used.
The use of Agile methods and the Cloud make it even more urgent that businesses understand the need for clarity of vision. Agile by its nature should reduce the problems, but the product backlog has to be managed and prioritised effectively if the final Business System represents what the client wants.
My response is - Businesses get your act together - you must know what your business will look like at the end of the business change lifecycle. As ever it's garbage in and garbage out. WIth software now deliverable in the time it takes for two committee meetings to be set up and run, it's vital that business get their thinking straight, coordinated and ahead of the IT stream.
If IT is no longer the defining part of the critical path of Business Change then what is? It must be the rest of the Business System Changes that now control delivery. In the new universe the key is defining and developing planned business changes in the knowledge that development of any new IT to support it is not the looming bottleneckÂ and black hole for money it once was.
Software development can come nearer the end the Business Change Cycle so that the IT Change can be defined easily and recorded accurately, but leaping on the fast development bandwagon without giving some forethought to the final business solution is indeed the fast lane to disaster.