下面将对上述的五个方面分别进行详细分析，总结的同时，探讨适宜的改进办法。其中可能存在片面的经验之谈，不求事事言正，希望能够起到抛砖引玉的作用，和大家一起探讨。
1、项目组织
一个项目建设的关键因素是什么？我认为抽象来讲就是资源、目标、时间三大主题。
一个良好的、和目标相匹的项目组就是资源中最重要的组成部分，是一个项目成功的基石，其重要性毋庸置疑。
一个好的项目组应具备的基本特征，首先就是需要对项目工作具备绝对的支配权，将合适的人放在合适的位置上。分析一下当前项目：
这个项目是个典型的配合业务管理创新的IT项目，此类项目重点就是业务模型的确立，这将决定IT系统建设的方向。基于建设最终目标，我们换个角度，跳出单纯的IT系统建设，在业务员薪酬体系改革的这个目标下，整个项目的推进，涉及业务模型的确立、规章制度的制定、政策的宣导，以及相应系统的建设等等工作，IT系统建设只是达成目标的技术保障。
基于这样的认识，结合公司部门组织特点，项目的管理责任落在IT部门并不合适，IT部门并不具备足够的支配权，这也基本可以为系统建设中出现的一些矛盾、停滞、突变等情况找到病根。
结合以往的项目经验，推荐两种组织模式，这在我个人以往的项目实践中得到检验，能够有效帮助规避上面的问题：
第一种模式：项目经理&开发经理 分立制
根据此类项目的特点，跳出单纯的IT系统建设的范畴，从最终目标出发，建议设立跨部门的大项目组，由相关业务负责人担任项目经理一职，IT部门委派开发经理。
开发经理的工作职权由项目经理委派，开发经理核心工作承担项目中的技术服务工作，例如：负责筹建开发团队，负责开发团队的日常管理，负责系统开发的进程，保障系统的质量等等。开发经理向项目经理汇报工作。
项目组其他成员按照业务相关性从各个相关部门抽调，项目制本身的灵活性，所有项目成员都可以根据项目工作的需要，决定是全职投入还是部分投入。
这种组织模式是基于责、权、利平衡的原则，比较纯粹的一种方式，可收到很好的效果，推荐采用此种方式。
第二种模式：项目总监制
此种模式在IT部门内部建立项目组织后，可以再设立项目总监一职。项目经理负责项目筹划、协调、分配任务、考核等项目执行中的日常工作，项目经理对项目总监负责，负责向项目总监汇报项目进展、变更等重大事项；项目总监对项目整体负责，负责项目的进程以及目标的实现。
在当前的背景下，项目总监适合由业务部门负责人担任，这样可充分利用总监的协调、控制力量促进项目实施有效推进。需注意的是，这种模式下，对项目经理的担任者需承担较大的协调压力。
2、规划
前面提到项目的三个关键影响因素之一“目标”，在系统建设中的规划工作就是确立目标的过程，此项工作在一个项目中具有决定性的影响，决定了项目组“做正确的事情”，这属于项目中战略性的工作（这样的定性一点都不夸张）。
结合项目情况，纠正两个误区：
误区1：业务部门的要求已经明确了，也就是项目的建设目标，没有必要再作规划
针对这个误解，首先来解释系统开发项目中作规划是作什么？开发项目中的规划工作是规划未来系统的蓝图，通俗的讲就是系统完成后应是什么样的。业务部门提供的需求是业务模型，是系统建设的终极目标，但绝对无法构成系统的蓝图，这也就是软件工程中提到业务需求需转化为系统需求的意义。这个差异是因业务人员的知识背景和IT人员的知识构成的差异造成的，这种差异存在的情况下，将需求进行转换的必要就永远存在。
对此，做个比喻似乎更容易理解，假设某客户想建一套别墅，但他不是建筑专家，仅能就普通人能感受到的一些感官的、想象的元素提出要求，例如：
a、要建一栋别墅；
b、要满足最多10个人的居住，要有足够的生活空间；
c、希望主要的房间例如客厅、卧室，采光、通风良好，给人阳光、明亮的感觉；
d、希望有户外活动空间，满足日常健身、朋友聚会的需要；
<就假设上面几点要求>
开发商承接此项工程后，有必要根据客户的要求推出几个建设方案，就房屋的造型、布局、功能区域划分、装修风格、工程造价概算等内容向客户做出规划设计。仅此，客户才能真切的感受到他能得到一个怎样的别墅，他也才能真正的做出判断和取舍，也才能保证最终建成的房屋是他想要的。如果没有这个规划沟通的过程，开发商直接就开始建设，恐怕客户最终得到的要么是惊喜、要么是诧异，有必要为50%概率的惊喜进行冒险吗？！
规划的好处还将确定和用户沟通的一个基础，技术人员和业务人员可以在一个共通的环境下讨论问题。
误区2：项目工作时间紧，项目建设也不复杂，投入精力做规划必要性不大
这对这样的看法，我想明确了对系统规划的认识后，应该就消除了。系统规划工作是保证项目“做正确的事情”，是项目建设的目标。纠正认识后，剩下的也就仅是“怎样规划？”这样的方法问题了。
这里再简单对规划的方法多言几句，信息系统建设工作发展至今，面向对象方法是个行之有效的方法，建议还是准循其思路展开规划工作，但也要说明一下，面向对象不要狭隘的局限在就是采用用例、流程图、状态图这样的方法上，更不是使用Rose等工具。根据我参与项目实施的经验，将我们分析需求、规划系统的方法归纳一下。
首先对待业务需求，我们将需求分为三个层次：基础业务模型（流程）、功能性需求、系统性需求。
基础业务模型：归纳整理业务处理流程，最好是完整的业务处理流程，明确流程中各个环节的输入与输出，明确相应的操作涉众。（注：这个思路其实和国外倡导的用例分析是相同的，用例分析的核心也就是挖掘业务流程）
功能性需求：对数据、算法、报表等功能都属于此类需求，功能性需求是和业务流程伴生的，通过流程发掘功能需求，功能需要又是对流程的完善。
系统性需求：也即技术性的要求，例如对系统性能、安全有影响的需求，比如业务员的数量。
将需求分为三个层次目的就是为了规划的方便，首先基于业务模型归纳的业务流程，提炼核心业务对象；第二步，基于业务模型的流程，归纳未来系统应具备的功能单元，基于功能单元映射业务流程总结相应的操作流程（注意：这里的操作流程仅需明确到功能单元，避免具体到增、删、改这样的无确切业务意义的操作）；第三步，结合功能性需求、系统性需求，修正规划。这是一个操作性比较强分析需求的思路。
很多在时间上有误解的技术人员大多是因为觉得编写文档费时费力，这也是产生误解的一个原因。对此，强调一下，效率优先是项目的一大原则，这一点大家是一致的，上面阐述的是种分析的方法，并不要求必须按什么形式、编写什么文档，输出什么文档完全应由项目组结合实际确定。需要提醒的是一定要考虑沟通的代价，长期来看，标准化是必要的。
3、计划
上面谈规划，讲到“规划是保证作正确的事情”，那么计划就是保证项目组“正确的做事情”的一个手段。
“凡是预则立，不预则废”，项目计划的制定对于整个项目推进来说无疑十分重要，好的计划应该注意如下的几个方面：
a、项目计划需完整。好的计划需照顾到项目工作的目标、资源、质量、时间、完成标志等要素，同时计划要覆盖到项目所有的工作；
b、项目计划需维护。计划应是变化的，一个可执行的计划一定是伴随着项目的推进逐步细化明确的。
c、计划是手段。抛弃一切为计划而作计划的作法，作计划的目的，在于辅助统筹工作、筹划资源、分配任务、效能考核、沟通协调。
当前项目的情况，可能并不在于没有认识到计划的重要性，而是没有坚持，束之高阁的计划没有意义。计划的维护是需要代价的，但这个代价和其收益相比微不足道，我认为一切涉及多人协作的项目都是需要做计划且要坚持的。同时需要保证计划的可执行性，必须根据阶段发展进行细化明确，明确到具体工作任务上。
另外，计划要覆盖全面，项目相关工作，不仅是开发工作，业务部门的配合工作都应该纳入计划中。
4、控制
项目执行中的控制力也是项目健康推进的关键因素，项目的控制力涉及多个方面，比如团队的管理、时间的管理、成本的控制、风险的控制等等，在这里我想探讨的就是风险管理这一块内容。
某项工作之所以采用项目方式管理，就在于其本身的独特性，或者说任何项目的工作都具有不可复制性。变化的环境中必然带来大量的风险，风险就是“能够影响项目一个或多个目标的不确定性”，一个项目风险如果变成现实，就有可能影响到项目的进度，增加项目的成本，甚至使软件项目不能实现。
风险管理就是探讨如何去应对这些不确定性，使潜在机会或回报最大化，使潜在风险最小化。项目管理理论发展多年，提供的风险管理方法和工具也多种多样，但其中都贯穿着这样一个核心思想：识别风险 → 量化风险 → 计划风险 → 监控风险。这四者构成一个闭环的风险控制系统，识别风险是基础，通过有意识风险识别工作，达到提前识别风险，为后续的量化、应对风险打下基础。
当前项目的实施中，控制风险的力度太弱，项目受到风险因素的影响实在不小，其中表现比较明显的就是需求的风险：建设初期没有充分的开发并明确需求；在建设过程中急于开发，强行推广。此类风险多次对项目造成冲击，造成一些不必要的重复工作，导致项目进度一推再推，对此加强控制实有必要。
对付此类需求变更的风险，应对的策略就是加强沟通、风险前移、强化反馈。
加强沟通就是和需求的提供者最终用户、企业领导进行沟通，让其理解信息化是由开发需求、系统建设和持续改进三个阶段不断循环构成的，系统建设是基于既定的需求展开的。获得用户及企业高层的理解和支持，将有助于加深对风险管理工作的理解：开发需求阶段需要明确需求的价值；系统建设阶段需要控制变更风险；在确定的范围、成本、进度和质量等目标的平衡和取舍下完成项目。
风险前移、强化反馈，目的在于将风险的影响尽量的推进到产生风险的环节，以期可以平抑风险。具体来讲就是将需求变更带来的影响及时直接的反馈给需求制定者，让其承担其应有的责任，一个通行的办法，也是需求管理中倡导的做法，需求的变更不可避免时，一定要对需求进行评估，明确影响范围，修订工作计划，拿出确切的数据反馈给用户，这样才能实现由用户对项目的范围、成本、进度和质量等目标进行平衡和取舍。这个方法还有一个好处，在时间上可以缓冲变更的冲击。
注：需求风险当前来讲毕竟是个过往的事情，在目前的状态下，后续需要控制系统应用无人管理的风险。
5、效率
效率是项目的生命，假设一下，一个支持奥运的项目到了开幕的时候尚未建设完成，它的后果会是怎样？很难想象！
一个项目组的工作效率涉及多个方面，沟通效率、工作效率、开发效率等等。提高效率，最有效的办法就是对经常性的、重复性的工作进行规范，将流程标准化，以便减少甚至消除交流的成本。
这里我并不打算针对当前项目去讨论效率问题，效率改进的长期价值在于部门建设上。
后记：
项目之后的赘言，目的不是去评价一个项目的功与过，希望大家能够用发展的眼光看待问题。大到部门能力的建设甚至企业实力的强化，小到个人能力的提升，都可以通过总结、改进、再总结的过程得到提升。
先聊一下部门能力的建设，就我的了解，当前这个项目应该是公司自主开发的第一个项目，相应的开发团队也是逐步形成。我个人虽然直接涉足保险业时间不长，但对整个金融领域有着长久体验，比如银行、证券、信托、财务公司等形态的企业。整个金融行业有着一些共同的特点，金融是个信息密集型的行业，在金融行业信息是可以直接创造价值的。信息密集化的特点造成了金融企业对信息化的高度依赖，这种依赖不是简单的对IT环境可靠性的依赖，而是有更高的要求，要求企业具备信息创新能力，而这种创新能力是不可能依赖外部的。这个方面一个典型的成功例证就是招商银行，招商银行1987年在深圳成立，成立之初仅1亿资本金，36名员工的小银行，发展到今天，成为现在总资产近万亿，拥有500多个营业网点，并成功在上交所和香港联交所挂牌上市的全国性商业银行。在一次信息化的研讨会上，招行行长马蔚华坦言，招行的发展是信息化带来的革命，他要感谢IT。
金融企业对信息化的依赖性，直接讲也就是对企业的IT部门的建设提出的要求，粗略的讲，金融企业的IT部门仅具备维护、支持等服务能力是不够的，还必须建立支撑企业发展的信息化创新能力，我相信这也必将是部门发展的一个广阔空间。
发展的空间有了，剩下的就是如何发展了，IT项目的管理能力是其中必备的一项素质，工作流程的规划化、标准化，技术部门人员梯队建设、金融业务素质建设等等都是需要去建立的。
第二点，企业的发展。前面明确了信息化对保险企业的价值，那么企业如何建立运用信息化这把利器的能力呢？这个方面需要企业全员的参与，上至企业高层需要加深对信息化工作的理解和支持，下至普通员工需要积极配合，信息化建设有其自身的特点和规律，遵循规律办事，少些所谓的“特色”。在这个能力建设中，企业的IT部门有着责无旁贷的责任，IT部是企业信息化工作的领导者，需要在日常的一点一滴的工作中正确地去影响每一个员工。
最后，个人的发展。每个热爱IT的、愿意投身金融行业的，一定要相信自己的选择，在这样一个大环境中，相信每个人都能找到适合自己的扩展空间。
第一业务员网
·
业务员文摘频道
