“All projects are business projects; it’s just that some have a significant IT component,” says Rick Vosila, IT director of the company formerly known as Chubb Security now operating under United Technologies ownership.
He adds, however, that so-called IT projects are probably the most common and visible type of project in most organisations, and often the most expensive, high profile and high risk.
This has driven perceptions that IT projects are a recipe for disaster, are not properly planned out or managed, and end up being over-budget, over-schedule and under-performing in terms of promised functionality.
This depressing image has been a mantra of the oft-quoted and equally oft-derided Standish Group Chaos reports. By the consulting group’s estimation, as many as two of every three IT projects fail – that is, they succumb to total failure and/or cancellation, suffer cost overruns, time overruns, or are rolled out with fewer features than expected.
Sometimes these failures have disastrous consequences beyond the extension of time and budget, and can seriously impact the continued existence of the organisation itself.
There are those who seriously doubt and argue against the methodologies used to develop the Chaos reports, but these arguments have not necessarily damped-down the poor image many IT projects have even before they kick off.
But is this image true? And what can be done to ensure project governance works toward successful project completion?
Purpose and process
Dexus Property Group recently completed its flexible working environment (FWE) project, the technology component of which came in significantly under budget and finalised more quickly than the two or three years expected.
Dexus GM for technology and operations, Clive Bailey, says FWE shares many principles with traditional activity based working (ABW) projects, but is not as rigid in its implementation. For example, people can sit at the same desk everyday if they want to.
“FWE is a functional fit-out based around the concept of creating an environment that encourages collaboration and innovation,” he explains. “People are grouped in neighbourhoods defined by their area’s storage and have access to collaborative spaces or quiet spaces, which suit their current working needs.
“Dexus senior management recognised technology was key to the success of the project. We had a technology project team that sat under the core ‘office move’ project team. The technology team supported the project’s business objectives through research, product selection and implementation.”
The underpinning of business objectives is equally significant. John Smyrk, a leading academic on project management thinking, suggests the important distinction in business terms between “output” and “outcome” is not always clear to those developing projects and management plans.
The difference can be explained through a non-IT example: A medical research project can lead to an output of a vaccine with the outcome of reduced sickness or death.
Smyrk thinks this lack of understanding is particularly common with IT projects. For Bailey, however, the distinction is not a problem.
“The difference between outputs and outcomes is always very clear to me. An example might be a system output is a management report. The outcomes are the decisions made as a result of the report,” he says. “I always focus on outcomes – the outputs are a means of achieving the outcomes.”
Other CIOs agree. Vosila’s IT management position incorporates local implementation United Technologies’ “achieving competitive excellence” program and is focused on outcomes. “It is about how the business has a different - and better - capability as a result of delivering the project successfully,” he says.
“The outputs and artefacts of the project are essential, but it’s the outcomes, such as being able to address the online market for our products so we can deploy our services globally, that truly transform a business.”
Just because there is an output doesn’t necessarily mean the project achieves the desired outcome, so the distinction is important. And this comes down to proper planning and implementation. If a project’s aim is output without consideration for the outcome, it is likely to fail.
“A project’s success is largely determined by the rigour and intensity applied at the very beginnings of the project”, Vosila says. This means ensuring the objectives are clear and agreed; the best resources are fully deployed; the scope is unambiguous; and organisational support is present and apparent to all.
While there are many variables in successfully delivering an ICT project, Joann Corcoran, deputy CIO with the Commonwealth Attorney-General’s Department, says four key criteria will help guide your project to its intended conclusion:
- A clear articulation of the benefits the program is to deliver. “This forms the basis for all the decisions and strategies put in place to deliver the project,” she says. “Without this clarity, the project will suffer, perhaps terminally. This is the holy grail of project management – remaining focused on the intended outcome from all of your hard work.”
- Knowing your timeframe, being realistic about what can be achieved and staying on track. “Understanding the implications of the amount of time you have to deliver a project guides resourcing strategies and project phasing,” Corcoran says. “Good project planning avoids unexpected bottlenecks and crisis points.”
- Understanding what can be delivered within your cost ‘envelope’. “Have well costed primary plans, fall-back plans and contingency plans on your fall-back plans. Knowing how much each approach costs helps you define scope and leaves you room to move when the unexpected happens.”
- Understanding expectations about quality. “Don’t deliver a Rolls Royce when the client is after a budget model, or vice versa.”
“If, as the project unfolds, downstream impacts such as an increased need for organisational change management become apparent, then decisions on time, effort and expectations can be more easily tackled,” Corcoran adds.