14 Common Project Management Mistakes
Mistake No. 12: Project Schedules Are Incomplete.
Impact: Project team members don't know what is due when, which makes completing the project on time a challenge.
Solution: Clark says a quick way to come up with a schedule for a project is to determine all the activities involved in getting the project done (e.g. scoping, getting requirements, testing and implementing) and then attaching due dates to those activities based on the deadline for the project. Project management software can also help create schedules.
Mistake No. 13: IT Doesn't Push Back on Unreasonable Deadlines.
Impact: IT sets itself up to fail and gets a reputation for not being able to deliver projects on time.
Clark says IT departments will scramble to accommodate project deadlines set by the CEO. But tampering with dependencies and with the plan only creates more problems that make delivering the project on time even more difficult, he says.
Solution: IT management has to explain to the CEO what it's going to take to meet that deadline in terms of cost and resources and has to get the CEO to choose between cost, scope and schedule, says Clark.
Mistake No. 14: They Don't Communicate Well with Project Sponsors and Stakeholders.
Impact: IT fails to deliver the expected requirements.
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."