In my previous article, I discussed the importance of learning the procurement process. This article will cover the importance of understanding your project’s requirements for procurement, and the timing of the delivery of those items.
Your project requires that a certain amount of hardware and/or software must be purchased and delivered to one or more locations. This seems fairly simple at first glance, but if you are to be successful at navigating the procurement process, there are some things you should consider.
Hardware and software standards are common in large organizations. If you have a list of all of the items that the team has indicated that needs to be purchased, this list needs to be very specific and needs to be reviewed by whoever is responsible for enforcing the hardware and software standards. Depending on the size of the organization, the team that provided you with the list of hardware and software usually will not be the same team that develops and enforces those standards. The last thing you want to do is order the hardware and then be told you have to order a different model or software release in order to comply with those standards. When you ask for a list from your team, ask that the hardware and software on the list are very specific. The list should include AT LEAST the following information:
- Hardware device manufacturer, model number, and quantity
- Software vendor name, full product name and version required
- Cost center or project number that has approved funding for the project (Process specific)
- Date by which you need that device or software available for configuration
- Contact person for questions regarding the order and their contact info
- Email address
- Phone number
While you are assembling the list of hardware and software you need, remember that the date you want the hardware delivered is NOT the date the user indicated they needed to begin using it. The project schedule needs to allow for the time required to physically rack the hardware, provide power and network connectivity to it, configure it, install software on it, etc. So, before you hand that list over to procurement, meet with the engineers and other team members who have work to do and determine how much time they need to rack and configure before the device is turned over to the user. Subtract that time from the user required date, and that becomes the date you want the hardware delivered. Also understand that once the purchase order is actually cut for the vendor, there is any number of factors that could delay the delivery of that hardware, so plan accordingly.
When you learned the process, you learned what the average lead time was between the time you submitted your requirements to procurement and the time you could expect the request to make its way through the process and equipment or software would be delivered. It is CRUCIAL that your initial requests be submitted early enough to allow for this lead time. If you are ever going to have a good rapport with the procurement team, the last thing you want to do is make your first couple of requests emergencies and ask people to jump through hoops so your project will not be late. It is your responsibility as project manager to calculate these lead times and ensure that anyone who needs to deliver something has an adequate amount of time to do so. Procurement teams in large organizations are usually under the gun at all times, so it takes some time to get the team to know you are willing to follow the process whenever it is humanly possible to do so.
Here are some other things that will help develop a good relationship with the folks in procurement:
- Invite them to meetings so they can understand the requirements
- Make yourself available for questions
- Treat them with respect
- Let them know that you understand the pressure they are under
Then, when a project comes along where you were not given sufficient lead time, they will be much more willing to cut you some slack and expedite things where necessary to meet what could otherwise be an unrealistic delivery date.
You will find that this is a great way to begin to navigate your company’s procurement process. There’s more to come in my next article.
Meanwhile, if you have comments, questions, or suggestions for topics to be included in future articles, please comment below, and I’ll do my best to answer them.
Phil Katz, PMP, SA, ITIL, has 25 years of project management experience spanning various industries and currently works at a major insurance company managing infrastructure projects and providing infrastructure support to application development. He remotely leads large and globally diverse project teams. His experience extends into the area of infrastructure procurement, and he advises stakeholders on the best way to navigate that process at a fortune 100 company. Phil writes about procurement and remote project management.