It is important to document the lessons learned during the course of a project. Documentations of decisions made or decisions/actions that would have been better if done are crucial to transferring the knowledge of the team members of others in the organization that might run into similar circumstances. While the physical documentation of these lessons are needed, what may be equally as important is the why behind why this change/decision/action was done or is preferred. This will give much more perspective to the person reading the document. If there isn’t much context behind why something was a lesson learned, then readers may not take much stock on the point and end up running into the problem themselves. For example, in a previous role, during a project a change was made in a process which was a result of a ‘lessons learned’ from a previous project. However, because there was no context behind why the change was desired, when a review of the process came, no one knew why the change was done (since the people on the project were either new or not on the old project). The process change was reverted, however a problem occurred that put into perspective why the previous team member had put that change in the lessons learned. If there had been more context behind that point, time would likely not have been wasted undoing and redoing the change and the problem probably could have been avoided altogether.