Without exception, every large project I was involved with over the past 15 years had a Steering Committee (SC).
Broadly speaking a SC is a group of high-level stakeholders who provide strategic direction for a project, provide governance, and supports the Project Manager. Ideally, SCs increase the chances for project success by closely aligning project goals to organizational goals. However, this is unfortunately not always guaranteed.
Many SC’s I have worked with were very effective and added tremendous value to the project, some of them were the reason that a project got into trouble, some of them never noticed that a project was in trouble until it was too late, and the large majority of them were somewhere in between. Note that my experience is biased because I primarily work with troubled projects for a living.
In this article I will provide my perspective on the definition of a SC, what it should aim to accomplish, who should be part of it, and present my lessons learned in the form of 16 tips on how you can establish a SC that adds value to your project and your organization.
The SC members help guide the business. The project team and the Project Manager do not. They can direct, control and manage the required changes in the business, the team can only define, plan and support them. If the business isn’t prepared for the project (and the team has done their part) then the steering committee has failed.
Few SC members realize this but their function is to serve as a resource for the project team, and in particular the Project Manager. They need to be searching for what has to be done to ensure the success of your project, determine what challenges exist, and reveal what other business or external events need to be taken into account and managed. You don’t just want them to turn up once a month to have a few questions and engage in meaningless discussion.
Most SC’s believe their role is to ‘control the project’. The recent use of the title ‘Project Control Boards’ for SC’s emphasizes this lack of understanding as to the SC’s role. Undoubtedly there is an element of ‘project control’, and yes, there is an element of board-like governance (are you complying with the necessary standards and policies?), but these are minor aspects of their role.
Where the steering committee adds value is by clearing obstacles from the pathway to success for the project. This requires taking action. Many SC’s don’t realize this is their critical function, and often they are not prepared to adopt it, until enlightened (and, often, pushed).
This doesn't necessarily mean that every SC’s specific job description is automatically the same. Quite the opposite, specifics can vary greatly based on the following key factors:
Scope: Will the SC have jurisdiction over a single project or a group of projects (program or project portfolio)? This article will address only project SC’s, but much of it is applicable to portfolio and/or program committee’s as well. I have written extensively about project portfolio management in other articles.
Authority: Will the SC serve as the ultimate authority on the project, or will the SC function to advise the ultimate decision making authority (i.e. the project executive or sponsor)?
Difficulty: What is the degree of project difficulty? When the project is of a higher degree of complexity, visibility, sensitivity, cost and risk, the job difficulty increases in direct proportion, which ultimately places greater burden on the SC members and exposing SC operations to increased scrutiny. Job difficulty goes a long way in determining how a given SC will be organized, who will be appointed, and how it will operate in order to reach the expected results.
Deliverables: What will the SC produce? After all, that's the reason for forming a SC - to produce all the results (analysis, decisions, directives and opinions) needed to support and "steer" a successful project.
These are the factors that will drive job specifics. No steering committee can be expected to function properly without a clear description of job requirements. That's why defining the job is the first and most important action for SC success.
Most often, the project sponsor, senior management, key stakeholders and high-level permanent representatives of clients and suppliers are members of a SC. Within the project governance structure, the members of the SC are now strategically positioned to effectively promote the goals of their respective organizations.
This sounds good in theory, but SC members are usually chosen by the areas they represent in a checklist type style. It may sound counterintuitive, but having balanced representation can be problematic. Members come to the table only with perspectives that are influenced by their vested interests. For example, during a restructuring exercise, the SC can disintegrate into winners and losers; those who got their way and those who did not. In the end, the ultimate loser is the organization.
You can tackle this challenge by involving non-biased members. Identify members who do not have vested interested in particular outcomes of the project itself. This could be a finance person for a technology project or a product manager in an HR project. A neutral member will not get lost in the details and will not push for their own agenda. They can contribute by challenging the biases of others, and helping ensure balanced participation and achieving results.
Some projects are so controversial and political that the SC cannot function objectively. Bringing in professional facilitators adds a critical dimension of neutrality and a focus on achieving objectives.
In my opinion SC’s benefit from a mix of executive leadership and practitioners. This creates a balance of hands-on experience and people who are agents of change. You need people in the SC who are in the position to bring about organizational change.
Having such a mix will often result in members having not equal levels of power within their own organizations. While some are mid-level managers, others may be top executives, which results in an imbalance in decision-making abilities. I will address this later in the article when discussing the rules of engagement.
Having the optimal membership of the SC is critical to project success. Potential members should:
> Have a known vested interest in making the project and the SC a success.
> Be willing to participate as a SC member and agree to the SC’s job and expectations.
> Have the authority to make decisions on behalf of the organization they represent.
> Be willing and able to work with the other SC members.
> Be able to perform the work in a timely fashion.
> Have a clear line of authority over the project team.
Importantly, the Project Manager is NOT a member of the SC but is essentially “contracted” by the SC to ensure project success as agreed. The Project Manager takes part in the SC meeting, but they should not participate in decision-making; the Project Manager’s role is to update members on the project’s progress, areas of concern, current issues, and options for addressing these issues.
A small group, comprised of senior people, can make strategic decisions, give strategic advice, and also give the project influence among the intended users. However, a small group may not represent the necessary breadth of experiences and perspectives needed to ensure success. Moreover, busy senior executives and experts may not be able to give enough time and thought for the tasks at hand.
A larger group, (say up to ten), is manageable when the meetings are very organized and structured. A large group can obviously include a greater range of members, thus tapping in to a wider range of experience. However, a larger group can sometimes lose its effectiveness because of its sheer size. Meetings are even more difficult to schedule.
For some, believe it or not, a SC is treated like a stage. Power plays are made behind the scenes. Deals are cut before meetings are held. You can almost see the strings being pulled in the meetings. Suddenly, SC meetings begin to get cancelled, and members become disengaged. Solutions lack vital information and perspectives. The puppets don’t enjoy having their strings pulled and simply walk away from the SC.
This can be avoided when the job (see above) is presented as a roadmap in the form of a documented "SC Charter". The Charter specifies how the SC will be organized and how it will operate, all from a procedural and process point of view. This is a great approach to improve productivity, save time, minimize conflict and set expectations. I recommend that SC members agree at a minimum on the four following things:
> How decisions are made
> How participation will be managed
> What happens when there is disagreement / conflict
> What happens between SC meetings
Normally, the members of a SC are selected because they occupy positions in an organization that the ability and authority to make strategic decisions is a given. However, it must also be recognized that regardless of the make-up of the SC, or the position of its members in an organization, it is in most cases not intended to be a “voting democracy”.
As discussed in the job of your SC it makes a huge difference what authority your SC has in how the rules of engagement are invoked. In theory it would be optimal to have the decision making authority with the SC according to a pre-defined decision making process. In reality a SC often exists as a group of individuals who should share a common purpose but whose opinions and agendas may not always be completely aligned.
Therefore, it makes sense to give the final decision power to the SC chair when there is disagreement. It is of course than essential that the chair of the SC should be an individual with the actual authority and empowerment to make such decisions as may be necessary in the best interests of the organization and the project.
The chairing of the SC is most often done by the Project Sponsor who should have been selected for those very qualities. In my experience, from time-to-time the Sponsor as chair of the SC will be required to make decisions that run counter to the view of some (or even all) of the other SC members.
At the end of the day, SC members are just individuals who are appointed to do a difficult (and often thankless) job. The job is made much easier if the surrounding work environment is consistently positive, where every voice is heard, opinions are respected, information is shared, and common sense prevails. This occurs when SC (and project) leadership acts to promote member collaboration, cooperation and communication. Create trust.
Tip #2 You should plan your SC meetings ahead and decide upfront how you handle decision making between meetings.
Simply scheduling a SC meeting can be a problem, as each representative has his or her priorities and a busy agenda. If the Project Manager needs input before going ahead with some important change, he or she may not be able to get it in time if a SC meeting is required and it can’t be scheduled immediately. Even with the best intentions, the SC might slow the project down to a halt, due to slow decision-making or excessive analysis. For this reason, it makes sense to already plan the meetings a long time ahead. This is where the monthly SC meetings comes from. But this is not really helpful. Imagine having an issue a week after your last SC meeting. You have to wait for three weeks for the next meeting, and then in that meeting no decision is made because some or all members want additional information/analysis. And suddenly you are waiting for up to 8 weeks from issue to decision. Hence you have to discuss how you handle these situations.
Tip #3 Your SC time should not be used by looking at a status report.
The precious time available during the monthly SC meetings is often occupied by the Project Manager presenting a progress report. This is utterly useless, since this can be done far more efficiently through email without the demand on time (and the associated cost and non-productiveness) of senior managers and the Project Manager. Address SC members’ need for regular, timely information, with a monthly report that is a little more than just a snapshot of the previous month’s performance against known targets. Besides this snapshot you should add changes in the RAID lists and a forecast of “highlights” anticipated in the month to come (proposed completions, benefits delivery, transitions to operations, handovers to customers etc.). Provide this information by email and only discuss it during SC meetings when somebody has a question.
Tip #4 Show instead of tell.
A demo of what the project has been building, or an example of what is not working is so much more powerful than just words. Use this strategy as often as possible. It promotes a better understanding and awareness for the project and its issues. What I have done at different companies with great results is to have one regular SC and then a SC in the form of a “Sprint Review” where the project team is showing the SC members what they have done and the SC members can ask the whole team questions rather than just the project manager. These meetings are very helpful for both sides.
Tip #5 Be honest and transparent.
It is a shame this should be even a tip, but more times than I would like to remember I have worked with project teams that want to keep issues and challenges away from the SC because they think it would make them look incompetent or endanger the career of the Project Manager. We all have seen the watermelon reporting tactic. Green from the outside and bright red from the inside. This way of handling organizational challenges causes so much troubles for everybody involved. Don’t create drama about small things, but indicate issues when they arise not when it is too late to react. Tell them as it is.
Tip #6 Make decisions, real decisions.
A decision has NOT been made until people know:
> The name of the person accountable for carrying it out;
> The deadline;
> The names of the people who will be affected by the decision must be made aware of the consequences, understand the issue, and approve it—or at least not be strongly opposed to it; and
> The names of the people who have to be informed of the decision, even if they are not directly affected by it.
Tip #7 Your SC should not manage the project.
The more significant a project is to an organization, the more vital it is that the SC actively supports the Project Manager, but paradoxically, it is this role which is most often misunderstood or simply overlooked in many organizations. Too often, because of the importance of a project, the SC seeks a degree of control which should reside in the hands of the Project Manager with the result that “micro-management” occurs, often manifested through the “monthly meeting”. SC’s should steer, not manage.
Tip #8 Your Project Sponsor and Project Manager need to be able to work with each other.
It is critical to ensure a good working relationship between the Project Manager and Sponsor – some conflict or difference of opinion is healthy but if the two roles are constantly at odds, the project will suffer. Before finalizing decisions on either role, the current working relationship between the two should be evaluated to increase the likelihood of success.
Tip #9 Your SC should organize the necessary resources.
SC members should help a project by providing active support to ensure that resources are made available as required, especially in a “matrix” organization where key people reside within functions and are only “loaned” to projects. SC members in charge of such functions should use their position and influence to help the Project Manager overcome the many obstacles that the matrix approach creates, e.g. where a conflict arises between project and functional priorities, it is usually the function that prevails. It is also not uncommon for resources to be withdrawn or reallocated at short (or no) notice.
I am the opinion that when a project is of major strategic importance to the organization, key people should be withdrawn from the functions and dedicated to the project for the duration required. Such a proposal often meets with considerable resistance which SC members should seek to overcome if the project is deemed to be of greater significance than the function affected – at least in the short term but perhaps even in the longer term.
Tip #10 Your SC should establish how project success will be defined and measured.
A project can only be successful if the criteria for quantifying success are clearly defined. And this should ideally occur upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on a project, it's essential to work actively with the SC to define success across three levels:
1) Project delivery
2) Product or service
3) Business
Project delivery success: Project delivery success is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic triangle "scope time, budget, and quality?" It is limited to the duration of the project and success can be measured when the project is officially completed (with intermediary measures being taken of course as part of project control processes). Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.?
Product or service success: Product or service success is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria must be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured at the end of the project itself.?
Business success: Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (5% market share won, technology advantage), and etc.?
Tip #11 Your SC should take responsibility for business success.
When it comes to accountabilities for success, they are different for each level:
1) Project delivery success: PM (and project team).
2) Product or service success: Product/Service Owner.
3) Business success: Project Sponsor.
But when it comes to responsibility, I am the opinion the SC is responsible for business success. They run the business, the team and the Project Manager does not. They can direct, control and manage the required changes in the business, the team can only define, plan and support them. If the business isn’t prepared for the project (and the team has done their part) then the SC has failed.
Your SC should monitor business and strategic issues and provide advice to the project team on issues that may present a risk to the project or have impact on the project rationale or success.
After the project has delivered the SC should continue to monitor if the expected benefits are actually realized. A lessons learned session on each of the three levels should be organized and summarized so that the rest of the organization can learn from both past successes and failures.
Tip #12 Your SC should be a strong advocate for the project.
Your SC members should actively and overtly support the project and act as an advocate for its outcomes. If even your SC is not supporting the project, how can you expect the organization will?
Tip #13 Your SC has a very active role in maintaining your RAID lists.
A great tool to proactively manage your project are the so-called RAID lists. RAID is an acronym for Risks, Assumptions, Issues, and Decisions. Some use the "D" for dependencies instead of decisions, and some use the "A" for actions instead of assumptions. I personally track dependencies on my assumption list (because that is what dependencies are) and I have no need for a separate action list because I track actions in a separate column of each of the other lists. Your SC has a very active role on maintaining these. The members will have meaningful input on the Risks and Assumptions of the project. The same for mitigations. They will need to be aware of the Issues and every decision that cannot be made by the project team typically will be made by the SC. So instead of spending precious SC time on status reports (see above), use this opportunity to actively engage with the RAID lists.
Tip #14 Your SC should provide some governance.
Besides the steering there is also the governance role of the SC. Typically this means:
> Approve the business case, project approach and project management methodology;
> Establish delegation authorities and limits for the project management, with regard to cost, time,
resource, quality and scope;
> Define the acceptable risk profile and risk thresholds for the project, based on the company’s risk management strategy and review project risks;
> Oversee stakeholder management and change management programs;
> Oversee the project quality assurance program;
> Review and approve or reject project plans;
> Resolve matters of project cost, time, risk, resource, quality and scope escalated to the Committee;
> Monitor project progress against approved business case, project plans and delegations; and
> Approve project closure.
Tip #15 Your SC should be aware of the Dominator Effect.
SC’s need leadership, and leaders often have strong personalities. When strong personalities begin to dominate SC agendas, projects can be put at risk. The problem with the dominator effect is twofold:
> The steering committee’s direction becomes more biased towards the dominators personal preferences.
> Valuable input and perspectives from other members rarely make it to the table.
As the dominator takes over the SC participation from other other members will decline. What’s the point in attending meetings if you’re not heard? In this case, the SC remains in name only. The co-lead model has proven effective to balance perspective and help prevent the dominator effect. Ideally, your co-leads will bring very different perspectives and leadership styles to the table to balance things out. In some instances, even a tri-lead model can be effective for large and complex initiatives.
Tip #16 Your SC should not be afraid to request project reviews.
In regular intervals on multiyear projects, reviews can serve a wide range of stakeholders and fulfill a variety of roles. It’s therefore not surprising that organizations undertake several different types of review on their most important projects. From my perspective, there are five distinct types of review. Each with its own focus and outcome.
1) Project Review: Can occur at any point through the project. It assesses progress against the original schedule, budget, and deliverables. It looks at the effectiveness of the team, project management, engineering practices, and other related processes. It typically delivers some sort of assessment of the likelihood of project success and identifies areas of concern and corrective actions.
2) Gate Review: Occurs at the end of a project phase or at some other defined point in the project’s lifecycle. It typically represents a decision point, using the outputs from an evaluation to decide whether continued investment in the project is justified.
3) Project Audit: An objective evaluation by a group outside the project team. A project audit is about being compliant and about the now. An audit aims to demonstrate the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will examine how closely you follow the processes. An audit can take place during or after the project.
4) Project Retrospective: Occurs as the project closes down. It assesses the overall success of the project and identifies what did or didn’t work during its execution, generating lessons learned for the future. Also known as Postmortem or Post-project Review.
5) Benefits Realization Review: Occurs after the organization has had some chance to use the outputs from the project. It evaluates the extent to which the benefits identified in the original business case have been achieved.
In a nutshell: A steering committee adds value by clearing obstacles from the pathway to success for the project. This requires taking action.
When you need some guidance on how to define and measure project success, just download the Project Success Model by clicking on the image.
Broadly speaking a SC is a group of high-level stakeholders who provide strategic direction for a project, provide governance, and supports the Project Manager. Ideally, SCs increase the chances for project success by closely aligning project goals to organizational goals. However, this is unfortunately not always guaranteed.
Many SC’s I have worked with were very effective and added tremendous value to the project, some of them were the reason that a project got into trouble, some of them never noticed that a project was in trouble until it was too late, and the large majority of them were somewhere in between. Note that my experience is biased because I primarily work with troubled projects for a living.
In this article I will provide my perspective on the definition of a SC, what it should aim to accomplish, who should be part of it, and present my lessons learned in the form of 16 tips on how you can establish a SC that adds value to your project and your organization.
So what exactly is a SC?
The "steering committee" of a project can be described as a "governing device" used to organize key project stakeholders and empower them to "steer" a project (or group of projects) to successful outcomes. So what is ‘steering’? Steering is not managing. Managing seeks to get the job done, but steering determines what the job is.The SC members help guide the business. The project team and the Project Manager do not. They can direct, control and manage the required changes in the business, the team can only define, plan and support them. If the business isn’t prepared for the project (and the team has done their part) then the steering committee has failed.
Few SC members realize this but their function is to serve as a resource for the project team, and in particular the Project Manager. They need to be searching for what has to be done to ensure the success of your project, determine what challenges exist, and reveal what other business or external events need to be taken into account and managed. You don’t just want them to turn up once a month to have a few questions and engage in meaningless discussion.
Most SC’s believe their role is to ‘control the project’. The recent use of the title ‘Project Control Boards’ for SC’s emphasizes this lack of understanding as to the SC’s role. Undoubtedly there is an element of ‘project control’, and yes, there is an element of board-like governance (are you complying with the necessary standards and policies?), but these are minor aspects of their role.
Where the steering committee adds value is by clearing obstacles from the pathway to success for the project. This requires taking action. Many SC’s don’t realize this is their critical function, and often they are not prepared to adopt it, until enlightened (and, often, pushed).
What Is the Job of Your SC?
As pointed out above of the SC’s general job description is "to steer a project to successful conclusion through deliberation, decision making, support and action".This doesn't necessarily mean that every SC’s specific job description is automatically the same. Quite the opposite, specifics can vary greatly based on the following key factors:
Scope: Will the SC have jurisdiction over a single project or a group of projects (program or project portfolio)? This article will address only project SC’s, but much of it is applicable to portfolio and/or program committee’s as well. I have written extensively about project portfolio management in other articles.
Authority: Will the SC serve as the ultimate authority on the project, or will the SC function to advise the ultimate decision making authority (i.e. the project executive or sponsor)?
Difficulty: What is the degree of project difficulty? When the project is of a higher degree of complexity, visibility, sensitivity, cost and risk, the job difficulty increases in direct proportion, which ultimately places greater burden on the SC members and exposing SC operations to increased scrutiny. Job difficulty goes a long way in determining how a given SC will be organized, who will be appointed, and how it will operate in order to reach the expected results.
Deliverables: What will the SC produce? After all, that's the reason for forming a SC - to produce all the results (analysis, decisions, directives and opinions) needed to support and "steer" a successful project.
These are the factors that will drive job specifics. No steering committee can be expected to function properly without a clear description of job requirements. That's why defining the job is the first and most important action for SC success.
Who is in Your SC?
With the right people in the room, your SC can almost guarantee project success. But how do you have selected the right people? Picking experienced leaders and subject matter experts is beneficial, but it is not always good enough.Most often, the project sponsor, senior management, key stakeholders and high-level permanent representatives of clients and suppliers are members of a SC. Within the project governance structure, the members of the SC are now strategically positioned to effectively promote the goals of their respective organizations.
This sounds good in theory, but SC members are usually chosen by the areas they represent in a checklist type style. It may sound counterintuitive, but having balanced representation can be problematic. Members come to the table only with perspectives that are influenced by their vested interests. For example, during a restructuring exercise, the SC can disintegrate into winners and losers; those who got their way and those who did not. In the end, the ultimate loser is the organization.
You can tackle this challenge by involving non-biased members. Identify members who do not have vested interested in particular outcomes of the project itself. This could be a finance person for a technology project or a product manager in an HR project. A neutral member will not get lost in the details and will not push for their own agenda. They can contribute by challenging the biases of others, and helping ensure balanced participation and achieving results.
Some projects are so controversial and political that the SC cannot function objectively. Bringing in professional facilitators adds a critical dimension of neutrality and a focus on achieving objectives.
In my opinion SC’s benefit from a mix of executive leadership and practitioners. This creates a balance of hands-on experience and people who are agents of change. You need people in the SC who are in the position to bring about organizational change.
Having such a mix will often result in members having not equal levels of power within their own organizations. While some are mid-level managers, others may be top executives, which results in an imbalance in decision-making abilities. I will address this later in the article when discussing the rules of engagement.
Having the optimal membership of the SC is critical to project success. Potential members should:
> Have a known vested interest in making the project and the SC a success.
> Be willing to participate as a SC member and agree to the SC’s job and expectations.
> Have the authority to make decisions on behalf of the organization they represent.
> Be willing and able to work with the other SC members.
> Be able to perform the work in a timely fashion.
> Have a clear line of authority over the project team.
Importantly, the Project Manager is NOT a member of the SC but is essentially “contracted” by the SC to ensure project success as agreed. The Project Manager takes part in the SC meeting, but they should not participate in decision-making; the Project Manager’s role is to update members on the project’s progress, areas of concern, current issues, and options for addressing these issues.
What is the Optimal Size of the SC?
Ideally a SC is made up of four to seven people, but it can be larger in order to obtain buy-in from all concerned areas of the organization.A small group, comprised of senior people, can make strategic decisions, give strategic advice, and also give the project influence among the intended users. However, a small group may not represent the necessary breadth of experiences and perspectives needed to ensure success. Moreover, busy senior executives and experts may not be able to give enough time and thought for the tasks at hand.
A larger group, (say up to ten), is manageable when the meetings are very organized and structured. A large group can obviously include a greater range of members, thus tapping in to a wider range of experience. However, a larger group can sometimes lose its effectiveness because of its sheer size. Meetings are even more difficult to schedule.
Establishing the Rules of Engagement
Try putting a number of people in a room, call them the SC, vaguely define their job and leave them on their own to figure out what it all means and how to get the job done. They might produce results for a while, but sooner or later, problems will appear. Perhaps not everyone heard the same message. Perhaps people will struggle to gain control. Perhaps changing circumstances will throw everyone a curve ball. These are the types of risks that diminish productivity and can complicate results.For some, believe it or not, a SC is treated like a stage. Power plays are made behind the scenes. Deals are cut before meetings are held. You can almost see the strings being pulled in the meetings. Suddenly, SC meetings begin to get cancelled, and members become disengaged. Solutions lack vital information and perspectives. The puppets don’t enjoy having their strings pulled and simply walk away from the SC.
This can be avoided when the job (see above) is presented as a roadmap in the form of a documented "SC Charter". The Charter specifies how the SC will be organized and how it will operate, all from a procedural and process point of view. This is a great approach to improve productivity, save time, minimize conflict and set expectations. I recommend that SC members agree at a minimum on the four following things:
> How decisions are made
> How participation will be managed
> What happens when there is disagreement / conflict
> What happens between SC meetings
Normally, the members of a SC are selected because they occupy positions in an organization that the ability and authority to make strategic decisions is a given. However, it must also be recognized that regardless of the make-up of the SC, or the position of its members in an organization, it is in most cases not intended to be a “voting democracy”.
As discussed in the job of your SC it makes a huge difference what authority your SC has in how the rules of engagement are invoked. In theory it would be optimal to have the decision making authority with the SC according to a pre-defined decision making process. In reality a SC often exists as a group of individuals who should share a common purpose but whose opinions and agendas may not always be completely aligned.
Therefore, it makes sense to give the final decision power to the SC chair when there is disagreement. It is of course than essential that the chair of the SC should be an individual with the actual authority and empowerment to make such decisions as may be necessary in the best interests of the organization and the project.
The chairing of the SC is most often done by the Project Sponsor who should have been selected for those very qualities. In my experience, from time-to-time the Sponsor as chair of the SC will be required to make decisions that run counter to the view of some (or even all) of the other SC members.
16 Tips for a Highly Effective Steering Committee
Tip #1 Your SC should focus on collaboration, cooperation and communication.At the end of the day, SC members are just individuals who are appointed to do a difficult (and often thankless) job. The job is made much easier if the surrounding work environment is consistently positive, where every voice is heard, opinions are respected, information is shared, and common sense prevails. This occurs when SC (and project) leadership acts to promote member collaboration, cooperation and communication. Create trust.
Tip #2 You should plan your SC meetings ahead and decide upfront how you handle decision making between meetings.
Simply scheduling a SC meeting can be a problem, as each representative has his or her priorities and a busy agenda. If the Project Manager needs input before going ahead with some important change, he or she may not be able to get it in time if a SC meeting is required and it can’t be scheduled immediately. Even with the best intentions, the SC might slow the project down to a halt, due to slow decision-making or excessive analysis. For this reason, it makes sense to already plan the meetings a long time ahead. This is where the monthly SC meetings comes from. But this is not really helpful. Imagine having an issue a week after your last SC meeting. You have to wait for three weeks for the next meeting, and then in that meeting no decision is made because some or all members want additional information/analysis. And suddenly you are waiting for up to 8 weeks from issue to decision. Hence you have to discuss how you handle these situations.
Tip #3 Your SC time should not be used by looking at a status report.
The precious time available during the monthly SC meetings is often occupied by the Project Manager presenting a progress report. This is utterly useless, since this can be done far more efficiently through email without the demand on time (and the associated cost and non-productiveness) of senior managers and the Project Manager. Address SC members’ need for regular, timely information, with a monthly report that is a little more than just a snapshot of the previous month’s performance against known targets. Besides this snapshot you should add changes in the RAID lists and a forecast of “highlights” anticipated in the month to come (proposed completions, benefits delivery, transitions to operations, handovers to customers etc.). Provide this information by email and only discuss it during SC meetings when somebody has a question.
Tip #4 Show instead of tell.
A demo of what the project has been building, or an example of what is not working is so much more powerful than just words. Use this strategy as often as possible. It promotes a better understanding and awareness for the project and its issues. What I have done at different companies with great results is to have one regular SC and then a SC in the form of a “Sprint Review” where the project team is showing the SC members what they have done and the SC members can ask the whole team questions rather than just the project manager. These meetings are very helpful for both sides.
Tip #5 Be honest and transparent.
It is a shame this should be even a tip, but more times than I would like to remember I have worked with project teams that want to keep issues and challenges away from the SC because they think it would make them look incompetent or endanger the career of the Project Manager. We all have seen the watermelon reporting tactic. Green from the outside and bright red from the inside. This way of handling organizational challenges causes so much troubles for everybody involved. Don’t create drama about small things, but indicate issues when they arise not when it is too late to react. Tell them as it is.
Tip #6 Make decisions, real decisions.
A decision has NOT been made until people know:
> The name of the person accountable for carrying it out;
> The deadline;
> The names of the people who will be affected by the decision must be made aware of the consequences, understand the issue, and approve it—or at least not be strongly opposed to it; and
> The names of the people who have to be informed of the decision, even if they are not directly affected by it.
Tip #7 Your SC should not manage the project.
The more significant a project is to an organization, the more vital it is that the SC actively supports the Project Manager, but paradoxically, it is this role which is most often misunderstood or simply overlooked in many organizations. Too often, because of the importance of a project, the SC seeks a degree of control which should reside in the hands of the Project Manager with the result that “micro-management” occurs, often manifested through the “monthly meeting”. SC’s should steer, not manage.
Tip #8 Your Project Sponsor and Project Manager need to be able to work with each other.
It is critical to ensure a good working relationship between the Project Manager and Sponsor – some conflict or difference of opinion is healthy but if the two roles are constantly at odds, the project will suffer. Before finalizing decisions on either role, the current working relationship between the two should be evaluated to increase the likelihood of success.
Tip #9 Your SC should organize the necessary resources.
SC members should help a project by providing active support to ensure that resources are made available as required, especially in a “matrix” organization where key people reside within functions and are only “loaned” to projects. SC members in charge of such functions should use their position and influence to help the Project Manager overcome the many obstacles that the matrix approach creates, e.g. where a conflict arises between project and functional priorities, it is usually the function that prevails. It is also not uncommon for resources to be withdrawn or reallocated at short (or no) notice.
I am the opinion that when a project is of major strategic importance to the organization, key people should be withdrawn from the functions and dedicated to the project for the duration required. Such a proposal often meets with considerable resistance which SC members should seek to overcome if the project is deemed to be of greater significance than the function affected – at least in the short term but perhaps even in the longer term.
Tip #10 Your SC should establish how project success will be defined and measured.
A project can only be successful if the criteria for quantifying success are clearly defined. And this should ideally occur upfront. Unfortunately, I have seen many projects that skipped this part completely. When starting on a project, it's essential to work actively with the SC to define success across three levels:
1) Project delivery
2) Product or service
3) Business
Project delivery success: Project delivery success is about defining the criteria by which the process of delivering the project is successful. Essentially this addresses the classic triangle "scope time, budget, and quality?" It is limited to the duration of the project and success can be measured when the project is officially completed (with intermediary measures being taken of course as part of project control processes). Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.?
Product or service success: Product or service success is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria must be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured at the end of the project itself.?
Business success: Business success is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (5% market share won, technology advantage), and etc.?
Tip #11 Your SC should take responsibility for business success.
When it comes to accountabilities for success, they are different for each level:
1) Project delivery success: PM (and project team).
2) Product or service success: Product/Service Owner.
3) Business success: Project Sponsor.
But when it comes to responsibility, I am the opinion the SC is responsible for business success. They run the business, the team and the Project Manager does not. They can direct, control and manage the required changes in the business, the team can only define, plan and support them. If the business isn’t prepared for the project (and the team has done their part) then the SC has failed.
Your SC should monitor business and strategic issues and provide advice to the project team on issues that may present a risk to the project or have impact on the project rationale or success.
After the project has delivered the SC should continue to monitor if the expected benefits are actually realized. A lessons learned session on each of the three levels should be organized and summarized so that the rest of the organization can learn from both past successes and failures.
Tip #12 Your SC should be a strong advocate for the project.
Your SC members should actively and overtly support the project and act as an advocate for its outcomes. If even your SC is not supporting the project, how can you expect the organization will?
Tip #13 Your SC has a very active role in maintaining your RAID lists.
A great tool to proactively manage your project are the so-called RAID lists. RAID is an acronym for Risks, Assumptions, Issues, and Decisions. Some use the "D" for dependencies instead of decisions, and some use the "A" for actions instead of assumptions. I personally track dependencies on my assumption list (because that is what dependencies are) and I have no need for a separate action list because I track actions in a separate column of each of the other lists. Your SC has a very active role on maintaining these. The members will have meaningful input on the Risks and Assumptions of the project. The same for mitigations. They will need to be aware of the Issues and every decision that cannot be made by the project team typically will be made by the SC. So instead of spending precious SC time on status reports (see above), use this opportunity to actively engage with the RAID lists.
Tip #14 Your SC should provide some governance.
Besides the steering there is also the governance role of the SC. Typically this means:
> Approve the business case, project approach and project management methodology;
> Establish delegation authorities and limits for the project management, with regard to cost, time,
resource, quality and scope;
> Define the acceptable risk profile and risk thresholds for the project, based on the company’s risk management strategy and review project risks;
> Oversee stakeholder management and change management programs;
> Oversee the project quality assurance program;
> Review and approve or reject project plans;
> Resolve matters of project cost, time, risk, resource, quality and scope escalated to the Committee;
> Monitor project progress against approved business case, project plans and delegations; and
> Approve project closure.
Tip #15 Your SC should be aware of the Dominator Effect.
SC’s need leadership, and leaders often have strong personalities. When strong personalities begin to dominate SC agendas, projects can be put at risk. The problem with the dominator effect is twofold:
> The steering committee’s direction becomes more biased towards the dominators personal preferences.
> Valuable input and perspectives from other members rarely make it to the table.
As the dominator takes over the SC participation from other other members will decline. What’s the point in attending meetings if you’re not heard? In this case, the SC remains in name only. The co-lead model has proven effective to balance perspective and help prevent the dominator effect. Ideally, your co-leads will bring very different perspectives and leadership styles to the table to balance things out. In some instances, even a tri-lead model can be effective for large and complex initiatives.
Tip #16 Your SC should not be afraid to request project reviews.
In regular intervals on multiyear projects, reviews can serve a wide range of stakeholders and fulfill a variety of roles. It’s therefore not surprising that organizations undertake several different types of review on their most important projects. From my perspective, there are five distinct types of review. Each with its own focus and outcome.
1) Project Review: Can occur at any point through the project. It assesses progress against the original schedule, budget, and deliverables. It looks at the effectiveness of the team, project management, engineering practices, and other related processes. It typically delivers some sort of assessment of the likelihood of project success and identifies areas of concern and corrective actions.
2) Gate Review: Occurs at the end of a project phase or at some other defined point in the project’s lifecycle. It typically represents a decision point, using the outputs from an evaluation to decide whether continued investment in the project is justified.
3) Project Audit: An objective evaluation by a group outside the project team. A project audit is about being compliant and about the now. An audit aims to demonstrate the extent to which your project conforms to the required organizational and project standards. So, if your organization uses PRINCE2 or their own project management methodology, an audit will examine how closely you follow the processes. An audit can take place during or after the project.
4) Project Retrospective: Occurs as the project closes down. It assesses the overall success of the project and identifies what did or didn’t work during its execution, generating lessons learned for the future. Also known as Postmortem or Post-project Review.
5) Benefits Realization Review: Occurs after the organization has had some chance to use the outputs from the project. It evaluates the extent to which the benefits identified in the original business case have been achieved.
Closing Thoughts
Carefully constructing a functioning and effective SC is critical for project success. Don’t gamble unnecessarily on the success of your project. Strategically structure your SC to have the right leadership model based on the personalities around the table. Build objectivity into your membership and take the time to ensure everyone is in the same boat before the committee sets sails and starts steering.In a nutshell: A steering committee adds value by clearing obstacles from the pathway to success for the project. This requires taking action.
When you need some guidance on how to define and measure project success, just download the Project Success Model by clicking on the image.