LIfE--learning and improving from experience

Prem G. Ranganath, MBA, PMP
IT Audit Consultant, Northwestern Mutual

Abstract

In most organizations, IT project managers are recognized and rewarded for ensuring that a positive message regarding project performance is always communicated. “This drives project managers to implement the zero-error principle to the n-th degree, which in turn stifles team creativity, and in many ways curbs real improvement” (Kriegesmann, Kley and Schwering, 2005, Page 57). Defects are either hidden or just fixed without a real understanding of root causes since the goal is to somehow make the project and project manager look good in the eyes of the beholder. While the practice of capturing and reviewing lessons learned is part of project work plans, the focus is more on the administrative aspects of project closure than on adopting a methodical approach to learning and improving from experiences.

The goal of this paper to present a strong case for IT organizations to accept failures as much as they celebrate successes and learn from the experience to prevent errors and pursue innovation through a disciplined approach to learning and improving.

Introduction

“Many organizations hope that personnel will think more creatively and take risks, but they are rewarded for well-proven, trusted methods and fault-free work”, (Kriegesmann, Kley and Schwering, 2005, Page 57). The fear of failure slows the process of innovation and also sends an indirect message to teams that status quo is the assured path to growth and success in the organization. Managers and team leads celebrate successes and review the critical success factors, but a similar exercise is rarely encouraged for accepting failures and learning from those failures. This is not to suggest that we need to celebrate failure, but unless failure is accepted and a causal analysis is performed, teams are denied the opportunity to learn from those failures with the goal of preventing similar events in future projects. In some organizations, teams celebrate for discovering a significant number of defects on projects. While the successful discovery of defects is commendable, the increasing number of defects confirms the prevalence of a variety of problems in the solution development process which by no means is a reason to celebrate. It is important for teams to realize that the discovery of defects is only the first step and the opportunity to learn from these defects and prevent similar occurrences in the future is the more critical and valuable exercise that teams should be engaged in (Abdel-Hamid & Madnick, 1990).

However, it is interesting to see teams being told to specifically prevent certain types of showstopper defects when senior management gets a pulse of these defects or when the clients escalate the impact of these issues to senior management.

The inspiration for LIfE was driven by the fact that in our day-to-day life, we do make mistakes (some more costly than others) and some of those mistakes may fall into the realm of failures. We have heard or experienced failures relating to getting a bad deal on a car or basement renovation project going awry. However, while the initial reaction to these personal failures is negative we eventually accept these events and view them as experiences from which we can learn and make the necessary changes to drive us towards better decisions in the future. For example, if we are building a house we establish expectations for each of the major tasks that need to get done – roof, electrical, heating. plumbing etc. We do not wait till all the construction is done to assess reality against those expectations, but identify milestones at which these need to be reviewed and identify action items. This proactive approach to problem solving helps us mitigate the risks of failure and in most cases we share these valuable lessons with our friends and peers at work with the hope they can use the lessons that we learned.

Interestingly, while this appears to be a rational approach for problem resolution in personal life, the same practices are seldom implemented on projects at work and particularly on IT (information technology) projects.

The Case for LIfE

The data and findings from popular studies such as those commissioned by the Standish Group and the National Institute of Standards and Technology (NIST, 2002) have confirmed the alarming failure rate of IT projects and the economic impact of software defects. These scenarios present a strong case for building resilient processes in IT and develop practices that focus on preventing defects and failures through continuous learning and improvement. Also, despite the availability of methodologies and processes for developing and delivering IT solutions, there has very limited published information regarding IT teams’ ability to spur innovation within a business domain or at an enterprise level. This scenario really makes one wonder if the methodologies and processes are being applied more to implement controls and effectively document various project artifacts and not necessarily to innovate prevailing practices and deliver value to the clients.

The key driver for encouraging learning through failures is that there have been several cases from a variety of industries where failures have spun off some very impressive innovations.

“Its only a failure if we fail to get the learning”

- Scott Cook, Chairman, Intuit Inc.

(McGregor, Symonds, Foust, Brady,. & Herbst, M., 2006 ¶15)

However, a question might arise as to whether managers should encourage project teams to consciously make mistakes in the name of experimentation. While experimentation is relevant on some projects and in specific industries, the scope of LIfE is focused more on experiential learning from unplanned failures and mistakes. The expected outcome from project teams’ willingness to engage in prudent risk-taking and to learn from experiences is three fold,

  • To develop a ‘prevention’ mindset and thereby drive towards building resilience into the processes they execute to develop solutions.
  • To learn from failures and apply the learning to innovate products and services
  • To use the lessons from failures as a tool to improve and optimize processes and the resulting outcomes.

