1

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?

1
  • I don't agree that a PM methodology must provide a guidance on how a contract should be negotiated, prepared, agreed, etc. A methodology doesn't provide guidance on how code should be written, or engineering work should be carried out, or concrete poured, and these are as fundamental to the operation of the project as the establishment of the contract. Sorry! – Iain9688 May 27 at 11:32
2

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.

7
  • How can a contract give planning, scope, delivery dates, etc to a PM? PM and the project team gives this information. – Daniel May 25 at 17:12
  • @Daniel If a contract specifies that you will deliver X by Y date, then that's where your project planning has to start. Q.E.D. – Todd A. Jacobs May 25 at 18:05
  • But where do these X and Y come from? They come from a PM and its team to the company's legal team. Not from the legal team to the PM and the project team. And this is why I'm actually asking how the legal team and the PM work together to negotiate and agree a contract with a customer. – Daniel May 25 at 18:21
  • 1
    If there is no contract, there is no project, and then there is no PM. During negotiations of that contract, the seller may consult experts--the same folks who may or may not become part of the project team and one of whom may become the PM--to inform the seller what X they can commit to in Y time. But the X and Y are determined by the customer and the seller supported by legal and other SMEs. – David Espina May 25 at 18:47
  • 1
    A project could include requirements development but it does not have to. I would not expect contract negotiations and preparation to be a knowledge area for the PMBoK. – David Espina May 26 at 17:42
0

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.

2
  • "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." Do you mean T&M? Anyway, many customers would not agree with you - they only want to buy a product, that's all. These customers are not ready to work by T&M model. – Daniel May 26 at 18:00
  • @Daniel My answer was about contract software development. Irrespective of whether the terms are T&M or not, software development involves the customer working with the technical team. The customer has to explain requirements and review proposals, perform acceptance testing, give feedback and help diagnose and resolve defects. This is vastly different to buying a product because it is a collaborative effort. If a customer doesn't understand that software development is different to buying a product then they are badly deceived and I would suggest the best course of action is to walk away. – nvogel May 27 at 10:56
0

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.

0

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.

3
  • I suppose that T&M is the only pricing model compatible with Scrum. Isn't it so? – Daniel May 26 at 17:53
  • @Daniel Depends how you define 'compatible'. Scrum/agile can still work for a non-T&M contract, but in that case, the only advantage is the 'fail fast' aspect telling you early whether or not you're going to fail the contract. – Sarov May 26 at 18:04
  • I have heard of contracts where the customer pays for a number of sprints, but not a fixed scope. They can then make as many scope changes as they want and provide lots of feedback. – Barnaby Golden May 26 at 18:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.