3

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. I'm mostly interested in contract software development projects.

And let's suppose that a customer comes to us, explains their needs in business terms and asks us to develop a software solution. We gather the subject matter experts, PMs, estimate the scope, take into account all possible risks, add our profit margin and finally get a price for this work. When we offer this price to the client, do we need to explain it (to provide the detailed list of work items the price is comprised of)? That would reveal our proft margin and our approach to risk management.

2
  • This is a contracting, marketing, or sales issue. Why do you think that choosing between line-item pricing or roll-up pricing is a project management concern? – Todd A. Jacobs May 31 at 15:53
  • In practice, PMs are often involved in contracting and sales, especially in small and average companies. – Daniel May 31 at 17:25
1

I'd say yes, you ought to be able to explain the price. You should be able to itemise your person-days estimates and for a T&M contract that's what matters. If you are asked for a FFP quote for any part of the work then my suggestion is that you quote both the T&M and the fixed price with its associated premium. It's not unusual to see FFP quoted at 40% or more on top of the standard day-rate and that in itself is a good lever to negotiate with. In any case you can't really avoid quoting a day-rate because FFP means that the customer has to pay for any excluded out-of-scope costs. None of this reveals your profit margin.

2
  • "any excluded out-of-scope costs" - do you mean CR (Change Request)? – Daniel May 31 at 15:18
  • @Daniel, anything that isn't part of the FFP scope, yes. – nvogel May 31 at 16:51
3

You don't have to explain your price if you can write a watertight contract

You don't have to explain your price to the client if you can write a watertight contract. A watertight contract is one where there is no possibility for dispute. That means writing a contract so it cannot possibly be misunderstood by anyone.

I'm mostly interested in contract software development projects.

Attempting to write a watertight scope of work for a software development project is like trying to put the genie in the bottle. This is because requirements become increasingly clearer as you make progress in the project.

If you strictly follow the terms of the contract, you may complete the project successfully ontime and within budget. But the software product will fail because you didn't adapt to the things that you learnt along the way.

However, you don't have to reveal your profit margin: You can quote an hourly rate for each skill type that includes your direct cost, your overhead costs, your risk cover and profit margin.

My recommendation would be that you quote a price per sprint for a specified team size. Give the client the option to end the contract at the end of any sprint, say, with a two sprint notice period.

3

Contracting with the US government, especially for CAS-compliant contract requirements, you have a requirement to exhibit your basis of estimates--labor cats, labor rates, cost build-up, justification, and fees--as part of your work proposal. Other than that, you have zero requirement to explain your price for any type of work you do. Except where required to submit for a proposal in the government space, it is not the business of your customers to know how you arrived at your price. What you pay your employees, how you wrap your indirect costs into their labor rates, how you determine what fee you want, how you determine how you build in contingency dollars are none of your customers' business.

The only caveat is if you do a T&M contract where the customer has skin in the game to control costs. In that case, they need to the how much a worker will cost them because they get to choose a cheaper worker if they want. But even in that case, they only need to know the price rate you charge. They don't need to know how you built up the dollars to get to the price rate...including the fee you built in.

Your customers' responsibility is to compete you against others. That's how they get to control their costs. If they don't like your price, they get to challenge you by showing you your competitors' bids, not by dissecting your price build-up.

1

If your offer consists of one deliverable, then there is no reason to explain the price breakdown.

If the deliverable consists of multiple parts, and the customer could - theoretically - decide to contract you for part of it and use another contractor for the other part(s) then you may want to be able to explain the cost breakdown.

Note that I said "want to be able to" - i.e. if you're asked. If they don't ask then you don't need to.

That said, if you break down the costs, it makes it easier to charge more, if a specific component needs to be changed.

Say you explain that 40% is for backend work, based on AWS RDS, and the customer decides AWS or RDS is not their cup of tea, or force-majeur prevents its use, then they understand that the 40% is going to change (upwards) as you research and define what they are prepared to use.

If you don't have a cost breakdown, then first you have to persuade them it's 40% of the cost and then you have to start wrangling over a new price - that's double the trouble.

Note that nowhere have you disclosed your profit margin.

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.