Too focused on training and not learning

A common cause for the multiple maladies facing IT projects is the aggressive schedule that teams are forced to chase. While a study of the cascading effects of unrealistic expectations set by management to the clients is outside the scope of this paper, it is a key factor that drives the schedules and estimates developed by the project teams. A key outcome from this aggressive scheduling is the absolute lack of any dedicated time for real learning on the project. Team members may be encouraged to attend training classes as part of their training plan or performance plan, but there is little or no motivation to encourage learning. Unlike training, learning happens only when the information gathered during training is applied to real situations and the results evaluated against a criteria. For example, attending multiple training sessions during a calendar year can look very impressive on one’s resume, but their inability to apply the information from the training to solve real-world situations cannot lead to effective learning.

It is important for managers to develop the mindset in teams to perceive and approach training as an opportunity to reconstruct and validate experiences and not merely as an event to assimilate information (Kolb & Kolb, 2005). In addition to institutionalizing this mindset, it is important for performance management systems to support this mindset by developing goals that promote intrinsic learning and applying the learning to create value. As in the case of most large-scale change initiatives, the realization of benefits from this change can involve ongoing reinforcement and skeptical feedback and recognizing this reality will be helpful. From the teams’ standpoint, there could be relapse of old habits and potential failures which need not be flagged as a disaster instantly, but instead reposition these failure points as opportunities to learn from experiences.

Lessons Learned – administrative process vs. learning process

While there is a strong need to differentiate between training and learning, it is also important for managers to encourage opportunistic learning by identifying learning opportunities within a project lifecycle that do not require attending a formal classroom session. ‘Conversational Learning’ is a widely accepted social experience that is practiced in organizational environments that encourage ideation through interactions and exchange of ideas and experiences. A first step in leveraging practices of conversational learning for capturing and sharing lessons learned from projects is to trade political correctness for real and purposeful communication. For lessons learned to yield potential innovations, conversational learning can be used to assess the ‘know-why’, ‘know-how’ and ‘know-when’ from a project’s perspective.

“How do you learn if you don’t examine the past?”

- Chris Timble, Tuck School of Business at Dartmouth College

(McGregor, et al., 2006 ¶17)

There is considerable skepticism in management circles at organizations on the ability to leverage IT for innovation since many IT organizations perceive the practice of introducing a new model or framework as a means to innovate. IT teams position the introduction of frameworks and models such as DMAIC (Define-Measure-Analyze-Improve-Control), CMMI (Capability Maturity Model Integration) and ITIL (IT Infrastructure Library) as a starter for innovating processes. However, the message that the enterprise gets from this approach is that IT is expensive and tends to create more layers of work and thereby slowing down the innovation process. The solution for resolving this gridlock is for IT is to be mindful of the real needs of the enterprise and the prevailing culture and recommend ideas for innovation based on solid reasoning developed from organizational facts (Swanson & Ramiller, 2004).

Simply stated, IT has to learn from experiences and present proposals for innovation by ‘right-sizing’ ideas to real needs and thereby simplify the process of organizational buy-in. From a process perspective IT teams have to end their strong addiction to processes. The solution for process related problems is not to slap it with yet another process!

The cure for process addiction is in the ability of teams to have a healthy dialog on problems and attempt to identify root causes. While it is important to recognize the symptoms of these problems, the focus should be on addressing the causes. However, for teams to take this approach to problem solving requires the support of management and the organization’s culture. For example, if the reward systems in an organization are designed around using schedule conformance and budget conformance as the measures that validate ’success’ without the context of risk and innovation, then it will be a challenge to motivate teams to modify their problem solving and problem management.

Implementing LIfE

As in the case of any improvement efforts, implementing the LIfEcycle requires a structured approach for a successful adoption by project teams and management. While a formal structured approach backed by best practices is recommended here, it should not hinder teams who are already familiar with other approaches such as PLAN-DO-CHECK-ACT. The critical success factor for implementing LIfE is the ability to drive behavioral changes in both management and project teams in how problems and failures are identified, recognized, managed, and resolved. Most importantly, this is not about adding yet another approach to an organization’s overflowing (yet sparingly used) process library.

