Adding Value in Program Management

This year (2017) I complete 10 years of software program management in India, in multiple companies and towards the release of several products. While looking back and by comparing notes with peers in other organisations I observe that for software development, the program manager role can be misunderstood and underestimated by many.

There are formal definitions for program management but it is difficult to create a common description of the role that can be used for all organisations and all programs. An added difficulty arises while considering the relationship of this role to a program director and to a project manager. For the purpose of this article I treat all of these as similar but with varying breadth of focus.

An Ideal Program Manager

My first introduction to program management was as a kid, while reading Herge's Destination Moon. This comic book tells the fictitious adventure of Tintin and others as they build a rocket and prepare to travel to the moon as early as 1950. We meet Mr. Baxter - a supporting character but clearly central to the success of their mission. He brings the right people together, plans and tracks the progress, brings issues and conflicts to resolution, makes the right ground decisions for Explorers On The Moon and stays with the team until after they eventually return to Earth. The value added by Mr. Baxter is unmistakable. He does whatever it takes to make the program succeed and to me he was the ideal program manager.

Over the years I have had the good fortune of learning from seasoned program managers (Jeff, Venky, Michael and Srinath - you know your influence) and I have refined this role for myself. For my programs I now look to see where I can add value and what type of program manager the program needs. Often I try to identify the program manager I don't want to be and here's my list.

Five Program Managers Who Don't Add Value

1. The Reluctant Engineer 

The qualifications for software program management often include an engineering background, preferably software engineering. However after being hired this former engineer often chooses to forget how software is developed and is reluctant to get into the details. After all, he is a manager and there are other people assigned to the details. However he often struggles to identify the next steps, especially when things do not go according to plan.

Using engineering experience to understand the details will add value.

2. The Yes-man

Organisations love a program manager who always says Yes. Yes - we will build the system in 1 year (even though we understand neither the requirements nor the solution). Yes - things are under control. Yes - we can deliver the software on time with 20% less staffing than estimated. It takes a mature organisation to understand that the yes-man does not add value.

Equally notable are those program managers who remain silent while the business owner parades his non-existent solution tailored by architects also of the yes-man type (as in the tale of the Emperor's New Clothes).

Speaking up when something is not possible or when assumed technology does not actually exist, will add value.

3. The Dreamer

The dreamer is not a yes-man but one who honestly believes that somehow things will workout for the program, without researching the "somehow". This is most common in the context of timelines. For the dreamer his organisation is a software factory that can somehow increase capacity and production at will. His teams have long conquered architecture and design and anything new will somehow be designed and implemented.

Underpinning planning, keeping estimation real and considering the "cone of uncertainty" while planning will add value. As for architecture, asking to see before believing adds value.

4. The Improviser

The improviser is mainly driven by what should be done next without any view of the endgame. He rationalises that in programs where requirements and technology are so prone to change, why create a plan that one will abandon anyway? And with Agile methodologies his team only plans to deliver increments. When asked for an outlook of the final delivery he almost says "you'll get it when you get it".

Creating a complete plan and rigorously updating and communicating changes not only adds value but is a basic expectation in multi-function programs of significance.

5. The Boaster 

The boaster is very visible in the organisation, publishing every detail about the program as an achievement. The rise of social media has provided this individual with convenient capabilities to chirp and harp, brimming with positivity about even the most mundane events. This creates hype about the program that does not always add value and sometimes even generates ridicule. Some boasters can also be self-serving in what they publish and this definitely does not add value to their programs.

To paraphrase King Solomon for modern times: there's a time to be silent and a time to tweet.

The Program Team

As in Destination Moon, the real talent is not the program manager but the team. The program manager can add value by raising the bar for the team and by challenging and coaching team members to achieve more. This not only develops the production capability for the program but helps each individual in their future endeavours.

As I look back I am grateful to those architects who helped me see and believe, to those testers who helped me to keep it real, to those developers who indulged me in discussing engineering details and to everyone who did their best to make our programs succeed.

Image Credits

• Program management tag cloud: masterart / 123RF Stock Photo 
• Mr Baxter: Destination Moon, Herge, published by Little, Brown and Company in 1976
• Five program managers: sifotography, dolgachov, vadymvdrob, gstockstudio, oocoskun / 123RF Stock Photo