Outline
How do we build a program governance that ensures clear communication across all levels and measures the status of all projects within that program?
In this blog series, I’m addressing how I did this in my consulting and entrepreneurial program management career. When managing programs or project portfolios, I prioritize ensuring that communication feels safe, which encourages initiative and the proactive removal of potential blockers along the way of a project. Let us explore in this blog post how we can build a program work environment that is based on mutual trust and engaging collaboration.
Key goals of program governance in startups and established companies
I worked in startups, directing targeted projects, and in established Fortune 500 companies as a program management consultant. In all companies, I noticed that working together for a temporary endeavor, like a project within a program, feels new and strange to most project members. It doesn’t matter if a company has a long history of people knowing each other for decades or if the people have just met like in a startup: a program is complex and ambiguous with no clear path to success. We find ourselves in new roles and get to know new people, and our project work is all but business-as-usual (BAU). This is where a good governance structure makes all the difference in establishing healthy collaboration between people.
My approach to program governance was applied and tested to both startups and large companies. Managing and governing programs requires tackling three priorities:
- Create trust between management levels and across projects. Communication and transparency are essential for people to voice concerns and new ideas.
- Balance admin work we put on people to capture program status and the time they save through this work. We’re aiming to reduce the overall workload, not add to it.
- Accept that different projects in our program could use different methodologies (agile or waterfall) and other tools. One-size-fits-all is a killer for effective project teams.
The four steps of creating a governance structure
When we think about programs, we see the complexity of organizing across different departments and geographies and the strategic importance. Often, that results in overengineering program governance: I saw program governance structures laid out in 200+ PowerPoint slides, detailing anything from how to hire new people to the project, how decisions are made, how approvals are collected, where deliverables are stored, etc. While these administrative questions are indeed important, they are not vital in getting started to work effectively with each other. Besides the program QA team and me, almost no one ever read all those slides, and still, the program members worked effectively with each other. This suggests that we can focus on a short selection of questions regarding program governance.
I personally follow the four steps below to establish a collaborative environment and effective program governance. All detailed questions of a sophisticated program governance can be tackled once these four steps are done (if you wish to).
- Organize the program team into three decision layers: strategic, tactical, and operational.
- Establish communication channels bottom-to-top via status reports.
- Create simple tools to collaborate.
- Establish planning processes and thus establish a communication channel from top-to-bottom.
In this blog post, I will go further into detail about how we organize the program team into three main layers before I outline how I tackle the other three steps in more detail.
Building an org. chart to understand the different layers of governance
We can keep the structure simple by dividing the organization into three different levels that can decide on different spectrums:
- A strategic level
- A tactical level
- An operational level
Each level has a different role to play, and in some organizations, they could be covered by the same people (e.g., a startup usually doesn’t have three layers at the beginning). However, it makes sense that different discussions happen on each level. A first step to split the team into these three levels would be to look at the actual org chart and try to answer the following questions:
- Who is overall accountable for the program’s success and would decide whether to spend more money on the program? This is the strategic level.
- Who keeps an overview across all projects within the program or project portfolio and sets priorities between the projects? That is the tactical level.
- Who works on the project deliverables according to a clear scope, schedule, and budget? Here, we have the operational level.
The entire org. chart could also be split along other lines; often, tactical and strategic levels are reflected in committees. The critical step here is to suggest a split and then engage with key decision-makers and stakeholders to refine the split and decision layers.
Once we have the organizational chart and the different levels mapped out, we can move to establishing the first reporting and communication channel: the most important channel, the one from bottom to top.
Read my next blog entry [coming soon] to learn more about how to establish regular reports without overburdening the project teams with admin.
Personal thoughts about adding more levels
I accompanied programs valued at USD 250 million and only saw these three levels. My caveat is that I only worked in IT programs, and there might be industries or regulatory environments that require more layers. I can imagine, for example, that strategic construction or health research programs would have additional decision-making layers like a regulatory or political body. Obviously, these would have to be mapped out if necessary. Otherwise, I strongly recommend staying with the three layers: strategic, tactical, and operational.