Project Management: The 14 Most Common Mistakes IT Departments Make

Nearly 70 percent of IT projects are dogged by cost-overruns or aren't completed on schedule due to poor planning, poor communication or poor resource allocation. This story assess the impact of the 14 most common project management mistakes and offers ways IT groups can avoid them.

1 2 Page 2
Page 2 of 2

Solution: Project communications need to be catered to the audience, says Kondo. She sees misunderstandings about the scope of a project or a systems' requirements arise when IT departments hand over a spreadsheet to the business with thousands of lines describing the systems' functionality and specs. Because the business owners don't have time to look over such detailed technical documents, they ignore them.

"One side is communicating, but in a language the other side can't understand," says Kondo. "Then IT gets frustrated and they say, 'We described this to them. How come this isn't what they want?'" (Business analysts play a critical role as the liaisons between users and IT.)

Kondo recommends giving every stakeholder who will be impacted or involved in the project on the business side a high-level overview of the entire project, from design to rollout. The overview should highlight the activities that require interaction with the business and should explain why the business is needed, she says.

In general, IT needs to put more effort into educating the business about the steps involved in executing a project, says Kondo.

"If you have an open dialog about what's needed, what you're really delivering, and you have fluidity built into the process, the budget and scope becomes a dialog so if you go over budget, it's not necessarily a failure," she says.

Kondo's firm once worked with a client that was deploying a financial system and whose employees had never been involved in a large system implementation before. When design of the system was complete and Intellilink was beginning to plan for testing, Intellilink explained to the employees why testing was important.

"We told them about different kinds of testing and what they did and didn't need to be involved in. We talked about why we needed user input, what kind of input we'd need and how much time it required," says Kondo. "That gave people an idea of why it takes so long to test."

Copyright © 2008 IDG Communications, Inc.

1 2 Page 2
Page 2 of 2
Get the best of CIO ... delivered. Sign up for our FREE email newsletters!