Voices on Project Management

> Back to Voices Home

More posts in Lessons Learned

To Have and To Hold

| | Comments (0)
In one of my previous posts, I suggested ways to maintain documentation. And as you know, documentation is very important -- it's the essence of knowledge transfer. The beauty of documentation is that it allows us to avoid the pains of reinventing a series of events that may only reside in a person's mind as a singular experience. It can also lead us to extract some aspect that may move our project from uncertainty and unknowns to more useful information. 
So, once we have taken the precautions I mentioned in my previous post for generating clear and valid documentation, the question becomes: What project documentation should we always have and hold on to? I would suggest, at a minimum, the following:

The charter. It is the closest disclosure to everything the project should touch on. It includes a high-level look at the project: resource list, budget, timeline, assumptions, constraints, risks, other areas of impact and dependencies, a brief description and an immediate focus. 

Budget background and expenditures. This information typically details the budget spending and directs you to possible future support, if any can be used again.

Sources. These include contacts and stakeholders; where information is stored; direct lines of contact; contacts who would be next in the succession; who and where to reach out to in case of additional needs; and where information stemmed from, and how it should be categorized and even prioritized.

A status report of risks and issues in their most recent form. These items show the progress that has or has not been made and is especially helpful in communicating to a new project manager (or yourself, if returning to a project) where to pick up. This status report can even help determine the project's resource needs.

Scope. This tells you what should have been the focus of the project. It also helps determine whether there needed to be an extension to this scope or if something different should be embarked upon, such as a total new project or maybe a revamping of the current scope. 

Are there any types of documentation you find significant to have during a project and to hold on to after a project closes?

From Lab to Hospital, More Lessons Learned

| | Comments (0)
Voices_Vivek_Customer Service 2.png

In my last post, I discussed my experience at the lab and insurance desk at a hospital. Now I'd like to share the remainder of the story and my analysis on the lessons learned from the hospital stay. 

A nurse on my first evening in the hospital asked me to sign some papers. As I read the papers, there was a note that said I should not sign if the paperwork was not explained to my satisfaction. I looked at the nurse and said, "No one has explained anything to me. How can I sign?" The nurse looked at me and asked me to hold on for a moment. After some time, a doctor came, explained the process and situations that could arise during the operation. I asked some more questions that he answered, and I signed the papers. 

Thursday morning, the operation was completed successfully, with follow-up visits by the doctor and nurse. On Friday, the process continued. A group of three senior staffers came in the room, introducing themselves as administrators, and asked if the air conditioning, food and other services were okay. In the evening, the doctor visited again and told me all was well and he would discharge me the following day. He said he would start the process in the morning and requested my patience as the billing and insurance-approval process might take many hours, even perhaps the whole day.

On Saturday morning, the administration staff visited again and asked if all was well. At noon, the staff took my signature on the bill and asked me to wait for approval. I sat around and inquired about the approval few times, but no luck. I finally got approval by 7 p.m. -- but by that point I had had dinner at the hospital and afterward moved to my house. 


My experience at the lab and at the hospital were quite opposite. At the lab, the work at hand was minor, but it escalated. However, at the hospital the work at hand was greater and there were more opportunities for issues to arise, yet all went well. I think it was the hospital's well-defined process and disciplined execution that allowed for a smooth experience.

Takeaway 1: Words Have No Meaning, Only Action Works

At the lab, the manager was trying to defuse a situation by promising and explaining, but actions were missing, and therefore the matter became heated. At the hospital, when I was asked to sign papers without explanation, I raised the concern -- and the nurse and doctor both handled it well by doing what was expected without uttering a single word to the contrary. 

Takeaway 2: Keep the Ego Under Control

The manager at the lab appeared to possess a big ego. First, he did not accept the problem; moreover, he defended his and his team's actions. Second, as he was also a doctor, he could have collected the blood himself but chose not to, perhaps because it wasn't in his job description. He missed the opportunity to win over customers and set an example for his staff. 

Takeaway 3: Set Expectations

