The Proposal Process: Lessons Learned

Recently, I had the displeasure of bidding on a contract for a client who I am now convinced missed the “Reality Train” years ago. The experience has taught me a few lessons, good and bad, that I thought would be useful to pass along; Especially for those who are new to the consulting gig like I am.

First off, the job was to produce reports from an aggregated data source. I would be getting the crunched data from a partner firm in XML format and my responsibility was to produce a series of charts and tables from that data, injecting some business logic and row manipulations along the way. The reports would need to be produced sometime in July; A date had not been set, but it later became clear that the deadline would be July 1st.

I chose a total .Net solution; Import the XML to a SQL Server 2000 database, use a combination of stored procedures and C# code to re-organize the results as required, and build a custom set of Crystal Reports as per the client's specifications. I was aware that the client had a number of similar projects that are run on an annual or bi-annual basis, so I opted to design a set of tables and framework classes that would allow the final app to be extensible and adaptable for future efforts.

So far so good, right? Next, I attended a meeting to pitch the concept to the client, bringing my laptop with me to show off a quick app I did the night before to demonstrate using Crystal Reports, and how it could export to a variety of formats. By the end of the presentation, they wanted to know if I'd accept the job then and there. I tentatively agreed, and said I'd have a proposal letter to them in a day or so.

Mistake #1:

I opted to self-assess the project, breaking it down into individual tasks and estimating in “perfect programming days” how long I thought each would take. I estimated for design and testing, coming in at around 300 hours. I drafted the proposal letter outlining the concept, requirements, and estimated cost.

Lesson Learned: Set up a project planning meeting to go over the specifications in detail with the client and perform on-the-spot estimations as per ExtremeProgramming's “planning game”. That said, it became apparent later that the client had no interest in taking ownership of their project.

A week went by and no word came from the client. I called them up and they sheepishly admitted that they had begun to farm the bid out to other firms. Fair enough, I thought. It's their prerogative. However, if I hadn't called they would have left me twisting.

Lesson Learned: Don't expect clients to keep you informed on what's going on; keep in touch to see where things are headed, and determine if it's time to cut bait. If they are farming a bid out behind your back and you learn of it, pull the trigger and ditch them. This is a sure sign that they are going to try and weasel.

The client told me that they were concerned about the price and my skillset, and are nervous about whether I am capable of doing the job. I did my best to allay their concerns and described in detail my programming experience, comfort level with the toolset, etc. The client told me they would have a decision by early the following week.

Ancillary Lesson: Clients who are overly price conscious are really cheap bastards who will nickel and dime you to death in the long run. If you suspect this, plan your exit strategy. Doing a job at a loss is worse than not doing it at all.

Early the following week, I still hadn't heard from the client, so I put in another call to have a friendly chat with them, and learn what was holding up the estimate. Time was moving on, and I was concerned that my proposed solution would become unfeasible in the shrinking time window. The client told me that they were still hung up on the price, so I asked them to tell me what they were planning to spend. I explained to them that we were playing pool in the dark, and that we needed to get a better understanding of each other's expectations.

Mistake #2

Some clients are on a fishing expedition when they ask for proposals. Often, they mistakenly perceive their needs to be overly-simplistic and budget accordingly. I should have asked about the budget for the project way back when we had our first meeting.

Lesson Learned: Clients often want the equivalent of a ten-story building on a two-story budget. As professional consultants, it's up to us to explain why this isn't possible. Learn the budget cap early on, and reconcile the project realities against it.

The client called me back the next day (shock, surprise!) with a ballpark figure that would compensate for half of the 300 hours in my original estimate. They urged me to think about it overnight and get back to them later.

Knowing that this could lead to more time wastage, I realized that there may still be a chance to save the contract. I told the client that I'd like to set up a meeting with all of the key staff related to the project so that I could explain the proposal requirements, and how the costs were determined. They agreed, and we set up a meeting for the next afternoon.

In the interim, I drafted some notes, an agenda, and decided to offer them a pro-bono service; An on-the-spot design session as per ExtremeProgramming rules, to clearly demonstrate what was required for their project. I assumed that this would win the day, since they had no project management methodology in place for any of their projects, and had project specification documents that were essentially useless for programming requirements.

Mistake #3

Some clients do not like to be told how a project should be organized, and others still do not want to be involved in the process whatsoever. While I did ask the client if they'd be interested in this, and they agreed, I overestimated their capacity for reasoning.

I did my best soft-shoe at the meeting, and struggled to keep on the agenda as I was barraged by a battery of what-if scenarios and hostile questions that would make the defense of a college thesis look like a walk in the park. After almost an hour and a half, I still hadn't gotten to the design session I wanted to do, and in the end, only managed a quick demo.

The primary focus of their questioning surrounded giving guarantees on future development costs for projects they had yet to design, and if the proposed framework would be able to accommodate them. We were literally speaking in hypotheticals, and not on the realities of the current proposal. The client then threw out a veiled threat to take the job to another firm. I told the client that if that was how they felt, then maybe I wasn't the guy for the job. I didn't blink.

Lesson Learned: While you may think you understand what the business priorities are for a client's project, never expect them to be so obvious. Have confidence in yourself and your worth. If you think you're being taken advantage of, say so and be prepared to walk away.

In the end: Despite my efforts, I lost the bid. I got a platitude-laden email blowing me off, with some reasons they didn't like the bid. My favorite was my disqualification because I was an independent consultant. Should anything happen to me, they reasoned, then the project would be in jeopardy. What the fuck? That was a load of bullshit. If it was such a concern, why didn't they mention it weeks ago?

Lesson Learned: I wasted about 3 weeks of time chasing this client around, at a probable loss of around $3,000 in billable time. If you sense you're getting the run around, cut your losses and move on. There are other contracts out there with more reasonable clients.

What do you think about my experience? Do you have any additional lessons that would help guide a newbie consultant? Talk back!