Avoiding a Project Ambush

There was a story I read recently on the Times Online:  French troops were killed after Italy hushed up ‘bribes’ to Taleban.  What could this tragic event possibly have to do with IT security?  Let me explain.   

First, there were allegations that the Italian government had been paying bribes to the Taliban in exchange for save haven. But Italy vehemently denied it.  Then, last year, ten French troops were killed in what they had previously assessed to be a peaceful area of Afghanistan. 

Before France went into this deadly area, they (of course) did a risk assessment.  What factored considerably into France's conclusions was the fact that Italian troops were met by little aggression in the same area.  Unfortunately, France went in to the same area but ended up in a deadly ambush, resulting in the tragic deaths.

Politics aside, I think this example illustrates the importance of conducting a thorough assessment during the requirements phase of any security or software-related effort.  If an observation is made during this phase, you should check to see if there are any dependencies behind it.  This way you can better identify any variables that could negatively impact the software implementation.  Trust but verify, in other words.

Some points to consider:

• Resarch and look for any underpinnings to your conclusions.  Make sure there's no dependencies behind what is observed that are not guaranteed to be there.
• Interview and observe more than once.  How you see things one time may be completely different the following week.  Over a series of visits you should be able to aggregate and form a more reliable assessment.

In the book 97 Things Every Software Architect Should Know, Timothy Hugh has some good advice.

Best practices in software architecture state that you should document the rationale behind each decision that is made, especially when that decision involves a tradeoff.  In more formal approaches, it is common to record along with each decision the context of that decision, including the "factors" that contributed to the final judgement.

As an analyst, you make certain assumptions after conducting interviews.  This is how we fill the gaps, not only out of time and budget constraints, but also because this is just human nature.  Recognizing and mitigating this behavior can help ensure what is perceived is indeed fact, and this can hopefully prevent ambushes, project-related or otherwise.