A prospective client called on me to determine whether I could fix several application issues in her organization. This was a small company with limited cash flow and an unhappy staff. It became apparent that not everyone at the meeting wanted me there.

The COO explained that most of the company’s business was handled by a single application, which processed sales orders and purchase orders, managed inventory, and provided banking and accounting functions. The application was written for the company two years before by a small consulting firm that overcharged them, delivered an inadequate product, and soon after went out of business. It also was slow, crashed often, and was difficult to use.

These problems fell in the lap of the client’s IT manager. He had been with the company for 10 years and had worked with UNIX the whole time. Now, however, all the systems, including the one with the trouble, were Microsoft-based, and he was in over his head.

He saw my involvement as a threat to his job. His view was that any improvements I could make would reflect poorly on him. He ran his area by keeping the users uneducated and blamed system and data errors on user mistakes.

I was trying to sell my services to a company that had been burned by consultants in the past, had a very limited budget, and had an IT manager who didn’t want me there. The company’s goal was also very vague: Make the application better.

I saw this as a golden opportunity. They had systems issues that they couldn’t address, they needed my skills desperately in the short term and, because of their lack of Microsoft skills, I could be with them for the long term.

I made an initial proposal with the goal of getting my foot in the door. They would identify two key areas where performance improvements would provide the most benefit. I would do a no-cost half-day analysis and make recommendations to improve performance. In return, I asked for a good faith promise from the COO that they would engage my service if they decided to proceed with my recommendations.

Fact-finding
I performed the half-day analysis and found an extraordinary number of areas that could be improved. To start, the application was written as a single executable. There were no dynamically linked libraries (DLL) or configuration files. The executable was also large—over 20 MB.

There were also no stored procedures. All of the SQL statements were embedded in the source code. The SQL statements were also very poorly written. Rather than write complex (or even not-so-complex) SQL, the recordsets were selected into the application and looped through, row-by-row. In one section, opening a form would run code that looped through a recordset of 300 records and took more than two minutes, during which the user would be locked from the application.

I also found sections of unnecessary, old code—either left over from previous versions or even from the initial development—that ran for extended amounts of time.

Action plan: The application
I had enough information to make my recommendations. The biggest improvement would come from removing the code modules that looped through recordsets and replacing them with stored procedures and more advanced SQL. I would also evaluate the indexes on the affected tables and modify them if necessary. I’d remove old code and move the remaining logic into DLLs. I realized the effect of moving only two modules to DLLs would be minimal, but it would set the stage for some future work.

This addressed the application issues. I priced the proposal with a daily rate and estimated the work would take three to four days. I also put a cap on the total cost equal to five days times the daily rate. That addressed the issue of the limited budget and satisfied the COO.

Action plan: The IT manager
I still needed the approval of the IT manager, who was coming up with every reason not to hire me. He insisted that my work was going to have minimal, if any, impact and it would amount to wasted money.

Instead of arguing for his agreement, I circumvented him. I committed to a 25 percent improvement in performance from my initial benchmarks and guaranteed my work. If I didn’t provide the improvements I was committing to, I wouldn’t get paid.

I also met with the owner of the company. I knew his primary concern was that his company not get burned again. I emphasized relationship building. My goal with this project was to get a more long-term commitment, not just a single individual project. Short term, one-off projects meant I would have to start from square one with another company the next month. I worked with just a few companies on an ongoing basis and I wanted to increase that number.

What happened
They signed the contract, and I began my work. I implemented the changes exactly as I had proposed: I followed best practices and made sure that all my changes were documented and the original version of the code and database were backed up and readily accessible. I wanted to give an ultra-professional impression. When the work was completed, I benchmarked the changes, which, as expected, were much better than the 25 percent improvement to which I had committed.

I wrote a document detailing the changes I made and their effect. I also included recommendations for additional performance improvements and other enhancements.

Overall, the client was very happy with the work I had done and the way I had addressed their concerns. I proved myself as a consultant who did quality work and understood their problems. As I had hoped, they wanted to bring me in for further engagements.

The IT manager, although still concerned that I was a threat, began to understand that the work I would do addressed issues beyond his expertise. I negotiated an open-ended contract that brought me in one day a week with the possibility of this growing into a larger project a few months down the line.

How would you have handled this situation?

Would you have approached this client the same way Evan Stein did, or would you have taken a different tack? Post your comments below.