The Audit Excuse
I tried to remove a small impediment today. Nothing hard, just some access form we have to fill out to allow content authors access to edit content on our intranet. It’s costing us a few days per content author, and no one can see any value add by going through the process. I shot off an email after the standup meeting to the network admins asking why we have to fill out an access request for such a simple request and who I need to talk about to change it.
I got my response also via email soon enough:
Well, in the good old days we used to do it verbally. Then we had to start doing it when we added access to a network share for the content authors. Now we need to do it for the portal content authors. Audits happen around here.
Apparently we’re not even sure who started the policy. That’s one of those details I’ll have to follow up on. I’m guessing our internal audits group. I may find we have an actual policy because we had an audit finding on this issue.
What I expect to find is we’ve fallen into this cover your butt policy because of some fear of a possible audit finding. That fear leads to an avalanche of costly bureaucratic policies at many companies. You know the sort of things you have to fill out an elaborate five page justification survey to have your helpdesk download some dangerous open source software like Perl complete with signatures from your CIO granting explicit permission.
I can’t figure out any reason for this form:
- We have complete knowledge of who has access to the intranet authoring via LDAP. This includes tracking of all changes by a given content author.
- All of the content being edited is simple informational content. The worst thing someone can do is accidently delete something.
- There are no licensing issues involved, our license to Websphere Portal lets us setup as many content authors as we want.
With luck, tomorrow we’ll be able to mark off the impediment.
Ed Gibbs @ July 5, 2006
Sounds like an example of the phenomenon whereby a procedure gets institutionalized and people just follow it forever, long after the time when it was necessary, and nobody remembers why it was implemented in the first place.
At our company, the standard is to use Microsoft SharePoint for project-related information. It’s not a bad idea, since all the information posted by project participants remains available to others for future reference. QA, production support, and future development projects can benefit from this store of information.
But there’s a catch. Just as you described, every individual has to fill out an access request form to gain access to each SharePoint site separately. When asked why that is necessary for development team sites, the SharePoint administrator did not mention audits, but simply said that they “needed control.”
What actually happens is that project teams throw a wiki onto one of their development servers and use that to share information. It improves the efficiency of individual teams, but the organizational cost is that the information is not retained after the project has been completed. The wiki is deleted along with everything else when the development servers are recycled for a new project.
In that context, it’s an example of what I like to call the Governor Tarkin Effect. There’s a scene in Star Wars when Governor Tarkin intends to destroy Princess Leia’s home planet as an example to the rebels. Leia says, “The more you tighten your grip, the more star systems will slip through your fingers.”
So, they have their “control.” I hope they think it’s worth the price.
Governor Tarkin Effect, I like that. At least on the wiki front we’re still pretty much in control. We can create new Spaces in Confluence without any administrative involvement.