Article Archive Details
Hendon Publishing

Automation solutions for law enforcement

Planning, managing and implementing large-scale, high-cost law enforcement technology projects, such as automated fingerprint identification systems, computer-aided dispatch and records management systems, or radio system projects, require a working partnership between command staff and information technology staff, careful attention to detail, and approaching such projects with a business-like demeanor. That will help an agency avoid risks and save money.

Explaining how to do just that in dealing with vendors, contract issues, and the process of purchasing and managing new automation projects was Ronald H. Jayne, President of Innovative Technologies, Ltd., Glen Ellen Calif. Jayne was the instructor at a California Peace Officers Standards and Training (POST)-certified training seminar hosted by the Hemet, Calif. Police Department. Jayne began his career as a police officer. Later, he turned to the vendor side of the law enforcement field, becoming president of two law enforcement software development firms. Currently, he owns Innovative Technologies, Ltd., a justice information systems and technology firm. He is also a technology instructor for the California Peace Officers’ Association.

Jayne said an agency must focus on the processes and ideas that help it successfully complete a new automation project on time and within budget. That means considering the resources, funds, interest levels, education and experience of the personalities involved, and the politics of everyone’s interaction. Factors such as these, along with patience and motivation, can spell the difference between failure and success of a new project.

Jayne cited surveys of U.S. law enforcement agencies that have indicated that 32 percent of all projects are cancelled before they are completed; 53 percent cost over 200 percent of the original estimate; 84 percent do not meet the agency’s expectations; and fewer than 10 percent finish on time and within budget. He said such findings indicate that agencies might be awarding bids prematurely, without careful consideration of the process, or are not using expert advice that could protect the agency from mistakes. Problems can erupt anywhere—in the sales cycle, the RFP or proposal process, the vendor or product selection process, contract negotiations, implementation, and/or during maintenance of the system installed. But Jayne added that many problems actually begin BEFORE vendor or product selection because there is too much variance in the expectations of the people involved (or to be involved) with the proposed project. The agency’s expectations must be defined fully, and there must be recognition that motivations will differ between the agency and the vendor, thus affecting cost, risk and deliverability of a project.

Every detail must be examined closely, he advised. For example, if a contract or vendor says that updates to a system or its software will be “provided”, the agency must be sure that such updating also includes installation of those updates or, at least, a plan for future time and materials costs if installation is not included over the long term. “See if on-site installation of future updates are included in the contract,” Jayne said. “The agency must examine the contract and discuss the issue early in the process,” or else there will likely be added costs. Watch for third-party providers because equipment obtained from them through your primary vendor may be sold “as is”. Terms of system acceptance could come with a defined date—a forced acceptance—even though there might still be problems with the new equipment or there are portions of the project not yet completed. That, too, could mean more money to fix the problems, after acceptance has already occurred.

Such small, but important, details have to be considered. Don’t be rushed by the vendor, Jayne advised. Some vendors tend to create “unrealistic expectations early in the sales cycle,” he said, and, if the product does not live up to the agency’s expectations, the project may be in trouble. Many people in the agency will be impacted by a project—dispatchers, analysts, patrol officers, administrators, etc. They probably have very different expectations about a project, so their views should be considered early in the project. The agency must define what it wants and what it expects.

Some vendors have a sales process that is often “cookie cutter” in its approach. Agencies are often led to think that they will be getting a good deal at a right price, and a “plug and play, and load it and go” ease in implementing the new project. Such is often not the case. The “meeting of the minds” has to be done for a project to succeed.

“Project methodology” is a term often used in the private sector, explained Jayne, and it relates to the impact of risk, cost and results in a project. The project methodology is akin to the steps of a ladder and each one must be scaled before the next one is taken. The project methodology is your road map to project success. Negotiate a project methodology that works for both sides and the agency will avoid a wide array of issues and problems. “Understanding vendors, how they are motivated, and why they make the decisions they do offers us some insight and ability to negotiate those positions in order to create a more balanced relationship in the contract we sign,” Jayne said. The sales department is responsible for generating new revenue, and the operations department is responsible for installing the systems sold. And, the reality is that sometimes they are at odds with each other over how a system should be implemented.

Remember that the vendor’s company is represented by the sales department during the initial phase of the relationship. Except for very small companies, the agency is not likely to see operations (installation) personnel at its site during the sales process. Sometimes vendors do things we don’t understand,” said Jayne. “It is an issue of business, risk and profit margins, not necessarily one of dishonesty.” Remember that motivation factors differ between vendors and their clients.

