We recently added a relatively large feature to our product that involved the entire R&D department (with all the different teams within it).This feature included UI development, server side development, and huge migrations of SQL schemes (and other stuff that I myself was not involved in at all).The development process for this feature was chaotic - Front-End and Server teams were not synchronized, SQL migrations broke the DB, and product specifications were incomplete which meant that with every step of the way we found new issues with the initial definition, requiring changes to core concepts that the developers had relied upon.All in all, a feature that was planned to be released within 10-14 days, took roughly 24 (intensive) days of development.I was requested to write a report of 'What went wrong' (from my team's side - each team writes such a report from their pov).What are the common methodologies for writing such reports, specifically in the field of software development?Also - Is there some formal name for such reports?EDIT & ANSWER:Apparently, such a report/review-process is commonly referred to as 'Project Post-Mortem' (other names exist as well).After figuring this out, I found these two resources that outline suggested methodologies for gathering the necessary data, organizing it, analyzing it, and formulating solutions for discovered issues (as well as some general information on these reviews and their purposes):  'A Defined Process For Project Post Mortem' -http://www.csee.umbc.edu/courses/undergraduate/345/spring12/mitchell/readings/aDefinedProcessForProjectPostMortemReview.pdf'Post-Mortem Reviews: Purpose and Approaches in Software Engineering' -   http://www.uio.no/studier/emner/matnat/ifi/INF5180/v10/undervisningsmateriale/reading-materials/p08/post-mortems.pdf
Common Methodologies for Writing Post-Mortem Reviews
writing