Remember to include the details of your customer or stakeholder response in addition to the technical action your team took to address the mistake. Also, be sure to include any retrospective activities your team completed to ensure the mistake would not occur again.

"I was the project manager on a recent project that involved making updates to a legacy system none of the engineers on my team had ever worked with before. It had been two years since any adjustments had been made, and nobody really knew the code. We were asked to automate a process on behalf of our business users and developed a solution that we thought would work. We leaned heavily on a business expert to walk us through the system and explain what happened in all of the use case scenarios.

It was decided to use a particular flag to kick off a calculation and resulting data update included in the automated process. Based on our review with the user, the flag would become active during a particular scenario and it seemed to fit our processing needs. We tested the solution and everything seemed fine. However, the process updates caused a data mess when we moved the solution into production. It turned out that the flag was used in more use cases than we thought and our process was running more frequently than needed. It was also making erroneous updates to the database.

We identified the problem quickly and found the root cause. We rolled back the update, cleaned up the data, and then reengineered the process to use another flag. Additionally, we took the time to review all of the associated legacy code to make sure we would not end up in the same position with the new solution.

I kept our clients aware of the issue and our steps to remedy the problem the whole time we worked to fix things on our end. They appreciated our quick response and dedication to fixing the issue. They also appreciated that we invested time after things cooled down to learn the system better and ensure mistakes like these were minimized going forward."