I’ve worked on at least one project now and heard of several others where a super-secret development team works in parallel to solve the same business problem as the “official” IT project team.  A coworker of mine coined the term “IT Black Ops” to refer to these sorts of projects where the business, either out of frustration, arrogance, or ignorance, hires their own shadow development team to implement a competing solution, or an enhancement to an existing solution. I’ve never seen this go well.  However, unless you are at an executive level, there is very little you can do to shut down the black ops team.  In many cases, you won’t even realize the black ops team exists until the last minute when you are forced to integrate their spaghetti code solution with what the actual IT project team has built.  Of course, this kind of surprise is to be expected, since the very nature of IT Black Ops is to operate stealthily, and for their business owners to neither confirm nor deny their very existence.  However, once their presence is detected, a project and budgetary train wreck usually ensues.

I’ve done a little bit of thinking recently about why IT Black Ops projects are launched in the first place.  It’s probably because of one or more of the following reasons:

1. Low confidence that IT will be able to build something that actually solves a business problem.   Sometimes this low confidence is warranted.
2. No budget to build something the “right way” (i.e., gather requirements, manage the project, test it, and deploy it).
3. Business owner finds an extra million dollars in the budget and can finally implement his/her pet feature, even though it was initially shot down because there was no ROI for it.
4. Lack of understanding about why it takes so long to develop working software.

Even though the decision for the business to go undercover with their IT development will likely be disguised, there are a few ways you can help prevent them from wanting to do this in the first place:

1. Keep the business engaged throughout the development lifecycle. Giving the business partial ownership over the project by having them sign off on and review working prototypes is a great way to give them confidence in the system and make them feel as though the solution is a joint effort.
2. Sell them on the value of process. The ROI for good processes is difficult to calculate; however, turning a team of developers loose to write code with no requirements or process discipline is about as successful as hiring a room full of 1000 monkeys to develop your solution.   Giving the business ownership of the process will help.
3. Each project should have a clear ROI.  This sounds obvious, but too many projects have a vision statement akin to “you know it would be really cool if…”   People also become emotionally invested in certain solutions, without taking the step back and evaluating how well the solution solves a business problem.   Just watch out for pencil-whipped  and contrived ROIs.  Be suspicious of any feature which does not tie back to a quantifiable business objective.
4. Use comparable projects to set expectations.  People who do not work in software development often find it difficult to understand how expensive and time-consuming software development can be.  This can sometimes lead to the attitude of “This is simple–I can do it faster and cheaper myself”.  In order to head this off, it helps to show the budget, resources, and time to execute for similar projects.  It is natural to ask the question “Why is it so expensive/time-consuming/so resource-intensive?”  You can use the lessons learned on other projects to help answer this question.

It never really helps to mention that the black ops team will always fail, that someone will get fired if the black ops project continues, or that it will end up being more expensive in the long run–even though these statements are almost always true.  Once the black ops team is hired, you’ve already lost, so do what you can to prevent IT Black Ops projects from being launched in the first place

This blog post will self-destruct in 500 views.