By Tom Mochal

What do you do when an IS department doesn’t have a project management method in place? How about when a project is missing a business driver? Or when a lagging project has a list of issues a mile long?

These kinds of issues seem to pop up every day in the life of IT pros with project management responsibilities. To help them along, I offer my advice and, hopefully, some short-term solutions, as well as troubleshoot the big issues.

“We don’t do projects here”
As the newly appointed project management mentor for the Blue Sky Manufacturing Company, I work with many project managers—some very experienced and some brand new. I was asked to talk with Juan Martinez about an upcoming project. Juan works in the information infrastructure department and was just beginning to lead an effort to upgrade the company phone mail system. He said this effort would take nine months and cost more than $350,000.There would be six people involved, although not all full time.

When I met with Juan for the first time, he was a little confused. “I thought you were the project management mentor,” he said. “I’m not sure if there’s anything you can help me with.”

I was initially taken aback. “So, you sound like an experienced project manager.”

“Project manager?” Juan questioned. “We don’t do projects in this department. We just go ahead and get the work done.”

This is going to be a tough one, I thought. Not only is Juan an inexperienced project manager, he doesn’t even know that he is a project manager!
Projects are not something that only certain departments do. Projects are a way to get work done. They have start and end dates, common objectives, a specific set of deliverables, a defined scope, a project team, and always a project manager. How many times have major initiatives failed because they weren’t organized and managed as projects? Many, many times. Juan wants to “just get the work done.” I know he’ll have a much better chance of success if he defines, structures, and manages the work as a project. When I meet with him next, the education process will begin.
Updating the project definition before each major phase
I was talking recently with Donna Morgan, the PM on a large marketing information database project that was just beginning a major new phase. Donna is hard working and conscientious, and knows the importance of maintaining alignment with business needs and priorities.

When she came to me, Donna was concerned. Work on the next project phase needed to begin right away, but she wasn’t sure the business client was fully involved. The original sponsor had been reassigned, and she hadn’t met the new manager.

In today’s rapidly changing business environment, it’s common to experience turnover of key project resources. That’s one reason it makes sense to break large projects down into phases, each of which can be managed as an individual project. In fact, this was the approach Donna was using on her project.

Donna had a completed project definition document, but it was written and approved seven months earlier.

Now I saw the potential problem, and the cause for Donna’s concern. The project definition document shouldn’t be thought of as a one-time exercise. For large projects, it should be updated at the beginning of each phase. The charter should be updated based on the reality that exists today, and taking into account what has been learned on the project so far. This has a number of advantages. First, it allows the PM and customer to revalidate the project objectives, deliverables, scope, estimates, assumptions, and risks. It also refocuses the business customers and the project team on the new work about to be undertaken. Of particular benefit to Donna, updating the charter is also a way to revalidate business sponsorship and ensure that the entire organization is committed to this next major work effort.
I advised Donna to not let the project continue based on its prior momentum. This was the time to revalidate business involvement and ownership, and refocus the team. The worst thing that could happen would be for the project to continue without business engagement, and then have to redo much of the work later on, or worse, have the project cancelled later because of the lack of sponsorship.
Focusing on real project issues
Sam Murphy is the project manager on a major initiative to install a new release of the company’s financial software package. Sam said the project was full of ”opportunities.” Of course, I knew the code word. The project was having problems.

“I think I can manage issues with the best of them,” Sam remarked, “but how can a person effectively manage issues when they are coming up every day? My issues log must have 20 outstanding problems on it now.”

I thought about what Sam was saying and it just didn’t sound right. Problems arise on a project all the time. Most of them come up and are soon resolved. These are not “issues.” An issue is a big problem—one that has the potential to cause the project to be disrupted or to fail. If they were true issues, the project should probably be stopped right now, since there is a high probability of failure.

I reviewed Sam’s issues log and my initial suspicion was correct. These were not all “issues.” The first item was a note that a team member needed to upgrade their computer RAM. I asked if this was a major problem. Sam said that it was, since the team member was having poor response time. I asked if this was going to jeopardize the success of the project. Sam said that it wouldn’t.

“Great,” I said, “I just removed one of your issues. Put this item on your work plan instead.”

The second item referred to the price of airline tickets to visit a customer site. I again asked if this would jeopardize the success of the project. He said it would not. In the worst case, the ticket price could cause him to go slightly over budget.

“I have just removed another one of your issues.” I said. “Identify this as a budget risk.”

Sam was beginning to understand. This project was just encountering the types of problems that come up and are resolved every day. The next day when I saw Sam, the issues log was reduced from twenty items to one. Since all the non-issues no longer obscured this problem, proper focus could get it resolved.
Issues are major problems that will jeopardize the success of the project. They are problems not totally within the control of the project team to resolve, and may require outside help from managers and sponsors. Because of their magnitude, project managers shouldn’t expect to deal with more than a couple at any given time.

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 project management and life cycle skills to the IS division. He’s also worked for Eastman Kodak and Cap Gemini America, and has developed a project management methodology called TenStep.

Got a project management nightmare? Looking for a solution? Send us a note with the details. Tom may consider it for an upcoming column.