Ask the Experts
Ask the experts is a column in the Financial
Times IT Review supplement, which focuses on addressing IT issues faced by
business leaders. This short article, written by Auridian’s MD and founder, Ade McCormack, appeared in the 20th
October edition.
“Why do IT projects fail?”
Most people will agree that a project is an activity that is
constrained by a number of variables, including time, money, environment,
people etc. One important variable is the expectation level of the recipient.
Meeting or managing this expectation is key to project success.
The IT industry provides the fertile conditions needed to
maximize the chances of project failure. A lack of standards coupled with a
plethora of half-baked technologies turns the most mundane requirements into
groundbreaking exploratory science. There is little project managers can do
about that except trying to use the same ‘tried and tested’ technologies for
every situation regardless of the business requirement. A safe but
innovation-free approach.
Let’s focus on the reasons that lead to failure that are
within the control of the project manager. Firstly, failure is in the eye of
the user. Traditional quality assurance systems define success in reliability
terms, which will no doubt suit the six-sigma vendors. However quality could
equally mean usability (“I don’t care if it crashes once per week, what’s
important is that my slave wage IT-illiterate temp staff can use it”) or even
speed of delivery (A 100% fault tolerant parcel logistics solution will be of
no use to Santa Claus if it is delivered after Christmas). With the exception
of a minority of applications, most users will trade reliability for other
benefits. One well-known software house has built a business on this.
A common phenomenon in the IT industry is that clients
complain that they have received exactly what they asked for. This problem
highlights two issues. One is that the client was asked what they wanted two
years ago and then did not hear from the project team until the day of
delivery. A more user-involving development philosophy would get around this.
But I do empathise with the IT department for not taking the customer’s phone
calls during the development process. The established approaches to system
development need to be more agile to keep pace with ever changing business
requirements. Secondly the client does not fully know what they want and just
because they signed off a thick functional requirements document should not be
taken as an indication that they have read it. In court, this document counts
for little. It’s all about fitness for purpose. Again a more user-inclusive
approach is required.
Software engineering, which by the way is on the verge of
coming back into fashion, has a large part to play. The principles of building
a McDonnell Douglas Phantom jet fighter bomber out of Airfix parts does not
scale up to building a working model. The software engineering industry has in
many ways still not recognized this. You are encouraged to turn all big-bang
projects into a series of little phuts; the latter is currently state of the
art.
To avoid board level disappointment, ensure that IT
department projects are underpinned with a strong business case and board
sponsorship. Large spend that has no link to the business strategy will slow
down the CIO’s ascent to the board.
In conclusion the IT department has a responsibility to
allocate its resources in line with the needs of the business, to involve the
sponsors and users throughout the project and to have a sufficiently flexible
approach that can absorb unforeseen changes in direction. If ever there was a
case for project outsourcing…
Ade McCormack
ade@auridian.com
www.auridian.com
Ade McCormack is an IT value consultant and the author of IT
Demystified - The IT handbook for
business professionals, which is currently available via www.auridian.com/book, and all good
business bookstores.
