Widening Gap Between Business and IT

Alastair comments on an earlier post where I wrote about software skills and development skills. This prompts me to take a closer look at what I wrote based on what I see happening in many companies. I certainly read a lot about the necessity to align IT with the business but, I really don't see that happening. I actually think there is an increasing amount of mis-alignment. One major symptom which I believe proves this is outsourcing.

Setting aside all of the buzzwords about efficiency, core competencies, etc., outsourcing is about saving money and reducing payroll size. Everything else is pretty much bullshit. The root cause of outsourcing being so attractive up front really comes down to 2 issues:

a) Low quality requirements;
b) A mutual lack of respect and understanding between business and tech.

In a typical business/IT arrangement, the first thing that happens on any project is the kickoff meeting followed by 1 person from IT meeting with about 1/10 of the people in the kickoff meeting for several weeks-months, gathering requirements. Based on past experience with waterfall-like development and the length of time required, the business thinks, "If I don't get all of my feature requests in that requirements doc, I'll never get it done." At the end of the process is a comprehensive requirements document, forming the basis of a contract between business and IT. Then, the spec gets handed off to development (an intra-company gap) and the business sees nothing until the first demo/beta.

In a typical outsourcing arrangement, the first thing that happens on any project is an army of experts like analysts, designers and architects from the outsourcing company show up, typically outnumbering the client's staff by 3:1. Why does this happen? Simply, this is the outsourcer's insurance policy; clear, detailed requirements form the basis of the contract for delivery. Based on their experience, the outsourcer knows that businesspeople generally can't write requirements and that discovering requirements is a highly labor-intensive business. There's lots of data stating that the largest costs in any development project are gathering requirements and fixing defective software due to defective requirements. Therefore, it's in the outsourcer's best interest to make sure the requirements doc is as comprehensive as possible. Then, the spec gets handed off to development (a wider, inter-company gap) and the business sees nothing until the first demo/beta.

Look at the similarities! The goal is comprehensiveness, not quality or priority. When the goal is quantity, cheap labor will win, every time. Isn't it easier to see why outsourcing looks so much more attractive, up front? The business sees that due to the cost of labor differences, it will take less time/money to develop a comprehensive contract, or, given equal time the outsourcer can develop a far more comprehensive contract.

How can we solve this problem in favor of business needs and in-house IT? That brings me to my second issue, the mutual lack of respect and understanding between business and tech. The formal solution would be to train businesspeople how to discover and write better requirements and also train IT staff how to better elicit requirements. The less formal (and zero-cost) solution would be to co-locate (no gap) the developers with the business people. This would allow the developers to deeply understand the intent behind the requirement and it would allow the business to focus on the most important requirements at that moment. Sounds a lot like the techniques favored by agile software development methodologies.

It would seem that a relatively simple change in the physical business architecture would reduce both software development costs and legal costs (for when the outsourcer doesn't deliver what was intended for them to deliver).