The cost of control

I saw a great post by Ron Ashkenas on how controls create complexity.  We’ve been struggling with this issue in our transformation program.  We have put stronger controls and more frequent communications in place.  However, these controls and communications shouldn’t create double or triple work.

Askkenas captures what drives these issues in his opening paragraph:

Have you ever noticed that organizations are great at creating controls and policies to prevent incidents that have already happened? Once the proverbial cow escapes the barn, they adeptly make sure it won’t happen again by, say, authorizing only certain people to man the exit and constructing barn-door status reports. 

Sometimes this needs to happen and usually it is straightforward to figure out what a “new normal” approach should look like.  But the rest of the program or business can get left behind and needs to be brought along to the new reports.  There is nothing more frustrating than reconciling “old program” status reports to the “new project” control paradigm.

Encouraging deviancy in projects

First off, apologies for the misleading advertising — this isn’t a how-to post.

I’ve linked to a lot of Bas de Baar’s shared posts, but I’ve never commented on one of his own posts (or at least not in a long time).  Let’s remedy that oversight.   On a recent post (here), Bas admitted to deviant behavior on a previous project.  He stopped doing his status reports.  Or more accurately, he first sabotaged the status reporting approach (e.g., submitting the same report with different dates, added nonsense risks, etc.).

I asked myself: “Would I have noticed?”  Bas’s colleagues sure didn’t; or worse, they never admitted they did.  The only reaction came when he forgoed submitting the reports altogether.  Never mind that he had stopped providing useful information already… it was only when he ended his formal compliance that he got in trouble.

Sometimes our project’s rebels are our first and best indicators that something is wrong with how we’re monitoring and controlling our project.  I’ll bet that Bas had voiced his opinion to the project leadership.  Something like this: “Our status reports are a waste of time because they aren’t substantive, aren’t read, and therefore waste our time.” 

He was right, of course.   Bas’s post is a reminder that instead of punishing deviants, maybe we should encourage them.  Or at least listen to them.

%d bloggers like this: