The relation between a project and a contract

Question

Let's suppose we're talking about companies that perform some work for customers. This work is usually considered to be a project and is done on a contract basis.

It's natural to assume that any project management methodology must provide a guidance on how a contract should be negotiated, prepared, agreed, etc. But it seems that neither PMBoK nor Scrum touch these questions.

What is the relation between project management and fulfillment of a contractual obligations? Can these two knowledge areas be decoupled at all?

Answer 1

There is no direct relationship. Contracting is a legal concern, not a project management one. From a PM perspective, the contract may inform planning and controls related to scope, change management, delivery dates, budget, and so forth, but the contracting process is generally the responsibility of a company's legal team or outside counsel, and authorized by executive leadership.

Answer 2

If you were building a house or a bridge then you would expect to pay for architecture and engineering work even before the finished construction could be specified and costed in detail. You might well start with a budget but you would have to sign contracts with at least some of your contractors and spend a significant amount without knowing the eventual price to any degree of certainty.

Building software is not like building a house or a bridge but one thing software does have in common with complex construction projects is that you cannot expect to agree a realistic price on day one. You can guess, you can take a risk, you can decide how much the work is worth to you, but that is about all.

When you contract for software development work you are not buying a product, you are buying the time and expertise of people who you want to collaborate with to solve a difficult problem. You can control risks and costs by requiring early and frequent delivery of software and source code. That way if things seem to be going sour you can walk away with minimum lost and at least some benefit retained (unlike construction where an abandoned project probably becomes a total write-off).

On the other hand, attempting to fix software development costs and scope early on can only reduce flexibility and will inevitably put limits on a contractor's ability to solve problems in the most creative and collaborative way. Fixing cost, time and the detailed scope of software development is very often counter-productive, expensive and some people argue it is also unprofessional and unethical.

PMBoK and Scrum try to be relevant to all kinds of industry and types of work - contracted or not. You shouldn't expect them to tell you how to negotiate a contract or run your business.

Answer 3

You might consider any goal-oriented business activity (in contrast to ongoing activities such as accounting or house-cleaning) as a project. Preparing a contract, scheduling meetings, getting estimates from engineering etc. can be planned and performed using project management techniques, even though such a project would normally be much smaller and less complex than the actual execution of a customer contract. The goal (winning the contract) is internal, so the stakeholder and the sponsor for this kind of project is your own company, not the customer. The expenses for this project must be covered by income from customer projects, just like expenses for non-project activities.

If the actual customer project is huge, the contract-forming project might involve the customer as an explicit participant, stakeholder and sponsor, so the cost is at least shared between you and them. Compare this to car repair cost estimate: In simple cases, the repair shop will just tell you what the repairs will cost, but in more complex cases, they may bill you for creating an estimate.

Answer 4

Adding to the answers you have already.

There are contracts that are specifically designed for agile frameworks like Scrum.

I have also seen the approach of using time & materials costs rather than a fixed-price contract.