The issue with a quick quote
When new clients meet me for the first time, they often talk about the idea that they have for a new web or mobile app, their goals, aspirations and product positioning. With product development, client expectations can be matched by a simple grid of what the product can and cannot do.
Bespoke software development on the other hand is a bit more challenging. The client has a certain picture in his head about what he requires. Yet, requirements are never set in stone.
As clients see their product being built, changes often creep in. In the same way, as users use the software, the client’s needs evolve.
To avoid a mismatch of what the client wants and what the developer (or tech partner) develops, it is best to pin down exactly what is required. This is generally done in a business requirement specification (BRS).
Once a blueprint of requirements is pinned down, a proper estimate of time and cost can be given. Tasks can also broken down into small chunks and delivered in an agile/incremental fashion.
Understanding the requirements
From a business perspective, it does make sense to understand what is required. However, it seldom offers insights into the end-user of the software.
The users are often neglected for the greater vision and mission of the company, seen as a lagging factor that ‘users will get used to’. For a better view of the business and its requirements, it makes sense to include the following in the diagnostics phase:
- Business requirements
- Business goals for the solution
- Timelines and output requirements
- Expectations of the user
- User personas – who will be using the website/software/app
- Story flows – what would each of the users like to do and how will they achieve this
- Technical requirements
- API integrations
- Third-party dependencies
- Technology, architectural and code considerations
The BRS – Needs mismatch
Many clients would explain to me that they already have a BRS with a full needs analysis. It makes total sense that they would not want to pay again for another needs analysis. It would also be irresponsible of the new technology company to start solving client problems before they are engaged.
Effectify focuses on simplifying what the clients think they need. For example, we know that a client has a 250 page BRS, a pitch deck and 10-year marketing plan for their innovative mobile app.
With these details, we need to consider breaking down the project in smaller chunks – maybe there are online solutions, open-source code, APIs and third-party products that could decrease the time to market.
Although the client would want to have a bespoke software solution, the need on a project could possibly be satisfied by other means that are more cost-effective, time saving and still deliver the same value.
Conclusion
It’s vital that the technology partner can do the job, but it is also important that you get along with them.
The diagnostics phase is as much about requirements and understanding the business as getting to know your customer.
Simply be effective.
0 Comments