> Unfortunately, nobody's really come up with any reliable process for having the flexibility to get good products for good value, while reliably preventing corruption.
I've seen one approach work, but it struggles to scale, as it needs technical people on the client side.
Buying "outcomes" rather than services can work well - rather than procuring a specific "specification", you buy a solution. The standard contractual framework means you are paid for delivery to tangible milestones (demonstrable value), with engineering/technical background project management team overseeing the work. You work at risk, as you only get paid for delivery. That keeps many of the charlatans away, since it's very clear you're paid for delivery, not effort. That means the headline rate is higher, of course.
Focusing aggressively on actual delivery, but also not dictating the solution means you can see suppliers compete not only on price, but also on how they'll solve the problem. This means the government client needs to understand their problem well enough to articulate it (with some of that support from a technical project manager), but they then evaluate proposals for solving their problem. This moves away from the incentives to "body-shop" low-pay graduates onto a project that a partner pitched for, as it has to actually deliver.
I tend to see the "worst" projects (in terms of non-delivery, large bills incurred, poor value, and the only output being a report recommending more work) come about when the government client doesn't understand their own problem or goal though, so perhaps this approach self-selects problems where the customer can actually articulate their need.
Problem with that is government is worst customer: don't know what they want, what they have and how to get anything done. It is very hard for companies to commit to deliverables, when incompetent department they need to integrate with doesn't play the ball.
Indeed, however this approach effectively offers them a carrot - if you understand your problem, you can use this (very effective and well regarded) route to getting your problem fixed.
The end result, as you'd expect, is mission-focused solutions to problems with minimal external dependencies. That means the problem gets solved in the simplest way possible, with the least overlap with incompetency possible.
It doesn't work for every problem, but it does show that forcing government to understand the problem before spending money can actually work, at least at some scale.
I've seen one approach work, but it struggles to scale, as it needs technical people on the client side.
Buying "outcomes" rather than services can work well - rather than procuring a specific "specification", you buy a solution. The standard contractual framework means you are paid for delivery to tangible milestones (demonstrable value), with engineering/technical background project management team overseeing the work. You work at risk, as you only get paid for delivery. That keeps many of the charlatans away, since it's very clear you're paid for delivery, not effort. That means the headline rate is higher, of course.
Focusing aggressively on actual delivery, but also not dictating the solution means you can see suppliers compete not only on price, but also on how they'll solve the problem. This means the government client needs to understand their problem well enough to articulate it (with some of that support from a technical project manager), but they then evaluate proposals for solving their problem. This moves away from the incentives to "body-shop" low-pay graduates onto a project that a partner pitched for, as it has to actually deliver.
I tend to see the "worst" projects (in terms of non-delivery, large bills incurred, poor value, and the only output being a report recommending more work) come about when the government client doesn't understand their own problem or goal though, so perhaps this approach self-selects problems where the customer can actually articulate their need.