ABC of a Quotable Software Project Brief

Over the past 6 years I’ve had conversations about custom software development projects with tens of clients from dozens of different countries. Each of these meetings was slightly different and so were the questions I was asked. However, if I had to put together some sort of an FAQ, one particular question would probably  undoubtedly top the list. Any guess which one it is?

OK, and how much do you think it will cost? You know, just roughly.

Or something like that... (I never thought such a plain thing can be asked in so many ways.)

This wasn’t a tough puzzle, was it? People want to know how much a product or service will cost. First of all to determine whether they can afford it all and once it’s confirmed they can, they still need to manage the budget. Therefore, the desire to know the price upfront is fairly understandable regardless of what they buy.

I wish I had been able to provide an honest and true answer every time I heard the question, but I could not and do not expect to be able to in the foreseeable future. At Software Brothers we build custom digital products, often from the grounds up. In order to create the product, we involve a team of usually 5-10 specialists (designers, developers, testers, a project manager) and together with the client work iteratively until a desired effect is achieved. It is a creative, agile process whose length and cost is difficult to forecast at an early stage of the conversation.

Difficult, but not impossible. Let’s then try to establish what a software development company has to know in order to respond with a reasonable quote, or - in other words - what a quotable project brief should consist of.

The Basics

In the first place, it’s worth to say what you would like to create and what kind of problem you want to solve (with this new product), hence it’s best to share a high level product presentation or an (investment) pitch deck. A vast majority of people I speak to already have it before they involve a software house in the conversation, so usually no extra effort is needed. A software house is not just a group of engineers who will write thousands of lines of code for you - it’s a company who must understand your vision and be able to provide a business value too. If they don’t bother to grasp what you’re doing, it’s a sign you should go somewhere else. In case you have IP concerns before sharing the project details, you can always ask to sign an NDA.

Description of Functionalities

There’s no need to spend days writing a very detailed project specification. First, a Project Manager appointed by the software house will be doing that anyway or at least will have to adjust the one provided by you (if you cannot resist the temptation) so that it meets the company’s internal guidelines. And second of all, you can be (almost) sure the scope will change, at least to a certain extent. From experience, I can say that the first version of the products clients decide to build is usually around 30% different (mainly smaller) than the very first concept submitted for quotation.

What would make the most sense for the first estimation is a list of all the functionalities you want to have. They can come in the form of user stories (if you don’t find it too time-consuming) or just as a bulleted list of “raw” features, e.g.:

User Mobile App

  • Sign up (via email or FB)
  • Log in
  • Creating Profile (name, last name, phone number, taking a picture or uploading from gallery)

Showing a map (Google Maps or some open source alternative) with the current location etc.

It is, of course, most efficient to write them down “chronologically”, thinking of the standard and uninterrupted journey user will make from the moment the app is downloaded (or website opened etc.) until a desired action is successfully performed - depending on the nature of your product this would mean that a purchase has been made, an appointment has been booked etc.

Do not expect to cover all the potential user behaviours or edge cases, it’s not the time for that. Instead, try to focus on a “happy path” an average, ideal user will take. Having that information, an experienced dev shop will be able to put together a list of epics and user stories as well as make (and describe!) the assumptions that had to be made. Once this is ready, each use story (i.e. functionality) will be estimated separately (usually in work hours). This way it will be easy to see how removing or adding features impacts the overall quotation.

Visual Materials

Visuals are always very helpful during the estimation process and probably even more helpful during the very initial prototyping (or rather brainstorming) phase, simply because they allow to structure the app / web product in a coherent way. I am by no means talking about creating designs or even interactive (clickable) wireframes - though if you feel comfortable doing that then go ahead. What I mean is a very rough, handmade draft of all the main screens you envision your product should have. Again, ignore some “extreme” or unlikely user behaviours for now, focus on the features you want to provide and put the screens together in a logical user flow. Remember to focus on the content, i.e. functionalities and ignore the form, e.g. whether there should be a hamburger button or a navigation bar at the bottom. This sort of mockups - or however else we decide to call them - may look like those below.

You may think they look even a little too pro (it’s a quick app concept draft by our UX team), but do not hesitate to sketch your app or web product even if art class was the one you’d skip most eagerly when in your teens (I fall into that category myself).

For the sake of clarity, make sure you mark the user journey by drawing arrows from one screen to another and feel free to add a few words of comments to each step, especially when things are not self-explanatory.

What if it’s not a greenfield project?

So far we’ve been referring to a situation where the project starts from scratch: not a single line of code has been written yet. These are ideal circumstances for a software company to get involved because they will be able to plan the project “their way”, select management and development tools (on average there are around five 3rd party SaaS tools used throughout the development) and in some cases, usually when the client is non-technical, choose the technology stack (programming language, database, server infrastructure etc.).

If the latter is the case, make sure that such decisions are consulted with you and if the fancy words you hear are all Greek to you try to seek a friend’s (or a friend of a friend’s) advice just to make sure no obsolete technology stack is offered to you. However, the sword cuts both ways and starting from scratch also means the company you involve takes ownership for the whole project and won’t be able to “blame” the previous software house in case something’s broken.

Situations when clients consider involving a (new) software house while the project is already under development are not infrequent - in our case approximately 50% of the RFPs we receive are related to ongoing or uncompleted (and interrupted) projects. The reasons vary, but the most common ones are these:

  • the project turned too big and/or complicated for a small in-house team
  • external development team did not perform well
  • new requirements appear and the current in-house team does not have the required skills (e.g. you need a mobile app and your developers specialise in web development only).

If any of the above, or yet some other, circumstances take place, providing a quote requires a bit more effort, but is still doable. In that case, the very first thing to share is, just like with a greenfield project, a pitch deck / product presentation. As the next step, a software house will want to get the following:

  • Project specification (the form may vary, but it’s usually User Stories with comprehensible acceptance criteria)
  • Access to the project management tool that has been used so far (JIRA is probably the most widely used one, it’s also Software Brothers’ main tool for daily management)
  • The complete UI design, ideally in the form of a clickable prototype
  • Access to the code repository (usually stored on GitHub or Bitbucket)
  • Access to what has been built so far (assuming it has been deployed and is available on a production or staging environment)

Having the above will enable a software house to understand the project progress by comparing the end product specification against the current “state of things” and thus estimate the effort (and cost) required to complete the project. As a kind of by-product of this analysis you should also expect a brief review of the quality of work that has been done so far - this should cover the overall architecture, technology stack, code quality and UX.

To sum it all up, it’s worth to remember that quoting a bespoke software project requires not only technical knowledge, but also a decent level of business acumen. Your task, as a client, is to provide as much information as possible, but it’s extremely important that this information is well-structured, coherent and up-to-date. This will not only make the dev shop life’s easier (yeah, who cares?), but will allow them to be as accurate as possible. You will likely ask a few companies for a quote and when it’s time to choose your tech partner it’s good to be sure the estimations they provided are based on a solid and comprehensible brief.