How To Fix Procurement 6: Use Agile Policymaking
Streamline the process behind your online forms.Learn about Screendoor →
One of my favorite quotes is from Albert Einstein:
The significant problems we face cannot be solved at the same level of thinking we used to create them.
In the case of crafting a 21st century procurement practice, it’s worth taking that to heart. Anyone that’s ever worked at any government agency – local, state or federal – and tried to do anything “innovative” ends up frustrated with procurement and probably ends up with lots of ideas about how to fix things.
And our natural instinct is to gather a commission of those frustrated people together and think up ideas for change. Then draft these ideas into a recommendations document. Perhaps we sign some petitions and organize a bunch of people together in order to send those recommendations to policy makers, who then may implement the policy changes. And some policies change. This is often how policymaking works.
Does this sound crazy to anyone else?
It’s like waterfall software development, but without any of the quality checks. We imagine what kind of policies might work and then implement them, never investigating whether or not those policies created the desired outcomes we were seeking.
As we move forward in figuring out what to do with procurement, I’d like to suggest that we avoid this model for crafting new policy and techniques. That is the level of thinking that created our significant procurement problems. Instead of using the waterfall technique of policymaking that got us into this mess, let’s be agile policy scientists and get us out.
That’s the battle plan for Procure.io:
- Find governmental bodies that are willing to participate in a test.
- Craft a low-risk test for that body.
- Publish the results of that test, and if the results are successful, use the results to justify expansion of the test, or to inform future policymaking.
- Lather, rinse, repeat.
The implications of working this way are significant because it allows for controlled failure. It makes it so you don’t need consensus of the whole acquisition community from the get-go: the seats at the table only expand when the scope of the test expands. And it means we don’t have to come up with all the answers before we affect change. We can acknowledge that we don’t know everything, and we’ll see what happens. If what happens turns out to be good, let’s implement it. If it doesn’t, we won’t.
We’re not going to solve IT procurement problems by sitting around the table drafting documents and signing petitions. We’re going to solve them by conducting tests, measuring outcomes, and implementing change based on the results.
Clay is the chairman and co-founder of The Department of Better Technology.