How do users attach a price to an indeterminate outcome? At a rational level, the answer would be: they can’t. This means users either provide an exhaustive specification of the exact outcome, or take a leap of faith based on industry experience, intuition, and commercial or emotional drivers, says Chris Wilkins, CEO of DVT.
It is important to understand that the indeterminate aspect of most software projects is the business requirement, not the technical software development.
So software projects should really be called “business” solutions, not “software” solutions.
A new business solution can rarely be specified exhaustively before the project is nearly complete. This is because we all know from experience that current levels of knowledge grow as projects progress, and that the more is understood, the more the requirements keep changing.
This continues right up until the system is declared “finished”. And most finished systems will have an immediate requirement to make more changes. Why? Because commerce is restless and dynamic, and is constantly being refined. Therefore, the project process itself is the ultimate specification.
Yet providing a price for software, in advance, is nearly always a requirement. Generally speaking, this is not unreasonable. Companies want commitment and they want predictable budgets.
If a team of professional business systems experts commits to an indeterminate outcome, they should rationally charge a ‘risk’ premium. However, because it is difficult to price the outcome, it is difficult to price the risk premium. Risk pricing then becomes a subjective and emotional debate. No exact formula can be applied. This result is disappointed business leaders and disillusioned project teams.
Arguably, the most effective way to price a business solution that involves software development is to first decide how much users should spend. In other words, how important is this solution for the business? What is the price of NOT having the solution? Can users live without it, or is it a mandatory requirement for staying in business, making revenue or improving profit.
If users really need it, introduce industry experts with prior experience of the same or similar systems to provide scope, skills, and cost guidelines. Industry experts have an experienced and realistic view.
Add in a contingency for project duration and cost. Consider the implications of spending more than users wanted. Refer to how important the solution is to the business. And then take a leap of faith.
Once users decide to proceed, they have to accept that they are in the hands of the process itself, and that project budgets often go up. They rarely go down.
Compile and build the project team with the right skills and personalities. This is a critical step and takes careful recruitment and planning. It requires a flexible staffing approach to get the right people at precisely the right time. Staff costs are usually the biggest cost, and this point is usually ignored when it comes to staffing up, and staffing down projects. External service providers can help with this.
Recalibrate the budget, progress and timelines every two weeks. Make sure the team works hard, is engaged, and is supported, nurtured and consulted through the entire process.
If users have the right team, and they introduce the right skills (people) at the right time, they will have optimised their project. This means users will pay the going rate for a solution. If it is important enough for the business, this will have been the right decision.
And as always, it all rests on whom users asked to help them.