Why are proposals always so long?


Many customers have asked me why proposals always seem excessively long. This is often the case early in the process, when the buyer is simply looking to engage a new system integrator. Even if the customer does not ask for fixed price or fixed scope and keep the tender at less than 10 pages, many system integrators and vendors respond with proposals that are more than 100 pages (10 times longer).

Naturally the ideal scenario for you as a buyer, would be that all the received proposals were of a high quality, but that is rarely the case. Even in these challenging times, most bidders deliver copy-and-paste jobs and have simply added lengthy standard responses to each requirement. Sales people - like many others - are lazy, and rather than producing fresh, concise, case-specific material, they often add a bunch of ultimately irrelevant files; appendixes with product datasheets, annual reports, training courses, case studies, project methodologies, corporate background and history are not rare.

As a customer you want to make sure that you treat everybody fairly and provide a reasonable cause for disqualifying a bidder. However, reading through thousands of pages is very time-consuming.

In my view, you should indicate early on that you will simply disqualify any proposal that is longer than your tender. If the vendor does not have any more respect for your time, and are unable to summarize their qualifications, you should look for somebody more capable. Call me old-fashioned, but I would also disqualify a bidder with too many typos. If the bidder is unable to start off with high quality, what makes you expect that the quality will come later?

Janus Boye

Janus Boye
CEO and Head of Research

As founder and managing director at J. Boye, Janus has grown the business from an office at home in 2003 to an international operation today with members in Europe and North America.

Janus is a frequent speaker at industry events and chairs the renowned J. Boye Conferences held since 2005 in Denmark and since 2009 in Philadelphia, US. Among the organisations that have recently called upon Janus' expertise are  local government agencies, the UN in New York and companies such as Brother, Carlsberg and Red Bull.

