What are your risk management strategies?

Question

We're a small web development business and we eventually want to release web applications as well. Right now, we're doing some risk assessment and would like to know what other companies do for security and risk management. What are your risk management strategies and practices, technical and otherwise?

Here's what I have so far (and I'll keep a running list):

Technical

• Source control
• Unit testing
• Consistent coding standards
• Backups at different physical locations
• Bug tracking
• QA testing
• Security audits

Other

• Explicitly detailed contracts
• Business insurance
• Evidence based scheduling
• Weekly deliverables and customer sign-offs
• Audit trails for accountability

Answer 1

Step 0 - identify and implement POC project for all high-risk technical issues.

Weekly deliverables with customer acceptance (even if it's just a faux customer).

Answer 2

Even with a small company, I feel like 'ownership' and 'answerability' are key. If you are going to have a lot of community projects, then who is answerable if it goes bad? Obviously, this is something which should evolve with the company, and being too strict about hierarchy leads to stifled teams. But it's something to think about the kind of team-dynamics you'll want to create and foster at your company.

Answer 3

• A good project management plan (i.e.: SOW, requirements gathering, "as-is" model, "to-be" model, etc.)
• While backups are a great risk management step, what many people/companies fail to take into consideration is their process for backing up. I've seen too many instances where the process for backing up (inserting tapes, scheduling, removing tapes, moving tapes offsite, etc.) was too easy to break.

Answer 4

On a more abstract level:

Keep a risk-list with all possible risks you can think of, be they big or small, probable or improbable. Update or at least recheck this list every few weeks. This may be as tangible as "hard disk failure on main server" or as intangible as "competitor launches his product first".

Then, for each risk, evaluate the impact and probability on some scale (this can be quite arbitrary). The real risk will be somewhat proportional to the product of both. I.E., a high potential cost with very low probability is not as bad as medium cost with high probability. These numbers are just there to help you sort the risk, don't take them to seriously.

Next, for each risk think about mitigating measures you can take, be they countermeasures, insurance, whatever. Again, figure the cost of those (not onle the monetary cost!).

Only now you can really decide what (and if at all) to do about each risk. Just accepting the risk may be an acceptable solution at this point, but not earlier.

You might want to read Waltzing with Bears: Managing Risk on Software Projects by Tom DeMarco, Timothy Lister. Well woth the time.

Answer 5

You included one item about infrastructure.

• Backups at different physical locations

I recommend expanding this to include data protection.

• Hardware that guards against power loss (battery or mechanical power)
• Hardware and software that supports ready access to your code and builds

Crashing and losing your data breaks coding flow and restoration from backup takes much longer than never losing it in the first place.