In my last column I explained the obvious, if mostly ignored, reason why so many significant development projects fail.
At its most basic, the problem boils down to the refusal or inability of developers and their managers to adhere to commonplace quality control and documentation procedures that have been proven to result in better products, lower costs and fewer delays.
The chronic overruns of time and resources that blight the average unstructured corporate development project leave hapless or helpless managers with two main alternatives:
- Fix their hiring, their staff of programmers, their methods, their procedures, their management practices, and invest in training; or
- Buy work from outsiders with a quality requirement that approximately matches what they are already delivering, but at a lot lower cost-per-hour, and hope the benefit-cost of the lower ceiling on quality hurts the value less than the lower price helps it.
The first is the professional approach, the second the response of an amateur throwing up his hands because he doesnt know what else to do. Prayer rug time. The lack of skill and discipline among most development management doesnt excuse this abrogation of responsibility.
But does it always fail? Is it really so bad?
It doesnt always fail, but its always bad.
There are two reasons offshored developers and help desk people have a quality ceiling thats too low for any organization that can only succeed with quality thats adequate or better.
(Some organizations depend totally on volume, or come to the table with such overwhelming superiority of force in sales and marketing that they are exempt from ordinary quality requirements; think monopolies, organized crime, WalMart and the U.S. military).
The first fracture point is proximity.
You can collaborate with someone in a different location, but you cant know a users work and how he or she views it if youre not immersed in it; and you cant be immersed in it if youre not physically present. You cant learn it through e-mail, screen sharing, screaming video, cell phone voice dialogue or a collaborative software client.
That ignorance simply cannot be overcome with technology. Which is not to say that legacy practices were any better. There are plenty of shops that had developers on the same floor of the same building who didnt bother to immerse themselves in the work they were enhancing or automating.
Its a rare application developed with that missing ingredient that doesnt sap productivity, however. Losses come in the form of missing features and late changes to specs, steep incremental training efforts, user discouragement or resistance, and large numbers of avoidable updates or patches.
The other fracture point is culture. And culture is really two different related things here: Departmental and regional.
People who build products of any sort who dont share the culture of the specific department that will be using the product will miss subtle features or areas of concern.
Like physical hand tools that are designed for right-handed people but sold to left-handers, there will always be some loss of effectiveness and occasional damage to the user.
The entire repertoire of behaviors that constitutes the cultural norm for a factory floor is, in most ways, not just dissimilar but antithetical to the repertoire of development groups behaviors, for example.
Culture, much of which relies on shared perception, cant be transmitted without proximity.