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 ...


4

Normally, if you reprioritize or reschedule tasks to be started immediately, you need to interrupt and postpone current activities. This inevitably incurs overhead. Your client needs to understand that changing plans isn't free. In a fixed contract, you will have calculated some buffer for unforeseeable changes, but this buffer isn't there to be used up by &...


4

A FFP is not appropriate for your customer or you. If you pursue that you have to load it with a ton of contingency in both money and time that it would make it unfeasible for a normal customer. And it would ruin your reputation. A T&M is perfectly appropriate for this scenario. Insist on it or walk away.


3

Without detailed and fully agreed requirements, you have a load of assumptions. I suggest you document the assumptions as fully as possible, then structure a contract on a time and materials basis with the assumptions clearly stated. Then you can test the assumptions and document them as risks or issues as necessary. As an alternative to this you may prefer ...


3

The best software solutions are built when the software vendor and the customer that ordered that software collaborate to make it happen. "Customer collaboration over contract negotiation" says the Agile Manifesto. Of course, the two parties involved in building the software (vendor and customer) need some legal agreement in place. They need a contract. For ...


3

"Outcomes" Aren't Synonymous with Fully-Fixed Constraints In Scrum, the burn rate of each iteration is (relatively) fixed. The flexible sliders are scope and schedule. So, "outcome-based pricing" is certainly possible so long as you can adjust scope and schedule, but it isn't feasible if you're abusing the term to mean "fixed price for fixed scope." If the ...


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 ...


2

One of the factors to consider is whether the client is sufficiently experienced at this kind of engagement. It only makes sense to take this kind of thing on if both parties are prepared to negotiate scope later, otherwise one or both of you is likely to come away dissatisfied. The customer should understand that "fixed" price means they pay a premium for ...


2

Simplistically, what your customer is telling is you is not illogical. If you bring tasks forward to complete, causing an increase in cost burn secondary to an additional resource, it follows logically that you should be able to reduce a resource in the second half of the project, thus netting out a breaking even. If you have two employees across the PoP, ...


2

There are always questions that can't be answered at the start of a project. You begin with incomplete information and learn more as you go on. This is a well-known principle called the Cone of Uncertainty and it means that decisions taken at the start of a project have to be made based on information that may prove to be incomplete or inaccurate. This is ...


2

It's a matter of how the vendor and the client negotiate the contract. Most commonly though, payments are made as work proceeds (monthly, quarterly, more frequently or less, etc) or at specific intervals (like agreed upon milestones, etc). It's a fixed-price contract, so both parties know upfront what needs to be payed, but vendors usually prefer to have ...


1

A great option where cost risk is shared and where scope is largely defined is a cost plus fixed fee. In this case, both the seller and buyer are at risk for cost increases and therefore motivated to do what they can to keep costs from climbing, unlike a T&M where the seller is motivated to maximize charges. This type of contract also avoids loading up ...


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 ...


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,...


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 ...


1

Scrum should be focused on delivering outcomes, so yes, it is applicable. I think it would be very important to have a common understanding of what "Done" is so that you aren't charging for something the client can't use and they aren't constantly moving the goal posts. Past that, it should be a perfect fit.


Only top voted, non community-wiki answers of a minimum length are eligible