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.