Outline
After organizing the program members into strategic, tactical, and operational levels, the question arises: How do we start working together?
Starting a project often comes across as an overwhelming venture, requiring close attention to many project management processes and tools. Project management frameworks like PRINCE2®, PMP, or agile methodologies like Scrum present a large spectrum of considerations that can take out the speed and initiative of getting started in the first place. This is even exacerbated for project portfolios or programs. In this blog, I outline how to get the basics right by making regular reviews, forward planning, and proactive removal of blockers in one presentation slide, which is an ideal starting point to establish a more sophisticated program governance in the future.
Start by ensuring project teams are heard by program leadership
As outlined in my previous blog of this series, my approach aims to create trust between program members across all levels. Programs and the subset of projects within them throw people into a new environment with new people, processes, and goals that deviate from the business-as-usual (BAU) activities. A good starting point in building this trust is for program leadership to prioritize that they hear and support the project teams who deliver. That is where we institutionalize the first communication channel from the bottom-up, which happens in regular meetings with the program management on the following topics:
- What has the project team delivered since the last meeting?
- What does the project team aim to deliver by the next meeting?
- Any risks or issues that could block the advancement of delivery.
This is what such a slide could look like:
The three aspects of project management
Let us dive deeper into the 3 critical aspects of the project status update slide.
Status this week: An essential part of project management is to reflect on achievements to celebrate and have a retrospective delivery analysis. Creating clarity of achievements fulfils two purposes: First, it demonstrates to leadership what the delivery team has achieved; second, it is vital to motivating project members on what they have achieved. Retrospective analyses are essential because projects are usually new endeavours for the team members. Learning what worked well and where they are struggling helps to derive critical insights in optimizing how the team coordinates and works together.
Outlook next week: Ideally, the outlook is based on an overall project plan. However, I have seen projects being launched where the end goal wasn’t clear, and the project managers had to plan from week to week. Regardless of the existence of an overall project plan, the outlook of next week institutionalizes the process for a project manager to think ahead about what the team should work on next week, which in the next presentation to leadership would hopefully end up in the achievement section of the status update. It is also a record that, over weeks, shows how well the project managers and their teams can plan and execute against the plan.
Critical risks and issues: Presenting results to program leadership should not be a one-way street to woo senior management of the work that projects delivered. In this section, project managers need to outline the risks and issues that could block their ability to deliver. Risks are potential outcomes with a certain probability and impact, which need to be aligned on what happens if they materialize. An example would be that the team needs to hire a key developer in 2 months and has been unsuccessful so far. An issue is either a risk that becomes real or an unforeseen event that hinders or even blocks the delivery of the project. A prime example would be if a key developer had an accident and needed to be hospitalized for 2 months. In both cases, the project needs to understand that raising risks and issues is a call for attention or help from program leadership. When done right, this is how leadership builds up trust to implement further program management processes that are accepted by the frontline project delivery teams.
Escalation principles
Writing a status update slide takes about 30-45 minutes for the first one and 15 minutes to update on a weekly or bi-weekly basis. It is essential to understand that these 15 minutes need to be worth it for the teams. If the project teams need senior guidance or help, the tactical or strategic levels should be there to help and avoid blaming the project team’s performance. This is where program leadership can be the knight in shining armour instead of the brutal dark knight that everyone fears.
There is another reason to escalate beyond the cry for help. Each level in the governance setup should have defined what they can decide on and where they need to ask the next level for permission. For example, it’s typically within the project manager’s remit to approve holidays or PTO for his or her team members. However, if a key person requests a 6-month sabbatical, which could tremendously impact another project team, this decision might be escalated to the next level. The same goes for budget constraints, time changes, etc. For example, if a project’s budget allows to hire either an expensive designer or an expensive developer, this would be the decision of the project manager. If the project needs an increase in budget to hire both an expensive designer and developer, he or she would have to ask the next level to approve the new budget. An example of how the decision criteria could be defined per level is outlined below.
Why we start this way and the next steps
This is my structured approach to establishing a program management environment, which aims to move a new, huge, and complex venture into a manageable, controlled, and collaborative environment. My approach does not replace the required program planning, which must happen before large sums of money are spoken and invested in a strategic change program. These planning activities include hiring the key people, knowing the key stakeholders, and having a vision and high-level objectives to guide a program. However, even with the best planning, reality hits like a freight train when program managers and their governance teams try to bring order in the ever-moving world of a project portfolio like a program. This often leads to a firefighting mode where leadership and project teams focus on putting out fires from unforeseen events, thus neglecting proper prioritization of tasks.
Giving project teams the trust of leadership by making their reporting the very first priority for leadership helps to install routines that facilitate proactive planning and anticipation of blockers, thus moving away from firefighting to proactive management. Once the calm and trust in the program leadership are established, more sophisticated tools like deliverable trackers can be introduced, which are also accepted by the project teams on the frontline.
What about the RAG or traffic light system on the slide?
The proposed status update slide also shows a traffic light system or RAG (Red, Amber, Green) for some project dimensions like scope, schedule, costs, etc. These are optional and give program leadership a high-level view of where a project could have challenges. The RAG status can either be qualitative, depending on the project manager’s assessment, or quantitative, thus depending on data from project management trackers. In either case, a clear distinction should be defined so that all project managers know when to change from green to amber and from amber to red. In my opinion, this RAG reporting is not critical in status report slides, but they can give a flavour of how well the projects are performing. A better alternative is the reports from dashboards based on project tracker data.