The Community Blog for Business Analysts


IT Black Ops

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.

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.

By Jhulgan

Want more? Check out our other posts

This entry was published on Aug 22, 2010 / Seilevel. Posted in Project Management, Soft Skills, Leadership & Management, Technical Topics, Roles and Responsibilities. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  4 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.


Copyright 2006-2024 by Modern Analyst Media LLC