Thursday 15 March 2012

Lessons Learned about Lessons Learned (Part 1)

My last post about "Best Practice" was something of a personal peeve rather than a major hurdle to successful business improvement, although lessons should be learnt from the story I told, namely:
  • your improvement focus shouldn't be about creating templates and completing documents to provide evidence for appraisals and audit
  • measures that you put in place need to be thought through from the perspective of those being measured if you want to avoid costly and wasteful dysfunctional behaviour
  • best implies that there is no room for improvement
Ultimately, I also suggested a relatively quick fix; simply stop using the term "best practice" and come up with something more appropriate.

"Lessons Learned" (learnt?) is a different kettle of fish however. Most organisations have some kind of lessons learned mechanism in place (very often associated with their "Best Practice Repository"!) and in my experience very few of these mechanisms add any real value to the organisation. They are put  in place to meet the "requirements" of CMMI, etc. and as is so often the case, fail to even to do this adequately because people fail to understand what the model is really trying to help the organisation achieve.



There are a whole bunch of issues associated with the Lessons Learned process, many of which would appear to be associated with the origins of the idea. When I first started working in Software Development over 25 years ago we never did Lessons Learned - but then again, we didn't do much of the stuff commonly considered as integral to the development process today. My first memory of anything resembling the concept of a lessons learned review was when I read an article by Tom deMarco on Project Postmortem Reviews * some time towards the end of the 1990s. This made a lot of sense back in those days - at least in the organisations I worked in where we had a small teams of developers who stayed together and worked on project after project. It made sense in projects that lasted for years, where phase postmortems could be used to identify and correct mistakes prior to starting the next phase. And in the days before I started getting involved in SW-CMM initiatives I introduced the concept and practice into several groups with some small success.

On a small scale the Project Postmortem Process defined in that paper can be very useful as long as two conditions remain in place:
  • The same teams of people are used in a "product development environment" so that they have a shared understanding of the issues which cause problems
  • There is a management environment that allows the problems to resolved internally within the teams rather than imposing  inappropriate solutions on the team without really understanding the underlying issues.
The Project Postmortem Process fails as soon as:
  • It is scaled up to become an organisational process - e.g. the focus changes from an internal review and change exercise to a management mechanism for fixing organisational issues
  • Project teams are constantly rearranged and staff treated as interchangeable resources
  • Emphasis changes from internal and potentially informal communication within a team, to a demand to codify the findings for wider use
  • Managers and process experts attempt to implement CMMI without understanding what the model really implies - i.e. that the process is part of the feedback mechanism to improve the business, not an exercise to generate paperwork to fill up a repository
  • The process is used to apportion blame
Over the years since first reading about the Project Postmortem Process I have been seen numerous lessons learned systems in numerous organisations. Most of them suffer from exacly the same problems.
  • Lessons Learned reports are documented and filed away and the feedback element to improve process rarely occurs
  • Lessons Learned are purely qualitative and can easily be distorted by the strongest or most vocal members of a team
  • Not all project team members or stakeholders are invited to participate in the process so not all perspectives are represented
  • Most staff perceive the process as a waste of time (and in most cases they are right)
  • Reviews are usually focused on project failures and successes and the process improvement opportunities are not realised
  • Managers or SEPGs that do any analysis on the results attempt to implement heavy handed changes based on their interpretation of the results without understanding the underlying circumstances or, most significantly, the differences between the environmental characteristics of the originating team (project or programme, agile or waterfall, etc.)
In fact many Lessons Learned reviews and reports have become so worthless that I can often predict the findings without knowing anything about the project or people. Typically the section on Things That Worked Well include:
  • Excellent teamwork and communication between project team members
  • Everyone went the extra mile and worked hard to complete the project under extremely difficult circumstances
  • The pizza brought in by senior management on the nights we had to work was really tasty and much appreciated
And in the Things That Could Have Been Better you'll see:
  • Really difficult relationship with the key stakeholder made this project a major challenge
  • Customer was never available
  • Requirements were so poorly specified we had to make them up as we went along
  • Technical procurement issues led to long delays
  • The CMMI initiative caused us a huge amount of extra work which didn't add value to the project
So very often, project lessons learned reviews tell us what we already knew, and probably have known about for some time. And the only thing that future projects can learn is that they are doomed to follow a similar pattern because nothing is being done to correct the organisational issues. The most likely outcome is that new status report and requirements specification templates will be imposed on the projects.

In part 2 I'll have a go at look at some of the things we might be able to do to make Lessons Learned a more valuable tool for the organisation, by extracting value for both projects and processes.

* Collier, DeMarco and Fearey: "A Defined Process for Project Postmortem Review" IEEE SOFTWARE 0740-7459/96/$05.00 © 1996 IEEE Vol. 13, No. 4: JULY 1996, pp. 65-72 Print this post

5 comments:

  1. Nice post. Overlooks the real problem with any project post-mortem review though: The generally enormous gap in time between the events being reviewed and the review itself. It's this gap that contributes to many of the other dysfunctional things you mention.

    Looking forward to part 2.

    - Bob

    ReplyDelete
    Replies
    1. Thanks Bob : agree about the time issue which I've got covered in part 2 but neglected in this part - doh!

      Delete
  2. Good post with a lot of examples that are true to Lessons Learned meetings. One of the bigger barriers can be trust. It can be hard to provide honest feedback when other team members may get offended and you still need to work with them. This is feedback I have often received on why people do not want to speak freely.

    I like Lessons Learned where we focus on both what went well that we would repeat and what we would like to do better. For those items what is reasonable or within our circle of influence to change? In my situation it can be how we approach testing problems. Perhaps we research different approaches such as using Mindmaps to layout strategy.

    Another problem with these meetings is they can get very angry. If the project did not go well often it becomes a complaint session. And at the end of the meeting you don't have anything to work with but a bunch of angry complaints. The right facilitator is important - someone who can remove himself from angry outburts or criticism of the project. The facilitator needs to monitor and progress the meeting. There is a certain skill needed to be a good facilitator.

    ReplyDelete
  3. Thanks Bernice - yes trust can be an issue, but we shouldn't we be focusing on the system and process issues anyway? As Bob indicated, some of these problems are caused by having LL sessions at the end of projects when people are stressed and likely to have a large supply of anger stored up. More frequent, process oriented reviews go someway to diffusing this.

    ReplyDelete
  4. I do agree about focusing on process instead of people. But many people still take that as a personal attack. I think a good facilitator can help in that situation to diffuse any anger or misunderstandings. I like frequent LL to incorporate learning while progressing a project. Looking forward to part 2.

    ReplyDelete