Update to root cause analysis for poor software requirements

Just a quick note.  After reading through some of the feedback on my recent post on "the root causes of poor software requirements," I had to agree with some of the respondents: I had forgotten a branch in the analysis. 

So, for the past week, I've been stealing a few minutes here and there to review the analysis and add updates.  I just posted an updated analysis, adding a new top-level branch (at the end) and adding a sub-branch about half-way through.

Feel free to check it out. 

Now, to take this to the next step: anyone can figure out the steps and costs involved with improving your requirements-gathering practices.  Here are the steps.

a) Steal the list right from the post.

b) Load it into an Excel spreadsheet.  Add the following columns: Score, Mitigation type, Mitigation Tactic

c) For each item, add a score, from 0-5.  See the weighted ranking below.

Score 0 if this cause does not happen in your environment
Score 1 if this cause occurs but is easily overcome in your environment
Score 2 if this cause occurs but it doesn't occur frequently or drive substantial quality problems
Score 3 if this cause occurs occasionally, and the business analyst or program manager finds the flaws
Score 4 if this cause occurs frequently, and/or the software developers or testers find the flaws
Score 5 if this cause occurs frequently and the flaws are found in deployment or production

d) For each item that ranked 3,4, or 5, write a statement for how you think you should mitigate it in the Mitigation Tactic column.  Feel free to brainstorm many possible ways, but then select the way that you believe is most feasible.

e) For each mitigation, add a value in the Mitigation Type column.  use one of the types below or create your own list.

Use type 'Training' if your mitigation is focused on improving the skills of a participant
Use type 'Automation' if your mitigation is focused on moving information efficiently or using workflow tools
Use type 'Data' if your mitigation is focused on improving the information collected or making it available
Use type 'Process' if your mitigation is focused on analyzing workflow, allocating responsibility, or insuring accountability
Use type 'Staffing' if your mitigation is focused on adding staff to a role or creating a role that doesn't already exist

f) Sort your analysis by type and score.  For each group of mitigations by type, you have a workstream (or sub-project).  That effort can be estimated and an approximate cost established.  For the 'Data' and 'Automation' groups, you have a list of objectives that can be used to select software for requirements management.

g) Pull together a project proposal from your cost estimates and propose a project to your management that outlines the steps you intend to take, the problems you intend to solve, the amount of money that you believe it will cost, and (here is the hard part) the value of the quality gains that you expect to reap.

Good Luck!