The Money Files

I looked at the first two steps of the procurement lifecycle: requirements and vendor selection, as explained by by Alex Sandercock of Turnstone at a recent womenintechnology event.

Today I’ll be looking at Step 3: Negotiating and contract.

A typical IT contract has 50-100 configurable clauses. That’s a lot to take in, especially if you aren’t used to dealing with procurement issues.  In some companies, procurement and managing suppliers is part of the job, but in others you may have a team of buyers or procurement experts to help. Either way, as you are close to the project’s requirements it is likely that you’ll get involved in drafting the contract.  Of those configurable clauses, you should consider negotiating about 20-50%.  

Of course, the exact amount of negotiation you want to do when the vendor presents you with the contract is entirely dependent on what the contract says.  It could be completely acceptable to you.  But the important thing to remember is that you don’t have to accept the contract at face value.  Don’t just focus on negotiating the costs and the legal aspects of the contract.  You can negotiate on everything.  After all, you are representing the company’s best interests.  What is right for the vendor is not necessarily right for your company.

These discussions with the vendor should include things around warranties, as you would hope that the contract would specify that software would be delivered substantially error free.  If that clause isn’t in there, add it.  Make sure you understand the warranties and how to invoke them.

Service credits are another thing to look out for.  What happens if the service is not up to scratch?  Say you buy a piece of cloud technology for your project and it is unavailable more often than not?  Your requirements would have specified up time, and hopefully that is what you get.  But if it isn’t, you need to ensure that you have some kind of ‘payback’. Service credits are payment for when service levels are not reached. They do not need to be substantial amounts of money.  Often service credits have to be authorised by the Finance Director, and that provides a level of visibility about the poor service that is being offered.  That alone can be enough to improve the service for the following month.

The contract should include information on liabilities as well. Alex’s recommendation was that the liability should be unlimited for personal injury or death and limited for direct loss.  

There will also probably be a standard clause on force majeure.  Read this one carefully – does it include an exclusion for strike action? With all the ongoing industrial disputes in the UK Alex recommended that this clause be crossed out.  Just draw a line through it and see what the vendor says.

Finally, consider what happens when you want to terminate the contract.  As with the rest of your project, where you are continually planning for closedown, think about how you are going to get out of this contract when the time comes.  What do you want from them on exit?  Specify the documents they will provide for you, service reports, any training you’ll need for internal or external staff, any transition support arrangements and so on.

The final 2 steps in the procurement lifecycle are:

• Service delivery and performance monitoring
• Renewal, retendering or exit.

These happen when the project has delivered the software and the contract and project deliverables have been handed over the operational team who are going to use them going forward.  The project structure no longer exists at the point that these lifecycle stages take place.  However, think about these when you hand over the project into the live environment, as all the relevant contract information and the history of the negotiations should be passed over to the operational team.
 

Last 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.

Requirements

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.
 

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.
 

Pedro Serrador presented yesterday at PMI Global Congress North America on how to become a program manager.  There are many career advantages to program management – not least that program managers tend to earn more than project managers.  So if you want to move into program management, here are Pedro’s tips.

“A program manager adds more value than just project managers,” said Pedro.  He said there are eight principles to being a successful program manager, and shared these from Vincent J. Bilardo, Jr.:

• Establish a clear, compelling vision
• Secure sustained support from the top
• Exercise strong management and leadership
• Facilitate open communication
• Develop a strong organisation
• Manage risk
• Implement effective integration
• Create your own success

Moving to a program manager role requires you to deliver the goods, he said.  There might also be a case for upgrading your education, and learning from others.  Pedro also said that prospective program managers should put themselves in a position where they can lead and mentor others, and especially learn to delegate appropriately.  “Show that you are a leader, not just one of ten project managers in the group,” he added.  Look for the opportunities that arrive and take them.  Finally, act the role, he explained.  “If you want to become a program manager, act like a program manager. Start to structure things like programs.”  If you act like a program manager, your manager will see that you are capable of operating at that level.

“Often it is beneficial to move around,” he said, when he spoke about how to land that new program management job.  That could mean moving to a new initiative or to a new company.  He explained that outside CEO’s earn an average of 13% more than internal candidates.  However, they fail 34% of the time, compared with only 24% of internal candidates, so there is something to be said for sticking with what you know.  “Moving is riskier,” Pedro said.

Pedro had some tips for what to do when you get that first program, or you choose to structure your existing work as a program (even if you don’t yet have the title):

• Structure sub-projects properly
• Make your project managers run things how you would run them
• Don’t micro-manage
• Get strong business and executive level focus

Pedro also said that senior managers spend more time planning their own time.  “You help the projects managers get on the right track and then go on to something else,” he said.  Factor that into your daily schedule and take the time to plan your day (and your schedule in general).  It might seem like it takes a long time but it will be effective.

“A big part of your role is to let the stakeholders know the importance of your program and you need to be able to push to have obstacles removed,” he said.  His final piece of advice was to have a 30 second status summary in meetings in case the executive you are presenting to gets called away.  “Know to stop at yes,” he added.

“It was two years of effort and two years of struggle,” said Steve Wake, describing the work to bring the Earned Value Management certification to fruition yesterday.  Wake, the chief examiner for the EVM qualification, was speaking at Project Challenge.

“The best thing that a project manager can do for us is this – it’s status,” he said.  “It’s where we are and what we’ve done.  To ask a project manager to do more than that is quite a lot.”

Earned Value does ask us to do more than that.  Wake explained it as “a disciplined framework for managing work.”  His definition is:

“A project control procedure based on a structured approach to planning, cost collection and performance management. It facilitates the integration of project scope, time and cost objectives and the establishment of a baseline plan for performance measurement.”

Got it?

If not, never fear.  There is a new exam you can take to prove you understand the concepts of EVM.  “It keeps you out of harms way,” Wake said of the new qualification.  “You’ll understand the language and vernacular and when asked to do something you’ll have a grasp of the process.”  If that sounds basic, it’s because it is.  There is no Practitioner EVM qualification yet, but there is one in the works.

The Foundation exam, like the others from the APMG stable, is a multiple choice, entry level paper.  It’s 40 questions, 30 of which are knowing/comprehending questions and 10 of which are applying/analysing questions.  Questions are based on the EVM – APM Guidelines.  Candidates have one hour to sit the closed book exam and the pass mark is 65% - or 75% if you want to be an assessor.  Wake explained that when the pilot group took the exam all but one passed.  This has given them confidence that they have set the difficulty levels appropriately. 

There is a course that accompanies the exam, although it is not compulsory and you can enter yourself directly for the qualification itself.  The course objectives are:

• Define EV concepts
• Select and deploy EV formulae
• Describe EV processes
• Explain different levels of system review
• And of course, take and pass the exam.

“We have a problem with Earned Value in the UK,” Wake said.  “We all use it, those who say they do, but there’s no way to put a stamp on it.”  He hopes that this qualification is the stamp, and that it will help avoid differing understandings and applications of EV.  However, he was pragmatic about how much a qualification can really increase the abilities of project managers.  “If you are confident that the thing is working correctly it frees you from chasing data,” he said.  “Exams are good because they determine a standard and also because with this method they give you the chance to manage.  With a good method you make good people very good.  It won’t make bad people good, though.”

The EV qualification has been put together by APM’s Earned Value SIG, and they are now working on a paper to discussed EV and PRINCE2 alignment.  “They are a good overlay to each other,” Wake explained.  “There’s limited detail in PRINCE2 about how you measure progress.”  This paper will be presented to the Best Practice User Group mid-November and made available after that – watch this space for more on how the two fit together.