The vendor wants a sale and will often present the entire product line during a demonstration, or in the text of a request for proposal, but that may not be what is priced in the pricing document of the proposal. Sales personnel (sales people, sales managers, sales directors and the vice president of sales) are often paid a base salary and a commission, of course, but they are also often on a quota, reminded Jayne. If that quota is not met over time, their employment could eventually be in jeopardy. Such pressure often impacts priorities, decisions and methodologies, which can lead to problems in the buying process.

When an agency is considering a vendor’s product, there will be a demonstration of how the vendor can meet the needs of the agency. That product demonstration may not be comparable to what is actually installed. Instead, the demonstration will likely show ALL aspects of a system’s potential, which is not necessarily what is actually sold to the customer. An agency has its expectations increased during such a sales presentation, but it won’t be hearing the cost emphasized during the sales presentation, or the necessity of purchasing additional components to make the system installed comparable to the initial product demonstration, said Jayne. It is often a result of “selective information suppression” and it impacts the product demonstration and the expectations of the agency by sometimes often appealing to emotions.

Vendors want “happy” customers so that the vendor receives good referrals. Some vendors only make minor issues a problem so that there is no jeopardy to the sale. The vendor may be taking good notes during discussions with the agency, but sometimes those notes can “disappear,” said Jayne.

“With the cards stacked against us, how can we turn the tide and create a more balanced relationship with our business partner?” he asked. Only by taking the time to create a functional plan that works, and developing a project methodology that works for both sides, he said, adding, “Dig a little bit deeper.” What the vendor says will probably sound good, but be sure it makes sense. Ask questions, but also know what questions to ask, such as whether components are coming from a third party manufacturer. Make decisions only if you are being analytical, not emotional, in the process, he emphasized.

Asking the vendor to post a performance bond may be highly desirable, especially for high cost, high profile projects. It is a negotiable item and the bond should be for 100 percent of the total contract price. A performance bond is not required for every project, however, and some smaller vendors with a low sales volume may not be able to get a bond at all, Jayne said. But even the high sales volume vendors may try to get an agency not to require a bond, especially if they are not “bondable” due to poor performance on other projects. A performance bond is a form of “insurance” for the agency to enforce the terms of a contract. If the contract is poorly written, or offers no way to enforce the bond, the bond becomes an expensive, useless tool. The performance bond should start at the beginning of the project and remain in full force and effect through to the final acceptance of the system.

Commercial off-the-shelf or “COTS” is a term that tends to be highly overused in the law enforcement market. Although COTS is a term that has been used successfully in the private sector for applications such as word processing, spreadsheet, or even some database management software, it is mostly misused, however, for highly complex, high cost law enforcement computer systems that involve complex, custom-designed interfaces or extensive custom software development.

Consider all the steps of a project, Jayne reminded. There must be project organization, project planning (scope vs. budget), master planning, feasibility studies, requirements analyses, the request for proposal, product and vendor evaluations, vendor selection or bid award, contract negotiations, implementation, a warranty period, and annual maintenance. “The process is familiar,” said Jayne. “It is the details of that process that must be changed if we are going to control the outcome of our project.”

Visiting a vendor’s headquarters may be prudent. The sales presentation will certainly give a perception of the vendor, but it may not be the full reality about that vendor. Traveling to the vendor’s headquarters allows the agency to see the documentation department, visit the support department, and see whether the sales presentation accurately represented the resources available from the company under consideration. Also be aware that some companies are subject to corporate buyouts. For example, a smaller company that is actually owned by a larger one might be sold off in the near future, to save the larger company more money. That could mean loss of a warranty or future service.

If an agency uses the help of a consultant with its project, it is wise to see if that consultant gets referrals from vendors or works with certain vendors. That could spell a conflict of interest, which could mean problems for the agency.

Have your vendor identify preexisting conditions. The vendor should do a complete review of existing equipment, the existing network, the facilities, etc. and identify any components that would impede the new system’s successful implementation. Being aware of pre-existing conditions is important, but it is up to the agency to remedy them.

A project for a vendor consists of costs and profits. These are often referred to as “hard dollars” and “soft dollars.” Finding creative solutions to complex problems often requiresd knowledge of hard dollars and soft dollars so you know when and how to negotiate with a vendor. Ask a vendor to waive all costs for a server and there is a direct cost (hard dollars) to the vendor to provide that server. Ask a vendor to reduce a software license fee (soft dollars) by $30,000, however, and you are asking him/her to reduce their profits, not absorb a direct cost. There is a difference, said Jayne.

