What’s a project manager to do when dozens of requests for small changes make the scope management of a project seemingly impossible? And what should you include in a good risk management plan? Here’s some guidance for tackling these everyday issues in the life of a project manager.

Batch small scope changes together for one approval
Doug, an application support specialist, always knows where to find the answers if they aren’t already in his head. Like many support specialists, however, Doug is not the strongest project manager. Perhaps it is the nature of good support people—they’re used to jumping in and fixing problems quickly. That may explain why it’s tough for Doug to plan and manage larger projects.

In spite of his shortcomings, Doug has enough knowledge and experience to deliver small enhancement projects reasonably close to expectations. And, perhaps unlike many people from the support organization, Doug is open and willing to learn structured project management techniques—at least up to a point. When I talked to Doug about how his current project was progressing, he was a little apprehensive.

The purpose of his current project was to add the ability to track the response rates of direct mail campaigns. Unfortunately, the project was at risk of missing its budget and deadline. I asked a standard series of questions about how the project was being managed—project definition, assumptions, risk, staffing, issues—to see if I could identify some root causes as to why the project was in trouble. When we got to scope change management, Doug was a little defensive.

“You know I’m willing to use formal project management techniques when they make sense,” he said. “But you know marketing. They always want changes after the initial scope has been agreed to. The frustrating part is that I would like to use good scope change management, but the size of the changes is always fairly small. Five hours here, three hours there, pretty soon you are talking about some real hours. I think that’s why we are in trouble.”

I asked Doug how he was managing these small changes. He said the scope management process normally includes gaining sponsor approval for changes. “But I can’t take every two-hour scope change request to him. He would throw me out of his office. So, we’re trying to be client-focused and fit as many of these small changes in as possible. What other options do I have?”
When projects are at risk of missing their budget or time deadlines, the project manager must be especially diligent to manage scope change requests tightly. Sometimes these scope change requests are for substantial amounts of new work. Smaller changes, however, are harder to manage because there’s a tendency to just want to do the work. This is a mistake. When a project is at risk of missing its deadline, all scope changes must go through scope change management. If the changes seem too small to take to the sponsor for resolution, the next best approach is to bundle them together. A number of smaller requests can be taken to the sponsor at one time. Then instead of making ten trips to the sponsor for small decisions, you can take one larger batch of scope change requests. The benefit is that the sponsor can see the current list of outstanding scope change requests in its entirety. The sponsor can then make a more substantial decision to accept or reject the changes, with an understanding of the corresponding impact to budget and schedule.
Minimize the impact of future problems with a risk plan
When I last spoke to Chi, she was facing a major risk on her project. Jill, who held much of the business subject-matter expertise on connecting banks with the accounts receivable system, was pregnant and would be taking extended leave when the baby was born. Chi and I identified this as a project risk. She drafted this risk plan to ensure that the project could survive if Jill needed to leave before the work was completed.

  • Identify all activities needing Jill’s expertise, and accelerate as many of them as possible to the front end of the work plan.
  • Work with the business client in the next two weeks to identify a backup for Jill, and include the backup as a member of the core team. (The manager of accounts receivable needed to do this anyway since he would have to backfill Jill’s responsibilities when she was gone. Chi’s requirement was that they identify a backup sooner rather than later so that the backup could be involved in the project.)
  • Have Jill’s backup assigned to all the same activities as Jill to ensure maximum continuity if Jill leaves early.
  • Have Jill document what her role would be on all relevant activities, starting at the end of the project and moving backward. This would ensure the backup would have at least some information on the activities if Jill needed to leave early.

Chi was also very logical in her planning. If she were lucky, she would be able to complete the project while Jill was still here. If Jill went out early, this plan would ensure a smooth transition and help the project complete successfully.
Identifying project risks is only the first step in risk management. Step two is to develop a plan of specific steps that the project team will perform to ensure that the potential problem does not occur. Step three is to think about what you will do if the risk plan fails and the problem actually occurs. (This provides some sense of the problem’s potential severity.) Step four is to manage and monitor the risk plans and do ongoing risk evaluations to see if new risks occur while the project is in progress. In Chi’s case, the risk to the project is not that the baby would be born. That is a fact. The risk is that Jill will leave work during the project and the resulting loss of expertise would have a detrimental impact on the project. Now that Chi’s risk plan has been defined, she needs to ensure that all the specific activities get moved to the work plan so that the plan actually gets executed, monitored, and managed.
Time to think about (ugh) metrics
After a few weeks as project mentor for Blue Sky Manufacturing, I asked my manager, Wayne, to provide me with some feedback regarding my performance. Wayne said that he would talk to some of the managers of the people I had worked with.

“I spoke with four managers,” he told me a few days later. “All the feedback was positive. Even Juan looks like he’s putting together a decent plan before he begins the project. In the past, he would have been a third of the way to disaster by now.”

“This all makes me feel good and makes me believe I am on the right track,” I said. “Unfortunately, that’s all it is right now—feel-good feedback. I guess it’s time I start to collect some more meaningful data on the value I’m providing.”

“Value,” Wayne said with surprise and confusion. “The feedback I heard was that you have been providing a lot of value.”

“Yes, I appreciate the kind words. But you gathered feedback from fellow managers you’ve worked with for years. At this point, I’m sure they would have given you positive feedback regardless of what I was doing. I need to collect some more meaningful, quantitative feedback on the value I am providing. I’m preaching the value of collecting metrics to the project managers I’m working with. I guess I need to start taking some of my own medicine.”
Too many companies have no idea whether they are getting value for the money spent on projects and have only a vague idea of how successful their projects are. Collecting metrics is the only way to get quantitative information on how you are doing and to give you the data you need to improve your processes. Metrics must also be collected to show the effectiveness and value of services being provided. In my case, I am providing a service to the organization. I need to collect metrics to show the effectiveness and value of the service I am providing to project managers. The basic philosophy I recommend is to start collecting metrics—even if they turn out to be the wrong ones. You can modify them over time if they don’t provide indications of how effective and successful you are. In the next few weeks, I’m ultimately going to go through an exercise to determine what metrics make most sense for me to collect. In the short term, however, I am going to start small, with a simple client satisfaction survey.

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.