So last time I put out a fairly unstructured post where I covered the high level value that I see in having a program management function at all. In this post I will try to explain how this motivation translates into actions and what they are designed to achieve.

This article does not aim to present an exhaustive list, but rather a few examples.

The rhythm of business

Whether you work in a very agile environment where you practice your scrum rituals or a more traditional enterprise having a rhythm to what your teams do is in incredibly important. It acts as a forcing function, increases predictability, and chops up project cycles into more measurable chunks.

Program Managers are not always responsible for creating these rhythms (be it a business review, scrum meeting, etc.) but they are very often responsible for ensuring that they happen and that they are a success.

The most important thing about regular cadences is that they need to be valuable.

  • A good program manager will always question the value in each meeting that they and their team attend.
  • They will evolve the activities in these meetings so that they don’t turn into tickbox exercises or time sinks.
  • They will always be focused on enabling people to do things asynchronously where possible.

Clarifying the message

There is three elements to this one:

  • Making sure everyone knows why the team is doing what they are doing
  • Communicating the “why”
  • Helping others in communicating the “why”

All steps take a long time to get right and if you are new to the job you shouldn’t expect that your leaders will do any of these for you. Often there can be disagreement on what exactly “the vision” is in all parts of the organization.

It’s core to the PM’s role not to set the vision but to test different ideas and enable groups of people to find consensus about it. This does not mean making every decision in a big mutual discussion but rather putting a process in place that allows people to make the decision.

Once you have clarity the real work starts. It’s about over-communicating the vision but also about helping others articulate it. This comes in many different forms. For example: Program Managers might start assessing items on their backlog based on the core principles of the vision that has been agreed and ask others to do it for new items.

Understanding the future

Sometimes people may call this “just enough planning”. People do this in different ways. I like to define a short term (sprint) horizon where I know exactly what work needs doing, a medium term horizon of a few months where I’ve got a good idea, and a long term horizon, where I know the big things I want my product to achieve, but not a lot of detail.

What we’ve got to understand is that change is a constant, so it’s difficult to always exactly predict the future. That doesn’t mean that we shouldn’t predict it. Instead we should use all the information that we have now and make a good estimate with the understanding that it is just that: an estimate.

PMs spend quite a bit of time communicating when something will “land”, what timeframes have shifted, and why. A good level of tracking and the right tools are important to achieve this. Less is often more here. You don’t need a fancy work item tracking system to tell you exactly what your team’s capacity is, you just need a coarse but relatively accurate view of the world, because no doubt stuff is going to change in a few week’s time.

“Understanding the future” is about having the least cloudy vision at any one time and articulating how cloudy that vision is with effectiveness so that people can help provide clarity, engage in planning, and brighten that vision as the team works towards it.