I was faced with a problem. I needed to implement a development ticket system for my department that could talk to both the support call center software and the accounting software. David also mentioned wanting it to support the future sales tool, and I knew there were people in accounting who needed it to fill some gaps in the package they had already.

The problem was that before I arrived, Doug the insane support manager had begun working with Slomo, a certified Shady Software Vendor®. No one in the company had done a proper study of our needs across departments, and no one had bothered checking whether Slomo could deliver anything as described.

The result is that Slomo had been contracted to develop a support ticketing system that had a rudimentary connection to the accounting software (there would be a drop down list containing all the customers in the system). It would not support any functionality required by the other departments.

The punchline is that Slomo had been working on this project for six months, and it was dead in the water. Doug had dropped the ball, and Slomo never had a great grasp of it to begin with. There was some investment already so people were reluctant to simply drop Slomo even though my gut said to run (fast).

To humor the good people of Ideal, I began my research into the capabilities of Slomo’s offering. I found out who had taken point on the initial deal on both sides, and maneuvered to take over the project. It’s worth mentioning that our guys, Doug and Walter, were more than happy to let me have it because it was a source of stress for them, but it’s important to realize that I asked very carefully for the responsibility. I felt out the situation, and I asked in a way that gave the impression that I was doing it out mercy, not with my own agenda in mind. The real agenda: get a system my team could use to build better software.

The first step was setting up a meeting with the sales guy who originally sold the software. That’s when it became clear.

Déjà Vu

I’d seen Slomo somewhere before. The lofty promises. The subpar interface. The alarmingly friendly sales guy, John. I could recognize all the failings of Ideal in the mirror of Slomo, and frankly, I wouldn’t do business with Ideal right now.

Here’s what I did to figure out that we were in trouble:

• When John made a claim that was specific, I asked him for more detail. For example, he said that the system was fully documented. Too bad for him Doug had already told me that the documentation they were given was dismal and outdated. So I asked John pointedly, “Ah, you have an updated manual?,” to be followed quickly by “Excellent, can you send that to my E-mail so I can take a look?”

  It never got that far — he admitted he didn’t have the documentation. Lying in a sales pitch, check. No product documentation, check.

• I took notes about what he said the software could do, and I’d occasionally ask him “How does that work?” Sales guys hate that question, because it derails their train of thought. They have designed the pitch to sound good, like someone who is a little shifty on a first date: “Oh did I say Assistant Manager instead of Assistant to the Manager?”

  Often, upon clarification, features will be a little less “rich” and “robust” than the sales guy would have you believe. For example, he told me that the software could act as a “full featured” development ticket and project planning environment. I asked him how that worked and he admitted that it was possible give support tickets a status of “Software Bug,” and that was about it.

• John gave me an on-screen demo of the software. It looked great. Word of advice: don’t ever take demos at face value. I’ve seen demos from the other side, and they are invariably hacked together smoke and mirrors. Always ask to be able to use the software yourself.

  I asked for a demo account that I could use to poke around. I discovered that the software doesn’t work in any browser except Internet Explorer. No self-respecting computer geek uses Internet Explorer — they only grudgingly make their software compatible with it. The issue is that developers who aren’t very good at what they do will only work and test in Internet Explorer, so a tell tale sign of subpar construction is only working in Internet Explorer.

• John kept mentioning how scalable his application was, so I asked him for details. First of all, web applications can naturally be split into at least 2 servers — one for the application, and one for the database. This takes no special effort, it comes automatically. I asked him if his software could that. “Yes,” he answered confidently. That was the primer. I gave him a hypothetical scenario in which Ideal grew and needed more servers, and I asked him if it was possible to split the app across multiple application servers and a database cluster. “Yes,” he answered just as confidently.

  To find out if he was lying, I asked to see their database schema. This is a diagram of the database that drives the application, and it must be specially designed to split in the way that John had promised it could. Since only a developer would have the schema, it also gave me the opportunity to speak to someone at the company who was not a sales guy.

  I discovered shortly that John had lied. I also discovered that the database was poorly designed in many ways, which is another indication that the construction is shoddy.

• I familiarized myself with the inner workings of the accounting software, so I would understand the effort involved in connecting the systems. This is something I have experience with after running my own software shop which specialized in making legacy systems talk to each other, just like I was doing now.

  What I found was that a substantial effort was required on our side to organize our books such that it was even possible for an external system to extract meaningful data from it. I had begun coordinating that effort with Ben prior to the meeting. I didn’t tell Slomo this information. Instead, I let them dig their own grave by asking how they planned to make it happen. Of course they hadn’t considered it at all, and over the course of a couple hour conversation it became apparent that they had grossly underestimated the amount of effort it would take to provide everything they promised.

So, what did you do?

I’ve retold this tale as if I had all the information at once, which isn’t quite accurate — I collected these data over the course of a week and a half, so until the end, I wasn’t sure about my conclusion. That’s why I gave John the benefit of the doubt. I told him that I thought the project had floundered because our guys let the ball drop, and that the requirements hadn’t been clear from the beginning. I told him I wanted him to take a day or two, and come back to me with a realistic estimate of price and time line to get the project done.

After I gave him this opportunity to redeem himself, he came back with a bullshit estimate, riddled with typos. Even after holding his hand through the requirements to emphasize that they were deceptively complex, he grossly underestimated the time, and said he could be done in two weeks.

I had put on my project manager hat, and estimated the effort in some detail as if I were going to actually complete the project. My estimate was around 400 hours of effort, which is 10 weeks. I had also contacted a number of other vendors and provided them with my requirements. They were uniformly 350 to 450 hours.

Moving On

The vendor that I finally settled on, AwesomeSoft, was on the ball. I gave them a fairly detailed specification of what we needed, and the project manager still grilled me about our existing system and needs, to get a clear picture of what we needed. He asked questions that only a thoughtful developer would think to ask. He provided me an estimate that was in line with the effort involved, and he followed up frequently but not annoyingly while Walter dragged his ass. If I could recommend him without blowing my cover, I would certainly do so.

Putting it all Together

The biggest lesson here is that I didn’t take anything for granted. I carefully evaluated the needs of the company, by interviewing almost everyone here about what they do and how they do it. I literally have a word document that contains a description of everyone’s job as told by them personally. I transcribed it from my notepad that I carried around the office for a week.

Then, when evaluating the software and vendors, I always double checked their claims by making them prove what they were saying. I had a distinct advantage as a very technical person myself, but if you are not very technical and you are about start a project of any size, you should consider bringing in a trusted technical consultant. Any cost will pay for itself many times over.

For quick reference, I’m putting together a summary of the Dos and Don’ts of selecting a software vendor, and it’ll be available on Wednesday: Guide to Selecting a Software Vendor.

Popularity: 20% [?]