The Money Files

A blog that looks at all aspects of project and program finances from budgets and accounting to getting a pay rise and managing contracts.

About this Blog


Recent Posts

How to read a bridge (and use one on your project)

What recruiters want from project managers (and what the project management industry thinks they want)

How much do you cost your project?

Easy illustrations for your project meetings

7 Reasons to crash your schedule

5 Steps for Make or Buy Analysis (video)

Categories: procurement, video

Posted on: July 29, 2014 05:06 AM | Permalink | Comments (0)

Make or Buy? Advantages & Disadvantages (video)

Categories: procurement, video

Posted on: June 23, 2014 05:36 AM | Permalink | Comments (0)

Procurement Management 101: Three Types of Contract

Categories: procurement

You can’t do many projects to change something without spending a bit of cash. And when money is involved, a contract is essential! Generally you’ll come across one of three types of contract on a project: fixed price, cost-reimbursable (also called costs-plus) or time and materials. However, the contract is for the whole deal, so if it makes sense to have some services from a vendor on a fixed price basis and others on time and materials, then the contract would include both these terms. You wouldn’t have a different contract for both elements simply because they were on different terms. There may be other reasons to have contracts for different terms but they are likely to be because the deal was agreed at a different date or similar.

OK, let’s take an example. You want to buy software consultancy and development services from a vendor. They will help you spec out the software so it is fit for use by the users, then they will build it. The requirements gathering part of this deal is on a fixed price basis. They know that it will take them 6 workshops and some prep time to prepare the complete requirements, so they can cost for that in one hit (fixed price). But they don’t know how long it will take to build the software, because they don’t have the requirements yet. If it’s a lot of work they want to be compensated, but they don’t want to overcharge you if it’s not much work, so they’ll price that based on the effort it takes (time and materials). They do know that there is a software licence that they will have to buy on your behalf, and you plan to pay them for this at the purchase price (cost-reimbursable). The one contract between your company and theirs will cover all these elements.

You choose your contract terms based on the best procurement arrangement for your company and theirs depending on what you both want to get out of it and making sure that everyone’s interests are covered. So let’s look at those three contract types in a bit more detail.

Fixed price contracts

With a fixed price contract the buyer (that’s you) doesn’t take on much risk. This is great for the project’s risk register, but not so great for the project budget. As the seller adopts all the risk they normally add a bit to the price to allow for any risks. For example, just because our software consultancy firm thinks it is going to take 6 workshops to define requirements because it has done on the last 10 occasions this doesn’t mean it actually will this time round. They have never worked in your industry before so they add enough into the fixed price proposal to cover them in case they have to do more.

What sometimes happens is that vendors want to win your business so much that they price too low. The problem there is that if something does go wrong and all the risk is on the vendor’s side, they then don’t have enough profit in the deal to make it worth their while, and they may even lose money by working on your project. If this happens then you should watch out – they may start to cut requirements or drop quality to try to claw something back.

However, the advantage for you with a fixed price contract is that you know exactly how much it is going to cost you before you begin the work, and for many project teams this is very valuable.

Cost-reimbursable contracts

With a cost-reimbursable contract you pay the vendor for the actual cost of the work. This could be materials, equipment, whatever and will normally include direct (e.g. salaries) and indirect costs (e.g. electricity for running the office). Indirect costs will be a fixed percentage amount – they won’t send you their electricity bills and ask you to pay a proportion.

So how does the vendor make any money? Obviously they aren’t working for you for nothing, and while you are covering all their expenses they want there to be some kind of financial return. The contract will include a clause that allows them to claim a profit over the cost price, either a fixed fee or some kind of incentive payment. It’s common, but if your vendor proposes this make sure you fully understand what you are signing up to.

Time and materials contracts

Time and materials contracts see the vendor being reimbursed for materials purchased plus a per day or per hour rate for time spent. The developers building the software in this example will charge on a time and materials basis. In this case, there probably won’t be many materials and they will charge their daily rate for time spent writing and testing the new product. They will act pretty much as if they are a salaried member of your project team, and you’ll have a fair amount of control over what they do (as you are paying for it, after all). They might ask you to sign timesheets or at least submit their own timesheets for your approval along with the invoice as proof of the hours spent working on your software.

This sort of contract is great for projects where you don’t know exactly what you want when you start out. Provided you keep a close eye on costs and manage the budget and the work so that you don’t overspend, this can be a really cost effective way to add more resources and skills to the team.

Which of these have you used on your projects? Let us know your experiences in the comments.

Posted on: May 20, 2014 05:26 AM | Permalink | Comments (0)

7 reasons why you need a resource management strategy

PeopleDoes your project or program have a resource management strategy (RMS)? While they are mainly used in program management, you can also find an RMS useful in a project environment. This is especially the case if your project is not affiliated to a program and you have to work it out how to handle resources yourself.

An RMS sets out how the project or program will get and manage the resources it needs to achieve the change required – after all, projects are about delivering change and you need resources to do that. “Resources” is not just an unfriendly word to describe people. Resources can be:

  • Money;
  • Buildings;
  • Equipment;
  • Technology;
  • Services, and of course;
  • People.

The people element can include temporary staff, permanent staff, contractors or part-time employees.
An RMS helps you manage the approach to using these. Not convinced? Here are 7 reasons why you need a resource management strategy.
1. It describes how the human resources requirements will be managed. This includes internal and external resources. How will you keep their line manager informed? Will they be part of a matrix organisation and if so how will this work in practice? Will you have the people reporting directly to you instead?
2. It describes how you will manage the transfer of knowledge and skills back to operations when the project has finished. This part of the RMS can be an input into the training and communications strategies.
3. It defines the dispute resolution process for when resource conflicts happen. And they will! Having this documented in advance will help you deal with issues as they arise. You will already have plans for how to fix problems, for example, when resources are called on to business as usual work or other projects. Who will arbitrate? Will it be the program manager or a board member? Can you solve conflicts yourself or do you need someone else to look at the overall priorities of the project portfolio?
4. It sets out how you will resource business as usual activity when you are using project staff for your project. The company still needs to operate, even when project resourcing demands are high. The RMS acts as a prompt for discussions with line managers. You can use it as a basis to ensure that they have plans in place for when they need to resource the ongoing commitments for their departments.

5. It defines an approval process for getting people and money.Don’t underestimate this! It really does help to know in advance about how to get resources for your project. It will save a lot of time and negotiation if you have already talked to the process owners and other people involved and already have this written down.
6. It defines the accounting and financial reporting procedures for the project. An RMS can also be used to determine how you will get financial resources, how you will spend it and how you will monitor it.

7. It defines the procurement strategy. You might not need an entire procurement strategy for your project or program, so you may find that this section of the RMS just references your corporate procurement process. This explains how you go about buying things and what arrangements or contracts need to be in place.

Remember that resources are not just people! A resource management strategy can help you be a helicopter project manager and see the big picture for all the resource needs on your project or program.

Have you used one or got any tips? Let us know in the comments.

Posted on: August 06, 2011 10:17 AM | Permalink | Comments (1)

Procurement Lifecycle: Negotiating and contract

Categories: procurement

Picture of people signing a contract 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.

Posted on: November 03, 2010 01:35 PM | Permalink | Comments (3)

"Love your enemies just in case your friends turn out to be a bunch of bastards."

- R.A. Dickson