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: