Quoting on Software & Application Development — The Eternal Struggle
If you’re in the software development business I’m sure you’ve experienced the ‘joys’ of quoting and proposing on projects which are very difficult to estimate up front. Often thumb sucking ballparks or wasting vast amounts of time getting to more accurate figures, which will inevitably change over the lifetime of the project.
What does the problem look like:
We’ve often spent huge amounts of time with a potential client prior to any billing, only for them, or us, to be disappointed when their needs and our value offering didn’t quite align once we’d gotten a deeper understanding of their project objectives. This presented a recurring problem, in that we often didn’t start out with enough information to meaningfully estimate a project at the outset — and this opened both parties up to risk down the line.
We have been on both sides of the table. On one hand, we’ve vetted exorbitant proposals put forward to our clients by other parties — knowing that the agency who was quoting couldn’t possibly have had enough insight, at the starting point, to give an accurate estimation. On the other hand, we’ve had limited insight, or been confined to a rigid Request for Proposal (RFP) and had to quote on this with the awareness that we couldn’t possibly know at the outset what we needed to know to do so well. As a result, we have put forward RFPs where our cost estimates were far too high in comparison to other candidates and, other times, far too low to be viable.
Whenever a potential client walks through our doors, physically or digitally, they are at vastly different states of familiarity with our company, and at markedly different levels of technical understanding of their own project.
There were many clients with whom we’ve built a great rapport after only a few interactions. In some instances, they have seen previous projects of ours or been referred to us by a trusted source. Other times, clients have done a fair bit of research and have a much clearer idea of their needs — but unless these clients came armed with a full technical specification and complete wireframes covering every unique screen and feature, we are not able to dive straight in. Yet, we’ve made the mistake of doing so in the past to our detriment.
This was all before we’d refined our process for getting started with a new project. We needed to create buy in to the necessary processes and relevant good practices. We needed to understand exactly what the client was looking for when often they didn’t have a clear idea of this themselves. Through a lot of trial and error we’ve arrived at what we believe is the correct solution to this conundrum.
Enter our adaptive Discovery Process
The initial ‘Discovery Workshops’ we ran when we started exploring this process had their challenges, involving far to many textbook exercises and ‘UX planning best practices’ because they were “an essential must have for the UX process” at the time. These sometimes ran over many weeks with multiple client touch points and far too much on the agenda. We’ve adapted over time in line with our learnings and refined the process down to a far more efficient, and cost effective, group of 3 x 2 hour workshop sessions which run over the course of roughly one week. These leave us with client stakeholder alignment, a good understanding of the business goals that motivate the project, and a solid idea of the full project specification required to meet them.
Underlying this was our aim of improving our processes and design thinking without using a cookie-cutter approach. We realised it was important to challenge the client’s “why”, to create stakeholder alignment and push beyond superficial KPI’s, and understand long term business goals. We looked to uncover evidence, and critique and review with fast feedback from the client to create alignment and initial design / development decisions, all the while delivering tangible value at each phase of the process.
As part of this process, we had to challenge a lot of our assumptions. Here are some of the things that influenced me during this time:
How to link users needs to business goals
The biggest WTF in design right now
The value proposition explained
Why Product Thinking is the next big thing in UX Design
At this point, we felt we had converged on a process with what we considered to be all the essential features:
- Stakeholder alignment
- Business/Project KPIs
- Value proposition / mapping
- Identify users along with successful outcomes and constraints
- Map out all key features
- Rapid low-fi prototyping
- Interactive low-fi prototypes of key features
- Overview of infrastructure and platforms required
- System architecture
But we still felt like something was missing…
Even after refining our Discovery Process down to only the 3 workshops, which reduced both our and the client’s cost substantially, the cost of engaging with the process still posed a barrier to entry or ‘barrier to buy-in’ for some clients who were perhaps at an earlier phase of their project plan/idea/understanding and couldn’t quite commit to the full discovery process.
Enter the Initial Consult
The Initial consult is an even more rapid fire, results driven process which consumes even less time. It runs as a single two-hour consulting session, where we aim to get at the critical answers a potential client is looking for around the feasibility and/or potential paths to implementation of a perhaps very technical or complex idea.
We give preliminary advice on:
- The likely scale of the project where possible
- The suitability of chosen technologies and potential platforms
- The required components
- The kind of user interfaces which are a good fit for the problem or the solution and it’s users
- Other technologies that are worth exploring for your the stated use cases or business needs
- Specific recommended next steps
Again, our main priority here is delivering tangible value, so after due research we make sure the client receives a document containing the following:
- Areas that need more extensive research before starting
- Ideas about the scope for initial development
- Most likely, the outline for a discovery workshop, to develop the idea further.
This has proven very successful with clients in the very early stages of a project idea or proposal or those who are unsure about the integrity of their concept. It also paves the way for getting started with best practices and clear processes.
In Conclusion
The Initial Consult and Discovery Process are about more than starting the project and ticking the relevant UX planning and design best practice boxes. They’re about buy-in and alignment from both sides. They’re about getting to really understand the businesses and the “why’s” of our clients, as well as setting a solid foundation for the design and development teams while mitigating risk for both sides before embarking on a big project with a lot more clarity around the scope of work.
It is no silver bullet, but it has helped us to massively manage expectations and ultimately paved the way for a much smoother experience all round.
A couple of takeaways:
- Avoid attempts at ‘accurate ballparking’ whenever possible
- Stakeholder alignment and participation is vital
- Discover business goals and needs before exploring UX & UI
- Deliver tangible value at every possible step