If the hospital staff had not set expectations that it would take two hours for approval on the estimated cost and a whole day for approval on the final bill, I would have waited impatiently and probably fought with the staff over the delays. But setting expectations in advance helped them control customer reactions and achieve satisfaction.

Takeaway 4: Have a Process, Maintain Discipline and Re-evaluate

The most interesting thing I found is that the administration staff visited my room twice and personally asked if all was going well. They were monitoring that discipline was being maintained and if anything in the process needed to be fixed. I think this was critical in ensuring foolproof processes and disciplined staff. 

What's the top customer service lesson you've learned from an unlikely source?

Customer Service Lessons -- From a Hospital?

| | Comments (4)

Recently, my doctor advised me to go in for a minor surgery, so I had the opportunity to visit a clinical lab and stay at the hospital for three days -- an unlikely place to learn some customer service lessons. 

Before the surgery, I had to undergo blood tests. There was only one attendant at the blood collection center and a long queue. A woman at the back began complaining about the queue until a nurse came out, took that woman to a room and drew her blood sample. This upset others in line and led to more complaining. The manager came out from his office and asked people to calm down. But after time passed with the queue remaining as long and the manager offering another assurance, people became agitated again. This time, the manager told some people they were unnecessarily raising their voices while he was trying his best. This continued until another staff member (possibly late to his shift) came in.

This experience made me think: Do mere assurances work all the time? Don't we need to apologize for unfair treatment and take action to correct the wrongdoing? Perhaps our egos do not allow us to do all this. So what does it take to control our ego?

After finally getting my test, I scheduled the surgery. The hospital suggested I come in beforehand to complete the formalities of cost estimation and approval from my insurance (a procedure in India for cashless treatment at a hospital). 

When I arrived at the hospital's insurance counter, the attendant in charge took me to a room, asked me to fill out a form and told me that a few people are involved in the process, so it might take up to two hours. I filled out the form in a couple of minutes and waited for 30 minutes for a doctor to appear. He asked me a couple of questions, filled out the remaining form and gave it to the attendant. She asked me to wait for another half hour while she conducted some office formalities. Half an hour passed and I became restless. I approached the woman, and she promptly explained, "I said it would take around two hours. Hold on for some more time." After half an hour, she appeared, took my signature on a form and asked me to leave. 

My experience at the insurance desk taught me a simple lesson. If I don't set expectations (as the attendant did), a customer is free to expect anything based on his or her own experience. For better customer service and satisfaction, it is important to set expectations at the beginning and then exceed those expectations.

In my next post, I'll discuss the lessons I learned from my hospital stay, and how those could be applied to project management. What customer service lessons have you learned when you least expected it, and how have you applied them in your projects?

Getting Out of Trouble

| | Comments (3)
Project trouble can hit from a blind spot, even though you tried as much as possible to prepare for issues. You did a risk analysis when you took the project on, and even tried to be ready to mitigate unknown issues.   

As I advised in my previous post, do an assessment to determine the problem. Figure out what needs to be fixed, or if the situation is even fixable. If the project seems to have reached a point of no return, here are some tips on how to pull it out of trouble:

  1. Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
  2. Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them. 
  3. Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase. 
  4. Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need. 
  5. Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources. 

Finally, keep in mind that not all trouble devours all. Before panicking, calmly look to areas that will guide you to a solution. You may even find your project is more sound than it seems.

How do you confront trouble on your project?

First Steps Toward Recovery

| | Comments (2)

In my previous post, I discussed points to help prevent problem projects. Here, I'll talk about what to do when you realize an existing project is headed for trouble. 

Let me try to explain it like this: If you are driving a vehicle, what happens when you see a red light? You know that when you come to it, you will stop. After the light turns green, you will look both ways before proceeding. When our projects hit red lights, we as project managers must also stop and assess our environment.  

As you look at the big picture, review your inputs, factors and the overall sanity of the project. Examine your risk register or issues log. Is the status of risks or issues showing something that was missed and needs to be addressed immediately? For example, something easily overlooked is when the schedule for applying security patches is on the same timeframe as the testing phase. This sort of impact can cause testing to grind to a halt, with the team unaware of the source of conflict. A review of the risks or issues log would have highlighted these events.  

