Projects don’t arrive at their conclusion perfectly executed
and delivering all the benefits promised in the Business Case, at the
advertised cost. They must be measured along the way to ensure they are
developing to plan. Our project management training (especially our PMP Exam
preparation training) provides us with a variety of tools to measure project
progress against schedule, budget, requirements, and quality goals. The most
critical of these for demonstrating your project’s successful progress is the
Gate Meeting. These meetings are variously called Phase Exit Reviews (by our PMP Exam preparation training), or Business Decision Points.
Whatever your organization calls your meetings, these are
the points at which all the project stakeholders will determine whether your
project is on track to meeting the organizations expectations for it. This
article should provide you with some useful information, tips, and tricks to
ensure that your meetings are successful.
Why Do I Need Gate Meetings?
Aside from the reasons stated above, there are 2 key reasons
you should schedule gate meetings at key milestones throughout your project:
You
not only need to ensure your project is on track, you need to demonstrate
your success to your project stakeholders and have them acknowledge you
are staying the course. Gate meetings are your opportunity to accomplish
this.
Gate
meetings also serve the purpose of validating the Business Case. As the
project’s scope, budget, and schedule change throughout it’s life cycle,
your Business Case will change. The Business Case may also be changed by
circumstances outside the span of your control such as changes in the
market place. The Gate Meeting is your opportunity to have the updated
Business Case validated by your project’s executive sponsors. Your PMP
Exam preparation training emphasizes the importance of an up to date
Business Case and validation at these meetings.
When Do I Need to Hold a Gate Meeting?
Gate Meetings should be held at key milestones throughout
the project. There is no hard and fast rule for how many Gate meetings a
project should have, or when they should be held. We can say that each project
should have at least two Gate Meetings: one between the Planning Phase and the Build
Phase and one before the project Closeout. The first is critical because it has
the ability to save the organization the bulk of project costs should it decide
the Business Case doesn’t justify the expense, or the project doesn’t align
with the organization’s strategic goals. The second is critical because this is
the meeting where the customer will formally accept the products of the
project. It should drive any formal sign offs and final payments that conclude
the project.
Gate Meetings should be held at points in between when the
project can benefit from them. For example, if you’re managing a software
development project, you may want to hold a Gate Meeting between the
requirements gathering and the start of software development and between the
completion of software development and the start of QA testing. If you’re using
RUP (Rational Unified Process), you’ll probably want to hold a Gate Meeting
between each iteration. These are only a few examples of suitable points to
hold your Gate Meetings. You should define a set of Gate Meetings customized to
the needs of your project.
Here’s one final tip to help you define the correct set of
Gate Meetings for your project: the points at which these meetings should be
held should jump out at you when you look at your Work Breakdown Structure
(WBS). If they don’t, it could be an indication that you haven’t broken the
project work down correctly. Your PMP Exam preparation training will provide
you with the process that will correctly break the work down. Don’t be afraid
to hold too many Gate Meetings. Being selective when choosing invitees to these
meetings will avoid Gate Meeting "burnout”. We’ll explore some tips and tricks
for selecting Gate Meeting attendees later in this article.
What Gets Done at the Gate Meeting?
The key objective of your Gate Meeting is to reach a
decision on whether to proceed to the next phase of the project, or cancel the
project. Do not lose sight of this objective when you set the meetings agenda
or conduct the meeting. Like every formal meeting you hold, you need to set an
agenda for this one and your agenda should make this objective clear. It should
also set the criteria for the decision and most importantly, identify
the decision maker(s). We’ll expand on successful strategies for doing
this when we discuss the meeting attendees.
The criteria that you should set for passing the Gate will
be dependent on the specific Gate Meeting and your project. Generally speaking,
there are 3 categories of criteria that will apply to most Gates:
The
Business Case is still valid. This means the expected benefits in your
up to date Business Case still
outweigh the costs and the project still aligns with the organization’s
strategic objectives.
The
work of the finished phase is complete and meets quality standards established
in your plan. This will generally be established by the completion of
project deliverables.
The
resources required for the start of the next phase have been acquired and
are in place. Resources include the people to do the work and everything
they need to do it such as tools, work stations, facilities, hardware,
software, etc.
The agenda of your meeting should serve the purpose of
verifying that all these criteria have been met. Once the criteria have been
satisfied, the decision should follow.
Gate Meeting Attendees
Remember that the key objective of your Gate Meeting is a
decision to go forward with the next project phase (or not); your meeting
attendees must include the decision makers to ensure this happens.
One of your key decision makers will be the project’s
sponsor. This is the person who is accountable to the organization for the
project budget; sometimes known as business sponsor, executive sponsor, or just
plain sponsor. Your going to need this person at the Gate Meeting which marks the
advance of your project from planning to execution. The sponsor should also be
present at the Closeout Gate Meeting; they need to be satisfied that the
project has delivered all the benefits promised in the Business Case. They may
also want to attend intervening Gate Meetings depending on the level of their
interest and the deliverables being discussed at the meeting. You should always
make the sponsor welcome at any Gate and make sure they understand what
deliverables are being discussed but leave the final decision on whether to
attend or not to them.
Other categories of stakeholders will include: partners
(partner tools or partner organizations), sub-contractors, vendors, and project
team members. You won’t be able to have the whole team present at the meeting
but should have a spokesperson for each deliverable being discussed. You may
want to speak for the deliverables yourself if you’re well enough acquainted
with them but should at least have a spokesperson in the meeting with a
technical command of the deliverable. Your PMP Exam preparation training
material contains a fairly comprehensive list and description of project
stakeholders.
Meeting Logistics
You’ve carefully chosen the right project milestone for your
meeting, chosen all the right attendees, and have a clear understanding of the
meeting objective and how to achieve it. Here are some simple rules to follow
in order to guarantee success.
Craft an agenda for the meeting that specifies the subject
being addressed which includes the time allotted and the spokesperson. The
agenda items should include each deliverable produced by the previous phase and
each resource necessary for the next one. Don’t get too granular with the
deliverables or resources; remember you don’t want to drag the meeting out,
just satisfy the stakeholders all the criteria for success have been met. One
trick to ensure the meeting doesn’t drag on is to bundle deliverables or
resources into categories, for example instead of reviewing each module or
feature in your software development project, lump them in categories such as
Application Program Interface (API) software and "back end” software. Conclude
the agenda with the decision. Identify the decision makers as spokespeople for
the decision.
Be sure that the invitees are free at the meeting time. If
you’re lucky enough to have access to Microsoft Outlook, you have the means to
do this from your computer, otherwise you’ll have to do this person to person.
You may want to speak with your sponsor face to face even if you have access to
their calendars on-line to avoid any misunderstandings or last minute changes.
Choose a room large enough to hold all attendees. If you
have a geographically dispersed team you also want to ensure that you’ve chosen
a time that is suitable to all remote attendees. If this can’t be done because
of time zone differences, make sure you spread the pain by considering the
convenience of each remote attendee in turn. Be sure to book any audio/video
equipment well in advance of the meeting such as conference bridges, Polycoms,
projectors, etc. Be sure your bridge provides enough lines for all remote
attendees.
Communicate the meeting invitation at least a week in
advance of the meeting. Make sure that your invitation includes all the key
information: purpose of the meeting, time, location, duration, and bridge
numbers. You need to include the meeting agenda with your invitation. A day or
two in advance of the meeting, send a meeting reminder including all the
pertinent information plus the agenda.
A presentation for the meeting is optional but a simple
PowerPoint presentation will tend to focus attendees on the business at hand.
If you decide you should focus the meeting with a presentation, the
presentation should itemize the deliverables and resources that comprise the
criteria for passing the gate. A tip for making your presentation more
effective at drawing a line under the discussion around a deliverable: make the
presentation animated (this is a PowerPoint feature) and follow each
deliverable/resource with a check mark.
You’ll make your meeting much more palatable if you can
provide refreshments. These aren’t essential but will serve to make attendance
more attractive to the invitees. If you do decide to provide refreshments,
don’t let them disrupt the meeting. Make sure they’re either in place before
the meeting starts or have them delivered during a short break in the meeting.
Running the Meeting
Running the Gate Meeting isn’t vastly different than running
any other meeting effectively. If you’re unfamiliar with running meetings, you
should take a course on the subject, or use a book or magazine article on the
subject to upgrade your education. The knowledge we provide here is meant to
augment your meeting generalship.
Rule #1: You are in charge of the meeting. This means a
successful conclusion is your responsibility and your sponsor will expect you
to keep the meeting and the attendees on track and focused. If the attendees
take the meeting down a "rat hole”, it’s your responsibility to bring them back
on track.
The first tip I’ll offer you on running an effective Gate
Meeting is to appoint a timekeeper. Be sure the room understands the role of
the time keeper. Their role is simply to inform the meeting of the time
remaining for discussing a criteria or decision, or to announce that time is
up. This person will keep the meeting on schedule and avoid having time run out
without a decision being reached. This person may take some heat for
interrupting an attendee giving a speech that runs over their limit, especially
if the speaker is someone senior. It’s up to you to deflect the heat – remind
the room that the time keeper is only doing the job you gave them. The more
senior that person is, the more effective they will be in keeping the meeting
on schedule. If you can solicit the timekeeping services of a respected
project manager for your meeting you’ll have a head start keeping your meeting
on schedule. One way of rewarding your timekeeper is to offer your timekeeping
services in their meetings.
Take the lead on discussions on the ability of a deliverable
or resource to meet gating criteria. You’re the subject matter expert on the
criteria and are either speaking for the deliverable, or directing the owner to
speak to it. You are ultimately responsible for the deliverables and resources
of the project and it’s up to you to decide whether they meet gating criteria.
You can have a team member who is directly responsible for the deliverable or
resource describe it in terms of the gating criteria but it’s ultimately your
responsibility to convince the room of it’s ability to meet gating criteria.
Tip: don’t go into the meeting room without being thoroughly familiar with the
status of each deliverable and resource itemized in your agenda.
Don’t expect discussion of your gating criteria to adhere to
your schedule like a well rehearsed play. You can only expect your timekeeper to
remind your stakeholders of the time limit on the topic of discussion; at best,
they may be able to halt a stakeholder holding forth on topic that is tangent
to one of your gating criteria and if you don’t have a strong personality in
that role, you’ll have to step in yourself to preserve your schedule. If there
is a lively debate on a deliverable, resource, or issue around either, help
your timekeeper out by capturing an item in your project’s action register to
follow up on the discussion. The follow up can happen at the conclusion of the
meeting (leave a sufficient amount of time for these "parking lot” items in
your agenda), or the item may require an action. If an action is required, you
can either identify a team member in the room to accept responsibility for the
item, or you can assume responsibility for it yourself. Never assign an action
item to someone not present and ensure that items you assign to team members
present in the room are accepted with a forecast completion date.
Accept that some gating criteria may not be met to every
stakeholders satisfaction. Each stakeholder comes to your meeting with their
own set of agenda and will only speak to their own agendas so a deliverable may
satisfy every stakeholder but one and that one stakeholder may have a fairly
minor complaint about the deliverable. If that’s the case, capture the
complaint in the form of an action item in your action register and move on.
The inability of the deliverable to satisfy your lone stakeholder won’t
necessarily cause your gate to fail.
The Decision
The objective of the meeting is reach a decision on whether
to proceed to the next project phase or not. In fact there is a third
acceptable option: proceed to the next project phase contingent on some actions
being taken or issues being closed. This decision is sometimes referred to as a
"conditional pass”. The point is you have to define the process for reaching
the decision, ensure the decision makers are provided with the information they
need to reach the decision, and extract the decision from the decision makers.
Choosing the decision makers is critical to arriving at the
decision. Make the stature of the decision makers commensurate with the
significance of the Gate. At critical gates, your executive sponsor(s) will
want to have ultimate say in the decision. At less critical points in your
project you may want to delegate decision making responsibility, or make the
decision yourself. In either case, make sure your sponsor is comfortable with
the process and decision makers.
Review your decision maker selection and decision method
with your project’s executive sponsor in advance of the meeting to ensure
they’re comfortable, whether you identify them as the decision maker(s) or not.
If you expect them to articulate the decision, make sure they know what you
expect before the meeting. Your executive sponsor may need the project
stakeholders to acknowledge that all the gating criteria have been met, but don’t mistake
concurrence with veto power.
Decision Makers
Executive Sponsor(s) This is the simplest model, either the
sponsor agrees that gating criteria have been met and the gate is passed, the
criteria have not been met and the identified action items must be closed
before the gate can be passed, or the business case no longer justifies
continuing the project. Your project’s executive sponsor(s) will be the only
stakeholders empowered to determine the project Business Case no longer
justifies continuing the project.
Project Manager Another simple model. You take on the
role of the executive sponsor in this case and your authority (with the
exception of deciding on the Business Case) is identical to that described
above.
Project Stakeholders These stakeholders may include partners,
either internal or external, sub-contractors, vendors, the executive
sponsor(s), clients, customers, and of course, yourself (as project manager).
The sponsor and/or yourself will have the same level of authority as the rest
of the stakeholders or decision makers in this case.
Decision Process
The decision making process where one person (either the
executive sponsor or yourself) has authority over the decision is straightforward,
just get the person to articulate the decision. When all or a subset of the
project stakeholders must make the decision, you’ll need to employ one of these
processes.
Majority A majority of the decision makers must agree
on the decision. If there are an even number of decision makers, you’ll have to
identify a tie breaker. This is probably the least useful and least used of the
methods. The drawback to this method is the risk of a stakeholder disagreeing
with a majority decision and either overtly or covertly sabotaging it.
Consensus This is a type of majority decision: the
majority of decision makers agree on the decision and the rest can "live with”
it. This means they don’t agree with the majority but can see the value to the
project of their decision and are prepared to support it.
In my experience, no matter how diligent the project manager
and team are in dotting the i’s and crossing the t’s on their project
deliverables and resources, Gate Meetings seldom end in a clear cut decision to
pass the gate. The pass is usually contingent on some issue being addressed or
action being completed.
Pre-Gate Meetings
Gate Meetings run the risk of having "dirty laundry” aired.
The most critical gates, or larger, more complex projects are more prone to this
risk than ones where the project manager is thoroughly acquainted with all the
deliverables and resources. Going into the Gate Meeting without a complete
knowledge of the status of each deliverable and resource, or outstanding issue,
is a guarantee of an ambush. Remember, the stakeholders are there to speak on
behalf of their interests, not on behalf of yours or the projects. Don’t expose
yourself to the risk of an ambush in front of your executive sponsor if you can
avoid it.
A good way of avoiding an ambush is to conduct a pre-Gate
Meeting a week or two before the actual Gate. The meeting should be conducted
in exactly the same fashion as the actual Gate with the exception of the
invitee list. Your executive sponsor, client, or customer, should not be present
at these meetings. Your pre-Gate is similar to a rehearsal for a play. If there
is any dirty laundry to air, such as a deliverable not completed to the
satisfaction of a stakeholder, the pre-Gate Meeting ought to uncover it.
Holding the pre-Gate a week or two before the actual Gate Meeting provides you
with the time to address the objection before the actual Gate Meeting.
Don’t
forget to "Cc:” your executive sponsor on the invite to the pre-Gate. In case
you have any political enemies in the ranks of your stakeholders, the knowledge
that your executive sponsor is aware of the meeting and it’s purpose should
guarantee that the stakeholders won’t hold anything back during the pre-Gate
that they later air in front of the sponsor at a Gate Meeting.
Follow-up
You must communicate the results of your Gate Meeting to the entire project team. If your project includes a "general" mailing list, use that as your "To:" list for the communication. You need to communicate the meeting's decision. If the decision was a straightforward "proceed" or "stop", communicate that and the reasons behind the decision. If the decision was to proceed contingent on some actions being completed or issues resolved, identify the actions or issues, their owners, and due dates.
You may capture actions or issues identified during the meeting in your project's Action Register or Issue Log. If so you will need to identify these with the Gate so they can be uniquely identified. When the issues are closed or actions completed, communicate the closure/completion to the same "To:" list as the original communication.