Welcome to the second article in the ‘Commercial Proposal top 10 must Dos’. In this article we explore the way in which you may need to build your deliverables and the important of benefits focus in a proposal.
- Do we know what we are planning to do? – Deliverables/Outputs
Be Clear – There are organisations I help who start with ideas and developed understanding in a proposal, having been mostly diligent in numbers one and two of our top ten. The next stage of knowing what you are planning to do though requires finesse and skill to gauge the customer’s expectations. I would first advise those drafting the proposal to avoid the following quote, which is a caricature of the samples I have read over the years.
“this proposal sets out to strategize the delivery of an open ended conversation in research potential that will illumine the growth anatomy of the data cave industry in Peckham. In addition, we will expand this globally, based on feedback and 5 completed questionnaires to create a thought cloud nuance engine of the data cave that filtrates hydroponically the outputs of the mission to the wider global markets.”
Perhaps I over-egged it a bit. Apologies for any offence caused to Peckham. I have family there so they understand.
The point is (I hope I got that across) say what you are going to do and nothing more. If you can’t deliver on any of the above statements, then the customer may be calling you during delivery of the project to ask why things weren’t delivered. Try working out what is being delivered from that statement and managing the expectations with the client in relation to it. Impossible. To be honest, if they let that statement remain during contracting then perhaps you shouldn’t be doing business with them in the first place.
More specifically for new business, innovation and new technology the proposal may need to speak more to the relationship. Use terms such as ‘establish’, ‘explore’ and ‘discover’ where that type of enterprise prevails. As with points one and two in this blog I am deliberately focused on the building of relationships through listening to your client and therefore building the proposal one step at a time. For that reason, your organisation may be wise to show caution in the deliverables statements.
For example, let us say that your potential customer wants to innovate and use information to increase rate return on invested property by being able to know where and when their properties are ending or coming to an end of leases etc. They are currently struggling to know where to start. You are a company that can meet part of the requirement with some data prototypes supported by some relatively heavy data science to model the data. However, you are not equipped to undertake the other potential (and I say this carefully) elements to hold workshops and open-sessions with stakeholders etc. You see this is needed but have not qualified any third party help to do the latter stakeholder piece. You think you will be able to do it but it’s not an affirmative. Either qualify it with the third party or gain principled agreement or put it into the proposal as a ‘potential’. Don’t assume you will be able to do it. I have seen some proposals fail when third parties become over committed.
Less is more – this statement can be misleading to a point and lead you to suggest vagueness and ‘blarney’ but ‘less is more’ should be considered when your proposal is less clear on what may be achieved and is exploratory. I am not a great fan of ‘less is more’ as it can lead to misinterpretation which then requires unexpected overhead from your organisation to ‘walk statements backwards’ when things go wrong.
Points one and two of our ‘top ten’ may have identified the problem or opportunity and market but perhaps not all of the solutions are clear. Therefore, play particular attention to ‘less is more’ in your approach. If done well, ‘less is more’ leaves your proposal with opportunities for combined answers to “do we know what we are planning to do?” and critically an opportunity to sell more. Here is an example.
A hospital customer is engaging you to “improve bed turnover by 10% in year one, rising by 10% per annum for the term of the contract”. Imagine the contract is for three years and you have to find 30% of improvement. Bed-turnover is a bit like a restaurant turning over tables every two hours to get more customers in to spend money. In the same way hospitals need beds all of the time and getting patients discharged is a constant drain on the resources of the hospital. Your organisations software, when installed can provide vital patient throughput metrics and decisions support to move the processes of admission, bed availability, transfer and discharge onwards. Your software does however rely on staff using the software and abiding by the system rules to be effective.
Remember the opening statement that the hospital is looking for your organisation to “improve bed turnover”. A great statement in broad terms but it must be qualified by the combined deliverables of committed staff abiding by the system rules. If your organisation signs up to be the sole provider of that statement; beware. You can’t succeed without the hospital’s commitment. It is a joint effort.
Wherever you speak to this be clear about the statement in terms of who is contributing to it. Hence why I am less a fan of the ‘less is more’ principle when it comes to deliverables. And don’t forget; in this scenario you are likely to have sold a number of service lines as part of the deal. Local systems configuration, data migration, systems integration and training et al. I would advise you remember to include communications and stakeholder engagement in your service lines of the proposal to ensure the message of combined effort to improve bed turnover is sold to all involved. Secondly I would urge you have professional services consultancy in your back pocket to up-sell as this may potentially also help to bring success.
If you don’t reach the targets because staff ignore the system (this happens a lot) yet you didn’t state the combined effort and the hospitals deliverables to make staff use it, then you may be deemed to have failed. The ‘less is more’ has defeated you. And you may not get paid if the contract is ‘performance based’ and is linked to payment milestones. Like a tiger with no teeth you will have to the suck the contract to death to get the money out of it.
Expectations – is that what we heard? Is that what I said? Language and description is key here and if you are going to announce deliverables and outputs make sure they are understood by the customer. “I thought we agreed you would build a data platform for our organisation to draw in disparate data sources and provide the ability to data mine at extended levels. Whats a data cave anyway? Is that the same thing?” This is particularly unhelpful. It’s like promising Cider and giving them apples. It is cider………kind of, just not in the way the customer expected it.
Makes sure you manage expectations on lengthy or complex proposals as your BD leads change during the process sometimes, or a part of the proposal is written by someone else without the author reviewing, such as one of your development teams. If you are the author……then be the author. Don’t let anyone alter the proposal and let it go out to the customer.
Planning – This may seem obvious but I put the word “planning” into the opening title because it is here that you should be testing the “to do” bit. I have seen far too many proposals that have established the deliverables the customer wants, after listening well and understanding the market conditions, to then use the agreed promised deliverables without having sought further qualification internally that this can be done in a timely fashion. The worst thing in a proposal is to say you can deliver then have to go back later and say “er…..may take longer”. Far better, particularly with innovation and new technology, to qualify quickly the high level timelines of deliverables early on as this will keep your internal delivery teams happy and ‘stitched in’ to the deal. Nothing worse than disgruntled internal teams taking ‘umbrage’ at not being consulted.
In less complex and innovative environments, you should have a much better qualified set of timelines for delivery, particularly if you have been repeating this over and over for years. You get the hang of it. For innovation proposals though take more care to plan and manage expectations of planning with the customer and your internal delivery teams.
- Do we know what success looks like – benefits/outcomes
OK – probably my biggest bug bear of all the sections in a proposal. The place I get most frustrated. The most important section to get right. The section that brings together why we are doing this.
Don’t confuse an output with a benefit. They not the same – Benefits are not something to ignore and when writing them please take your mind off the sense that these are effectively deliverables in other words or outputs. The former are objective elements of a proposal. We delivered or outputted something. Fact.
A benefit is effectively a subjective assessment by those involved that they gained from the deliverables and outputs. For example, imagine deliverables of a proposal would be “a refuse measuring tool prototype attached to waste bins of local shops and residents of a certain area that can measure the level of refuse in the bin from the outside”. The output was then stated as “to produce a combined ‘heat-map’ of refuse levels to inform demand analysis for refuse collection”.
The benefit should be something like “to lower costs of refuse collection by optimising schedules”. Coupled with perhaps other benefits such as “reduce pollutant emissions of public service vehicles”. You may have set out to provide the first benefit but you have also delivered an inferred or accrued benefit in reducing the amount of public service vehicles on the road. That may then also infer/accrue to other strategies in the local council to improve air quality.
Remember when doing this though to be sure what is a direct benefit and an inferred/accrued benefit. The monetary value to each benefit should be clear and tangible and don’t double count. Classic mistake.
Benefits shouldn’t be long winded and open to interpretation too much. They should though be linked to the deliverables and outputs. Sadly, the latter does not happen enough.
Know who the beneficiary is and who owns the benefit – Who owns the benefits? The ones delivering? Nope. Those receiving own the benefit and if you don’t tell them they have received it they may never know. Focus in the proposal on communicating the realisation of benefits and what is required to take part in realising a benefit. It is not enough to state the above benefits in a list (e.g “to lower costs of refuse collection by optimising schedules”) without mentioning who benefits, how it is delivered, when its delivered and how it is measured. You may want to refer to a benefits realisation process in your planning cycle to reflect this and a simple benefits profile in your proposal in grid summary with the following headers as a minimum. Don’t go too detailed in the proposal but show that you understand the concept.
|Benefit Type||Benefit Statement||Delivered as a result of||Measured by||Benefit Owner|
|Financial||To lower costs of refuse collection by optimising schedules||a combined ‘heat-map’ of refuse levels to inform demand analysis for refuse collection||Reduced revenue costs for ‘refuse runs’ by 5%.||Director of Finance|
|Environmental||To reduce pollutant emissions of public service vehicles||Less vehicles on the road. (accrued).||AQMA (Air Quality Management Area) readings improved by 10%||Residents|
A full benefits profile and realisation process includes other columns such as inferred and accrued etc. and is not required in the proposal but at this level of proposal a summary is workable. If you remember the idea in our first article, of building confidence with the customer that your organisation listens and understands what is wanted, this grid speaks volumes for laying out the true benefit you hope to bring as a result of this and conveys your appreciation of the customers desired benefits.
From an innovation perspective this also allows your organisation to reflect the benefits to your business growth or product research and speaks to the shared inputs and outputs.
Note the content in the section on ‘Measure by’. It is particularly difficult to measure some benefits but using key words such as lower, reduce, increase and expand et al will require you to measure the degree. Don’t shy away from this. Its not easy but it is important in my opinion, particularly around innovation, shared contributions and collaborations. There are many parties with vested interests in those scenarios. In this scenario push the Finance Director to tell you what success looks like. He/she may have a monetary figure or percentile that will be a benefit. It also links to the payment milestones.
It is even more difficult when something bad that was happening has reduced or gone away altogether. Its very difficult to quantify these ‘silent’ benefits but your proposal should speak to them and articulate the tensions and difficulties in measuring them.
Disbenefits – I know of many IT systems installed in hospitals that are effectively ‘white elephants’ as the benefits for improving healthcare required such significant data entry that nurses and doctors spent more time entering data than they did caring for patients. They were meant to be real-time systems that kept up with care but are effectively storage units of ‘after the fact’ data entered by clerks at weekends to keep managers happy. In this instance they are a disbenefit and you should show caution that what you are delivering does not cause the opposite effect. I am pleased to say some of those companies who delivered those behemoth IT systems have learned their lessons somewhat and innovations in real time locating systems that pre-empt patient flow and follow (in the positive sense) nurses and doctors, building automated information for care, are actually now starting to bear fruit in a benefits sense.
The commercial strategy – I have seen many proposals without a section on this. Why? Because too much focus is on ‘shifting boxes’ and “we don’t really want the customer to dig deep into the proposal and actually benefit from it. If they do then we are done and we can’t up-sell anymore as they are completely satisfied. We don’t want them completely satisfied though do we?” This is a caricature of course and the reality for most commercial enterprises is less inclined towards this.
However, this type of mentality does exist and in some ways is a commercial approach that works: i.e give the client slightly less benefit…….just enough to hook them to extend the up-sell a bit more. Total satisfaction as advertised on your website comes not from a single proposal but perhaps many. I don’t really have an issue with that but at least if you’re going to take that approach put down the benefits you can deliver on in this proposal at some level and spread your total realised benefits across a number of proposals.
There is a great deal more to learn about getting your deliverables right and expressing your benefits clearly than this blog represents. Both can be delivered with equal clarity but its your decision. Your organisation’s philosophy will dictate how these two elements are expressed and you may therefore be governed to say less or to structure in a certain way.
My advice though, particularly for those drafting proposals that speak to innovation and new technology is to allow room for deliverables to be better explained and to be as clear and as precise as you can. Do benefits the right way. It speaks volumes for your credibility to a customer that you have listened and understand what is important to a customer.
Our next blog speaks to the strategic fit of the organisations involved and ‘why them’, together with an exploration of the importance of contributions expressed from parties investing in the proposal.