Another source to review is your budget plan. Have unplanned circumstances arisen, such as the need to produce more prototypes? Does the acquisition of resources require additional time? Is equipment becoming obsolete or in need of repair? Expenses such as these caution you to slow down and reevaluate your budget. Be aware that ultimately, you may need to secure a renewed budget approval.

Consider client relationships as well. Are your clients becoming unsatisfied and impatient, regardless of how well you're completing deliverables and meeting milestones? If so, you may need to allay fears or even compromise on a feature of your project. Perhaps that means reconfirming a budget forecast, or something as simple as picking up the phone and calling the client with an impromptu status report.

One last piece of advice: Take a look at lessons learned. It's very likely a previous project manager may have outlined specific pain points on similar problem projects. These will provide valuable insights that even the most technically experienced project manager can lean on. They're good for figuring out what to do in grey-area situations: when it was difficult to get management signoff on a needed budget increase; how a concern was handled when a client change request was denied; or how to garner support when team conflicts arose.

After you recognize there's trouble ahead, how else do you assess the size of the problem?

Gen Y: Driving Lessons Learned

| | Comments (0)
Any project manager or team member can appreciate the value of historical data to learn from previous project experiences and reduce associated project risks. But have you considered whether it's available in a format that appeals to Gen Y team members?

The traditional way of capturing lessons learned is by using a template to record the lesson and saving it in a repository. But given their collaborative nature, Gen Y team members may perceive this as a limited source of information, based on the experience of a single individual. 

Instead, many Gen Y team members are pushing for a more collaborative approach, in which all project documents can be classified under categories, linked to wikis, referenced in blogs and be shared via micro-blogging or clouds. The goal is to prevent having valuable project documents stuck in one person's hard drive.

This new approach stands in contrast to the traditional view of knowledge as a finite asset, living and managed inside the organization's boundaries. With a more collaborative approach, it doesn't matter if the author of the lesson learned left the company, because the organization still "keeps" that employee's knowledge when she or he is gone.

One happy medium is to limit the collaboration environment to the employees in the organization and restricted to the project team until the project is completed. The adoption of this new way of managing organizational process assets will require the endorsement of senior management. You will also need to implement a strategy that's attractive to all team members for full adoption of a new collaboration approach to lessons learned. To do so, introduce a collaborative approach that best suits your project environment. Perhaps task the Gen Y team members to present this new method and highlight its benefits to the project during a team meeting. Finally, remember that individuals take time to accept new practices, so have patience.

How easy or difficult would it be for you to embrace a collaboration approach for lessons learned? What are the benefits for your team and your organization?

Head Off Problem Projects

| | Comments (2)
We've all seen the signs a project is about to blow up — a schedule goes awry, a budget exceeds its tolerance threshold. To prevent this, consider taking a few measures:

  • Secure executive support for major issues. Initial project documentation, such as a project charter and communications plan, will classify your project sponsors and champions, their roles and responsibilities, and escalation procedures. Rely on that, but also position yourself for frequent project status meetings with executives. 
  • Keep communications with sponsors and key stakeholders at a level that allows you to reach out to them when you may need them.
  • Be aware of your project environment at all times. Regularly review project plans against where you are and what's planned to come. It will help minimize the risk of an issue arising when you least expect it — a resource pushed to the point of no return, for example. 
  • Look for lessons learned. Review the project history for potential concerns you may want to monitor and document in your risk log. Meet with other project managers in and outside of your organization to learn about pitfalls they may have encountered and how they handled them. 
Prevention requires preparation, listening and awareness. As you interact with your team, your sponsors and other project managers, be sure to listen and look for pain points that warrant investigation. 

In my next post, I'll talk about recovery steps when facing a troubled project. For now, please share what you do to prevent troubled projects.

The Other Lessons Learned

