Lessons Learned from Collaborative Writing Projects

We make mistakes every week on our Technical Writing projects. However, since we’ve started to capture things in our lessons learned meetings, the ‘repeat offenders’ have gone down. Running web-based Technical Writing projects is difficult as you don’t get to meet the team you’re managing, so sessions like this can make a real difference.

Lessons Learned – Is it worth the effort?

If you keep making the same mistakes in your Software Development projects, then one way to improve the development process is to created a Lessons Learned Template, preferably in Microsoft Word, and use this to share those really crucial lessons, insights and workarounds.

One way we do this is to create a web meeting near the end of the project. Note, not when it’s over. I also arrange for my team to meet with our customers and discuss what went well and what could have been done better.

It’s low-key and no finger-pointing.

‘We want to improve – can you help?’

The purpose is to:

  • Develop a better understanding of how others see us
  • Improve our tech writing processes
  • Examine where communications broke down
  • Capture unexpected issues that arose during the SDLC
  • Identify those who deserve credit for going the extra yard

After the meeting, we capture the information in the Microsoft Word templates and share these with the tech docs team so others have an opportunity to learn from this experience – get the credit they deserve.

Remember, it’s not a blame game.

Format for Lessons Learned

The purpose is to capture what worked well and what could have been improved. Then look at all the key areas during the design, development and testing phases:

  • Business Requirements – identify what was missed or not captured correctly when writing the business requirements
  • Design Phase – discuss if we needed to be more involved in this phase and what we missed.
  • Development – outline what techniques worked best and where issues arose, especially when we worked with the developers to understand how the system worked
  • Test – identify gaps in the testing strategy and how the linkages to the tech writing department could be improved
  • Project Plans – identify what worked well and areas for improvement in the project management lifecycle
  • Communication – identify how to develop a better communication plan that meets client expectations. You can also look at developing better report writing methodologies.
  • Quality – identify how to improve the quality of the deliverables
  • Risk – identify how to reduce risks and how to track these across all development phases
  • Team Characteristics – identify which team performed above expectations and where others could improve.
  • Other Comments – identify other observations that need to be shared, such as teamwork, professionalism, work relationships, responsiveness,as well as technical observations in relation to the tech writing software.

Do Lessons Learned Work?

None of this works unless what you share is useful, accurate and balanced.

The point of the Lessons Learned document (especially when documenting Software Development Projects) is not to criticize your writing team – or pass the blame to someone else – but to share insights that they may have overlooked.

What else would you add?