Edit Home › Business

How to prepare a proposal?

Once we’ve identified an opportunity as “Qualified” (see *How to track contacts & opportunities? and Our sales workflow), we most likely need to produce a proposal to the client. This takes a few steps.

Preparing the estimation

  1. Share all resources from the client. You can save all the documents received up that point (e.g. wireframes, requirements, user interviews, strategy brief, etc.) into a Google Docs folder (WCL Business › Projects › CLIENT_NAME › Resources).
  2. (Optional) Send forms to client
  3. Prepare the estimate and proposal documents on Google Docs. You can copy the templates;
    • The estimate is a simple spreadsheet that allows us to list and describe the features/deliverables for the project. We then associate a work load in days to each item, which gives us the cost. More on that below.
    • The proposal is a much larger document that we deliver to the client. While it includes the estimate information, it also gives an overview of the company, team, strategy, portfolio…
  4. Create a GitHub issue that you’ll assign to the person on the team who will prepare the estimate. To make this easy on him/her to it done, you should give as much context to it (example of this);
    • Context: what is the project about
    • Customer: who is the customer
    • Budget: what is the budget available for it (do not hesitate to be upfront and ask)
    • Timeline: any relevant (e.g. expected launch date, any external event, etc.)
    • Assets: add any relevant assets (e.g. RFP, data diagram, etc.)
      Note that it is important to label your issue properly (most likely to start, Stage: Lead and Status: Backlog).
  5. Assign the issue to the proper person. Depending on the nature of the project, you may want to send this to a project manager, a developer or a designer. When in doubt, ask on Slack who can tackle it,
  6. Outline the next steps. To ensure the estimation is properly followed through, make sure to outline the next steps,
  7. Add the key dates to the sales calendar and book time of relevant team members. You want to make sure we send notice of intent, questions and estimates in due time. You also want to time box the efforts of your team working on the proposal,

You’ll notice that the way we go at estimating projects is pretty simple. A few things about it;

  • There are recurrent items in most projects. Things like QA, documentation, testing, project launch, …
  • The hard part is to identify what the features are and describe them concisely. Once this is done, estimating the work load is pretty easy,
  • We estimate in man/days but don’t get hung up on the details. In the end, this process is mostly there to:
    • Ensure we are not underestimating certain aspects of the project (aka “losing money”),
    • Have a simple medium to communicate our assumptions to the client.
  • We often end up tweaking the budget a lot either to fit the client’s resources or our gut feeling with regards to overall difficulty of the project. Projects always have a lot of imponderables, estimates are all about finding a compromise between what the client can afford and what we feel comfortable getting engaged for.
  • Timing is important you should go fast to answer but not rushing and omitting issues. You should submit the strategy under 5 days maximum (for normal contracts and after last meeting with client)

Make sure to have a look at the Product Development Solutions.

Finalize proposal

Once the estimate is done, you should finalize the proposal you’ll send over to the client;

  1. Drop the budget from the estimate into the “Budget” section. In some cases, it is better to split this section in several sub-budgets for each main milestone/deliverable and give an “Overview” budget.
  2. Fill in the details; title, context, etc.. These should mostly be well understood at that stage as you’ve probably done most of the work when you created the GitHub issue.
  3. Add a strategy. This is often a crucial part of the proposal; you may need to refer to existing resources (e.g. How we design products) and/or work with the person who prepared the estimate to get . Some of our larger projects (e.g. Myanmar elections) feature an extensive strategy with a lot of details and schemas detailing the architecture, technical stack, user flow, etc.
  4. (Optional) “The Wiredcraft advantage”; we sometimes include a section that explains why our team is a particularly good fit. More often than not, we mention projects that are very similar or demonstrate skills crucial to the project.
  5. Share it with the client; once you’ve double-checked everything with the rest of the team, you can share it as a PDF with the client or (alternatively as a view-only Google Doc).