Program management: six herds, three boxes on fire, and one color-coded chart

Purpose

Program management is the coordinated management of multiple related projects and business-as-usual activities to achieve strategic objectives. Project management is the day-to-day delivery of one well-defined thing, within strict limits on cost, time, and quality. A project is a train that a project manager pulls into the station with a finished product aboard. A program is several trains on different tracks headed for the same station, and the program manager is the one standing on the platform directing them.

In plain talk: if project management is herding a dozen cats into a box, program management is finding out you have six separate herds, three of the boxes are on fire, the budget only buys dog food, and your main job is convincing the brass that the smoke is a planned deliverable.

Roles and responsibilities

1. Sponsor. Authorizes funding, guards the business case, and owns the high-level risk. Also mentions dates in elevators. See § 5.
2. Program manager. Handles governance, coordinates resources, and solves problems that cross project lines. Carries the blame for work done by people who do not report to the program manager, armed only with a color-coded chart and a calendar invite.
3. Project managers. Run the day-to-day execution of each project inside the program. Each believes their train has priority on the shared track.
4. Business change manager. Oversees how the organization adopts what the program builds, assuming the organization was told.

Because client teams are small, individuals will hold several of these roles at once. However, the person who verifies the work shall not be the person who did it. This requirement is copied from every serious design-control system ever written, and it is the one most often waived on a Friday.

Lifecycle and phase gates

Programs under this procedure pass through six phases: concept and feasibility, planning, requirements, design, verification and validation, and launch. Each phase ends with a phase review, which has three purposes:

1. Confirm that the deliverables for the phase have been met, or document why they have not.
2. List the open issues and carry them into the next phase, where they will be renamed.
3. Reach consensus that the program is still viable. Consensus is reached when the last person who disagreed leaves for another meeting.

A human use decision is required before any plan produced under this procedure is applied to actual humans. In a medical device program, this meeting reviews safety before a device touches a patient. In a business, it reviews whether anyone has asked the people who will have to live with the plan. Both meetings are frequently scheduled after the fact.

Assumptions, dependencies, and constraints

1. All resources identified in this plan will be available when needed, and their time will be dedicated so that every schedule commitment is met. This assumption is listed first because it is the one most likely to be false.
2. Requirement changes requested after the requirements phase will require a re-evaluation of the plan. They will be requested anyway, usually by the sponsor.
3. Failure of outside consultants to deliver work that meets requirements will require a re-evaluation of the schedule, resources, and budget. SavanTech has reviewed this clause and finds it reasonable.

Rules that never make it into the handbook

1. A green status indicator on an executive dashboard means nobody has had the stomach to open the tracking sheet since Tuesday.
2. Any date a vice president mentions offhand in an elevator immediately becomes the immutable baseline for the year-end audit.
3. Adding three new workers to a late workstream guarantees another two weeks of delay while the old hands explain to the new ones why everything is broken.
4. A risk mitigation plan is an elaborate fiction that everyone praises at the kickoff meeting and ignores until the afternoon the roof caves in.

The five pillars of the profession

1. Strategic alignment. The formal practice of taking a chief executive's vague weekend whim and dressing it up as a twelve-month operational roadmap.
2. Stakeholder engagement. Nodding with a straight face while two rival directors demand opposite outcomes from the same pot of cash.
3. Resource allocation. The daily sleight of hand by which one exhausted technician is split across four urgent tasks and the result is called optimal utilization.
4. Governance and compliance. The art of generating enough paper to prove that when the wagon went into the ditch, it went into the ditch in strict adherence to corporate policy.
5. Benefits realization. The quiet phase at the end of the year when the original charter is rewritten so that whatever the team actually built looks like what was intended all along.

Worked example: Thanksgiving dinner as a regulated product launch

The absurdity of the discipline shows best when strict program governance is applied to something that has no business being managed, such as a multi-family Thanksgiving dinner run as a medical device rollout.

Put the brother-in-law's deep-fried turkey on the critical path and issue a formal nonconformance report at eight in the morning, because the bird is still a solid block of ice. Convene an emergency change control board in the hallway when an aunt arrives with an unapproved green bean dish, forcing a live reallocation of oven rack capacity while two cousins dispute jurisdiction over the television remote. By the time the gravy lumps are logged in the risk register, everyone is eating cold ham and resenting the steering committee.

The program met all of its documented milestones.

Schedule

Nothing on this page is advice to any client, living or deceased. The cats are composites.