Managing Information Strategies (www.misweb.com)
Cooking with gas: How to make your I.T. projects sizzle
There’s a quiet revolt underway in IT shops across the
land. CIOs are standing up to be counted, or rather to not be counted. After more
than a year of unprecedented scrutiny by other members of the management team,
IT is again flexing some muscle. The coming battleground is over the arcane
territory of ‘investment metrics’, the vanguard of a decade-long push to define
the value IT delivers to the business. These are tools IT adopted willingly
in the 1990s, to evaluate new strategic IS initiatives and in the acceptance of
It’s possible to become over-simplistic when talking about managing successful IT projects. CIOs are fed a healthy dose of project success and failure stories in magazines and on vendor conference circuits. The frustrating thing for attendees at such events is they know things aren’t always that simple.
From talking to CIOs in various industries, the main constant is difference. A CIO can watch an IT executive from a different organisation explain the intricacies of their e-business revolution and be left thinking, ‘well it sounds good, but it would never work here with our CEO’.
Taking the point that individual personalities within organisations can play a big part in the success of any initiative, MIS Australia spoke to four leading CIOs and two industry analysts to discuss the elements that must exist in the recipe to produce a worthwhile project. This includes how decisions are taken within their organisations when looking at selection, purchasing and deployment of new technologies and processes.
Speaking broadly, there are two types of projects in most organisations: technical infrastructure development and enterprise wide, business process changing initiatives. In many ways, the approach to purchasing decisions in the former is a lot simpler from the CIO’s perspective.
Ingredients for success
“Personally I have never seen a project or initiative fail that has these characteristics,” says David Boyles, chief operations officer, ANZ Banking Group:
Fairfax general manager of IT Linda Price says the recent acquisition of a storage area network (SAN) was handled entirely within the IT department. No cross-departmental meetings were required because no one else really cares about the backbone of the systems.
“However, in an enterprise-wide project, it must start with the development of a sound business case with a business sponsor who is going to drive it hard,” says Price. “We have a gentleman in our pre-press department looking for standardisation across the group; it is very high on his agenda and he is driving it hard so it is a delight to work on.”
Price says at Fairfax, part of the business case for any acquisition she authorises must be an explanation in a standardised template, and includes specific details about how processes will change as a result of the project, what the business benefits and return on investment (ROI) will be and what the actual investment is. All related costs are predicted early.
State the business case
At Colonial First State, CIO Tony Clasquin says there are very few projects that can be called ‘IT projects’ – all projects require a business case and are tabled at the general managers’ (GM) meeting. He believes it doesn’t matter which department wants to undertake the initiative, all departments are involved at the GM level to create a supportive environment.
“We cancel all projects that aren’t sponsored by the GMs, it’s that simple,” says Clasquin. “It is so important to get the sponsorship that if we don’t find someone who is willing to sponsor it, then it is the wrong project for the company. If it is not important enough to inspire support, it is not important enough to run.”
Projects at Colonial First State are then approved in a series of stages. They can start simply as a word of mouth request to the GM who then gives approval to develop a business case. Clasquin believes the approachable nature of the GM negates the wasting of resources in developing business cases for projects that would quite easily have been ruled out at an initial verbal stage. If the business case is approved, it is prioritised and commenced.
Clasquin’s colleagues from the business units work out what they want to do functionally and it is given a score based on how it matches commercial outcomes. The technology unit then assesses the architectural fit and resilience. The project sponsor from the relevant department then has to make the purchasing decision based on the counsel of the others involved.
“Vendors are made to pitch to everyone at the same time so we get a truthful viewpoint,” says Clasquin. “If you get a vendor speaking to various members of the company, you will get three or four different stories. They will tell the business how simple the technology is and when it doesn’t turn out that way it is the IT department that gets the tough questions...IT will discount some products that we can’t technically support or back-up, but if there are a few left, then it is the project sponsor’s final choice.”
Don’t act in isolation
ClickStream managing director Rainer Runge says many organisations still mistakenly expect their IT directors to make all decisions related to technology in almost isolation. He says IT directors are not equipped to do so if a business expects any coordination between overall strategy and technology planning. He cites examples where companies have run IT projects improving efficiency to require fewer staff and when the project is finished, the business units have not wanted to cut headcount in the first place, rendering the whole process futile.
“I have seen many organisations where the CIO’s active role is in pursuing the business and asking where they can work with them and add value. In those cases, the CIO finds themselves in more of a business development role … they need to get on to the right steering committees and tie the project into goals that other departments want to help them achieve,” says
|CLICKSTREAM'S BEST PRACTICE I.T. DECISION FLOW||
This collaborative approach to a project is one of a number of points ANZ Banking Group’s COO David Boyles, insists are the staple of a successful project. Boyles says successful projects share common requirements, largely based upon the people involved.
Vendor selection comes down to Boyle’s rubber stamp, although he has many systems engineers and procurement specialists who meet with vendors and provide recommendations. He agrees sponsorship is important for a project to gain credibility and momentum within the organisation.
He says there are certain areas such as enterprise resource planning (ERP) and information security, where the benefits are often company-wide and IT simply has to go it alone as individual departments are unwilling to take on the expense.
ANZ’s intranet, referred to as MAX, was one such example where the IT team put together a plan but could find no one in the business to sponsor the initiative. They eventually went to the CEO and were granted a budget.
“We couldn’t promise revenues out of it but could say indirectly there would be returns from having improved knowledge of the company. If you look at MAX today, we have hundreds of business applications running [off it],” says Boyles.
“The problem with IT projects is like the John F Kennedy saying: ‘Victory has a thousand fathers, but defeat is an orphan’. When a project goes well you don’t hear too much about it and the business marches on. If something goes wrong it is much better if there has been clear sponsorship so you can assess it instead of just blaming it on IT problems.”
With projects encompassing more than just the CIO and their direct reports, it’s important to maintain clarity about responsibility. ANZ simply publishes it on MAX. With the issue of sponsorship clearly high on the agenda, it is interesting to look at the key responsibilities of a project sponsor as defined by ANZ as it can obviously apply elsewhere. Key project sponsor responsibilities include:
The documenting of expectations and responsibilities may sound time-consuming
and laborious but it is a worthwhile exercise, according to Tethys Consulting’s
principal Bronwyn Evans.
She advocates the creation of a ‘case for action’ before anything is actually underway. This is similar in theory to a detailed ROI calculation but, says Evans, works around the scepticism felt in many organisations towards such documents.
“In many companies, it is still unlikely that people go back and check an initial ROI calculation once the project is implemented to find out if it was achieved,” says Evans. “A case for action document is more like a sales document – it’s visual so it can be distributed throughout the organisation and is a good way to mobilise the organisation in support of the project.”
Evans says the document must contain a realistic description of risks to be expected in a project. For example, an ERP implementation is going to bring about significant process changes, so preparing upfront for staff resistance to change means the technical aspects can be focused on without problems coming up seemingly from nowhere.
Without fail, every CIO spoken to about the ideal approach to running projects of any kind talks of the importance of both the wide reaching transparency of actions and the continued involvement from areas of the business other than IT to enable successful change management. This is something that can begin well and then trail off as a project gets underway.
According to Evans, there are warning signs to alert CIOs to the fact the company-wide interest is flagging, such as the newsletter and staff briefings becoming less frequent due to people being too busy. This can lead to people feeling either apathetic or even angry about being excluded.
Keeping a project in the company consciousness and keeping it relevant is something Linda Price pays great attention to at Fairfax.
“You want people involved but you have to make people feel like their involvement is worthwhile,” says Price. “There is no use having project meetings that go on ad infinitum with people sitting there wondering why the hell they have to be there. That is the best way to piss people off and have them not turn up again.”
Price says the simple solution is to keep project meetings on a strict agenda and ensure they are fast-paced. It is also unnecessary to pack every meeting with everyone involved in the project, a little thought before-hand about who really needs to be there can save everyone significant time.
Change and transition
The issue of change management is obviously a big one that can be the subject of books in itself but in the context of project process one point that really must not be forgotten is the transition from project to operation.
“You can go through the perfect project, sort out the change management and deliver it stunningly on time and on budget, but if the ultimate way of operating the system hasn’t been well thought through and allowed to move smoothly into an operational phase, you end up retaining staff from a project for much longer than you should,” says University of Queensland’s director of IT services Nick Tate.
He says the manner in which a project transitions into an operational activity is one of the great measures of how successful a project has been. Finishing on time and on budget is obviously important but Tate says there can be a tendency for organisations to believe a project is over once it has been switched on.
“Poor transition is averted if you get the funding right at the start,” says Tate. “You have problems where people say ‘here is x dollars for the project’ and, as all good projects should, it comes to an end and the x dollars come to an end as well. People haven’t budgeted for the fact that it now requires y dollars a month to keep it running.”
With the post-project analysis, it also helps to have put the plans in place right at the beginning. Clasquin echoes Tate’s sentiment, warning against the propensity to get blasé once a piece of technology has been implemented. He says a post-implementation review must take place about six months after the project is supposedly finished.
As with anything involving variables centred on human interaction, a technology initiative cannot be an exact science. Tony Clasquin observes that a surgeon can perform a theoretically successful operation and still see the patient die because of external factors. From an IT perspective, controlling those external factors is the best way of monitoring and cutting down their risk.
Making sure everyone affected by a project is involved throughout is by far the simplest way of doing so.
This story was found at:
All material on this site is Copyright. Any unauthorised copying or mirroring is prohibited.
(c) 2001 Fairfax