1、项目管理的意义 项目管理是一个范围较大的课题。由于市场的快速变化和大量的创新工作，企业中越来越多的工作可以归类为项目管理的范畴。这样，一方面，如果企业能够理解和掌握项目管理的一般规律和技能，无疑会大大提高企业应对市场竞争和变化的能力；另一方面，由于项目管理几乎包罗万象，一般来说，项目管理价值不大。企业应深入研究关键价值链中项目活动的组织、流程和技术，形成成功模式。 2、项目特点 1） 及时性。企业启动项目的原因是希望在短时间内集中资源，快速完成任务。 2）创新。项目工作往往涉及新技术、新方法、新环境，无前例可循。 3） 协调性。项目工作往往涉及多个方面，项目人员往来自多个层面和部门。可以说是创新的。"乌合之众"应对"八路神仙"，很难协调。 4) 结果。项目将有一个既定的目标。然而，对目标程度的评价是不同的。项目经理往往费力不讨好，不可能取悦所有人。 3、项目失败的主要原因 以上四点决定了项目管理的难度、不确定性和高风险。项目失败的案例随处可见。失败的主要原因是： 1） 战略错误。对于市场和技术前景的错误判断，项目做了一半，发现环境发生了变化，项目毫无价值，或者有更好的替代方案。 2) 项目组织结构不合理，责任和权利不明确。 3) 需求分析不准确。 4) 主要技术障碍。重大技术创新困难，应单独批准；常规项目应尽可能成熟。 5) 资源冲突。同时进行多个项目，忽略一个，失去另一个。 6) 盲目乐观，计划和控制无效，工期延误。估计工期过于乐观，缺乏缓冲。 本文重点讨论了前四个问题。 4.项目审批和规划 研究项目管理，首先要考虑的问题是：项目来自哪里，或者项目来源是什么？一般来说，项目的主要来源是：市场或客户的需求；技术研究、跟踪或创新的需求；产品完善或支持的需求；领导或员工的 "灵机一动" 这些原始需求只是一些粗糙和混乱的项目概念。如果项目在这种混乱中匆忙启动，那么这些项目很可能会失败。这些混乱的项目概念必须通过严格的项目审批过程进行梳理和评价，明确项目的目标和范围，识别项目之间的依赖关系，区分优先事项，形成结构化的项目清单，才能在某些基础上成功。 因此，项目审批过程非常重要，直接决定了企业项目管理水平，部分企业项目审批是事后反应，只能被动应对企业内外部需求，采取消防解决方案。部分企业的项目审批是前瞻性的，可以积极预测需求，掌握需求，指导需求，提前预防可能出现的问题和风险。这种前瞻性的思维可以使企业避免一些没有业务价值的项目，而忽略那些真正能够提高企业核心竞争力的项目。 项目审批应认真考虑以下问题： 项目的总体目标是什么？ 用户需要什么？ 现有的东西可以使用什么？ 的成本极限是多少？ 项目持续多久，何时开始盈利？ 的风险是什么？ 。项目运营的组织结构和工作角色支持项目良性运营的组织结构的基本原则： "三权分立，各司其职，相互制衡"。 1) 全国人大:立法和法律解释，定期修改； 2) 国务院:按照法律要求做具体的事情； 3) 检察院:保证依法办事，纠正错误。 以软件开发项目为例CMM正式的软件开发组织应包括以下角色： 1. 软件工程过程组相当于"人大"。其主要功能是建立流程、模板、 检验表、标准、指导书等质量管理体系；软件工程流程组建立后，主要负责质量管理体系的改进 进工作，定期召集会议，讨论制度流程的改进。老子说："治大国若烹小鲜"，煎小鱼儿，必须经常翻，不翻就煎糊了；但也不能翻得太勤，翻得太勤就会破环小鱼儿的形状。制度流程也是一样，不应该变动太频繁，让员工不知所措；但也不能永远"以不变应万变"。 2. 软件开发项目组，包括：项目经理、项目成员、质量控制专员、项目秘书等，负责具体的软件开发。 3. 质量保证人员，相当于"检察院"。其工作主要保证制度流程的顺利执行，一个质量保证人员监控几个项目组了。质量保证人员不仅是事后检查，还必须强化事前和事中控制。质量保证人员要主动协助项目经理以及项目组成员理解这些流程、模板、规范，譬如写代码前，质量保证人员可以给项目组介绍编程规范，写文档前，介绍文档的标准、模板等。质量保证人员保证公司的质量体系在项目组内得以实施，每个阶段结束后，都要对该阶段的进行质量以及流程执行情况的总结，监控项目按照质量计划（质量计划是项目经理制定的）执行。质量保证人员还要通过项目组成员搜集数据，分析数据,给出分析报告，等等。 六、需求分析 需求分析贯穿项目始终，在项目过程中会不断产生新的需求，也会不停地发生需求变更。需求分析是项目管理的重点和关键，需求分析常见的问题有： 1. 需求膨胀。希望一次解决所有的问题，项目范围不断扩大，"把海水煮沸"，最终导致项目失控，偏离原来的项目目标。 2. 需求曲解 a) 需求镀金。对用户需求进行了包装和拔高，"用户需要的是一辆自行车，而不是宝马"。 b) 选择性地过滤用户的需求，"对一个拿着榔头的4岁小孩来说，满世界都是钉子"，需求分析人员可能因为自己的价值观而片面分析问题。 3. 需求分析人员过早给出解决方案，失去了寻找更好解决方案的机会。 需求分析的"5C"和"5T"原则 1. Correct（正确）：表述的内容一和包含的信息应该是准确无误的。 2. Clear（清晰）：言简意赅，意思明确，无需别人绞尽脑汁这个需求到底是要表达什么意思，措辞不可含糊不清，模棱两可，更不能让人感觉话里有话，引起岐义。 a) 易引起岐义的需求表述句式通常是否定式，而不是肯定式。 b) 不要隐含假设 -- 所有假设都应表述清晰。 c) 对所有需求要进行优先级排序。一些需求会比另一些重要，如果需求分析人员已有了这样的判断，就应该也传递给别人。 3. Complete （完备）：每条需求都应完整无缺，避免漏缺或不必要的重复。 4. Consistent （前后一致）： 需求应能与上下文保持一致。需求应包含关键字或标识符，如"应"代表必要的需求，"将"代表导向性需求，而且全文保持这一种优先级定义原则。 5. Changeable（可变更）：对单个需求的更改不会对其他项造成过多影响。 6. Traceable（可追溯）：所有需求的来源都要明确，应可追溯到其他相关文档。 7. Tenable（合理）：所表述的需求必须是可实现的和可操作的。 能否在项目预算范围内，利用有限的资源，按时实施这些需求？一条需求是否与其他需求有冲突？是不是正当需求？ 需求实际上都应是必要的。也许需求用"将"来描述更好一些，也就是指，导向性或非基本功能。某个需求是否只是一般描述，与系统功能没有什么关系？某个需求是否超出系统控制范围，或根本不是需求？ 对每个需求，是不是都能找到用途或用户？有没有存在的理由？ 8. Testable （可测试）：确定每一条需求都可以通过某种方法去测试其是否能实现。是否已量化？容错性和误差范围是否说明？能不能想到一个合理的方法去测试它？ 这个需求的结果是否可见？ 9. Tool （工具性）：需求管理的工具化。 10. Terminology（项目术语表