By Tom Mochal
When is just doing the work not enough to make sure a project is a success? Is there such a thing as too much planning? And what should you do when a key player might be unavailable to work on an important project? Here’s some guidance for tackling these everyday issues in the life of a project manager.
First plan; then do
Juan works in the information infrastructure department of a large manufacturing company and is leading an effort to upgrade the company phone mail system. A reluctant project manager, Juan thinks the best course of action is to not worry about project management but instead to “just get the work done.”
I recently asked about the success his group has had in the past with large initiatives.
“Well, like all areas, we have been mostly successful,” he said.
“But how about the recent initiative to rewire the second floor?” I asked. “My understanding was that many people were disrupted because they didn’t have phone access for two days.”
Juan replied, “Yes, but it wasn’t our fault. We didn’t realize that we had to do both sides of the floor. We thought only half the phone lines needed to be rewired.”
“How about the work you just completed to pick a new mobile phone vendor? I heard that this three-month evaluation took almost six months before it was finished.”
“I wasn’t involved in that project.” Juan said, “But I heard they were given an unrealistic date to shoot for. Mary was running that project, and she said that the short deadline didn’t give her enough time to plan out how the RFP process should be.”
Juan stopped talking as he realized where my questions were heading. His initial paradigm about “just doing the work” was now open to a better alternative.
It’s not uncommon to have a debriefing session at the completion of a project. (For projects that have cost, quality, or cycle time problems, these meetings are sometimes called ”postmortems.”) When the team discusses the reason for the failure, a common theme seems to dominate—a lack of planning. If only the team had spent more time understanding the work, expectations, deliverables, scope, and risks, the results could have been different. The time spent adequately planning the work will be more than made up by a smoother-running and more focused project over the long term. By remembering why other projects had problems, Juan was now open to the value of planning the work before jumping in.
Do the right amount of planning, based on the project’s size
Ross is creating a real-time equipment utilization report for a manufacturing division client. He wanted some help developing a project definition document. I asked him some general background questions, including whether there were any potential risks.
“There shouldn’t be any risks on this project,” he said. “It’s pretty straightforward.”
“What type of team will you be putting together for analysis, development, testing, and QA?” I asked.
“Right now, I’m the only one identified,” Ross said.
“You are going to put the whole application together yourself?” I questioned.
“Oh, yeah,” he said. “There will just be one new online screen to create.”
I was beginning to get the picture. “Ross, how much effort are you estimating it will take to complete this work?”
He estimated 80 hours. I was now able to shift gears and start down a new line of questioning. The rest of our phone call was focused on gathering only the information that made sense, given the size of the project.
All work can be structured into projects. However, the process (or methodology) used to complete the work needs to scale up or down, depending on the amount of work effort. For instance, large projects should have a formal planning stage that results in a project definition document and a work plan. Small projects, on the other hand, require a minimum amount of formal planning and documentation. In the case of Ross and his 80-hour project, a formal project definition document is overkill. It doesn’t usually make sense to spend 10 hours planning and documenting the work of an 80-hour project. It makes more sense to create a one-page deliverable with information such as the work requested, estimated effort, end date, business value, and priority. You also need space for the clients to sign off on approval to begin work as well as on a formal acceptance of the completed deliverables. An effective methodology must be tailored to provide value and be practical for all sizes of projects. Otherwise, it will be ignored.
Identify potential problems in the future as risks
The manufacturing company has developed a business relationship with a new bank, and Chi’s project was to establish interfaces connecting the new bank to the accounts receivable system. A lot of effort hours weren’t required, but the duration of the project was about six months.
Chi was putting together the project work plan when she realized that many of the activities in the plan relied on the expertise of one individual—Jill from the finance department. Jill was going to be instrumental in the success of this project, since she had provided the business expertise and leadership for setting up the last two banks. Chi wanted to rely on Jill again, but Jill was going to be taking an extended pregnancy leave.
“If we’re lucky, we’ll have the project finished by the time Jill has her baby. But, if the baby comes early or the project is delayed, we could be in trouble,” Chi said.
I asked Chi how she planned to account for this.
“Well, I called you just to be sure,” she said. “I think this is definitely an issue. Like you always say, ‘Issues are problems.’”
“I’m glad you remember about issues”, I said, “but this situation isn’t a problem yet. It’s a potential problem. You should identify it and manage it as a project risk.”
Issues and risks are related but not the same. Issues are large problems present today. They must be focused on and resolved quickly. Risks, on the other hand, are potential problems that exist in the future. The good thing about risks is that you have some time to deal with the threat. In the case of Chi’s project, Jill is on the job today. The potential for her leaving the project early is real, but not definite. It’s possible that the project will be completed while Jill is here. However, this result cannot be taken for granted. Instead, Chi must put a risk plan in place to mitigate the potential problem. Normally, the objective of the risk plan is to ensure that the problem does not occur. In this case, the timing of the new baby’s arrival is something that cannot be controlled. However, since Chi identified this risk early, she has plenty of time to ease the impact of the event and to ensure that the project can still be completed successfully.
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.