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.
One of the most important reasons to manage scheduling as described above is so that you don’t mislead management. Keeping management accurately informed of project status will keep them on your side and allow requests for additional resources to be an understandable outcome of the project situation, rather than a surprise brought about by project leader lack of competence.
Important Lesson #2: Project status must be provable by inspection or demonstration to be 100 percent up to requirements
It’s not done, if it’s only 90 percent done. Progress payment must be tied to provable 100 percent complete milestone accomplishments.
Payment milestones are a key control mechanism for large projects. Don’t pay 90 percent of a progress payment and expect the 10 percent retained to be a motivational factor. If you do, you will find out the hard way that the real motivation will be to complete the next project milestone to get the next milestone check. The small check (10 percent held back on a previous milestone payment) just won’t matter as much.
You can’t complete the project by accepting partial work.
Important Lesson #3: To get out ahead of potential problems requires active project risk management as a key customer role
Most contractors and project team members don’t ever envision themselves as sources of risk—they almost always view risk as an external factor. They look at things like as technology defects, backordered products, customer task delays, bad weather, and so on.
For this and a number of other reasons the customer must assume the full responsibility for project risk management. Even though the customer is not the source of most problems that can arise, the customer can identify the areas of project risk and actively manage the risk factors, including those that are not within the scope of the installing service provider. The bottom line is this: if you don’t manage project risks, you can easily lose control of the project.
This is why a risk officer (or whatever name you use) must be included on the project team, and this individual must not be the project leader or manager.
Approaching Projects Effectively
An effective approach to technology projects takes into account the aforementioned factors and many more. Such key project success factors are identified in the Security Tech Project Survival Test.
Use this checklist to rate your current or upcoming project. If your current project does not rate well, then now is the time to take corrective action. The longer corrective action is delayed, the bigger the risk of project cost and schedule overrun will be.
This Project Survival Checklist is based upon an in-depth study of deployment projects involving today's complex physical security system technologies and documented IT best practices.
Using the Security Tech Project Survival Checklist is easy:
- Start by selecting answers for the 36 checklist questions.
- Select the project size and complexity factors that apply to your project.
- Press the Calculate My Score button to obtain the Survival Test results.
- Review the Score Rating and related comments.
About the Author: Ray Bernard, PSP, CHS-III is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services for public and private facilities. For more information about Ray Bernard and RBCS go to www.go-rbcs.com or call 949-831-6788. Mr. Bernard is also a member of the Content Expert Faculty of the Security Executive Council. Follow Ray on Twitter: @RayBernardRBCS.