The six phases of the recommended LIfEcycle are,

  • PLAN the experience
    While experiences cannot be exactly planned for, the goal of this phase is to identify the key milestones or gates in a project’s lifecycle where it is important to assess experiences. While it is very common in IT projects to discuss experiences at the very end of a project when the impact of negative experiences (such as failures) have already been absorbed by the project in terms of cost and schedule overruns and led to hidden costs such as embarrassment. Also, in this scenario, several team members have already moved to other projects or in the process of transition and they are really committed to spending any additional time to share or document experiences.

    A good practice would be for project managers to include LIfE forums at the major milestones or gates in a project as part of their schedule or project plan. It is also important to designate the teams that will participate in the different forums communicate this information early in the project to ensure that teams adequately plan for these forums. The primary driver for this exercise would be the project and business risks rather than merely basing the discussion on outcomes and deliverables. It would also be very important for the individual facilitating the discussion to ensure that the meetings are not drowned in the popular paradox of ‘low probability’, which would mask some of the critical risks that could affect the project. The goal of this exercise is not to increase the number of project meetings (which might already be a bane for many IT organizations), but to encourage teams to engage in active conversations to share their experiences. Experiences documented as bullet points and sent via email may lead to archive-worthy information, but innovation and real improvements can result only from conversational analysis of experiences.

  • LIVE the experience
    One can draw many parallels between work life and personal life because in work life, there are issues, problems and failures that one cannot just run away from. Therefore, the solution is to just live the experience and accept the reality failures and problems are just a part of our work life as are successes.

    The leading author and management guru Jim Collins once said that the mark of a good leader facing failures is to look at oneself in the mirror rather than looking out the window and finding someone to blame. Reinforcing the practice of accepting one’s failures and living the experience will not only be a strong motivator for innovation, but might prove to be a good training ground for emerging leaders in the organization.

  • REFLECT on the experience
    While it makes sense to accept the reality about problems and failures, it is important to reflect on the symptoms that flagged the problems as well as what might be the probable causes that triggered the problem. The simplest route to reflection is to shift the burden on to another individual or team or blame it on the lack of a process or on ill-defined process (the most popular approach for reflection in IT). Again, to draw parallels to our personal lives it is very common to feel disappointed and discouraged when things don’t go as planned and reflect on why an event could not have worked out differently. While the disappointment is only natural, the goal of LIfE is to facilitate taking experiences (positive and negative) to the next level with the goal of understanding the drivers for each experience and then attempting to understand from the experience.
  • LEARN from the experience
    A key outcome from the reflection exercise is to capture information and data on what can be learned from the experience to ensure that the same or similar problems can be prevented in future projects.

    Analyzing the positive experiences should provide us with clues on how we might replicate these on future efforts and the negative experiences should provide us with insights on what should be done differently on future efforts and how we might be able to prevent these experiences on future efforts.

    The expected outcomes from the analysis and learning of negative experiences:

    • identifying corrective action
    • flagging opportunities to document patterns/ anti-patterns
    • identifying opportunities for large improvement efforts.

    The purpose of categorizing the learning is to ensure that the primary direction and goals of project teams is not compromised by the need to fix problems.

  • ACT on the experience
    The process of learning is important to assess the real impact of an event and the required changes. However, the validity and reliability of a change will be assessed only when the change is rolled out as part of a workflow and executed. It is important for the problem manager or a designated team to capture results and feedback from the teams that are executing the change.
    The activities related to learning and acting from the experience can be iterative cycle depending on the result of implementing the changes.

    While there might be several methodologies and practices that organizations can use to ‘learn’ and ‘act’ on their experiences, it is important to align the teams’ thinking using a structured approach that is relevant and practical for learning and developing solution options. The rationale for a structured approach is to ensure that the teams’ efforts are targeted more on the experience and less on meeting the needs of a specific methodology.

    One popular and easy-to-apply approach is Total Systems Intervention (TSI) (Taiwo, 2001) which includes three well-defined phases – creativity, choice, and implementation. The TSI approach applies metaphors to encourage teams to actively engage in conversations problem analysis and solution identification. The key message in TSI is to adopt the most appropriate intervention method that enhances efficiency and effectiveness in organizations.

  • RELIVE a new experience
    The truest measure of a successful lessons learned program is to relive the experience based on the changes made to a process or product and yet to continue to watch out for opportunities to improve and innovate. It is the team’s ability to successfully transfer their learning from a project into the planning activities of another project that provides an opportunity to relive the experience from a change.

    A key requirement for reliving the experience is also to ensure that the history from initially living the experience of a defect or failure does not continue to haunt the team. It is only then that teams would be open to sharing ideas and accepting failures as being part of their learning process. There are several companies that practice this philosophy successfully by requiring managers to encourage their teams to learn from failures with the caveat that the management will not accept the recurrence of a defect, since that would demonstrate the lack of control within the learning process. While this principle, at the outset, might signify extreme tolerance for error, it clearly demonstrates management’s commitment to accept failures and learn from it and the commitment to prevent errors from occurring.

