IT项目规范化建议与细则
2014-06-19 09:28
197 查看
转载自http://www.ciotimes.com/lifecycle/xmss/201009030910.html声明:凡注明CIO时代网(www.ciotimes.com)之作品(文字、图片、图表),转载请务必注明出处为CIO时代网(www.ciotimes.com),违者本网将依法追究责任。 公司自从成立以来,取得了很大的成绩。然后也存在很多的问题,特别是在项目管理方面,项目延期不能及时验收,尾款回收不来。直接影响公司的经济效益。公司应该高度重视项目管理的作用和地位,为此,我们为公司项目做整体规划与建议: 任何一个项目,从启动到收尾,从项目管理角度出发,可分为以下五个环节的关键步骤,并且中间环节应环环相扣: 以下是关于项目整个周期各阶段规范化的想法与建议。 项目阶段一:项目的立项和启动 项目的启动过程可以是项目的核准和确定,项目新阶段的范围,或者使暂停的项目工作继续进行。在这个过程中,我们应该明确项目授权人员,项目实施人员,项目目标和边界,总体概算和里程碑。 项目目标的制定可遵循SMART原则(此原则为2009年《项目管理》时的学习内容): ü S(Simple):简明的项目目标,具体的阶段结果和里程碑 ü M(Merit):项目进度的可考核性 ü A(Authority):责权到位的,包括客户方与我方的接口对应,实施方与开发方的责任对应 ü R(Reasonable):项目整体,乃至具体到各阶段,都是有理由且可实现的 ü T(Time-defined):(整体和阶段)有时限的 该阶段主要强调的是一个项目的整体原则,作为一个启动节点,只需要在资源调配上占用时间即可。 项目阶段二:项目计划阶段 项目的规划过程应定义项目的范围并使之完善成熟,识别发生于项目中的各项活动并为之安排进度,进而制定项目所涉及的各方面的管理计划。 在这个过程中,我们应该制定完整的项目计划书,为整个项目周期的进展做好先决条件以及规范约束。项目计划书应包含以下部分(可进过公司讨论确定最终的计划书模板): 1。项目背景,周期和项目目标; 2。约束和假定; 3。项目实施范围和实施方式; 4。需求分析说明; 5。工作分解结构,项目成果和交付物; 6。任务角色配置,人员职责和项目组织结构; 7。项目里程碑及明细工作结构; 8。项目信息沟通和汇报关系; 9。依赖关系,问题解决流程(包括部门内部和跨部门间的协调和冲突解决); 10。变更处理,变更范围和变更限制; 11。风险分析和对策; 12。质量要求和验收标准; 13。培训,支持性工作; 14。其它必要内容; 项目的计划阶段会对整个项目的进展,阶段性成果,客户满意度以及最终的验收产生直接的影响,是一个重要的阶段。可通过内部会议沟通讨论,确定符合我们的一个标准化的项目计划书模板,为整个项目以及项目参与方提供依据。 对于其中的工作分解和里程碑,我觉得这里已经涉及到了项目节点控制。可使用Office Project工具(附件为IBM对美邦的HER实施的Project范例,以作参考)对其进行规划,制订明确的项目计划。并在一定的周期阶段,进行实施人员,开发人员和部门负责人之间的meeting,以Project中的节点为依据,进行阶段性的评估。各阶段工期的制订,首先要确立工作内容是否存在依赖关系,若存在,则应有前导图与之对应。活动历时的制定,要衡量悲观时间,乐观时间和最可能的时间,以根据内容不同,制订出更合理的任务工期。 项目阶段三:项目实施与执行技巧 项目的执行过程为执行项目管理计划中确定的工作,交付项目阶段性成果给客户,管理项目的实施,实现项目需求和目标的过程。 在这部分工作中,承担着主要角色的是公司的实施人员。在实施过程中,最常用的是项目执行的“硬”技能(项目实施方法和标准化的流程;产品,专业和技术知识与技能等)和“软”技能(沟通协调和人际技巧;项目过程管理技巧;谈判技巧等)。在实施的过程中,会不可避免的出现很多违规范,个体化的需求,应从规范化的角度着手,告知流程改变所需的代价,甚至适当进行拖延,当然这里要有充分的识别。因为任何一个系统都应有其规范化的操作,不能因个体习惯而变,对于系统规范化在个体上的执行,应先僵化,再优化,再固化,使其改变操作习惯。 另外,实施过程中应该注意到以下几个关键点: 1。与客户的对应一定要保持一对一的关系,不能打破这种单一对应,不能未经接口人认可执行任何变动; 2。项目进展中,以计划阶段的Project管理文件为基准,工作内容中的待确认部分应提前于开发进度; 3。阶段性结果或总结,要有邮件告知客户接口人确认,抄送项目相关人员及负责人; 4。明确质量要求和验收标准,分辨客户的硬性需求和软性需求,并以此为原则指导日常工作; 另外,以展濠项目为例,展濠清单中分为三部分:合同,BUG,OTHER。随着合同内容的进展,客户开始更多的提出OTHER部分的内容,而将合同剩余内容优先级降低,这种情况会影响到项目的规划进度。个人有个建议:在制订合同时,我们可加入适当的条例。比如针对项目过程中提出的OTHER内容,若需要项目周期内完成的提供100H的支持,项目收尾后提供支持并解决的内容为160H。超出部分需另支付成本费用。任务所需时间由乙方制订并交由甲方确认(基本确认内容为任务需时是否认可;周期内完成还是作为验收后的后续支持处理)。 这样可以减少项目周期不断拖延的风险,具有一定的约束力。也可以避免当项目规划与客户要求发生冲突时,实施人员难以与其协调而产生磨擦。 项目阶段四:项目控制 项目控制的主要作用是监视和控制项目的启动,规划,执行和收发,评估实施结果,采取必要的纠正措施解决项目进程中出现的各种问题,以满足项目管理计划说明书所确定的绩效目标。 在这个过程中,要着重处理好项目变更和新需求这两种情况。若为需求变更,则应先确立该变改是因需求分析不明确造成的,还是由于客户原因变更。这种情况的解决方式我觉得应按以下步骤进行处理(以序号顺序优选): 1。站在客户角度分析:对客户谈影响,让客户了解风险; 2。若有其它方式可解决该变更,以一些技巧说服客户使用; 3。说服客户在保证项目进度的情况下,待项目完成后另立项目解决; 4。变更项目计划,实施变更; 需求变更和新需求申请,应遵循以下流程: 项目阶段五:项目收结与验收 项目收尾与验收,是正式结束一个项目或阶段的所有活动,将完成的产品移交给客户。 在这个阶段开始之前,要为收尾工作做好计划和预算。实施人员应整理每个里程或阶段交于客户的书面文件(在实施阶段中对客户的各阶段的邮件,内容应有附件说明,以作验收时的书面文件),客户应对合同各细节进行确认,以立项细则为准进行全盘收尾,并最终签字完成验收。 公司内部应有完整的项目纪录和会议纪要,以此总结经验教训。 管理控制建议 我认为我们的管理控制可以逐步要求符合CMMI标准,并在一定的时间以后,产品申请通过CMMI标准,我想这也可以成为我们产品销售时的一个卖点。 对于我们的VSS管理,在原有的基础上,可扩充为以下List: Remark: Doc: 包括开发规范等一系列规范化说明,以及一些实用的资料等内容; Pro。 Name: 各项目名称,各项目父目录结点; Summary: 项目概述,包括项目计划书,Office Project等一系列项目相关文档; Dev Code: 开发项目代码; Design Documents : 项目设计文档。现在我们这部分是相对不够完善的,希望可以逐步完善补充各模块业务设计文档,并在其基础上,对每次更改进行纪录和修改。这样既规范了文档化管理,另外对人员流动,工作交接都会有好处; Update History: 更新文件历史。存放命名格式为Update20100416的压缩文件,此文件为更新文件,文件,文件应包括update, bin, DB三个文件夹,并包括更新清单文档;该文件夹可开发实施人员权限,在更新结点日,项目负责人将文件放入该文件夹,供实施人员获取,确认更新清单内容并对客户进行更新。实施人员应定阶段向客户提供标准化的阶段性成果汇总文档,以邮件形式告知; 现阶段VSS上的DB文件夹,提供更新时需运行的SQL文; Test & FAQ: 测试文档和FAQ文件,此权限可开放。供日常发现问题纪录。部门管理者应阶段性审核该目录下文件,并评估紧急程度,分配资源解决。(责编:陈广成)声明:凡注明CIO时代网(www.ciotimes.com)之作品(文字、图片、图表),转载请务必注明出处为CIO时代网(www.ciotimes.com),违者本网将依法追究责任。
相关文章推荐
- IT 项目监理细则(转)
- 按期完成IT项目的10条建议
- IT 项目监理细则(样本)
- 按期完成IT项目的11条建议
- 浅谈Android开发中项目的文件结构及规范化部署建议
- IT项目管理中的几个建议
- 按期完成IT项目的10条建议
- 按期完成IT项目的10条建议
- IT项目监理细则(样本)
- IT 项目监理细则(样本) [转]
- IT 项目监理细则(样本)
- 给想进入IT行业的同胞一点建议(加入我的观点)
- 软件项目失败不起:人才环境对IT项目影响[zt]
- IT项目管理最佳历程之一: 项目经理在售前阶段的任务
- 如何进行IT项目的需求调研?[读后有得所以转之]
- IT项目监理暗流涌动
- IT整体外包后业务系统从开发项目转入维护项目的过程管理
- 项目管理:规范化的过程及关键概念
- IT项目如何做好进度管理
- 从优秀IT项目经理到千万富翁的距离只有1m——如何当好项目经理