Will you survive your current or upcoming security technology project with your organization’s security capabilities, your personal reputation, and your job status fully intact?
A great many security technology projects are late. And many of these do not accomplish what they were intended to. Large organizations with IT departments that have well-established project management 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” and “academic”—and thus not seriously 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% complete” in spite of the advance of the calendar—and often are declared “complete” by compromising with what the stakeholders actually wanted to accomplish. (If you are in the midst of such a project now, head over to the Troubled Project Checklist page.)
Based upon your organization’s past security deployment experience, would you comfortably bet your job on a 100% 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 Lessons Learned below probably includes some good ideas that you didn’t think to incorporate in your project—or didn’t know that you could.
Lessons Learned
You learn a lot when 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 appropriate 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 about project scope or results requirements, 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% complete. It can take a bit of backbone to refuse to close out the project phase until it is provably 100% complete. But failure to do so can 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% up to requirements”.
It’s not done if its only 90% done. Progress payments must be tied to project milestone demonstrable “100% complete” status.
Payment milestones are a key control mechanism for large projects. Don’t lose control of the project by accepting “almost” results.
Don’t pay 90% of a progress payment and expect the 10% 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% 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. Such as technology defects, backordered products, customer task delays, bad weather, and so on. This means that 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. This is another important element of project control. 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 customer’s project team (whether employee or consultant), and this individual must not be the project leader or manager or member of the installing contractor’s team.
Approaching Projects Effectively
An effective approach to technology projects takes into account the above factors and many more. Such key project success factors are presented in the Security Tech Project Survival Test page.
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.
The Security Tech Project Survival Test is based upon in-depth study of deployment projects involving today’s complex physical security system technologies.