Change Management in the Project Lifecycle: Plan Phase

On to the Plan Phase.  This phase can be slightly frustrating for Change Managers, because so many of the activities we do are dependent on the activities conducted by the other project teams.  It's very difficult to plan when you'll conduct training if you don't know when the system will be built and stable.  Because of this, I typically recommend that Change Managers add their team's activities to the plan after the technical and functional teams.

There's also an ongoing debate as to how much of the Change Management plan should be included in the overall work plan.  I've met a number of Project Managers who don't want to see every single planned communication cluttering up their work plan.  

Here's my recommendation.  It's good to have as much of the Change plan in the overall project plan as possible, so that the integration between the teams is clearly visible.  The functional and technical teams should understand how changes and delays in their activities impact Change Management activities.  If that's not possible, however, the project work plan should at a minimum include Change Management milestones and the activities that are most impacted by other teams, such as training development.

If the Project Manager doesn't want any Change activities in the overall project work plan, you have bigger problems on your hands, and I suggest you set up a meeting immediately to discuss.

But enough of the introduction.  It's time to discuss:

Practical Steps to Develop a Change Management Plan

Training:  Training is perhaps the most critical Change activity to plan well.  You may not know exactly how many training courses you're going to develop or how many people you're going to train, but here are a few guidelines to get you started.  (A quick disclaimer that will apply to the rest of the post: Work plans are living documents.  You will constantly need to go back to update and refine your plan as you get new information. )

• Build some time for training into the Analyze, Design, and Build phases.  Training developers who spend some time in business requirement meetings, system demonstrations, and testing will be better prepared to develop training...and will reduce the amount of time required from Business Analysts.
• The industry standard for the time required to develop training is this: It takes 40 hours of development time to create 1 hour of classroom training.  It takes 200 hours of development time to create 1 hour of fully interactive computer-based training.  Everything else falls somewhere in between.
• The level of expertise of the people developing training impacts the amount of time they require for development.  Take this into consideration.
• During training development, Business Analysts should expect to devote 10% of their time to working with the training team.  This is extremely important and often overlooked.
• For training delivery, assume that for the first time someone delivers a course, they will need 1 hour of preparation time for every 1 hour of training they are delivering.
• During training delivery, the technical team needs to devote a portion of their time to addressing technical issues and performing activities such as training instance refreshes.
• Training doesn't end at Go-live.  There will be people who need to be trained in the 1 - 4 weeks after the system is implemented.  Plan to have one or two team members stay around to deliver this training.

Communications:  Although you might not know exactly what communications you need to send each week throughout the project, assume that you will be busiest starting about a month before training delivery and lasting until about a week after Go-live.  Also consider how many people will be impacted by the project and how geographically diverse they are.  Finally, talk to your leadership about their expectations for communications.  I had one client who wanted marching bands and giveaways.  I had another client who thought it was excessive when I wanted to send out training reminders.

Change Management:  Change Management is more than just training and communications.  As appropriate for your project, build into your plan activities such as Super User Networks, Executive Sponsorship activities, Stakeholder Management tasks, Change Readiness Assessments, and Change Impact Assessments.

Project Management:  Now is the time to have a frank conversation with the Project Manager about where you want to draw the line (or not) between Change Management and Project Management activities.  This is an ongoing debate that I won't address here.  Suffice it to say that you should determine what will work for your project and plan accordingly.  Discuss who will conduct activities such as project and phase kick-offs, lessons learned sessions, and presentation development and delivery for Sponsors.  These activities take a lot of time, and it's important to know who will be responsible for them.

Administrative Tasks:  Finally, if you've planned all of these activities and they will require every second of every day for every Change Management team member, you need to stop and re-evaluate.  First, remember that everyone needs a bathroom break at some point.  Second, keep in mind that unexpected activities will arise and you need the flexibility to absorb those that fall to Change Management.  Third, you need to build in time for administrative tasks.  They may not be high on your list of fun things to do, but you still need to take the time to update your work plan, review and approve work done by other people, and attend meetings.  If you forget to plan in time for these activities, you will quickly find yourself falling behind or working a lot of overtime.  I've heard people say that a good rule of thumb is to expect administrative tasks to consume 10% of your work hours.  Unfortunately, I find it tends to be more.

Contingency:  Most projects build some amount of contingency into their work plans.  It never hurts to build a little into your team's plan, as well.