| | Comments (0)
At a project's end, I sometimes have to tackle non-project lessons learned — those issues or takeaways that arise beyond what went right and wrong on the project. Here's how I've implemented some I have faced:

Team adjournment. Team members must now move on to other teams and projects. To mitigate the sense of loss, arrange an end-of-project reward, such as a social gathering. And if emails, instant messaging, and social media — such as a company Facebook page — were arranged for project communications, encourage new discussions via these channels to foster continued friendships.  

Changes to the organization's processes. Lessons learned should provide direction on the processes that benefit the organization the most if adopted right away. Once those are identified, speak to sponsors or executives and request that a task force be appointed to evaluate these processes further. The task force should consist of key stakeholders who can make changes to processes. For example, I organized a task force to review our quality control processes on a recent production project. During the project, our quality manager only reviewed product consistency and workmanship in the testing phase. The task force, however, determined the quality manager should be involved earlier and review elements during the design phase. This ensured design elements were consistent with other products released to market and cut down on time spent on the testing phase.

For your projects, if you determine your organization can benefit from the process changes identified during a lessons learned, embed change management principles in project plans to lay the groundwork for employee buy-in. This lessens the impact of new processes for the employee — and the organization. Finally, the changes may require new training, which you should champion. Without it, you'll have new processes, but no team members capable of following them. 

Revenue breakthroughs, good or bad. Even when your project is facing cancellation, you can help drive discussion around its closing. Prepare reports that show in-depth understanding of the issues. After all, many of the projects that get cancelled may just need portfolio realignment. 

On the other hand, if your project was successful, there is a new bottom line to celebrate. So if appropriate, publish your accomplishment in the form of best practices with organizations such as PMI. You can also prepare training sessions and webinars or publish articles about the organization's steps toward success.

Do you look beyond the project's lessons learned for other challenges and opportunities?

Alexa Beavers, PMP, submitted the best comment on Bernadine Douglas' Getting Real with Lessons Learned post. Ms. Beavers is a Petersburg, Virginia, USA-based associate director and global project manager at German pharmaceutical company Boehringer Ingelheim. She has managed projects for more than 15 years, and specializes in large-scale change management. Ms. Beavers founded the project management community of practice at her previous employer, and assisted in the development of Boehringer Ingelheim's. Follow her on Twitter at @awbeavers.

Read her thoughts on realizing change from lessons learned below:

You're feeling really good because you took the time to gather your project team and key stakeholders, to reflect on what went well during your project and what did not go so well. You even took the critical step of leaving the meeting with an action plan, with clear ownership to pursue the actions you identified. But are you getting the most out of your lessons learned?

If you don't have a simple process to build improvement into your next project, then you're not reaping the full benefits. Many project managers are familiar with W. Edwards Deming's Plan-Do-Check-Act cycle. It's meant to be a continuous cycle. Our lessons learned is the "check" stage, where we review results and identify learnings. But we can't stop there -- we have to move into "act" to get the true value of a lessons learned. Here are some ideas for how to do that. 

  1. Assign ownership and follow up. Coming out of the lessons learned, you have created an actionable plan. Make sure that you also assign a clear expectation for closing the accountability loop. Lessons learned often come at the end of a project, when project meetings are no longer routine, so it's extra important to set up a way to ensure this "crowning" moment of your project doesn't fall flat. 
  2. Look for trends. The Plan-Do-Check-Act cycle is about continuous improvement. Use your lessons learned findings to look for patterns and trends. You may find trends in traditional project processes, technical specifics or cultural aspects. Set up lessons learned standards so you can see if you are making positive strides over time.
  3. Revisit lessons learned with each new planning phase. At the start of each new project, build in a step where you look back at trends from past projects. Use this step as you build your new project plan with your team, so you can learn from experience. 
  4. Set a goal. Make it clear to your project team that you are committed to their development and growth. Part of helping your team develop is to set a goal for everyone to reach for. Look to the lessons learned from your last projects and set goals around continuous improvement.
Read other comments submitted for the guest post, or tell us your thoughts on turning lessons learned into real change below.

