3SD handbook

Proposal writing

Draft proposal

Once we have received feedback from the client, we want to collate the answers into a formal proposal. This should be done following our epic process and guidance on doing epic estimates. Just a rough description of the epics are necessary, we don’t want too much detail at this stage (this will be filled out as we carry out the discovery and design phase of the epic process).

It is important to also consider our own past experiences with projects and successful and unsuccessful proposals we've done in the past - see tips below.

As you write a draft proposal, it is important to check our capacity and when the work could be carried out in our Pipeline.

Before sending to the client for feedback, a colleague should review the proposal, especially epic estimates and the proposed budget and timeline. We may also want to give the client a heads up on what they will be receiving / highlights / give them a chance to ask any questions etc.

The amount of time to allow for this stage will really depend on the size of the project and proposal. As a rough guideline, allow for a minimum of a day for this going up by a day per £10k worth of the proposal e.g. if the proposal budget comes to £30k, allow for 3 days.

Tips on how to put together a successful proposal

Having done a fair few proposals, there have been many lessons learned, especially from the less successful projects that have ended up costing us money. At times this was due to setting unrealistic estimates, and other times due to poor project management and not keeping track of the budget and timeline, thereby making it harder to keep a good relationship with the client. Sometimes it has been more to do with the client and their demands or unrealistic expectations and budget constraints. But in either case, having a good proposal from the get go can help minimise these types of issues, and the below list of lessons learnt should help with this.

  • Don’t expect too much from the client, even when they say they can do a lot of the work, their skills might in fact be limited and we should either anticipate that they will need support and it will take longer to do, and maybe offer some training.
  • If a client asks us to reduce the budget, make sure they are aware of the tradeoffs and if they change their mind once work has started, go back to the budget and make sure this gets adjusted.
  • Have someone double check the proposal for mistakes (especially the estimates and budget figures).
  • If the client insists on using technology that isn’t part of our technology stack, we need to carry out a tools audit / discovery phase and increase the estimate to cover the uncertainty of the unknown technology.
  • Doing an audit as a pilot project with a new organisation, especially one where we are inheriting a system that hasn’t gone well with another provider, is always a good way to suss out the system, and also what they are like as an organisation to work with, and a way to better spec out a realistic proposal. It will also allow us to pick up on warning signs that the organisation might be on a too tight budget e.g. the fact that they hadn’t upgraded for the past 2 years (was this because of budgetary constraints? Indication of the complexity of the system?)
  • Using the Client wide approach helps, where we apportioning back ‘research’ work to billable client work in the future
  • Add in a bigger buffer in the estimate for high risk ‘new’ technology project, and not be too optimistic.
  • If we aren't using tools from our technology stack and it's a bit of unchartered territory, including discovery work on the ‘technical’ / solution side of a project e.g. an audit of the tools we think we could use, might be appropriate.
  • Sticking to a timeline so we don't feel compromised in discussing issues with the client is important so doing good discovery and planning at the start of the project, and highlight any issues in an epic estimate early on and discuss this with the client.
  • [LINK TO] data on past projects and how long typical chunks of work (e.g. theming a website) took, to help us with estimates in the future.

Checklist

  • The proposal epic(s) cover all areas mentioned in epic descriptions
    • The wider business context
    • What we will do
    • Dependencies and constraints
    • Discovery work
    • Client involvement
    • Risks
  • The proposal epic(s) include time for:
    • Discovery
    • Design and prototyping
    • Configuration
    • Development
    • Testing
    • Incorporating client feedback
    • Documentation
    • Deployment
  • The proposal text has been reviewed by a colleague
  • Estimate(s) are realistic
  • Estimate(s) have been reviewed by a colleague
  • Add the proposal into the pipeline
  • Send the client the draft proposal (as a 3SD branded PDF) and ask them for feedback

Proposal feedback

Once we have a draft proposal we want to present this to the client and talk them through it, to avoid any misunderstanding of the proposal. It will also allow them to ask any initial questions they might have. After which they can digest and work through it themselves and give us any feedback they have. We then want to incorporate this feedback into a final draft and answer any questions they may have.

It is difficult to predict how much time this stage will take as it will depend a lot on their feedback and whether we need to make a lot of amendments to the draft proposal. Allow ?? for this.

Checklist

  • Schedule in a meeting with the client to present the draft proposal
  • Have proposal approved by the client
  • Management buy-in / develop relationship with CEO

Once the client is happy with the proposal, we move onto the final stage of the process which is to formalise the proposal in a contract.