Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Avoiding IT project disasters

Tim Mendham | Aug. 13, 2013
Your initiatives are often the most expensive, high profile and high risk.

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

 

Previous Page  1  2  3  4  5  6  Next Page 

Sign up for CIO Asia eNewsletters.