In this economic environment, there are a lot of companies competing for a little work. Someone is bound to give them a very sweet bid that will
Not be able to deliver on,
Kill their team with, or
Both.
When they can't deliver at the agreed price, they will start to cut down on the quality in order to deliver something and get paid.
Your challenge is to present that fact to your prospect in a professional manner, and convince them that you will work very hard to deliver at a reasonable cost, but also to deliver exactly what they need. The fact that you're going back for more detail, and the method you approach the project with (agile... but be sure and explain the business benefit to them) helps ensure that they will end up with what they really need.
Remember, they want to get the software delivered that they need at the lowest possible price.
Convince them that you will deliver exactly to their needs, and that your price is reasonable.
Welcome to the world of fixed priced development services :-)
Techniques for to win this project and avoid death march situation at the same time:
Don't underbid a project. Bid for what you think the project will take and add some percentage for things likely to go wrong.
If you are missing 75% of the detail, odds are the project will be significantly different than you currently expect. Document some reasonable detail assumptions within the outline of the defined work. When the project actually starts and the details don't match the assumption, you have an opportunity to negotiate the costs for the changes. At that time, you may also be in a better position to know how much you are over/under and attempt to compensate with this quote.
Your goal in an SOW (statement of work) should be to define enough details so that it gives you an opportunity to renegotiate the cost of changes when you know more about the project. Write these as positives, as much as possible. Note, it is unlikely that people that actually understand the project will read or understand the SOW...I base this on the point that you are given few details to quote. This means it isn't a consultative sale and neither party is really focused on building the 'right' solution.
If you can get a contract as T&M (time and materials) great. I doubt you'll get it or unable to get it without some restrictions that essentially defeat the purpose of a T&M. Your potential customers look at this as them accepting all of the risks around your abilities.
Hopefully, you aren't the first at your company to do this. Find out, historically, how projects have been and the typical result rates. Many software development groups charge an hourly rate that is significantly higher than cost...but their quotes tend to be lower and not actual hours. Customers often will argue more about the hours/days than the actual quote. Enterprises tend to be used to paying high hourly rates.
Figure out your department's expected margin (profit you need to gain from the job). This may help you to understand how much of a 'death march' you may face when your project slips.
In the SOW specify the level of detail that will be required in a specification before you begin work. While Agile and other customer focused processes take an approach that oriented at finding the best solution, they aren't designed to keep costs under control in a fixed bid environment. You will need to take a waterfall approach to requirements and then build in an agile fashion so that you can adjust along the way. The specification, like the SOW, will give you an opportunity to bill for changes. While the customer won't like this, it will put the burden and risks associated with requirements on them and not your team.
Note, to be successful with these negotiations, you needs a supportive management, sales and project management team. If you don't have that, you are bound to always be on 'death marches.' Even if you forgo quality, process, testing and other items, you'll find there's never enough time for a project.
Addressing the middle-men situation. I think the best course of action would be to submit a list of risks along with your bid as a courtesy to the customer. Kind of like giving them a heads-up on what their project limitations are. This will cost you some work up front but I think it could help you win the project.
you have two options
make a best-guess and double or triple your estimate (your competition is probably doing the same thing.)
explain to the customer that you can't bid work like this, and tell him that everyone else that gives him a fixed estimate is probably not being completely truthful.
At the end of the day, if you can't make money on the work, the there is not point in trying for it.
Personally, I prefer the latter, up-front and honest communication with your customers will take you farther than any bid tricks ever will.
Assumptions: There's no one disclaimer you can add but you need to fill the gaps in the requirements with sensible assumptions and document them. Nothing major or scary, just a section in your spec/bid with a list of bullet points saying what you assumed to be true which was missing (e.g. users details will be pulled using LDAP and no admin screens will be written to cover user admin).
This gives you clarity in estimating as you now have a full scope to work from, but it also means that if the client comes back with things which are wildly different you have a fair basis to start talking about raising change requests and varying the cost. Alternatively they may come back during the negotiations saying this assumption or that one isn't true and you have more information.
Out of Scope: A specific case of assumptions - list things which you aren't including (e.g. No integration will exist with system X). Again this allows you to have a full scope and a reasonable case for potentially varying cost at a later stage.
Assumptions and out of scope are particularly applicable when things are mentioned in passing but not really followed up, or for things which they say could wait for a second phase. These are often the things the client will believe are being done as part of the main project but the project team don't.
Hopefully the thoroughness and insight from the assumptions and scope you define will help inspire confidence with the ultimate client too.
Contingency: A tricky one but you should add contingency in two ways:
(1) for specific risks. For things which might mean something takes longer than you've estimated then put in an amount to cover that weighted by the chance of it happening. Add all these up and that's your risk contingency.
(2) Shit happens contingency - unpredictable shit happens on IT projects. Add between 10% and 20% to cover this.
Whether you hide contingency from your commercial people and the client or not depends on your relationship but if it gets removed they need to understand what that means (essentially you WILL over run).
Understand the relationship between effort and cost: As a technologist your role is to provide an estimate of the effort based on the information you have. You need to then communicate that with assumptions, level of contingency and so on to your commercial team who can convert it into a monetary value. The thing to be clear with them on is that if they want to drop the cost that doesn't change the effort.
There are loads of good reasons for writing down the cost to the client (to build a relationship, because you'll end up with stuff you can reuse later and so on) but people need to understand that unless the scope changes the effort stays the same - the reduction comes out of the profit.
one of the other posters here has a good point to. there will always be someone who will offer a lower price to get the work. and the developer will suffer for it later (i.e. having to do a lot of free work to satisfy the client).
some clients need to have this experience before it clicks that you cant do IT projects on the cheap without paying some kind of price.
Go for realism. Avoid promising too much, then make a point of it.
A lot of customers out there have been burnt by unrealistic offerers who fail to deliver as promised.
Emphasize the need for a specifications sprint. Convey a focus on core functionality and commitment to deliver rather than a feature bonanza. Offer a primary development phase to deliver core functionality.
Communicate the power and safety of the agile approach. Credit the customer with the ability to see good sense.
In short: Strive to come across as realistic and serious (more so than your competitors). The most important thing for any serious customer in the end is not the price, but a confidence that the product will be delivered on time and budget.
发布评论
评论（6）
在这种经济环境下，有很多公司在争夺一点工作。有人肯定会给他们一个非常甜蜜的出价，但无法
当他们无法按约定的价格交货时，他们就会开始降低质量，以便交付产品并获得报酬。
您面临的挑战是以专业的方式向您的潜在客户展示这一事实，并让他们相信您将非常努力地以合理的成本交付产品，同时也准确地交付他们所需要的东西。事实上，您要返回更多细节，以及您处理项目的方法（敏捷......但一定要向他们解释商业利益）有助于确保他们最终得到他们真正需要的东西。
请记住，他们希望以尽可能低的价格获得他们需要的软件。
让他们相信您将完全满足他们的需求，并且您的价格合理。
In this economic environment, there are a lot of companies competing for a little work. Someone is bound to give them a very sweet bid that will
When they can't deliver at the agreed price, they will start to cut down on the quality in order to deliver something and get paid.
Your challenge is to present that fact to your prospect in a professional manner, and convince them that you will work very hard to deliver at a reasonable cost, but also to deliver exactly what they need. The fact that you're going back for more detail, and the method you approach the project with (agile... but be sure and explain the business benefit to them) helps ensure that they will end up with what they really need.
Remember, they want to get the software delivered that they need at the lowest possible price.
Convince them that you will deliver exactly to their needs, and that your price is reasonable.
欢迎来到固定价格开发服务的世界:-)
赢得该项目并同时避免死亡行军情况的技巧：
请注意，要成功完成这些谈判，您需要一个支持性的管理、销售和项目管理团队。如果你没有这个，你注定会永远处于“死亡行军”之中。即使您放弃质量、流程、测试和其他项目，您也会发现项目的时间永远不够。
Welcome to the world of fixed priced development services :-)
Techniques for to win this project and avoid death march situation at the same time:
Note, to be successful with these negotiations, you needs a supportive management, sales and project management team. If you don't have that, you are bound to always be on 'death marches.' Even if you forgo quality, process, testing and other items, you'll find there's never enough time for a project.
编辑：
解决中间人的情况。我认为最好的做法是随出价一起提交一份风险列表，以示对客户的尊重。有点像让他们了解他们的项目限制是什么。这将花费你一些前期工作，但我认为它可以帮助你赢得这个项目。
您有两个选择
：做出最佳猜测，以及将您的估算提高一倍或三倍（您的竞争对手可能也在做同样的事情。）
向客户解释您无法出价像这样工作，并告诉他其他人给他一个固定的估计可能并不完全真实。
归根结底，如果你不能通过工作赚钱，那么尝试就没有意义。
就我个人而言，我更喜欢后者，与客户进行预先和诚实的沟通将比任何出价技巧让您走得更远。
EDIT:
Addressing the middle-men situation. I think the best course of action would be to submit a list of risks along with your bid as a courtesy to the customer. Kind of like giving them a heads-up on what their project limitations are. This will cost you some work up front but I think it could help you win the project.
you have two options
make a best-guess and double or triple your estimate (your competition is probably doing the same thing.)
explain to the customer that you can't bid work like this, and tell him that everyone else that gives him a fixed estimate is probably not being completely truthful.
At the end of the day, if you can't make money on the work, the there is not point in trying for it.
Personally, I prefer the latter, up-front and honest communication with your customers will take you farther than any bid tricks ever will.
我想说您应该考虑以下几件事：
假设：您无法添加任何免责声明，但您需要使用合理的假设来填补需求中的空白并记录它们。没什么大的或可怕的，只是你的规范/出价中的一个部分，其中有一个要点列表，说明你认为是真实的但缺少的内容（例如，将使用 LDAP 提取用户详细信息，并且不会编写管理屏幕来覆盖用户管理员） 。
这使您可以清楚地进行估计，因为您现在有了完整的工作范围，但这也意味着，如果客户回来时带来的东西截然不同，您就有了一个公平的基础来开始讨论提出变更请求和改变成本。或者，他们可能会在谈判期间回来说这个假设或这个假设不正确，而你有更多信息。
超出范围：假设的具体情况 - 列出您未包括的内容（例如，系统 X 不会存在集成）。同样，这可以让您对后期可能发生的不同成本有一个完整的范围和合理的案例。
当事情被顺便提到但没有真正跟进，或者他们说可以等待第二阶段的事情时，假设和超出范围特别适用。这些通常是客户认为是作为主项目的一部分完成的事情，但项目团队却不这么认为。
希望您定义的假设和范围的彻底性和洞察力也将有助于激发最终客户的信心。
意外事件：这是一个棘手的问题，但您应该通过两种方式添加意外事件：
(1) 针对特定风险。对于可能意味着某件事需要比您估计的时间更长的事情，然后投入一定的金额来覆盖根据它发生的可能性进行加权的金额。将所有这些加起来，这就是您的意外风险。
(2) 糟糕的事情发生是偶然的——IT 项目上会发生不可预测的糟糕事情。添加 10% 到 20% 来覆盖这一点。
您是否向商业人员和客户隐瞒意外事件取决于你们的关系，但如果它被删除，他们需要了解这意味着什么（本质上你会超额运行）。
了解工作量和成本之间的关系：作为技术专家，您的角色是根据您所掌握的信息提供工作量的估计。然后，您需要将这些假设、意外事件的级别等传达给您的商业团队，他们可以将其转换为货币价值。需要向他们明确的一点是，如果他们想降低成本，就不会改变他们所做的努力。
有很多充分的理由向客户写下成本（建立关系，因为你最终会得到以后可以重复使用的东西等等），但人们需要明白，除非范围发生变化，否则工作量将保持不变。同样 - 减少来自利润。
A few things I'd say you should think about:
Assumptions: There's no one disclaimer you can add but you need to fill the gaps in the requirements with sensible assumptions and document them. Nothing major or scary, just a section in your spec/bid with a list of bullet points saying what you assumed to be true which was missing (e.g. users details will be pulled using LDAP and no admin screens will be written to cover user admin).
This gives you clarity in estimating as you now have a full scope to work from, but it also means that if the client comes back with things which are wildly different you have a fair basis to start talking about raising change requests and varying the cost. Alternatively they may come back during the negotiations saying this assumption or that one isn't true and you have more information.
Out of Scope: A specific case of assumptions - list things which you aren't including (e.g. No integration will exist with system X). Again this allows you to have a full scope and a reasonable case for potentially varying cost at a later stage.
Assumptions and out of scope are particularly applicable when things are mentioned in passing but not really followed up, or for things which they say could wait for a second phase. These are often the things the client will believe are being done as part of the main project but the project team don't.
Hopefully the thoroughness and insight from the assumptions and scope you define will help inspire confidence with the ultimate client too.
Contingency: A tricky one but you should add contingency in two ways:
(1) for specific risks. For things which might mean something takes longer than you've estimated then put in an amount to cover that weighted by the chance of it happening. Add all these up and that's your risk contingency.
(2) Shit happens contingency - unpredictable shit happens on IT projects. Add between 10% and 20% to cover this.
Whether you hide contingency from your commercial people and the client or not depends on your relationship but if it gets removed they need to understand what that means (essentially you WILL over run).
Understand the relationship between effort and cost: As a technologist your role is to provide an estimate of the effort based on the information you have. You need to then communicate that with assumptions, level of contingency and so on to your commercial team who can convert it into a monetary value. The thing to be clear with them on is that if they want to drop the cost that doesn't change the effort.
There are loads of good reasons for writing down the cost to the client (to build a relationship, because you'll end up with stuff you can reuse later and so on) but people need to understand that unless the scope changes the effort stays the same - the reduction comes out of the profit.
我有一篇博客文章，其中可能有一些提示给您：
http://pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html
这里的其他海报之一有一个很好的观点。总会有人提供更低的价格来获得这份工作。开发人员以后会因此而受苦（即必须做大量免费工作才能满足客户的要求）。
一些客户需要有这样的经验，然后才会明白，如果不付出某种代价，就无法以便宜的价格完成 IT 项目。
LM
i have a blog article which may have a few tips in it for you:
http://pm4web.blogspot.com/2009/06/surviving-under-resourced-project.html
one of the other posters here has a good point to. there will always be someone who will offer a lower price to get the work. and the developer will suffer for it later (i.e. having to do a lot of free work to satisfy the client).
some clients need to have this experience before it clicks that you cant do IT projects on the cheap without paying some kind of price.
LM
追求现实主义。避免做出太多承诺，然后明确它的意义。
很多客户都被不切实际的报价者所困扰，他们未能按承诺交付产品。
强调规范冲刺的必要性。传达对核心功能的关注和对交付的承诺，而不是功能丰富。提供主要开发阶段以提供核心功能。
传达敏捷方法的力量和安全性。相信客户有能力看到良好的判断力。
简而言之：努力给人留下现实和严肃的印象（比你的竞争对手更是如此）。对于任何认真的客户来说，最终最重要的不是价格，而是对产品将在预算内按时交付的信心。
Go for realism. Avoid promising too much, then make a point of it.
A lot of customers out there have been burnt by unrealistic offerers who fail to deliver as promised.
Emphasize the need for a specifications sprint. Convey a focus on core functionality and commitment to deliver rather than a feature bonanza. Offer a primary development phase to deliver core functionality.
Communicate the power and safety of the agile approach. Credit the customer with the ability to see good sense.
In short: Strive to come across as realistic and serious (more so than your competitors). The most important thing for any serious customer in the end is not the price, but a confidence that the product will be delivered on time and budget.