August 13, 2025 • 46 mins
Ever sat in a steering committee meeting drowning in data but starving for decisions? You’re not alone—and it’s a sign your pack might be working against you.
In this solo episode, Fatimah shares what she’s learned from years of working with steering committees across some of the largest and most complex organisations internationally. She unpacks the critical elements that make a steering committee pack effective, cutting through the noise to help leaders focus on what matters most.
We explore the five essential elements every pack should include, why visual summaries beat wordy walls of text, and how to structure information so it actually supports strategic decision-making. Plus, Fatimah shares a few personal lessons from early career mistakes (including one pack she hopes never resurfaces).
Whether you're a project manager, a delivery lead, or part of a PMO supporting governance, this episode offers a blueprint for building steering committee packs that inform, influence, and drive outcomes.
🎧 Don’t forget! Registration is now open for the Global PMO Leader Conference, happening October 15th. Join over 1,000 project professionals from around the world. Link below;
https://www.thepmoleader.com/2025-annual-conference
In this episode, I cover:
0:00 Introduction & Conference Announcement
7:58 Understanding Steering Committees
14:37 Three Levels of Governance Explained
22:32 Purpose of Steering Committee Packs
30:16 Essential Components to Include
39:12 What to Leave Out
43:19 Personal Experiences and Lessons Learned
And more…
Have you built a PMO from the ground up—or thinking about it? Tune in to learn how to create a solid foundation that supports growth, governance, and agility. Then, share your PMO wins or challenges—I’d love to hear your Agile
Thank you for listening to Agile Ideas! If you enjoyed this episode, please share it with someone who might benefit from our discussions. Remember to rate us on your preferred podcast platform and follow us on social media for updates and more insightful content.
Thank you for listening. If you enjoyed this episode, I'd really appreciate it if you could share it with your friends and rate us. Let's spread the #AgileIdeas together!
We'd like to hear any feedback. www.agilemanagementoffice.com/contact
Don't miss out on exclusive access to special events, checklists, and blogs that are not available everywhere. Subscribe to our newsletter now at www.agilemanagementoffice.com/subscribe.
You can also find us on most social media channels by searching 'Agile Ideas'.
Follow me, your host, on LinkedIn - go to Fatimah Abbouchi - www.linkedin.com/in/fatimahabbouchi/
For all things Agile Ideas and to stay connected, visit our website below. It's your one-stop destination for all our episodes, blogs, and more. We hope you found today's episode enlightening. Until next time, keep innovating and exploring new Agile Ideas!
Learn more about podcast host Fatimah Abbouchi
...
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Fatimah Abbouchi (00:00):
You're listening to Agile Ideas, the
podcast hosted by FatimahAbbouchi.
For anyone listening out therenot having a good day, please
know there is help out there.
Hi everyone, and welcome backto another episode of Agile
Ideas.
I'm Fatima, CEO at AMO, mentalHealth Ambassador and your host.
(00:22):
In today's episode we will betalking about steering
committees, and I'll explain allabout that in just a moment,
but before that, I just want toremind everyone that we have the
Global PMO Leader Conferencehappening on October 15th.
(00:43):
It is a virtual conference andit generates over a thousand
attendees globally.
We have over 75 volunteers whoare currently assisting with
getting the conference ready.
It's completely free toregister and attend, and that's
(01:03):
thanks to our sponsors.
Free to register and attend,and that's thanks to our
sponsors.
So, for those of you who areinterested, I will include in
the show notes a link to theconference and I hope to see you
there.
Now on to the episode.
Have you ever sat in a steeringcommittee meeting and thought
(01:26):
why am I flipping through 40slides just to find the one
thing that I need?
The problem is steeringcommittees are there to help
make high impact decisions, andbad steering committee
presentations and PACs lead tobad decision and decision
paralysis.
(01:46):
Pacs are the signals tosteering committee that help to
guide what decisions you needthem to make and often, when
they're not done well, itcreates a whole lot of confusion
, and that confusion is justnoise.
Now, for those of you who arelistening, who probably haven't
(02:07):
heard about what a steeringcommittee is, it's there to help
guide projects and programs toactually stay on track in the
direction.
Hence the comment aroundsteering committee direction,
(02:27):
hence the comment aroundsteering committee stay on track
in the right direction.
For the life of the project or aprogram.
It's made up of a group ofsenior stakeholders.
Often there's a sponsor theperson or persons that are
paying or funding for theprogram or project along with
key decision makers who overseethe direction and progress of
the project's program initiative.
(02:48):
Think of it like a governingbody that provides the guidance
needed and makes those strategicdecisions that often can't be
made by the project or programmanager itself.
The way that I like to thinkabout things when I'm setting up
a new project, program, or evenwithin the portfolio, is I like
(03:11):
to think about things in a waythat categorizes governance into
three groups, and these threegroups of governance I apply and
have applied in everyengagement that I can recall for
at least the last 10 years,successfully.
So let me give you a quickoverview of the three different
(03:33):
governance groups and how tointroduce them for your projects
program, and then I'll tell youa bit more about how to make
sure that your steeringcommittee can be as best as
possible so you can get betteroutcomes, and I'll also tell you
about what to leave out of yoursteering committee.
(03:54):
So, in terms of governance,you've got to think of it this
way there are decisions andhierarchies that can and can't
be made Sorry, there aredecisions that can and can't be
made based on approvalhierarchies that exist already
within an organisation.
Typically, as a program orproject manager, you will have
(04:16):
some level of authority over theproject or program, and that
itself will be based on, often,some thresholds.
As an example, in most projectsI've seen over the years, there
is usually a small nominalamount depending on the size of
(04:37):
the organization.
In a large organization I'veseen it as low as ten thousand
dollars that a program or aproject manager has the ability
to make decisions as long as thecost doesn't exceed that.
They also have the ability tomake decisions on how projects
get managed, as long as theymeet the business requirements
and the scope of the project.
(04:57):
That was agreed up front.
There's other differentexamples of that that pertain to
other parts of the project, butjust to provide that example,
that is relevant for the purposeof level three, which to me is
the lowest level in my threelevel hierarchy for governance.
So project and program managerssit at level three, and often
(05:21):
there are many decisions thatcan be made that are level three
, meaning they don't needvisibility or escalation any
higher than that level.
Level two is what I woulddetermine as a steering
committee level, and thesteering committee level is
exactly the type of content thatyou would include in your
(05:44):
steering committee pack.
The steering committee itselfis often made up with the
project sponsor, which is asenior executive, and often
business unit operationalleaders that are impacted by the
project or providing resourcesto support the project.
There's often someone fromfinance and probably someone
from risk, and, depending on howbig or complex your project or
(06:07):
program are, there might bethird-party suppliers that are
involved in the program, like aconsultancy, et cetera.
They'll often meet at regularintervals as well, and they will
be there to provide strategicoversight, decision making.
They're also there to driveaccountability and help to
(06:27):
mitigate risks or address issues.
So think of that level two,steering committee level, as a
governing body that is thereoften to make sure that you meet
what deliver, what you promiseto deliver in terms of value for
the organization, thestakeholders.
Then we've got the third andfinal level, which is the top
(06:50):
level.
So, again, depending on theorganization, there might be
structural differences for thesethree levels, but level one of
governance is usually the seniorleadership team.
It could also be your executivecommittee, it could even be
your board, depending on thesize of the company, but
(07:11):
ultimately that is the directorlevel aspect of the organization
, where decisions that have beenendorsed by the steering
committee but don't sit withinthe thresholds of a steering
committee approvals goes up theline.
For example, the sponsor on thesteering committee might not
(07:32):
have the authority to make adecision over something that
impacts the project pertainingto timelines, pertaining to,
maybe, a budget, that's over thedelegation that they have, and
so therefore, that decision hasto go up the line.
Another example that's reallyrelevant for me right now is
where there is new obligationson the organisation.
(07:54):
These things go up to theexecutive committee, who are
those that are directlyaccountable for the organisation
, meaning its regulatory andcompliance obligations.
So just really quickly to recap, there is three levels Now,
depending on the size of theorganization, you may go further
down.
(08:14):
For example, level four might beteam member level.
That being said, I've neverreally had to use that and I
would be surprised if you neededto go any further.
So level three is your programproject level, where program
manager has the ability andauthority to make certain
decisions within thresholds.
Level two is your steeringcommittee, who makes decisions,
(08:35):
again within their delegation,and drives risk and issue
resolution and strategicoversight of the initiative.
And then, when needed, there'san escalation point up to level
one, which is your executivecommittee or senior leadership
team.
So always have that in mindwhen you're establishing
projects and programs for thevery first time, because doing
(08:57):
so will help you to make surethat you are in fact meeting the
relevant, necessary structuralobligations of governance from
the outset and stop you fromgetting caught out.
Now let's go back to thesteering committee pack.
This is a question that's comeup a few times.
(09:18):
I had heard it again recentlyand I thought it would be really
helpful to talk through thesteering committee pack what to
leave in and what to leave out.
So let's start off by talkingabout the purpose of a steering
committee pack.
The steering committee pack isnot just a status update.
It's used to make executivedecisions.
(09:40):
Now, of course, within any pack, you do want to give a progress
update, particularly becausesteering committees are usually
once a month.
Depending on the life of aprogram, they could be every few
months, but often I find almostevery organization is usually
once a month.
The smaller the project, themore frequent they will be, and
(10:01):
the longer project, the moredrawn out they'll be, and the
longer project, the more drawnout they'll be.
So the steering committee packis not there to just provide a
status update.
It's important to give thecontext quite quickly, and doing
so helps them to then be ableto make informed decisions.
So what you'd want to do ismake sure that you include a bit
(10:23):
of a background on progress,particularly as you may have
made some progress since thelast steering committee that you
talked about, and so thingslike what you've achieved since
the last steering committee, anyopen actions that you addressed
, any new information, anythingthat's going to really be the
(10:44):
foundational support items forbeing able to get the decisions
that you need.
I'll cover off what to includespecifically, but just to
reiterate, you're not there togive a status update.
It's an executive decisionmaking tool.
You need to give the contextquickly to enable them to get to
(11:04):
a point where they can makeinformed decisions.
You'd want to highlight the keyrisks, dependencies and
decision points.
Key risks are things that havenot become issues yet
Dependencies pertaining tothings that you may be dependent
on internally, from other teamsor even externally, from
regulators or from another thirdparty, and what key decision
(11:30):
points that you will be raisingin this steering committee.
What you want to do is makesure that there is enough
discussion relevant to thedecisions that you need made,
but doing so in in the minimaltime.
So you want enough informationfor them to make a decision, but
(11:51):
not too much that they drown inall of it.
Now, the cardinal rule of asteering committee is, if you
feel like there is informationthat is necessary to include in
that pack and in that meetingand you really feel strongly
about it, put it in the appendix, because the appendix, as I've
(12:13):
learned, is there to provideadditional context for those who
want to look at it, but itdoesn't directly link or inhibit
the ability to make thedecision that you're asking of.
As someone who receives PACsand reports all the time, I like
to skim through the appendix,but I do find that many
(12:34):
executives tend to not look atthat.
So be aware what you put inthere may or may not get read
and effectively, that's thepoint really.
So, now that we've covered offthe purpose of a steering
committee and the pack, let'stalk about what to include,
(12:54):
what's essential in a steeringcommittee pack, and what I'm
going to do is I'm going to takeyou through a real live example
of a steering committee packthat I currently prepare for one
of my clients and talk youthrough the relevance of it and
also some of the things I've hadto include.
(13:15):
Now, each pack and meeting willbe different, based on your
organization's maturity, size,expectations of the executives
involved.
So take what I'm giving you asa guide and then I will ask that
you apply that to yoursituation, based on feedback
(13:36):
that you get from your steeringcommittee members and leaders.
One of the things that can behelpful early and upfront,
before you go into numeroussteering committees, is it would
be a good idea to start yourfirst steering committee by
setting the scene in terms ofwhat you plan to cover in the
meetings going forward, settingthe scene in terms of what you
(13:57):
plan to cover in the meetingsgoing forward.
As an example, one of thethings relevant to an existing
client is a particular updatepertaining to a specific change
that they want to see regularly.
Now, that sort of change itselfis not something that would be
in a standard pack, but it issomething that our steering
committee and sponsor hasdirectly requested.
So it's good to get thatfeedback early and upfront.
(14:18):
Now, thinking about what toinclude, what is essential to
include, in your steeringcommittee pack.
Okay, so there is a number ofkey sections that you would want
to focus on.
What I'll first do is I willgive you an overview of some of
the essential components andthen I'll take you through that
(14:40):
real example of what I've gotand why I've had to personalize
it to suit the situation andenvironment that I'm in for one
of my recent clients.
So there is a number ofsections and, first and foremost
, you would want to include theexecutive summary overview.
Now, an executive summaryoverview is usually one or two
(15:02):
pages.
I prefer to keep it to one,which is usually quite visual
and high level.
It gives status at a glance forsomeone who just doesn't read
any other part of the pack, whojust doesn't read any other part
of the pack, and gives them aquick overview of what they need
to know progress decisionscoming up, key risks, key issues
(15:24):
, et cetera.
Now the way that you lay out anexecutive summary can vary
significantly.
Most people will put aexecutive summary in just text
format with bullet points.
Now the way that I've laid itout, which I find extremely
beneficial, is I've actually gota summary page that includes
(15:50):
the current and previous red,amber, green status or RAG
status, with the overallparagraph that outlines what the
status is in a nutshell.
I also highlight on that samepage the key decisions or
escalation points that need tobe discussed in that day.
I have a overview of the red,amber, green or RAG status
(16:17):
across the previous months.
That gives them an overview ofthe trend of health, trending
health across the months.
In the same one page layout Ialso have an overview of the key
components of the project andtheir RAG status and an overview
summary, for example, theschedule, scope, budget, the
(16:42):
resources, the change, and thenI have an overview for anything
that is red or amber in thatpoint in time, how we'll get to
green the key deliverable, thenext step, when it's due and who
is actually accountable for it.
And then, on the right handside, I would outline the key
activities completed since thelast report and the next
(17:04):
period's key activities, just tokeep everyone on track with
what's coming up and what's beenthe top.
Maybe six or seven milestonesthat number is not, there's no
math behind it, it's just whatconveniently fits on a summary
page.
And then your top five risks orissues.
(17:24):
Now, that sounds like a lot butlaid out really efficiently on a
page can be very well received,and it's something I've been
using quite often for all myclients and they seem to
resonate very well with it.
It's the talking point for thebeginning of a meeting and
really gives that snapshot.
(17:45):
With those traffic lightindicators, milestone progress,
it gives a really good overviewand a great basis to start your
conversation.
Now, in some instances youmight need to add an overview
executive summary text page,although it's rare that I do
that.
The only time I would do thatis when we're in a really
(18:06):
complex part of a program or aproject, for example nearing a
transition, where I may want toprovide more background and
context, where I may want toprovide more background and
context.
The same can be said of anotherkey, essential element, which
is progress against your plan.
Now, your progress against yourplan needs to be an overview.
(18:27):
Usually it's a very visualtimeline with key milestones.
I have a number of differentways that I do this.
One of them is utilizing acritical path view, and a
critical path view is asimplified version of my
detailed timeline but providesan overview of the critical path
activities and milestones thatwe need to meet to get to the
(18:51):
end of the project or program,and in that progress slide, or
what you would want to includeis call out any deviations and
or any, I guess, key risks tomilestones that are maybe behind
or at risk of being completedon track.
(19:11):
And you'll also want to makesure that you include any other
visual indicators.
For example, in some projectsthey might include a detailed
Gantt chart.
They might include a dashboardview of progress against
different streams.
There's really lots ofdifferent ways of doing it, but
to keep it really simple, theway that I've laid it out is I
(19:34):
have an overview of the criticalpath, which shows the key
phases and then the criticalpath milestones across the
phases.
And then I also have a nextslide which is more detailed.
For example, at the moment I'mgoing through a process where
I'm including a detailedtimeline for our transition,
(19:55):
including a detailed timelinefor our transition, and so
that's where, if they want todive into more detail beyond the
critical path, they can have alook at that as well.
So progress against the plan isthe second most important thing
to include in your steeringcommittee pack.
The third piece which is reallyimportant is risks issues,
dependencies.
Now, risk issues anddependencies can be done in lots
(20:18):
of different ways.
What I like to include is anoverview of, say, the top five
risks and issues and in thatsame overview I like to provide
a number of different visualaids to support understanding
the number of risks.
Risks by status so what'sclosed, what's in monitor state,
(20:40):
what's in progress, what's new?
The overview of risk bygovernance level, what I
explained early on.
So, level one, level two, levelthree that gives a good
overview to executives of howmany risks being managed at the
program level that has not beenraised to them.
It shows the sign of maturitybut also just the complexity of
(21:01):
the program.
Open risks by stream.
So if you've got multipledifferent streams or
sub-projects within your program.
Open risks by residual risklevel that is what the risk
level is when you take thelikelihood and the consequence
and bring them together.
Issues by status, what's new,what's being investigated,
(21:25):
what's resolved and so forth,and then issues by stream as
well.
Now some people like to includedetailed pages in the appendix
of explanations of those topfive risks or issues with more
information, in case someonewants to delve into.
What is that risk or issue,particularly if there's any that
are rated high or very high.
You can do that and that's easyaddition to the appendix.
(21:51):
I'll only do that when asked.
If people don't ask for it, Idon't add it because otherwise
you're creating unnecessary workfor yourself.
Now, for your top five risks orissues that you include, you
typically need to include yourrisk severity and also any
mitigation actions.
It's all well and good to callout top five risks and issues,
but without explaining whatyou're doing about them, there
(22:14):
is really no point, because ifthey are high or very high and
you don't have a mitigation, Iwould be concerned.
And then, finally, yourdependencies.
Now the dependencies can bedone in a couple of ways.
One of the ways that you coulddo this is you could include
that on a dashboard page summaryas a visual and again have some
graphs that outline thedependencies in the different
(22:36):
stages, etc.
But one of the better ways Ilike to do it is to include it
on my visual of my detailedtimeline, so I would actually
highlight and show a linkagebetween the different
dependencies and call them outas well.
These dependencies should bethe ones that are going to
derail your timelines if notaddressed.
(22:59):
Okay, so then we move into oneof the I guess one of the most
common and most important slidesin a steering committee pack,
and that is your financialsoverview.
Now, your financials overviewtypically is there to provide an
(23:20):
overview between your budgetand your spend today.
So, how much money did you getapproved for at the sponsor
level?
How much money have you spent?
What's the variance betweenthat?
What are the reasons for thevariance?
And then also, if there's anyadditional asks, if you have a
requirement for new resources,if you have a requirement for
(23:42):
new budget, for a change in thebudget, anything at all that
could be different to what wasoriginally outlined and agreed
early on, usually in a businesscase, before the project itself
kicked off.
This is where you wouldhighlight it.
Usually you'll find a financerepresentative who provides
(24:06):
input into the financial slidein larger organizations, their
finance business partners, andother times you have to do it
yourself.
So it's really important tohave a good view on what is your
budget, how you're tracking toyour budget, what you've spent
so far and what's the estimateto complete.
So how much more money do youneed to complete your project
(24:27):
and then call out the variancesand explanations to support that
and that summary slide?
There is something that youtypically don't really need to
talk to unless there is somevariance or some decision that
needs to be made.
And then the last kind of keyessential element is around
decisioning and decisionrequests.
Decisions need to be called outupfront and early, so I like to
(24:53):
do decisions in a couple ofways.
First and foremost, at theoutset of my steering committee
pack, in my executive summary,either in that visual slide I
mentioned or in a supplementaryslide, I will have an overview
of the key discussion points,which usually pertain to the
decisions that I'm looking for.
I also have a decisionsregister that is managed offline
(25:18):
in SharePoint most often, and Iextract those decisions on a
regular basis and I include themin the steering committee pack,
up front and early.
And just to give you an exampleof what I would include in
something like that.
So, just like you would haveyour actions log, the decisions
log typically outlines what thedecision is.
(25:39):
Is it a change request?
Is it something you want themto know?
Is it an escalation that needsto go further up the line?
So there's a number of thingsthat you can include.
It's a decision, an escalationor a noting item, what it
relates to, what's the decisionrequired, who's the owner, owner
and the status of it.
Now those decisions themselvestypically have come up from
(26:02):
level three, the program level,and sometimes decisions that
need to go up to level one, thatsenior executive level.
So you'd outline that in asummary table and then you would
reference the pages that you'regoing to cover off throughout
the pack and throughout themeeting to help the steering
committee follow along.
So that's the first sort ofplace that I would reference it.
(26:25):
The second place I wouldreference it is on the actual
detail page.
For example, if I'm looking fora decision on a particular
change request and I need togive context and background, I
would include a supplementarypage and on that page I would
have a decision box.
That's quite clear, it'shighlighted, it's you know
borders are, read, says decisionrequired and calls out the
(26:47):
exact same decision that wasreferenced on that decision log
page so that you can followalong.
You need to give the historythat's relevant, but keep it
minimal and just enough contextto be able to make that decision
.
Now, in summary, the fiveessential elements is your
executive summary slash snapshotand that, as I said, visual is
(27:09):
always works best.
Your progress against plan,which can be your critical path
or your detailed timeline thatshows any deviations from the
plan, and also a visual, whetherit's your Gantt chart, a
milestone chart or similar.
Your risk issues anddependencies, usually over a
couple of pages one for risksand issues, with those graphs,
(27:30):
mitigations called out, and thena dependency view can be on its
own or it can be incorporatedin the progress plan timeline
page.
A financial slash resourceupdate, which is usually left in
the appendix unless there's adiscussion around it.
And then your decision log,which is at the front and early,
but also referenced throughoutwhere the decisions need to be
(27:53):
made, reference throughout wherethe decisions need to be made.
Now there are a few things thatI would recommend you keep in
mind.
But before we do that, let mejust take you through a couple
more examples of things Igenuinely have in a real life
steering committee pack that atthe moment goes all the way up
to the CFO level of a very, verylarge company, one of
(28:15):
Australia's largest companies.
So in that we would typicallyhave a running view of all the
previous actions.
We would have a running view ofthe decisions, escalations and
noting items.
I would then kick off with theexecutive summary and in that
executive summary I wouldoutline, as I said, the
essential components that wewant to discuss for that day and
(28:38):
enable people to dig in.
We would revisit the timeline,be it the critical path or the
detailed timelines, and thenoften in programs and projects
of this size, we would have abreakdown by the individual
subprojects or streams.
Within and in that subprojectsor streams you would want to
provide an update on how thestream is going, what their RAG
(29:01):
status are they red, amber orgreen a trend from the last
report and also whether they'reimproving, staying steady or
declining, with some commentary.
You have your risk and issuespage as well, and then also, in
addition to that, I like toinclude, and always have, my
steering committee charter andmembers page to provide an
(29:24):
overview so that if anyone needsto reflect on it, particularly
when we have guests that mayjoin a steering committee
upcoming leave relevant for alarge, complex program.
And then also I would includean overview of what the
definitions are pertaining toRAG status and provide that
information so that they canunderstand when something's
(29:47):
green, amber or red, the reasonsbehind it.
Now, the steering committee packdoes vary from time to time.
As I said, in one monthsteering committee I would
include more detail relating tocommunication checkpoints we've
got to make, or I would includean overview of third party
status and the activitiespertaining to those third
(30:09):
parties when the program iscomplex.
But as long as you focus onthose five key areas I mentioned
, you would be really well setup for your steering committee,
okay, so now I want to talkabout what to leave out.
Now, when you think aboutsteering committee packs, often
(30:31):
what people typically find and Iknow because I've been one of
these people who loves detailsometimes you go way over the
top and put in way too muchdetail.
Now, the problem with that isyou usually only have a very
limited time for your steeringcommittee.
I've never really seen themmore than 30 minutes, on the odd
(30:54):
occasion 45.
But excessive detail is adistraction.
It's going back to what I saidearlier about the excessive
noise.
So you don't want to includefull raid logs, you don't want
to include all the details forthe risk, all the actions, you
don't want to include all of thenitty-gritty detail around the
design or all the issues fromthat level three.
(31:15):
So think about everything at alevel three.
At the program, project level.
You can manage.
You can manage as a program ora project and you only want to
raise things that are relevant.
Otherwise it becomes adistraction from the key
decisions you need to drive theproject forward.
You also don't want to includeeverything that happened at the
last meeting.
All I would do with reflectingon the last meeting is the
(31:38):
actions and have a summary tableat the beginning of any open
actions, not only from the lastmeeting but from any previous
meetings that have not beenclosed.
Now I'll give you a tip One ofmy favorite things to do when
logging actions from previousmeetings is I like to date the
actions and number them in a waythat makes it really easy for
(32:00):
anyone to see how long thataction's been open.
As an example, if I had anaction, let's say, on the 31st
of July 2025, then my actionwould read 2025-07-31.
So the date, the year, themonth, the day backwards .01,
(32:23):
and then the subsequent actionwould be .2, .3, .4, and so on.
What that means is when I getinto my August, september,
october steering committees andI look at my actions register
and my actions log and I seesomething dated with July, I'll
know that that action isactually from that month and it
gives me a good visual and itcuts out the extra noise on the
(32:43):
actions page, because you won'tnecessarily be able to fit
everything that you want to.
So only include the actionsthat are open.
Don't worry about providing anyfurther information on meeting
minutes.
You also don't want to providewalls and walls and walls of
text, because I've done thatmany times and it seems like
(33:04):
steering committee members areallergic to it.
They don't like it.
It's not helpful.
You think you need to provideall the detail To counteract
that for people like myself whocan be quite detailed.
I've started to prepare thatfor my own benefit and having it
in my in my notes so that whenI get asked questions I can
reflect on those, as opposed toincluding
(33:25):
it in the pack.
Don't include data that linksto nothing.
So be very aware that if youinclude a graph with numbers in
it, the numbers need to becorrect.
You need to make sure thatthere is a link or something
that supports the data thatyou're including.
All my actions link to anactions register.
All my decisions link to adecision register.
(33:46):
All my risks, issues,dependencies link to their own
sources of truth.
There is a direct throughputand a linkage between all of
those as well.
All my actions, decisions, riskissues, dependencies, et cetera
all linked to one another, andI've done that to make sure that
we understand when a riskbecomes an issue, where the
issue came from, when an actionor a decision is made, what
(34:07):
change request it may relate to,and so forth.
Don't include metrics in therethat are irrelevant and actually
don't provideany substance or value.
And also, you don't want toprovide too much unnecessary
information at a steeringcommittee where you don't have
time to explain it.
(34:27):
For example, if you have amajor issue and you're going to
need some specific attention tothat issue, then you might need
to call a subsequent meeting todeep dive into it, or you may
need to provide additional timefor people to absorb that and
really come to the steeringcommittee prepared to talk
through it.
You also want to think aboutmaking sure that, when you're
(34:54):
running your steering committee,that the right people who have
been agreed as members of thesteering committee are present.
Otherwise, you will run asteering committee and not all
the decision makers will bethere, and then sometimes, in
stricter governance, you willfind that you don't meet the
requirements and therefore thedecision could be null and void.
(35:17):
As a really good example ofthat, I worked in an
organization where the programwas being funded by a third
party, and so we agreed thatthere would be a quorum of
members that needed to bepresent for a steering committee
to go ahead, of members thatneeded to be present for a
steering committee to go ahead,and where five of the seven
members weren't present, thesteering committee had to be
(35:37):
cancelled, which is a waste oftime, and you should know that
upfront if people aren't comingalong, but unfortunately it
doesn't always work that way, soyou might need to have
something like that, verysimilar.
What you don't want to do ismake decisions and not have the
right people in the room.
Now, in some instances, thesponsor can override the
decision because they might beof a senior level and they have
(35:58):
the ability to do that, and ifthat's the case, that's fine.
But where you've got a numberof head of or senior managers
that are all the same level,that represent their functions
and they all need to be part ofthat decision, you need to be
careful not to bemaking decisions without them.
Now, from a structuralperspective, I sort of outlined
briefly how I would lay it out.
(36:19):
You've got your agenda, whichis similar each month but also
can be modified.
You also have your actions,your decisions, and then you
move into your executive summary.
You want to call out yourdecisions right up front and
early, directly after youractions, so that they don't get
lost and also people know whatthey're there to do.
And it also helps to keep theflow of the meeting because you
(36:40):
know what hasn't been decidedand that it's coming up.
You want to use graphs, charts,etc.
You want to try to create thoseup front and early and reuse
them, as opposed to having tocustomise each time.
And then you also want to makesure that you are consistent as
much as possible in the layoutof your pack.
(37:01):
Now, the consistency relates toenabling the steering committee
members, who don't have lotsand lots of time to pre-read the
packs, the ability to skimthrough it in a way that
becomes comforting for them.
Speaking of pre-reading, myrule of thumb is you want to
(37:21):
give a minimum of two days forpre-reading, so you want to send
the pack out two days before asteering committee, at least.
Sometimes, depending on howcomplex the program is, you
might have to send it out a weekbefore.
I know we definitely send it aweek before for more senior
executives at that level one,but for a steering committee,
two, three days minimum two daysis ideal to give them a chance
(37:44):
to pre-read the pack.
The assumption for a lot ofsteering committees is that the
pack is read prior to themeeting and so you can focus on
making the right decisions.
And then, finally, the lengthof the pack.
As I said, it's okay to havenumerous amounts in the appendix
, but the core length of thepack typically, depending on the
(38:04):
size of your program, you mighthave five to seven pages.
You know, I find on average Isit around seven or eight,
depending on what part of theprogram we're in, and then
everything else in the appendix.
I mean, I've been known to have10, 15 pages in the appendix
and that's okay.
You just want to make sure thatyou provide that context in the
(38:32):
up first steering committee,that you will include things in
the appendix that theydon't have to read.
One thing that is a reallyimportant thing that I learned
along the way sometimes, whenyou're drafting these packs, you
may need to get a review orapproval from your line manager
or whoever it is that needs toendorse it before the steering
committee pack goes out.
And a top tip for me is alwayssend it out in PDF format if you
(38:56):
are wanting a manager to reviewit, but also when you send it
out to members.
Two reasons for that One, whenyou send it out to someone you
want to review and give youfeedback.
If they are anything like mostexecs, they're on the go and on
their phones and so skimmingthrough a file that's in
PowerPoint or similar is toocomplicated, whereas in PDF you
(39:16):
can actually skim through itquite easily.
So it makes it quicker andeasier for them.
And the reason I would send itto members in PDF is because
people are notoriously bad andmodifying a steering committee
pack after the pack's beendistributed, and we don't want
that because the pack that yousent for pre-reading needs to
match the pack that you presenton the day, otherwise it can
(39:38):
cause mistrust and confusion.
So I like to start my packswith the naming convention that
includes the date and the wordsdraft, and when the pack has
been distributed I convert it toPDF and I mark them as final.
That way, people always knowthey're receiving the PDF
version, which is the finaldocument, and not having to
worry that changes are beingmade
(39:58):
after they've read them.
Now a few last tips.
Getting the pack right ismaking sure that you build the
pack with the audience in mind.
Remember, executives havelimited time.
They just need to know whatthey need to know and nothing
else.
You want to make sure youreview the pack with the
relevant person or persons whoare going to provide you
(40:21):
valuable input before youcirculate.
They might pick up on somethingthat you don't, particularly if
you're preparing the pack onbehalf of a group of people.
You don't want to go into asteering committee and your line
manager, who may not be thesponsor or the steering
committee chairperson, and notmake sure that they are across
what's going to be raised interms of decisions, etc.
(40:42):
So, working backwards, I wouldlike to set a pre-review meeting
when I'm drafting the pack withthat manager, and I'd also then
do a quick follow-up before Iactually get the
pack out for distribution.
Now, a good steering committeepack is worth its weight in gold
.
It provides the ability to makebetter decisions.
The meetings are moreproductive.
(41:02):
You need to focus on what'sreally necessary to drive your
program or project forward, andthe steering committee itself is
a really good segue into whatyou are able then to proliferate
in terms of insights andinformation down to the broader
project and program team.
(41:23):
So you want to be able tocreate a pack that makes the
decisions that you can thenrelay back to keep the project
moving forward.
One question you can think ofwhen preparing your presentation
is this does this slide orsection or visual, or whatever
it is that you're doing help theexecutive to make a decision or
(41:44):
act or actually inform them onsomething that they would need
for their higher ups?
If not,cut it out now.
My experience with steeringcommittee packs is very vast and
varied, and I've had lots ofgreat and lots of bad
experiences along the way.
(42:05):
When I first started in thecorporate world.
My first experience of creatinga steering committee pack was
literally one of the worst I'veever ever come across, and that
is because I had no idea what asteering committee was.
Simply put, I did not know I'dcome up the project journey as
(42:30):
an administrator and reallydidn't get involved in so much
in those, and I also didn'tattend those meetings, so I had
no idea what to expect.
So I think I overwhelmed theexecutives far too much and
provided every single possibledetail I could think of and the
pack was huge and surprise,surprise, we didn't get through
it.
Inside that steering committeeslot that we had with those
(42:53):
executives.
I also, in one of my firstexperiences, minuted the meeting
, took the actions and themeeting notes, and I recall
after a 30-minute meeting I hadover seven or eight pages of
notes.
Why?
Because I had no idea whattaking steering committee
meeting minutes or actionsreally was.
I literally wrote down everysingle word that everyone was
(43:20):
saying as quickly as I possiblycould, which was completely
useless and a waste of time.
But I learned the hard way andthat's what happens when you
work in this corporate world orin life in general.
So don't do the mistakes I madeand make your steering
committee something that peoplelook forward to, something that
people get value from attendingand something that really helps
(43:42):
you as the project manager, thePMO manager, the program manager
, to drive your project forward.
Without that support, youreally are going to struggle to
get the value and to deliver theoutcomes.
So use it to your advantage.
Make your steering committeepack and meeting work for you,
(44:03):
not the other way around.
So, in summary, there arethings to include in your pack
andthings not to include.
You want to keep it consistent.
You want to front load yourdecisions.
You want to keep your detail inthe appendix, you want to make
sure you send it out in advanceand you want to make sure there
is continuity with all of youractions, decisions, risks, etc.
(44:26):
All throughout each pack as yougo, so that the story continues
in an informed way.
You want to give committeemembers the right context
quickly.
You want to highlight key risks, dependencies and decision
points early and you want to beable to help executives make
informed decisions and havediscussions relevant, but in the
(44:46):
most minimal time.
So don't be one of those peoplewho sits in a steering
committee and wonders why thereis 50 pages to flip through that
don't actually provide thestory of what you're there to do
, and it's bloated, it'sinefficient, it's unclear and it
becomes wasted time.
Instead, enable your steeringcommittee to make high impact
(45:09):
decisions with good qualitypacks that are clearly laid out,
that support doing it right.
So that's it, guys.
I hope you have enjoyed thisepisode.
It's a little bit different towhat we normally do, but if you
did find it helpful this bit ofa deep dive into the steering
(45:29):
committee packs world, pleaselet me know so I know to do more
or less content like this.
Thank you for listening.
Thank you so much for listeningto this podcast.
Please share this with someoneor rate it if you enjoyed it.
Don't forget to follow us onsocial media and to stay up to
date with all things Agile Ideas, go to our website, www.
(45:50):
agilemanagementoffice.
com.
I hope you've been able tolearn, feel or be inspired today
.
Until next time, what's yourAgile Idea?
You're listening to Agile Ideas, the
podcast hosted by FatimahAbbouchi.
For anyone listening out therenot having a good day, please
know there is help out there.
Hi everyone, and welcome backto another episode of Agile
Ideas.
I'm Fatima, CEO at AMO, mentalHealth Ambassador and your host.
(00:22):
In today's episode we will betalking about steering
committees, and I'll explain allabout that in just a moment,
but before that, I just want toremind everyone that we have the
Global PMO Leader Conferencehappening on October 15th.
(00:43):
It is a virtual conference andit generates over a thousand
attendees globally.
We have over 75 volunteers whoare currently assisting with
getting the conference ready.
It's completely free toregister and attend, and that's
(01:03):
thanks to our sponsors.
Free to register and attend,and that's thanks to our
sponsors.
So, for those of you who areinterested, I will include in
the show notes a link to theconference and I hope to see you
there.
Now on to the episode.
Have you ever sat in a steeringcommittee meeting and thought
(01:26):
why am I flipping through 40slides just to find the one
thing that I need?
The problem is steeringcommittees are there to help
make high impact decisions, andbad steering committee
presentations and PACs lead tobad decision and decision
paralysis.
(01:46):
Pacs are the signals tosteering committee that help to
guide what decisions you needthem to make and often, when
they're not done well, itcreates a whole lot of confusion
, and that confusion is justnoise.
Now, for those of you who arelistening, who probably haven't
(02:07):
heard about what a steeringcommittee is, it's there to help
guide projects and programs toactually stay on track in the
direction.
Hence the comment aroundsteering committee direction,
(02:27):
hence the comment aroundsteering committee stay on track
in the right direction.
For the life of the project or aprogram.
It's made up of a group ofsenior stakeholders.
Often there's a sponsor theperson or persons that are
paying or funding for theprogram or project along with
key decision makers who overseethe direction and progress of
the project's program initiative.
(02:48):
Think of it like a governingbody that provides the guidance
needed and makes those strategicdecisions that often can't be
made by the project or programmanager itself.
The way that I like to thinkabout things when I'm setting up
a new project, program, or evenwithin the portfolio, is I like
(03:11):
to think about things in a waythat categorizes governance into
three groups, and these threegroups of governance I apply and
have applied in everyengagement that I can recall for
at least the last 10 years,successfully.
So let me give you a quickoverview of the three different
(03:33):
governance groups and how tointroduce them for your projects
program, and then I'll tell youa bit more about how to make
sure that your steeringcommittee can be as best as
possible so you can get betteroutcomes, and I'll also tell you
about what to leave out of yoursteering committee.
(03:54):
So, in terms of governance,you've got to think of it this
way there are decisions andhierarchies that can and can't
be made Sorry, there aredecisions that can and can't be
made based on approvalhierarchies that exist already
within an organisation.
Typically, as a program orproject manager, you will have
(04:16):
some level of authority over theproject or program, and that
itself will be based on, often,some thresholds.
As an example, in most projectsI've seen over the years, there
is usually a small nominalamount depending on the size of
(04:37):
the organization.
In a large organization I'veseen it as low as ten thousand
dollars that a program or aproject manager has the ability
to make decisions as long as thecost doesn't exceed that.
They also have the ability tomake decisions on how projects
get managed, as long as theymeet the business requirements
and the scope of the project.
(04:57):
That was agreed up front.
There's other differentexamples of that that pertain to
other parts of the project, butjust to provide that example,
that is relevant for the purposeof level three, which to me is
the lowest level in my threelevel hierarchy for governance.
So project and program managerssit at level three, and often
(05:21):
there are many decisions thatcan be made that are level three
, meaning they don't needvisibility or escalation any
higher than that level.
Level two is what I woulddetermine as a steering
committee level, and thesteering committee level is
exactly the type of content thatyou would include in your
(05:44):
steering committee pack.
The steering committee itselfis often made up with the
project sponsor, which is asenior executive, and often
business unit operationalleaders that are impacted by the
project or providing resourcesto support the project.
There's often someone fromfinance and probably someone
from risk, and, depending on howbig or complex your project or
(06:07):
program are, there might bethird-party suppliers that are
involved in the program, like aconsultancy, et cetera.
They'll often meet at regularintervals as well, and they will
be there to provide strategicoversight, decision making.
They're also there to driveaccountability and help to
(06:27):
mitigate risks or address issues.
So think of that level two,steering committee level, as a
governing body that is thereoften to make sure that you meet
what deliver, what you promiseto deliver in terms of value for
the organization, thestakeholders.
Then we've got the third andfinal level, which is the top
(06:50):
level.
So, again, depending on theorganization, there might be
structural differences for thesethree levels, but level one of
governance is usually the seniorleadership team.
It could also be your executivecommittee, it could even be
your board, depending on thesize of the company, but
(07:11):
ultimately that is the directorlevel aspect of the organization
, where decisions that have beenendorsed by the steering
committee but don't sit withinthe thresholds of a steering
committee approvals goes up theline.
For example, the sponsor on thesteering committee might not
(07:32):
have the authority to make adecision over something that
impacts the project pertainingto timelines, pertaining to,
maybe, a budget, that's over thedelegation that they have, and
so therefore, that decision hasto go up the line.
Another example that's reallyrelevant for me right now is
where there is new obligationson the organisation.
(07:54):
These things go up to theexecutive committee, who are
those that are directlyaccountable for the organisation
, meaning its regulatory andcompliance obligations.
So just really quickly to recap, there is three levels Now,
depending on the size of theorganization, you may go further
down.
(08:14):
For example, level four might beteam member level.
That being said, I've neverreally had to use that and I
would be surprised if you neededto go any further.
So level three is your programproject level, where program
manager has the ability andauthority to make certain
decisions within thresholds.
Level two is your steeringcommittee, who makes decisions,
(08:35):
again within their delegation,and drives risk and issue
resolution and strategicoversight of the initiative.
And then, when needed, there'san escalation point up to level
one, which is your executivecommittee or senior leadership
team.
So always have that in mindwhen you're establishing
projects and programs for thevery first time, because doing
(08:57):
so will help you to make surethat you are in fact meeting the
relevant, necessary structuralobligations of governance from
the outset and stop you fromgetting caught out.
Now let's go back to thesteering committee pack.
This is a question that's comeup a few times.
(09:18):
I had heard it again recentlyand I thought it would be really
helpful to talk through thesteering committee pack what to
leave in and what to leave out.
So let's start off by talkingabout the purpose of a steering
committee pack.
The steering committee pack isnot just a status update.
It's used to make executivedecisions.
(09:40):
Now, of course, within any pack, you do want to give a progress
update, particularly becausesteering committees are usually
once a month.
Depending on the life of aprogram, they could be every few
months, but often I find almostevery organization is usually
once a month.
The smaller the project, themore frequent they will be, and
(10:01):
the longer project, the moredrawn out they'll be, and the
longer project, the more drawnout they'll be.
So the steering committee packis not there to just provide a
status update.
It's important to give thecontext quite quickly, and doing
so helps them to then be ableto make informed decisions.
So what you'd want to do ismake sure that you include a bit
(10:23):
of a background on progress,particularly as you may have
made some progress since thelast steering committee that you
talked about, and so thingslike what you've achieved since
the last steering committee, anyopen actions that you addressed
, any new information, anythingthat's going to really be the
(10:44):
foundational support items forbeing able to get the decisions
that you need.
I'll cover off what to includespecifically, but just to
reiterate, you're not there togive a status update.
It's an executive decisionmaking tool.
You need to give the contextquickly to enable them to get to
(11:04):
a point where they can makeinformed decisions.
You'd want to highlight the keyrisks, dependencies and
decision points.
Key risks are things that havenot become issues yet
Dependencies pertaining tothings that you may be dependent
on internally, from other teamsor even externally, from
regulators or from another thirdparty, and what key decision
(11:30):
points that you will be raisingin this steering committee.
What you want to do is makesure that there is enough
discussion relevant to thedecisions that you need made,
but doing so in in the minimaltime.
So you want enough informationfor them to make a decision, but
(11:51):
not too much that they drown inall of it.
Now, the cardinal rule of asteering committee is, if you
feel like there is informationthat is necessary to include in
that pack and in that meetingand you really feel strongly
about it, put it in the appendix, because the appendix, as I've
(12:13):
learned, is there to provideadditional context for those who
want to look at it, but itdoesn't directly link or inhibit
the ability to make thedecision that you're asking of.
As someone who receives PACsand reports all the time, I like
to skim through the appendix,but I do find that many
(12:34):
executives tend to not look atthat.
So be aware what you put inthere may or may not get read
and effectively, that's thepoint really.
So, now that we've covered offthe purpose of a steering
committee and the pack, let'stalk about what to include,
(12:54):
what's essential in a steeringcommittee pack, and what I'm
going to do is I'm going to takeyou through a real live example
of a steering committee packthat I currently prepare for one
of my clients and talk youthrough the relevance of it and
also some of the things I've hadto include.
(13:15):
Now, each pack and meeting willbe different, based on your
organization's maturity, size,expectations of the executives
involved.
So take what I'm giving you asa guide and then I will ask that
you apply that to yoursituation, based on feedback
(13:36):
that you get from your steeringcommittee members and leaders.
One of the things that can behelpful early and upfront,
before you go into numeroussteering committees, is it would
be a good idea to start yourfirst steering committee by
setting the scene in terms ofwhat you plan to cover in the
meetings going forward, settingthe scene in terms of what you
(13:57):
plan to cover in the meetingsgoing forward.
As an example, one of thethings relevant to an existing
client is a particular updatepertaining to a specific change
that they want to see regularly.
Now, that sort of change itselfis not something that would be
in a standard pack, but it issomething that our steering
committee and sponsor hasdirectly requested.
So it's good to get thatfeedback early and upfront.
(14:18):
Now, thinking about what toinclude, what is essential to
include, in your steeringcommittee pack.
Okay, so there is a number ofkey sections that you would want
to focus on.
What I'll first do is I willgive you an overview of some of
the essential components andthen I'll take you through that
(14:40):
real example of what I've gotand why I've had to personalize
it to suit the situation andenvironment that I'm in for one
of my recent clients.
So there is a number ofsections and, first and foremost
, you would want to include theexecutive summary overview.
Now, an executive summaryoverview is usually one or two
(15:02):
pages.
I prefer to keep it to one,which is usually quite visual
and high level.
It gives status at a glance forsomeone who just doesn't read
any other part of the pack, whojust doesn't read any other part
of the pack, and gives them aquick overview of what they need
to know progress decisionscoming up, key risks, key issues
(15:24):
, et cetera.
Now the way that you lay out anexecutive summary can vary
significantly.
Most people will put aexecutive summary in just text
format with bullet points.
Now the way that I've laid itout, which I find extremely
beneficial, is I've actually gota summary page that includes
(15:50):
the current and previous red,amber, green status or RAG
status, with the overallparagraph that outlines what the
status is in a nutshell.
I also highlight on that samepage the key decisions or
escalation points that need tobe discussed in that day.
I have a overview of the red,amber, green or RAG status
(16:17):
across the previous months.
That gives them an overview ofthe trend of health, trending
health across the months.
In the same one page layout Ialso have an overview of the key
components of the project andtheir RAG status and an overview
summary, for example, theschedule, scope, budget, the
(16:42):
resources, the change, and thenI have an overview for anything
that is red or amber in thatpoint in time, how we'll get to
green the key deliverable, thenext step, when it's due and who
is actually accountable for it.
And then, on the right handside, I would outline the key
activities completed since thelast report and the next
(17:04):
period's key activities, just tokeep everyone on track with
what's coming up and what's beenthe top.
Maybe six or seven milestonesthat number is not, there's no
math behind it, it's just whatconveniently fits on a summary
page.
And then your top five risks orissues.
(17:24):
Now, that sounds like a lot butlaid out really efficiently on a
page can be very well received,and it's something I've been
using quite often for all myclients and they seem to
resonate very well with it.
It's the talking point for thebeginning of a meeting and
really gives that snapshot.
(17:45):
With those traffic lightindicators, milestone progress,
it gives a really good overviewand a great basis to start your
conversation.
Now, in some instances youmight need to add an overview
executive summary text page,although it's rare that I do
that.
The only time I would do thatis when we're in a really
(18:06):
complex part of a program or aproject, for example nearing a
transition, where I may want toprovide more background and
context, where I may want toprovide more background and
context.
The same can be said of anotherkey, essential element, which
is progress against your plan.
Now, your progress against yourplan needs to be an overview.
(18:27):
Usually it's a very visualtimeline with key milestones.
I have a number of differentways that I do this.
One of them is utilizing acritical path view, and a
critical path view is asimplified version of my
detailed timeline but providesan overview of the critical path
activities and milestones thatwe need to meet to get to the
(18:51):
end of the project or program,and in that progress slide, or
what you would want to includeis call out any deviations and
or any, I guess, key risks tomilestones that are maybe behind
or at risk of being completedon track.
(19:11):
And you'll also want to makesure that you include any other
visual indicators.
For example, in some projectsthey might include a detailed
Gantt chart.
They might include a dashboardview of progress against
different streams.
There's really lots ofdifferent ways of doing it, but
to keep it really simple, theway that I've laid it out is I
(19:34):
have an overview of the criticalpath, which shows the key
phases and then the criticalpath milestones across the
phases.
And then I also have a nextslide which is more detailed.
For example, at the moment I'mgoing through a process where
I'm including a detailedtimeline for our transition,
(19:55):
including a detailed timelinefor our transition, and so
that's where, if they want todive into more detail beyond the
critical path, they can have alook at that as well.
So progress against the plan isthe second most important thing
to include in your steeringcommittee pack.
The third piece which is reallyimportant is risks issues,
dependencies.
Now, risk issues anddependencies can be done in lots
(20:18):
of different ways.
What I like to include is anoverview of, say, the top five
risks and issues and in thatsame overview I like to provide
a number of different visualaids to support understanding
the number of risks.
Risks by status so what'sclosed, what's in monitor state,
(20:40):
what's in progress, what's new?
The overview of risk bygovernance level, what I
explained early on.
So, level one, level two, levelthree that gives a good
overview to executives of howmany risks being managed at the
program level that has not beenraised to them.
It shows the sign of maturitybut also just the complexity of
(21:01):
the program.
Open risks by stream.
So if you've got multipledifferent streams or
sub-projects within your program.
Open risks by residual risklevel that is what the risk
level is when you take thelikelihood and the consequence
and bring them together.
Issues by status, what's new,what's being investigated,
(21:25):
what's resolved and so forth,and then issues by stream as
well.
Now some people like to includedetailed pages in the appendix
of explanations of those topfive risks or issues with more
information, in case someonewants to delve into.
What is that risk or issue,particularly if there's any that
are rated high or very high.
You can do that and that's easyaddition to the appendix.
(21:51):
I'll only do that when asked.
If people don't ask for it, Idon't add it because otherwise
you're creating unnecessary workfor yourself.
Now, for your top five risks orissues that you include, you
typically need to include yourrisk severity and also any
mitigation actions.
It's all well and good to callout top five risks and issues,
but without explaining whatyou're doing about them, there
(22:14):
is really no point, because ifthey are high or very high and
you don't have a mitigation, Iwould be concerned.
And then, finally, yourdependencies.
Now the dependencies can bedone in a couple of ways.
One of the ways that you coulddo this is you could include
that on a dashboard page summaryas a visual and again have some
graphs that outline thedependencies in the different
(22:36):
stages, etc.
But one of the better ways Ilike to do it is to include it
on my visual of my detailedtimeline, so I would actually
highlight and show a linkagebetween the different
dependencies and call them outas well.
These dependencies should bethe ones that are going to
derail your timelines if notaddressed.
(22:59):
Okay, so then we move into oneof the I guess one of the most
common and most important slidesin a steering committee pack,
and that is your financialsoverview.
Now, your financials overviewtypically is there to provide an
(23:20):
overview between your budgetand your spend today.
So, how much money did you getapproved for at the sponsor
level?
How much money have you spent?
What's the variance betweenthat?
What are the reasons for thevariance?
And then also, if there's anyadditional asks, if you have a
requirement for new resources,if you have a requirement for
(23:42):
new budget, for a change in thebudget, anything at all that
could be different to what wasoriginally outlined and agreed
early on, usually in a businesscase, before the project itself
kicked off.
This is where you wouldhighlight it.
Usually you'll find a financerepresentative who provides
(24:06):
input into the financial slidein larger organizations, their
finance business partners, andother times you have to do it
yourself.
So it's really important tohave a good view on what is your
budget, how you're tracking toyour budget, what you've spent
so far and what's the estimateto complete.
So how much more money do youneed to complete your project
(24:27):
and then call out the variancesand explanations to support that
and that summary slide?
There is something that youtypically don't really need to
talk to unless there is somevariance or some decision that
needs to be made.
And then the last kind of keyessential element is around
decisioning and decisionrequests.
Decisions need to be called outupfront and early, so I like to
(24:53):
do decisions in a couple ofways.
First and foremost, at theoutset of my steering committee
pack, in my executive summary,either in that visual slide I
mentioned or in a supplementaryslide, I will have an overview
of the key discussion points,which usually pertain to the
decisions that I'm looking for.
I also have a decisionsregister that is managed offline
(25:18):
in SharePoint most often, and Iextract those decisions on a
regular basis and I include themin the steering committee pack,
up front and early.
And just to give you an exampleof what I would include in
something like that.
So, just like you would haveyour actions log, the decisions
log typically outlines what thedecision is.
(25:39):
Is it a change request?
Is it something you want themto know?
Is it an escalation that needsto go further up the line?
So there's a number of thingsthat you can include.
It's a decision, an escalationor a noting item, what it
relates to, what's the decisionrequired, who's the owner, owner
and the status of it.
Now those decisions themselvestypically have come up from
(26:02):
level three, the program level,and sometimes decisions that
need to go up to level one, thatsenior executive level.
So you'd outline that in asummary table and then you would
reference the pages that you'regoing to cover off throughout
the pack and throughout themeeting to help the steering
committee follow along.
So that's the first sort ofplace that I would reference it.
(26:25):
The second place I wouldreference it is on the actual
detail page.
For example, if I'm looking fora decision on a particular
change request and I need togive context and background, I
would include a supplementarypage and on that page I would
have a decision box.
That's quite clear, it'shighlighted, it's you know
borders are, read, says decisionrequired and calls out the
(26:47):
exact same decision that wasreferenced on that decision log
page so that you can followalong.
You need to give the historythat's relevant, but keep it
minimal and just enough contextto be able to make that decision
.
Now, in summary, the fiveessential elements is your
executive summary slash snapshotand that, as I said, visual is
(27:09):
always works best.
Your progress against plan,which can be your critical path
or your detailed timeline thatshows any deviations from the
plan, and also a visual, whetherit's your Gantt chart, a
milestone chart or similar.
Your risk issues anddependencies, usually over a
couple of pages one for risksand issues, with those graphs,
(27:30):
mitigations called out, and thena dependency view can be on its
own or it can be incorporatedin the progress plan timeline
page.
A financial slash resourceupdate, which is usually left in
the appendix unless there's adiscussion around it.
And then your decision log,which is at the front and early,
but also referenced throughoutwhere the decisions need to be
(27:53):
made, reference throughout wherethe decisions need to be made.
Now there are a few things thatI would recommend you keep in
mind.
But before we do that, let mejust take you through a couple
more examples of things Igenuinely have in a real life
steering committee pack that atthe moment goes all the way up
to the CFO level of a very, verylarge company, one of
(28:15):
Australia's largest companies.
So in that we would typicallyhave a running view of all the
previous actions.
We would have a running view ofthe decisions, escalations and
noting items.
I would then kick off with theexecutive summary and in that
executive summary I wouldoutline, as I said, the
essential components that wewant to discuss for that day and
(28:38):
enable people to dig in.
We would revisit the timeline,be it the critical path or the
detailed timelines, and thenoften in programs and projects
of this size, we would have abreakdown by the individual
subprojects or streams.
Within and in that subprojectsor streams you would want to
provide an update on how thestream is going, what their RAG
(29:01):
status are they red, amber orgreen a trend from the last
report and also whether they'reimproving, staying steady or
declining, with some commentary.
You have your risk and issuespage as well, and then also, in
addition to that, I like toinclude, and always have, my
steering committee charter andmembers page to provide an
(29:24):
overview so that if anyone needsto reflect on it, particularly
when we have guests that mayjoin a steering committee
upcoming leave relevant for alarge, complex program.
And then also I would includean overview of what the
definitions are pertaining toRAG status and provide that
information so that they canunderstand when something's
(29:47):
green, amber or red, the reasonsbehind it.
Now, the steering committee packdoes vary from time to time.
As I said, in one monthsteering committee I would
include more detail relating tocommunication checkpoints we've
got to make, or I would includean overview of third party
status and the activitiespertaining to those third
(30:09):
parties when the program iscomplex.
But as long as you focus onthose five key areas I mentioned
, you would be really well setup for your steering committee,
okay, so now I want to talkabout what to leave out.
Now, when you think aboutsteering committee packs, often
(30:31):
what people typically find and Iknow because I've been one of
these people who loves detailsometimes you go way over the
top and put in way too muchdetail.
Now, the problem with that isyou usually only have a very
limited time for your steeringcommittee.
I've never really seen themmore than 30 minutes, on the odd
(30:54):
occasion 45.
But excessive detail is adistraction.
It's going back to what I saidearlier about the excessive
noise.
So you don't want to includefull raid logs, you don't want
to include all the details forthe risk, all the actions, you
don't want to include all of thenitty-gritty detail around the
design or all the issues fromthat level three.
(31:15):
So think about everything at alevel three.
At the program, project level.
You can manage.
You can manage as a program ora project and you only want to
raise things that are relevant.
Otherwise it becomes adistraction from the key
decisions you need to drive theproject forward.
You also don't want to includeeverything that happened at the
last meeting.
All I would do with reflectingon the last meeting is the
(31:38):
actions and have a summary tableat the beginning of any open
actions, not only from the lastmeeting but from any previous
meetings that have not beenclosed.
Now I'll give you a tip One ofmy favorite things to do when
logging actions from previousmeetings is I like to date the
actions and number them in a waythat makes it really easy for
(32:00):
anyone to see how long thataction's been open.
As an example, if I had anaction, let's say, on the 31st
of July 2025, then my actionwould read 2025-07-31.
So the date, the year, themonth, the day backwards .01,
(32:23):
and then the subsequent actionwould be .2, .3, .4, and so on.
What that means is when I getinto my August, september,
october steering committees andI look at my actions register
and my actions log and I seesomething dated with July, I'll
know that that action isactually from that month and it
gives me a good visual and itcuts out the extra noise on the
(32:43):
actions page, because you won'tnecessarily be able to fit
everything that you want to.
So only include the actionsthat are open.
Don't worry about providing anyfurther information on meeting
minutes.
You also don't want to providewalls and walls and walls of
text, because I've done thatmany times and it seems like
(33:04):
steering committee members areallergic to it.
They don't like it.
It's not helpful.
You think you need to provideall the detail To counteract
that for people like myself whocan be quite detailed.
I've started to prepare thatfor my own benefit and having it
in my in my notes so that whenI get asked questions I can
reflect on those, as opposed toincluding
(33:25):
it in the pack.
Don't include data that linksto nothing.
So be very aware that if youinclude a graph with numbers in
it, the numbers need to becorrect.
You need to make sure thatthere is a link or something
that supports the data thatyou're including.
All my actions link to anactions register.
All my decisions link to adecision register.
(33:46):
All my risks, issues,dependencies link to their own
sources of truth.
There is a direct throughputand a linkage between all of
those as well.
All my actions, decisions, riskissues, dependencies, et cetera
all linked to one another, andI've done that to make sure that
we understand when a riskbecomes an issue, where the
issue came from, when an actionor a decision is made, what
(34:07):
change request it may relate to,and so forth.
Don't include metrics in therethat are irrelevant and actually
don't provideany substance or value.
And also, you don't want toprovide too much unnecessary
information at a steeringcommittee where you don't have
time to explain it.
(34:27):
For example, if you have amajor issue and you're going to
need some specific attention tothat issue, then you might need
to call a subsequent meeting todeep dive into it, or you may
need to provide additional timefor people to absorb that and
really come to the steeringcommittee prepared to talk
through it.
You also want to think aboutmaking sure that, when you're
(34:54):
running your steering committee,that the right people who have
been agreed as members of thesteering committee are present.
Otherwise, you will run asteering committee and not all
the decision makers will bethere, and then sometimes, in
stricter governance, you willfind that you don't meet the
requirements and therefore thedecision could be null and void.
(35:17):
As a really good example ofthat, I worked in an
organization where the programwas being funded by a third
party, and so we agreed thatthere would be a quorum of
members that needed to bepresent for a steering committee
to go ahead, of members thatneeded to be present for a
steering committee to go ahead,and where five of the seven
members weren't present, thesteering committee had to be
(35:37):
cancelled, which is a waste oftime, and you should know that
upfront if people aren't comingalong, but unfortunately it
doesn't always work that way, soyou might need to have
something like that, verysimilar.
What you don't want to do ismake decisions and not have the
right people in the room.
Now, in some instances, thesponsor can override the
decision because they might beof a senior level and they have
(35:58):
the ability to do that, and ifthat's the case, that's fine.
But where you've got a numberof head of or senior managers
that are all the same level,that represent their functions
and they all need to be part ofthat decision, you need to be
careful not to bemaking decisions without them.
Now, from a structuralperspective, I sort of outlined
briefly how I would lay it out.
(36:19):
You've got your agenda, whichis similar each month but also
can be modified.
You also have your actions,your decisions, and then you
move into your executive summary.
You want to call out yourdecisions right up front and
early, directly after youractions, so that they don't get
lost and also people know whatthey're there to do.
And it also helps to keep theflow of the meeting because you
(36:40):
know what hasn't been decidedand that it's coming up.
You want to use graphs, charts,etc.
You want to try to create thoseup front and early and reuse
them, as opposed to having tocustomise each time.
And then you also want to makesure that you are consistent as
much as possible in the layoutof your pack.
(37:01):
Now, the consistency relates toenabling the steering committee
members, who don't have lotsand lots of time to pre-read the
packs, the ability to skimthrough it in a way that
becomes comforting for them.
Speaking of pre-reading, myrule of thumb is you want to
(37:21):
give a minimum of two days forpre-reading, so you want to send
the pack out two days before asteering committee, at least.
Sometimes, depending on howcomplex the program is, you
might have to send it out a weekbefore.
I know we definitely send it aweek before for more senior
executives at that level one,but for a steering committee,
two, three days minimum two daysis ideal to give them a chance
(37:44):
to pre-read the pack.
The assumption for a lot ofsteering committees is that the
pack is read prior to themeeting and so you can focus on
making the right decisions.
And then, finally, the lengthof the pack.
As I said, it's okay to havenumerous amounts in the appendix
, but the core length of thepack typically, depending on the
(38:04):
size of your program, you mighthave five to seven pages.
You know, I find on average Isit around seven or eight,
depending on what part of theprogram we're in, and then
everything else in the appendix.
I mean, I've been known to have10, 15 pages in the appendix
and that's okay.
You just want to make sure thatyou provide that context in the
(38:32):
up first steering committee,that you will include things in
the appendix that theydon't have to read.
One thing that is a reallyimportant thing that I learned
along the way sometimes, whenyou're drafting these packs, you
may need to get a review orapproval from your line manager
or whoever it is that needs toendorse it before the steering
committee pack goes out.
And a top tip for me is alwayssend it out in PDF format if you
(38:56):
are wanting a manager to reviewit, but also when you send it
out to members.
Two reasons for that One, whenyou send it out to someone you
want to review and give youfeedback.
If they are anything like mostexecs, they're on the go and on
their phones and so skimmingthrough a file that's in
PowerPoint or similar is toocomplicated, whereas in PDF you
(39:16):
can actually skim through itquite easily.
So it makes it quicker andeasier for them.
And the reason I would send itto members in PDF is because
people are notoriously bad andmodifying a steering committee
pack after the pack's beendistributed, and we don't want
that because the pack that yousent for pre-reading needs to
match the pack that you presenton the day, otherwise it can
(39:38):
cause mistrust and confusion.
So I like to start my packswith the naming convention that
includes the date and the wordsdraft, and when the pack has
been distributed I convert it toPDF and I mark them as final.
That way, people always knowthey're receiving the PDF
version, which is the finaldocument, and not having to
worry that changes are beingmade
(39:58):
after they've read them.
Now a few last tips.
Getting the pack right ismaking sure that you build the
pack with the audience in mind.
Remember, executives havelimited time.
They just need to know whatthey need to know and nothing
else.
You want to make sure youreview the pack with the
relevant person or persons whoare going to provide you
(40:21):
valuable input before youcirculate.
They might pick up on somethingthat you don't, particularly if
you're preparing the pack onbehalf of a group of people.
You don't want to go into asteering committee and your line
manager, who may not be thesponsor or the steering
committee chairperson, and notmake sure that they are across
what's going to be raised interms of decisions, etc.
(40:42):
So, working backwards, I wouldlike to set a pre-review meeting
when I'm drafting the pack withthat manager, and I'd also then
do a quick follow-up before Iactually get the
pack out for distribution.
Now, a good steering committeepack is worth its weight in gold
.
It provides the ability to makebetter decisions.
The meetings are moreproductive.
(41:02):
You need to focus on what'sreally necessary to drive your
program or project forward, andthe steering committee itself is
a really good segue into whatyou are able then to proliferate
in terms of insights andinformation down to the broader
project and program team.
(41:23):
So you want to be able tocreate a pack that makes the
decisions that you can thenrelay back to keep the project
moving forward.
One question you can think ofwhen preparing your presentation
is this does this slide orsection or visual, or whatever
it is that you're doing help theexecutive to make a decision or
(41:44):
act or actually inform them onsomething that they would need
for their higher ups?
If not,cut it out now.
My experience with steeringcommittee packs is very vast and
varied, and I've had lots ofgreat and lots of bad
experiences along the way.
(42:05):
When I first started in thecorporate world.
My first experience of creatinga steering committee pack was
literally one of the worst I'veever ever come across, and that
is because I had no idea what asteering committee was.
Simply put, I did not know I'dcome up the project journey as
(42:30):
an administrator and reallydidn't get involved in so much
in those, and I also didn'tattend those meetings, so I had
no idea what to expect.
So I think I overwhelmed theexecutives far too much and
provided every single possibledetail I could think of and the
pack was huge and surprise,surprise, we didn't get through
it.
Inside that steering committeeslot that we had with those
(42:53):
executives.
I also, in one of my firstexperiences, minuted the meeting
, took the actions and themeeting notes, and I recall
after a 30-minute meeting I hadover seven or eight pages of
notes.
Why?
Because I had no idea whattaking steering committee
meeting minutes or actionsreally was.
I literally wrote down everysingle word that everyone was
(43:20):
saying as quickly as I possiblycould, which was completely
useless and a waste of time.
But I learned the hard way andthat's what happens when you
work in this corporate world orin life in general.
So don't do the mistakes I madeand make your steering
committee something that peoplelook forward to, something that
people get value from attendingand something that really helps
(43:42):
you as the project manager, thePMO manager, the program manager
, to drive your project forward.
Without that support, youreally are going to struggle to
get the value and to deliver theoutcomes.
So use it to your advantage.
Make your steering committeepack and meeting work for you,
(44:03):
not the other way around.
So, in summary, there arethings to include in your pack
andthings not to include.
You want to keep it consistent.
You want to front load yourdecisions.
You want to keep your detail inthe appendix, you want to make
sure you send it out in advanceand you want to make sure there
is continuity with all of youractions, decisions, risks, etc.
(44:26):
All throughout each pack as yougo, so that the story continues
in an informed way.
You want to give committeemembers the right context
quickly.
You want to highlight key risks, dependencies and decision
points early and you want to beable to help executives make
informed decisions and havediscussions relevant, but in the
(44:46):
most minimal time.
So don't be one of those peoplewho sits in a steering
committee and wonders why thereis 50 pages to flip through that
don't actually provide thestory of what you're there to do
, and it's bloated, it'sinefficient, it's unclear and it
becomes wasted time.
Instead, enable your steeringcommittee to make high impact
(45:09):
decisions with good qualitypacks that are clearly laid out,
that support doing it right.
So that's it, guys.
I hope you have enjoyed thisepisode.
It's a little bit different towhat we normally do, but if you
did find it helpful this bit ofa deep dive into the steering
(45:29):
committee packs world, pleaselet me know so I know to do more
or less content like this.
Thank you for listening.
Thank you so much for listeningto this podcast.
Please share this with someoneor rate it if you enjoyed it.
Don't forget to follow us onsocial media and to stay up to
date with all things Agile Ideas, go to our website, www.
(45:50):
agilemanagementoffice.
com.
I hope you've been able tolearn, feel or be inspired today
.
Until next time, what's yourAgile Idea?
Popular Podcasts
New Heights with Jason & Travis Kelce
Football’s funniest family duo — Jason Kelce of the Philadelphia Eagles and Travis Kelce of the Kansas City Chiefs — team up to provide next-level access to life in the league as it unfolds. The two brothers and Super Bowl champions drop weekly insights about the weekly slate of games and share their INSIDE perspectives on trending NFL news and sports headlines. They also endlessly rag on each other as brothers do, chat the latest in pop culture and welcome some very popular and well-known friends to chat with them. Check out new episodes every Wednesday. Follow New Heights on the Wondery App, YouTube or wherever you get your podcasts. You can listen to new episodes early and ad-free, and get exclusive content on Wondery+. Join Wondery+ in the Wondery App, Apple Podcasts or Spotify. And join our new membership for a unique fan experience by going to the New Heights YouTube channel now!
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!