There are more and more products or even entire business models whose success depends on specifically developed software. Only a few companies can develop this software completely themselves and therefore have to cooperate with external software development service providers. The procurement of such purpose-build software, developed by a partner, is complex for the responsible purchaser and requires specific experience.
The challenges in procurement are driven not only by the complexity of the new software itself, but also by the intended use case. Particular attention should be paid to both the total development time of the product in which the software is to be used and its expected useful life. For example, if that software is used in vehicles, aircraft or industrial plants, one is likely to be tied to the software development partner for decades. The potential service providers on the purchasing shortlist cannot therefore be selected solely on the basis of "price or TCO". Other criteria must be used to determine whether these service providers could still be the right partners today as well as years down the road.
For this reason, we recommend the following measures, among others, during the qualification of development service providers and during subsequent development:
These measures allow a focus on the following technology, partnership and future relevant questions, like the following*:
| For the company's own departments (purchasing, R&D, QM) | For the software development service provider |
|
Is the necessary knowledge available to audit the software service provider and to control its work progress? What criteria are used to check delivered versions of the software? |
Do the billing models ensure effort transparency during development?
|
| Are state of the art tools (partners) available to prove software quality already in the development process and during acceptance? |
Is experience available to successfully synchronize long-term software developments with the associated product development (of the customer)? Do they have experience in developing and maintaining individual software over very long periods of time? |
|
What are the technological KPIs during progress monitoring and acceptance of the respective iteration? Have these KPIs been included in the contract as quality and acceptance criteria? |
Is there a commitment to be monitored already in the development phase? Examples: trend of technical debt, completeness of documentation + traceability of code, status of cloud readiness). |
| How is it ensured that, over the long development period, only the cost for justified change requests will be approved? |
How is access to technology and development materials generated (e.g., issue trackers, code histories, documentation) ensured in the event of developer or development system failure? |
Table 1: Checklist of questions
* These questions are specifically intended for the technical review of suppliers and their deliveries. Of course, all other usual criteria of a supplier qualification (creditworthiness, references, costs, conditions) should also be checked.The following picture shows that the minimum requirement for a successful procurement of a purpose-built software, is the good cooperation of the internal stakeholders (purchasing, R&D and QM), which should be synchronized by purchasing. In order to be able to judge the quality of the software iterations during the development really competently, software analysis tools must be used as early as possible also on the customer side such as DETANGLE of Cape of Good Code.
Figure 1: Custom software is a fluid product with volatile requirements. Purchasing needs new holistic concepts for the entire supplier lifecycle for software service providers.
As a final note on new criteria for purchasing custom software, we recommend regularly checking possible dependencies on individual developers at the service provider. A failure or departure of developers with key competencies is not easy to compensate for and could jeopardize the entire development project, or at least delay it considerably.
However, the service provider will usually only disclose this when it is already too late to limit the damage to a minimum.These dependencies can be uncovered by regular scans of the code history with our software analysis suite DETANGLE and enable proactive risk management.
Everyone in the supply chain for built-to purpose software should be aware that dysfunctional software can have a catastrophic impact on your company as well as on your customers and the users of their products. Only utmost care in the entire software lifecycle can minimize that risk. Selecting the right development partner by using the state of the art methods and criteria in procurement is part of this responsibility.
1. Blog-Picture