How to survive your next security tech project

A look at organizational best practices for avoiding common mistakes in technology deployments

A great many security technology projects are late and do not accomplish what they were intended to. Large organizations with IT departments that have well-established project management teams have a much greater chance of success in their projects than organizations who don’t apply IT best practices.

Some physical security systems integrators, dealers and installers consider project best practices to be “idealistic” or “academic” and thus not necessarily applicable to physical security technology projects. This is nonsensical since electronic physical security systems definitely are IT systems with computers, networks, applications, databases and so on.

Many security technology deployment projects remain stuck at “90 percent complete” in spite of the advance of the calendar and often are declared “complete” by means of a compromise with what the stakeholders actually wanted to accomplish. (If you are in the midst of such a project now, head over to this Troubled Project Checklist page.)

Based upon your organization’s past security deployment experience, would you comfortably bet your job on a 100 percent successful conclusion of your next technology project? That would mean a project that’s basically on time, did not go significantly over its budget, and actually achieved all it was supposed to in terms of system functionality and security operations capability.

A technology deployment project should provide you with substantially improved security operations capabilities. If it doesn’t, what is the purpose of the investment? Sometimes the “substantial improvement” is moving from a failed or continuously troublesome system, to one that runs well. But hopefully it’s moving from technology that gives you some of what you want to a technology that gives you all of what you are looking for.

The Security Tech Project Survival Test is based upon best practices collected from over two decades of critical project success experience. It is likely that the test includes some good ideas that you hadn’t thought to incorporate in your project—or didn’t know that you could.

Lessons Learned

You learn a lot while you are executing technology projects that you didn’t know at the outset. This is one reason why project planning, including schedule and cost estimates, are usually overly optimistic. They are based on best-case assumptions, and don’t take into account the things that can go wrong - otherwise known as project risk.

It is important to learn from past project experience, and mature IT department project practices are based upon many “lessons learned.”

Important Lesson #1:  Initial project schedules are preliminary

Schedule slippage occurs based upon many causes, such as:

Insufficient project management at one level or another, which could be a customer issue or a technology-provider issue.
Logistics issues, such as longer-than usual product lead times, conflicts that relate to access to work areas, such as a customer remodeling project, unusually inclement weather, business events, and so on.

Insufficient early testing in the project, resulting in a need to revisit designs and specifications.
Not enough project milestones, which usually means that the project planning is not detailed enough. This results in projects whose real progress is not highly visible.

Lack of sufficient project team member qualifications, causing tasks to take longer than they should due to increased “learning on the job” time.
Technology problems, such as incompatibility between devices and/or systems, or software/firmware bugs.
Disagreements, which can happen as a result of insufficient requirements development or contractual language that isn’t detailed enough.

An extremely helpful project best practice is to consider initial project schedules to be preliminary estimates, which get updated as each phase of the project is completed. This of course requires that you do have a well-defined project, with phases that can easily be verified as 100 percent complete. It can take a bit of backbone to refuse to close out the project phase until it is provably 100 percent complete, but failure to do so will cause you to lose control of the project.

This content continues onto the next page...