Why is the relationship between business and IT so often so fraught? Kube Partners Andrea Guerra, Managing Director London, 30th June 2009 What Chris Hanks will talk is about the use of IT in Commercial Insurance, where process automation and data integration have an increasing important role. To make IT work, especially in Commercial Insurance (which is a sort of uncharted territory for IT) , business and IT will necessarily have to work together. And I will talk about this relationship - why it is so often so difficult? What are the main reasons behind that and what can be done to mitigate this issue? Let me start with not an entirely moot question.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Why is the relationship between business and IT so often so fraught?
Kube Partners
Andrea Guerra, Managing Director
London, 30th June 2009
What Chris Hanks will talk is about the use of IT in Commercial Insurance, where process automation and data integration have an increasing important role.
To make IT work, especially in Commercial Insurance (which is a sort of uncharted territory for IT), business and IT will necessarily have to work together.
And I will talk about this relationship - why it is so often so difficult? What are the main reasons behind that and what can be done to mitigate this issue?
Let me start with not an entirely moot question.
Would you get a train if you knew that it has 75% probability: - to arrive late - to get to the wrong station - to double its fare while youʼre on it - or even to stop halfway?
According to a 2002 Gartner Group research 75% of IT projects are considered a failure by those who have started them. They mean that the solution fundamentally did not do what was agreed, it missed deadlines and over-spent.
Half of the IT projects go 200% over-budget. So, in terms of failure of human endeavours, IT projects are second to none - not even marriages.
In more prosaic terms, the perception of the business of IT has become part of the corporate culture and is ridden with cynicism: - wasted money - missed opportunities - massive frustration in the boardroom - ...
Unclear or unconvincing business caseInsufficient or non-existent approval process
Poor definition of project scope and objectivesInsufficient time or money given to project
Lack of business ownership and accountabilityInsufficient and/or over-optimistic planning
Poor estimatingLong or unrealistic timescales; forcing project end dates despite best estimates
Lack of thoroughness and diligence in the project startup phasesLack of user involvement (resulting in expectation issues)
Product owner unclear or consistently not availableScope creep; lack of adequate change control
Poor or no requirements definition; incomplete or changing requirementsWrong or inappropriate technology choices
Unfamiliar or changing technologies; lack of required technical skillsIntegration problems during implementation
Poor or insufficient testing before go-liveLack of QA for key deliverables
Long and unpredictable bug fixing phase at end of projectInsufficient attention to stakeholders and their needs; failure to manage expectations
Lack of senior management/executive support; project sponsors not 100% committed to the objectives; Inadequate visibility of project status
Denial adopted in preference to hard truthsPeople not dedicated to project; trying to balance too many different priorities
Project team members lack experience and do not have the required skillsTeam lacks authority or decision making ability
Poor collaboration, communication and teamworkNo project management best practices
Weak ongoing management; inadequately trained or inexperienced project managersInadequate tracking and reporting; not reviewing progress regularly or diligently enough
Ineffective time and cost managementLack of leadership and/or communication skillsCourtesy of www.agile-software-development.com, “Why IT project fails?”
So the question on “Why do IT projects fail?” is quite a relevant one.
Project, as every human activity, have this remarkable tendency to go pear-shape; I am sure that everyone in this room has a ideas why.
I have listed some very valid reasons here. They vary from a poor business case, optimist planning, wrong technology, lack of senior management involvement, to sheer overt incompetence.
I would like to offer a couple of reason of my own.
The first one is about perception of what IT can deliver and how this perception has changed in the last few years.
The reason for this change has been the impact of Consumer Electronic in every day life (phone, game console, sat nav)
According to 2009 research of ESA (Entertainment Software Association) 42% of american households has a game console; the average game player is 35.
Technology not only entertains us everyday but also allows us to communicate in unprecedented ways: we can keep in contact with a distant cousin in Australia via Facebook or talk for hours over skype a girlfriend in Sweden or watching the latest Little Britain episode on my iPhone So if technology can do such a magic so easily ... why do I have wait for months to have my IT guys to upgrade our web-service capability for the Broker Extranet? Why it takes lo long to launch a new product?
Consumer Electronic has spoiled us, raising the bar of our expectations.
So coming back to the original question. Why the relationship is so fraught?
Well, first of all because one party expects magic.
135 metres
There is also another factor to be considered when we talk about this relationship.
Sometimes it is hard to match the business expectations for one simple reason: IT is phenomenally complex.
I would like to give you an appreciation of what I mean by complexity in IT. As you know, IT is all about writing code that computer can execute. Code has grammar and a syntax - is a sequence of sentences, similar to a book, just a bit more boring. Have you got an idea of how many lines of code have been written by Microsoft engineers for Vista? 50 Million! In IT terms, 50 SLOC which stands for Million of Source Line of Code.
If I decided to print it on a 12 page per minute laser printer, it will take 115 days ... from the 1st of Jan till the 26th of April.
The pile of shit ... sorry, the column of paper ... my command of the English language is painfully limited, will be 200 metres high and if it happens to fall over, it will cover a an surface of more than 1000 football fields.
And how about an Insurance System? I have phoned a client of ours and asked how many SLOCs they have. He was a bit baffled by the question, but after a couple of days, he came back claiming that for his company the whole monty (Poladmin, Claims, Accounting, General ledger, CRM, MI, finance, ...) was about 75 million of line of code.
So, when you shout to your IT guy, “go and fix that damn thing”, just for a sec, think about how difficult it might be to find a sentence that is wrong a book that is 250 meters thick.
“Strangely enough it seems that the more information is made available to us the less well informed we become. Decisions become harder to make
and our world appears more confusing than ever.” (Jeremy Rifking, “Entropy: a new world view”, The Viking press 1980)
There is another reason why the relationship is is so fraught - because IT people are under a lot of pressure from to business to deliver ... and that is expected but also from another couple of dangerous forces.
(1) “Conspiracy of the vendors”: managers, senior managers, IT Directors have a constant INFLUX of emails, phone calls, visits from hardware and software vendors that claim that they have the perfect solution or the right answers to WHATEVER the problem may be. How can you separate the wheat from the chaff?
and if this were not enough, there is a second menace.
(2) “The Reign of Terror” instigated by consultants to justify their own existence and fees: we consultants SOMETIMES instigate the constant urgency of experiments, of changes, of never-ending improvements. making the water even more murkier.
So an IT professional needs to use to his own advantage vendors & consultants, a balancing act between waves of technologies and technologists under the pressure of everyday business.
So coming back to the original question - why the relationship is so fraught?
One party has high expectations and the other - caught is overwhelming complexity and information overload, has no time to listen.
How to make IT less painful?
So, we how to make all this less painful?
There are many proven recipes out there on how to do that and, so I though that if I threw in a couple of mine it would not harm anyone.
Nowadays to compete and win in Insurance you are AS dependent on IT AS a F1 DRIVER is on his car.
If your IT is not good, there is no race, you wonʼt win - end of story.
But also there is another side of this Formula 1 analogy.
I have been in many meetings where business people have been called upon to make fundamental decisions re IT investments.
When presented with all the relevant facts to make that decisions, they balked at the technicality and they bail out saying ... “Sorry, I AM NOT A TECHY!”
Can you imagine Hamilton or Button making the same excuse?
To manage the business, a Senior Manager in Insurance needs to have knowledge of IT, as an F1 driver need knowledge of his car.
Since you need to be able to communicate effectively with IT, you should learn their language.
Since you need the mechanics as they need you, you need to have an appreciation of what they do.
Luois Hamilton and Janson Button do not see their mechanics as suppliers - they see them as partners.
And if you want to help a consultant to make a living, here it is a good use of his time ... ask them to make you understand how IT works and what it can do.
Simplicity ! " ultimate soph!tication
The second point that I would like to make is for the IT guys.
Leonardo da Vinci said that simplification is the ultimate sophistication - it is trivial and even self-evident, but many times forgotten.
Simplification and Standardisation drive flexibility - they are a blessing.
Whyʼs that? because you have 75 million of lines of code to look after.
Simplification: a colleague of mine recently said that “a productive day is deleting code not writing new one.”
Standardisation: adopt a standard for your products being Polaris or Accord; and be consistent and EVEN inflexible with that.
It will shorten the development cycle, reducing redundancy in code and therefore errors.
Component based pricing
Virtualisation
Geo-rating capability
Advanced anti-fraud system
Non linear under-writing
Dynamic pricing
Self-servicing web-sites
Web 2.0
Advanced UI
If you can do simplification and stardadization, then you will have time to do more innovative projects.
Remember consumer the business expectation raised by Consumer Electronics?
A simplified architecture will give you more time for doing things that make your system much more than a glorified cabinet for policies - you will have the possibility to reverse the old business perception.
Here is a list of things that I would love to talk about (maybe another time ...) READ THE LIST
We have already used computer to do things that people can do, but the real benefits will be gained when we use them for things that people cannot do.
www.kubepartnes.com
So the take away message is for business invest time in understanding IT and for IT invest money in simplifying your infrastructure
and this is an effective recipes, among others, to get a less fraught & more productive relationship between business and IT.