Getting Real with Lessons Learned

| | Comments (8)
By now, if you have been following my blog posts, you know the importance of lessons learned. In past posts, I have provided many tips on how to conduct them, who should be involved and the types of project management tools to use for  evaluation in the sessions. 

But how do you get true value of lessons learned? To glean results that can really fuel change, focus your lessons learned on the following questions and actions:

What did not go so well? Do not finger point. Ensure the discussion is targeted toward the actions, not a person. Try to gather specifics. For example, if a delay caused a slip in the project timeline, discuss the lesson that caused the specific problem, and alternatives that might have avoided the delay. Perhaps there was a miscommunication that caused the delay. In that case, extract the lesson that led to that miscommunication. These are the lessons that you want to document and mark for corrective action. Actions or lessons that are not documented well cannot be translated into controllable elements.

What went well? Determine your successes, and then strategize what needs to be done so these actions can be repeated. Adopt processes around these successes that may not already exist in your system for managing projects. If it is a process that has been working well for a long time, integrate it with your new and existing policies and procedures but in a way that it remains intact and unchanged. You should also consider rewards and recognition events for successes. There are many ways to accomplish this, even when budgets are tight. For example, using social media by posting praises and kudos to employees online can go a long way.

What are we going to do to improve projects going forward? This is really the main objective of lessons learned. You can get together to understand what went wrong and what was right on your projects, but more importantly, you will want to leave the session with a direction on how to have future successes on a continuous basis. For this to happen, take the time to rank the learnings in some ordinal manner. For example, consider what needs to be addressed immediately and how to make the action possible; determine what can be changed and how to minimize the impacts; and explore how to ensure processes are apparent and possibly even mandatory. No matter what ranking system is used, conclude the meeting with an accountable action plan.

What do you see as next steps after getting together, gaining reality and gathering the lessons? Share your thoughts below, and Voices on Project Management will publish the best response as a blog post.

Integrating Project Communications into Lessons Learned

| | Comments (0)
Lessons learned sessions typically focus on project deliverables and budget. But I'd recommend adding project communications to the agenda of elements to review.

Take a hard look at the communications plan and how well it worked. This process should include evaluating the stakeholders listed, the way the tool was manipulated throughout the project life cycle, or even the categories listed on the communications plan, such as audience, frequency and deliverables. 

Then discuss other communications documents — status reports, issues lists and risk registers — and how to make them more worthwhile. Consider the frequency with which these documents were published and the need to develop communications tools specific for each of your different audiences.

Finally, look at your communications with team members and executives. How you communicate with team members is different from how you communicate with management, so these should be separate areas of discussion. Yet for both groups, keep in mind how time zones, language barriers, leadership style and working relationships may have affected communications.

When examining your team communications, here are a few questions to ask:

  • Did you regularly communicate with the team? Were there provisions for local team members vs. members located abroad? 
  • Did you establish a systematic process, such as a daily phone call or e-mail? 
  • Did you make face-to-face rounds from time to time to show your interest and have diligent participation with your team?

When looking at your communications with management, keep in mind that this probably required less day-to-day communications than you had with the project team. Management's interest is in the big-picture, milestone items, such as presentations on status, the budget and the go-live date. When looking at your communication with executives, ask yourselves:

  • Did you express the positive and negative project information?
  • What communications methods and tactics did you use?
One last thing to keep in mind: As with any topic in a lessons learned session, be prepared to discuss unforeseen issues. Some project communications mishaps that I have heard about include not bringing in the data owner, issues reported too late or misalignment of user feedback with a requirement.

How do you evaluate your project communications in lessons learned?

The Basics: Skills for a Successful Lessons Learned Session

| | Comments (5)
Project professionals wear many hats. As writers, you prepare the project's charter to initiate the project. As leaders, you manage project teams. And as an accountant of sorts, you control the project budget.

With the many skills you must possess to oversee a project, you should also be cognizant of the basic skills you'll need when conducting a lessons learned session:

1. Time management

