Procurement

Procurement of individual software requires new criteria in purchasing

In order to conclude better contracts for better software when purchasing customised software, a rethink and new tools are needed in purchasing.


Challenges in Procurement

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:

  • Analysis of the software quality of a reference project of the potential development partners
  • Analysis of its development processes and methods
  • During the development: continuous tool based control of the individual software iterations to monitor progress and quality.

Technology-focused Questions

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?


Is the technology of the delivered software such that it can be further developed over the product life cycle at normal costs?

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. 
 

Adapted Approach and New Criteria for Purchasing

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.

CapeOfGoodCode_SoftwareSupplier2-768x267

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.

Links

1. Blog-Picture

Similar posts