How to Build Client Trust With Software Cost Estimation
Over the last 10 years or so, the software development world has taken a strong inclination toward agile methodologies. And rightly so, as there are many advantages to running a software project in an agile mode, including:
- As the stakeholders “see” and “touch” the growing product, sprint after sprint, the tendency to tweak the requirements by adding features increases. An agile process helps better adapt a development project to change, which is inevitable.
- Business requirements tend to have different interpretations, both within stakeholders and development teams, which lead to miscommunications. An agile process helps determine this and allows adjustment of the development cycle without having conflicting discussions about scope and money.
- It takes time to understand the client’s domain. You don’t know what you don’t know! An agile process allows the development teams sufficient time to better deal with the unfamiliar by adjusting the team velocity.
As software teams increasingly adopt agile methodologies, the strong agilists tend to favor a “no estimate” paradigm. The argument is that when “we know things are going to change, any forced estimate provided will be wrong.”
Many have heard of the #noestimate movement. It saves valuable time spent on estimation, allows teams to work on a reliable long term solution, and thrives on the creativity of the team members. Unfortunately, it doesn’t work for 90 percent of clients.
What Clients Want
When a new prospect comes in, they fall into one or more of the following categories:
- Those that have a new idea they want to implement, ideally being first-to-market, and have no previous experience working with software teams
- Those that have worked with software teams before, where the budget escalated to twice the original estimate (or more), yet they are nowhere close to getting their final product
- Those that already have a number in mind for what the project cost should be
During the first few meetings with your team, the new prospect wants to get to a point where an estimate can be provided. This would provide the guarantees on budget, date and scope they want, to either sell the project internally to their own management, which demands similar guarantees, or to satisfy the number they had in mind.
What Is the Purpose of a Software Estimate?
While many agilists disapprove of providing estimates, there are many technology stalwarts that are for it — even working in an agile mode. According to Martin Fowler, “an estimate is valuable when it helps you make a significant decision.” For example:
- From the client’s perspective, estimation is a way of buying knowledge. If having this additional knowledge will lead to different decisions, acquiring that knowledge might be a good thing to do.
- An estimate allows the client and the internal stakeholders to determine how to allocate money and resources on a project, as well as if it is worth it.
- Estimates force clients to understand the tradeoffs between features and decide which ones are important.
- Estimation allows teams to find better ways to implement a solution, discuss on how generic the modules of the system should be built, and have better architecture discussions based on the overall product road map.
How We Build Trust with Software Cost Estimation
A prospect once commented that if we are not able to provide him with an estimate, we may not be good at our jobs. Harsh and incorrect as that may be, it provides a keen view into the world of stakeholders. “How can I buy something from you if you do not tell me what it would cost?” The simple answer is: we cannot provide you a cost for something that will change.
But trust has to be earned.
Over the years, we have formulated a process:
- We determine the scope for a minimum viable product during an initial engagement of 3 to 4 weeks.
- We then provide an implementation project plan, not to exceed 6 months of duration, which would include initial design and architecture time, followed by a fixed number of sprints, and ending with 4 to 6 weeks of user testing. Even if the client wanted to invest in a larger project, we strongly recommend and steer them to this first phase model.
- Finally, we talk to them about post-deployment support and maintenance effort of about 25 to 30 percent of the original project cost.
As the project progresses, the team works in an agile mode, with a pre-prioritized backlog and a duration estimate. The engagement manager works with the client, regularly showing them progress, and has any tough scope discussions if the need arises. At the end of the process, the client has a working product they can sell or use to perform business. A successful product earns us their trust in the agile process, now that they have seen it, sprint over sprint.
As with every complex software applications, the work has just begun at this point. With established trust, and a product that they can do business with, the client finally buys into the agile process, and we engage again, this time in a month to month resource-based agile model. We provide the client with tools to manage their own backlog, view story points (they get a crash course on it), and adjust priorities as their business needs dictate. No more questioning the invoices every month. Now they know the size of the team they are paying for and the velocity in which they can develop.
The process I have defined is nothing extraordinary. It’s simply an amalgamation of old-world, estimate-first tactics combined with the understanding that our work is what will buy us the trust we need. It’s about showing clients the benefits of agile, not just the process.
Once we are there, it’s smooth agiling!
Written by Atul Shukla
Share post
