Menu
Menu
How to predict, prevent or dump bad IT projects

How to predict, prevent or dump bad IT projects

PALM DESERT, CALIFORNIA (03/09/2004) - Just about every IT organization has had a disastrous project. The key to preventing them is to apply gut instincts and a host of hard and soft measurement techniques to catch the bad ones before millions of dollars are poured down the drain.

So said Paul Glen, a principal at C2 Consulting in Los Angeles, who addressed the issue at Computerworld's Premier 100 IT Leaders Conference here in Palm Desert, California, yesterday. Glen, who is also a Computerworld columnist, pointed to an annual study of 10,000 application development projects by The Standish Group International Inc., which found that just 28 percent of all IT projects deliver the functionality sought and come in within scope and budget. While that's still an abysmal figure, it represents a better-than-50 percent improvement over success rates tallied by West Yarmouth, Mass.-based Standish Group in the early 1990s, he said.

Glen, who is also the author of Leading Geeks: How to Manage and Lead People Who Deliver Technology, suggested four strategies to avoid disastrous projects. The first and least desirable option is to do nothing. But that isn't pragmatic, nor is it much of a career-enhancer, Glen said.

IT managers can also try to do the same project over and over. Glen said he has come across several companies that have devoted two teams to work in parallel developing the same project where the first one that's completed wins. But he acknowledged that's a "relatively expensive strategy."

Project leaders can also intervene early on. Glen pointed to a Web-based effort he had consulted on that aimed to support student development at a major university. At the first meeting, project team members dwelled on load-balancing server farms. Glen stepped in and suggested that they instead look at other project criteria and objectives, such as organizational structures and end-user requirements, to which team members "nodded politely" and moved back to their original discussion.

After three or four meetings like this, Glen intervened and told project team members that they were wasting their money on the project. "The next week, they had a vision document," he said. Glen's point: The deeper you get into a project, the harder it is to pull the plug on it.

The fourth suggestion Glen offered is to "kill bad babies," or terminate failing projects "when they're still young."

The key to all of these strategies is early disaster prevention. Fortunately, there are resource management and other tools that project managers can apply to better predict and influence project outcomes.

Here, Glen pointed to the "three P's": prescriptions, processes and power. He recommended the use of forward-looking prescriptions such as developing a formal project plan. Then there are processes that can be applied to ensure that an IT project is in sync with IT systems and business activities already in place. And while IT managers might have limited power within business units, they can certainly influence the resources allocated to projects, Glen said.

Project managers should also apply intuition to IT/business initiatives, since they know what works and what doesn't from past experiences. Moreover, they should use a set of lagging, real-time and leading indicators to help them prepare better for project outcomes, he said.

These should include preproject assessments of how project team members tend to think and how they are likely to perform during a project, said Glen.

Some of these assessments are fairly evident, he said, such as comparing the outcomes of project teams whose software developers work fairly closely to one another in cubicle farms as opposed to those who work behind closed doors.

In other instances, the organizational structure of the team itself might be counterproductive, where, for example, one project team might end up competing with another instead of cooperating, Glen said.

To help measure these indicators, he recommended both formal and informal techniques, such as regular surveys of project team members to assess their views on things such as organizational structure and project planning. In addition, focus groups and individual interviews can also help project leaders determine why projects fall apart or where processes can be approved.

Through better preparation, said Glen, "you can't avoid all project disasters, but you can avoid a lot of them."

Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!

Error: Please check your email address.

More about C2Standish Group

Show Comments

Market Place