Frustrated by constantly having your infrastructure projects
shelved? Then you probably need to learn to justify the project
properly and improve the way you communicate this to the board.
Karl Cushing reports
All too often IT professionals fail to give the presentation of a
new project proposal to the board the attention it deserves,
resulting in projects being stalled, not receiving the necessary
funding or even not getting done at all. This is particularly true
of infrastructure projects.
A key problem is the difference in outlook and metrics - what an IT
professional thinks is vital a businessman might see as peripheral,
and the two are often to be found singing from different hymn
sheets. Justifying a project when there is a strong financial
reason is one thing - cash is the metric that is most readily
understood and willingly received. The problem comes when there are
other reasons for doing a project, which is usually the case with
an infrastructure project or a software upgrade.
"For infrastructure projects you need to be clear what the ultimate
business goal is," says Sharm Manwani, member of the faculty of
information management at Henley Management College and also a
former IT director. "Every major IT investment is a business
decision - you've just got to be smarter in the way in which you
link it to a business case. You have to think as the business
thinks. Work out where it will really add value, try to follow the
argument through, get the stakeholders on-side and see the bigger
picture," he says.
However, Manwani stresses that the way you go about justifying the
project should depend on the culture of the organisation.
Broadly speaking there are three types, he says. Some organisations
are centred on financial control and will be looking for a strong
financial justification, while at the other extreme are the
organisations focused on strategic planning - the ones that will be
more receptive to arguments based on elements such as improved
communication.
In between are the organisations focused on "strategic control",
says Manwani, which will be looking for a mix of the two.
"Culturally, it's important to be aware of where the organisation
is sitting," he says. If all that fails, try tying an IT
infrastructure project into a more return on investment-friendly
one to make it easier to justify."
The problem is not just that infrastructure projects are seen as
"unsexy" by the business side. Often there appears to be no clear
financial benefit in doing them and the short-term costs are
usually high. However, they still need to be done - or at least
this is what the IT professionals will think.
From the business side, it may well seem like another example of
the ITers putting something in for the sake of it and hitting them
in the pocket in the process. It can often seem like a case of the
emperor's new clothes, with IT doing something that makes no
noticeable difference except for the big bill. As Ovum analyst Gary
Barnett says, "The problem is that IT infrastructure, when it is
working, is invisible."
In such instances, formulating a strong project justification case
can be hard and deserves much more attention than it often
receives. Time for the transformation into IT evangelist-cum-super
salesman. Basically, the trick with infrastructure projects is to
explain to the business why it needs to do them and weave solid
reasons into a strong business case. A common ploy is to spell out
the consequences of failing to undertake a project or embrace
change.
"With infrastructure you're buying options and choice," says
Christopher Young, managing director of the Impact Programme, a
mentoring programme for IT professionals. "If you want the option
of doing 'x' in the future you will have to do 'y' today - that is
the benefit. Being able to communicate that in a powerful way is
very important," he says.
This is one of the things that the mentors at Impact focus on -
instilling the need to communicate effectively and justify actions
to the board. "You can develop these skills comparatively quickly,"
says Young. If the board says no, try to find out why and set about
removing those objections one by one, he says. If necessary be
ready to offer cheaper alternatives.
Unfortunately, most senior IT professionals do not enjoy a strong
relationship with the business, says Robina Chatham, who teaches a
course on organisational politics and IT management at Cranfield
School of Management. They tend to lack leadership qualities and
people skills, which becomes a serious problem in cases such as
these where "the ultimate aim is to make the end result seem like a
business and not an IT decision", she says.
Another problem is more historical. "Most businesses feel they
don't get value for money from their IT department and when they
are asked for money there's a reluctance to give it," says Chatham.
All too often the board will feel that it has been "whitewashed" in
the past by the IT department and will be suspicious of them, she
says.
So Chatham emphasises the importance of building a good reputation
with the business side and earning a reputation for delivering
value. The idea is simple enough - if the board trusts you it will
be more inclined to accept your reasoning and provide funding
without going too deeply into the technical ins and outs.
Building a good reputation on the business side takes time,
however. IT directors - especially those who accept a "poisoned
chalice" and go into an IT department that is failing and generally
held in low esteem by the business - should first concentrate on
achieving some easy wins and getting their most vociferous
opponents on their side, says Chatham. "Target your worst enemies,
as it were," she says.
However, the idea of going for easy wins is not without its
pitfalls. Simon Ratcliffe, a consultant at Business Systems Group,
believes there is a serious problem related to the high turnover
among senior IT staff, with new IT managers coming into a company
and wanting to make changes straight away in order to get some
quick wins and make their mark.
According to Ratcliffe, too often the result is that the same bits
get changed all the time and some are never touched - especially
those with an element of risk attached. "Not all change is good,"
says Ratcliffe, although he adds, "If you never take risks you
never progress."
He recommends that the IT side goes to the business first to see
what it wants before coming up with a plan for a project, which
should ultimately be "a technical design based on business
objectives", says Ratcliffe. The important thing is to find out
what the board wants out of the business, where it sees the
business going and what it wants IT to deliver. This will help to
get buy-in immediately, says Ratcliffe. "You'll be able to put a
business measurement next to the cost," he says. If, later on, the
board balks at the price tag the IT department will be in a far
better position to justify the expenditure.
Ultimately, however, Ratcliffe is on the side of the business in
the idea that IT projects should add value and improve efficiency
or they should not be allowed to go beyond the discussion stage.
"Infrastructure projects can add value," he says. All IT projects
should be seen as an opportunity to realign the business and
business processes. "It's all about business efficiency - making
sure that the technology is aligned more efficiently with the
business," he says.
Another option is to employ the services of a third party, such as
a consultancy that can act as a broker between the business and IT
camps and find out what the business wants to do, what it wants to
achieve and what it wants to change or keep, says Barnett.
"They can help to mitigate the risk," he says. IT departments need
to factor in the business at all levels of a project, especially
when relatively new areas such as Web services are involved, he
says. "The best and most sought-after IT managers will do this very
well."
The aim is to build a real sense of commitment, shared goals and
trust and make the business more willing to take risks and back
projects that have a long-term vision, instead of gunning for quick
wins, says Barnett.
Whatever you decide - whether you employ a third party, tie
infrastructure projects in with other IT projects, build a
reputation for delivering value or focus on developing your
communication and people skills - the key is to "put the business
on every agenda", he says. Adopt its language, assume its ways and
concentrate on building bridges instead of walls. And don't be
afraid to make the first move. IT departments, like good IT
managers, need to become proactive instead of reactive. A bit of
effort made now could pay major dividends down the line.
Building the business into the IT strategy
Ovum analyst
Gary Barnett's tips:
- Put the business on every agenda
- Remember, there is no such thing as a solution in a box
- Develop a strategy that serves both the builders and the users
of the system
- Find partners who can accelerate change, reduce risk and
increase confidence
- Try to use business language and do not be too techie - the
business will be impressed that you are making an effort.
Seven steps to securing board funding
Robina Chatham,
from Cranfield School of Management, offers these tips on
justifying IT projects and getting board funding.
- Build a positive reputation in the business and develop a track
record of delivering value
- Be in tune with the business and see "the bigger picture"
- Explain, in simple terms, why the project will cost so much and
where the money will go
- Use analogies to simplify technical points or particularly
tricky concepts
- Give the board options: for example, cheaper alternatives with
less functionality
- Explain the importance of accounting for future flexibility and
the consequences of not doing a project, as well as the
consequences of doing it
- New IT directors should try to get some "easy wins" under their
belts early on and try to win round their most vociferous opponents
on the business side.
Lessons in business dialect
Language to use when
drafting project-related documentation and presenting ideas to the
board:
- Be brief and stick to the point
- Break up long chunks of written text
- Use appropriate language for your audience
- Avoid rambling off on extended acronym and jargon-fuelled
tangents
- If you must use jargon, make sure it is business, not
technical, jargon
- If you are unsure about it, try your "pitch" out on a
non-techie before going to the board.