Priorities will impact a project. These differences in priorities can affect a project just about anywhere. For example, some vendors want the warranty to begin when the implementation contract is signed,; or within a fixed number of days after the contact is signed (regardless of whether the installation is completed or not, or whether defects are remedied or not). For the agency, that means that the warranty is running concurrently with implementation—sometimes even before the system is actually in place! This is an added, unreasonable expense for agencies and should be negotiated with every contract. It is written in the vendor’s draft agreements—documents that are often included with the vendor’s proposal, but are never read by the agency until after bid award. “Read the vendor’s contract early,” said Jayne. Identify the major issues before you award a bid, not after. And be patient. Doing a project takes time and effort. Be certain you set a more realistic timeline for what is done and what is to be done.

Have a project sponsor or director who attends all monthly meetings and who will serve through the duration of the project. The project sponsor should be at a high enough level in the department so that policy and cost issues can be easily addressed, advised Jayne. The sponsor hears status reports, problems about the project, and issues to be resolved, and is the conduit to the police chief, the sheriff, and the city manager or county administrator. “The project sponsor must own the project,” said Jayne. Policy, workflow and perhaps even personnel will change with the project so the project sponsor must keep aware of the cultural and operational changes, need for personnel or resources, and the money involved in the project.

Also have a project manager who is given a reasonable amount of authority equal to the level of responsibility you are asking him/her to assume. This person should have a strong interest in the project and in technology, said Jayne. This person will be responsible for all day-to-day project activities, and should understand how law enforcement workflow now exists and how it will change with the new system. The manager must have a “deep interest in bettering the department,” Jayne said.

If the project involves various personnel of the agency, there must be a project team. As appropriate to the specific project, the team might include a supervisor, records personnel, patrol or field officers, finance personnel, property representatives, detectives, crime analysts, information technology personnel, etc. In other words, it represents those most impacted by the project. Meetings of the team should be held at least monthly, and tasks should be identified and responsibilities assigned. “Be aware of time and resources,” though, Jayne advised, because, for example, some users may need to be present at a product demonstration, but might not be needed for meetings about networks or installations.

“The scope of the project should equal the funding available,” said Jayne. Project planning involves both. Balance available funds with what the scope of the project will be. Changes in scope may mean changes in funds. “You don’t have to have every dime to do a project. You can phase things in,” he said, depending on the needs and requirements of the agency.

The master plan document should identify the initial scope of the project, problems to be resolved, funding for the project, and project organization. It should include the project methodology for the project. It identifies, at a high level, the steps to be done and the time in which to do them. “Project schedules do change over time,” said Jayne.

Stay analytical, pay attention to detail and let each step build on the one before it, he recommended. Create a conduit of input to allow those affected by the project to be part of the project. This will greatly enhance user acceptance of the system installed. Know what the expectations are, and what can be afforded by the project. Do interviews in the agency. Investigate vendors. Validate and verify if the project is, in fact, feasible. Get bid estimates and quotes. Talk in detail, not generalities. When conducting a requirements analysis, focus on functional requirements for the new system, but don’t forget the more complex areas of an implementation (e.g., interfaces, training requirements, data conversion, workflow changes to come, geo-file build and maintenance, etc.). These are often ignored until it is too late and, then, costly change orders become the norm.

Project planning documents (master plan, feasibility study, requirements analysis, etc.) lead to development of the request for proposal. Budget requirements are based on the feasibility study— validating the scope, and finding what the funding requirements are. When the RFP is out, consider all qualified candidates. Clarify issues, in writing, when the RFP and the vendor’s proposal don’t match. When negotiating important documents, changes should be tracked in electronic form, on disk and with hard copy. The contract determines what will be delivered, not the RFP, and certainly not the vendor’s proposal, said Jayne. Define requirements accurately and understand the importance (or the diminished value) of each project document as a project matures.

As a project progresses, keep track of training, demonstrations of new versions of software, testing of the server, work flow analyses to review all forms and how they will change to comply with the system, software licenses, hardware configurations, upgrades, interface configurations, price adjusting, change orders, data conversion, etc. It will be a big list, but each detail needs attention to keep the project within expectations—and budget. Updates to the system should be included in the contract throughout the installation process and only “freeze” the configuration when the system is complete and ready to go live. Jayne pointed out that other customers are receiving updates and those updates should be a part of all new installations, not just something for existing systems, and they should not be delayed unnecessarily by the vendor nor should they be used as leverage to ‘force” the agency into paying maintenance prematurely, just to get an update.

After the project goes live, go to a final acceptance test period in a live, operational environment for a reasonable period of time and require reproducible defects to be remedied as a condition of acceptance. Jayne concluded that time should not be the priority over quality. “A contract with a vendor is a business relationship, not a personal one. Remain analytical, fair, focused on detail, and negotiate a project methodology that works for both sides,” he advised. Only in that way will you significantly increase the possibility of the success of your project.

Published in Public Safety IT, Jan/Feb 2011

Rating : 6.2

Related Products



No Comments

Related Companies

Article Images

Click to enlarge images.

Close ...