Published in PM World Today - May eons [voL x. Issue v} PM WORLD TODAY CASE STUDY - MAY 20GB Editor's note: This paper is based on the experiences of the authors at later Corporation in the USA. White it is not a case study in the strict academic sense, we feel that this paper comfortably tits in the case studies category of PM Worth Today hotter than in other sections. The People Side of Program and Project Retrospectives {Part 3 of a Series] By: Debra Laveti and Russ Martinetii Due to the growing complexity of our prodrrct and service development processes at Intel. as well as the increase in global dispersion of our development teams. we've implemented a more effective approach for capturing and implementing our program and project leamings. This approach is known as the retrospectives methodology. A retrospective is a ritual where a team comes together several times during the lifecycle of the program to discuss what is working well and uncover opportunities for improvement. Retrospectives are a powerful way to help a team apply the wisdom learned with the intent of longterm behavior change {see part one of this series for the foundational elements of retrospectives). As with any organization or brrsiness process change endeavor. one of the most difficult challenges to overcome is getting people en mass to change the way they work and behave. Bringing the retrospectives methodology into Intel has been no different. A key learning we've discovered is that the services of a trained facilitator is beneficial to improving the likelihood of sustainable change in moving to the retrospectives methodology. In this paper. we explore the people side of bringing retrospectives into an organization from a facilitator's perspective. and how one deals with human aspects of introducing changes in the way people work and behave. Changing human behavior One of the primary reasons that organizational change is many time so difficult is that it requires sustainable changes in how people do their work and how they behave while performing that work. Introducing the retrospectives methodology eectiveb: within an organization requires the management of many facets of change: Adoption of a new methodology. Many program and project teams have never experienced continuous process improvement efforts through multiple touch points across the lifecycle. They wait until the end to discuss what happened. which is too late to affect the current program. The retrospective methodology requires a series of events where team members meet at strategic points during the development lifecycle to discuss what is working and what needs to be improved. Plvl Itrl'orlizl Today rs a free monthly eJoumal. Free subscriptions available at; httpzttwwwpmworldrodavnet Fans 1 Management of a new output. After a post project review, some team's output is a bulleted list of items. never to be reviewed or discussed again. The deliverable from a retrospective is an action plan with owners and due dates for the next steps. Updating existing work systems. To ensure retrospectives and the key learnings that come from them become institutionalized, work systems need to be developed or existing work systems must be modied to incorporate organizational learning as a tenant of the workow. At lntel we have included multiple program retrospectives within the Product Life Cycle, which is the common development lifecycle framework that all teams utilize to manage their programs and projects Replacing old behaviors. This is the most challenging aspect of change. lf you want to get the most out of retrospectives. it will require change in business practices of people within the company. This means that the human side of change has to be managed in order for it to become institutionalized. Why institutional change has to be managed In order for retrospectives to become a widely accepted and utilized method for capturing program and project key learnings within an organization. it has to be accepted by the masses. [t is not uncommon For new ideas and ways of doing things to be tried. and if successful, accepted by a segment of any organization known as the innovators and early adoptam. However, gaining widespread support for an idea can be a much tougher problem to solve. Figure 1 borrows from the work of Geoffrey Moore and his book titled "Crossing the Chasm " to describe the challenges we've encountered to gain institutional acceptance ofretrospectives within Intel]. Source: Crossing the Chasm {author modied] Figure I: Modied Version of the Adoption Life Cycle As shown in Moore's model, a chasm many times exists between those people and teams willing to experiment with retrospectives [innovators and early adopters}, and the remainder of the organization that may not be willing to implement it as a standard method of improving their organizational learning capability [early majority, late majority and laggers}. [n the grevious paper in this series, we discussed the importance of having an inuential sponsor for your retrospectives initiative. This is a critical aspect for crossing the adoption chasm. Also fundamental to the process is having an understanding that the value proposition for method changes such as retrospectives is different on each side of the chasm. To the left of the chasm, the value proposition needs to be sufcient to convince the innovators and early adopters to experiment with the method. However, if you want to achieve broad adoption by the remainder of your organization, the value proposition on the right side of the chasm must be sufficient to convince the mass majority to change the way they collect and disseminate program learnings a much more difcult taslt. Debra recently encountered this phenomenon when she and her early adopter relrospectives champion from a business unit within Intel presented the results of a retrospective that had been perform about half way through the execution phase of a program to the business unit senior manager. The intent of the presentation was to demonstrate the improvement action plan that resulted from the retrospective, and to gain senior mmtagement support for broad adoption of the methodology across the business unit. It became clear almost immediately that the senior manager was satised with the current method of performing a single postprogram review at the end of the execution phase of each program. The retrospective output was good, but it didn't satisfy the value proposition for broad deployment. However. the value of the methodology became clear during the meeting when Debra and her business unit champion successfully demonstrated that the midexecution phase retrospective output could be immediately applied to a followon program that had just entered the planning phase. The business unit now had the means to immediately apply key program learnings to improve two programs in progress: execution improvements on the current program, and plam'ting improvements on the followon program. If the senior manager continued to stay with the old methodology of a single postprogram review, the plaJming phase leamings would continue to come in too late to affect the next program. At best, they could be applied to the third program on the roadmap too late for effective change. As a result, the senior manager now requires all programs within his business unit to utilize the relrospectives methodology as part of the standard program management practices. Keys fa managing the change lD'nce the value proposition for broad deployment is established and influential sponsors are behind you, the real work begins to ensure that retrospectives achieve full adoption. The five primary aspects for managing the transitional change management activities that we've used within lntel are explored below. PM Worm Today is a free mmly eJeumaI. Free sunscnptnens available at; httpwwmpmwmtdmdaynat Page 3 Determine your starting point. The retrospectives methodology is about capturing program learnings and modifying the way people perform their work moving forward The rst question that needs to be asked is: \"Is my organization a learning organization? " [f the answer is no, the rst step may be to build the case for organizational learning as a means for continuous improvement, and retrospectives as the method for capturing and applying the improvements. [f the answer to the question is yes, the first step may be to understand and document how the retrospectives methodology can improve your current method. Tailor the methodology. Every organization is unique; therefore the retrospective methodology may need to be tailored to meet the full needs of the team. Start by asking simple questions to understand the coiTent program review process, and then negotiate how much change the team can absorb. For example. instead of starting with performing three retrospectives at strategic points across the program lifecycle. negotiate for one additional retrospective [in addition to the end]. Ensure someone is accountable for results. Action plans created in a retrospective have committed owners and established due dates, but it becomes easy for the owner to procrastinate on the follow through of an action plan when it is in addition to their normal program-related work. A few things can be done to prevent apathy from taking over and increase the accountability of action owners. 3" Select one opportunity to improve. During the brainstorming of issues, it is easy to get over zealous and want to \"solve world peace". Resist the temptation! 5; Document the action plan fully and consistently. It is human nature to want to jump to solution space and fail to clearly state the problem in the form of a well written problem statement. Brainstorm various obstacles to making the improvement, identify who needs to support the change, and the next steps in short, two week intervals. Ensure the completed action plan is accessible to the team. Many times the output from a retrospective is stored on someone's computer hard drive. If possible, create a centralized repository for all leamings so those who need to get to the data can do so quickly and easily. V Make changes to existing work systems- Change is easier for humans to embrace when it is embedded into wellestablished work systems. Companies who use a development \"lifecycle\" or a \"software development life cycle" where a program team passes through various stages such as exploration, planning, development. and product launch can link leamings to the entry and exit criteria of the phases to help reinforce change. Change reward systems: Establish a reward system to recognize and reward teams that utilize the retrospectives methodology and make the necessary behavioral changes. We have found an effective reward is something desirable, timely, and provides an opportunity for reinforcement of the change. Small rewards, delivered for meeting smaller goals. are many times more effective than bigger rewards. These can be as simple as a direct thankyou, gift certicate from a nice PM World Today is a free mmly eJoumal. Free Subscriptions available at; httpzttwwwpmwortdmdaynot Page 4 restaurant, or movie passes. Whatever the reward, invest time and energy in devising a reward system that reinforces the behavior changes you desire. Conclusion As with any change in the way people perform their work, one of the most difficult challenges to overcome is getting people en mass to modify the way they behave in order for the change to become institutionalized. Bringing the retrospectives methodology into your organization will be no different. The first challenge is to define and communicate the value proposition for broad adoption of the methodology in order to cross the chasm between the early adopters and the mass majority of the organization. Once this is accomplished, the five key steps in making the transition to retrospectives that we've implemented at Intel include determining the starting point based upon an organization's current learning capability, tailoring the methodology as needed, ensuring someone is accountable for implementing retrospective action plans, making necessary changes to existing work systems, and changing the reward systems to reinforce positive behavior. In the next paper in this series we will explore the utilization of the retrospective methodology in a distributed team environment. As in many company's today, our program and project teams at Intel have become highly distributed across the U.S. and the world due to the forces driving globalization. We will discuss the nuances of conducting a retrospective for a highly distributed program or project team. For more information or assistance with retrospectives for your organization, you can contact us www.programmanagement-academy.com. References 1. Moore, Geoffrey A. Crossing the Chasm. New York, NY: HarperCollins Publishing, 1991. Copyright 2008 by Debra Lavell and Russ Martinelli