Avoiding IT project disasters

“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.

Page Break

The ‘key’ criteria?

The triumvirate of criteria – time, budget, scope – are not always as clear cut or as exclusive as some might think.

Smyrk, who consults to industry through Sigma Management Science and is a Visiting Fellow in the Business School at Sydney University, recently co-authored a book with the Australian National University’s Ofer Zwikael on the subject, Project Management for the Creation of Organisational Value.

Classic elements of what he calls the ‘iron triangle’ are often used as the measures of the success of a project, but there may be end effects that are “unexpected, unacceptable and avoidable”. Smyrk calls these “detrimental outcomes”.

As an example, he cites a project manager who fulfils his project triangle, but in doing so puts his team under so much pressure that key technical staff resign towards the end of the project.

“If the loss of staff was considered a detrimental outcome, the conclusion is that the iron triangle fails as a test of project management success, because it ignores those detrimental outcomes that can be attributed to the management of the project,” Smyrk explains.

This then leads to a ‘steel tetrahedron’ – scope/quality, timeframe, cost and ‘acceptable’ detrimental outcomes (collateral damage in the military).

“Even if the project meets these four criteria, but doesn’t give the investment return expected, then it is an ‘investment failure’,” he continues. “It must be a project ownership failure and the project owner would be regarded as also failing”.

An example is the Cross City Tunnel in Sydney, which achieved the criteria for project success, but then failed to meet the investment criteria: 30,000 cars per day out of the CBD rather than the targeted 90,000. That the Tunnel was a project management success was of little comfort.

Increases in time and cost do not necessarily imply a project ‘blowout’, Smyrk says, if this has been accepted as a possible scenario and funded accordingly. “If a situation had not been identified, then the timeframe and budget have certainly been blown, but even this does not imply a failure of project management unless it can be shown that such a risk should have been identified.”

The customers

Regular communication with customers or end users is regarded as essential in the project governance mix. “The importance of this is often largely underestimated and is a main contributor to why projects are continually delayed, or not well adopted or accepted by the user community,” Corcoran says.

“Where possible, you should try to develop an implementation/delivery program to roll-out functionality incrementally, to bring users along with you on the journey, build acceptance and try to address some of their issues early in the piece. This is particularly important for projects attempting to address productivity and usability issues.

“At some point, a CIO needs to consider when any additional functionality that comes with a new technology should be implemented, taking into account their understanding of the impact on, and readiness of, the users of the system.

“If you foster a good working relationship, you should be able to ride out any bumps in the road that inevitably occur during big projects.”

Bailey agrees on the need for communication. “As I’ve heard it said, a stakeholder is someone who can put a stake in the ground or they can drive a stake through you. Ignore stakeholders at your peril.”

But letting customers and end users loose on the design and running of the project can be fraught with frustration. For Smyrk, customers should participate in the discussion of project scope but not define it.

“Project customers – those who generate outcomes through their use of the project’s outputs – are clearly critical stakeholders in a project. If they do not utilise the project’s outputs, then the project cannot generate its target outcomes,” he says.

A long-held view of project customers leads to the conclusion they have a dominant role in defining the project’s scope and specifying its outputs, but Smyrk warns this assumption and approach is naive.

“Any methodology which seeks to scope a project by asking customers to identify outputs is invalid because it involves circular reasoning,” he claims.

“The customers become known only after outputs are identified, not before. In other words, outputs identify project customers, not the other way around.”

That doesn’t mean customers are irrelevant. “Customers should be involved in scoping, but only to identify certain fitness-for-purpose features that proposed outputs must have so they can be utilised successfully.

“In other words, customers have an important role in constraining the project’s scope, but limited role in setting scope. In general, any congruence of views about the project between the funder and a customer is fortuitous.

In many cases, customers are negatively impacted by a project or will have objectives that conflict with those of the funder, so considerable care must be exercised when accommodating their views about desirable and undesirable features of outputs.”

Corcoran adds a caveat in dealing with customer expectations. “IT has become such an enabler for our everyday lives that we often forget there are limitations to it – either direct technological limitations or those we impose upon ourselves in the interest of system optimisation, security or cost,” he says.

