In my first post, we discussed the agency model paradigm and how it differs from the internal PMO model. We also talked about understanding of the opportunity, itself. In Part 3, we look at how you manage the client experience from end to end, both externally from the client’s perspective and internally within your firm.
As a project manager in an agency model, your strategic goal is simple; when your client hangs up the phone after talking to you, they should think “If only ALL my vendors were like THIS vendor, then I’d be set! My project manager and the project team have my back. They ‘get it’!” How can you achieve this goal? Let’s start with the external side; what your client can see:
- Execute and Deliver: Your tactical goal is to manage the solution of a problem which means first and foremost, you and your team must execute and deliver. Solve the problem in a timely manner and at a reasonable cost to the client.
- Make It Safe To Walk Down The Hall: Understand what your client needs to know so that they can safely walk out of their office, knowing that if anyone asks about their project, you’ve updated and prepared your client in their language to speak knowledgeably about the project – particularly with regard to project risks or issues.
- Details, Details: Remember the little things, such as spell checking all your documents and emails, ensuring any re-used artifacts have the former client’s name removed and the new client’s name included, getting people’s names right, etc. This also includes preparing your project team for on-site client meetings, making sure the team is appropriately dressed and sufficiently updated on the nature of the client and the desired outcome of the meeting. I won’t go into every detail here, but understand that the little details can have a strong impact on you and your firm’s brand with the client.
- Under Promise / Over Deliver: Make sure you build in any cushion when making commitments. Your goal is to “under promise/over deliver,” so it’s important to make sure you understand the other commitments made by people on your project team who are also assigned to other projects. Ultimately, your client needs to feel as though their project is the ONLY project, so your ability to understand, negotiate and ensure proper resourcing within your firm will have a strong impact on your ability to deliver.
- Proactive Communications: Your client should never need to call you for an update – you should be calling them. Be proactive and anticipate your client’s needs, then meet them.
- Keep It Business-Focused: Your communications with your clients – even when technical in nature – should be such that they can be understood in terms of your client’s business operations. This not only shows respect for your client, but it also ensures that you give them information in language that they can easily understand and share with other people at their firm, thus helping your client look great.
Managing the experience also has an internal component. Most agencies share services such as creative and production design, development, QA, business analysis/strategy, etc. Therefore, you’ll have to manage the experience from a perspective that won’t be immediately visible to your client:
- Relationships: Your ability to build, maintain and leverage relationships with all the functional groups within your firm is key to your ability to delivery a strong, consistent and positive client experience. Make sure you know key people in all groups, particularly the people you’ll need when escalating an issue. Know who the strong players are, as well as the weaker links. Learn how to work with and, if necessary, work around the weaker players on the various teams. Until weaker players leave or are “enabled to leave,” they work at your firm and they’re who you have – it’s on YOU to learn how to get them to deliver.
- Accountability: Learn to respectfully but consistently hold people accountable for delivering. This means being very clear on what you need, when you need it and what will happen if you don’t get it. If you are waiting on a deliverable from an unreliable resource, it’s on YOU to check in a little more frequently that you “should have to”.
- Respect: Be respectful of the other members of your project team, as they most likely have other commitments to other project managers on other projects. Most agencies leverage shared service models, so while your customer needs to feel as though their project is the only project, you have to be smart enough to understand that within your firm, this is not the case. Respect and understand this fact, then collaborate/negotiate accordingly.
- Risk Planning: Make sure you communicate any tight deadlines, making your needs and expectations clear, potential impacts understood and then hold the team accountable. Follow the adage of “inspect what you expect” and don’t leave yourself open to surprises. If you have resources working through the weekend on a tight deadline, do you have everyone’s cell numbers? Do these resources know you need them to work through the weekend? Do their managers know, as well? Take some time to think about what COULD happen (as opposed to what SHOULD happen) and plan accordingly.
- Communicate, Communicate, Communicate: As the project manager, it is your responsiblity to make sure everyone has the information required to do their jobs and to deliver for your client. Make sure you’ve share the right information with the right resources and over-communicate when necessary. Make sure you tell team members what you need, when you need it and clearly explain the business impact if you don’t get it.
Ultimately, Managing the Experience is about two things; relationships and delivering. You leverage internal relationships to ensure your shared project resources within your firm meet their commitments to you and your client. You likewise leverage relationships with your client to collaborate as one team to solve the business problems at hand.
Delivering a powerful and positive experience helps ensure that the next time your client has a problem, their first instinct is to call your firm first. By doing so, you not only achieve your tactical goal of solving the client’s business problem, but you also achieve a valuable and lasting strategic goal; building a lasting and mutually beneficial partnership to help your client achieve and maintain a competitive advantage over their competitors and to help your firm grow revenues organically.
© 2011, Mark E. Calabrese
In my first post on this topic, I talked about how project management in an agency model differs from project management in an internal PMO model, primarily that in the agency model, the client chooses the firm from among other firms. This presents a unique opportunity for the project manager and this post discusses that opportunity.
Throughout the sales process, clients meet and interact with account managers, account executives, sales personnel and even with the firm’s senior management. Yet the client’s lasting perception of the firm rarely comes from these interactions. Firm branding is a result of your client’s direct experience with your firm, which is almost always through the project manager. Given this reality, the project manager has an opportunity to brand the firm, develop a strong partnership and act as business development resource.
Every email you send, everything you say or do, every issue you resolve, even how you prep your project team for interaction with the client; EVERYTHING you do and manage on the project brands your firm. Therefore, be mindful of how you use this opportunity to not only add value for your client, but to present your firm as a trusted advisor (as opposed to an order-taker) to your client.
Even though everyone on the project team – development, creative, testing and business analysis resources – doesn’t necessarily report to you, you still are accountable for delivering an outstanding client experience as you work to solve the business problem(s) outlined in the client’s statement of work. Therefore, build solid relationships within your firm so you can make the most of this opportunity as you work with other functional teams in the SDLC.
Earning the role of a trusted advisor helps lay the foundations for a strong and mutually beneficial business partnership between the firm and the client. Project managers should therefore be mindful of the experience they manage, end to end. Work to add value for your clients but also strive to ensure the next time your client has a problem, their first instinct is to call YOUR firm first. This is the opportunity before you as a project manager.
Project managers also have the opportunity to gather business intelligence on the client’s other needs and how the firm can assist. I’ll discuss this more in a future post.
© 2011, Mark E. Calabrese
Project Management in an Agency Model: Understanding and Leveraging the Strategic Opportunities (Part 1)
Simply stated, a project solves a business problem at a reasonable cost and in a reasonable amount of time. In an internal PMO model, the work is performed as part of an inter-company allocation with the “client” usually having no choice as to who will perform the work. In an agency PMO model, the client chooses the firm from among other service providers with the business problem being solved in exchange for client payment. In the internal model, the business relationship is by necessity; in the agency model, by choice. The strategic opportunity for a project manager in an agency model, therefore, is to influence this choice to the mutual advantage of the client and the firm.
Project managers in both models are responsible for managing project outcomes and for providing strong communication, planning, project control (especially scope and risk management) and regularly managing expectations. In both models, the tactical duties are the same – ensuring that the project solves the business problem in a reasonable amount of time and at a reasonable cost. To that point, clients are more likely to be accepting of a project that runs over budget and behind schedule, provided that it solves the business problem.
Understanding the nature and context of the business problem to be solved is a step toward understanding and leveraging the strategic opportunities available to project managers. Doing so will help you understand your client’s business and inherent challenges but most importantly it is a key element in earning the role of a trusted advisor to the client. Trusted advisors have an advantage over service providers, as the trusted advisor is more than just an extra pair of hands; it’s an extra pair of hands with a brain that “gets it” from the client’s perspective.
Trusted advisors and the firms for which they work get asked back, specifically because their words and actions differentiate the firm from other service providers. They do more than take orders; they add value by leveraging understanding, applying their own knowledge and making their client’s success their mission. Project managers in an agency model should leverage the opportunities below to initially and continually earn the role of ‘trusted advisor’ role the course of managing client projects:
- Understanding The Opportunity
- Managing The Experience
- Knowing The Business
- Acting As A Steward
- How Else Can We Help?
By understanding and leveraging the strategic role of a project manager in an agency model, project managers can add significant value to their firm. They can use every email, phone call, discussion or action as an opportunity to consistently brand the firm and deliver a strong, positive experience to the client while solving the business problem as scoped in the Statement of Work.
In the next posts, I’ll cover each of the bullet points above in more detail. The end goal is to help your firm build lasting and mutually beneficial partnerships with clients, which not only helps each party in the business relationship, but helps you grow as a professional both in skill and in personal brand.
Often times we’re tempted to add new processes, new templates or tools, modify existing procedures, re-organize – you name it. Sometimes such changes are called for, but other times they’re performed for the sake of performing them. Change for its own sake is never good. It can be a drain on time, resources and on morale.
When confronted with such ideas – whether your own or from others – try asking these two simple questions:
- What Business Problem Will This Solve?: Is the proposed change in response to something that is having an identifiable impact on business operations? If so, how will this change help?
- What Will This Change Allow Us To Do Tomorrow That We Cannot Do Today?: Little more than a restatement of the above, this simply asks the question from another angle. It’s important to understand how things will change as a result of any new processes, tools, etc. Then….ask yourself, “So what?”
While you can apply these questions to process or organizational changes, you can also use them when determining whether to send an email, schedule a meeting or conference call, etc. The idea is to simply be mindful of what you are about to do. Think of it as an internal CBA on the fly or, to borrow a quote from my friend, John Kennedy, “Break it down, think it through, execute!”
© 2011, Mark E. Calabrese
I don’t agree with the whole “good news/bad news” paradigm. There is only “news delivered” and “news withheld.” The difference is whether the news is delivered well or delivered badly.
It’s tempting to withhold “bad news.” Sometimes we hope that things will change and we won’t have to deliver the news. Other times, we hope that we’ll have more and better information later. In both cases, we tend to do the wrong thing by failing to share what we know with those who have an interest in knowing it. This doesn’t change the nature of the news, but it may complicate your ability to resolve the situation.
The worst way to deliver such news is to put it off until you have no choice, then deliver the news late. If you think the recipient is going to be unhappy when they hear the news you withheld from them, just think about how angry they’ll be (with YOU, by the way) when they find out that you ‘ve known for a while but didn’t bother to tell them. You could try to cover up this fact too, but now you’re complicating things even further.
Another way to deliver such news badly is to do only that – deliver the news. You do a disservice by showing up and only presenting a problem. What’s the context? What’s the impact? What should we do? You need to do more than show up and deliver the news. You need to provide leadership. A better approach is to do one of two things:
- Deliver the news right away with assurances that you/your team is looking into options to address the issue and that you will have options and a recommendation forward by a specific date/time; or
- Get with your team first to develop the options and a recommendation forward, THEN go deliver the news, options and recommendation.
This is just the same approach at two different points in time. You’ll judge which is most appropriate based on the nature of the news and the business impact to the stakeholder. You also have to consider the temperment of the stakeholder in framing your delivery (that’s another post entirely). The goal is to get everyone informed, in agreement and focused on addressing the issue as a team and moving the ball forward.
We’ve all played “How Did This Happen??” where a customer or business partner demands timelines, root cause analyses, written assurances that this will never happen again, etc. While there is value in “How Did This Happen??” in the right context, this exercise is usually intended as a punishment or to send a message. This is more typical of an ‘Us and Them’ relationship and not the product of a true partnership. Producing timelines doesn’t solve the problem. Avoid this.
I like this simple approach. Provide the recipient with the following:
- High level details of the issue: “What happened?”
- Business impact: “Why should YOU care?”
- Options (including pros and cons for each): “What CAN we do?”
- Recommendation (yours or your team’s): “What SHOULD we do?”
- Request a decision
If you do this verbally, follow-up with a summary in writing, capturing all of the above and cc’ing other appropriate stakeholders (particularly any members of your team who provided input and who may also be implementing the solution). Root cause analyses and lessons learned come after the fact, but initially you want a team commitment to solving the problem, not in assigning blame.
Delivering “bad news” does not have to be painful, but you do no favors by withholding information. Go ugly early, but provide options toward getting beautiful again. Don’t deliver problems – deliver solutions.
© 2011, Mark E. Calabrese
In reading Patrick Lencioni’s “Death by Meeting” a few years ago, I came across a simple and effective idea: the daily ‘stand up’ meeting. Often employed in Agile development, the concept is a simple one; the project team meets for 10 minutes each day for a quick meeting where everyone literally “stands up” and the focus is on three simple questions:
- What did you do yesterday?
- What are you doing today?
- What do you need from me (the project manager, business sponsor, etc.)?
I’m currently working with some great clients who are making good use of this approach. We meet every morning, knowing the agenda (above) in advance. After about 5 minutes of respective prep work, the participants are ready to go. Everyone understands that issues that only impact several members of the team are to be addressed after the meeting in a smaller group, made up of those stakeholders.
I think there are several benefits of this approach:
- Teaches participants to collaborate to conduct highly efficient, content-rich meetings
- Allows everyone to hear each other’s expectations of the day and each person’s take on what they believe they did the day before, providing a great opportunity to catch any problems, miscommunications, accountability issues or potential risks
- With strong leadership of the meeting itself, the team remains focused (the leader will need to work hard to enforce the ground rules while at the same time not taking a dictatorial approach to running the meetings)
- Significantly reduces the chances of unpleasant surprises
If you choose to employ this method, a few tips:
- Prepare ahead of time and insist that all participants do the same
- Everyone should be on time
- Minimize distractions – make sure everyone is focused on the speaker and not sending emails, texting, making/taking calls
- Stay focused, but make sure that any topics brought up that aren’t appropriate for all participants but that are critical to the project are acknowledged and dealt with as soon as possible after the meeting
While the ‘stand up’ meeting isn’t a substitute for a more comprehensive weekly project team meeting, its great way to manage expectations, make sure the team is communicating, and to manage risk.
In a world where we’re deluged with information on a daily basis, writing effective emails is an important skill. I’m a big fan of the ‘above the fold’ approach. In the publishing business, ‘above the fold’ refers to placing important information ‘above the fold’ of the newspaper to entice someone to buy the paper*. In writing email, the concept is the same – enticing your reader to READ your email and perform the desired action. Here are some tips and tricks on writing ‘above the fold’ emails:
DEFINE THE OUTCOME: What is the desired outcome of the email? What do you want to happen? ANSWER that question before you write, then use the answer as a litmus test, asking yourself “is this information absolutely necessary to achieve the desired outcome?”
BLOCK CAP THE SUBJECT: Make it clear what’s coming. For example, if you’re asking the recipient to do something, try a subject line like “ACTION REQUESTED: Budget Review/Approval” or “REPLY REQUESTED: Input To Communication Plan”.
ASSUME THE RECIPIENT WON’T READ PAST THE FIRST PARAGRAPH: This will keep you from rambling. Refer back to your defined desired outcome to keep it concise.
CALL OUT THE REQUEST: If the subject line says that an action or reply is requested, call it out in the email. Start the second paragraph with ACTION REQUESTED: <What you’re asking the recipient to do>. You can even call it out by making the text red.
USE A FRAMEWORK: Using a framework not only makes it easy on you when you write an email, but it helps your regular readers when they know that emails from you tend to follow a framework that is respectful of their time and gets right to the point. One that I like goes as follows:
- What: What you need
- When: When you need it
- Why: What the business impact is if you don’t get it
MULTI-PARAGRAPH EMAILS: Sometimes, even the best writer has to send a multi-paragraph email. In such cases, you still need to assume that your reader isn’t going to read past the first paragraph so you have to catch their attention and give them a reason to read on. The first paragraph should explain the situation that prompted the email and why YOU, THE RECIPIENT needs to care. Here’s an example:
- “As you know, we are currently working on a project to sunset our existing CRM application and replace it with a new application. The project must be completed before the end of July, as our busiest time of the year begins in late August/early September. There are several issues that must be resolved in the next two weeks if the project is to remain on schedule. Each of these issues requires your approval. The issues and requested actions are summarized below:”
Make sure that the first sentence of every paragraph summarizes that paragraph. This will keep you focused while you write and will also protect you if your reader takes the ‘how to read a business book’ approach and skims the first sentence of each paragraph.
PROOF: Read the email before you send it, asking yourself if everything you’ve included is really necessary to create the desired outcome.
Writing clear and concise emails not only is respectful of your reader but helps build a personal brand that ensures your emails are read!
© 2011, Mark E. Calabrese
In Part I, we talked about setting up the postmortem meeting and in Part II, we discussed conducting the postmortem meeting itself. In Part III, we’ll focus on creating a deliverable that can be used to exploit both short-term and long-term opportunities through Action Items and Lessons Learned, respectively. Consider the following in completing your deliverable:
- Respect The Framework: The framework focuses on Pluses or Deltas in each phase of the project or incident. Therefore, only capture those practices that were successful and should be kept (Plus) or that were unsuccessful and should either be changed or discarded (Delta), by phase.
- Action Items or Lessons Learned: Every Plus or Delta captured in the postmortem must result in either an Action Item or a Lesson Learned. Action Items are specific actions that should be taken in the short-term and are assigned ONE owner and a due DATE. Lessons Learned are easy-to-understand guidelines or principles that are understandable on their own and do not require extensive knowledge of the project or incident in order to make sense. More on Action Items and Lessons Learned can be found below.
- Simplicity: Use a simple template and keep the contents pragmatic (I’ve attached a sample template, below). Some additional content, such as names/roles of participants, overview of the project or incident, etc., can be beneficial but the primary contents are Pluses and Deltas by phase and resulting Action Items and Lessons Learned. KEEP IT SIMPLE, creating a deliverable that is READABLE and USEFUL.
If you plan to submit your postmortem document to your business partners as part of project or incident closure, you may wish to include additional content. That said, strive to keep the content simple, direct and to the point unless circumstances DEFINITELY require otherwise.
ACTION ITEMS: Action Items can include, but are not necessarily limited to, any of the following:
- Meetings or Discussions: Meetings to discuss a process change or process development, a potential risk mitigation strategy, etc. In other words, setting up a meeting that might have otherwise have resulted in a problem-solving or sidebar discussion during the postmortem. Do NOT conduct such discussions in the postmortem; conduct them on their own, with the appropriate stakeholders in attendance, and call out an Action Item to make the meeting happen.
- Specific Actions: For example, any code changes, configuration changes, etc. Any specific actions required in the short-term to address any issues that were raised during the postmortem or immediately after project go-live or incident closure.
Action Items have ONE owner, who is accountable for completion. Even if multiple resources will be involved in completing the work, there is only ONE person accountable for ensuring the item is completed and closed by the due date.
Action Items have a Due DATE. The postmortem facilitator should have the Action Item owner set the due date, but if the owner hedges, suggest a due date to them and NAIL THEM DOWN. The due date can always change, but get a commitment during the postmortem and DOCUMENT IT.
LESSONS LEARNED: Lessons Learned should be archived in a single Lessons Learned Master Document (e.g., a simple MS Word document with bullet points). You can categorize Lessons Learned by phase, etc., but be careful; the more you play with the list, the more likely you’ll end up making a task out of maintaining the list. Better to maintain a simple list that can be printed out and reviewed at the start of every project as a reminder of what was learned in past projects and what should be considered in the current project.
Each Lesson Learned should be stated very clearly and concisely and should be understandable ON ITS OWN and on a FIRST READ. Lessons Learned should NOT require detailed knowledge of the project in order to gain context and understanding. Therefore, it’s important to edit each Lesson Learned to make sure they are well written. Have someone who is NOT familiar with the project or incident review the final Lessons Learned for readability before they’re added to the overall Lessons Learned Master Document.
Review the Lessons Learned Master Document after each project or incident to ensure there are no duplicates and also to ensure that, as noted above, each lesson is clear and understandable. Production support/service restoration issues will now allow the luxury of a review of the Master Document at issue identification, so support teams may wish to review the Document on a regular basis as a risk mitigation strategy.
The template below is a baseline document to be stolen/edited it as you see fit. As always, I welcome any comments, questions or thoughts and can be contacted at firstname.lastname@example.org. Good luck!
© 2011, Mark E. Calabrese
In Part I, we talked about setting up the postmortem meeting. The postmortem is part of a project or release close out and is also beneficial (and should be used) at the close of any security or production support incident, etc., as part of the RCA (root cause analysis). Bottom line is that any time a project, incident or initiative is closed, there’s an opportunity to capture any lessons learned and leverage the knowledge going forward.
I’m a big fan of the ‘Plus/Delta’ framework for capturing postmortem findings. In this framework, a Plus is any practice, process or finding that worked well and should be kept or repeated in the future. Conversely, a Delta is any practice, process gap or risk that resulted in a problem and should be changed or fixed. Identify Pluses and Deltas for each phase of the SDLC/Project Life-cycle:
You can use this framework to conduct the meeting, as well. Keep it simple; for each phase, discuss and document all Pluses and Deltas. For incident postmortems/RCAs, you can be flexible on the specific phases (as the SDLC or Project Life-cycle may not be appropriate). For example, incident postmortems can make use the following phases:
- Short-Term Resolution (how was the problem fixed?)
- Long-Term Resolution (how do we make sure the problem doesn’t happen again?)
The point is to go through the incident or project in a logical, chronological fashion, capturing Pluses and Deltas.
Here are some guidelines to consider in facilitating the meeting:
- Who Should Facilitate the Meeting: The facilitator should NOT be a member of the project or incident team. The reason that the facilitator shouldn’t be someone involved in the project or incident is that you want THOSE resources to contribute content, while the facilitator is responsible for guiding the meeting, keeping it productive and acting as…..well….as the facilitator. It’s also best to have a neutral party facilitating the meeting in the case of a not-so-successful project or issue resolution. This avoids anyone thinking that, for example, the developers got off easy because the facilitator was the lead developer on the project. The facilitator should be someone familiar with the team who can keep the meeting controlled and productive. You can facilitate the meeting if necessary, but it’s always better if it’s someone at the same level as those on the postmortem team.
- Pre-Meeting by Functional Teams: The postmortem team should not just “show up” for the meeting and figure it out as they go along. Each functional team (e.g., the Development team, the QA team, the network team, etc.) should meet on their own beforehand to discuss their specific observations. During this pre-meeting, each functional team should use the framework below to document their findings, then publish these findings to the rest of the postmortem team in advance of the meeting. This will help stimulate thought and discussion, resulting in a more productive postmortem. Strongly encourage all participants to review the combined findings beforehand. The facilitator can also combine all the findings into a draft document and send it to participants in advance as well as using the document on the overhead to guide the meeting.
- Documenting: Use an overhead projector and a laptop to avoid any double-work in documenting the findings. If that’s not an option, use a white board or easel and get everything written down and into the document as soon as the meeting is over (and throw all that paper away). Only document findings that will result in an ‘Action Item’ or a very clear ‘Lesson Learned’. For example, documenting that the QA team did “a really great job” feels great but it has no pragmatic benefit going forward. The point is to create a deliverable that is useful beyond the project or incident.
Establish and communicate the ground rules in advance of the meeting and review them as the meeting begins. Make sure you follow the same rules for each postmortem. The facilitator MUST be very clear on the ground rules and tactfully enforce the rules while not quashing discussion (particularly with the ‘No Problem-Solving’ rule; that is the hardest to enforce, I guarantee!). Here are some ground rules to consider:
- No Problem-Solving: The purpose of the postmortem is to capture Action Items and Lessons Learned and NOT to solve all the problems that came up during the project or incident. Problem Solving sessions are Action Items and should be conducted outside of the postmortem and will include all stakeholders in resolving the particular issue or process gap. While you will DEFINITELY have people in the meeting who’ll want to tear into a problem and start kicking around ideas, the facilitator has to stop this and instead, note an Action Item to set up a meeting to tear into the problem and NOT do it during the postmortem (if you ever want the meeting to end, anyway!). Trust me – this is the one rule you’ll be enforcing right up to the end of the meeting, so be very tactful and positive about this – again, you do NOT want to quash discussion and have people shut down/not participate.
- Processes, Not People: When focusing on some of the Deltas, avoid focusing on the actions of specific people. Focus on the process gap and not the person. If someone’s actions caused a problem, this is evidence of a process gap that allowed something bad to happen. If someone falls through a hole in the floor, firing the person who fell through the hole WILL get rid of the “faller” but the hole remains; fix the damn hole. Besides, focusing on the people will lead to bad blood both during and after the meeting. Don’t allow this to happen.
- No Distractions: This one is obvious. The “no sidebars” rule is important and, to my mind, goes without saying. I also recommend a ‘no Blackberries/iPhones’ rule. With the sole exception of someone who has a specific reason, production support issue, etc., that necessitates that they keep their phone near them during the meeting, instead set up a “coral” (i.e., a shoe box or something) to house everyone’s phones and allow a break every 45 minutes / 1 hour for people to retrieve and check their phones. This keeps the meeting focused and is respectful of other people and their time.
- Action Items: Action Items have ONE owner, who is accountable for ensuring the action is completed. It’s true that Action Items usually have many stakeholders/participants, but only ONE person accountable for delivering – period. Also, ‘TBD’ is NOT a due date. Due dates have specific dates, months and years. You can always change a due date but do NOT let anyone walk out of the meeting with an Action Items assigned to more than one person and with no firm due date.
- Follow the Framework: Make sure you follow the framework in order to maintain focus. For example, for a project you’ll start with the ‘Intiating’ Phase and discuss what went well and should be repeated/kept (Plus) and what went badly and needs to be fixed/changed (Delta). The idea is to keep the framework simple and clean and focus on identifying the action items and lessons learned.
Basically, your facilitator ensures that the brainpower in the room produces a solid list of Action Items and Lessons Learned and makes excellent use of everyone’s time. The facilitator should ask for anonymous feedback after the close of the meeting – what could have been done better/different? Another good opportunity to capture some learnings. Also, allowing others to facilitate and avoiding the task yourself is a good way to build leadership skills in your team. If your team is new to this process, you facilitating the first few sessions to establish precedence is worth considering.
In Part III, we’ll discuss the postmortem deliverable and I’ll include a sample.
© 2011, Mark E. Calabrese
Part of closing out any project, outage, service restoration team effort or any initiative whether succesful or otherwise (and it’s even more critical on the “or otherwise”) is the postmortem. Too often, this milestone in the ‘Closing’ phase of a project is either ignored or not fully exploited. I’d like to share some guidelines on conducting a succesful postmortem that net useable results.
While the guidelines below are not meant to be all-inclusive (I like to keep my posts short; no more than 2-3 scrolls as my friend Greg Hubbard at Cenage wisely advised). Use your judgement on what to add, modify or ignore. In Part I, we’ll focus on the meeting itself (timing, participants, etc.):
- Setting Expectations: Make it known either at the start of a project, early in the SRT (service restoration team) effort during an outage or just as a general principle of your management style that you will hold a postmortem after project or issue closure. This will help ensure that people will take note of the good, the bad and other learning opportunities.
- When To Meet: Schedule the postmortem shortly after successful project go-live, or as soon thereafter as is practicable. The key is to schedule the meeting so that doesn’t interfere with any critical post go-live activities but soon enough to capture any learnings while they’re still fresh in everyone’s minds.
- Where to Meet: Pick a conference room that has lots of room and ideally, lots of natural lighting. You want to keep people awake and talking in order to get good input that can be used well after the project is completely closed out. Make sure there are plenty of white boards or easels with tear-away Post-It sheets as well as markers that work. Finally, have some coffee, water, pop (or ‘soda’ as you east coast people insist on calling pop) on hand. I’m not a big fan of food at a meeting, but that’s your call.
- Conference Calls: Ideally, you want people to be there in person but these days that’s not always practical or possible. Do the best you can. In Part II, we’ll discuss how to ensure good engagement and input from those dialing in.
- Who To Invite: Include everyone on the project team, especially business partners who were critical to both the decision-making process as well as in any UAT, JAD sessions, requirement gathering/approvals, etc. Ultimately, you want to include everyone who did the “real work” on the project, as well as any key stakeholders or project influencers. If you find that the list of attendees is becoming unwieldy, try to limit it to those who have the most knowledge of what went right and wrong on the project and also make sure they are people who will SPEAK UP AND GIVE THEIR OPINIONS!
- Timing and Duration: Set aside at LEAST two hours and try to hold the meeting on a Tuesday or Wednesday morning. Mondays tend to be busy and Fridays, people have other things on their minds (or may be working from home). I prefer mornings, as afternoons can be “sleepy time” for some people, so earlier in the week and early in the day is optimal. I like 9AM until 11 or 12.
In Part II, we’ll talk about conducting the postmortem meeting and in Part III, we’ll talk about the deliverables and putting them to work for you, your team and your organizations beyond the project so that you truly CAN leverage lessons learned. Stay tuned.
© 2011, Mark E. Calabrese