When Your Projects Are a Program

I was supposed to start coaching with a project manager, Trish. She postponed our weekly coaching call–for the third time. I said, “Trish, are you postponing again because you have too much work to do?”

“Yes!”

“Then I suggest we carve an hour out of your day sometime sooner than next week and determine why you have so much work to do.”

She reluctantly agreed.

When we spoke later that day, I asked her about all her projects. She sent me her spreadsheet of everything she was working on.

“Trish, I see these three projects. They are unique and stand-alone, right?” She agreed.

“I’m confused about these six projects here, and those seven projects there. Are they related to each other?”

They were. The six projects composed Program1 and the seven projects were Program2. Each project in the programs had its own project team, so Trish was trying to manage 13 project teams for the two programs.

How did we decide these projects were really programs? Without the sub-projects, the larger “project” had no value–that is, the organization could not release the sub-projects or the larger “project.” That interdependency of sub-projects to create one valuable deliverable is one definition of program.

A program is a collection of projects that all together deliver significant value. Each project may have some value by itself. But the real value is the collection of projects into one deliverable: a program. You might have a program of a number of subprojects all with one release date. Or, you might have a program of phased releases, where each release delivers some significant value.

Managing one program is difficult enough. Managing more than one plus other unrelated projects is impossible. But the first step is to recognize when you are managing a project or a program.

Once we collected all her work and decided which were projects, which were programs, and the relative progress on each one, we could start solving the problem of how to manage all that work.

Trish was very lucky. Of the three projects, two project teams had been pushing at her to let them work feature-by-feature in timeboxed iterations. She’d never managed a project like that so we discussed how to assess project progress. I assured her that once she saw a velocity chart she could let her Gantt charts go. That�s because a velocity chart shows actual progress of completed work.

She also promised to assign one of the technical leads who had been helping her on each of two teams as the real project manager for those projects. Now we were down to one project and two programs. We discussed the relative importance of the three efforts, and realized that both programs were more important the project–at least, Trish thought so.

I asked, “Can you really manage both programs at the same time?”

“No.”

“Do you have someone you can ask to manage one of the programs?”

“No.”

Ok, so now Trish feels stuck. She can’t do all the work and she doesn’t know anyone else to ask. It’s time to ask for help.

We discussed what she could say to her manager, Ted, so he could see the seriousness of the situation and help Trish with her work.

“First, make sure you know what Ted wants. Make sure he actually wants both programs and this project completed at the same time. Do you know that he does?”

“Um, no. We never discussed the real due date. Everything here is due yesterday. It never occurred to me I had some wiggle room on when things needed to be done.”

“You might not. But you might. Asking ‘when’ might be a big help. If all the releases are staggered, no problem. But I bet they are not staggered, so after the when question, ask which project or program is more important.”

“JR, I know that Program2 is more important.”

“How do you know?”

“It’s obvious.”

I repeated my request for Trish to ask Ted about the relative importance, and sure enough, when we spoke again, the priorities were not what she expected.

“Ok, the priority was not obvious. It turns out that Program1 is more important than anything else I’m doing. Surprised me. I could have sworn that Program2 was more important. And that other project? That’s not even on Ted’s list of things to discuss.”

“Ok, can you stop work on Program2 now, and concentrate on Program1?”

“Yes! If Program1 is delayed, I’ll be in trouble because that will postpone Program2, but for now, I can work just on Program1.”

We discussed how to organize Program1’s work, how to have other people lead the project management on the subprojects, and how to see if Program1 was making progress or was in trouble.

Trish was lucky. Normally managers say everything has to be done–and now! If you want some tips on how to help your manager rank projects, see the next Pragmatic Manager.

In the meantime, if you are attempting to manage 57 gazillion projects, or develop 30 bazillion, or test 92 zillion projects, first think about whether each effort is unique, as a project or if the work is interdependent and is a program. You’ll make different choices about the work you need to do depending on whether this is a project or a program. Sometimes, it’s much easier to see how things fit together when you know you’re managing a program.