A final note:  One of my favorite phrases comes from the world of SCUBA...Plan your dive.  Dive your plan.  Finding the right balance between this philosophy and being flexible enough to roll with the punches that are part of any project is the true test of anyone responsible for managing part of a project plan.

Let me know:  How much time do you devote to administrative tasks each week?

Change Management in the Project Lifecycle: Pre-project Phase

In my last post, I provided an overview of the eight basic phases that make up the project lifecycle.  Now it's time to dive in and look at how Change Management fits into each of these phases.  Please note that I won't be able to include every single Change activity that could happen in a phase.  That would turn this into a text book rather than a blog post.  I will cover the major activities, though, and if you include them in your plan you will be off to a great start.

Let's get detailed.

Practical Change Management Activities in the Pre-Project Phase

Unfortunately, I often see Change Management - and Change Managers - left out of the Pre-project phase.  Because many people think of Change Management as just communications and training, they assume that they don't need to worry about it until later in the project.  This is a great way to doom the Change program before it even begins.

If you're going to be the Change Manager, now is the time to speak up and jump into the fray.  You need to ensure that the following items are given serious consideration by your organization's leadership...and included in the overall scope of the project:

• If you're partnering with a consulting firm, at least one consultant should be a Change Manager.
• Just because they agree to have a Change Management consultant doesn't mean they can remove you from the project.  At least one person from the organization needs to be a full-time Change Manager, as well.
• Change Management needs its own budget.  Activities involved in communications, training, Super User Networks, etc. can add up.  While there are lots of ways to do it on the cheap, for the most part, you get what you pay for.  If leadership hesitates, show them this fact from IBM's Making Change Work study: "Our study found that project success rates were 23% higher when the amount invested in change was greater than 11% of the project budget."
• If it's a technology project, training should be included in the technology budget.  Training development uses a lot of server space, and you need to consider if your company has a Learning Management System (LMS) available to host any computer-based training courses.
• Make sure that the number of Change Management team members is commensurate with the amount of Change Management work.  Very few change programs can be fully executed by one person.

If you're brought onto a project in a later phase and discover that these items weren't taken into consideration, never fear.  There are ways to address this, which I'll cover in a future post.

Let me know: In your experience, is Change Management adequately addressed in the Pre-project phase?

Change Management in the Project Lifecycle: Project Phase Overview

Forgive me, readers, for my extended absence.  I'm going to start the new year by getting extremely practical.  The next series of posts will focus on the nitty-gritty of preforming fundamental Change Management activities.  If you've been assigned to run a Change Management program but don't know where to start, these next few posts are for you.

Let's start by talking about how Change Management fits in with the overall project lifecycle (I'm assuming here that you are working on a project of some kind - technical, business process, organizational re-design etc.  I'll note that Change Management doesn't always happen in the context of a project, but for the record, I consider change for the sake of change to be a losing battle.)

Most projects have eight basic phases: Pre-project, Plan, Analyze, Design, Build, Test, Implement, and Post-project.  Different companies will use different names for the phases, and you often won't see Pre-project, Plan, or Post-project on the official project work plan, but in general, these are pretty standard.

For anyone who hasn't worked on a project before, I'll begin by providing:

A Practical Understanding of Project Phases

Pre-project: The Pre-project phase typically doesn't appear on the project work plan because, as its name suggests, it occurs before the project begins.  The team is typically very small at this phase.  They are focused on building the business case for the project, which explains the business reasons for doing the project (why do we need to do the project, what are the benefits of doing it, what are the risks of not doing it, etc.), and is often used to get approval from senior leadership to move forward with the project.  For technical projects, this phase also consists of selecting a technology and vendor.  Many companies also choose to partner with a consulting firm, which is chosen during this phase.  Usually, by the end of this phase you will have permission to do the project, vendors and partners selected, a budget, and a general time frame for the project.

Plan: As you may have guessed, during the Plan phase you create a project plan (also commonly referred to as a work plan).  This plan lays out what activities need to happen, when they need to occur, how long each activity will take, and how many people are needed to compete the activities.  Developing this plan allows you to determine how many people you will need on the team at any given time, as well as the skill sets you will need over the course of the project.  This is also the time when the general project time frame you determined during the Pre-project phase becomes more precise.  For technology projects, you will also be able to use the plan to figure out when you will need to procure physical assets, such as system licenses and extra servers.

