Project managers have to get involved in the procurement process, and recently I went along to a womenintechnology event to hear Alex Sandercock from Turnstone speak about improving your skills in procurement.
50% of IT budgets are now spent with third party vendors, and project managers are often involved in setting up these arrangements. The balance in the negotiations is uneven, though. The vendor’s sales team just does selling: that’s what they are trained for, and that’s what they spent their time doing. Project managers on the other hand – buyers of the services – don’t get any training in buying, and we don’t do it full time. We’re at a disadvantage.
Here are Alex’s top procurement disasters:
- Assuming that negotiation can finish after the work actually starts
- Inadequate statement of work or requirements specification
- Acceptance of undocumented assurances from suppliers
- Focusing on speed instead of delivery and rushing the process
Let’s look at each of those.
Assuming that negotiation can finish after the work actually starts
Hands up, has this happened to you? It’s certainly happened to me. Work starts without a purchase order in place or a full understanding of the costs. Then you try to query something with the vendor who comes back and says it is too late to be negotiating these small points and the time for discussion was before you said yes to starting the work. Apart from cancelling the work completely – and you might find it difficult to wriggle out of the contract even then – there isn’t a lot you can do.
The lesson here is to make sure that you have a full understanding of what is going to be done and what it is going to cost. Sign a contract only when you believe the negotiations are done. Never sign a contract that isn’t completely negotiated! And only issue purchase orders once you are clear what it is that the vendor will be doing.
Negotiating once work starts puts you in a much weaker position, so if this looks likely to happen on your project, talk to your project sponsor to see how they can help speed things up.
Inadequate statement of work or requirements specification
Surprised? I wasn’t, and I’m sure you’re not. Don’t start work without knowing what it is that you are going to get. Project requirements are important and having them in as much detail as possible ensures the best chance of actually getting what you want at the end of it. Ideally, build in review points with the vendor to check that they have interpreted the requirements accurately. And build in review points with the customer, so you can be sure that the project is still on track from their perspective too.
It’s not enough to only have high level requirements when you are committing a vendor to carry out work on the project. You both need to know what it is that is being delivered.
Acceptance of undocumented assurances from suppliers
“We can do that,” the vendor project manager says to you as you get coffee together before a meeting. “Leave it with me.” That’s not good enough. You pay these people to deliver what your project needs, and verbal assurances are not enough.
Project team members change, both on your side and on the vendor’s side. What happens if that person leaves? What if they aren’t senior enough to be making that kind of commitment? What if they think they are and then have to pretend they never said anything when they find out that actually their software can’t do whatever it is they promised?
Get it in writing. Always.
Focusing on speed instead of delivery and rushing the process
Speed to delivery is always important in projects. We want to know when things will be done so we can tick off milestones on our project plans. But sometimes quick is not good.
Don’t rush the procurement process. There’s pressure to get things done quickly, but talk to your project sponsor about the importance of getting these negotiations right. Don’t be tempted to agree before you have had the opportunity to properly investigate all the contract details and you are happy with the outcome.
Next time I’ll be looking at the procurement lifecycle.