Fixing security project failures

In this four-part series, I will investigate why large IT security projects fail and how organisations and vendors can ensure success.

We all love going after the BIG ONE, that Ub"er IT security project in a huge organisation which is going to ensure a massive improvement in that organisation's security stature and, of course, comes with a great deal of prestige. If successful, that is.

The project is typified by spanning multiple business units and would require bringing together role players from all parts of the organisation.

It has a multiyear project plan and will cost millions of dollars in hardware, software, implementation services and consulting. Everybody, both internally and outside of the organisation, gets excited by the project and works hard to make it a success.

Then out of the blue one day, senior management decides to can or shelve the project due to valid reasons that nobody on the project had foreseen.

The question arises: how can an organisation successfully implement larger projects such as ERP and CRM but then find success so elusive when it comes to smaller projects such as IDM or SIEM?

The massive projects normally arise out of tangible requirements within an organisation to address very real risks to it that have already resulted in security incidents. The organisation then follows the normal process of gathering information, speaking to vendors, refining requirements, motivating for budget and then, once the budget is approved, going through a tender process, followed sometimes by a proof of concept or pilot phase.

Just the process of getting to the tender phase can sometimes take several years; meanwhile the risk profile that drove the initial requirement has grown significantly.

All along there are vendors and system integrators involved in advising and refining the requirements of whatever tender might eventually be released to better suit their particular product, and by doing so spend a lot of time and money in the process.

Everybody likes building big tenders to address a whole host of requirements - fight this desire.

Andrew Ochse is product manager at SecureData.

Why a big security project fails at this stage is normally because the organisation can't sufficiently justify the budget for a solution to go out on tender, or there is no suitable business owner for the solution since it spans too many business units.

If the tender comes out, vendors scramble to get their responses in and unholy alliances are made because everybody wants a piece of the pie.

In the process, there is even more time and money spent on responding to these huge tenders, along with political and legal wrangling that goes on in the background to "cover all the bases".

Then everybody waits in a state of great anticipation for the tender to be awarded.

Projects normally fail at this point due to the costs involved being far greater than what was budgeted, or there simply is not one single elegant solution which fully satisfies all the requirements.

There have also been cases that the project gets shelved because the organisation realises that the business impact would be too great and its maturity level is not at a point where it is capable of undertaking such a project.

Then you get the situation where a tender is re-released on a yearly basis for a few years until technology has caught up with the requirements, or the cost of the technology has reduced to such a point that it does justify moving to the next step. This occurred with an IDM tender that was issued five years in a row by a certain telecommunications company.

Given costs involved responding to these tenders, vendors often simply stop responding to a tender after the third time it has been reissued.

To address these issues, organisations need to understand clearly the threats and risks they are attempting to mitigate. Once they have done that, they need to identify clearly how they are going to mitigate those risks, and the result is that their requirements for the project become crystallised.

Once the requirements are identified, investigate which technologies and processes are able to address these requirements best. Talk to the vendors, pick their brains; it works out cheaper for both parties. A one-hour technical vendor presentation is worth far more than a 1 000-page tender response.

Once as much information as possible has been gathered from all the vendors, including budgetary pricing, build a solid business case with ROI models and accurate risk and threat quantification.

Everybody likes building big tenders to address a whole host of requirements - fight this desire. Rather build small, manageable tenders and business cases as they have a better chance of being successful.

If the company has to go out on a huge tender, try to keep as much to the core requirements as possible and avoid scope creep. The important thing is to get the business case with the associated budget approved; once that is done, half the battle is won.

In the next Industry Insight in this series, I will investigate how to guide a large security project through the post-tender and pilot phase.

* Andrew Ochse is product manager at SecureData.