The session should be arranged with a specified meeting start and finish time. Team members will have other projects and tasks to work on, so it is imperative to respect the time they give you during the session.

Start on time and keep the meeting moving. Pay attention to the clock to control the lengthiness of the discussions. This way, the meeting ends when it was arranged to end. To keep the meeting on track, you may have to tell team members when to close on a discussion point or ask them to discuss it more in-depth at a later time. If needed, schedule an additional meeting to talk about that point, or add it to the meeting notes and solicit feedback when you circulate the document.

2. Ability to engage

As the facilitator, you must be able to persuade everyone to participate — from team leads to database administrators.

You should also detach yourself from ranking attendees by their titles. After all, the goal of a lessons learned session is to collect details and feedback on a project's activities and decipher what may or may not be relevant to the next project — no matter the team member's position.

3. Shared vocabulary 

Many times, project teams use jargon that only they know. For example, the word "call" could refer to a programming term or simply to describe a customer service method. If you have not been a part of the project all along, make a point to familiarize yourself with some of the terms that may have been used on the project or may be mentioned in the discussion.

What other basic skills do you use for conducting effective lessons learned sessions?

How To Evaluate Lessons Learned

| | Comments (0)
A Guide to the Project Management Body of Knowledge (PMBOK® Guide) is useful both for navigating the fundamentals of project management and for evaluating lessons learned. It can help you determine if you focused on the right things in your project and where you could have improved.  

Consider each knowledge area of the PMBOK® Guide as you review your project. In the planning stage, for example, let's say you used brainstorming to develop your charter. Was the brainstorming effective? If so, what made it effective and if not, why wasn't it? Address these things in your lessons learned session.

Or, think about the risk management tools you used in your project. The PMBOK® Guide highlights such tools as 'The Probability and Impact Matrix' or the 'Data Quality Assessment.' If either was used during your project, in the lessons learned session you could analyze the ratio shown on certain risks or the integrity of the data.     

Here are three other ways you could apply the PMBOK® Guide principles to your meetings:

  • Check the knowledge areas as you plan your projects. After a project is completed, things will come to mind that you should have done differently. For example, let's say you accidentally omitted quality management from your planning. As you complete your lessons learned and check against the PMBOK® Guide knowledge areas, you might realize this omission. In your lessons learned, you can share that you should have selected the Pareto diagram, a histogram or high-low defect charts to identify problem areas in your project.
So even if it was not a knowledge area that you focused on during project planning and control, the PMBOK® Guide is still a good  reference to check your work against.

  • Refer to the PMBOK® Guide as a source of structure for your projects. Every project manager knows that projects can become chaotic. But if you relied on the PMBOK® Guide to control your project, then make that known in your lessons learned session. With the more positive outcomes from the project, you have a strong foundation and reasoning for structuring projects around the processes in the PMBOK® Guide. With the negative outcomes, you can know which areas to pay closer attention to next time.
  • Create lessons learned from using the PMBOK® Guide. When you're preparing lessons learned sessions, use the PMBOK® Guide to help create topics of discussion. Was there a tool or technique used in your project that could have been emphasized more as you managed a particular knowledge area?
For example, as you review estimating in your lessons learned, you could question whether the team should have relied on PERT (program evaluation and review technique) or the Monte Carlo technique.

Have you used the PMBOK® Guide for lessons learned? How?

Lessons Learned with External Teams

| | Comments (4)
Many companies only have internal projects, and therefore conduct lessons learned sessions with the same people. But what if you have an external project and you collaborate with team members outside of your organization?  

Should the project manager of the lead organization invite the outside project team to the closing project's lessons learned session?

Here are three tips project managers can use to incorporate external project teams into their lessons learned:

1. Be discreet about company information, but target improvement. Before working on the project, there was likely some type of agreement with regard to proprietary information. This agreement should still be in effect for the lessons learned session. Before you host the lessons learned meeting, talk openly about the processes with the external team to help ensure your discussions are protected.

