The humble project budget proposal might just be one of the most underrated tools in the industry.
Software agencies spend countless resources and time working on their branding, the website, even the sales deck.
And then, at the end of a long sales process with a new potential customer, they send a simplistic budget proposal, with no structure or story, directly from the excel file used by the team for estimations.
A lot rests on the shoulders of the project budget proposal. Your win percentage and your revenues depend a lot on the proposals you send out.
For this reason, the “proposal” document type deserves a lot more attention.
The problem with intangibles
The big advantage when selling software services is that you can create unique, custom teams or projects plans for every client. This gives you flexibility and an ability to cater to many different clients.
The disadvantage of selling software services is their virtual nature. You cannot touch, smell or hear software projects. Unlike most objects or products that your customers use every day, with software they have to imagine what they will get for their money.
This creates multiple challenges for a vendor, since not everyone is good at imagining abstract solutions to their problems, different people use different meanings for the same words and various psychological biases and emotions tend to introduce uncertainty and doubt.
Let’s do this exercise: imagine you need a new table for your kitchen.
For some reason, you don’t have time to go shopping or search online, but you can write a list of specifications, requirements and have a friend bring you the table, based on their understanding of the request.
Kitchen table specifications:
- 4 people can use it comfortably
- styling: not too flashy
- would look well in a kitchen with a wood countertop and natural wood window frames
- could also be used as a surface for cooking preparation
- would look good with the chairs you already have
- can suffer abuse from children activities without major damage
- can be easily cleaned
If I would give you these specifications, what table would you have in mind?
Is it this one?
I can already hear some of your thoughts when seeing this picture.
“Is this a kitchen table? Looks more like a toy or an accessory for electrical wiring”.
“If it is a kitchen table, it cannot possibly seat 4 people.”
“What about the wood? You said you wanted a wooden table.”
This is how most software projects proposals look to customers.
Without context.
Without reference points.
Some numbers that are supposed to describe something, but you can’t really tell if they are real.
What if you would see this?
The table in use.
How it fits the larger context.
How it can also be used for other purposes.
Detailed pricing information, including other options and suggestions.
This is how a project budget proposal should look like.
A lot more detailed.
A template for proposals
Here is a non-exhaustive list of topics that should be included in a project proposal for software development services:
- Estimations, with breakdown of modules, features
- Estimations level of certainty
- Risks and ways to mitigate them
- Who made the estimations, what previous experience do they have with this technology or business domain
- Details about the tech stack used for the estimations
- Recommended team setup
- Possible implementation timeline
- Financials
- Payment terms
- Type of contract
- Budget (how many options?)
- Process, limitations and constraints
WHAT THIS MEANS FOR YOU
If it looks complicated, it should.
There are too many attributes, variables and concepts that your potential customer needs to understand, compare and evaluate to make a decision.
If you want them to choose you, it’s mandatory that you proactively try to influence how the information you are communicating reaches its intended audience.
PS.
As you’ve probably already guessed, the table in the pictures is an IKEA product.