You got the tender: now what?

The previous Industry Insight in this series investigated why large security projects failed in their initial phases leading up to and including the tender process.

Once an organisation has run the gauntlet of the initial tender process - which normally involves requests for information or for proposals - the security people, after a lot of hard work, get approval for a pilot phase or selected vendor "shoot-out".

Depending on the type of project and technology being deployed, a vendor shoot-out is an excellent method with which to decide which vendor's technology would work for the organisation - or even if it is going to work.

Let's be honest, all vendors and system integrators oversell their technologies and capabilities. They sell the road map and tell the customer that they can influence the time scales on a particular set of features, or that integrating critical legacy system written in Fortran to work with a .Net base single sign-on solution is no problem.

Reality check here please. No matter how big the company, it is not going to dramatically influence the road map of a product produced by a vendor that has a few hundred products in its portfolio.

Let's be honest, all vendors and system integrators oversell their technologies and capabilities.

Andrew Ochse is product manager at SecureData.

Legacy systems and large security projects require a side discussion. Perhaps that legacy system running critical data should have been retired last century? Do you remember how much it cost to get that system Y2K compliant?

Well it's now eight years later, the people who originally worked on that system are probably retired or dead, and it is time to get rid of it.

This gets to the crux of the matter of why large security projects often fail technically: the need to integrate with legacy systems hinders the success of the project.

And if it is hindering the success of security projects within the organisation, it is probably hindering the success of any other IT-related project within the company.

In extreme cases, I would not be surprised if the legacy systems in such an organisation hinder the success of the business in totality.

This begs the question: How do you address this fundamental problem involving legacy systems?

Security professionals would tell you to apply the 80/20 principle, whereby it would cost a lot more to secure legacy system versus securing everything else. So here is the uncomfortable question: Isn't that legacy system a security risk to your organisation?

Obviously, yes - that is why we are trying to secure it in the first place. But then the uncomfortable question is: Aren't the legacy systems within the organisation a risk to the business in totality? This will require further discussion in later Industry Insights in this series.

So now we continue the vendor shoot-out. The beauty of such an exercise, in a lab environment which is a replica of the organisation's live environment, is that it quickly reveals a number of things about the vendor and system integrator.

You need to check:

* Does its technology actually do what it says it will or did the vendor try to sell vapourware?

* Are the people involved from a system integrator and vendor side actually capable of deploying the technology successfully?

* Are your own people on the project competent?

The problem I have found is that there are few people in the industry, both on the vendor and customer side, who have been involved in the scale of projects I'm talking about and even fewer who have been involved in successful ones. So a vendor shoot-out is a good method of testing the project team which will eventually deploy the solution.

A very important factor is to make sure the people involved in the shoot-out from both the organisational and vendor's side are also going to be the people who actually deploy the solution across thousands of desktops and hundreds of branches. There is nothing worse than having some hot-shot presales guys flying in to do the shoot-out from the US and then you're left with the local monkeys to try to deploy the solution in a live environment.

Make sure the environment of the shoot-out replicates the live environment as closely as possible so that as many of the technical stumbling blocks get addressed at this stage.

On the financial side, shoot-outs cost money, both to you and the vendors involved. The best way to address this is to enable the successful vendor to reclaim the costs involved as project costs - particularly as a lot of technical integration work might already have been undertaken as part of the shoot-out.

In the next Industry Insight in this series, I will discuss how to get the project under way successfully after it has been awarded.

* Andrew Ochse is product manager at SecureData.