We are supposed to learn from our mistakes. I usually learn from mine. Sometimes that learning process can be painfully embarrassing. I will discuss one that was so embarrassing, I have made sure to never repeat it.

An Internal Project

Several years ago, I was working for a consulting firm that was very good about training and development when consultants were on the bench between projects. This firm had a handful of consultants in that situation and initiated an internal project.

We ran it like a real project. Although we generally executed projects in an agile approach, there was some waterfall approach involved. We defined the full scope up front in order to provide an estimate for the total cost.

The CEO of the firm was going to play the role of the product owner. We met with him several times with business analysts to gather the requirements he had for an application.

We took those requirements and created stories. We then met with an architect and some developers to do analysis of each story to provide an estimate.

From there, we developed our formal proposal to present to the CEO. We provided the approach for how we would execute the project. We described the team and how it would be structured. There was a roadmap with a timeline to set expectations for delivery.

The final component – the end of every proposal – was the cost. We detailed how many hours it would take to design, develop, test, and deploy the application. As directed, we used our standard billing rates that we use for our clients.

I read and proofread the proposal thoroughly. I verified the grammar and the spelling. I made sure it was audience appropriate. I verified the math from the estimates to make sure it as correct. We were ready to take it to the CEO.

The Presentation

The lead architect and I met the CEO in his office. The proposal was a professional looking PowerPoint deck with the company logo and the CEO’s name on it.

We sat down and began discussing the proposal. We briefly summarized the purpose of the application and how it would be used internally. The CEO was engaged as we reviewed each slide.

Then we got to the cost. As soon as we turned the page, I knew there was something wrong. The CEO wrinkled his brow and looked straight at us. “Who did these estimates?” He asked.

 “We did them as a team,” The architect answered.

“They seem very high.” The CEO said, still staring at the numbers.

I was still trying to determine whether he was playing hardball as a matter of training, or if he really though they were high.

The architect went through their process, describing how they broke the stories down and came up with their final estimates.

 The CEO absorbed the information and thanked him when he was done. “Okay. Thanks guys. I’ll review this and get back to you.”

We got up to leave and he asked me to stay behind. When the architect was gone, he looked at me and paused for a few seconds. Then he explained that the estimate to develop this was at least 3 times more than the value of the application.

He turned it into a learning opportunity. He politely explained that if we had taken this proposal to a client, we probably would have been laughed out of the conference room. There is no way a client would consider this proposal seriously.

I walked out pretty dejected. For a moment, I rationalized that at least I had not presented that to a client. But the truth was that I had presented it to my CEO. I may now in fact, never get the chance to present to a client.

After all of the pedantic reviews I made of the proposal; after all of the mathematical verification of the estimates, I failed on one big thing. I had not verified that the final estimate was reasonable. I had not stepped back to ask, “Is this even worth doing?”

Lesson Learned

As embarrassing and demoralizing as that was, I am a better consultant today because of it. When I have an initial meeting with a client, I ask them what their budget expectations are.

If possible, I also try to give them an order of magnitude estimate of how much we expect a project like this to cost. This allows us to see where the client is in their expectations. If they flinch, we can at least consider estimating a minimum viable product that would get them started.

Regardless of any previous conversations I may have had with the client about the cost, I always verify how reasonable our final estimate is. I stop and compare what it might cost for a SaaS solution is one is available. I will often run it past another person who is not so close to the estimating process.

I still check for grammar, punctuation and math in my proposals. But I also spend a significant amount of time to make sure it makes business sense for the client. It is perhaps the most critical component of a proposal.

What mistakes have you made on proposals?

As always, I welcome your comments and criticisms. 

If you would like to learn more about working in consulting, get Lew’s book Consulting 101: 101 Tips for Success in Consulting at Amazon.com 

Image courtesy of tawatchai at FreeDigitalPhotos.net