Project Management

Define overall approach before building the workplan

Are you overanalyzing your efforts on a large project? This week's Project Management Mentor column suggests high-level ways to design your workplan so you're not mired by details.

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, and then offers a solution using practical project management practices and techniques.

The dilemma
I was looking forward to my meeting with Juan today. Juan was the first project manager I helped in my role as project mentor. His success on a prior project helped him get responsibility for a larger project to deploy a Windows 2000 client operating system on all the desktop machines at our corporate headquarters.

When I met with Juan, his head was still swimming with too much information.

“As you can imagine, the technical considerations for this project are not difficult,” Juan began. “But the timing and scheduling are very complicated. I have started to think through a number of scenarios, and the permutations seem endless.”

“I can imagine the difficulty,” I said. “But are you overanalyzing the effort? If you have a number of ways to come up with a successful project, does it really matter which one you choose?”

“I think you’re right,” Juan said. “But it’s been hard for me to lay out any detailed plan from beginning to end. I get halfway through one plan, and then I start to see multiple options.

“As I work through the options, the details get more complicated. Then I start to lose track of the overall pros and cons of the scenario I am following. The worst thing is that I am afraid that once I have a good plan, others may have ideas for changes. Some of my effort may be wasted.”

“Juan, I know you are going to write a project definition document for this work,” I said. “There is a section in that document for defining the overall project approach. Have you defined the approach yet?”

“Actually, that’s what I am trying to do now,” Juan said. “I will be able to define the approach once I think through the details and the implications.”

“In some projects, that might work,” I said. “But the project workplan should be built from the top down. If you lay out and gain agreement on the overall approach first, then the detailed workplan can be built much more easily.”

Mentor advice
Part of the planning process for a large project should be defining and communicating the overall approach. Put simply, the project approach contains three elements. These elements are:
  1. A high-level description of the phases (or high-level activities) needed to complete the project.
  2. An understanding of the relationship between the phases. For example, what major deliverables are completed in a prior phase, and what is created for a subsequent phase? What resources might be needed for one phase, but not another?
  3. An explanation of any special or unusual techniques or events that may be required. For example, if you plan to gather business requirements by sequestering all the stakeholders in an off-site joint application development session for a week, you probably should note that in the approach.

If the project is very complicated or if there are many permutations, the approach should be defined and agreed to first, before the workplan is built.

Juan’s tendency to want to execute before planning has resulted in him trying to lay out the detailed activity in a workplan rather than define a high-level project approach first. By defining an approach first, he can get away from having dozens of permutations on how to execute the project.

He can also communicate with others to gain an agreement that the approach makes sense.

Juan can then break down the approach into lower levels for the workplan. As further workplan alternative options are encountered, he can make appropriate decisions based on the framework of the overall approach. This high-level planning of the project approach will save time and provide focus when a complicated workplan is built.

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.

Do you have questions for The Project Management Mentor?
Have a question for Tom Mochal? Send them to us.


Editor's Picks