Communication skills: Speech therapy

Click here to view original web page at www.computerweekly.com

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.

Email Alerts

Register now to receive ComputerWeekly.com IT-related news, guides and more, delivered to your inbox.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Read More

This was first published in September 2002

Leave a Reply

Your email address will not be published. Required fields are marked *