The purpose of this blog post is to explain in depth what the procurement processes are, then compare and contrast them in traditional versus Agile environments.
First, we should explain what procurement is and what it is all about. Procurement simply means getting resources or services from an outside source. So project procurement management is doing stuff like identifying, acquiring, and managing these goods/services to complete a project. The subject of project procurement management is a big one, it can include something like going to the store to get some supplies, to outsourcing sections of the project. Companies that supply these resources or materials are mainly known as suppliers but are also known as things like vendors, contractors, and sellers. Someone might ask, is it good to rely on these outside suppliers for your project rather than just do things yourself? It honestly depends on the situation there might be hundreds of reasons to get resources from somebody else, they might be cheaper or more accessible, or they might just be better. And there are just as many if not more reasons why parts of the project are outsourced. An example is a team is trying to make a video game, they are really concerned about the gameplay and mechanics of the game but are too bogged down with quality assurance and testing, so the company decides to hire another company to do all those things for them so they can focus on the part they think is important.
Here are some more benefits of outsourcing.
Image source: https://agiliway.com/wp-content/uploads/2019/01/benefits-of-outsourcing-1024x649.jpg
There are three processes in project procurement management.
Planning- this is where you decide what you need to procure and how you will do it.
Conducting- This is where you get a response from suppliers, select them, and award contracts.
Controlling- You monitor the relationship and contract performance of the seller, make changes if need be, and close contracts.
As mentioned, this is the process where you are just choosing what or who you will need and how you will get it. During this part, there will be a make-or-buy decision, this decision says what it does in the name, and the company decides if it will make these goods or services inside the organization, or will acquire them from outside of it. If everything is going to be inside, then you actually do not need project procurement management anymore, as there is nothing you are procuring. Another important part of this process is the how, the answer to the how are contracts. When it says the organization will decide on how they get the stuff, it means what type of contract they will choose. There are several types of contracts, some are risky for the buyer while others are risky for the seller, and some are risky for both, but in the end, the buyer must choose a type of contract that they and the supplier agree upon. Some other things that are included are project procurement plans and statements of work.
In Agile the procurement plan is developed iteratively- with each sprint. Meaning not everything is set in stone at the very start, it is regularly updated and reviewed to make sure it evolves with the needs of the project. It can also be adjusted due to stakeholder feedback or experience from previous iterations.
This part is all about the selection of the supplier, by the end, the two things you should have are a selected seller and agreements with them. The buying organization is meant to advertise its work while the supplying organization is meant to advertise its goods or services. It is really recommended you ask around and see what everyone is offering so you can have the best. Something called a "bidder's conference" might be held so that part parties are on the same terms when it comes to the agreement.
One thing to note is that, while it is good to have good relations with your suppliers, it is important not to become too dependent on them.
As with planning, there are no large decisions that are made and held until the end. Instead, it is a more buy-as-you-need type of thing.
Controlling is all about making sure that the contract is being met by both sides. It is a legal agreement, meaning that it is subject to state and federal contract laws. Someone on the project should be the one who helps make decisions in the contracts, but there should also be legal professionals involved when need be. It is a lot better to lose a little money because you had to hire a lawyer to help with the contract than to lose a lot of money because you did not and now you are getting sued.
Some good practices for controlling project procurement are:
Making sure changes to the contract are made in writing, and that the changes are approved by the same people who originally decided on the contract in the first place.
Any changes made should have an impact analysis done.
Having tools and systems in place to update and check contract requirements.
The final part of controlling is closing contracts. This is just making sure contracts are completed formally and correctly, there should already be something in place for closing contracts. Results from the contract should be updated and stored for future use.
Most are the same in Agile, since there are no big plans or purchases things are done in much smaller and incremental steps.
When it comes to Agile, project procurement management is done in much smaller steps. One of the biggest differences between traditional methods like waterfall and Agile is that traditional methods have these big plans that are more or less static because they are so big that it makes them hard to change. Agile is smaller so changes are incremental but more manageable. This whole ideology can be seen in project procurement management.
Outsourcing: One company hires another for an activity that could have been done internally.
Impact Analysis: An analysis to measure the effects a change can have on things like scope, time, cost, and quality.
Here is an example of what an impact analysis can look like.
Schwalbe, K. (2018). Project Resource Management. In Information Technology Project Management (9th ed., pp. 505-538). Cengage.