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


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


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


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


1

Of course, you post a question and then you immediately find the answer. I tried some new word combinations and found this that solved my problem: If you have costs by task and resource in your project, here's how to see them by month. Switch to the Task usage view (Utilisaton des Tâches") Right-Click on the timescale, select Timescale As Middle Tier, ...


1

There are two crucial parts for making the estimation that will be met in the future. First, the estimation should be correct (the amount of work to be done predicted without mistakes). Secondly, the scope will likely change. So new tasks should be evaluated in addition to the cost and time you've agreed before. You only asked for the first part, so here ...


1

I have noticed a trend during our projects that the consultants seem to always wait until the last possible moment... I noticed you used the plural "the". The fact there's more than one group or team that is consistently delivering late indicates that it's more likely to be the management of these resources (see: the common denominator) that may need to ...


1

I suggest we share the observation with the manager of the consultants, agree with him or her the expectation gap, brainstorm the probable motivation or ability root causes (for example, Start Late, if indeed that is agreed as a gap) and alternative solutions to bring about positive changes to close the gap and agreed on the next steps with ownership and ...


1

Fix the scope, then fix the price. Update constantly as you progress. Try the estimate the project in a range according to the rough spects you have. Because they are 'rough' - the cost and time estimate ranges can be relatively far apart. 10k - 20k or 3Q - 4Q of 2016. Use iterations for development. After each iteration you will gain more knowledge about ...


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