Analyze: During the Analyze phase you will dive into requirements gathering.  This is your chance to determine exactly what your organization needs from the project.  This phase helps to ensure that the finished product meets your technology, process, and cultural needs.  Once you've gathered the requirements, this is also the time when you will do a gap analysis.  How well does your project as currently planned meet your requirements?  Any gaps will need to be addressed as part of the project, which means you will need to go back and re-assess your project plan, including budget, timing, and people resources.

Design: Now that you know your requirements, it's time to design your project to meet those needs.  For technology projects, this means designing the system.  For an organizational redesign, this means designing the new organization.  A business process project will design new processes.  (A quick note - I talk about different types of projects, but it's very common for one project to contain aspects of each of these project types.  In fact, it's best if your project has at least two of these types.)  The Design phase is often called the Blueprint phase because by the end you will have the blueprint of the project you need to create.

Build:  With your design in place, you're ready to begin the Build phase.  This is the phase where you make your design a reality.

Test:  Once you've built your project, whether it's a computer system, new business processes, or an improved organizational design, it's important to test it before rolling it out to the entire organization.  There are a number of steps involved in the Test phase, but to make it simple, by the end of this phase you should feel confident that the product you built works the way you designed it and meets the requirements you gathered.

Implement:  This is the exciting phase.  During the Implement phase you roll your project out to the organization, letting everyone see/use/participate in/experience the finished product.  By the end of this phase, most of the consultants will leave and many of the people from the organization will go back to their day-to-day jobs.  And, if you did your job well, you'll be receiving positive feedback about the product you created.

Post-project:  This phase often isn't on the project plan mostly because it often gets forgotten.  Just because the project has been implemented doesn't mean the work is done.  There are short-term activities, such as officially closing down the project, closing the budget, and immediate end-user support.  You may also have long-term activities, such as follow-up analysis of how successfully the new product is being used by the organization and continuous improvement cycles.

Now that you understand the project lifecycle, the next question is, "How does Change Management fit into each of these phases?"  In upcoming posts I'll address this question, explaining the Change Management activities typically completed in each project phase.

Let me know: 

The Negative Impact of Ghosting Hours

Forgive me, Readers, I'm about to get on my soapbox.  Over the years, dozens of new consultants have listened to my speech about the dangers of ghosting hours.  Today, I'll share the speech one more time.

First, let me describe the phrase "ghosting hours."  Unlike the legal profession, where new associates are encouraged to work as many hours as possible and bill them all to a client, in the consulting profession, consultants are often encouraged to work as many hours as necessary, then only record 40 hours at the end of the week.  The hours that were worked but not recorded are "ghosted."

Even on projects where ghosting is never explicitly discussed (and most managers know better than to directly tell their team to ghost), it is implied.  Too many weeks with too many hours recorded generates frowning leaders and hard discussions.  The expectation, however, is that the work still get done...usually without any additional resources.

The benefits of ghosting are obvious.  Keeping (recorded) hours under control helps projects make their margins.  It makes the client happy.  It makes the consulting organization believe that the project is running smoothly - on time and on budget.

These are only short-term benefits, though.  In the long-term, ghosting has a negative impact on the organization, the team, and the individual.  And I firmly believe that the long-term negative impacts far outweigh any short-term benefits.

Five Dangers of Ghosting Hours

