Project Management

The procurement lifecycle

From the The Money Files Blog
A blog that looks at all aspects of project and program finances from budgets, estimating and accounting to getting a pay rise and managing contracts. Written by Elizabeth Harrin from

About this Blog


Recent Posts

3 Tips for when your to do list is full of important things

Managing data maturity risks

What does commercial viability mean?

Building resilience into project delivery

Lessons about project metrics

Categories: procurement

People shaking handsLast week I looked at four things that go wrong with negotiations with vendors when it comes to buying things for projects.  Today I want to look at the procurement lifecycle, as presented by Alex Sandercock of Turnstone at a recent womenintechnology event.

There are five steps in the procurement lifecycle:

  1. Requirements
  2. Vendor selection
  3. Negotiation and contract
  4. Service delivery and performance monitoring
  5. Renewal, retendering or exit.

These aren’t all relevant to project managers, so let’s focus on the ones where you could have some input.  Today I’ll be looking briefly at requirements and then vendor selection, and next time I’ll cover Step 3: Negotiating and contract.


Before you start building something you need to know what it is that you have to deliver, and that means developing a proper requirements specification.  One important thing to consider here is are you buying the intellectual property rights to custom-built software or changes to package software.  Also consider your requirements for delivery dates.  Alex shared a story about a piece of hardware that was specified, configured and delivered, but was unable to get through the door to the data centre where it was to be housed.  The team had forgotten to specify the requirement that it must be able to fit through the door.

You may have business analysts who prepare requirements documentation and a development team who prepare technical specifications documents.  These all input into the next step, which is choosing which vendor can work with you to deliver the best possible outcome to meet your requirements.

Vendor selection

Once you know what the business requirements are, you can start contacting suppliers to find out if they are able to provide you with suitable services.  This stage of the procurement lifecycle could simply involve contacting the company you normally use and asking them if they want to take on the job.  This is particularly the case if your company has preferred suppliers for certain things.  Other options are:

  • Sending out a Request for Information (RFI, also called PQQ: pre-qualification questionnaire). This is used when you don’t know exactly what the solution is, and you want more information on available options to meet your needs.  This could go to one or multiple suppliers.
  • Sending out a Request for Quotation (RFQ), Request for Proposal (RFP) or an Invitation to Tender (ITT).  These all broadly have the same outcome, which is getting the vendor to send you their proposal for meeting your needs, with costs.  Again, these could go to one or multiple suppliers.

Before sending out any documentation, be sure to send a confidentiality agreement.  The whole tendering process will involve sharing potentially business confidential information about your project, and you want to make sure that the vendors don’t share this with anyone else.

Once you have decided to send out a RFP, phrase it in such a way to make the questions and answers neatly form bits of the contract.  This means you won’t be reliant on the vendor’s standard contract, which will include clauses heavily biased in their favour.  We’ll look more at contracts next time.

If you can, keep the selection criteria to yourself.  In public sector tendering for projects in the UK you have to declare the selection criteria, but as far as possible Alex recommends not sharing these with the vendors if possible.  Why give them extra help?  

Vendors will ask questions during the tendering process, and to make it fair all the companies involved should get the same information.  That means that if one vendor asks a question, all vendors get to hear the same answer.  Alex’s recommendation was to pick a date for the receipt of all questions.  Then collate the questions and respond to them.  Only handle questions in writing.  This makes sure that everyone receives exactly the same information – email is a suitable medium for this.

Finally, if you are the person charged with doing this negotiation, make sure that the vendors only speak to you!  They might try to call your project sponsor, or someone else on the project team, or someone higher up the organisation.  Warn the project team and the relevant stakeholders that you are handling the tendering process and to make sure that they don’t inadvertently give one supplier an unfair advantage by providing additional information.

Next time I’ll be looking at Step 3 in the procurement lifecycle: Negotiating and contract.

Posted on: October 26, 2010 04:03 PM | Permalink

Comments (9)

Please login or join to subscribe to this item
Elizabeth, thank you for an indepth topic on Procurement.

The only thing that I would add is that once a shortlist of vendors has been decided [usually 3 suppliers], to ask each of them to provide a presentation of their services and how these services meet the requirements, including benefits\ costs, SLA''s [escallation process included] and what really makes them unique above the other vendors. Take it a step further and visit their premises to see their set-up, not only this approach will make the selection much clearer it is about establishing business relationships [if vendor is totally new].

That's a great tip, thanks Vasoula. It will help to assess the vendors against the same criteria. Would you let the vendor know which other vendors were being considered?

I saw a question asking if it's OK to let vendors know who their competition is, and having worked on numerous procurement projects, as well as having been a Buyer, I figured I'd pitch in my 2 cents...

IMHO - It depends on the project; but unless there's an over-riding reason not to, I usually let other vendors know who their competition was. if you've done the RFP in an open and transparent manner, it won't make much of a difference, for several reasons:

1. If you've done an RFI (Request for Info) before-hand, the vendors will have likely met somewhere along the line. Even if they haven't, you'll still have a better idea of what you want to put into the RFP, and it's pretty telling when you see a requirement that "reeks" of a specific brand...

2. There's a lot of industry buzz, and most of the professional salespeople talk to each other (to keep an eye on the competition). Believe me, they talk to each other, and will find out!

3. Many vendors have something (service, desktop delivery, free support...something) which sets them apart from their competition. Once you find out what their 'selling point" is and ask the other vendors how they measure up, it becomes obvious who you've talked to.

4. Often, on large purchases (like ERP systems or large service/support contracts), there's a vendor conference that will involve all the top contenders and a panel of project members, so you can get all their questions resolved in a format that respects everyone's time. (This is necessary for the vendors to 'tune' their bids, as well as an opportunity for the evaluation team to compare and contrast each vendor.)

Also, letting vendors know who their competition is can be pits them against each other and gives you a strong position in the bargaining process without lifting a finger. This allows you to sit back while the vendors beat down their own price or offer "bells and whistles" to out-do the competition, without leveraging your position or relationship.

Don't under-estimate the salespeople...they're not stupid, and can figure out who you've talked to with a little work. It's best if you work with them, instead of working against them. (But never forget who you're working for!)

I agree that transparency is the best policy. If you believe they will find out anyway, you might as well be upfront with them. I also heard it is a better idea to not disclose the criteria against which they will be assessed, unless you have to (for some public sector projects, for example). This will hopefully encourage them to present their solutions in the best possible way, rather than focusing on the things that will give them points.

Visting their (Vendor's) premises is a good idea. Moreover, I would also like to know whether these vendors were involved earlier in this type of project(s) or similar project(s) anywhere else and how was the outcome like is the customer happy etc.

Understanding the vendor's premises is a great suggestion, especially if you are looking at a cloud computing service. Some contracts may require you to not transmit data out of a certain geographic area, and knowing where they do their data processing is key to knowing whether you can use their services or not.

Hi Elizabeth

To answer your question, once a shortlist of vendors has been decided, inform the vendors in question that there are other vendors in the running, this approach will ensure that they do not become too comfortable, the contract will go to the very best.

Great discussion.
I would like to add two things:
When you are in the area of support of critical business processes in your company you might also ask the vendors on the short list to develop a Proof of Concept and select one or two business processes. in this way you will see the way the vendor works if he can meet timelines, if there is chemistry and understanding and last but not least if the result is liked with the end users. Does it meet the expectation

The ideal thing is to have the proof of concept at your premises

As a question I am always interested in is what will there solution do to the total cost of ownership.

Hopes this contributes

Hans, thanks for your comment! You might like to read the next installment of this, which is about negotiating.

Please Login/Register to leave a comment.