Amateur hour: A database disaster IT can’t fix

Let’s say you’re a business manager working on a tech project that has a budget of thousands of dollars. Let’s also say IT is supposed to be involved from the beginning to keep an eye on the tech details as the project progresses.

Now, let’s say you never communicate with IT about the project, it goes south, and you call IT in to clean up the mess. Then don’t be surprised if the IT manager is upset, as in this story of a manager we’ll call “Jack” and a data analyst we’ll call “Jill.”

[ Also on InfoWorld: Find out how to rise above office squabbles in “IT turf wars: The most common feuds in tech.” | Follow InfoWorld’s Off the Record on Twitter for tech’s war stories, career takes, and off-the-wall news. | Subscribe to the Off the Record newsletter for your weekly dose of workplace shenanigans. ]

A little background info: The company in this tale had a toxic environment. Business managers were encouraged to compete with each other to get the desired results for as little money as possible. Those who did so were rewarded; those who did not had to try harder. Managers would get so focused on the final goal that they didn’t think about how best to achieve those results, didn’t communicate with key departments, and overlooked important details. As you would guess, many projects ended badly.

On the tech side, most of the database applications at this company were custom built by outside vendors, as we worked in a segment that couldn’t use off-the-shelf software. IT would do basic development in-house but didn’t have the staff to undertake any full-scale projects; we worked with outside vendors if a lot of coding was required.

In one of our departments was a new hire for a data analyst position. A recent graduate, Jill didn’t have much experience. But she was smart and ambitious, and she impressed her manager, Jack.

Jill had been there about a year when Jack put her in charge of a complex project: She was to create a custom database with a Web interface that customers could access anywhere. Jill had no expertise in this area and was in over her head, but Jack did not notice. He gave her free reign over the project.

She found a vendor who could code the Web interface part, but after several months, the database was full of problems that the vendor wasn’t doing anything to fix. Jack wasn’t happy and called the IT manager (me) to straighten out the project.

Now I was the one who wasn’t happy. “Why were we not notified of this project?” No good answer.

I asked more questions, but Jack sent me to Jill for the details. I tracked her down and asked her to walk me through the project from start to finish, beginning with what the project was about and who was working on it. I was shocked at her half-baked responses to these basic inquiries.

As I continued talking to Jill and becoming more familiar with the situation, two major problems stood out. The first was that the scope of the project wasn’t well defined and was, therefore, a moving target. The second was that the vendor had promised the moon but couldn’t deliver. The main components of the project were working, such as the Web interface, but there were many bugs and missing features.

Thinking through the options, I told Jill we wouldn’t pay the vendor unless they fixed those issues. She hesitated, shifted nervously, then looked down and muttered that she’d already paid them in full. Face palm.

I got the vendor’s contact information from her and told her I’d see what I could do. After a few conversations with them, I found out that they were a group of experienced developers who’d decided to go out on their own but were still inexperienced about handling the business side — though obviously they knew how to get paid. Still, they promised the world but couldn’t make good on their word.

To be fair, it seemed they didn’t have an easy time on the project, either. They told me that in the beginning, the scope was much simpler. As development progressed, Jill told them to change this, change that, add this, subtract that. It ended up being a lot more work than they had anticipated.

However, I couldn’t verify much of this because there was very little written communication between Jill and the vendor. Even the initial scope of the project was based on an oral agreement, and the written contract was full of holes.

Trying to salvage the situation, I asked the vendor for the source code and documentation to see if our IT department could take over the project and fix the issues, but they refused. Their solution was to offer to host the database for us, charging us by the record.

We had no leverage because the vendor had already been paid in full. They refused to work with us on our terms and always tried to steer us back to their conditions, of course asking for more money. Negotiations were futile.

I gave Jack the recommendation that we cut our losses and move on. He said he’d think about it. A month later, Jill was no longer with the company, probably to give the execs the impression that something had been done to compensate for the money lost — although she shouldn’t have been given that level of responsibility in the first place.

A couple of months later, Jack told me he’d scrapped the project, and I eventually left the company. I never found out what happened with the Web-based data application, but odds are it met the same fate as its original leader.

Do you have a tech story to share? Send it to offtherecord@infoworld.com. If we publish it, you’ll receive a $50 American Express gift cheque.

This story, “Amateur hour: A database disaster IT can’t fix,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.