Deciding When to Build a Program

We know what a program and project are, but this has all been with the assumption of a preexisting program. As a TPM, one of our jobs will be deciding when a program needs to be created—when it is appropriate to the needs of our organization to do so.

Knowing when to create a project is straightforward—we receive requirements to deliver a new application or service, a new feature, and so on, and we create a project to deliver on those requirements.

However, knowing when a program should exist is a bit more nuanced and depends on the situation. There are two avenues in which a program is created: from the beginning when requirements are given and during project executions when a need arises.

Let’s explore both scenarios.

Building from the start

Deciding to form a management program around a set of requirements is how most people perceive program formation because it mirrors the form that project creation takes and therefore makes sense. To make this decision, we must first clarify the requirements, because this process will require analyzing the requirements closely to define appropriate boundaries.

Previously, we went in-depth into driving clarity in requirements, so we won’t repeat much here in that regard. The biggest difference between driving clarity in requirements for an existing project compared to before project and program formation is that our clarity helps us categorize the requirements. We are looking for patterns or deliverable chunks of requirements—much like determining features in a project.

When examining requirements, we are looking for scope and impact cues that may serve as logical delineations between multiple projects to deliver on the requirements we have. Once a set of requirements is broken out into more than one project, a program is needed to ensure the full requirements are met.

Using the Mercury program and project list as an example, the figure below illustrates a typical project and program boundary.