You forgot 'risk'. That was the main thing I noticed at CitySafe was that, rationally enough, eliminating risk in a project was a major issue for people. Consequently the system is designed to favour large contractors, or at the very least to ensure that large contractors, from approved supply lists only, assume the risks involved in dealing with any smaller contractors who aren't huge companies.
As you've identified, this is clearly going to make it harder to ensure the most suitable product or service wins.
So I would suggest three things:
1) You and I know that being agile actually reduces risk, so that needs to be made evident. Diagrams and crayons might help here.
2) Have the procurement system acknowledge that the risks created from being a small company (such as suffering from cashflow problems) are different from the quality of their service or product, and create ways to compensate for this. Partnership with a large supplier doesn't do much other than triple the cost of the project.
3) Have a look at the Rapid Procurement Processes employed by the military. This is their response to realising that slow procurement meant dead people. Not only will it probably include a lot of good checks and test points, but will also demonstrate agile procurement being employed at the highest levels.
Joe
· 8 months ago
Hey bro,
I haven't experienced the governments procurement process but I have been involved in a number of procurement exercises at the large corporate which pays my salary and I expect that the process is very similar.
My observation is that the aim of our current procurement process is to define a project outcome or result in a large degree of detail and then get that priced by a number of competing bidders.
This results in a game of cat and mouse between the procurer and the bidders.
The procurer is trying to nail down exactly what it wants so that when the bidders fail to deliver they can point to the contract and say "you said you would do X. see it's here in black and white" i.e. They are trying to offload risk.
The bidders are trying to win the contract without committing to too much that they can't deliver. The bidders also want to have mistakes in the contract so that when the procurer says "Oops! We didn't get that quite right in the contract. Sorry could you just make this change..." the bidder can say "Certainly Sir but as it's not in the original contract you will have to pay £1 zillion"
The answer to this in my opinion is to stop trying to define outcomes. This is (of course) one of the teachings of agile.
So how do we specify a contract? Easy: The procurer says "I have a job to do. It requires people with skill X and skill Y. Can you bidders tell me how many people you can give me with what skills and at what rate?"
Bidders can then compete on the skills of the people provided which can be checked by looking at CV's or interviews with the people who will be involved.
Contracts can then be agreed on either a pay as you use basis or more likely a "call off" basis where the procurer pays £X and the project burns money as the people work until it runs out (or the project is finished)
This allows both parties to work closer together in partnership and lets them embrace change and generally be agile.
Problem is that this means that the Procurer has to accept that the risk of the project failing themselves and can't offload risk to their suppliers. This is an illusion anyway as the procurer will get blame if the project fails anyway but psychologically this may be difficult for them to accept.
Cheers
Joe
alex
· 7 months ago
Hi
If you live in a Conservative held seat, suggest you speak to your local MP. If they get in next year, they can start the work now
All Comments
As you've identified, this is clearly going to make it harder to ensure the most suitable product or service wins.
So I would suggest three things:
1) You and I know that being agile actually reduces risk, so that needs to be made evident. Diagrams and crayons might help here.
2) Have the procurement system acknowledge that the risks created from being a small company (such as suffering from cashflow problems) are different from the quality of their service or product, and create ways to compensate for this. Partnership with a large supplier doesn't do much other than triple the cost of the project.
3) Have a look at the Rapid Procurement Processes employed by the military. This is their response to realising that slow procurement meant dead people. Not only will it probably include a lot of good checks and test points, but will also demonstrate agile procurement being employed at the highest levels.
I haven't experienced the governments procurement process but I have been involved in a number of procurement exercises at the large corporate which pays my salary and I expect that the process is very similar.
My observation is that the aim of our current procurement process is to define a project outcome or result in a large degree of detail and then get that priced by a number of competing bidders.
This results in a game of cat and mouse between the procurer and the bidders.
The procurer is trying to nail down exactly what it wants so that when the bidders fail to deliver they can point to the contract and say "you said you would do X. see it's here in black and white" i.e. They are trying to offload risk.
The bidders are trying to win the contract without committing to too much that they can't deliver. The bidders also want to have mistakes in the contract so that when the procurer says "Oops! We didn't get that quite right in the contract. Sorry could you just make this change..." the bidder can say "Certainly Sir but as it's not in the original contract you will have to pay £1 zillion"
The answer to this in my opinion is to stop trying to define outcomes. This is (of course) one of the teachings of agile.
So how do we specify a contract? Easy: The procurer says "I have a job to do. It requires people with skill X and skill Y. Can you bidders tell me how many people you can give me with what skills and at what rate?"
Bidders can then compete on the skills of the people provided which can be checked by looking at CV's or interviews with the people who will be involved.
Contracts can then be agreed on either a pay as you use basis or more likely a "call off" basis where the procurer pays £X and the project burns money as the people work until it runs out (or the project is finished)
This allows both parties to work closer together in partnership and lets them embrace change and generally be agile.
Problem is that this means that the Procurer has to accept that the risk of the project failing themselves and can't offload risk to their suppliers. This is an illusion anyway as the procurer will get blame if the project fails anyway but psychologically this may be difficult for them to accept.
Cheers
Joe
If you live in a Conservative held seat, suggest you speak to your local MP. If they get in next year, they can start the work now
http://delicious.com/harrytc/agile+procurement