What are the program management competencies?

Program managers are the glue that bring your best people and teams together to collaborate like never before. They crack the hardest problems by cutting through the red tape in your organization and aligning them to the single goal. Clearly, a lot depends on having the right program manager in place. How do you hire or groom good program managers? Or, in a large organization, how do you ensure that your program managers have similar minimum competencies across the organizations? You might or might not have a single program management framework, but it might still be a good idea to have some model that allows you to baseline your program management competencies.

Levin-Ward Program Management Competency Model

Levin-Ward Program Management Competency Model

Last week, I sat through an evening session by J Leroy Ward, who has recently co-authored a book on “Program Management Complexity – A Competency Model” with Ginger Levin. He talked about the Levin-Ward Program Management Competency model that they have created. They have identified two categories of competencies – six performance competencies related to the functional ones and another eight personal competencies relating to the soft-skills. While the specific competencies are not really new, and the performance competencies are more like the specific ‘stages’ in a program lifecycle – Defining, Initiating, Planning, Executing, Monitoring and Controlling and finally Closing, they have put in efforts to specify what exactly contributes those competencies. The personal competencies relating to soft-skills are Leading, Building Relationships, Negotiating, Thinking Critically, Facilitating, Mentoring, Embracing Change and finally Communicating. I would recommend it for any newbie to program management – it could serve as a good roadmap on what to learn and focus on. The book also gives self-evaluation questionnaires for organizations, program managers and prospective program managers.

During the Q&A with Leroy, many folks (incidentally, majority were from Indian service companies – which is a very interesting phenomenon because most of them don’t have a company-wide program management function today) asked questions that seemed to indicate that the ‘Indian’ context was missed out. For example, there were specific references to cultural sensitivities, managing globally distributed teams and so on.

I also pitched in with my 2 cents and offered my views on two program management competencies that I consider fundamentally different from project management. I mean all those 8 personal competencies in Levin-Ward model are kind of ‘similar’, or linear extension to what you would expect a project manager to possess – albeit in little lesser proportions. However, these two competencies, at least to me, represent a fundamentally different and additional skills required without which a program manager can’t simply operate. Let’s discuss them:

Lead by Influence

Influence and Authority are extreme ends of a continuum. When there is very high authority, the ‘leader’ need not have any personal credibility – the followers have no option but to simply follow the ‘orders’. Needless to say, this is the old world that is rapidly falling out of favor. The new world order requires leadership to embrace influence to bring about necessary change.

In majority of organizations, more so in today’s matrixed organizations, a program manager has no direct or indirect people responsibility. He has no ‘positional power’ to lead by ‘authority’ anymore. This is a significant change from the classical project manager who typically has solid line reporting of his team under him. Even though the command and control model is long dead and buried (but perhaps still alive and kicking in some old world industries and governments), the project manager still wields ‘reward power’ for he allocates responsibilities, approves resources, writes their appraisals, determines their salary revisions and makes recommendations for their promotions and other career progression avenues. So, while on a day-to-day basis, we can argue that teams are ‘flat’, there is always this invisible hierarchy that is present at least in our minds. Contrast to this, a program manager is devoid of all such ‘reward powers’. He might have a bigger responsibility mandate than the component project managers, but he still has considerably less ‘power’, both positive and negative, to motivate (or coerce) team members to achieve the program objectives. In today’s complex problems, it takes more than a monolith silo to deliver! There might be individuals and teams spread across the organization, or even outside, all of whom must collaborate in real-time to deliver a solution.  In such scenario, the program manager must rely on his ability to lead by influencing the component teams. What does it mean?

Leading by influence means establishing personal credibility and accountability and earn trust among rest of the program team. It doesn’t mean doing everything by himself, but by facilitating collaboration of work within and across the team. It doesn’t mean dropping names to coerce the teams to somehow reluctantly agree on some artificial top-down resource and schedule constraints. It means listening to issues from all component projects and adjusting plans to achieve the program goals. It means tearing down the silos by establishing trust and transparency and helping people succeed with each other – not at the cost of each other. This article “The Language of Leadership” by Nancy MacKay nicely identifies ten leading by influence skills. I think that makes a great list.

Tony Wagner has identified it to be among seven survival skills (and I would strongly recommend checking out other six skills as well). Leaders like Mahatma Gandhi and Mother Teresa led by influence. It’s high time we learnt this fine art.

Manage at Interfaces

Project management requires fortifying a project to maximize its output. In a way, it is like a small tribe that must protect its interest over everything else. However, a program is like a much larger state that must not just look after interest of its multiple tribes but ensure that that the sum total of it all is maximized. Its primary interest is in the ‘outcomes’ that lead to creation brand-new or significant and sustainable enhancement in existing capabilities of an organization or a society. For example, Bangalore Metro is a program, whereas its components like individual metro stations, or the tracks, etc. are its component projects. While a component project manager is interested in ensuring that he hits the deadline and quality bar for his project, the overall program manager must work with all individual project managers to create a program plan that identified and manages interdependencies and allow the most optimum outcomes to be created at program level. To that end, the program manager doesn’t have micro-level control over what goes on inside each project. He must resist the temptation to micro-manage each of the component project les he loses the oversight of overall program (and also, quite possibly, upset the component project managers by such intrusion). He must manage at interfaces.

What does that mean? First of all, this is not a recognized term (a search for this phrase led me to just two pages on the net, both of which were in a totally different context). Managing at interfaces means establishing a two-way trust with the project managers that allows everyone a space to perform while focusing on the higher-order ‘outcomes’ of the program. It means involving all key participants and collaborators, identifying establishing interdependencies and establishing collaboration mechanisms that allow the program to flow smoothly without anyone getting overinvolved in other component’s inner details. The aspect of managing at interfaces is not just limited to program manager alone – it is also required that other component project managers also establish similar levels of trust among each other. Why is all this important? Well, there is a segregation of responsibility. Unless you are working in a trivial program (in which case you might argue why do you need such elaborate management structure overhead?), there is every need to establish structures and mechanisms that would allow smooth flow of outputs from one component project to another, and if we allow them to get involved in white-box details of each other, we will not only lost the focus very soon, we also run the risk of back-seat driving – that of louder voice getting what it wants. We run the risk of breaking down common agreement and running the program on side-deals instead. Needless to say, this would be contrary to achieving common goals of a program.

Managing at interfaces symbolizes a sociological setup where teams trust each other and the program manager. It allows decentralization and appropriate division of responsibilities by eliminating any overhead that could breed mistrust. Obviously, this is an end-state that is achieved by upfront investment by program manager (and the organization as a whole).

So, there you have it. Do you recognize that program management is not just an overgrown project manager? Does your organization realize that more of whatever the project managers have been doing in past just won’t qualify and train them for program manager roles? Do you recognize that apart from performance competencies, your program managers need a completely different set of skills that allow them succeed? What are the program management competencies?

Leave a Reply