Avoiding Non-compliance

If you’ve built yourself a good process and proved that it works, you want people to follow the process.  You know that it makes a difference and it is really frustrating when people continue to cause problems by not doing “what’s best for them.”  Like a couple of prior posts, this one is about why people don’t do what you want them to do.

 I’ve already been down the People Are Selfish road so I’m not going to rehash it.  Let’s take that for granted.  Today I wanted to give you another option for getting people to do what you know to be the right thing.

Here’s the idea, and it’s super-simple.  Make it easier to do the right thing than the wrong thing.  “What!?!?” you say, “I’m not paying for that kind of advice!”  Of course, you don’t pay me anything, so…

When process compliance is a problem, you have to look at what it takes to get the process right.  Going back to that people are selfish (and lazy) thing, if there’s a shortcut to be taken then people will take it.  If taking that shortcut hurts the performance of the process, then you must make it hurt more to go down that path than to not. 

Take, for example, my old team at my last job.  No software developer likes writing documentation (or thinking through a problem) and they want to get right down to coding.  I already knew that this was going to be an issue.  The process I had designed worked because it relied on peer review to assure that everything was getting thought through.  That also meant that being sloppy was not an option for my employees.

Why were people sloppy?  Well, they figured if they didn’t get the design right in the first place that they’d just go back and fix the code later and that fixing the code later would be easier than figuring out the right thing now.  Of course, that’s not true.  Finding a bug later in the process results in effort that is orders of magnitude worse than finding and fixing it early on.

So, what could I do to make people do the right thing?  I couldn’t make people write good documentation.  However, because I had set up controlled access to the source control I could make them write more documentation.  In fact, this is exactly what I did. 

If a person wrote a defect and it made it to QA, they would have to write a complete set of documentation in order to fix the bug.  That meant even for the most simple one-line code defect I required an analysis document, an analysis review by a peer, a design document, a design document review by a peer, the code, a code review document by a peer, and a test results document.  It is really annoying to fill out all those documents for a single line code change.  It is so annoying, in fact, that it drives down the defect rate.  The cost to the developer for screwing up is now significantly greater than the cost to get it right in the first place.

Developers, or anyone for that matter, do not see the costs they incur on someone else for their screw-up.  If my laziness results in the need for a full-time support person, it doesn’t hurt me directly at all.  But, if my laziness creates work for me, then I’m less inclined to be lazy.  I hate doing stuff over.  I hate filling out documentation.  I hate being punished for something that I had the capability to avoid.

So, while what I really wanted was for people to do a good job at the documentation there was no way I could enforce it.  But, since doing a bad job at it could result in a significant punishment of even more documentation, I had an indirect means of getting what I wanted in the first place. 

And that is making it easier to do the right thing rather than the wrong thing.

Leave a Reply

Your email address will not be published. Required fields are marked *