Contract Styles

sheldonlinker

9 Contract Styles

Whether the money for a project comes from internal sources or a customer or venture capital, it has to come from somewhere, and on a given schedule. The quantity of money and its scheduling can have an impact on the project’s requirements. For instance, one main concern: Given the amount of money available, what can we do? That at least calls for prioritization, and may (and usually should) call for a limitation on the requirements.

Disclaimer: We’re not lawyers. Nothing in this (or any other) section is legal advice. Rather, this is all academic teaching and business advice. For actual legal advice, consult your company’s lawyer.

9.1. Internal Funding

Internal funding is the most common type of funding on a project. It simply means that the company is paying for its own project. Although funding from venture capitalists is actually external funding, it is usually treated like internal funding, except that the outsiders can pull the rug out from under you at almost any point. Within internal funding, there are several ways that money gets scheduled, listed below.

9.1.1. Budgeting in Total Dollars, or “Man-months”

Sometimes, internal funding is in terms of dollars, or in man-months. A man-month is defined as the amount of work one person will do in a work-month, allowing for vacations, holidays, sick days, and about 25% distracted time. When budgeting is in dollars, it may include hardware costs, and even overhead costs, such as the building and utilities. When budgeting is in man-months, it’s just head-count over time. Here is one place that project management type and money interact. If there is a limited budget, then the project management team, usually including one or more business analysts/spec writers, needs to decide on the management style based on requirement stability and money available. If the requirements are very stable and money is tight, then a Waterfall model (executed carefully) will often lead to the lowest expenditure, because only one team is on the project at a time. However, if the requirements are fluid, then the Waterfall model will be disastrous. Likely the requirements are somewhere in between, and a call of best likelihood will have to be made.

Note that the number of man-months required for any given amount of work will vary with the number of people working on the project. One person working for 100 months can do a certain amount of work. But 100 people working for 1 month will need a considerable amount of interfacing and coordination time, and management. As Frederick Brooks points out in The Mythical Man-Month, “Nine women can’t make a baby in a month.”.

9.1.2. Budgeting in Dollars per Month, Staffing Levels, or “Burn Rate”

Many, if not most, internally funded projects, seem to have a given staffing level, or dollars per month. The latter is often known as the “burn rate”. This type of funding may or may not have a dollar limit or a time limit. If there is a dollar limit or a time limit, then the requirements must be prioritized and limited. If there is no overall funding limit, and no overall time limit, then the requirements must be prioritized. Even if there is no limit, you’re still going to need to evaluate whether each requirement (a) needs to be done regardless of cost, (b) is worth doing, meaning that the return on investment is > 1, or (c) not worth doing, meaning that the ROI ≤ 1.

9.2. External Funding

When you’re producing a product for a specific outside customer, there are two main types of contracts, as described below.

9.2.1. Time and Expenses

In a time-and-expenses contract, the customer pays the producer for the manpower time used, normally at an hourly rate per person. This may be one set rate per worker, or a set rate per working in each individual class of workers, or on a rate set on a person-by- person basis. That’s the time component. The expenses component is that the customer pays for expenses, such as travel, equipment, and whatever else needs to be provided.

The relationship between this type of funding and the project management style and the requirements volatility is this: If the requirements are volatile, then you need to have a time-and-expenses contract, or the customer will do whatever they want to the requirements, and you’re left holding the bag, meaning that you’ll likely take a loss. If the requirements are stable, then you have the option of using time-and-expenses or fixed price. But, there is a limit to the volatility of the requirements in relation to customer happiness. If you allow the requirements to vary too quickly, then the bill on the customer will be run up, and the customer will not be happy. You’ll have a huge profit on this one contract, and no future business from that customer nor potential customers that the unhappy customer talks to. If you hold requirements to what is truly called for, this one contract will be a bit smaller, and there will likely be follow-ons and word-of-mouth referrals.

9.2.2. Fixed Price Contracts

A fixed-price contract is one in which the parties agree that the value of the contract is a certain fixed amount of money, no matter how much the job really costs. In this type of contract, the requirements should be finished before the contract starts. So, if the customer is paying for requirements engineering, then that requirements engineering will be (a) done by the customer, (b) paid for by the customer in a time-and-expenses manner, or (c) just done for free by the producer for the customer, in hopes of recouping the expense in the fixed-price contract.

If you enter into a fixed-price contract, then the requirements are locked in, and you might as well use a Waterfall model, since in this circumstance, it’s likely to be the cheapest to execute. Of course, you can always use an Agile model, even though the requirements should be known at the onset.

Even in a fixed-price Waterfall project, prioritization of requirements is important. First, if a given requirement is slated for an earlier release than some other requirement, then the earlier-scheduled item must have a higher priority. But often, the contract doesn’t say what’s in each release, only what’s in the final delivery. But just as often (at least), is that various components of the system each carry a part of the price. For instance, Component A has a delivery value of $5,000 and Component B has a delivery value of $10,000. If Component A will cost 100 work units (whatever those are in your organization), and Component B will cost 160 work units, then the delivery price per work unit of Component A is $50 per work unit, and the delivery price per work unit of Component B is $62.50, and so, the requirements for Component B should be prioritized higher than those of Component A (assuming that Component A does not rely on Component B), because that brings in more money faster.

9.3. Hybrid Funding

Of course, not all projects fix into the tidy boxes presented above. Sometimes a project has an external purpose, but the project is funded internally in hopes of selling the prject later. Sometimes there are cooperative ventures between two companies on a big project. In those cooperative ventures, some parts of the project will be paid for by each company as internal projects, but other parts of the project will be on a time-and-expense or fixed price basis between the two companies.

9.4. Offer, Acceptance, Performance, and Payment

Generally, the four steps in a contract are Offer, Acceptance, Performance, and Payment. One party offers the other party a deal, and that second party accepts. One or both parties perform some obligation and/or work under that contract, and then (or during), there’s payment. If a controversy arises, any three of those things is enough to prove or force the other:

The trivial case: If there was acceptance, performance, and payment, then there must have been an offer.
If there was an offer, and there was performance and payment, then the offer will be deemed to have been accepted.
If there was offer and acceptance, and payment, then performance or a refund can be compelled.
If there was offer, acceptance, and performance, then payment can be compelled.

In many jurisdictions, the contract still exists, even if it’s not on paper.

9.5. How Things Can Go Wrong

Contracts are often the driving factor, so we can’t say that there can be something wrong with the contract style, but having a disconnect between the contract style and the development methodology can be a big problem. Make sure that these two factors are compatible.