Force multiplication, in military usage, refers to an attribute or a combination of attributes which make a given force more effective than that same force would be without it. The question below came from a security manager who didn't realize that his company's IT department was offering to act as a significant force multiplier for the Security department's technology deployments. For companies with well-established IT functions, collaboration between Security and IT can bring valuable resources to the table-substantially improving what gets accomplished with electronic physical security technology.
Q: What can I do about IT trying to take over my security technology projects? They want to insert all kinds of overhead and people into my projects, such as: project manager, requirements specialist, architect, test specialist, network designer. They are asking if they should have a business analyst involved. I understand having a network designer involved. But it looks to me that if we add this much overhead to our projects, we'll never get anything done! I want to get my current project off the ground now.
A: This is probably a great opportunity to strengthen Security's approach to technology deployment. Almost always in this kind of situation, the IT folks are trying to do the same thing they do for the rest of the organization: support technology deployments so that the end users can concentrate on the application and use of the technology, not the technical parts and pieces. It is even possible that you have just been offered a high-power swat team that can save you time, effort and money-if you use them wisely. IT is a service organization, and will be looking to you to explain how they can support your efforts and make your technology burden less.
Physical security technology has changed significantly in the past 15 years. However, in most large organizations, the approach to deploying security technology has remained about the same-and that shortchanges Security's technology deployments department compared to what could be achieved.
One good way to start off the conversation with IT is to have an introductory meeting to explore the differences between physical security technology deployments and business information system deployments. This meeting could be a 1-on-1 with someone from the IT project management group or with a thought leader or business unit liaison contact in IT. Or, it could be a meeting with a small group of IT personnel representing business requirements, project management, network design, network and application security, and so on.
One objective for such discussions should be for Security to gain an understanding of the differences between how IT addresses technology deployment (usually with a more structured and highly documented approach) compared to how Security has addressed projects in the past. Getting an explanation of how IT approaches both large and small projects (roles, processes, working with procurement, partnering with vendors, sole source vs. competitive bidding, standards, technology lifecycle and so on) will be extremely educational for Security.
Providing IT with an explanation of security systems architecture will be very illuminating for IT, as IT personnel mostly see just the cards and readers. For example, with card access control, instead of 2,000 users needing 2,000 computers-they need 2,000 access cards for a hundred card readers. The card readers are the "end devices". The field control panels (a.k.a. system controllers) are battery-backed-up purpose-built "high availability computers" that interact with the card readers and the system server. Access control must run 24/7, and in most cases must operate in spite of power failures, so IT would say that the system has HA (high availability) requirements. Because access control is a critical system, the system server has DR (disaster recovery) requirements that would include defined backup and restore processes.