You’re in the IT department, and you have some pretty solid processes in place – project request forms and approval committees, change approval and management, and some kind of steering committee. Instead of everything lining up nicely, though, you’re getting business units going around the process, building their own applications, writing their own code, and doing it without IT approval. With such a great funnel to go through and everything so neatly defined and documented, why would the business do that?
What is “Involvement Entitlement”?
This Programmers.StackExchange question is a great summary of this, and there’s a general feeling throughout many of the answers that I’ll call “Involvement Entitlement.” In summary, I’d define it this way:
All use of technology must be in a manner explicitly approved by IT, and any custom solutions in place must be written by a developer in the IT department. Any use of technology in a way not explicitly cleared by IT is forbidden.
This attitude can manifest itself in many different ways:
- A policy requiring IT approval for any software
- Locking down computers so nothing unapproved can be installed
- Allowing custom development, but requiring that it clear some bar of “development” or “infosec” approval that’s never actually met in practice or is so complicated that it’s never actually attempted
- Custom applications or processes being “allowed”, but setting up requirements with learning curves so high that it’s not feasible for anybody outside IT to meet them (for example, “all applications must be developed in C++” or “every process must have high-availability and load-balancing with automatic no-touch failover to multiple data centers”), when there’s no technical reasons for these requirements
The problem is that these policies don’t actually prevent custom solutions; they just prevent IT from being involved in (or often even finding out about) the things that are being developed. The business doesn’t want to skirt the process or avoid IT, but they do want something very simple – for their jobs to be easier. When the business builds a custom solution like an Excel macro that takes a workbook and uses keypress automation to type a long list of transactions into the accounting software, or small .NET desktop app that generates PDFs for customer paperwork for bankruptcy processing and emails it to the relevant state authority, they’re doing it for one reason – it’s easier than doing it the old way. If they’re not involving IT, it’s for the same reason – it’s easier that way.
What’s really going on?
When you stumble across one of these processes that didn’t go through IT, ask yourself the following two things:
- What are they trying to accomplish by developing something themselves?
- Why is the business going around the IT processes?
If you don’t like all the custom development that’s going on, forbidding it is mistaking a symptom for the problem – you should instead be asking why they’re going around IT, not just telling them it’s not allowed. Remember that you (IT) exist to help make their job easier, not more complicated. Sometime the value of IT comes in the form of ensuring that applications are fault tolerant or high availability, or in the form of ensuring an application can be supported once the lone developer that built it leaves the company. At the end of the day, you’re in the solution business, and if you and your processes aren’t enabling the business to work better, you’re not adding value.
But here’s something to remember: Every custom application that’s been developed outside of IT corresponds to a need that’s not being met by IT. There may be a good reason they’re not met – not a priority in the company, very specialized problem, not as good as other options, custom language your IT people don’t know, etc – and the lack of IT involvement may be legitimate, but these solutions were created because some department had a need that IT couldn’t (or wouldn’t) satisfy.
IT can still help – be a partner, not gatekeeper
Try to help them solve their problems, and if you don’t have the time or resources, let them solve them on their own. Mandating some language that has a steep learning curve, with the sole purpose of keeping people out of your business, only serves to enhance the elitist attitude most business users perceive IT to have. In the end, that kind of elite attitude only leads to more of the same problem, as users are afraid to approach IT for fear that they’ll either be told “no” outright or that it will add extra effort without adding any value.
There’s no reason I’d forbid this sort of development, within reason – it eases up constraints on shared resources (mainly IT), and allows each group to empower themselves to solve their own problems (as people versed in advanced Excel are pretty common, since this is a common problem, most departments have at least one).
However, you also shouldn’t be expected to solve any problems that arise from these applications, or support them after the original developer leaves the company. As some of the comments in that original post mention, this doesn’t stop the big boss from demanding that you support it, but if you keep a feel out for the kinds of custom applications or processes out there, you can get a feel for when something becomes critical and you might need to get involved to bring it “in-house.” Also, if something is connecting to and modifying systems that are under IT control, then IT should be involved, if only to ensure the security and integrity of their central systems – however, if it’s something confined to a user’s desktop, why feel the need to forbid it?
Postscript – don’t let perfect stand in the way of done
When I said I started this post 7 years ago, I mean it – it’s a classic case of not knowing exactly what perfect looked like, so I let it stand in the way of done. Go find something you’re not sure how to finish and figure out what keeps you from getting it done – and then deliver 🙂 A moderately good idea delivered is worth 100x as much as an incredible idea stuck in your head!