2. Stay focused on the project. Even during lessons learned sessions for internal project teams, attendees can veer off topic. Try not to argue about which organization was responsible for the mishaps or which company fell short on delivery. Focus on the issues: How can you better prepare project plans with outside parties? How can you review risk and issue lists together? What different criteria should be included in the scorecard that will bring value to monitoring the project and measuring the vendor relationship?

3. Build camaraderie. The two organizations may want to collaborate on a future project or enhancements to this closing project. Prepare questions that will allow the groups to work as one in the future. For example, how did the quality standards benefit evaluating the finished product? If the project relied heavily on documentation, is there any additional information that could be helpful? What communication methods may need to be revisited for the two companies to reach a decision in a timelier manner?
If the third-party is holding separate post reviews on the same project, chances are valuable lessons from one group or the other are being missed. It is not uncommon for the lead organization to have an exclusive session in addition to a combined session. Having both groups present can be a favorable collaborative effort toward building vendor management best practices or improving the next project, the future vendor relationship or just a similar project situation.

Does your organization include the external team in its lessons learned sessions?

The Role of Executives in a Lessons Learned Session

| | Comments (2)
In a lessons learned or project review session, your attendees will usually provide feedback freely. Hopefully, they know the purpose of these sessions and their roles in it.

But what about when your sponsor or upper management is present? What are their roles?
Rather than shelter upper management from lessons learned, consider their value in these sessions. Don't have upper management viewed as attendees who just want to hear the rehash of problems that the team doesn't want to relive anyway. Nor should you have upper management included to be a part of the blame game.

Ask your sponsor and upper management to be open minded and supportive advocates in receiving feedback toward improvement.
Here are three ways to get upper management to engage:

Talk: You, the project manager, must engage upper management in the discussion. Review the timeline and other milestones that took place on the project. Upper management could talk about how the goals of the project and the team's successes intertwined with the strategic goals of the company.  The team would appreciate this perspective on the significance of their activities.

Listen: While some discussion points may not be pleasant for upper management to hear, their presence assures a level of impartiality to the team. Knowing someone from "up top" is listening reinforces the team's drive to be a part of a high-performing group. Getting to more favorable end results in future projects would become even more desirable for the team.

Share: Have your sponsor share comments about the purpose of the project and its greater use to the organization, the end users and the community. Have them elaborate on processes. Ensure early on that they recognize processes mentioned in the discussion that could be rewritten or are no longer necessary. This sharing will foster bonding with the team.
How do you involve your sponsors and upper management in lessons learned sessions?

Maintain Control in Lessons Learned

| | Comments (2)
In a traditional lessons learned session that is conducted face-to-face, project managers know each person who is present and his or her role on the project.

But technology today affords us the luxury of being able to do many things online -- such as holding a lessons learned session. We can engage with people across the country or someone who may be sitting right next door. Regardless of where someone is located, we must maintain a cordial and professional manner when we interact online.
When you have dispersed project teams -- and even sometimes otherwise -- getting people to stay focused and not be disrespectful to others in a lessons learned session is a challenge.
To overcome this, set the rules for participating in the session. Make sure participants understand them and agree to them. These rules should include:

  • Respect. Allow someone to make his post without experiencing sarcasm, blame or degradation. Emphasize open, honest and polite communications. Project team members will develop an appreciation for each other, the project manager and their organization.
  • Treat people as if they are right next to you. Use a tone of courtesy that can be recognized in any language. Respect the person's time and keep posts brief. Do not veer off on other conversations -- stick to the discussion.
  • Put a face to a name. Many applications allow photo uploads. When someone responds, everyone can see who is participating in the discussion.  
Setting the right tone in these sessions can lead to so many other opportunities. For example, when good feelings are engendered, it helps to build your team and other business relationships. You can learn more about each person, such as associations they may belong to or networking contacts that you can use for future collaborations and project guidance.
When you maintain control of the meeting and employ general courtesy, it keeps the discussion flowing and ensures everyone gets the information needed about lessons to be learned.
How do you maintain control in lessons learned sessions?

