As I discussed in my first blog in this series, moving to Agile delivery requires much more than a change for IT. For Agile to be successfully adopted by public services organizations, it needs to involve and engage a number of different functions-and one of the most important of these is procurement.
A survey that we conducted with NASCIO revealed that 70 percent of respondents didn’t feel that their procurement was set up for agile. Frankly, I’m not surprised. Moving to agile requires a big shift in not only what procurement does but also the way IT thinks about its role. In agile, the emphasis is on collaborating rather than dictating fixed scope to a vendor. Rather than issuing a highly detailed and voluminous RFP, going into painstaking detail about every requirement, the process under agile is focused more on value and outcomes and will be subject to change as the project rolls out.
So, of course, these are significant changes to take on board. Traditional contracts are plan driven. They have a lengthy upfront process to agree what will be delivered in a specific timeframe and dollar amount. In contrast, agile "contracts" are driven by the value delivered, requiring constant feedback and iteration in line with a very different delivery cadence.
For traditional approaches to public service procurement, this creates some big challenges. There are no set requirements and deliverables can look very different. In the absence of a set scope, reaching a desired fixed fee can be tricky. Getting approval from authorities used to doing things in the old way is tough. And incorporating user feedback that allows a solution to adapt is imperative.
Some of the CIOs that we spoke to in the course of our research with NASCIO are acutely aware of these tensions. Many of them discussed the challenge of balancing the more open-ended, iterative nature of agile delivery with the procurement function’s need to have an "end date" agreed and signed off. In response, we’re seeing hybrid models and experimentation. Some are bidding traditionally and then "modularizing" the work into agile-like chunks. Others are asking vendors to detail how they’ll deliver in an agile way while still providing the business with a level of granularity that they feel comfortable with. But these approaches tend to be more like workarounds rather than a set of agreed ways to incorporate agile with new budgeting and procurement processes.
So how can we move forward with a new way of working that will help procurement get more comfortable with agile? I think that there are a number of fundamental considerations that have to be taken on board. One is transparency. There needs to be clearly defined roles, responsibilities, governance and communications across all parties. And because with agile it’s possible to show progress at the end of each sprint, sharing that progress to value with procurement through open and honest communication can help improve buy-in. Different approaches to contracting, using hybrids of time and materials and fixed price, can also help balance and build a trusted relationship between clients and vendors.
Ultimately, there’s no one path to securing a new procurement approach that will meet the requirements of agile. But openness, collaboration and dialogue are all fundamental to any successful approach-and that’s where the IT, business and procurement teams need to start.
I’d be very interested to hear your experiences and insights about how you’re addressing the journey to agile. In my next post I’m going to look at the training and coaching that can help public service organizations get their people on board with agile.
See this post on LinkedIn: Buying into a new way to buy