Today, I feel like a massive RANT.
Although I’d rather book myself in for a root canal than get involved in creating proposals or responding to RFPs, I do find myself in this position frequently these days and I’ve yet to develop a suitably sustainable perspective on these things to make them enjoyable. Hell, forget enjoyable as a goal – I’d settle for a beige sort of feeling rather than the darker colours I tend to find myself wallowing in during those times.
And here’s why – proposals suck. The act of building them… sucks. The process they are a part of… sucks.
Why? Well, let me give my completely objective and not-at-all bitter take on how this stuff works.
Step 1: Company A wants some stuff done. They decide to go to market for whatever reason. Their governance mechanisms demand some form of RFP process to ensure fairness and transparency, etc, etc (hint: it doesn’t and it isn’t, but that’s another story entirely)
Step 2: Company A taps the shoulder of some poor schmuck(s) to write the documentation describing the work to be done. This document is usually 40% boilerplate with the rest being the gristle of the problem to be solved. Generally the authors of these documents are domain experts so understand the problem domain quite well. However using domain experts to explain complex problems to people who don’t share that expertise also sucks because:
- They have sublimated all the obvious questions naive people would initially ask and present the information at a level best consumed by other domain experts
- They are forced to filter their knowledge through the ultimate comprehension mangler that is… written sequential documentation
- They are often not naturally good technical writers, so I’ll leave you to your own conclusions about what impact this has
- No one ever thinks to “test” the quality of the documentation against typical end users
Step 3: Documentation is distributed to interested parties for response by a certain time. Some RFP processes include open Q&A sessions with all the potential respondees which inevitably turn into variations of pissing contents (i.e., who can ask the questions that intimidates the other parties in terms of specificity, detail, prior knowledge, etc) or exercises in studied banality (i.e., don’t ask anything publicly which might reveal how we’re thinking about the solution).
Step 4: Respondees digest documentation and subsequently devise solution, estimates, timelines, costs, staffing models, risks, etc., etc. Now this is where things get really interesting because I’m often part of the “devise solution plus estimates” side of things and a whole new circle of Hell must be navigated to survive this phase. The natural tensions are:
- You know that at least two stakeholders have unrealistic expectations about the accuracy of any estimates produced; Company A and your own “pursuit team”. Often people talk about +-30% as though this is a wide enough variance at this point in the project. All empirical studies I’m aware of around estimation accuracy suggest otherwise. How many times have I come across a line item in the RFP document that could range anywhere between a NOOP and a 6-month piece of work in itself depending on semantics or unstated context? How many times do literally dozens of similar statements occur in these documents.
- By definition, the accuracy of the estimate can never exceed the accuracy of the statement of the requirements. See my previous comments about the likelihood of these requirements being accurate and/or unambiguous.
- There are three main paths you can agree to take to resolve these tensions, although none of them satisfy all the groups involved. You can Optimise for Initial Success (i.e., winning the work) which seems to involve making the quoted numbers low and tightly bound to give the impression of thrift and confidence through an illusion of accuracy. This process is made considerably easier if you know what the budget for the work is. You can Optimise to Inspire Confidence by just giving an unreasonably small range for your quotes, implying we have sufficient control over all the variables required to predict with this level of accuracy (hint: we don’t). Alternatively, you can Optimise for Prolonged Trust (between you and Company A) by responding with the numbers that initially estimation gives you and with a suitably large variance to reflect the reality of project physics. IMO, this last type of response doesn’t lead to a lot of success (this also sucks).
Step 5: Respondees send response to Company A who now have the unfortunate task of reading, understanding, comparing and ranking n proposals. Sometimes there is a shortlist process and you get a second bite at the cherry and refine your response. Rarely is there any formal feedback process from Company A back to the respondees apart from the tersest of communications saying you have been successful or otherwise.
If you’re unsuccessful, I believe the required behaviour is to either justify the response by saying you didn’t want the work in the first place or rationalise the decision by saying that whoever won did so by lowballing the price with a strategy to change manage their way to profitability.
If you’re successful, then the once the project gets started, the vast majority of the assumptions you made to justify your estimates will be immediately or eventually invalidated rendering the basis of your estimates and costings null and void… this part doesn’t suck so much 🙂
Next proposal – BRING IT ON!