Procurement and agile product development

Technology companies across the world have enthusiastically adopted agile development and product management practices to great effect. Done well, this has allowed companies to be more responsive to customer needs and market changes and rapidly develop their products. Learning quickly from successes and failures, technology companies have shown how they can chart an incremental and optimal path to business and customer success.
 

As well as technology companies there are other types of organisation, for example, public authorities, who need to procure outsourced system development and could benefit from adopting an agile product development approach. However, they may be limited by governance and financial constraints to a more traditional approach of specifying requirements up-front and procuring a fixed price delivery by competitive tender. Can such organisations achieve the benefits of agile product development? It is certainly challenging, however, there are some strategies that could be considered to achieve some of these benefits.
 
Firstly the procuring authority may choose to adopt a product mindset itself, learning about customer needs before specifying systems, accepting that the full scope cannot be fully specified to the finest detail at the outset and also to expect and plan for significant change throughout the delivery. In this case, the change would be expected and planned for through the operational lifecycle of the procured systems/services. With experience, research and feedback would be used to define improvements. The other key aspect here is that the authority would expect to be working very closely (on a daily basis) with the supplier and its development teams allowing them to influence and guide the work toward the desired outcomes.
 
Ahead of a full-scale procurement, the procuring organisation could ensure sufficient pre-work is undertaken to set things off in the right direction, including customer and market research, prototyping and testing with customers and ultimately small-scale pilot studies to allow for iteration of the requirements. Through this, the authority may learn where requirements need to be changed to really meet the needs of the end customer, uncover unexpected use cases or even find that the envisaged service is not wanted or not usable by customers. Early investment to flush out these concerns before committing major funding is essential and can be highly beneficial.
 
Out of the testing and research phase should come an initial set of requirements. The form that these requirements take is important to defining how flexibility can be built into the project. Wherever possible the requirements should be stated as user outcomes, avoiding the desire to specify to a very low level. This leaves flexibility for collaborative work on design and approach to achieve the desired outcome.
 
The next consideration is the desired structure of engagement with suppliers. As mentioned above, a close and collaborative approach with suppliers is likely to lead to a better outcome and the authority should require this through the procurement.
 
Another consideration is whether it makes sense to structure the procurement and project into phases. This allows for refinement and adjustment of scope as the delivery progresses. Procuring organisations will need to consider how they protect themselves against cost changes, for example by requiring an open book appraisal of the differences between initial requirements and adjusted requirements. This may require engagement with regulatory and financial stakeholders to align them with the desired approach.
 
A final consideration is the division of scope (possibly into separate procurements) in a manner that allows for different development approaches as appropriate to the part of the systems being procured. For example, a transport authority may desire a complex business-critical transaction processing back-end system that meets regulatory needs or perhaps a customised version of the same. A risk assessment may indicate this is best procured in a standard fixed-price approach. In contrast, the authority may also require customer friendly and highly flexible customer-facing channels (website, mobile applications and agent tooling) that would be better developed in an agile manner and adapted over time to best meet the consumer needs. Splitting the procurement in this way may allow for an outcome that is the best of both worlds, although it needs to be remembered that the channels will need to be integrated with the back office so the quality of the back-end APIs becomes a critical factor.
 
It is probably infeasible to seek agile product development for a project that demands a fixed-price procurement. However, with the application of all or some of the approaches outlined here, it seems that it could, at least in part be achieved. As a result, the benefits in terms of end-user experience and therefore the overall success of the project could be significant.
 
If you would like to discuss this issue further, please reach out to Osmodal group.