软件项目成败的原由可以说是多种多样，但不论其千变万化都可以归纳为三个方面：技术，人力，过程管理。

　　在技术方面，首先是产品对项目的支持。产品的易用、易维护、易扩展、稳定性直接决定了对项目的支持程度。
　　衡量一个产品质量有许多种方法，ISO中也有对一个企业软件质量方面的明确规定。在企业应用管理软件中，常常从功能上提出了一些具体的标准，比如：自己封装的时间编辑框(支持时间的选择、清空和手工录入)和下拉框(支持中文过滤或者其他一些功能)、自定义统计、自定义报表、自定义流程、自定义界面、查询。每个经验丰富的软件过程师一般都会在其中一两个领域中有自己独特的一套办法。

　　一个好的界面在开发前应该考虑到日志、权限、通用业务流程、数据库操作的处理、界面控制(字体、焦点颜色、输入法控制)等、字符集和常量定义。同时要考虑到界面的展开方式(光标处理，延迟界面的处理)、界面间参数传递的方式或者消息处理、界面的封装和独立等。

　　好的产品才能对项目做出大的支持。

　　如果说技术是个基础，那么人力是一个项目的根本。

　　产品开发可以有梯队，企业可以有新人，但是项目队伍一定要精练。要用用的人才。有时候一个项目精英可以发挥一个企业系统级的作用。项目组的成员要素完整、分工清晰和权责分明。

　　权责分明非常重要，权责不明导致沟通中出现冲突。有时我们解决沟通冲突往往只想到统一接口，这样做会增加沟通的成本，造成项目的延迟。

　　必须有一个项目经理，而且这个项目经理不要承担过多具体的工作，他只需要协调全局，严格跟踪计划、推动计划的执行、控制项目范围、平衡质量和效率等。项目管理培训

　　个人经验、解决问题能力也很重要。

　　比如用户强调一个界面。我们去编程写一个界面，加上一些数据处理或者其他功能一般需要三天左右的时间。然后和客户一讨论发现不对，回去再改上个几天，反复几次，一个月过去了。我常常用word表格来做界面，用不同颜色单元格来替代工具栏，菜单项及其他工具按钮，在和客户交谈的过程中我可以做出这个界面，然后让客户确认。一些功能相对复杂的界面，我一般用编程工具做出大概样式，然后复杂部分或者数据连接部分直接用图片代替，让用户确定后再认真做出界面，这样节约了大量的时间。许多中小软件企业都采用这种方法做一些初级demo。

　　这种类似的经验可以相互交流，相互学习。这也是修炼内功。

　　要增加激励人的手段，出台一些项目奖励措施。避免出现困难时，员工找借口，抱怨待遇不好，奖少惩多。记得公司年中会后和李总吃饭时，李总说，险境是机会，公司内许多人的成长都是克服了重重困难后获得的。但是真正遇到难题时，大家却很难摆正心态，需要一些外在措施的激励，这个不是简单的敬业与否的问题。
　　影响项目的重要的因素却是过程管理。过去几十年，软件项目的失败，70%以上都可以归结为管理不善。

　　从项目启动会议开始后，要确认项目组成员，一定要把客户的业务骨干加入到项目中来。项目组内要定期汇报项目进度，总结项目工作。

做需求分析的人尽量熟悉业务和产品、以及一些标准规范比如ISO和CMM体系。只有这样才能使客户信服，甚至可以把业务实现方式向我们的产品上引导。做需求调研尽量有书面文档，文档要全面，了解一下客户的软件硬件环境、网络环境、客户组织机构、客户的人员素质。争取把医院的现在大体情况了解清楚。把一些问题指标化，比如有几个登记台，有几个his软件，超声科室放射科室主任是谁。以前我做需求调研时，常常抱着一大堆资料让客户去填，我了解后才开始分别找相应的人去咨询。同时要把可能有争议的问题，甚至业务规范中不明确的问题，提前和客户讨论清楚，避免问题到了项目中期才发现，那时发现这些问题都是些“硬骨头”时，只能感叹了。比如his融合，叫号系统，产品要求和业务需求。客户的主业务流程必须调研清楚，形成文档，并用迭代方式不断补充汇总，这一块内容要求能量化，明确化。需求调研的成效直接决定了能否准确的评估工作量。

　　项目经理要肩负起控制项目范围的作用。以市场和客户需求为导向，对需求变更进行评估，需求发生变更时要更改相应的工作计划。要编写或者汇总项目开始后每个工作计划，里程碑计划、需求分析计划、概要计划、产品研发计划，测试计划等。控制项目范围简单说是使项目中产品功能要或者客户需求及需求变更有一定限定性。防止过度追求产品完善或者客户需求无限变更造成风险增大、成本增加、进度失控。