14 Managing Network Vulnerability Assessment
in Exhibit 9 and a blank Project Scope Document is shown in Exhibit 10.)
This chapter also discusses what might well be the most important part of
project scope: how to manage scope change.
A note here about project management style and specifically about the
definition of what is “in scope” and “out of scope” in a project: some project
managers take the time and trouble to define activities, organizations, and
data that is “out of scope” (in addition to those that are “in scope”). As a
matter of personal preference, we work on the assumption that anything not
specifically defined as “in scope” is out of the scope of the project.
General Scoping Practices
Project Overview Statement
The first step in developing a Project Scope Document for any project is
drafting the Project Overview Statement, a document that we use to convince
management that our project is worthwhile and will bring benefit to the
organization. The Project Overview Statement is also the equivalent of a charter
for the project and will set out — in the broadest of terms — what the project
is about.
We must be mindful of the audience for the Project Overview Statement.
The document’s readership will include management who are not IT manage-
ment (i.e., internal audit, business unit management, compliance, human
resources, facilities management, etc.). The writing in the Project Overview
Statement must be clear, to the point, and, most importantly, free of acronyms
and technology terms. We will use language that is easily understood by the
nontechnologist.
The Project Overview Statement for an NVA should be one page, simple
in its statements, and clear in its objectives. It should contain:
Project definition: a short description of the purpose of the project and
must contain a statement of the benefit that doing the project will bring
Project goal: one or two sentences that state what problem or weakness
the project will address
Objectives: a short list of objectives that have to be met to reach the project
goal
Success factors: quantification of the benefits of doing the project. For an
NVA, the success factor can be a detailed knowledge of the weaknesses
in the organization’s network (knowledge is a benefit). Note: this section
is not intended for the “old favorite” project success factors such as on
time, within budget, etc.
Assumptions: details of the strengths, weaknesses, opportunities, and
threats involved in the project, but simplicity is the key
Once completed, the Project Overview Statement will be sent to the members
of management who have control over the budget for the project, plus others
who have oversight responsibility or a vested interest. These others may be
Project Scoping 15
internal audit, compliance, human resources, facilities management, IT manage-
ment, information security management, and the management of the business
units that use the network. Each should be asked to signal their agreement to
the content of the Project Overview Statement before any work begins.
Be prepared for the Project Overview Statement to “bounce” back and
forth a few times. Each recipient of the document may have concerns about
the wording or might be unclear about its meaning. It is our job to make sure
that, at the Project Overview Statement stage, everyone with a vested interest
understands what is going to happen, why it is going to happen, and what
the benefit will be.
The Project Overview Statement serves as a check for subsequent docu-
ments produced in the planning stage of the project. As we develop the scope
of a project, the details we put into subsequent documents must all reflect
the Project Overview Statement. That is, if we find something to be done in
the project that cannot be recognized as clearly fitting in the Project Overview
Statement, then either that task or the Project Overview Statement needs to
be changed. If we change the Project Overview Statement after all other parties
have signed it, then the document must be “re-reviewed” by all those who
reviewed the original. When the changed Project Overview Statement is sent
out for review a second (or subsequent) time, each party who approved the
original must approve the change(s).
Work Breakdown Structure or Task List
Once a Project Overview Statement has been issued for review, work can
begin on a Work Breakdown Structure (which most people recognize as a
Task List and so it is called a Task List here). The Task List is a part of our
Project Scope Document and the basis of our project plan, so doing a good
job of developing a Task List will help produce a good, manageable Project
Scope Document.
In a perfect world it would be nice to wait on approval of the Project
Overview Statement before starting the Task List but, because the Project
Overview Document might “bounce” around for some time, it makes sense
to start the Task List and amend it as changes are made to the Project Overview
Document.
Developing a Task List means breaking down a piece of work into its
component tasks. While this sounds easy enough, there are some other
considerations when creating a Task List. These considerations include:
Task status must be measurable.
Each task must be a clearly defined event with a clear start and a clear end.
Every task must have a deliverable.
For example, if we were to define a Task List for building a house, the
actual construction part (once a foundation is established) might look similar
to Exhibit 1. Notice what is not in our Task List at this point:
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.