Topic 10: Contracts, accreditation & tools
Most complex projects involve several contracts, so as much as you are a project manager, you also need to be a contracts manager. One of the first issues that you need to consider regarding contract management is what country you are in and what type of legal system and legislation exist in that country. Many multi-national companies fail to understand that different legal systems operate in different countries.
"The legal concept of contract has been defined in different ways, but most definitions emphasise that a contract usually results from an agreement which gives rise to legal rights and obligations between the parties to it, rights which will be protected and obligations which will be enforced in the courts"
(Vermeesch & Lindgren 1998: 135–136).
The question whether a simple contract exists may involve a threefold inquiry:
1. Was there an agreement between the parties? If so,
2. Did they intend their agreement to result in legal obligations? If so,
3. Is the agreement supported by consideration?
If the answer to each question is 'yes', then there is at least an apparent contract.
The basic elements of a contract that we tend to be concerned with are an intention to make a legally binding agreement, the agreement itself and consideration. A 'contract' is made when the accepting party verbally said yes to the offer. The piece of paper is actually evidence of the contract—but not the contract.
Projects many take several years to fulfil a contract. Parties to contracts may also change their mind. When agreed by the project manager, these changes become a binding agreement subsequent—that is, a new contract.
There are a number of terms used to indicate the type of contractual relationship we are talking about. In the broadest possible terms, we have fixed-price, time and materials, and cost-plus contracts.
Large development contracts are termed fixed-price when the bulk of the development risk is with the developer and a single price has been set. Within the overall fixed-price group of contracts there are a number of sub-types that include:
* firm fixed-price (FFP)—where no adjustments to items such as shipping, CPI or Foreign Exchange (Forex) are allowed at all
* fixed-price with economic price adjustment (FP–EPA)—which includes allowances for changes in external variables, e.g. price of oil, CPI, Forex, etc.
* fixed-price incentive (FPI)—a broad category that indicates that the developer can get more profit if it is able to achieve some targets, e.g. a higher price for coming in ahead of schedule, but a lower price for going over schedule.
Time and materials contracts are probably the most common form of contract used to hire contract labour. In time and materials contracts, the risks are totally with the customer and the supplier actually makes more profit when the costs go up. A time and materials contract is a good type of contract for hiring one person (because it is very easy to create), but is a very poor contract for large systems projects and so is almost never used.
In cost-plus contracts, the customer will pay for the developers' cost (an audited or auditable cost) plus some allocation for profit. In our cost-plus contracts, the profit element is clear and seen by both parties. Variations include Cost-plus fixed fee (CPFF), and Cost-plus incentive fee (CPIF).
Variations in the form of imposed ceilings and floors can be included in almost all the types of contract we have discussed. Ceilings and floors can also be used for almost any variable within a contract. A time and materials contract might have a ceiling on the number of hours to be charged. A cost-plus contract might have a floor for the minimum administration fee. A fixed-price contract might have the CPI and Forex variance (risk) assumed by the contractor unless they exceed certain limits, after which the customer will recompense the contractor.
Another type of commercial relationship exists where two organisations intend to join forces in some way. This is typical of the Public–Private Partnership type contracts (PPP) that are used by governments worldwide. The contract may call for Build–Own–Operate–Transfer (BOOT) to the government, or Build–Own–Operate (BOO) where the developer keeps the asset. Again, many variations to these concepts can apply, and any of the fixed-price or cost-plus types of contracts could be used.
It is money that drives most commercial organisations and project managers need to understand the language of money, track the flow of money (budgets and actuals) and increase the value delivered to their customers. To do this, the project manager needs to have an understanding of the project management process, but also the product development process and the commercial and legal environments.
Customer (Customer Project Manager) -> Contract -> Prime Developer (Prime Project Manager) -> Sub-contract -> Sub-Contractor (Sub-Contract Project Manager)
The customer is the organisation that has the business case (need) and created the system requirements. They will have a project manager who is responsible for the acquisition of the system. This project manager will have a title like Customer Project Manager. The Customer Project Manager will be responsible for developing and monitoring the contract for the supply of the system from the developer to the customer.
The second project manager is the Prime, Development or Contract Project Manager. The business case for the Prime Project Manager is the profit to be
made from the development and the contract provides most of the requirements and scope details that this project manager needs. The Prime Project Manager is less interested in determining business needs and drivers and more interested in the technical development and determining commercial requirements by analysing both the system (product) requirements and the terms and conditions.
The Sub-contract Project Manager is in a similar position to the Prime Project Manager. They have their contract and must ensure that their organisation delivers in accordance with the contract.
To summarise, each project manager has a project, a scope and contract requirements that are similar. Each project manager faces compliance, schedule, budget, technical, resource, deliverable, documentation and process issues. Their roles are similar, but their customers are not.
The customer's total costs comprise: (a) their non-contract costs (e.g. their project administration), (b) their contingency costs (i.e. the amount they retain to cover their retained risks) and (c) the customer's cost which is the contract price.
This contract price is also the total revenue that will be achieved by the Prime Contract Developer. The Prime Contract Developer will set aside profit margin and the rest of the 'price' budget will be allocated to the Prime Contract Project. This allocated budget is referred to as the total allocated budget (TAB). Ignoring for a moment some 'transitional costs', this TAB will consist of the Prime Contract Project Management Reserve and the Prime Contract Project Manager's performance management baseline (PMB) which will be allocated down through the WBS to work packages. These work packages may comprise sub-contracts.
When our project scope is documented within a contract, then a contract change is an agreement subsequent that changes the old contract into a new contract. Most importantly, this new contract must have the same elements as any contract—intention, offer and acceptance. The consideration will be taken to be for the entire contract though, so a change may not necessarily increase the cost of the contract. This means that contract changes need to be documented as thoroughly as the original contract.
For approval and documentation purposes, the contract changes are normally broken into:
* engineering change proposals (ECPs)—where a technical element of the system is being changed, but, importantly, without affect to the price, schedule or conditions of contract
* contract change proposals (CCPs)—where price, schedule or other non-technical elements are also affected
There are three other types of change that need to be looked at: waivers, deviations, claims. A waiver is when a Customer Project Manager says, 'Oh, don't worry about that', to part of the contract. Waivers are permanent. While a waiver is permanent, a deviation is temporary. The Customer Project Manager temporarily suspends part of the contract requirements. Claims are when one project manager says that another project manager has done something to increase the costs (or schedule) of the first project manager.
Project managers usually work out small claims between themselves, but larger claims can escalate. Most contracts have a claims process and dispute resolution procedure and disputes almost never get to court. The cost of taking commercial claims to court is high for both parties and also a major distraction when both parties should be concerned with making money.
Despite all the work of a project manager, things regularly go wrong. The first key to getting a project back onto path is to understand that something has gone wrong. The options open to the project manager are usually:
1) Ignore the problem. If the task is not on the critical path, is not affecting other tasks and is merely consuming a little bit more budget or schedule than in the plan—then this is a quite viable option. Not everything has to go to plan.
2) Motivate the manager or team to fix the problem.
3) Replace the manager.
4) Re-plan. If the team cannot fix the problem by working a bit harder, then something has gone wrong in the estimation. If the estimates are wrong for merely one task, then the plan simply needs to alter to accommodate the one delayed task.
Troubled projects occur for two major areas—those where the project is keeping to schedule and budget and those where it is not; Non-schedule budget problems and Schedule budget problems. In the former, if the problem cannot be solved by the application of time and money, your only choice is to
change the technical requirements and re-assess the business case. If the latter, follow these steps: Recognise the problem., Identify the source and extent of the problem., Create a new fully costed project plan., Emphasise the change to the team., Publicly assign the tasks to fix the problem., Make some realistic, near term 'inch-stone' targets., Closely, and publicly, monitor inch-stones., Communicate both successes and failures.