Nontraditional Ways to Get Feedback for Lessons Learned

| | Comments (2)
When capturing lessons learned, feedback can come from anywhere. Don't dismiss comments because of how you receive them.
Consider that you may want to receive feedback from the quality assurance manager who's always on the run. Talking on a mobile phone while he or she is driving from site to site may be illegal, though.

Or consider the database administrator who transitioned off your project in phase one, who no longer has security access to the project, and is now busy on her next project.

So how do you get their feedback?

It isn't easy to reach out and receive the lessons your stakeholders may want or need to share toward improving the next project.
These two unconventional communication methods can be used to help in lessons learned:
  • Try a text or Twitter message. Texts and social media aren't only for the younger generation. But to use them, you must to be concise. You may ask your stakeholders to drop a quick message and provide more detail later when they may have more time. 

  • Host a blog site. Start by setting up categories to receive feedback on particular areas of the project, for instance. Using the categories will allow a better way to coordinate the comments, and give the stakeholders a fast way to respond.
In lieu of attending an in-person project review, receiving lessons learned material by other traditional methods could work as well. Contact a stakeholder by e-mail. Dial the person on the telephone. No matter what, reach out for feedback.
How do you identify stakeholders on your projects and get feedback for lessons learned?

Build a Business Case for Lessons Learned

| | Comments (8)
If you are not having project reviews and meetings to address lessons learned, it may be that your project sponsors do not count these as valuable activities.

You know better, but how do you make a convincing argument to have project reviews?  

You must take the discussion with your project sponsor to a different level. It's not "we just need to know what happened." It's "we want to take action and get better results the next time around."

The lessons learned meeting could make you aware of changes that may be needed to turn business from being bleak to being more successful. Give your sponsors succinct reasons to pursue assessing projects to make improvements.

Consider these tips to influence your supporters:

Gather statistics and determine what you need to measure.
If your company is concerned about quality, chart examples of projects where quality was lacking. If ROI for projects has not been good, share those examples.

Share success stories.
Bring up achievements that occurred because of the attention on improvement. Discuss the situations that will make a difference to the bottom line.

Make a plan.
As a project manager, you already know that planning is important. Prepare a well thought-out plan for gathering and presenting the lessons learned. Then use the newly acquired knowledge.  

How have you built a business case for lessons learned and project reviews?

Technology Helps with Project Lessons Learned

| | Comments (6)
Conducting lessons learned and project reviews has been a practice that many organizations have used over the years to help their next projects be successful.
It's a continuous cycle of retrieving and assessing your project information.

As the project manager, you should call a meeting and discuss any issues or tasks that went wrong and what could have been done to improve the project. The improvements should be incorporated into the processes of the next project, which typically have a better outcome. Then that project will have its own challenges that will also need to be addressed. And so it goes.

If you aren't doing some type of project review or lessons learned, you will most likely repeat actions that have caused the project failures, budget overruns, scope creep, inadequate stakeholder involvement, technology mishaps and other problems that plague your projects.
Yet some project managers find excuses not to host these valuable meetings. One such excuse is a geographically dispersed team. There's no need for a dinosaur mentality to achieve a project review. Use today's advanced technology to your advantage when conducting a lessons learned meeting:

  • Conduct a lessons learned session in the same way as you would hold a virtual team meeting. Emphasize the goal of targeting improvements. Use a virtual whiteboard to list pre-determined questions or to show a timeline of how the project progressed. Allow the team members to post their version of the events that could be improved upon in the next project. 

  • Consider posting a social media page to capture comments. This venue would allow you to reach stakeholders in their habitat, possibly presenting more candid comments.
  • Send out a survey. Then collect and analyze the results. Gathering the data this way could lead to more impartial responses and a scientific alignment of the priorities that should be addressed.     
Traditional methods for conducting lessons learned will always prove beneficial as well. Bring in an outside group or consultant to assess projects and provide recommendations. As the lead and manager of an important project delivery, designate time to look back so that history does not repeat itself.

Do you use technology or traditional methods in your lessons learned?

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll