“As a result, … deterrence … [is] less effective than … self-control and moral belief … in shaping individual behavior.” Does Deterrence Work in Reducing Information Security Policy Abuse by Employees? Communications of the ACM June 2011, pg 54.

Project management is often about getting people to do the things we need them to do. This is true in both the management of the project and in implementing the project’s objectives. Often, projects that are completed attempt to improve human processes or otherwise attempt to influence personal practices and behaviors towards more productive and effective practices. “Deterrence” is about letting folks know what the consequences are if certain practices are not followed.

I was managing an organization of about 100 software engineers. Everyone had their own personal computers or workstations. I got a call from Human Resources (HR) asking me about one of the individuals in my organization. The conversation concluded that we were going to have to fire this person. Why? ” It appears he had been visiting pornographic websites through a company PC, which was, of course, a violation of company policy.

Open and shut case, yes?  Maybe.  I asked HR when was the last time we reminded everyone that company equipment was to be used for business purposes only (with reasonable exceptions).  She told me that it was in the employment agreement that everyone signed when they came to work for us. She said we don’t remind people they shouldn’t visit XXX sites because that is pretty obvious and doesn’t need repeating. She also said that Information Technology (IT) had just installed software that allowed HR to monitor sites people were visiting. I asked if anyone else knew that HR was doing this kind of monitoring and she said no. Again, her logic was that the monitoring had no impact on anyone unless they were doing something that was against company policy, and since everyone should be following company policy, there was no need to tell anyone about the monitoring.

I had spent 20 years in the US military, where we had some pretty strict policies and draconian consequences for violating them. So this relaxed approach to reminding people of policy and consequences just didn’t strike me as trying very hard to ensure everyone followed policy. I told HR that I would look into it and get back to them.

The first thing I did was send out what I hoped looked like a routine message that reminded everyone that company PCs were for business use only with approved exceptions. I reminded them that failure to follow the policy was grounds for dismissal. I also said that PC use was subject to monitoring to ensure the policy was being followed. I then called the manager of the individual who HR had brought to my attention and told him he needed to investigate and talk with the individual.

Did he get fired? No.  Did he violate policy? Yes.  Was he reprimanded and put on notice that he could be fired? Yes.  Did this scare the heck out of him? You betcha. Did he ever do it again? Nope.  In fact, HR admitted that a lot of computers were showing some visits to proscribed sites. The individual brought to my attention just happened to have the most, and so they were going to start with him in enforcing the policy using their new monitoring software.

What happened after my reminder communications on this policy?  HR said that the number of PCs visiting proscribed sites dropped to almost nothing in my department. Also, people would go running to HR and say, “sorry, I clicked on a link in what I thought was a friend’s e-mail and it sent me to a XXX site!” The IT department, upon investigating, confirmed that people were receiving a lot of socially engineered e-mails attempting to send them to questionable sites. HR was not aware that this was happening. The whole nature of what were “policy violations” changed character and took on a focus of increasing security (filtering external e-mails, awareness education, etc.).

The project management lesson, in this case, was that we often need to routinely remind people what it is we are doing and what they should and should not be doing. This includes project plans, standards, milestones, and the like. This case illustrates what we probably already know and that if we don’t over-communicate what folks need to know, then we shouldn’t be surprised when people don’t do what we want them to do. We need to remind our teams, regularly, about what it is we are doing and why we are doing it.

The findings of the study quoted above surprised me when they suggested that “deterrence” doesn’t work as well as finding people with strong ethical and moral behavior. Maybe I’ve always just had good teams (many multinational, multicultural, and multigenerational), but this didn’t seem to match my own personal experience of the effectiveness of regular communication. It also reminded me that the best study is the one we conduct within our own organization.

As in the case above, regularly communicating what we want people to do and what they shouldn’t do made a significant difference in their behavior. It also alerted us to other problems that were not obvious in the monitoring data we were getting. It reminded us to not underestimate the simple power of regularly communicating to people what it is we want them to know and do.

How consistently are you communicating what people need to know on your project?