立项会开得热闹，真到动手的时候才发现，钱最多出多少没人说，什么时候必须用上只有一句尽快，第一版要做哪些功能写了两页还没边界。这三个数字不清楚，后面每一步都在还债。
我们做项目复盘时发现，返工和延期很少是技术问题，多数能追到立项阶段这三件事没定死。下面按先后顺序说怎么定，以及定不下来的时候怎么办。
一、钱最多花到多少
注意问的不是大概花多少，是上限在哪。这两个问题看着像，实际差很远。前者得到的回答往往是二十万左右，后者得到的是最多不超过二十万，超了就得停下来重新议。
定了上限，后面很多事才有判断依据。功能要不要做，看它值不值这个钱。技术方案选贵的还是稳妥的，看预算还剩多少。要不要分期上，也看这一版的钱够不够覆盖全部。
拆的时候建议分三块记。软件本身的钱，这是大头。硬件和网络的钱，服务器、专线、扫码枪、打印机这些容易被漏掉。上线之后的钱，服务器续费、日常维护、小改动，这块漏得最厉害。按经验，第一年的维护费用通常相当于软件款的百分之十五到二十，招标时如果不写进去，第二年多半要重新走一遍流程。
二、什么时候必须用上
上线日期要有个具体理由。比如配合某项年度检查，赶上某个业务旺季之前，或者现有系统的服务商年底就不续了。有理由的日期才是硬日期，团队才会真的排优先级。
日期定了之后要做一件事，倒着排。从必须用上的那天往前推，先留出培训的时间，再留出试运行的时间，再留出测试和修复的时间，剩下的才是开发时间。很多项目排期排得紧，就是只算了开发，剩下的全当不存在。
没有硬日期的项目基本都会拖。人的惰性加上业务部门随时提意见，需求会一直长大，工期会一直往后顺。所以哪怕理由是内部的，也要指定一个日子，写进立项文件。
三、第一版必须有哪几件事
第一版只列没有它系统就转不起来的功能，其余一律往后放。这句话说起来简单，做起来最难，因为每个部门都觉得自己的需求不能等。
有个办法比较管用。让实际要用的每个人，各自写下如果只能保留三件事会留哪三件，然后把这些清单摊在一起。重合度高的，就是真正的必需项。那些只有一个人提、别人没感觉的，多半可以放到第二期。
为什么强调这个。因为功能数量和上线日期是直接冲突的。一个中等复杂度的管理系统，功能清单从三十项涨到五十项，工期通常要多出两个月，测试的范围也跟着翻倍。把想要的都塞进第一版，等于自己把日期往后推。
四、三个数字对不上怎么办
现实里三个数字很少一开始就和谐，常见的是钱不够、时间不够、功能太多，三样凑齐。
这时候要分清哪个是硬的。一般来说日期最硬，因为它往往挂在外部节点上。功能最软，因为大部分功能晚两个月用并不影响业务。预算居中，有时候能争取，有时候一分都加不了。
确定硬约束之后，选择就清楚了。日期和预算都动不了，就只能砍功能，砍到预算和时间能覆盖为止，并且把砍掉的部分写成下一期的计划，让对方知道不是不做，是排在后面。如果功能也不能砍，那就只能加钱或者延后日期，这时候要及时把选择摆到决策层面前，别让项目组自己扛。
最怕的情况是三个数字都模糊，靠项目组在过程中一次次妥协。项目组没有权限砍功能，也不敢报延期，最后就是硬扛，扛到某个环节崩掉。