The procurement plan is an interesting one…at least for me.  I’ve only created a procurement plan on 3 or 4 projects so far in my 19+ years of running IT engagements.  Basically, the procurement plan describes the functions and activities that are necessary to successfully procure materials and equipment essential to project deployment. How to get what, who needs to approve it, what selection criteria to use, what types of contracts will be utilized on the project, and even what spending limits will be in place may all be part of the formal project procurement plan.



If a procurement plan is required or is going to be utilized on the project, the project manager should establish procurement requirements to determine which resources should be procured externally versus internally. The procurement plan can be short and consist of only a few pages if required, but it should clearly list the intended resources needed to implement the solution. These resources could be hardware, software, leasing agreements, licensing or any other materials required on the project. The plan specifies vendor selection, acceptance of vendor deliverables, and the procurement process policy and procedures that need to be followed.



The procurement plan’s real role is to layout the overall process that must be followed to obtain what is needed to get the work done.  And of course that culminates with who can purchase and approve the materials.  While this type of plan may not be needed on all projects, if there are lots of acquisitions that must happen in order to successfully complete the project – and you know this from the start – then it’s going to be a good idea to put a procurement plan in place.  The key is to call it a project deliverable, formalize it, have it reviewed and signed off by the project customer, and definitely get paid for it as a formal project deliverable if at all possible.