Before I moved into the architecture space I diversified a little and ran a number of transformational IT projects. If you ever want to strike fear into a public sector project manager just say the word ‘Procurement’.
In my experience the people who support our buying activities are very supportive and helpful, but the rules and regulations around how you buy and who you buy from can be a minefield for the novice. Projects can get extended by a significant magnitude to allow for the dreaded tendering process and the level of frustration for those involved – especially the technical staff – can be high.
Don’t get me wrong, I fully respect the process and the need for due diligence. I was involved in preparing two very large tenders and in both cases I ended up contracting with both a different company and software set than I had originally expected – and the project was all the better for it. It was the right decision at the time to test we knew what we really wanted.
Interestingly, the mantra from my procurement leads at the time was “if you can’t define what a ‘good enough’ tender submission is, you can’t ask someone if they can meet it”. I relate this back to the principles of the GDS approach: What is "good enough"?, how can I measure it?, what are my critical success factors? Although very different in their philosophies, the goals of these approaches are arguably the same.
I say different approaches because the big issue with large public sector procurement is that you need to be clear on what you are going to buy before you buy it, whether it be software or services – mainly because at the end of the exercise you are going to build a contract around it. The agile agenda is much more on learning as you go; trying different things to see what works the best and then building your solution around it. The ‘fail fast’ is important here. If it doesn’t work learn from the experience, pick a different approach and try again.
The overall difference here is the focus on total cost of ownership. Agile is really great for getting a good solution out as soon as its feasibly ready to do so - but an efficient procurement exercise will ensure that your total cost of ownership over the extended period is affordable. I’ve tried to describe the dilemma in the picture below…
For example, I could go out and build a great system in a very short space of time with a piece of open source code based on a subscription licensing model. But then I get into the escrow, ongoing maintenance and scalability issues and suddenly I have a system that becomes high risk to support and unaffordable. On the other hand, I could spend several months going out and buying the ‘right’ system only to find that the original requirements had changed and my product is no longer fit for purpose.
There is a fundamental – but I might argue necessary – conflict here between the responsibility of the public purse to ensure that money is properly spent and to stop taking so long to get things moving that the user needs are forgotten.
The Scaled Agile Framework (SAFE) has recognised that you need to manage the challenge of intentional versus emergent architecture and to ensure that there is sufficient architectural runway for agile projects to understand the architectural constraints they need to adopt. To support this, the architects work closely with the sprint teams to both support them and to ensure that that runway is long enough and free of obstacles. We are finding that architecture is only one cog in this wheel.
The missing piece I think you need to have in your sprint team is a pragmatic procurement lead. They need to be involved during the sprint planning and "emergent thinking" phase to smooth the process of getting the right software and specialisms in place for later sprints.
Ultimately, however, this comes down to the overall appetite for "fail fast" – especially in projects where deadlines are immovable. But that’s another blog posting for another day….!
2 comments
Comment by Julie posted on
Interesting post Chris. I'd agree about procurement - and anyone else who needs to be involved in delivering the thing - being involved as soon as possible. Have you seen https://www.gov.uk/service-manual/making-software/choosing-technology.html?
Comment by Chris Thompson posted on
Hi, Julie, yes I did. However, the main issue here is not the choice of technology itself but the ongoing support - especially in a mostly outsourced organisation.
What is the risk appetite for the vendor? Is an escrow available? Can I buy the support off a framework? Do I need to do a managed quote or more for them? Where can I host it? What's the security implications?
Frameworks like SPRINT 2 have made the buying of software (if you need it) much easier but ensuring you can support it if you get it and avoid the contractual headaches much later on is usually the problem area.