Project Management

• By Dennis Adamkiewicz
• Jun 01, 2013

I recently participated in a webinar titled Industrial Security in the Real World: Practical Steps, which indirectly discussed how some fundamental tenants of project management were applied to this topic. The presentation was sponsored by Automation World and led by two staff members of Belden. Belden is a company focused on communication, and the webinar concentrated on security and communications equipment in an industrial environment.

The presenters discussed three topics that are the cornerstones of project management practice—stakeholders, definition and change. This led me to consider how project management techniques might apply to the area of security in general, regardless of the chosen technology. Beyond the definition of terms, it is helpful for team members participating in a project to understand some of these fundamental project management concepts and how to incorporate them to make a project successful.

Project managers focus on three elements of a development: budget, utility and schedule, where utility is the functionality incorporated in the project, whether it be a physical security or an IT project. Usually— and some would say at best—a project manager can help a team optimize two of these elements. Engineers appreciate the necessity to make similar trade-offs; for example, an electronic design will have to balance the trade-offs between running at a faster speed and the power consumed to run at that speed.

When looking at the elements of budget, utility and schedule, the tradeoffs are more fluid. While there are a number of reasons for this, it is partly due to the participants or stakeholders on the project.

Unlike the final customer, all stakeholders may not be have daily involvement in a project, but it is important to get all of them to agree on the priority of project goals. This aspect of a project consumes a great deal of energy. It is not uncommon for teams to have divergent and energetic opinions on which elements are most critical. A classic tool that I have recently used to help a project team arrive at consensus is a decision matrix.

What It Is

The decision matrix defines individual requirements to the stakeholders. After the requirements are defined, the stakeholders determine the importance of each element. This is done by assigning a weighting for each element as agreed to by the stakeholders. The weightings are tallied and the result will provide the priorities of the project.

One of the most recent projects I worked on used the decision matrix to help the team define what features were to be created and when they would be tested on a communications module. This empowered the team to set the project priorities and had a direct relationship to the schedule and budget. For those who are not familiar with this technique, I recommend that you go to the ASQ Web site for a description of the process.

The decision matrix should be used at the outset of a project, particularly if there is significant disagreement between the stakeholders. The initial stage of development is critical, for without a well-described definition and proper resourcing—funding and staffing—a project is doomed to struggle at best, or in the worst case, fail completely. One of the most glaring examples of such a situation, with respect to national security, is the fence to prevent illegal immigration from Mexico.

Frequently, a crisis will influence team members to determine the solution before reflecting upon the requirements and constraints of the project. This is a situation where the decision matrix can be useful to quickly determine the importance of each of the requirements. As part of a definition document there should be descriptions of features that have been discussed or eliminated; these should remain in the documentation to let others know the thought process used to gain consensus.

Adjusting to Change

The decision matrix also is useful when the project must adjust to change that will occur during the life of the project. Change is inevitable, and while some change is unexpected, such as the attacks on 9/11, some changes can be anticipated and should be addressed in the definition of a project. A colleague of mine has an expression: “They pay me to put it in; they pay me to take it out; they pay me to put it in again.”

This indicates that some stakeholders will start with optimistic goals for schedule, utility and budgets and will revise those requirements as pressures are applied or conditions change. In the case of the networking security Webinar, the presenters described how to connect the network to allow for expansion in the future as conditions changed. This is another way in which the decision matrix can be used—to think through potential changes that may occur in the future.

While all security projects have their unique requirements and constraints, it is important to recognize that there are common aspects to all projects. Techniques such as decision matrixes will help to define parameters, set goals and determine the impact of change of a project. Analysis provided by the decision matrix can establish the stakeholders’ understanding and set the project’s direction.

This article originally appeared in the June 2013 issue of Security Today.