255 lines
12 KiB
Plaintext
255 lines
12 KiB
Plaintext
|
||
|
||
|
||
POINT OF VIEW
|
||
A MANAGER'S GUIDE TO COMPUTER PROJECTS
|
||
|
||
By
|
||
|
||
Charles Brennan
|
||
Inspector
|
||
Information Systems Division
|
||
Philadelphia, Pennsylvania, Police Department
|
||
|
||
|
||
Increasingly, police managers find themselves placed in
|
||
charge of computer projects within their departments. Many feel
|
||
ill-equipped for the task because, although they know the
|
||
operational side of their agencies very well, the technical
|
||
aspects remain, in large part, a mystery. It is easy for even
|
||
the most attentive manager to become lost at meetings,
|
||
understanding little of the technical jargon and having to make
|
||
decisions without a full understanding of all the facts.
|
||
However, this need not be the case. Managers can take a number
|
||
of steps to help ensure that technical projects will be
|
||
completed successfully.
|
||
|
||
PROJECT MANAGEMENT
|
||
|
||
A large-scale technical project requires a project manager.
|
||
This person should be of sufficient rank or standing in the
|
||
department to make almost any decision independently once the
|
||
job begins. A full-time manager is best, and many
|
||
hardware/software vendors suggest that the department assign an
|
||
individual solely to this task, since the project manager is the
|
||
primary contact between the vendor and the department.
|
||
|
||
TECHNICAL KNOWLEDGE
|
||
|
||
Those assigned to a computer project who have no technical
|
||
expertise at all must develop at least a working knowledge of
|
||
computers. A recommended source is introductory courses at a
|
||
local university. In addition, there are many books that
|
||
explain both computer terminology and the operational aspects of
|
||
the computer. A thorough understanding of the terms is
|
||
especially important, since project managers must be able to
|
||
comprehend what is discussed at meetings that they will be
|
||
required to attend. But no matter what the technical
|
||
background, it is important to make sure that meetings with
|
||
vendors operate at the project manager's level of understanding.
|
||
Vendors want to retain customers, and therefore, will take the
|
||
time to explain the technical aspects in laymen's terms. If any
|
||
fail to do so, the best course of action may be to consider
|
||
another retailer. However, such issues should be dealt with
|
||
before issuing a contract for products or services.
|
||
|
||
For large and complex projects, however, it is advisable to
|
||
have some independent technical assistance. If the department
|
||
has an in-house technical staff, they may provide all the help
|
||
needed. If not, the city or county may have technical resources
|
||
available. In any case, the technical team assembled should
|
||
work closely with vendors providing equipment and software.
|
||
|
||
PROJECT GOALS
|
||
|
||
Every project has goals that must be satisfied, and computer
|
||
projects are no different. The project manager must understand
|
||
each one and how they affect separate entities within the
|
||
department. For example, in large departments, the installation
|
||
of a computerized records management system must satisfy the
|
||
specific needs of many departmental units. It is important to
|
||
realize from the outset that the system eventually put into
|
||
place may not satisfy everyone's expectations. But, one of the
|
||
manager's most important duties is to meld all of these
|
||
seemingly competing needs into what is both practical and
|
||
possible for the entire department.
|
||
|
||
ADMINISTRATIVE SUPPORT
|
||
|
||
Department administrators must understand and support the
|
||
project. The head of the agency will certainly be aware of the
|
||
implementation of a large-scale computerization project, but may
|
||
not fully understand the impact the project will have on the
|
||
department. For example, the installation of a computer system
|
||
may require changes in departmental procedures, personnel
|
||
allocations, and other fundamental aspects of the department's
|
||
operation. The chief administrator should be kept aware of the
|
||
project's progress, as well as what departmental changes will be
|
||
necessary, through regularly scheduled status meetings.
|
||
|
||
TIME TO PLAN
|
||
|
||
Proper planning is probably the single most important
|
||
factor to computerize a department successfully. For every hour
|
||
spent in good planning, 10 hours of aggravation can be avoided.
|
||
The project manager should take time to enlist the assistance of
|
||
employees and designate tasks. One way would be to form a
|
||
committee to guide the project. Another consideration is to
|
||
assign tasks, responsibilities, and timetables so that everyone
|
||
knows what jobs must be done and who must do them.
|
||
|
||
Potential repercussions for the agency should be
|
||
anticipated. For example, the introduction of personal
|
||
computers (PC's) in an agency goes beyond just buying the
|
||
machines. Such a purchase raises questions: Who will fix the
|
||
equipment? What about training? Are there certain procedures
|
||
governing their use or the information they contain? Other
|
||
issues regarding specialized programs and additional software
|
||
must also be addressed eventually.
|
||
|
||
Every computer system needs support that requires resources
|
||
and personnel. And, while a computer system may reduce the
|
||
number of people needed for a certain task in one area, it may
|
||
increase the personnel required in another.
|
||
|
||
RESEARCH
|
||
|
||
In any computerization project, there will invariably be
|
||
problems encountered and problems to be solved that have the
|
||
potential to be overwhelming. New software packages
|
||
particularly are subject to problems. Testing in the "lab"
|
||
cannot adequately duplicate real life conditions. Therefore, if
|
||
an agency is the first to install a package, it may be faced
|
||
with complex problems to which there are no known solutions.
|
||
Essentially, the department will be tasked with solving the
|
||
problems for all departments purchasing the package thereafter.
|
||
This could prove to be not only inconvenient but also very
|
||
expensive.
|
||
|
||
There are two conditions, however, in which this general
|
||
rule may be disregarded: 1) If a vendor offers a substantial
|
||
discount, or 2) if the software is so unique and innovative that
|
||
it cannot be purchased or tested elsewhere.
|
||
|
||
USER INPUT
|
||
|
||
One of the biggest mistakes that could be committed in any
|
||
technical project is not to involve the users in all phases of
|
||
development. No one understands the job better than those who
|
||
have been doing it for years. Shortcuts that have been
|
||
developed over time to "work around" problems could be missed if
|
||
no one is consulted on "how it is done." And, making changes
|
||
later to accommodate these procedures could be expensive. Only
|
||
by involving those who will use the program can project teams be
|
||
certain to develop a system designed for the job.
|
||
|
||
THE RIGHT VENDOR
|
||
|
||
If planning is the most important facet of a technical
|
||
project, then choosing the right vendor is next. Although there
|
||
are no rules for vendor selection, there are certain guidelines
|
||
that should be followed.
|
||
|
||
* Contact Other Departments
|
||
|
||
Every potential vendor should supply a list of clients
|
||
who have installed similar systems. The project manager
|
||
should take the time to contact a random sample of these
|
||
clients to ask questions regarding the workings of the
|
||
programs, problems encountered, and advantages and
|
||
disadvantages of the system. The project manager should
|
||
prepare a list of questions so that all important points
|
||
are covered. Most departments are willing to share
|
||
information about the reliability and performance of
|
||
vendors.
|
||
|
||
Some vendors may claim that they are "business partners"
|
||
with a larger computer firm; however, this does not mean
|
||
that the larger company guarantees the vendor's products
|
||
or software.
|
||
|
||
* Make on-site visits
|
||
|
||
The best way to see if vendors can do what they promise is
|
||
to make a site visit. Before selecting a product or
|
||
service, it is important to see it in operation. If at
|
||
all possible, the police department using the product or
|
||
service should be comparable in size to the one
|
||
considering the purchase. Again, the project manager
|
||
should plan for any site visits by formulating questions
|
||
and determining what functions are important.
|
||
|
||
* Judge vendors by the same criteria
|
||
|
||
It is important to judge every software package or
|
||
product by the same standards. This can be done by
|
||
creating a matrix with vendors listed down one side of
|
||
the page and the different criteria listed across the
|
||
top. By placing an "X" in the column where the vendors
|
||
meet the criteria, the project manager will have a
|
||
simple and easy method to evaluate vendors and to
|
||
determine which ones meet the standards necessary for
|
||
the project.
|
||
|
||
PROBLEM LOG
|
||
|
||
All problems encountered in completing a major technical
|
||
project should be relayed to one individual. This individual
|
||
should record the problem, who reported it, and how, or if, it
|
||
was resolved. Among other things, a problem log ensures that
|
||
all issues are communicated to the vendor centrally and in the
|
||
same format each time.
|
||
|
||
SAFETY NET
|
||
|
||
In a complex project, it is very important to construct a
|
||
type of safety net that would anticipate upgrades and factors
|
||
overlooked during initial program development. This is
|
||
especially true if the project involves the purchase of
|
||
software. A good safety net for this type of project is to
|
||
include a provision in the contract that requires the vendor to
|
||
provide a certain number of programming hours to "enhance" the
|
||
purchased software. In many cases, the enhancements are changes
|
||
required due to circumstances not anticipated when the software
|
||
specifications were given to the vendor. It is imperative to
|
||
remember that certain manual procedures may not translate easily
|
||
or cleanly to an automated format. The larger the project, the
|
||
more likely things will be missed. Unless provisions are made
|
||
ahead of time, changes to the original specifications may
|
||
require additional resource outlays.
|
||
|
||
IMPLEMENTATION
|
||
|
||
Once a new system is implemented, there is the impulsive
|
||
tendency [to] "get it up" and have everyone using it
|
||
immediately. This tactic usually only confuses the users and
|
||
breeds frustration. If the system has many different
|
||
components, it is a good idea to introduce them gradually, to
|
||
ensure that all users are operating at the same level of
|
||
understanding before moving forward.
|
||
|
||
If possible, it is also advisable to test the system in a
|
||
small segment of the department before releasing it for general
|
||
use. This will allow time to gauge the reactions of a small
|
||
sample group in a controlled area. It is better to find
|
||
problems here and correct them before everyone begins using the
|
||
system.
|
||
|
||
CONCLUSION
|
||
|
||
Technical projects require planning and forward thinking.
|
||
But, even the most complex projects can be successfully
|
||
completed if certain guidelines are followed. While some
|
||
technical background, or at least familiarity with computer
|
||
terminology, is important, a comprehensive, well-defined
|
||
approach is invaluable to complete a technical project
|
||
successfully.
|
||
|
||
---------------
|
||
"Point of View" is a forum for law enforcement
|
||
professionals to suggest recommendations to improve police work.
|
||
Submissions for this feature should be no more than 750 words,
|
||
typed, double-spaced, and forwarded to Editor, FBI Law
|
||
Enforcement Bulletin, Room 7262, 10th & Pennsylvania Ave., NW,
|
||
Washington, DC 20535.
|
||
|