• Estimating - Many consulting firms have an estimating model they use to determine how long a project should take, how many resources are required to do the work, and how much they should charge the client.  These estimating models are typically based on extensive review of past projects.  Even firms that don't have a set estimating model will look back on their projects and use them as a guideline for bidding on new projects.  Despite these estimating models, projects consistently run over budget and miss deadline after deadline.  Teams are constantly asking for more resources.  It has gotten to the point where many consultants assume from the start that every project they're on will be extended.  There are a hundred reasons why this might happen, but one of the root causes is ghosting.  When team members hide the true number of hours they are working, the historical record of the effort required to complete a project is wrong.  This leads to inaccurate estimating models, which leads to low-ball bids and project timelines that can never be achieved.  It might not seem to matter if a low-level testing resource shaves 10 hours a week off of his time report.  But if every tester does the same, you are quickly looking at enough hidden hours to support an extra full-time resource.  Multiply this across all of the teams on a project, and it's easy to see how a "little ghosting" can lead to a grossly under-estimated project and a large time and money over-run.
• Finances - The short-term financial benefits of ghosting are obvious.  Recorded overtime eats into a project's hours and budget.  The Partner can either choose to eat these hours, which kills his margin, or he can pass the hours along to the client, which leads to a very unhappy client.  When you consider the cost of missed deadlines, project extensions, and budget over-runs discussed above, however, one or two projects that miss their margins in the short-term are a small price to pay for better estimating models and more accurate bids that lead to consistently more successful projects across the organization.  What would your consulting firm save if it could reduce the number of projects that required an extension?  What would you gain in repeat business from clients who were happy to finally work with a consulting firm that met all of its deadlines? 
• Quality of Work - I'll keep this one brief.  No one does their best work after 5 straight months of working 60 hours a week.  On many occasions, consultants will ghost hours without letting their managers know.  They don't want anyone to think they can't handle the job.  Or they've received the cultural signals that overtime is frowned upon, so they hide it.  Whatever the reason is, let me pass on this advice I once received from a very good manager, "No one can help you if you don't let them know you need help."  Clients pay a lot of money for consultants.  They expect top notch work.  Ghosting degrades the quality of work.  This upsets clients and makes them less likely to pay for your company's work in the future.
• Trust - Many companies have policies against ghosting.  When the company policy states that ghosting is not allowed, but a project is asking team members to ghost, the consultants are put in a tricky situation.  Do they ghost, and go against company policy?  Or do they record all of their hours and risk the wrath of their immediate leadership?  This situation degrades the trust between consultants and their leadership, and reduces the team's ability to work together as a cohesive unit.  When a team can't work together, it takes longer to produce lower quality work.  I direct you again to the cost of missed deadlines and poor output.
• Burn Out - Consultants burn out at an alarming rate.  When I tell people I stayed at one firm for five years, they're usually surprised.  That's a long time to stay at a consulting firm.  Studies have shown over and over, though, that there's a huge cost associated with losing an employee.  Not only are you losing all of the time and money you have invested in that person - think training and mentoring - but now you have to spend time and money to find a replacement and get that person ramped up to a comparable level.  Ghosting directly contributes to burn out, which directly hurts your organization.

The short-term benefits of ghosting may help an individual project, but the long-term negative impacts affect the entire consulting organization.  It becomes a cycle that amplifies the damage over time and is increasingly hard to break.  Considering the cost of ghosting, though, the question isn't whether your company can endure the immediate pains of breaking the cycle...it's whether it can afford not to.

Change Management for Non-Profits: Motivating Volunteers

Two years ago, I helped develop and deliver Project Management and Change Management training for non-profit organizations.  It was the most fulfilling work activity in which I have ever participated.  Not only were the participants truly grateful for the training, but I knew that they would put it to good use helping their organizations better achieve their goals of reaching out to those in need.

As I talked to different organizations, I noticed some key themes.  One major question was, "How do we motivate our volunteers to stay actively engaged with our organization?"  Non-profit organizations don't have at their disposal many of the traditional levers that companies use with their employees.  Volunteers don't receive a salary, which means there's no hope of a bonus or raise for going above and beyond the call of duty.  There are no performance reviews and no fear of being fired. 

Add to that the fact that many volunteers are giving their time on top of commitments to family, friends, and a full-time job, and you can see why non-profits experience high volunteer turn-over, absenteeism, and loss of motivation.

What can you do to motivate volunteers when many of the common corporate methods just aren't an option?

Three Practical Tips for Motivating Volunteers

1. Renew their sense of purpose: With the possible exception of high school students forced to volunteer, people typically give their time because they are passionate about the cause.  Whether it's finding a cure for breast cancer, helping the homeless get back on their feet, or finding shelter for abused animals, volunteers come to their role with a sense of purpose and a drive to help the non-profit achieve its goals.  When volunteers lose this purpose and drive, it's your job to help them find it again.  Remind them of the people who are being helped.  Show them solid examples of how your organization has helped your target group.  Share with them your plans for delivering more benefits in the future.  Basically, remind them why they care, and pump them up to continue contributing to all of the good your organization is doing. 
2. Show them their value: Volunteer work isn't always particularly glamorous.  After stuffing and licking hundreds of envelopes, answering phones for hours, or filing mountains of papers, it can be easy for volunteers to lose sight of how the tasks they are doing contribute to the greater cause.  You need to help them connect the dots.  Did the hundreds of envelopes they stuffed lead to thousands of dollars in donations?  Tell them!  Show them how even the most menial tasks help the organization achieve its goals.  If you receive positive feedback from people who have benefited from your services, share that with your volunteers, and explain how that person was directly affected by the work they did.  Everyone wants to feel like their small piece of the puzzle is important to the big picture.  It's your responsibility to help them see where they fit and why their work is important.
3. Focus on "total compensation": Many corporations these days don't just talk about an employee's salary.  Instead, they talk about "total compensation."  This can include vacation time, training opportunities, and other perks the employee receives that can't necessarily be quantified as part of their pay check.  Since volunteers aren't getting paid, it's especially important for non-profits to think about the "total compensation" they can provide to their team.  If you have the money, small items like a branded t-shirt or hat can be a fun surprise for a volunteer, and everyone always loves a free lunch.  Even if you don't have any budget for your volunteers, though, that doesn't mean you can't provide compensation.  Remember to thank your volunteers for their time and hard work.  If you can, encourage the people who benefit from your organization to provide thanks.  There's nothing better than a thank you note from a group of kids whose school was painted by volunteers!  Recognize your volunteers publicly at events they've helped to stage.  And remember, for many volunteers, the best compensation is the great feeling they get from helping others. 

