Each week, project management veteran Tom Mochal provides advice on planning and managing projects. He first describes a common problem scenario, based on a real-life situation, and then offers a solution, using practical project management practices and techniques.
Project manager Reyna had just finished a project implementing a CRM package, and was starting up an effort to make a major enhancement to the client’s advertising tracking system. She was approaching the end of the planning process, and she asked me to review her abbreviated project definition and workplan.
I started off with a compliment: “I can tell you learned a lot on your CRM implementation. Your project definition looks great. Your workplan is looking good as well. When will it be completed?”
She looked a little puzzled. “For the most part, the workplan is complete,” she said. “I guess I can assume that you see some problems in that area.”
”I don’t know that problem is the right word,” I replied. “However, many of the activities seem pretty vague. I assumed that you were going to put in further details before you considered the workplan complete.”
“I think the workplan follows your advice.” Reyna countered. “In a class you taught a year ago, I remember you said that the work should be broken down into activities that are no larger than 80 hours. If you look at the estimated effort hours, you'll see that all of the activities are less than 80 hours.”
I realized then where the confusion was coming from—me!
“Reyna, I think what I said was that you shouldn't have any activities on your short-term workplan that are larger than 80 hours. However, they certainly can be much smaller. In fact, the smaller your project, the smaller the activities need to be.”
Reyna has just finished a major CRM initiative, and has typically managed large efforts during the past few years. That's why she's comfortable with a workplan that has large activities. However, her current project is much smaller, so she needs to also scale down the size of her activities.
She's in the planning process, and everything seems fine now. But I know from experience that when it comes time to manage the project, she will soon realize that this level of detail doesn't give her nearly enough information to know if the work is proceeding on schedule or not. By breaking the large activities into smaller ones, she will be able to gain visibility to schedule solutions to problems much earlier, while there is still time to actively manage through any delays.
In my approach to teaching and mentoring in project management, very few things are absolute. I try to stress that all processes are relative. The larger the project, the more discipline and rigor are needed on the project management side.
For example, scope change management must be more formal on a large project than on a smaller one, since there is more likelihood that scope changes will have a cumulative detrimental effort on a large project. Likewise, a small project probably has very little risk, but risk must be identified and managed much more formally on a large project.
One area that actually works the other way is in the work breakdown structure and the resulting workplan. The work needs to be broken down to a lower level of granularity for smaller projects than on larger ones.
Let’s say that you have a project that takes 12 months and 10 people to complete. Some work will be relatively quick, and some activities will take a long time. If you have an activity that is 200 hours, you may break it into four smaller activities of 70, 60, 50, and 20 hours. For a large project, that may be small enough. Even the 70-hour activity can be managed effectively, since it is just a tiny piece of the overall project.
Let’s take this example all the way down to the smallest degree. If we have a project that is 70 hours of total effort, we can hardly say we're managing it if we have the entire project collapsed into one activity of 70 effort hours. We're not going to know if the project is on track until the activity is completed, and by then it'll be too late. The project will already be over its deadline and budget.
The difference in the two examples above has to do with your ability to control the project. Reyna’s project is estimated to be 650 hours, and she has a handful of activities that are almost 80 hours in length. Her problem is not that she doesn’t understand the work. Her problem is that the large activities provide limited visibility if the activities are running late. If a couple of the large activities start to trend over their estimates, she may not realize it until the activities are late, and by then it may be too late to save the entire timeline.
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.