Plan Management

In this chapter, we’ll start delving deeper into the key management areas I discussed in Chapter 1, starting with plan management. We’ll build on the Mercury program example to inspect all stages of creating a plan both at the project and program levels.

We’ll dive into plan management by exploring the following:

• Driving clarity from requirements to planned work
• Planning resources in a technology landscape
• Exploring the differences between a project and a program

Let’s start planning!

Driving clarity from requirements to planned work

In Chapter 4, we discussed the importance of driving clarity in all aspects of a project or program. Out of all of the areas where driving clarity is needed, plan management is the most important.

When writing a project plan, we might find ourselves asking why. Why are we doing this? I ask myself this every time I’m writing one, even though it is one of the aspects of project management I enjoy the most. The answer to why we do it is simple: it enables us to be a force multiplier. We know the work that needs to be done and so does everyone else. The team spends less time on determining what and when and instead focuses on how to achieve the tasks and goals. Driving clarity in requirements early on takes less time than correcting the issue later in execution as this can lead to bad estimations due to poor understanding, which results in longer timelines.

The first step in driving clarity in your requirements and beginning...

Planning resources in a technology landscape

Every industry has its own unique challenges to project and program management and the tech industry is no different. There are two main aspects to resourcing that are consistent across the tech industry and are worth exploring in more depth: prioritization and team overhead.

Prioritization

From my experience, and through the interviews I conducted for this book, tech companies don’t follow a projectized resourcing model where a project is formed, resources are assigned, and the project keeps the same funding through out the life of the project. Instead, these large companies utilize capacity-constrained prioritization, where they perform multiple prioritization exercises throughout the year to align their existing capacity to the most strategic projects. The frequency of these exercises varies from company to company, and in some cases, team to team, but can happen as often as monthly, quarterly, yearly, or some combination...

Exploring the differences between a project and a program

Many of the tools and processes are the same between a project and a program. One major difference is scope. In this case, there is the program scope, which has its own set of requirements in the form of the program goals. These requirements are relayed down to the projects that impact them. Though I’ve been referencing the Windows Rollout Project, these requirements could easily have been for any of the other platforms.

When starting the program, you need to refine the goals in the same way you refine the project requirements. In Chapter 3, we stated the Mercury program’s goal is to have a P2P messaging application with a 90% user reach. This is an okay goal with enough wiggle room to assume success, but from a requirement standpoint, it’s too vague. What is user reach? How do we measure 90% of that?

There are also technical issues with this statement. Let’s say that the user base means all...

Summary

In this chapter, we discussed plan management in greater detail. We drove toward clarity by refining requirements into use cases, tasks, and then a basic project plan. Asking questions during each step ensured that each artifact could be traced back to the requirements.

We covered how a tech firm can add unique challenges to plan management through capacity-constrained prioritization causing mid-project changes in resourcing based on priority shifts. We also discussed the components of team overhead in a tech team including on-call rotations that service-based teams utilize for service health and stability.

We started discussing the various tools that are available to program managers for both projects and programs and each key management area. Lastly, we discussed how planning differs between a project and a program, which is tied to scope, and that defining a program comes down to ease of management of the goals you are delivering.

In Chapter 6, we’ll continue...

Further reading

• Dr. Goldratt, Eliyahu. Critical Chain (North River Press, 1997). This book describes the critical chain methodology that I have discussed under the Buffers heading in this chapter. The method is more intuitive to the way we work and give us a tangible way to handle the unknowns by assigning buffers based on complexity and ambiguity.