Planning Wrap-up

Create a program hub

At this point in the program lifecycle, you have created the program charter and the program plan. The program plan adds at least three new artifacts:

• The WBS

• The roadmap

• The RAID log

Both the charter and the plan contain critical information for many stakeholders. Time to flex your organizational skills as a technical program manager! You have the responsibility to make all the program artifacts easily discoverable.

Centralize these artifacts into some sort of program hub for easy discoverability.

This can be accomplished in multiple ways: a shared drive, a doc providing links to everything, a landing page within Confluence, and so on. Whatever method you choose, ensure everyone can access the one-stop shop for program information.

Planning to execution transition

Formalize the end of planning by clearly communicating to all stakeholders that the program is progressing from planning to execution. You can formalize this by:

1. Broad communication to all stakeholders linking all outputs from planning.

2. A program team meeting to review the planning outputs to sign off on alignment with everyone in the program team.

3. A program roadshow, which is a series of meetings with various stakeholders to inform them of the plans moving forward.

Doing this will help the program team shift its mindset from "planning to get things done" to "getting things done."

Once you've gone through sufficient planning to have reasonably high levels of confidence for the first three to six months, your program is ready for execution. Let's get this party started!

Common pitfalls during planning

During the planning phase, there are some common errors that frustrate program progress.

• Rushed planning: You will undoubtedly come across program participants who think planning wastes time. Real progress comes from doing the actual work instead of planning it, right? Right. However, if you fail to plan, the probability of having costly errors on your program voyage will slow you down quite a bit.

  • What can you do about it? Prioritize your planning activities according to your specific program. If a program is relatively straightforward from a technical perspective (low risk for dependency management), you don't need comprehensive documentation on dependency management. Focus on the highest-risk areas of the program instead.

• Doing too much planning: The opposite struggle is planning too much and delaying traction. If you allow planning to drag on too long in an attempt to sort out every detail, then the momentum of the program will quickly stall out before it even begins.

  • What can you do about it? Look at the program timeline as a horizon of probability. The near-term (the first three months) should have fairly high levels of detail clarity. As you expand beyond that, lower your expectations for the questions that actually can be answered, but do so in a structured way with horizons of confidence. Find the shortest path to value for the program. Start there, and jump into execution so you can pick up momentum.

Recap

There is a lot that goes into planning. This can be intimidating.

By the end of planning, however, your program team should have a solid idea of what needs to happen next, who is doing it, and what major risks will be a priority at first.

When planning is done right, you'll notice some key benefits:

• Spontaneous risk is drastically reduced, which will make your stakeholders happy.

• Clarity on next steps will motivate teams to make progress and subsequently make buy-in easier.

• The program team will be more unified by the end of these planning exercises.

As the technical program manager, you have the responsibility to drive successful planning, but you don't have the responsibility to do all the planning. Lean on your cross-functional experts and delegate as necessary.

Working together as a team, your program team can create a high-quality program plan.