[jnosCo]

I'm one of those assholes that makes security policy. I deal with the same requests. The problem is, I write up a proposal identifying the risks associated with the exemption, along with minimum and recommended compensating controls. This then gets discussed among IT Management, where it is usually decided it's too much overhead, and to just deny the request or if the user can scream loud enough, allow it outright and get some director to sign something. The third oft-used response is ignore the problem and hope the user finds their own work around so we can get back to the 13 projects we're somehow expected to complete this quarter.

[novok]

It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'.

Not letting people do their jobs, or in how fast they can do their job. Employees are a captive audience, and if there was competition they would probably chose something else.

[TeMPOraL]

> It's an incentive misalignment. IT is evaluated in 'how secure things are' or 'how easy is it to maintain' or 'does this give me more headcount'.

I tend to summarize my experience with IT in large companies and universities like this: IT is evaluated in "how secure things are", or "whether things are not broken". The only sure-fire way to ensure a system is secure and not broken is to make it completely unusable, so that people don't use it. If people don't use a system, they can't break it!

[brokenmachine]

Our outsourced IT has KPI's for closed tickets, so they are very keen to close any ticket for any reason. Then it is up to you to call and restate everything to first-level helpdesk again to reopen a new ticket in order to actually get things to happen, and thus they end up closing double the number of tickets.

Never mind that it took double as long, and sucked the life out of everyone subjected to the system.

Efficiency!

[jnosCo]

We attempt to address this by making IT's annual bonus tied in part to our dev's project completion. It's not perfect, but the heart is in the right place. A big problem with this is that when we're dealing with limited manpower, we'd rather throw it at the easy issues than the hard ones, and ultimately get more things done.

[novok]

Maybe create a 'time wasted' ticket system to help quantify employee hours wasted by IT roadblocks? It smells like it could be gamed heavily, but it might work better.

[basch]

the same should then apply to "adopting the tool to the process" instead of "adopting the process to the tool" when a new technology is implemented but process and behavior are declared immutable.

[novok]

It's proprietary software (adobe, apple/microsoft, autocad, etc) and they file it as a no fix. Or it's open source and it will take $30k+ in engineering time to change it and $100k+ in time wasted waiting.

Now what.

There is also an inversion of responsibility here. It really should be IT's job to 'adapt the tool to the process' instead of externalizing it to their staff. Until they can do it, the staff needs outweigh the lazy 'default no' of IT.

[basch]

if you buy a new erp, and it comes with a set of best practice process, and your management and employees all insist on transposing the new process onto the new software, in some cases why even buy the new software. its a different coat of paint on the same thing. youre buying a new erp for the change in process, but you refuse to adopt it.

[mariefred]

or simply use an Excel to log time and reason, this should be a short term effort only to prove a point.

[AstroJetson]

Me too, we try, but it's too easy for people in the management chain to push a fix into the "Too Hard Bucket" (tm) and it dies.

[maxxxxx]

I feel you. The whole setup is dysfunctional by design.