10 Responses to “Why are proposals always so long?”

  1. I agree on the limit concept, but not the size. I think that customer should consider how long it takes to answer each question and then add 2 pages. One page for company overview and one for an executive summary. The customer shouldn’t dictate the length of either, but should allow for their inclusion.

    I find that a good response is typically 1-2 times the length of the RFP, not counting appended resumes and other references that may have been requested. Much shorter and the customer may have trouble determining if the bidder has any idea what they are delivering. Longer makes my head explode as either a reviewer or an author.


  2. Jon Marks says:

    Well, being an SI I guess I have to comment. I agree the responses should be short. In particular, it should be easy for the reviewer to find the salient pieces, not have to wade through reams and reams of crap.

    You are completely correct that a lot of the material is cut-and-paste Boilerplate. It isn’t unheard of for customers to see another client name in the response when a search and replace went wrong. I also always check the document properties. You’ll be amazed what you see in there. However, sometimes an SI needs to include this material. For example, we’ll see questions such as “Detail your project management methodology”, “How do you ensure your system is secure” or “outline your testing process”. In order to be thorough, you need to say a lot. However, I believe the answer to this is to include the revelant document as an appendix (despite what you say in your post). For example, we’d include our PRINCE2 variations, our Security Policy or our Testing Process document as stand-alone documents not customised for the client. This makes it obvious that it is a standard document, and the client can choose not to read it. Often it is more important than we can demonstrate that we have such a document or process. The contents are secondary. Generic case studies or references should also be an appendix. Everything in the main document should be concise and case-specific.

    Asking for Fixed Price / Fixed Scope, as Janus mentions, is a sure way to get an unwieldly response. While I appreciate that a client has a budget and a set of requirements that need to be met, it is impossible to predict all of this before a project even starts. So the Systems Integrator needs to define the scope as completely as possible (it is never complete), and state hundreds of assumptions to set expectations, and cover themselves should things turn sour. Either of the two alternatives make a response far more sensible:
    - fixed budget, variable scope: We can guarentee a resource pool and duration, and will prioritise requirements as the project progresses. I believe this is the best way to get value for money. The time saved from the death-by-over-specification is directly translated into more features for your system.
    - fixed scope, variable budget: This is also workable. The SI will fixed price a “requirements” or “definition” phase and give indicative costs for the completion of the project. This prices are then firmed up after the requirements are clearer.

    Other RFP items that can cause a verbose response:
    - Creating a pricing response matrix that doesn’t really make sense for everyone, but is designed to allow Apples-for-Apples price comparisons
    - Not setting any boundaries so a supply has to cover all options. For example, it helps us enormously if we know your IT team will only support a Microsoft or J2EE solution. One less option for the response to consider.
    - Not specifying clearly which services are in scope for the RFP. I love seeing negatives in an RFP. If I see “creative design will be done by partner X” or “we already have a hosting partner” let us keep things more focused.

    And for the record, systems integrators do not like having to produce long responses. It costs a lot to produce them. As a very rough guide, the amount of effort spent on “business development” (proposal + pitch + other) is typically between 5% and 15% of contract value for most agencies, rising when creative work is involved. Do the maths – it’s expensive for us. No wonder our rates are so high ;-)

    I have been planning to write more about this kind of thing on my blog, but keep getting sidelined. I wish all these acquisitions would stop ….

  3. Sara Redin says:

    Here is an idea: Just tell the Vendors and SI’s that any information introduced after a certain fixed amount of pages into the proposal will be disregarded. That will encourage bidders to answer your questions up front and still be able to include loads of appendixes.

    If you receive a proposal where you can still see the name of the client who received something on the same template last time your vendor or IS went pitching, use that in your favour: Call that organisation and ask them about their project and their choice of vendor and SI. It might be a very effective way of learning about a solution similar to the one you are asking for…

  4. Lokesh says:

    I agree with you that SI and vendors respond proposals that are more than what actually is required. I truly understand that concise content should matter and focus must be on the solution approach. However, from an SI perspective, I know there are many areas where you have to display your company and solution approach in one document. Since the response plays a critical role to get the business, SI’s or vendors usually focus on defining project boundaries, implementation approach, solution architecture, governance, change control, effort and cost estimations, past relationships and what not.
    There are enough possibilities where the RFP does not have enough info or say customer itself do not know what the scope is, in that scenario SI’s usually tries amplify the known requirements, and add design approach to the response. Forget about SI’s adding design parameters, I have heard of some “technical” customers, explicitly asking the “technical design” of the proposed system. Considering these things, I can understand why the response becomes so big.

    On the contrary, here is what happens when customer circulates a 2-3 pages of RFP :-)

  5. Chris Regan says:

    You know, for me, it’s not really about the length of the proposals we receive, but it is very much about the quality, the attention to detail and the evidence of a specific effort to answer any specific questions we may have asked.

    I’m happy to read through a long proposal if it’s specific to the brief or RFP we may have put out. If there are standard documents and approaches to questions like ‘What is your preferred project management methodology?” or “Please provide details of your testing policy/approach”, then again, I’m happy for those to be attached as appendices to the proposal. At the end of the day, if we ask standard generic questions, then we as clients should expect to receive standard, generic responses!

    However, one thing I simply won’t accept is a poorly presented or poorly checked document. Spelling mistakes, typos or simple things like a badly bound proposal will inevitably lead me to immediately discount a proposal before I’ve read so much as a word. How can I expect an SI or any other prospective partner to provide anything like the level of service or commitment I want if they can’t even be sure to cehck waht tehy put in there docuemnt?

    Beyond that I think we as clients have to take some responsibility for the quality of the proposals we receive. If we take the time to produce a clear, well thought out (and of course, well presented) brief/RFP, then we should expect to receive well thought out and well presented proposals of a length that was either necessary to respond properly or as we specified. Everything else we can, and probably should, file in the bucket shaped object with a bag in just next to or under the desk.

  6. Neil Potter says:

    Some really interesting thoughts and responses here and agree a lot with what Chris Regan says – quality, relevant supporting evidence and carefully thought through answers that relate directly to the questions being asked are key to successful proposal/tender response writing. (too often I’ve seen individuals write things they want to tell the potential client rather than what the client really wants to find out).

    Jon’s comments about copy & paste made me laugh – unfortunately that happens a great deal. These things often take bloody ages to write and without locking yourself in a room for a day and ignoring phone calls, emails and Twitter it’s hard to come up with compelling answers that aren’t copied from the one you did last time. (and in all honestly, a lot of these things ask the same questions – especially public sector ones!). — I think I’ll be checking the properties next time Jon!! —

    Pricing up a project through a proposal is always tough. I believe too many clients don’t get it that you cant just pluck costs out of the sky without putting in the ground work up front. Vigorous requirements gathering will dictate the real complexity/scope of the project – so shouldn’t this cost be the most vital for the client to consider. Secondary to that, a rate card for the actual work (in theory) should be enough – shouldn’t it?

  7. [...] unnecessarily long tender will lead to very long proposals and may ultimately push you into buying an overly complex and expensive [...]

  8. [...] I hope you get many good, but not too long proposals! [...]

  9. [...] mock vendors on several topics on this blog, including their non-constructive habit of sending very long proposals. When I yesterday received a 122 page RFP for review from a higher education institution this [...]

  10. [...] an elaborate criteria driven scoring system, it will inevitably be time-consuming to read each long proposal. Naturally, usability is critical, but how will you score it? And how about intangibles, such as [...]

Leave a Reply

Most popular posts from our blog
August 12, 2009 by Janus Boye
Selecting the right CMS is not an easy task with; there is in excess of 1,000 vendors in the very dynamic CMS…
February 16, 2010 by Janus Boye
All modern CMS vendors claim to be capable of delivering content to mobile devices. Some even offer additional modules to make the…
March 21, 2011 by Janus Boye
You may be impressed by some of the features during a CMS product presentation, but in reality many of the features that…
Recent comments
April 8, 2014 by Bertrand
I would include the Apache Sling website in this list ( ) as it's what powers AEM. Understanding the…
April 8, 2014 by Scott Liewehr
Great resource, Janus. And thanks for the mention.
March 15, 2014 by John
Their site may not even be a CMS but more of a custom built web application. Also, how do you…