We all make choices in our careers for good and bad. Sometimes just speaking our minds will inadvertently cause a career choice. This is the story of how one such choice framed an entire information technology (IT) project.
In 1995, I was a sergeant with the Metropolitan Police Department (MPD) in Washington, D.C. At the time, the MPD had more than 4,200 sworn officers and close to 1,000 civilian em-ployees, not small by any stretch of the imagination. I worked for the Information Services Division under a visionary leader, Inspector James A. Lingerfelt. My assignment was project manager for a huge overhaul of our IT system. We hired outside consultants to guide us toward what was supposed to become a state-of-the-art environment. With a life span of several years, the project involved a complete redesign of how we conducted business in most areas of the agency, including computer-aided dispatch, field reporting, records management, prisoner processing and investigations. No stone was to be left untouched. We planned to begin by documenting every process and piece of information, data and writing an officer had to do. This process alone was to take up to six months.
The Internet was not as pervasive as it is today, but America Online (AOL) enjoyed extreme popularity. Chat rooms and what would be called newsgroups were spreading quickly on AOL. Someone brought a chat-room post to the attention of our chief. Written by one of our patrol officers, the post slammed the department for the project I was working on. I was more than upset. This officer had no clue what he was talking about, nor did he understand the intricacies of a project this huge. His allegations were based on his perceptions, not the facts of the project.
The chief directed Lingerfelt and I to meet with the officer to interview him about his public comments. I m sure the officer was nervous who wouldn t be upon getting called to headquarters by an inspector, four ranks above officer? Lingerfelt opened the discussion. We outlined the facts of our receipt of the post and the allegations made, from which the officer, to his credit, did not back down at all. Then, to the officer s surprise, we told him we wanted to talk openly and honestly about the project. Lingerfelt, as the ranking member, assured the officer that what he said in the office would stay in the office. Rank was no longer an issue. We wanted his complete and unbiased opinion. In return, we assured him there would be no lies, no spin doctoring and no politically correct responses. We would openly address all issues.
For the next two hours, we talked. We addressed his concerns from a field perspective, and educated him on the issues we faced on the support side of things. It was refreshing for him to have such an open dialogue. And it was refreshing for us to have someone willing to take a chance and let their opinion be heard.
In the months that followed, the officer became one of our best sounding boards and also one of our best proponents. Did we brainwash him? No, not at all. We just provided the information he lacked in forming his earlier opinion. He was able to speak with authority and knowledge to his colleagues in patrol. And the other officers were more apt to believe one of their own than some administrative type from headquarters.
Lessons Learned
That experience served me well and continues to be the basis for any of my IT projects. From an IT management approach, we often talk about officers who will use the technology in terms of stakeholders, end users and buy-in. These words have become so ubiquitous with any IT project their meaning is often lost, and more importantly, their value is mostly misplaced. However, it s these officers who will ultimately breathe success into your project.
Ask Questions
I now ask two questions of projects I m working on: 1) While we may be doing the right thing (according to manuals, guidelines, procedures, etc.), are we doing things right? and 2), How does what we create affect the front-line officer, detective, dispatcher, etc.?
The first question falls under the always-bring-your-2-year-old-to-work philosophy. Anyone who has had kids knows 2-year-olds are inquisitive. They ask, Why is the sky blue? Why are there clouds? Why are there mountains? If you re involved in an IT project, you should ask the same type of questions. Why are we collecting this information? How will this process improve what we currently have? Who will be affected, and how do they feel about it?
We need to encourage asking questions about projects. The questions should come from within the project team and, more importantly, from outside the team. If the project concerns traffic citations, the project team must talk with traffic officers. They must encourage the traffic officers to ask questions. Example: I was creating a citation software program for officers recently. During the rollout, I made sure officer questions were received and answered. I heard their input and incorporated it into the software, usually by the next day. As with any software, there were bugs. But because I involved the field officers, they knew they were part of the solution and took the errors in stride. The project was a huge success.
Now, the tough question, the one question I feel is not asked and answered in most projects: How does this affect the front-line officer, detective, dispatcher or whomever? How many times have we been given new technology that just doesn t work, or works poorly? If the programmer or project team had asked, we could have told them in the planning stage it wasn t going to work.
Put End Users In Charge
I ve seen many projects proceed forward without anyone asking how it will affect those who will use it. To this end, IT projects should be directed by those affected, not by those creating them. Back to my citation project. The software works smoothly because it was created by an officer who actually uses it rather than a programmer sitting in a room somewhere far from the front line. For example, citations take less than two minutes to create, and most of the options on the citation are auto-completed based on feedback gathered from users in the field during the planning stage.
Imagine creating a computer-aided dispatch system. Who should lead the project? A certified project management consultant? No! A dispatcher should lead the project. And not a former dispatcher, but one who sits in the hot seat every day. The same concept holds true for a mobile reporting system. A patrol officer should head up the project. The patrol officer has the most firsthand knowledge about what will work and what will fail. Yes, others need to be involved in the design. Detectives have their needs. Administration has theirs. But creating a system for patrol officers guided solely by the administration s needs will doom the project.
Gauge a Project's Success
Finally, how do you measure a project s success? Certified project managers will say you need to identify and gather metrics before you start the project. After completing the project, you take those metrics again and compare them to the pre-project metrics. The difference will demonstrate your success.
I have a different measuring tool, however. If the end users those officers I discussed above are happy, the project was a success. How do you know if they re happy? They ll be showing off their new software to friends in other departments, saying, Bet you wish you had this!
In Summary
The officer from the MPD and Lingerfelt left me with an extremely important lesson. That is, when given a project, don t think you know it all. Chances are, you don t, and your development vacuum will show in the final product. Ask around, seek input and listen. Take advantage of others experience from the rookie who offers a fresh perspective, to the seasoned veteran who can perform the task in their sleep. Become a synergistic manager rather than a project manager.
Chris Gebhardt is a patrol officer with the Taylorsville (Utah) Police Department, serving a city of 65,000. He serves as the IT manager for the department and created the TC Software Suite used by multiple agencies for completing traffic citations and crashes. Gebhardt was a lieutenant with the MPD in Washington, D.C., and also served in multiple consultant roles throughout the United States. He is currently completing a bachelor s degree in police management, and he writes for several law enforcement periodicals. Contact him at [email protected].
