Pricing is Art: How to quickly estimate a project with barely any info from the customer?

Howdy! 👋 We hope you're doing well during the current times and sincerely wish everyone that things get better. Hopefully the intro of next installment in our mini-series will be much more optimistic. Today we will cover a case that is often encountered and requested by some of you.

When the customer is not too informative

Software project estimates must rely heavily on the initial input by the end customer - the more info you have, the better you can plan everything in advance. Usually a formal specification document is made, some calls are exchanged, and a deal is signed at the very end of the process.

There is a caveat, though: while you and I both work in the IT industry, the customers usually do not. These are people from healthcare, manufacturing, FMCG, government, construction and all other sorts of sectors. They don't have to be used to the way most software projects go. In fact, this might be a very alien thing to them.

Add to this a very frequent case of unresponsiveness: it rarely comes from bad intentions, rather from a lot of work at hand. A big, multi-national entity will usually have priorities, and day-to-day operations & direct customer sales will always take the first spot.

The end result is similar: you will get confused and frustrated with a lack of response to your questions, seemingly moronic inquiries from the customer, endless feature creeps and no fast, convenient way to squeeze the info you need for your proposal. The clock is ticking, both parties are annoyed, and things might get out of hand.

1: Educate

Always assume the customer did not work in Agile and with IT project estimates before. You might be proven wrong quite fast, in which case simply re-evaluate your plans. However, if you have no reliable info on the matter, assume a lack of knowledge.

Then do the hard part: explain and educate. Yes, there will be a lot of questions. Yes, you will have to repeat things many times. No, you will not get a full 100% common understanding in the end.

So did your teachers and professors. You know, the people who guided your education for nearly 20 years. And yet they struggled so you can live a decent life.

Here's some quick tips:

• Prepare a short dictionary of common phrases; Bob Vance from Vance Refrigeration does not necessarily have to know what a middleware is.
• Schedule milestone checks during negotiations: ask if all is clear not just at the very end, but during the process.
• Prepare a common guide to developing software with you: concise, but also comprehensive, and distribute it to customers.
• Invite customers for a quick meeting with the team and show them how they work. If they see a graphic designer scheduling a frontend team meeting, they will understand that seemingly small changes are not always 5-minute tasks.

2: Explain

Whenever you make a statement or prepare a document, describe things in written form as well. Annotations, links, comments and side notes are extremely beneficial for your customers. The time you will lose on document preparation will be gained back with less back-and-forth during the project.

Be patient. Answers questions, but also try to think of them in advance. In you have doubts about a specific phrase or topic, ask a non-technical person you know if that's clear to them and what questions they might have.

Try to gauge the level of confusion: if you think the customer got completely lost or your visions do not align, propose taking a step back and trying to agree on common basics first.

3: Gather, guess and estimate

Let's assume you did you best with even the most overworked customer. You have an idea of what the project actually is, but it is not full and some details are what we often call unobtainium: think toilet paper in January 2021.

Sadly, no mater how much we all try, you will encounter situations where it will fall upon you to fill in the blanks. That's a risky position: any and all errors and bad judgements you make will directly affect the project and be seen as your fault. Not good.

Here's our tips:

• Always assume the worst possible scenario
• Give yourself some wiggle room: prepare a reserve in time & budget in case of sudden changes steming from lack of understatement
• Ask your colleagues & Uncle Google about similar projects. Many software houses have blogs detailing challenged they encountered during development and these might be common for you.
• Industry info is a goldmine, and here we can shamelessly mention that apropo.io features automatic estimation of most typical software projects with industry rates built-in. End of advertisment.

4: Be FAST

Last, but definitely not least, is speed. The longer you negotiate and close a deal, the more annoyed and willing to give up the customer will be. Competitors are just around the corner. Time is running out. The world is ending.

Here's a few tricks on how to be fast and implement our previous suggestions without losing deals:

• Send your proposal as a draft for the customer to accept. Give them a way to comment & suggest changes, ideally more convenient than calling you (like inline editing or Google Docs comments).
• Keep your proposals in a way that is very fast to edit, as it will need to adapt.
• Start with wide pricing brackets and mark them clearly as ballpark figures to be made precise after consulting with the customer
• Do not wait for more info to long. It's in your best interest to have all the details, if these are not supplied, call the customer and ask questions. Treat getting info as a priority as high as 1st contact with a lead.

Homework #3

We strive to make this series somewhat interactive. At the end of each article we will ask you questions ir give simple tasks. Today is such a day.

1. Go to any website where people post project briefs (upwork is a good start)
   
2. Find any project there
   
3. Try to think what is not clear from the brief? What questions would you ask?
4. Would your questions be clear to a non-technical person?

Tip: write down your answers as further reference will be useful!

Stay tuned for the next installment 👋

‍