当是否决定做一个项目时，总是要评价该项目是否能带来利润。
这就需要估算成本和收益。由于IT是人密集型产业，在估算成本时，人力成本是占主要成本之一。而在公司里面，人员的工资一般是固定的。因此，就需要估算项目的开发时间。
IT行业不同其他行业，其他行业，比如建筑，房地产等，开发完毕一个项目时，可能会再开发一个相同的项目。项目经理可以根据以前的经验，精确的估算下一个项目的时间。但IT项目每个项目都是最新的，因为不可能说开发同一个项目多次，也没有必要。加上IT又是一个新兴的行业，只有很少的历史数据可以参考。这就更加加强了估算的难度。
从以往经验来看，估算的精度一般是实际的20%-100%左右。能达到10%以内已经算是很好了。5%以内？呵呵，没听说过。
根据什么来估算呢？只能根据项目经理以往的经验和自己掌握的各方面技能估算。时间不能估得太短，也不能估得太长。如果估得太短，在开发过程中会面临各种各样的风险，比如人员的离职和抽调，需求的变更，其他项目的介入等等，到最后完不成任务，影响小组的士气，对以后肯定影响不好。估得太长，你的上司就不会同意，还会认为你的人怎么怎么样，会给他们留下不好的印象。何况根据帕金森法则：一个项目给它多少时间，他就会在这段时间内将它耗完。你的小组人员本来2天能做完的时间，听说有5天时间，于是乎，会将2天的工作量分散到5天里。不知不觉地就把时间耗完。同样的项目，给不同的开发团队，实际的进度也不同。开发人员的心情会影响进度，心情好的时候，开发速度快，心情不好的时候，开发速度就很慢。水平高的和水平低的开发人员，差异也很大。（据《人员神话》记载，好像相差10倍，等我确认后再写上去）。
然而大部分项目经理在执行项目时，时间进度却不是由自己和开发小组决定的，而是由老板或者市场部决定的。他们似乎也不怎么和你讲道理的。如果他们将时间压得太紧，而你知道，在这段时间内根本就不能完不成任务。怎么办呢？如果你只是将这个消息传递给开发小组人员，那整个项目注定是失败的。因为开发小组如果一致认为，是完不成的任务。那肯定就会有很大的压力，有能力者就会有跳槽的打算。反正完不成，很多人就没有心情再做下去了。于是，你必须针对不同的情况，了解为什么给自己这么紧的原因。后来你了解到，有些项目是客户为了应付上级的演示，这时候，你可以根据实际情况，对功能进行裁减，哪些功能是必需的，哪些功能是可要可不要的。确定功能的优先缓急，将最主要的功能部分做好。
值得注意的是，随着开发过程的继续，估算的精度会越来越趋近于实际值。等到详细开发文档出来，就和实际值相差无几了。这就是软件估算的渐进性。
项目估算是在进行执行项目前必须的工作。估算的结果，直接影响到该项目是否应该实施。建议最好在估算时，最好将部分有难度的功能提炼出来，给开发小组人员进行估算。另外，一个团队在一起进行估算，到以后实施时候就有很大的时间上的保证。三峡工程在进行估算（可行性分析）的时候花了几年时间，可见估算有时候也是一项很重要的工程了。
以上都是理论知识，下面说说我们单位的情况吧，我在我们单位的角色，既是某项目的负责人，又是其他项目的参与者。最多的时候，1个星期内负责/参与3-4个项目。同时工作10几个模块。让我很郁闷的是，竟然没有开发计划，老板会一天到晚在你身边转悠，问你进行到什么情况了，如果看到你没有完成，就更加有理由监督你了，如果看到你完成，就更急了，先是自己想，看看有没有事情给你做，想不到，就让部门经理分配事情给你做！无休无止的加班。 如果是老板早上来，就是9点初，因为我们9点上班。如果是中午，就是12：30过后一点点，因为我们12：30就会上下午班。下午，5点多过来，我们5：30下班。然后赖着一直不走。。。监督机制不错，但是殊不知，他无法确认我们在做什么。虽然公司装了监控系统，上网的行为都会被监控，但是，相互都不知道在做什么。我是不管，过了下班时间1小时左右，我是呆不住的。就算那时候走，也是差不多我们部门第一个走。(今年续签协议后，感觉很郁闷，压力也很大，发发牢骚罢了。)
记得福特公司老板去他车间里转悠时，看到一个人在那里吊儿郎当，非常看不惯，于是他把他主管找来，说，把那个翘着二郎腿，什么事都不做的那个人开掉。主管一听急了，说，我们公司所有的汽车可都是他设计的！结果可想而知，光从表面看，你无法知道脑力劳动者在做什么。区别于机器，一天能生产1000个零件，2天就能生产2000个。
在我们公司项目前期很少估算，因为谁也保证不了时间。我不知道这样的情况会不会是以后职业生涯中的一个反面案例。
开发是一项脑力劳动，和人有很大的关系，如果缺乏有效的管理，势必会跌入泥潭，能力高着一个接一个跳槽。