18

This depends a lot on how the two companies involved in the contract negotiation operate. You have to realize that there is always a cost of doing business, and somehow you have to recuperate it from the profits you are making. Think about your daily work, for example. You might work for 8 hours a day, but possibly you are productive and producing an actual ...


11

My company will sometimes engage into a "discovery" phase where we will spend 20-80 hours detailing the exact requirements of the project and determining the cost. We do this if we believe the requirements are not well documented enough or the project is so large that being off on the quote plus or minus 10% could mean 10,000+ dollars. The rate at ...


10

In Software Estimation: Demystifying the Black Art, Steve McConnell presents a table that is adapted and extended from Measures for Excellence: Reliable Software On Time, Within Budget, Industrial Strength Software, and Five Core Metrics: The Intelligence Behind Successful Software Management for line of code per staff-month for different kinds of software. ...


10

@DavidEspina has it right - I'd like to add a few thoughts This question illustrates one of the reasons tool recommendations are out of scope - CodeGnome's law says you need to decide how to solve the problem before you look for a tool. You haven't yet defined your problem, so no tool can help; tools are more likely to obfuscate the problem by providing ...


8

Pre-sales work is normally assumed to be at the vendor's expense, but usually I would expect the activities you describe (analysis and design) to be part of the work the customer pays for after the contract is signed rather than before. Detailed analysis and design requires extensive commitment and work from the customer as well as the vendor. The price you ...


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


5

Basically if anything does not go according to plan you are screwed. The problem is that you promised to deliver fixed features (scope) for a fixed budget (resources) before a fixed deadline (schedule). Scope, resources and schedule define what is called the iron triangle of software development. The idea is that if you change one side of the triangle, the ...


4

Scrum is an agile framework that is focused on adapting to change and delivering business value. It encourages feedback and looks to deliver what is needed, which is often not the same as what was originally planned. Combining Scrum with a fixed price, fixed scope contract is a challenge. It can often lead to arguments between the customer and the supplier ...


4

There is no tool or technique that will guarantee you will come in on time and within budget. Work is probabilistic. If you need more certainty, such as you don't have the funds to pay for overruns, then your only option is to bid a lot of fat. Bid in the 80th or 90th percentile of your estimate for both time and money. You won't win the work but, if you ...


3

I agree with everything David and Mark have said. Further, I'd just like to comment on: But, because I know what all the sprints are going to contain ahead of time, it's not really "agile". How can you possibly be sure that you know what it is ahead of time? Are you 100% certain that you have made absolutely zero mistakes gathering the requirements? ...


3

Lets assume that the consultants are working in good faith and their estimates are correct. Now delays must be caused by the usual things: external task needs to be completed by someone else. extra requirements added during project missing external resources, api, servers, accounts etc Enumerate and record the actual reasons for the delays. "what could we ...


3

As quick answer: "Roughly 1 screen, per team-member, pro day" of tested (debugged) code. So, about 24 lines in the 70/80's. And up to 50 lines nowadays. But it is very depending on how development is organized! E.g introducing lean/agile/scrum (correctly) may improve those numbers by 30%.


3

There are always two sides to a story. You should stick to the terms of the contact, which means honoring the fixed price assuming the scope was delivered, no matter if late (claiming any penalties if you had them in the contract). However, this also means to pay attention to the oft times ignored assumptions, exclusions, limitations, and any other ...


3

These costs are (usually) covered by the vendor. This is inherent risk, which can bankrupt small, specialized startup, especially if it enters the market under-capitalized. As a side note, this was for example a reason my university lab stopped working directly with clients seeking customized solutions. We only work with solution-providers who do this task ...


2

I don't think this is a disaster. We have done various projects on such conditions and it can work. Essential things are: Ensure that you are partners in the project (which is generally a good idea when it is a real project) and not competitors. Ensure you have explicitly defined what risks are moved over to the customer side as out-of-scope. Ensure you ...


2

That sounds like a disaster. I think that set up would be a set up for a bunch of finger pointing and blame down the line. If they want to have influence over the costs, do T&M or cost plus. In fact, that's pretty much what this is or will be except without the finger pointing and lawsuits.


2

Sounds like working in a more Agile-structured way would be beneficial. If you require being able to see incremental versions of the software every so often (say, every two weeks), then you will not only be able to provide early feedback, this will also force issues into the open much earlier, as well.


2

Agile methodology and fixed price projects doesn't go well together as by doing a fixed price delivery you will not be able to get the best benefits of doing a project in an agile manner. To quote an example, it is difficult to incorporate demo changes and business changes when you execute within fixed boundaries. Having said that, you can still do in ...


2

You need three values to forecast a cost: Speed of the team, estimate from the team and the cost of the team. Leading to a formula like this: FeatureStoryPoints * (TeamCost / AverageVelocity) = Estimated Price AverageVelocity: For speed you could take the average velocity (yesterday's weather) of a team. Do calculate capacity and normalize the velocity ...


2

Assuming you've done the work before on similar engagements, you and your team's experience should be able to arrive at a probabilistic estimate for the work ahead in a range from best to worst case. Since the work is fixed price, you would then select for your planning / target values--against which a price would be set--closer to the worst case side of ...


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

It does not matter the type of contract. All projects need to have a way to process changes because changes are a near certainty for every project in existence and will always be. The process does not have to be complex for smaller, less complex projects but there needs to be a way to understand the change, estimate cost and schedule impacts, estimate ...


2

This will not be a full answer to your question, but it contains one important piece of the puzzle if you ask me. Getting projects out of the door is very much about risk management. In my experience risk management is about two things: Finding the important risks Mitigating where possible Of course, if the project has too large scope, too little resources ...


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


2

As already answered, at some level this depends on what the sides agree upon, and there are no laws or rules governing this. Considerations that affect the decision of who pays, include: Will the quote be a simple number, or will it include the entire research you described? If you're delivering something useful, it's easier to ask to be paid. That said, ...


1

The answer to the first two questions can turn out to be simple or complex, but it is the same regardless of the size of project: negotiate. The evaluation as to whether something represents a change and then how much it costs often involves negotiation because not all eventualities can be be precisely defined in a contract. Even if it were possible to agree ...


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

As some other answers already pointed out no PM tool will guarantee success. Anyway, let’s take a look of your options. As you mentioned Scrum, it seems that your not only looking for PM tool more you are also looking for a (development) framework/process. First of all if your team doesn’t have already established a well working process then introducing a ...


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