“There is a lot which goes behind making something seem simple. This is not always well understood. This can be a real cause of dissatisfaction between the system developers and the client/users.”

Page Break

The people

Whether executive champion or project implementation manager, everyone needs to be involved, communicated with and, where appropriate, managed with anticipated outcomes firmly fixed in mind. Project management is key in this process.

According to Vosila, an excellent project manager has command over both the science of project management (such as PMBOK, Gantt, scheduling, task management and documentation), as well as the art (collaboration, negotiation, mediation and ‘solutioneering’).

“For me, it’s the art component that makes or breaks a successful project,” he says. “It is imperative senior business leaders put significant skin in the game in such projects by assuming project sponsor, champion and manager roles – and through this, accountability.

“Non-IT business leaders often don’t have the necessary project management skills to ensure the success of complex projects, which is why I resource such projects with a professional IT project manager to shadow the business project manager, assisting and guiding them through a successful methodology."

Central to this core of personnel are IT people, regardless of whether the project is characterised as “business” or “IT”. Corcoran says every project should consciously consider an ICT interface, and have a commensurate level of engagement with ICT providers.

“Technology has become so intrinsic in our business and private lives that there would be a shrinking pool of projects which would not ‘touch’ ICT,” he says.

“Poor, limited or late engagement with clients in these situations represents a real risk. Where policies or work programs develop in isolation from ICT specialists, or engagement occurs too late in the process, situations arise where individuals have become wedded to particular solutions which may not fit the operating environment of the organisation. Delays, cost blow-outs, or basic project failure can easily arise.”

But Vosila gives a word of warning: Organisations whose projects fail to meet success criteria have often done so because they lack the right skill sets “In these cases, the organisations have tended not to resource projects with the ‘staff you can least afford to assign to the project’, which is what I strongly advocate,” he says.

“It’s these staff who will drive home a successful project. And guess what… the organisation will not fold if some of your key people are working full-time on an important business initiative for six months. The cemetery is full of indispensable people.” And full of well-intentioned projects too.

Anatomy of a successful project

Dexus recently completed a project encompassing their own breed of activity based working known as “flexible working environment” (FWE). The technology component came in under budget and well within standard timeframes for such a project.

GM for technology and operations, Clive Bailey, says the team had a number of drivers including hard deadlines, budget and outcomes, which tightly framed the project. “They were challenging at times, but we were able to find practical and creative ways around every issue that cropped up.”

Here, he lays out the criteria used:

Preparation was vital to success. This involved thorough research, product selection and testing, piloting of products and eventual training and then rollout to the entire business.

Good communication was required to ensure an easy transition. This was managed by the project’s steering committee with regular project updates to staff and feedback from them as the project progressed.

Buy-in was needed at every level. “Everyone needed to understand what we were trying to do and why, which included management and staff,” Bailey says. “Buy-in was important to ensure we were prepared for the move and to get commitment to a new way of working once we moved.

Clear goals were in place. The CEO was clear about the vision and goals for the project and this framed all thinking and outcomes.

Metrics were paramount. “There were a number of hard metrics set like seating and workstation ratios, storage reduction, energy reduction and a NABERS fit-out rating target,” he says.

“Soft metrics such as improved collaboration and communication, a place where people want to work and greater engagement between our employees, tenants and investors are harder to measure but we are already seeing significant improvements in these areas and future surveys will validate this assumption.”

The success of the project was predicated on coming up with a clear vision for success. “For this project to be successful I want my business colleagues to have only one decision to make on the morning that they come into the new office space – ‘Which desk am I going to sit at today?’,” Bailey says.

“My rationale behind this statement was that there would be no surprises for anyone in the new office space, at least from a technology perspective. This meant we would have to research, test, pilot and deploy all the new technologies to everyone before we moved into the new premises.”

11 signs your IT project is doomed

1. The project has launched without senior buy-in
2. No detailed project plan exists
3. Meetings have been scheduled without concern for team member availability
4. Users have had little or no early involvement
5. The project targets the minimum specs
6. Testing is an afterthought
7. No recovery plan is in place in the event of failure
8. Expert recommendations have been rebuffed without testing outcomes
9. The go-live date is a weekend or holiday
10. Expectations have not been set
11. Training is an afterthought