Benefits and Challenges

The underlying theme of LIfE is the need for IT teams to effectively embrace and adopt change. As with any change effort, the typical challenges can range from strong skepticism for the new approach for lessons learned and the potential for increasing the number of meetings and that the team members do not have time to do “real work”. The role of a project manager is to play the role of a change agent by gradually gaining buy-in for the LIfE approach.

“Figuring out how to master this process of failing fast and failing cheap and fumbling toward success is probably the most important things that companies need to get good at”

- Scott Anthony, Innosight

(McGregor, et al., 2006 ¶9)

The most effective way to gain buy-in is by piloting the LIfE approach on ongoing projects by applying the patterns and other learning. This would be followed by activities to capture feedback from the pilot teams, develop metrics and quantitatively demonstrate the value added to the project through experiential learning and by implementing the LIfE approach.

Conclusion

The practices that surround the capture and dissemination of information related to lessons learned vary significantly on IT projects. While some companies have adopted a variation of the After Action Review (AAR) process popularized by the US Army, others have stayed on with simpler systems that pay more attention to the documenting lessons learned, but not necessarily attempting to understand the root causes and using the learning to implement changes or to drive innovation. The missing link that drives this variation is the lack of discipline in teams and lack of commitment in managers to assign the appropriate priority to the tasks relating to lessons learned.

“The performance culture really is in deep conflict with the learning culture”

- Paul J.H.Schoemaker, Decision Strategies International Inc.

(McGregor, et al., 2006 ¶11)

Project teams in most IT shops are driven by the ‘faster and cheaper’ mantra and not necessarily the need to do things ‘better’, which is a major roadblock. Also, teams are rewarded based on their ability to deliver solutions faster and cheaper thereby leaving little or no incentive to subscribe to a formal approach for capturing lessons learned or to drive innovation (faster) and yet be cost effective (cheaper). This mindset only sends a indirect message to the teams that fixing failures at any cost will be recognized and any additional effort expended towards preventative approaches will only increase the project costs.

Baker, A., Jensen, P., & Kolb, D. (2002). Conversational Learning, Quorum Books: Westport, CT.

Bierema, L. (2003). Systems Thinking: A New Lens for Old Problems. The Journal of Continuing Medical Education, 23, S27-S33.

Collins, J. (2001). Good to Great, HarperCollins Publishes, New York, NY.

Darling, M., Parry, C., & Moore, J. (2005, July). Learning in the Thick of IT. Harvard Business Review, 83(6/7), 84-92.

McGregor, J (2006, June 29) Eureka, we failed! How Smart Companies Learn from their Flops BusinessWeek online, Retrieved from www.businessweek.com on July 20, 2006.

McGregor, J, Symonds,W.C., Foust, D. Brady,D. & Herbst, M. (2006, July 10) How Failure Breeds Success Business Week Retrieved from http://www.businessweek.com/magazine/content/06_28/b3992001.htm

Hamid, T. & Madnick, S. (1990, Fall) The Elusive Silver Lining: How we Fail to Learn from Software Development Failures. Sloan Management Review 31(1), 39-48.

Kriegesmann, B. et.al. (2005) Creative Errors and Heroic Failures: Capturing their Innovative Potential. Journal of Business Strategy 26(3), 57.

Kolb, D. & Kolb, A. (2005) Learning Styles and Learning Spaces: Enhancing Experiential Learning in Higher Education. Academy of Management Learning & Education, 4(2), 193-212.

Larsen, H. (2004). Experiential Learning as Management Development: Theoretical Perspectives and Empirical Illustrations. Advances in Developing Human Resources, 6(4), 486-503.

NIST (2002) The Economic Impact of Inadequate Infrastructure for Software Testing Retrieved on June 14, 2006 from www.nist.gov/director/prog-ofc/report02-3.pdf

Standish Group (1994) The CHAOS Report Retrieved on June 4, 2006 from www.standishgroup.com/sample_research/chaos_1994_1.php.

Swanson, B. & Ramiller, N. (2004) Innovating Mindfully with Information Technology. MIS Quarterly, 28(4), 553-583.

Schoemaker, P., Gunther, R. (2006, June). The Wisdom of Deliberate Mistakes. Harvard Business Review, 84(6),, 65-71.

Taiwo, J. (2001). Systems Approaches to Total Quality Management. Total Quality Management, 12(1), 967-973.

West, M. (2004). Applying Systems Thinking to Process Improvement. Crosstalk-The Journal of Defense Software Engineering, March 2004, 26-29.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2006, Prem Ranganath
Originally published as part of 2006 PMI Global Congress Proceedings – Seattle, Washington

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.