• Marketing Manager
• Project Manager - Permanent...
• Calling All C++ & AI Game...
• Senior Desktop...
• ACCOUNT MANAGER

Tears before project management bedtime

Peter Davidson, Information Age

18/08/2005 14:54:54

According to two Sydney-based project analysts, more than 70 per cent of all ICT projects end in tears.

Their findings from a searching analysis of a long catalogue of local and overseas projects show that only 30 per cent of them succeeded by some measure (only 20 per cent provided "satisfaction") half didn't meet design, budget or completion specs and 20 per cent were abandoned entirely.

Independent consultant John Murphy and IP lawyer Rob Sanders set out to isolate the factors which bring down projects to develop a methodology to assess a project's prospects for success at critical stages of its development.

They have distilled a checklist of key criteria, weighted according to their priority and impact on the project, drawn from their own experience in managing or rehabilitating projects, and from a careful analysis of properly documented post mortems of others, particularly in Australia's public sector.

These key criteria, and number of other "mini-criteria" have allowed them to develop a 100-point scoresheet against which a project - and its managers - is audited once it has begun, but preferably before "serious money" has been spent.

"The checklist is comprised of empirical data we have been able to extract from our analyses, overlaid on commonly agreed criteria for assessing project performance. We have injected some elements gained in our combined 40 years of project management experience, but essentially we have isolated the factors which, time and again, mean success or failure." Murphy says.

The audit is a combination of independent review to identify the presence and welfare of key project indicators - or their absence, and a "self-audit" by the project team which must cite evidence before "scoring" an indicator.

The two audits are then overlaid to produce a customised report for the project. The process calls for briefings by senior management and interviews with the project's management, and its end users, over about a week.

The methodology has been subjected to formal proof of concept using historical data from project scenarios and road-tested by its authors on a current suite of projects. They claim successful identification of key issues which can derail a project, verified by post-mortem analyses of some spectacularly failed ICT implementations.

They are seeking further POC opportunities with Australian companies before commercial launch of their methodology.

Murphy found no lack of documented cases on which to base their tests, citing among others the $65m Centrelink/Department of Family and Community Services Edge project and RMIT's $50m Academic Management System.

Get users on side early Failure to get user support is the primary destroyer, Murphy says, generating resistance to change through misunderstanding and even outright sabotage by factional interests within the organisation.

"Technology does not kill a project, and project management is seldom to blame - the biggest make or break factors are the ways in which the project is hosted, organised or regarded within its own organisation," he says.

"That doesn't let project managers off the hook however; they are still responsible for alerting the organisation to a project's weaknesses. The trick is to recognise those flaws, most of which lurk out there on the workplace floor.

"All projects are political in the sense that they have their supporters, the 'don't cares' and those that hope for failure for whatever reason."

As such, the Murphy/Sanders process is as much an exercise in psychology and the teasing out of societal factors, as project teams often lack the marketing and sales acumen needed to get all stakeholders on side by getting their appreciation of the value of a project.

"Project teams compensate by adding more technology - and it only makes things worse.

"Many projects are difficult to get started; they require imagination, courage, persistence and a degree of insubordination. Our work starts when an idea has gained some shape, when management decides what time and funding it needs, and sign it off for preliminary development.

"It is better to let a project get to some level (however chaotically) where serious money or commitment is required, and then examine its chances and what resources it needs to go all the way. And killing off projects is only marginally easier than starting them in the first place.

"Complete deconstruction of a project is a good idea only for the consultants brought in to assess its viability - not for the host organisation. It's analogous to fixing a car - the garage does not dismantle the vehicle, it applies a series of valid diagnostics and experience to isolate the problem and fix it."

This examination is best done externally he avers: "Very few internal people are disinterested enough to assess projects effectively and quickly become immersed in peripheral issues which cloud wider vision and judgements.

"That's where our self-audit is useful - it requires team members to write down answers to our questionnaire and prioritise them. From that we can do a 'gap analysis' to see what critical factors are missing, or if there, may be misaligned.

"And if the project team itself is negatively inclined towards the task, that can be divined from the audit and course corrections made. It can be dangerous to assume that those managing a project are fully behind it."

He stresses that their methodology is to diagnose a project's prospects for success, not to make expert recommendations on technology: "ICT people know what kit is needed to do a job - it's how the business plan has been framed, and if the path to the solution has been properly mapped whether everyone along the road is cheering things on."

Protecting IP Sanders' involvement as an IP lawyer is crucial to the project team's analysis of ownership issues: if a software component of a project requires amendments, is that done internally or by the software vendor? Does this create new IP or does it contravene ownership of the original property?

"It goes all the way from 'who is in fact controlling the project?' to 'do we own enough of it to sell it - or sue anyone who steals it?'

"Our methodology addresses a number of vital questions over ownership, both legal and managerial, and these issues have to be clarified earlier enough to avoid expensive mistakes through assumptions based on ignorance of an increasingly complex area."

Further information at john@jjmurphy.com.au