In the previous article it was investigated what to do in the post tender phase, including going through a technology "shoot out" to choose the best vendor and system integrator for the job at hand.
Hopefully by now all relevant parties to the solution, namely the customer, vendor and system integrator know what is involved in getting this solution deployed within the enterprise, thanks to a successful technology "shoot out".
The important thing to remember when starting the planning of the deployment phase of the project is to have a strong project manager. It should preferably be the same project manager who facilitated the "shoot out". It is important to ensure the people who were involved in the "shoot out" from the vendor and system integrator side are part of the deployment team.
The key to success at this stage of the project is going into the deployment phase as quickly as possible, to keep the momentum up. Get the procurement of the kit done as quickly as possible after the project has been awarded. Secondly, don't let the kit sit in the warehouse for six months before it gets deployed. In most cases, a company pays maintenance on the kit from the minute it lands at the warehouse, so don't delay, install the stuff!
If the project involves rolling out software and hardware to end-users, then stagger the procurement process and buy the kit in batches. If for some reason deployment needs to be delayed, but the purchase has to be made, negotiate a maintenance holiday on the kit till it goes live.
Go for the quick wins with the project, put the solution in where it is going to have the greatest effect and impact, over the most users possible as quickly as possible with the least amount of effort. That way the project gets the maximum visibility and at the same time "buys time" for the more difficult parts of the project, when complex integration needs to be undertaken.
Of course, the other option is when it comes having to undertake complex integration is to avoid it at all cost, especially when it involves legacy systems. Is that legacy system maybe not just a security risk but also an enterprise risk? There are a number of issues around maintaining, supporting and updating legacy systems. If the vendor of that legacy system has "end of life" for the product and "end of support" for the product, maybe it is time for it to be let out to pasture and the data and function on it migrated to a new system.
The key to success at this stage of the project is going into the deployment phase as quickly as possible, to keep the momentum up.
Andrew Ochse is product manager at SecureData Security.
The issue is that trying to integrate security into something that isn't even supported by the vendor anymore is an extremely costly and time-consuming task. It could be found that the cost of migrating the data and function to another system would be significantly less than trying to maintain it.
The principle behind the argument is that most large enterprise-wide security solutions are severely hindered in the deployment phase by legacy systems and sometimes are the cause for the project to fail or not complete their deployment. Now the question is, if legacy systems are causing security projects to fail, chances are they are causing a number of other critical projects to fail.
The other thing to undertake as part of the initial deployment is to skill up internal resources that are going to manage the system eventually and ensure they are also part of the deployment team. Build a contingency plan into the project team from all sides. Ensure the vendor guarantees that they have multiple individuals involved in the project, so the unavailability of a single person will not impact on the progress of the project. Of course, in the current climate, this becomes very difficult from a customer, vendor and system integrator perspective, so spend the money on training those two or three additional individuals to ensure the success of the project.
Deploy the current version of the solution; don't wait for the latest and greatest version the vendor is promising you, since it could have an entire new set of problems associated with it.
The larger the project the more important it is to keep the profile high with management so they feel the money they spent was well worth it. This is not just important during deployment but also post deployment.
* Andrew Ochse is product manager at SecureData Security.
Share