Each week, project management veteran Tom Mochal provides valuable advice about how to plan and manage projects. Tom first describes a common problem scenario, based on real-life situations. He then offers a solution, using practical project management practices and techniques.

The dilemma
James and I recently discussed the status on his project to install document management software for the legal department. The project seemed to have been proceeding smoothly over the past few weeks, but then James uncovered a problem during testing.

“The document management software doesn’t interface well with one of our existing legacy systems, which is causing the legacy system to lock up on a regular basis,” he explained.

“What kind of feedback have you been getting from the team members doing the testing?” I asked.

“That’s the frustrating part,” James said. “I’ve been getting periodic updates from them, and they never mentioned this problem. The team said they thought they could resolve the problem on their own.”

“Have you notified your customers?” I asked.

James’ anger was evident as he explained that the customers already knew about the problem. “Since they were helping test the old system, they were the ones who discovered the problem.”

I pointed out to James that many technical people are natural problem solvers. They probably thought they could resolve this on their own. They also may have felt that raising an issue would have generated scrutiny of their work. They don’t always understand that issues management raises the visibility of a problem so that it can be resolved quickly.

“You’re right,” James agreed. “Two weeks ago, we probably could have resolved this and still met our project timeline. Now fixing the problem may cause the project end date to slip.”

Mentor advice
To resolve a project problem successfully, the entire team needs to understand that they’re all a part of the process. One of their primary responsibilities is to raise issues when they see them. Raising an issue should not be viewed as a negative event but as a proactive way to bring a problem to the surface so that the manager and project team can apply appropriate resources, find alternative solutions, and implement a resolution.

On James’ project, team members discovered a problem and thought they could resolve it on their own. And although this is an admirable first step, they should have raised this problem to James after their initial attempts at resolution failed. If James had an idea for resolution at that point, there would have been no need to raise the problem to issue status. If his ideas didn’t work, however, the problem should then have been raised as a formal issue, which would have invoked a proactive issue-management process. Since a third-party package was involved, however, the problem may not have been within the control of the team to resolve.

If James and his team had raised the problem as an issue, they could have identified options for resolution, suggested workarounds, or agreed with the sponsor to changes in project scope that would make the issue irrelevant. Of course, all of those options are still available now. However, since the issue was raised so late, the resolution may also require a slippage of the committed end date.

Project management veteran Tom Mochal is director of internal development at a software company in Atlanta. Most recently, he worked for the Coca-Cola Company, where he was responsible for deploying, training, and coaching the IS division on project management and life-cycle skills. He’s also worked for Eastman Kodak and Cap Gemini America, and has developed a project management methodology called TenStep.

Tell us about them. Tom Mochal will answer those that affect the widest number of readers. Post a comment below or send us a note.