Inside a law enforcement intranet Wisconsin

Deputies, officers, clerks and volunteers all seem to have the same two questions when it comes to law enforcement paperwork. The first is, "Where do I find that form?" Which is immediately followed by, "Is this the most recent version of that form?"

Law enforcement agencies face increasing amounts of communications clutter and must compile and store a large amount of data. Forms, manuals, job announcements and executive memos need to be made available to staff at all levels and in all locations, and this can pose a variety of challenges. Many police and sheriffs' offices, for example, have satellite offices within their jurisdictions, and distances between those offices can span 10 or more miles.

To manage information and promote communication, many agencies make a network drive available and fill it with a variety of folders and sub-folders. This means the material is stored and accessible to an employee, yes. But the computerized storage system often ends up doing nothing more than forcing the employee to spend an inordinate amount of time looking through virtual forms or manuals only to find that the document he or she needs is out of date.

An intranet — a Web site inside a department firewall which serves the mission of the department and is not available to the public — can make these sorts of problems disappear. As a bonus, an intranet can be an ideal solution for departments in search of the cost-effective key to better intradepartmental communication.

How we did it

One example of the many ways in which an intranet can streamline communications and manage information better can be seen in the experience of the Office of the Sheriff of Contra Costa County. Located east of San Francisco, Contra Costa County is 733 square miles of varying terrain and includes both flat and mountainous terrain. More than 680 sworn and 300 non-sworn employees staff the sheriff's department at more than 10 office locations throughout the county.

In May 2007, Sheriff Warren Rupf asked Undersheriff George Lawrence to conduct a departmental communications survey because e-mail and FAX were proving to be ineffective due to staff rotations and work site changes. The core questions to address were:

• How well do we communicate?
• How can we communicate better?

An overwhelming majority of the 710 returned responses suggested an intranet.

The sheriff requested an analysis of the survey results, and an executive summary and slide presentation were created and presented to the department's executive group. The presentation endorsed the development and deployment of a departmental intranet, with a 60- to 90-day project timeline. The sheriff and executive group recognized the communications potential of an intranet and gave the project a green light.

At the time of that presentation, I had been assigned to the Patrol Division but was temporarily re-assigned to the Technical Services Division from October 1, 2007 through January 5, 2008, to be the project manager and develop the intranet. Our Technical Advisory Committee provided constructive input into layout, functionality and content.

My first task was to develop a project plan and define the project scope. Without a scope, a project can develop a mind of its many contributors and mushroom beyond control. This was done by using a project application that breaks down individual tasks and sub-tasks, while providing a Gantt chart to provide a visual representation of the project development. Steps included in the project scope were:

• Create an intranet development and deployment strategy with existing resources.
• Create a one-stop shop where employees can access information.
• Define a project timeline and task list.
• Identify effective content layout.
• Research existing intranets used in law enforcement.
• Develop a plan for editing and adding content.
• Develop a plan for ongoing server-maintenance and support.
• Develop an editor training plan.
• Research and plan for risk management.

By the time the project scope was defined and development started, discussions were already taking place about additional functionality in future versions.

A content management system (CMS) approach was selected as the development platform. Essentially, CMS is a way to deploy a Web site where several editors are contributing content, and a large number of files are made available to users. Generally, CMS applications can offer an all-in-one solution by providing a Web site, a calendar, forums and storage for classified materials and an image gallery. A CMS is well known in Web site-development circles and is offered in many forms. Of the CMS applications tested, including Joomla, Mambo, Drupal and TYPO3, Joomla was selected for its ease of content editing, user-friendly interface and verbose functionality.

Linux was originally selected as the production operation system (O/S). From my experience and training, Linux can be obtained free, configured to be very secure, requires little in the way of a central processing unit (CPU) or memory resources, and runs well on Windows networks. However, one of the information technology (IT) managers noted that space was available on a Windows 2003 server, which meant that no additional expense would have to be incurred with another server. The developed O/S was Windows XP (my workstation). The applications used for this project included:

• WAMP5 version 1.7.3 (Windows Apache Web server, MySQL DB, and PHP)
• Joomla 1.0.13 (version 1.5 was in development at the time of the project)

These applications are Open Source GPL license, making them free to use with copyright restrictions consideration. High consideration should be given to a Linux server running the Apache Web server application and native Linux CMS applications; they play well together and provide a very stable and cost effective intranet solution. The deployment cost for the sheriff's department intranet was zero dollars; buying Windows IIS (Web server application) and a retail version of a CMS would have cost at least $3,000 to $5,000.

After the development site was complete, it was copied to the production server. Both the development and production servers were tested by first accessing them at each of the satellite locations, then opening a page and editing content, and then viewing the revised page. Access to the intranet can be made by Internet Protocol (IP) address or by domain name using the dynamic name server (DNS). Your IT department can configure the latter.

After the design and development of this intranet was approved and produced, training commenced. Each division assigned two editors to attend an editor class — during normal work hours, to save on overtime. The training was held in the Technical Services Division classroom, which houses 12 workstations; the classroom was booked about one month in advance, and two days were selected. Classes were five hours long, with a limit of 12 students per day. The importance of the selection of the editors cannot be overstated — they will be the gatekeepers of the content and must good writers. The editors' access the editing area (control panel) of the intranet is controlled by username and password combinations, and the editors replace a single Web master position.

