Although written a few years ago, this Technical Writing Sample of an Internal Communication of a Post Mortem Web Application Project Analysis is a good example of my skill in both Business Communication and Technical Writing.

Root Cause Analysis

Introduction

After the XYZ 2.0 product delivery, an informal Root Cause Analysis was completed by the QA Department. It is considered informal because:

  • Only one person from one department analyzed the bugs. Generally, this should be completed by 2 or 3 people from a couple of different departments (PM, Dev, QA).
  • Not every bug was analyzed, only a sampling (about ¼).
  • Only bugs from the closed list were sampled (vs. all bugs touched during the phase).

Methodology

Each bug was analyzed and put into one of the following classifications:

  • Requirements – these are bugs that are usually caused by no, or unclear, requirements. Development does not know something should be implemented or implemented the specific way.
  • Code – coding errors and code integration bugs.
  • Test – this includes incorrectly logged bugs, test not knowing correct functionality (which borders on being a Requirements bug), and issues that can’t be reproduced.
  • Suggestions – all of the suggestions and requests for new or improved features.

Findings

Out of 77 bugs analyzed, the number in each classification of bug was as follows:

  • Requirements: 10
  • Code: 35
  • Test: 14
  • Suggestions: 18

Implications

What do these findings mean and what can we do to improve our Project and Development processes going forward?

With Code issues being the highest, this suggests that Quality Processes need to be put into place to keep bugs from happening in the first place and to have the Developers finding bugs before the code is delivered to QA. These Quality Processes could include:

  • More unit level testing to be done by the Development Team
  • Code Inspections and walkthroughs
  • Write Unit tests, then code (Extreme Programming technique)

Although Suggestions being the next highest is a good thing, this would imply that Development, Support, and/or QA Team members are not being involved enough in the Requirements phase. We could improve our product quality by tapping into all of these resources during the requirements phase, instead of just during the test phase.

14 bugs in the Test category is not completely bad, but this number would be lower if documentation was kept more up to date and if there was more project documentation.

Only 10 bugs in the Requirements category suggests that we are doing a pretty good job of gathering, understanding, and implementing requirements.

Additional Recommendations

A more formal/empirical bug analysis needs to take place on upcoming releases when time allows.

Advertisements