Printer Friendly Version

Preventing Renegade Development Requires a Change in Attitude

My goal here isn't to imply that all development must be done by IT developers. The number of business requirements and application requests will almost always outnumber IT developers and resources. If IT has the luxury of working with knowledgeable and skilled non-IT affiliated developers it should take advantage of this opportunity. Otherwise, if ignored, these non-IT developers — many of whom have valid application requirements — will go rogue and become renegades operating under cover of darkness.

Many of the e-mails I received cited lack of IT response as the biggest contributing factor in their transformation from promising non-IT developers working in cooperation with IT to covert renegade developers. They tried going through the proper development channels only to hit a wall when confronted by overly territorial IT teams unwilling to listen to their suggestions. This type of attitude toward an organization's non-IT developers only goes to fuel the caricature of the high-and-mighty IT department that thinks it always knows what's best for everyone. Not only is this counterproductive, but it will drive non-IT developers right into the welcoming arms of the dark side. And once they make that jump and adopt a "no IT, no headaches" mentality it will be near impossible to bring them back.

In order to eliminate, or at least minimize the impact of, renegade development a fundamental change in attitude and approach must take place on both sides:

A Message for Non-IT Developers

For your part, you must understand that IT is responsible for the entire organization, and that it's unrealistic to expect instant gratification when your requests are made. IT probably has a very long to-do list and only a limited staff. Proposals for new features or applications are usually placed into a prioritized queue — if they can be done at all — so a reasonable amount of patience should be afforded to them whenever possible.

However, a far greater concern will be when official IT development teams won't even hear out your proposals, choosing instead to take a "stay off our turf" approach. To combat this, you should never make your proposals to them by yourself. More often than not, IT will look upon these types of requests as non-IT developers with itchy trigger fingers trying to make busy work for themselves. IT is usually much more receptive to suggestions that come directly from a group of users rather than a single would-be developer.

Your best chance of getting IT to accept your proposal is by presenting it to key members within your own department first (or whoever your users will be) such as group leaders and managers — the higher up the ladder, the better — and having them initiate the development process with you. This will hold much more weight than trying to go it alone since it's coming straight from users' mouths. If your proposal is accepted, your involvement in the actual development may vary from acting as a key point of contact between your users and IT to being a full developer "subcontracted" to work under the auspices of IT.

A Message for Official IT Developers

As mentioned earlier, you need to take a good look at yourselves to determine whether you're giving non-IT developers a reason to go renegade. Non-IT developers are not deliberately trying to usurp IT; they're merely trying to get applications out to their users. In some cases they're under extreme pressure from management to get it done any way possible. And if you don't provide them with the support they need, they will eventually be forced to take matters into their own hands — and then you'll only have yourselves to blame.

This isn't about territory. You need to have the foresight to see that working with non-IT developers will reduce the many headaches associated with the adoption of orphaned applications built completely outside of IT — big or small. In cases where you're unable to do they actual development yourselves, don't abandon them with an insincere "we'll look into it later" knowing full well that "later" means "never." If non-IT developers have the knowledge and ability to take on the development themselves, help them define the proper development parameters so that when it's done, their application can be easily integrated into the existing infrastructure.

The choice is yours: Help non-IT developers build an application within the confines of your established development infrastructure or ignore them and risk them going renegade.

Closing Thoughts

Renegade development is one of those strange problems that feeds itself: IT guards its territory fiercely so non-sanctioned applications won't threaten the organization's infrastructure, but in doing so they end up driving non-IT developers into seeking alternative solutions. Non-IT developers do this because they just don't want to have to deal with a troublesome IT department that won't take them seriously. And after having been turned around so many times in the past by unreceptive IT teams, they will eventually look to eliminate the middleman.

Maintaining corporate development standards doesn't mean restricting all development to official IT developers — this is not always possible. The true key to maintaining corporate development standards is for IT to provide support and guidance for non-IT developers when there's no other choice but to allow them to take the reins of development. If they are to follow development standards, it's IT's responsibility to help them do so.

The other option for IT is to ignore them, but that's a very dangerous attitude. Yes, they will go away — but only for a while. Then one day, out of the darkness will emerge a shadowy figure cloaked in black and accompanied by two menacing things: the mechanized sound of heavy breathing, and an application no one has ever seen before.