|
|
作者：佚名 联盟会员：项目管理者联盟 转载
（3）项目管理制度。 项目管理者联盟文章，深入探讨。
规范化而且切实可行的项目管理制度，必须因企业、因项目而异。一般而言，应是项目管理原理、企业/行业特点和项目规模/性质、企业开发文化/素质等各种因素综合的产物。产生的过程应是，由具一定的理论素养、丰富的规范化项目实施经验和总结能力的资深项目管理专家，结合企业的具体情况，有针对性地制定，并经培训、试行、调整予以落实贯彻。
而目前我国的普遍情况，或者是企业无项目管理制度，仅凭个人经验实施项目管理；或者是书生制度，照搬教条，纸上谈兵，束之高阁。其结果是，不仅实际的项目管理无所依循，而且也使项目监管层难以落实项目的间接监控和支持。
（4）专业服务组织。 项目管理者联盟文章，深入探讨。
国际上IT项目的开发服务组织，基本上分为产品研发和专业服务两类。我国由于市场成熟度低等原因，多以直接面向客户需求的项目型开发为主，属专业服务型的技术组织结构。但目前我国的专业服务与国际差距很大，主要表现在一是公司策略上将项目实施部门定位为配合系统产品销售的成本中心，而未能作为一个独立核算的业务单元或业务方向；二是基本采取层次性的业务管理性组织结构，而缺乏业务管理和专业管理（诸如运营经理、资源调配、资源开发、行政助理、项目会计、项目质量监控等）的分工合作的矩阵结构；三是缺乏纵向专业深度的设计和结构。
专业服务组织结构的差距，使专业服务部门市场定位模糊，发展方向迷茫。平时不利于专业队伍建设，不能持续有效地发展和提高技术队伍的专业素养；售前活动中，不利于程序化地组织售前支持及控制售前风险；项目实施中，不利于合理及时地调配项目资源，不能将运营监管和项目监管有机结合，以确保项目监控状态。
（5）项目计划。
项目计划是项目经理实施项目管理控制的基础。我国在制定项目计划方面存在的主要问题有：一是项目计划的制定不够严谨，随意性大，可操作性差，因而实施中无法遵循，如项目计划过于粗略，落实Breakdown（“粒度”）不足；没有做到任务、进度、资源三落实。二是缺乏贯穿项目全程的详细项目计划，甚至采取每周制定下周工作计划的逐周项目计划方式，其实质是“项目失控合法化”。三是项目进度的检查（与进度计划比对）和控制不足，不能维护项目计划的严肃性。
项目计划的Breakdown或曰“粒度”，是一个需要小心把握平衡的问题。越细则控制力度越大，但项目管理的成本越高；反之亦然。以国内IT项目目前状况来看，一般3个月以下的项目，应细到人天，至少2～3人天，半年以上的项目，至少应到人周。
如果项目经理对于项目专业领域不够熟悉，则项目计划主要应由项目技术主管和Teamleader（团队领导者）具体起草，因为他们最熟悉工作内容和具体资源的适应性，项目经理做沟通、调整、平衡、确认，并负最后之责。
（6）项目风险意识。
项目风险意识就是失败意识。每当我们启动一个项目的时候，我们往往憧憬项目投产之日的成功，但是否想过精疲力竭后失败的沮丧？做项目不比卖产品，产品卖出就是成功，项目投产才算成功；产品是静态的，项目是动态的；产品质量有问题可以包换、保修，项目一旦失败，时间不能倒流，客户损失的可能就是市场竞争优势和机遇。风险意识，就是对这种结局的可能性的警惕。如此，我们就会小心谨慎地处理许多项目业务需求、技术方案和组织管理的问题。
目前我国市场竞争的激烈和市场的成熟度不足，导致应用开发项目的恶性竞争风险。客户希望物美价廉但同时加需求、压价格、压进度；厂商惟恐出局而拍胸脯、打包票。忽视必要的科学的可行性分析和评估，签订不可能完成的服务合同，项目尚未启动，已经注定了其中的高风险。事实上，这种风险是双方的，厂商可能是经济和信誉上的损失，客户也可能是经济和业务发展上的损失。
项目管理者联盟文章，深入探讨。
（7）业务参与意识。
客户购买IT系统的目的是为了更好地发展自己的业务。应用软件将通用计算机变成了专用的业务系统，因此应用软件中渗透着业务制度、策略，成为应用软件甚至是IT系统的灵魂。因此，国际上成功的案例是业务部门贯穿始终地参与，作为确保项目成功的底线之一。遗憾的是，在我国我们经常会看见技术人员“独立”地开发“创新”性的系统，究其原因，往往有：认为应用开发是IT的事情；认为业务人员的认识囿于手工或现行方式; 业务人员工作太忙，无暇参与项目；嫌业务人员要求太多、太罗嗦，以致频繁变更需求。尽管这些原因不无道理，但归根结底，应用项目是来自于业务部门的需求，最终供业务部门使用。业务参与不足，既可能产生业务偏差的隐患，也可能因业务人员不理解、不认可而夭折。
|
|
发表于 2008-6-28 20:21:00