There are lots of projects to attempt transforming procurement.
Identifying the problem, and example from Philadelphia
My favorite is this project by Mark Headd former Chief Data Officer of Philadelphia where they did a GitHub-based procurement - "Redesigning Government".
Let's look at the problem: that the government procurement is broken, "fear-based procurement" is taking place, meaning people working in the government in general doesn't want to take risks so they stick to less risky procurement process, with old-style vendors they know, and the newer innovative startups has no way to contribute.
In the case of Philadelphia, they used GitHub for procurement for the following reasons:
1) They wanted to use a platform that would resonate with technologists, and wanted to work with firms that believed in what they believed- "we value open source software, we value collaborative software development, we value awesome things, and existing procurement processes don't allow us to find firms that share our values" says Mike.
2) They wanted to have some insight into the quality of other work done by bidders (to be able to look at their public repos to see what kind of solutions they were working on and how active they were in participating in other projects)
3) They wanted to see creative responses - something that potential vendors probably had not seen from a city government before.
The project they decided to use this process was called myPhillyRising, and they posted their RFP (what they want to build) on GitHub Gist.
https://gist.github.com/PhillyCDO/4666456
Anybody can see it, anybody can ask question or clarification can post public comment on this Gist so that everyone will see those questions and everyone will see those answers. If vendors wanted to bid, they had to create a GitHub repository, and the proposals should be in that repository. Mark and the team used GitHub issues to evaluate the vendor proposals, tagged them and issued bugs to assign the evaluation processes to the team.
Some firms just put a pdf document on their repository, some of them submitted actual code as submission, and the city can install and test them. Another vendor submitted a website that had user stories. Changing the "deign of the procurement process" itself allowed the city to reach those creative firms with shared values.
I think this is fascinating. You can read more about it here:
Experiments in GitHub Based Procurement
Many examples around the world
But this is not the only way to change government procurement - there are many different approaches taken by different governments.
How Barcelona and Philadelphia Are Turning Procurement Upside Down
It talks about how the cities opened their RFPs to everyone to be inclusive to the local citizens, and not specifying the solutions they are looking for but specifying the problems they want to solve made bidders more creative: “If we think about procurement as less about buying solutions and more about solving problems, I think we can open ourselves up to a whole variety of innovations”
And they introduce at tweet of a woman reading the RFP over breakfast: “Suddenly, procurement has gone from something completely horrible to something people can imagine participating in.”
Example from Namie, Fukushima
I wrote about Namie in the past on this blog post: it's a town very near Fukushima nuclear power plant, over 37% of the population is over 60 years old, all of the citizens are in evacuation in other places due to the radiation, and the town is completely in a diaspora. Namie is a small town with around 10,000 households/ 20,000+ citizens, and the town decided to distribute each household a tablet to communicate among each other as well as the town to distribute information. The project has 290,000,000 yen (approx. 2,900,000 USD) as the budget, from the Recovery Agency.
With such aging society, inclusion is extremely important. Here is how they are running the procurement process, together with Code for Namie team.
They have this website that explains to the citizens what this project is about, and the process of procurement.
http://www.town.namie.fukushima.jp/soshiki/2/201405tablet.html
1. They ran 6 ideathons where citizens, developers and designers gathered to discuss ideas for what they want the tablet to be doing in order for it to be useful for them.
2. They summarized the ideas to select the theme for hackathon.
3. They ran 2 sets of 2-day hackathons to develop prototype apps, and had the citizens evaluate those apps.
4. Based on those evaluations by the citizens, the town created RFP and invited vendors to submit proposals for creating applications and running the distribution and operation of the project.
5. All of the households receive application form to apply for the tablet, and monitor households will be able to start using the test device. Events to experience the tablet will be held.
6. Based on the monitor and events, adjustments will be made, and the tablets will be distributed.
Photo from one of the ideathons:
All of the RFP and Q&A results can be seen here:
http://www.town.namie.fukushima.jp/soshiki/1/20140801-proposal.html
http://www.town.namie.fukushima.jp/soshiki/1/8133.html
This is the actual specification from RFP.
http://www.town.namie.fukushima.jp/uploaded/attachment/2870.pdf
Some of the functions includes:
1. Local news distribution
2. Radiation level information distribution
3. Local government information distribution
4. Inter-household SNS
5. Function to increase usage (support function to support non-technical people using characters)
6. Slideshow
7. Inter-citizens SNS (optional)
8. Namie archive (optional function to preserve photos, videos and cultural assets from Namie)
These are the functions that actually came from the citizens' demand. You can see the "idea sketch" from ideathon incorporated in the RFP.
They also attached the "persona" analysis of the users, for the vendors to envision the user scenario.
http://www.town.namie.fukushima.jp/uploaded/attachment/2873.pdf
1. Community leaders, old couple living in temporary housing in Fukushima City
2. Community creators, young mom & daughter in Chiba, with high IT literacy
3. Old man living alone in Nihonmatsu, enjoying single life
4. Family living in Sendai, adjusting their lifestyle based on the children
5. "SOS" type- evacuated to Saitama, but cannot adjust to the locals and having trouble with communication
There were 6 companies that made proposals, all of the proposals can be seen here: the presentation files and video of their actual presentation to the town. You can see all of the scores, overall evaluations and detailed evaluations here. It is extremely transparent.
http://www.town.namie.fukushima.jp/soshiki/1/8028.html
Watching the video archive, you realize that at the beginning of the presentation, the vendors are told "citizens from Namie are in the room listening, so please do not use technical terms- please make your presentations understandable to everyone." One of the vendors started using lots of jargons in their Q&A and one of the person from the audience replied "I did not understand a word you said. Can you explain in plain sentences?"
Also, there is one person in the room that keeps asking the same question to the vendors: "Do you know the percentage of the population of Namie over 60 years old?" and "Do you know what percentage of the citizens have evacuated outside Fukushima?" These information were all in the first couple of pages in the RFP, but surprisingly some of them could not answer.
This is the slides and video of Fujitsu that won the bid.
Slides:
http://www.town.namie.fukushima.jp/uploaded/life/8028_24220_misc.pdf
Video:
https://www.youtube.com/watch?v=AL8Ds_tNtk0
This is the short summary evaluation doc of all of the vendors.
http://www.town.namie.fukushima.jp/uploaded/life/8028_24299_misc.pdf
This one is the detailed one.
http://www.town.namie.fukushima.jp/uploaded/life/8028_24201_misc.pdf
So the first question would be "Why the heck is NTT Docomo's score so low??" NTT Docomo is the largest mobile carrier in Japan, and clearly should have done lots of app development and system integration projects like this. They actually have a lot of experience- in fact, they already have ASP service that has many of the functions needed in Namie, and have already implemented in other town in Fukushima, that they can leverage. Their proposal was basically using this ASP service, customizing to Namie. At first thought, this makes sense, and their presentation seems legit. Instead of reinventing the wheel, let's use existing apps and customize it. What they did NOT realize is that this project was supposed to be agile, collaboration project involving the citizens to prototype, iterate, test, and give the feedback loops for further iteration, although it was written clearly in the RFP. It was not meant to be "giving" the system, but "building together". Also, the citizens did research about how Docomo's similar system in other town of Fukushima was doing, and it was not functioning well. Despite using the existing system, their initial cost and operational cost was expensive.
To summarize, almost all of the steps of the procurement is open, and citizens are inclusive of that process through the following steps:
1. Citizens were involved in shaping the RFP by giving ideas of "what they need".
2. Citizens were involved in hackathons to give feedbacks to the prototypes created.
3. Citizens were involved in evaluation of the vendors by joining and asking questions at their presentation.
4. Citizens will be involved in using the app early as monitors, join "experiencing events" to give feedbacks for iteration before the final rollout.
Sure, they didn't use GitHub, all of their docs are in pdf format, but I think it is subtle in this case: this is about a small and aging town, with all of their citizens in diaspora, almost nobody is tech-savvy and they have little experience developing systems or apps, but they are working together with the citizens to build something useful for their communication and knowledge sharing which is essential to their future.
Getting the government procurement right, together
Hopefully, those various examples of "changes to government procurement process" will help make more success cases to government procurement projects- according to a research, "94% of large federal information technology projects over the past 10 years were unsuccessful — more than half were delayed, over budget, or didn’t meet user expectations, and 41.4% failed completely".
More on that here: Why the Government Never Gets Tech Right
Instead of complaining about the failure rate, we have to work together to fix it.
Disclaimer: The opinions expressed here are my own, and do not reflect those of my employer. -Fumi Yamazaki
Identifying the problem, and example from Philadelphia
My favorite is this project by Mark Headd former Chief Data Officer of Philadelphia where they did a GitHub-based procurement - "Redesigning Government".
Let's look at the problem: that the government procurement is broken, "fear-based procurement" is taking place, meaning people working in the government in general doesn't want to take risks so they stick to less risky procurement process, with old-style vendors they know, and the newer innovative startups has no way to contribute.
In the case of Philadelphia, they used GitHub for procurement for the following reasons:
1) They wanted to use a platform that would resonate with technologists, and wanted to work with firms that believed in what they believed- "we value open source software, we value collaborative software development, we value awesome things, and existing procurement processes don't allow us to find firms that share our values" says Mike.
2) They wanted to have some insight into the quality of other work done by bidders (to be able to look at their public repos to see what kind of solutions they were working on and how active they were in participating in other projects)
3) They wanted to see creative responses - something that potential vendors probably had not seen from a city government before.
The project they decided to use this process was called myPhillyRising, and they posted their RFP (what they want to build) on GitHub Gist.
https://gist.github.com/PhillyCDO/4666456
Anybody can see it, anybody can ask question or clarification can post public comment on this Gist so that everyone will see those questions and everyone will see those answers. If vendors wanted to bid, they had to create a GitHub repository, and the proposals should be in that repository. Mark and the team used GitHub issues to evaluate the vendor proposals, tagged them and issued bugs to assign the evaluation processes to the team.
Some firms just put a pdf document on their repository, some of them submitted actual code as submission, and the city can install and test them. Another vendor submitted a website that had user stories. Changing the "deign of the procurement process" itself allowed the city to reach those creative firms with shared values.
I think this is fascinating. You can read more about it here:
Experiments in GitHub Based Procurement
Many examples around the world
But this is not the only way to change government procurement - there are many different approaches taken by different governments.
How Barcelona and Philadelphia Are Turning Procurement Upside Down
It talks about how the cities opened their RFPs to everyone to be inclusive to the local citizens, and not specifying the solutions they are looking for but specifying the problems they want to solve made bidders more creative: “If we think about procurement as less about buying solutions and more about solving problems, I think we can open ourselves up to a whole variety of innovations”
And they introduce at tweet of a woman reading the RFP over breakfast: “Suddenly, procurement has gone from something completely horrible to something people can imagine participating in.”
Example from Namie, Fukushima
I wrote about Namie in the past on this blog post: it's a town very near Fukushima nuclear power plant, over 37% of the population is over 60 years old, all of the citizens are in evacuation in other places due to the radiation, and the town is completely in a diaspora. Namie is a small town with around 10,000 households/ 20,000+ citizens, and the town decided to distribute each household a tablet to communicate among each other as well as the town to distribute information. The project has 290,000,000 yen (approx. 2,900,000 USD) as the budget, from the Recovery Agency.
With such aging society, inclusion is extremely important. Here is how they are running the procurement process, together with Code for Namie team.
They have this website that explains to the citizens what this project is about, and the process of procurement.
http://www.town.namie.fukushima.jp/soshiki/2/201405tablet.html
1. They ran 6 ideathons where citizens, developers and designers gathered to discuss ideas for what they want the tablet to be doing in order for it to be useful for them.
2. They summarized the ideas to select the theme for hackathon.
3. They ran 2 sets of 2-day hackathons to develop prototype apps, and had the citizens evaluate those apps.
4. Based on those evaluations by the citizens, the town created RFP and invited vendors to submit proposals for creating applications and running the distribution and operation of the project.
5. All of the households receive application form to apply for the tablet, and monitor households will be able to start using the test device. Events to experience the tablet will be held.
6. Based on the monitor and events, adjustments will be made, and the tablets will be distributed.
Photo from one of the ideathons:
All of the RFP and Q&A results can be seen here:
http://www.town.namie.fukushima.jp/soshiki/1/20140801-proposal.html
http://www.town.namie.fukushima.jp/soshiki/1/8133.html
This is the actual specification from RFP.
http://www.town.namie.fukushima.jp/uploaded/attachment/2870.pdf
Some of the functions includes:
1. Local news distribution
2. Radiation level information distribution
3. Local government information distribution
4. Inter-household SNS
5. Function to increase usage (support function to support non-technical people using characters)
6. Slideshow
7. Inter-citizens SNS (optional)
8. Namie archive (optional function to preserve photos, videos and cultural assets from Namie)
These are the functions that actually came from the citizens' demand. You can see the "idea sketch" from ideathon incorporated in the RFP.
They also attached the "persona" analysis of the users, for the vendors to envision the user scenario.
http://www.town.namie.fukushima.jp/uploaded/attachment/2873.pdf
1. Community leaders, old couple living in temporary housing in Fukushima City
2. Community creators, young mom & daughter in Chiba, with high IT literacy
3. Old man living alone in Nihonmatsu, enjoying single life
4. Family living in Sendai, adjusting their lifestyle based on the children
5. "SOS" type- evacuated to Saitama, but cannot adjust to the locals and having trouble with communication
There were 6 companies that made proposals, all of the proposals can be seen here: the presentation files and video of their actual presentation to the town. You can see all of the scores, overall evaluations and detailed evaluations here. It is extremely transparent.
http://www.town.namie.fukushima.jp/soshiki/1/8028.html
Watching the video archive, you realize that at the beginning of the presentation, the vendors are told "citizens from Namie are in the room listening, so please do not use technical terms- please make your presentations understandable to everyone." One of the vendors started using lots of jargons in their Q&A and one of the person from the audience replied "I did not understand a word you said. Can you explain in plain sentences?"
Also, there is one person in the room that keeps asking the same question to the vendors: "Do you know the percentage of the population of Namie over 60 years old?" and "Do you know what percentage of the citizens have evacuated outside Fukushima?" These information were all in the first couple of pages in the RFP, but surprisingly some of them could not answer.
This is the slides and video of Fujitsu that won the bid.
Slides:
http://www.town.namie.fukushima.jp/uploaded/life/8028_24220_misc.pdf
Video:
https://www.youtube.com/watch?v=AL8Ds_tNtk0
This is the short summary evaluation doc of all of the vendors.
http://www.town.namie.fukushima.jp/uploaded/life/8028_24299_misc.pdf
This one is the detailed one.
http://www.town.namie.fukushima.jp/uploaded/life/8028_24201_misc.pdf
So the first question would be "Why the heck is NTT Docomo's score so low??" NTT Docomo is the largest mobile carrier in Japan, and clearly should have done lots of app development and system integration projects like this. They actually have a lot of experience- in fact, they already have ASP service that has many of the functions needed in Namie, and have already implemented in other town in Fukushima, that they can leverage. Their proposal was basically using this ASP service, customizing to Namie. At first thought, this makes sense, and their presentation seems legit. Instead of reinventing the wheel, let's use existing apps and customize it. What they did NOT realize is that this project was supposed to be agile, collaboration project involving the citizens to prototype, iterate, test, and give the feedback loops for further iteration, although it was written clearly in the RFP. It was not meant to be "giving" the system, but "building together". Also, the citizens did research about how Docomo's similar system in other town of Fukushima was doing, and it was not functioning well. Despite using the existing system, their initial cost and operational cost was expensive.
To summarize, almost all of the steps of the procurement is open, and citizens are inclusive of that process through the following steps:
1. Citizens were involved in shaping the RFP by giving ideas of "what they need".
2. Citizens were involved in hackathons to give feedbacks to the prototypes created.
3. Citizens were involved in evaluation of the vendors by joining and asking questions at their presentation.
4. Citizens will be involved in using the app early as monitors, join "experiencing events" to give feedbacks for iteration before the final rollout.
Sure, they didn't use GitHub, all of their docs are in pdf format, but I think it is subtle in this case: this is about a small and aging town, with all of their citizens in diaspora, almost nobody is tech-savvy and they have little experience developing systems or apps, but they are working together with the citizens to build something useful for their communication and knowledge sharing which is essential to their future.
Getting the government procurement right, together
Hopefully, those various examples of "changes to government procurement process" will help make more success cases to government procurement projects- according to a research, "94% of large federal information technology projects over the past 10 years were unsuccessful — more than half were delayed, over budget, or didn’t meet user expectations, and 41.4% failed completely".
More on that here: Why the Government Never Gets Tech Right
Instead of complaining about the failure rate, we have to work together to fix it.
Disclaimer: The opinions expressed here are my own, and do not reflect those of my employer. -Fumi Yamazaki
0 件のコメント:
コメントを投稿