I was recently asked if I could provide “some figures” by a prospective client. He had sent us a 100-page brief with a bunch of graphics and absolutely no instructions regarding architecture. It was Friday afternoon, he wanted a proposal by Monday morning. Not exactly ideal conditions for providing an accurate software estimate.
Knowing it would be impossible to create an accurate software estimate without client involvement or a better scope of work, I decided to write the following guide to help both development teams and software clients create better software estimates.
The Need for Software Estimates
While software estimates can be difficult and frustrating to craft, they are necessary. Entrepreneurs have strict budget constraints, agencies attract clients by offering competitive pricing, and large companies need cost estimates to get internal buy-in and advance an initiative. Simply put, at least a ballpark figure is needed for almost any project.
For experienced software development teams though, software estimates are one of these most dreaded parts of the job – especially when the scope of work hasn’t been clearly defined. This creates a no-win scenario for the development team. Estimating low will attract customers but disappoint them in the long run, and overestimating can push prospective clients to lower-cost (and lower-quality!) competitors.
That is why careful construction of a software estimate with a reasonable margin of error is required. This takes time, and should not just be a one-way proposal. For best results, clients should work with the development team to help them provide an accurate software estimate.
Best practices call for an estimate that breaks out quality assurance, project management, pair coding, code review, and refactoring. Breaking out these secondary costs allows engineers to focus on coding, remain realistic, and provide transparency to the customer.
At the end of the day, taking the time for a proper software estimate is worth it for both parties. Customers will know what are they are paying for and understand potential risk, and development teams will feel confident they have presented their best offerings and a fair chance at winning the client’s business.
Scope is King
Obviously, the more precise the clients’ request, the easier things get. The 100 page long brief we recently received told us a lot about the final customer’s company and their vertical, but it didn’t explain how exactly the service is supposed to work and contained no actual data and requirements.
Sure, it is great to have freedom in choosing tools and technologies, but at least some direction is needed. And this is why the classic proposal has become obsolete. Asking for a proposal from a development team, without any client input or collaboration, is highly unlikely to fit the client’s actual needs and desires. Instead try working together to define scope and develop a solid software estimate. Here’s how:
First, define the project’s end-users. This should be simple. Figure out who is going to be using the product, when it is complete.
Once this is done, the real work begins. The next step is for the development team and client to perform a UX workshop together to get things really rolling. At least one engineer should be at the workshop, and a UX designer should facilitate. Having an engineer there, will help both the UX designer and the client understand the implications for every feature they discuss. The engineer should estimate features in hours, not dollars.
Another idea is for the client to hire a UX designer and perform the workshops internally before hiring a dev team. The product of the workshop is then passed along to developers in the form of a deck and mockups — giving the engineering team a better understanding of the product than a 100-page “brief”.
Uniting Frontend and Backend Estimates
While preparing for writing this article, I spoke with my colleagues Miłosz and Mateusz, our Django and Frontend Team Leaders. I did this to detail the vast differences between backend and frontend engineering. Despite many years of collaboration and several successful projects, both developers have different definitions of what well-prepared documentation is.
Generally, backend engineers prefer to work with sort of a ‘grocery list’ –a set of functionalities and requirements. From his point of view, the crucial elements of a project are those that ensure high efficiency on the server side. On the other hand, frontend developers must have a great understanding of business goals and of the product. Therefore they are very dependent on the UX aspect of work. Because of these competing ideals, engineers should work collaboratively together to create holistic software estimates.
What both engineers share in common is really the crux of estimation: choosing the right technologies. Several factors need to be take into account when making that decision, These are:
- Functions and Features: Primarily, project requirements must be met.
- Scalability: Technology choices must enable indefinite future growth and expansion.
- Client Requirements: Adhere to customer requests to use technology they prefer due to market conditions and internal capabilities.
- Professional Experience: There is no substitute for experience. Engineers must use knowledge gained from past projects to inform their decisions.
Project Engineers Do The Estimating
Just like with a team sport, combined practice and experience is hugely important. Thousands of hours spent together make teams work more efficiently. You learn to more accurately predict and plan for the actions of your teammates, and it’s easier to estimate how much time they’ll need to get a job done.
I often hear, “He’s great at databases”, or “She’ll need more time for designs, but you can expect clean code from her”. Coworkers get to know the style and skill of one another. That is why it is so important that the actual team that will staff the project does the software estimations. You cannot have an engineer from one project team estimate for a different project — it will be far less accurate. An experienced team who has worked together before creating a software estimate is the best possible scenario.
Prioritizing Business Goals
The next step is for the engineering team to help the client to figure out which business goals are priorities and which are less critical. The developers now need to become progressive and creative problem solvers, providing real world solutions to the client’s needs and helping the client to understand the many moving parts of the estimate. They need to provide the client with information to understand how to best prioritize the business goals, and to do this they need to understand the client’s business model, holding his hand during the long walk through the forest of anxiety and requirements.
The elimination of low-priority features, choosing the right solutions, and suggestions regarding the team’s size and project’s duration significantly reduce the figure next to the “$” mark.
The Final Figures
If you follow the above steps, you should have no problem producing a software estimate both the development team and the client are happy with. With a clear scope, the development team truly understands priorities, technologies have been selecting, and the staff has weighed in, building a spreadsheet with cost breakdowns is a simple task.
But remember, it takes time! Ballpark estimates are fast, but provide little actual value. A proper estimation will take longer to produce, but will make the project go much better in the long run.
So what did we say to our prospective client, and his 100-page brief? We checked some work we had already delivered and searched our archives to see how much similar projects cost. Our proposal was far away from being a real estimate, and was not something we felt truly confident in. Frankly, if we didn’t have a long history and large portfolio, we couldn’t have provided a quote at all.
So for all prospective clients: founders, owners, product managers, marketers – please remember what I wrote above. If you simply ask for an RFP the bids you receive will be created earnestly, but will likely be inaccurate. If you want a true estimate, put in time and work with prospective vendors to get a genuine, customized proposal. It’ll take some time upfront, but you’ll be much happier in the end.