Using adult learning methodology, a Content Editor's Guide was created with two points in mind:

1. To provide step-by-step tutorial on how to perform tasks with text and screen-shots; and
2. To have the student editors bring their own content for practice, i.e., hands-on learning.

The Content Editor's Guide was a mixture of hands-on experience, tutorials found online and Joomla's own Web site. After the first class, as lessons were learned and unanticipated questions were asked, additional graphic and document sections were added to the guide. The Content Editor's Guide started as a 13-page document and ended up with a total of 34 pages.

The editor classes were scheduled two weeks prior to the scheduled deployment of the intranet to allow time for a learning curve, late content and Murphy's Law. Days prior to the deployment, a department-wide e-mail was created, describing the intranet, its benefits and how to access it. As with other content, the copy was proofed several times for accuracy. The copy was retained until the morning of the launch. I came in at 0630 hours and pasted the content into an e-mail and, with my fingers crossed, sent it out to all department users. Then I waited for the e-mails and phone calls to come in, with complaints of spelling or grammar errors — or, the classic complaint of the technically challenged user: "How the heck does this thing work?"

To my surprise, the only correction e-mail I received was one about a front-page edit involving a spelling change. Otherwise, the e-mails contained compliments on the content, look and feel of the intranet. I received no phone calls. The day after deployment, I viewed the statistics page and was happy to see the results: 309 visits, 3,600-plus pages viewed (more than 10 per user), average time on the site at less than 10 minutes and most viewers had their monitors configured at 1024 X 768 (a hunch I'd had in the beginning, when designing the site).

What we learned

The results of this project were sometimes unusual in project management circles in that creating our intranet solution stayed within its budget and on its timetable. Because the software used was either in place or Open Source, we incurred no software cost. Even staffing was cost-neutral, as my transfer to Technical Services Division filled a vacancy. By updating the project sponsor, Lt. Elise Warren, every two days, production changes were kept in check and deadlines were met.

After the project concluded, many learning points came to light, and I offer these tidbits of wisdom:

• Get buy-in from advocates early on in the process, preferably from chain-of-command going vertical. For instance, my first advocate was a sergeant while I was a deputy.
• To create the buy-in, create a beta version, showing how the intranet will benefit the department. In this case, the survey results garnered support along with fact that the sheriff's office had forms, manuals and procedures that were difficult to access from various locations. Because an intranet works on transmission control protocol (TCP), which is a fundamental layer of most existing networks, the user with a workstation plugged into the network can see the intranet. To access the various network servers requires network username and password combinations. Simplicity of access, combined with data consolidation, proved to be selling points.
• When consolidating the forms and manuals, locate the people in the departments who have knowledge of the whereabouts of those materials and get the most current versions for posting from them. Then make sure only the editors have control of the updating.
• Unless your agency installs a word processor application on every workstation, consider creating all forms with Acrobat PDF. The reader version is free. The user can open the form, fill in the blanks, print it out, then sign and date it so that it's ready to turn in for approval.
• Find someone internally who is technology-savvy. Credibility and department knowledge go a long way.
• When designing the main menu, have your organizational chart nearby. In our case, the menu starts out from the top down: Bureau > Division > Unit. Several sections, such as a photo gallery, department openings and manuals, should have their own main menu link as they will be highly accessed.
• Try to keep the pages no more than three clicks away from the front page.
• Make the intranet project a real project. Use a project application to create a task list and a timeline chart to stay on track. At the conclusion of the project, Warren was handed a 50-page project document.
• Be careful to keep the cat in the bag. As the word gets out about the project, lieutenants, captains and commanders will desire to have their division information immediately put on their portion of the site, even while the site is still in the development phase. Any change requests should be funneled to the project sponsor, allowing the project manager to work within the scope of the project. Warren did an efficient job of constraining the last-minute changes people attempted to make to our project and instead held new ideas for the next version of the project, which is one to two years away. Stay focused and within the project scope.
• Remember to keep images small. Our editing guide suggests 150 pixels by 150 pixels, for fast loading and server space considerations.
• Keep videos to 10 MB or so, which relates to a nine- to 12-minute play time in WMV format. A video was placed on the front page, with message from Rupf.
• Spell check, times three. Encourage editors to spell check everything. Have a few different eyes proof the material. And remember to use the spell/grammar check in your word processor. I used two clerks to review content on a regular basis.
• When the time nears for the deployment, prepare the unveiling in advance. How will you announce it: e-mail, newsletter, FAX? How will users access it?

Data consolidation is an ever-changing challenge and a focus issue for any department, but managing the data does not need to be a nightmare. Creating a department intranet can make the consolidation more manageable, easier to control and simpler for the user to locate what is needed. Almost every sworn and non-sworn employee in the Contra Cost County sheriff's department and in departments nationwide has an Internet connection at home and is familiar with how to access information on a Web site. Intranets offer a similar access but offer department-specific information.

Sgt. Ralph Brown works for the Office of the Sheriff, Contra Costa County, California. He has 16 years of law enforcement experience with assignments in training, patrol, custody, special operations and technical services. He holds a bachelor's degree in management and a master's degree in Information Systems, and he can be reached at rbrown@so.cccounty.us.