Readers - If you work at a non-profit organization, how do you motivate your volunteers?

Volunteers - What could non-profit organizations do to help you stay motivated?

Lessons Ignored, Part 2: Applying the AAR to Corporate Projects

In my last post, I provided an overview of the 2005 Harvard Business Review article, "Learning in the Thick of It." (Darling, et al)  This article took an in-depth look at the Army's After-Action Review (AAR) cycle, the military version of the popular lessons learned sessions that so many corporate projects conduct as one of their wrap-up activities.  Unlike most corporate lessons learned, however, AARs actually produce on-going learning and tangible results.

As many of you finished reading about the AAR, I imagine your initial reaction was, "That sounds great, and I wish we could implement it, but my team just doesn't have the time or money to invest in such an involved process."  I can understand that reaction.  When timelines and budgets are tight, it's hard to come up for air longer than the time it takes to run to the nearest vending machine for your dinner.  The reality is, though, that when it comes to learning from our successes and failures, you pay now, or you pay later.  And I have always found that when you pay later, the price is much higher.

That being said, here I discuss:

5 Practical Tips for Implementing the After-Action Review

1. Build it into the plan: Six Sigma experts will tell you that the things that get measured, get done.  I'll modify that a bit to say that on projects, the things that get planned, get done.  Build the entire AAR cycle into your project work plan from the start.  Make the initial set of activities (e.g., the discussion of the objectives, the brief backs, etc.) part of each phase's kick-off activities.  Make the discussion of lessons learned a mandatory step in the sign-off criteria for each phase.  Set aside time in the plan for teams to discuss how they can incorporate learning and implement new strategies in each major project activity.  If you build the process into the plan from the beginning, you won't find yourself trying to find a place to squeeze it in later.
2. Remember the house rules: The Army has 5 house rules for AAR sessions - Participate, No thin skins, Leave your stripes at the door, Take notes, Focus on our issues. (4)  I would argue that the willingness of people to participate hinges on the willingness of leadership to "leave their stripes at the door" (i.e., forget your title - in these sessions, you're not the Project Manager or VP, you're a member of the team) and of the team as a whole to have a thick skin.  If leaders pull rank and colleagues leave the meeting in a huff, the team will either stop participating or the whole process will become a show where everyone compliments everyone else.  I would add one more house rule: forget your pride.  It's hard to take negative feedback.  The point of the AAR, however, isn't to focus on what you did wrong.  The point is to figure out how to move forward and be even more successful with each new phase. 
3. Focus on "We":  Most people have sat through a lessons learned session that was more about placing (or deflecting) blame than it was about learning.  Remove "you" and "them" from your vocabulary.  This isn't about figuring out which team did what activity wrong.  The point isn't to find a scapegoat for the timeline extension or budget overrun.  AARs are about "us" and "we".  What have we learned from the activity we just completed, and how can we incorporate this learning into the next activity we have to tackle?  We are a team, and we are jointly responsible for the success or failure of this project.
4. Make it visible: Once you've decided on the few major lessons you can learn, and figured out a way to incorporate them into the project, make sure everyone is aware of them.  Now is not the time to hoard information among a small group.  Let everyone on the team, from the top Sponsor to the most junior assistant, know what steps the group will be taking to improve the next cycle of activity.  If they're steps that are difficult or that people are likely to forget, post them someplace visible.  Learning takes time and repetition.  Sending out one e-mail at the beginning of a project phase is unlikely to do the trick.  If you're implementing new house rules for running efficient meetings, for the first few weeks make the first agenda item a reminder of the rules.  If you're asking people to follow new guidelines for system development, post the guidelines in the major work areas so people can refer to them without having to dig through their notes.  The easier it is for people to remember the learning, the more likely they are to incorporate it into their daily activities.
5. Highlight the results: Did the AAR generate lessons learned that led to new strategies that resulted in process improvements and project success?  Let everyone know!  Showing a direct connection between the learning process and improved results encourages everyone to continue the AAR process.  Did some of the new strategies not pan out the way you expected?  Don't hide these results.  AARs are a cyclical process for a reason, and a little trial-and-error is not considered failure.  Instead, when you don't achieve the expected results, look at this as another learning opportunity.  Discuss why the strategy didn't work and figure out how to tweak it so that next time it is more successful.  If you hide mistakes and treat them as a cause for embarrassment or fear, your team will do the same.  Instead of creating an open, learning environment where people look for ways to constantly improve, you'll create a closed and secretive project environment where people stick with the status quo, whether it works or not, to avoid making mistakes.  That's not how the Army's Opposing Force wins, and it's not how project teams achieve success.

