A steering committee is a part of a project that is a scheduled check-in where all of the key stakeholders or functional owners of a project get together. The goal is to ensure that everyone understands current progress and identify any pitfalls or roadblocks. This is also where the communication can be streamlined and unified. These meetings are also a bit more frequent and help prepare a foundational set of information that can be boiled down and condensed to a C-suite or senior leadership deck. This deck is a higher-level deck but can be built from your more detailed steering information.
Throughout a steering committee, you’re really focusing on the key functional owners and the things that they need to make decisions together to help steer or move the project forward in the right direction. This group is normally represented by a cross-section of functional owners both on the business side and the technical side, as well as any of the managers that are helping to do some of the operational or project work.
Some of the topics important for the steering committee are removing roadblocks that are preventing the project from moving forward, clarifying any details that may have been vague, and sharing the progress that has happened throughout the last check-in period.
Table of contents
It is recommended the steering committee meetings be held either weekly or bi-weekly. The important thing is to have a standard cadence between these leaders so that there is no gap in communication or a misunderstanding between each group and their responsibilities throughout the project. A larger meeting that is boiled down and condensed for C-suite or senior leadership is normally something that you do on a monthly or even a quarterly basis. The longer time period is not ideal for the steering team since it would limit the ability and flexibility to act on project information.
Building a Foundation
The steering deck is, hopefully, a foundation that is reproduced and used for multiple projects. As your team learns this once or twice, they start getting into a cadence of using the same deck format and looking at the same information. This results in spending less time trying to decipher the format of the deck, and really focuses on the information and the cadence of the discussions. Further, these more frequent steering meetings and a consistent foundation will make it easier to consolidate key points and bring them to the C-suite deck for all projects.
Best agenda for a project Steering Committee
The best agenda for a steering committee meeting uses some of the information that you may have read on the project kick off deck, but is really hyper-focused on getting to the Information that has been completed. The agenda will also give focus to each of the workstreams of the project, how they generally stand in the triple constraint, and identify roadblocks for making decisions on how they can be removed.
The agenda should consist of a gathering time, being mindful that this group is comprised of functional leaders that have teams and other obligations. You want to build in time where they may get a drink of water, have a bio break, or stop by their dedicated locations to gather their information for the meeting.
If you have a meeting that is over thirty minutes, which sometimes happens early on the project, I do recommend having a settle-in or focus time. Thirty minutes is the golden time allotment for this type of meeting. It should be possible to get through all of the information and discussions in that time period. If you are keeping to the golden time allotment of thirty minutes, you can dive right into the content of the deck.
The first slide of the steering committee deck should be a high-level project overview which consolidates all of the individual work streams into a birdseye view of the project. This overview slide should be maintained by the project manager or project owner.
This slide will be an important asset that you can use as a starting point in creating a review for the c-suite deck outlined in another article. It will also be the unifying message agreed upon by all teams on the project.
The project overview should always convey the general sentiment of the project. Unlike other workstream slides that are directly data-driven, we add sentiment into the metric process in the overview because the feelings of how people are progressing is a strong indicator of any functional or organizational components being impacted. Sentiment can also be incorporated here by the project team or change management team. These members are observing from outside the actual work and can incorporate sentiment into the status while addressing intangible issues. These intangible issues could be a slow down to overwork, personality conflicts in the team, and other moral issues. This format will also help senior leadership see what the mix of resources and possible frustrations are affecting the ecosystem of day-to-day operations and the organizational roadmap between all the projects.
A consistent use of “stop lights” in project decks should be a standard. For your overview slide, show your triple constraints, but factor in feelings/sentiment. For example, the project may be in an amber status for schedule, budget, and scope; but if the team is feeling confident with a strong risk mitigation plan, the overall project can be represented as green. The schedule, budget, and scope should have status based on actual facts. If the schedule is amber, that means the work is actually running behind, but not critically. If the budget is red, that means the cost is burning much faster than the amount required to finish the remaining work. If this scope is green, that means no other work has been added to the project that will affect the schedule or cost.
To recap, the overall stop light can be in contrast to others based on emotion or mitigation plans, but schedule, budget, and scope should always be based on data and the facts as they are at the time of the meeting.
- Green = According to plan
- Amber = At risk and in need of a mitigation plan
- Red = Critical and needs attention
A slide with the high-level timeline should be presented and have an indicator of where you are in that timeline. This timeline will start as an exploratory view in the kick-off deck and slowly become more concrete as discovery sessions are completed and the requirements of the project are confirmed. This version of the timeline should have a consistent format across projects with enough detail for the teams to understand when work will fall, but not so detailed that a full view cannot be seen in one slide height.
On the overview slide, there should be a shortened timeline based on your milestones, including the last milestone passed, the current milestone being worked on, and the next one upcoming. A more detailed breakdown of all major milestones, in order of completion, can also be expressed in a slide following the high-level timeline. Communicating this information in multiple ways is helpful for teams and the people who understand information in different ways. As this may be too detailed for some teams while others may require it, use of this slide should be based on the project’s individual circumstances.
Workstreams are fundamentally a subset of work that can be divided by a specific functional area or a group of people completing the project work. Workstreams are normally applied when a project is larger, allowing individual representatives to be tasked with tying off loose ends and removing roadblocks to completing milestones. These responsibilities are segmented into workstreams when they do not hinder other work in a project, but also provide another functional breakdown layer. This additional layer offers an opportunity for those teams to work together more closely and have a more immediate representative for support and suggested mitigation steps.
There are a couple optional slides that are good to have depending on how detailed or how technical, or conversely non-technical, your project is. For instance, if the project is going to have substantial testing, it is a great idea to have a test case slide and a bug tracking slide. The test case slide will roll up all of the important testing metrics and any test cases that need to be unblocked. On the flip side, a bug tracking slide will help show any issues from testing, how they are being prioritized for solutions, and the rate at which they are resolved.
Cost & Budget
The steering committee often does not include a detailed budget slide; this is because your steering committee could have representatives externally from the company. If you are working with one partner or several, they could each have a steering committee member that is participating. Each partner should be aware of the piece they hold and communicate it to the project team in a stoplight format, but the amounts should not be shown. Your budget is generally something that is reviewed internally.
A slide that is always optional for steering committees is a “next steps” slide. Generally the overview and steering workstreams have all the information and mitigation steps outlined, making this slide redundant.
Quick Links & Appendix
I do recommend at the end of the deck to always include a “quick links” or a “top links” section. This provides an easy place for the teams to access a business requirement document, a full project timeline, or any other important information that may be referenced on a weekly basis.
Final notes on responsibilities
Project managers should only be responsible for maintaining the versions of the steering deck and ensuring that the right representatives are attending. Other tasks project managers are responsible for in the deck include: adjusting the status of the project overview, moving the point-in-time marker on the timeline slide, and updating the milestones.
Each individual workstream should be assigned a functional leader that is responsible for updating their respective slide and rolling that up to the project manager for the overview slide.
There are two important reasons for this:
- The project manager is normally trying to “herd cats” for both meeting attendance and mitigation processes to hit the larger project goals. They are not in day-to-day work and cannot update those areas easily.
- Assigning ownership to a publicly viewed slide provides a direct view on the workstreams performance and those who are managing the work. When there is direct responsibility for both the work and the status, a connecting thread in that communication is achieved.
Do’s and Dont’s of a Steering Committee
|Keep a consistent agenda and format that you can carry out with 99% of your steering meetings.
|Create many different stop lights or metrics that are vastly different between projects.
|Create a project overview that includes information at a glance and incorporates team sentiment.
|Go into too much detail that could be expressed in a workstream which follows deeper in the presentation.
|Use stoplights to convey status at the current point in time.
|Bring non-tangible sentiment into metric-driven areas such as budget and timeline.
|Break up larger functional areas into workstreams for faster mitigation and streamlined communication.
|Have project managers complete or review workstream slides in a steering review.
|Include optional slides that show important status messages, like test case and bug resolution statuses.
|Include foundational information that was discussed in the project kick-off, like teams or project culture.
|Have partners and workstream convey their current state of a budget into the triple constraint stop lights.
|Show actual budget numbers for the project in the steering deck.
|Provide supporting information from the team in the appendix, as well as “quick links” for the project.
|Include detailed solution slides, individual details of test cases or circumstances surrounding bugs.
Use our toolkit
PROJECT MANAGEMENT – PRESENTATION DECK TEMPLATE
Apply the knowledge from this article to our powerpoint and google slides template. Everything you need to run successful project management meetings and presentations.