1

Let's suppose a customer wants to create a software product and there is a software development company that is able to develop this product. They need to create a contract.

But both sides has their own concerns:

  • a customer often wants a fixed-price contract (to be sure that he doesn't pay extra money)
  • a development company wants to be sure it will get paid and won't get penalties (so it usually prefers T&M)

We all know that developing software is a very complex proceess that has lots of potential impediments, technical problems that can't be foreseen. So it is very difficult to complete a project on time and on budget.

How does the software development company draw up a contract that protects the company's interests (doesn't cause losses)? Whose responsibility it is? Does the software development company need to always involve a lawer in contract negotiation?

1
  • 1
    Involve a lawyer? Big yes to that :)
    – nvogel
    Commented Sep 17, 2020 at 16:33

5 Answers 5

5

Customers prefer a FFP at times because of they believe it helps to control costs. In some ways it does; however, in many cases they end up paying more, either because of the contingency built in the price and / or the vendor submitting one change request after another. And the change requests typically have a lot of built-in margin since the CRs are not under competition.

There is nothing wrong with a FFP contract as long as the scope is well defined, a change process is understood, the customer understand they are paying a premium on it, and the vendor builds in an appropriate degree of contingency for risks.

So the key in a FFP is risk management. You do not price the work in the same way as you would with T&M or CPFF. With FFP, you HAVE to build in money to cover both known and unknown risks. For example, you may quote under T&M a $30k contract for a piece of work. For the same work, you might quote a FFP at $45K or maybe even as high as $50K. That $15K to $20K is all contingency to cover unknowns. And that's how you protect your firm. If and when things go wrong, you begin to eat up that contingency instead of paying for it with your profit margin. And of course you manage your scope well and submit change requests for out of scope work as soon as it is detected.

No, you don't need a lawyer for negotiations. Lawyers are typically in the background for the T&Cs; however, they are not typically involved negotiating with the client at the table unless something very unique is going on...at least in my experience.

2

There's a difference between being a software vendor and being a service provider for bespoke applications development. You seem to be describing a service-provider kind of relationship.

A fixed-price (FFP) contract does not mean the customer only pays a fixed price. It means the customer and supplier agree to negotiate on price and scope and that the customer will either compromise or pay extra for things deemed to be out of scope. FFP contracts normally cost more than equivalent T&M and can be unfavourable for both parties unless there is a high degree of trust and understanding - typically when there is a longer-term strategic relationship involved.

T&M tends to increase transparency and co-operation, maintain quality and agility and also avoids the client being locked-in to an expensive and risky relationship. Many customers understand that. As a service provider you can also emphasise that the T&M quote is significantly cheaper than the FFP one.

1

As you mentioned yourself, the problem with software development is that there are a lot of unknowns. These introduce variability in what will be built (which people assume will be fixed). What's worse, is that in the beginning, both parties have trouble knowing what is needed and what will change after the project is started (and things will definitely change as both parties get a better understanding of what's needed).

The problem with writing contracts is that they usually try to fix all aspects of the agreement about what to build, how much to pay for it, and when it will be ready. So because of the unknowns inherent to software development, the contracts end up not as writing down the rules of collaboration to reach the same goal or target, but as an attempt for each party to get the best deal out of it: the client to pay cheap, the provider not to pay penalties. It's basically a matter of writing the contract so that the other side takes on the risks. And you can get this with fixed-price and time and materials also.

As to whose responsibility it is to define the contract, it is a joined effort between business people, sales persons, executives, project managers, and legal staff. A contract defines things related to resources, personnel, roles and responsibilities, payments, warranties, insurance, limitations of liabilities, obligations of both parties, data security, data protection, change management, dispute resolutions, delivery plans, acceptance criteria, various other linked documents like requirements, specifications, etc. You can search online for some templates just to get an idea of what's involved.

So when drafting the contract, yes, it's best to involve some lawyers familiar with the IT field, or someone with legal experience that has done this before, to lay down the agreement in writing. Otherwise, if you are new to this, you are exposing yourself to a bunch of risks.

1

I strongly advise you to engage an attorney who is skilled at creating this sort of contract. (And, in general, in leading clients through this sort of business negotiation. (The old-fashioned word for an attorney was, after all, "counselor.")

An attorney is "an expert in the law." You are not.

I stumbled-upon my personal attorney, Tom, a number of years ago when our family needed to probate a will. Since that time, I've reached the point where I reflexively say, "Let me ask Tom about that." I call him up, he starts the time-clock, and I am more than happy to pay his bill – which is quite fair. Because: "Tom knows."

Legal expenses are a fully tax-deductible business expense.

1

Everybody (obviously) answered yes to getting a lawyer involved.

But nobody answered your first question:

How does the software development company draw up a contract that protects the company's interests (doesn't cause losses)?

However, besides for the legalese, the contract is going to need an addendum; specifically, a detailed Technical Spec.

This will spell out exactly what will be delivered at each milestone.

This Technical Spec needs to be approved by the customer, after which each change will cost them more money. This, naturally, is hidden in the legal part of the contract.

This is how the software company protects its interests, as you asked.

And that's why this question belongs here on Project Management: Since it's the PjM's responsibility to ensure the Technical Spec is comprehensive.

4
  • As you are probably aware a lot of people take the view that a detailed, milestone-bound spec in a contract can significantly increase rather than decrease the commercial risks for both customer and vendor. The idea of excluded costs being hidden rather than openly discussed also does not seem like a recipe for a harmonious and lasting relationship with the customer! Intentional humour?
    – nvogel
    Commented Sep 22, 2020 at 1:16
  • @nvogel, I'm not aware that "a detailed, milestone-bound spec in a contract can significantly increase rather than decrease the commercial risks for both customer and vendor." - and I'm curious why that is. I'm not sure that's a PjM-related question... maybe I can ask this question here... Commented Sep 22, 2020 at 13:44
  • @nvogel, who discussed hiding costs? It's "hiding in plain sight" if that's what you mean. How are you going to manage "Change Control" without an agreed upon spec? Commented Sep 22, 2020 at 13:45
  • Hi @Danny I actually tried to answer your question here. Perhaps I read too much into your words that "each change will cost them more money. This, naturally, is hidden..." When faced with a very prescriptive contract I would make the additional costs a big talking point - this being one way to persuade a customer that a more flexible approach is potentially better for them and for the vendor.
    – nvogel
    Commented Sep 22, 2020 at 14:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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