Has your project team successfully built lessons learned into the project?  What strategies led to an open environment where people were encouraged to learn from both their successes and failures?

References

Darling, M., Parry, C., & Moore, J. (2005, July-August). Learning in the Thick of It. Harvard Business Review, 1-8.

Lessons Ignored: What Corporate Projects can Learn from the Military

Anyone who has spent time around corporate projects has sat through a project wrap-up that included a lessons learned session.  The first time you're excited.  "I can offer insight and feedback that will help the next team avoid our mistakes!"  The second time you still hold out some hope.  "Maybe this group will use our input and build on our lessons learned."  A few projects later, you're resigned.  "Why bother?  They're just going to write my advice on a piece of paper, stick it in a folder, then never look at it again."

In 2005, Harvard Business Review published "Learning in the Thick of It" (Darling, et al).  This article looked at After-Action Reviews, the Army's version of lessons learned.  The found that instead of the typical post-mortem report generation that most companies slog through, the U.S. Army's Opposing Force had developed a dynamic, cyclical process that generated genuine learning and improved results.

If you want to read the article yourself (and I highly recommend that you do), the citation is located at the bottom of this post.  For those who don't, I offer a brief summary of highlights from the article.

The Process

1. Despite their name, After-Action Reviews (AAR) do not begin after a task is completed.  Instead, they begin during the planning phase.  Before any action is taken, the senior leader develops operational orders.  These orders have four parts: the task, the purpose, the commander's intent, and the end state.
2. The commander then shares these orders with his subordinates.
3. Each subordinate is responsible for providing a brief back - "a verbal description of the unit's understanding of the mission and its role" (3).
4. Soon after, the team holds a dress rehearsal.
5. Finally, the team begins the mission.  After-Action Reviews are conducted throughout the mission, not just at the end.

The Meeting

The After-Action meetings consist of three main parts that address four questions.  The first step is a reiteration of the AAR rules (4):

1. Participate.
2. No thin skins.
3. Leave your stripes at the door.
4. Take notes.
5. Focus on our issues, not the issues of those above us.

The team then conducts a comparison of the actual results versus the intended results.  To help focus this conversation, they answer four questions (4):

1. What were our intended results?
2. What were our actual results?
3. What caused our results?
4. And what will we sustain or improve?

Once the team has addressed these questions, the senior commander provides his assessment of the lessons learned and the lessons that will be relevant in the immediate future.  When the meeting ends, participants immediately hold AARs with their own teams, to continue the process through all levels of the unit. (7)

The Deliverable

What do these meetings produce?  Unlike most corporate lessons learned sessions, the Army's AARs aren't focused on creating a report or a presentation.  They are focused on generating lessons, theories, and plans that can be applied immediately to the on-going mission.  They avoid blame and instead focus on identifying ways to learn and improve.  Rather than producing a post-mortem, they produce results. 

AARs "focus on improving a unit's own learning and, as a result, its own performance." (4)  In fact, "the group does not consider a lesson to be truly learned until it is successfully applied and validated." (2)

If this sounds like a far cry from the lessons learned sessions you've sat through, you're not alone.  How does your organization conduct lessons learned?  Do they actually result in learning? 

Next up: Applying the principles of the AAR to the corporate project environment.

References

Darling, M., Parry, C., & Moore, J. (2005, July-August). Learning in the Thick of It. Harvard Business Review, 1-8.