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.
Here are some common IT project elements and what they can relate to for security technology deployments:
- High-level business requirements: short and long term strategies, future concept of operations (CONOPS in the military), regulatory compliance fall into this category
- Business case: the business case captures the risk mitigation aspects, as well as TCO (total cost of ownership) for the technology, and the hard and soft ROI for the technology investment
- Functional requirements: these are requirements relating to security operations functions such as specific reports needed, interaction between access control and video systems, performance requirements (such as turnstile throughput, full duplex rather than half-duplex intercoms, access control elevator button activation time), as well as DR/HA requirements
- Technology requirements: these include industry standards, corporate standards, support for legacy devices, integration and interoperability requirements, expected product life cycle, as well as system and application architecture
- Network requirements: Quality of Service (QoS), subnetworks, VPNs, Virtual LANs, Power over Ethernet (PoE), and bandwidth requirements are in this category
- Security requirements: as critical systems, there are physical and logical access requirements as well as computer and network security requirements; usually there are corporate information security policies and standards that apply
- Deployment staging: will a staging platform be required to test the initial deployment and upgrades before they are put into production use?
- Testing: proof of concept, initial acceptance (readiness for deployment), operational acceptance (30-day ongoing test), and ongoing testing often apply
- Risk assessment: what are the risks to the IT infrastructure posed by currently installed technology and candidate technology being considered?
If IT is providing support, then there may be two service level agreements (SLAs): one with the security systems integrator and one with IT.
Most successful collaborations with IT begin in exploratory mode, and then become oriented around specific needs or projects. For small projects, see if there is an "IT Lite" mode that can be applied or developed. IT can offer a wealth of resources, some at no cost and some for less than it would cost for an outside firm or systems integrator to provide. When IT becomes Security's force multiplier, a few people in Security can in effect accomplish the work of many, and to an appropriately high standard.
If you have convergence experience you want to share, e-mail your comments to me at ConvergenceQA@go-rbcs.com or call me at 949-831-6788. If you have a question you would like answered, I'd like to see it. We don't need to reveal your name or company name in the column. I look forward to hearing from you!
Ray Bernard, PSP, CHS-III is the principal consultant for Ray Bernard Consulting Services (RBCS), a firm that provides security consulting services. Mr. Bernard has also provided pivotal strategic and technical advice in the security and building automation industries for more than 23 years. He is founder and publisher of The Security Minute 60-second newsletter (www.TheSecurityMinute.com). 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 Subject Matter Expert Faculty of the Security Executive Council (www.SecurityExecutiveCouncil.com).