It happened by accident. Brad (not his actual name), the Manager of Quantitative Research in a large brokerage initiated an internal project. The goal of the project was to rebuild a legacy database application that was used by Research Analysts. For a number of years the app was supported by a moody contractor who was all too expensive to keep around. The goal of the project then was to transition to the full time people and make a few improvements along the way.

The project was high priority and Brad got the best guys from internal IT department, and, most importantly, he's got Glenn, the local God of DB architecture. Glenn stood behind several successful projects and everything he said was treated as a gospel.

Everyone has their bad days and when three weeks later the database model was complete, everyone noticed that it seemed a bit too complex. But every good developer knows that you need to build extendible applications and plan for the future so none questioned the model.

Requirements and software architecture were ready and the team began coding. As it turned out 3 months later, one of these days developer misunderstood BA's, verbal instructions and the formula was producing wrong results

After several weeks of troubleshooting, BA attempted to reduce the complexity and split functionality into several modules, The split required some UI changes. The changes did not properly sync with the business layer so the team went ahead and changed them which took over 2 months to complete instead of the planned 2 weeks.

At the end the code that was failing to properly analyze the data before the interface change was finally adapted to the new interface and still failed to produce correct results

One year later this three month project was cancelled altogether and the app was replaced by a costly vendor tool.

"You just can't trust IT" said Brad and took a big sip off his Stella... "no matter what they say, they will screw you over! I had no idea what all these design meetings were for. I didn't get a single word of their gibberish. My BA told them in plain English what we needed and a year later we've got nothing but errors! Next time I have to deal with these guys I better understand what they saying!"

Here is a million dollar lesson (Brad's department actually did pay close to a million dollars for him to learn it and it killed his promotion):

You can not manage something you don't understand. And you can not give up control and let IT manage themselves. Even if they could, misunderstandings are all too common and you need to be there every step of the way to see if the project is on course.

With proper management training In just a few days a business person can get a good handle on the core concepts of IT projects delivery while it may take years to train an IT person (or anyone) in Quantitative Research. Abdicating control never worked for anyone.