首先这是一个失败的项目,因为没有获得对应的商业利益。那症结就应该是基于商业利益的。
第一个问题:症结应该是在项目启动时的商业文件内容,公司是有很好的技术优势,但能否通过技术手段得到很好的商业效果是需要做前期调研与数据分析的。没有做好商业分析的话,技术好也没有用。责任人是发起人与项目经理。
第二个问题:症结已经找出来了,总结经验教训就是
1 要在启动阶段就做好商业分析并在项目过程中不断地反复查验商业分析的条件是否仍然存在。
2 不要盲目的相信技术优势,一个项目的成功需要很多个维度的思考与执行都到位。
项目的定义:
美国的项目管理协会定义:项目是为完成某一独特的产品或服务所做的一次性努力,项目就是一系列的相关工作。
中国的定义:项目是一个特殊的将被完成的有限任务。它是在一定时间内满足一系列特定目标的多项相关工作的总称。
1 项目是一个有待完成的任务,有特定的环境和要求。
2 有一定的组织机构内,利用有限资源(人力,物力,财力),在规定时间内为特定用户完成特定目标的阶段性任务。
3 任务要满足一定的性能,质量,数量。
项目的基本特性:
1 项目的独特性
2 项目的一次性
3项目的组织性
4 项目的生命期:项目启动阶段,项目计划阶段,项目实施阶段,项目收尾阶段
5 项目的资源消耗性
6 项目的目标冲突性,三约束:范围,时间,成本。
7 项目后果的不确定性。
项目管理,在项目活动中运用一系列的知识,技能,工具和技术,以满足或超过相关利益者对项目的要求。
1 管理活动,一种有意识的按照项目的特点和规律,对项目进行组织管理的活动
2 管理学科,以项目管理为研究对象的一门学科。探求项目活动科学组织管理的理论与方法
项目管理就是在项目活动中运用专门的知识,技能,工具和方法,是项目达到预期的目标的过程,是以项目作为管理对象,通过一个临时性的,专门的组织,对项目进行计划,组织,执行和控制,并在时间,成本,性能,质量等方面达到预期目标的一种系统管理方法。项目管理贯穿整个项目的生命期,是对项目的全过程管理。
风险是指损失或损害的可能性。项目由于它们独一无二的本质而具有风险。
风险管理是一项投资,也就是说,风险管理需要花费与识别风险、分析风险和制定风险减轻计划相关的成本。这些成本必须包括在成本、进度和资源的计划编制中。
组织部门承担风险,以从潜在机会中获利。
风险效用或风险承受度是指从潜在回报中得到满足或快乐的程度。风险喜好者乐于高风险,风险厌恶者不喜欢冒险,风险中性者试图在风险和潜在回报之间取得平衡。
风险管理是一种行业准则,它要求项目团队不断地评估什么会对项目产生消极的影响,并确定这些事件发生的概率,以及确定这些事件如果发生所造成的影响。风险管理也涉及分析和决定对付风险的备选战略。风险管理中包含的四个主要过程是:风险识别、风险量化、风险应对计划制定和风险应对控制。风险管理计划是风险管理的重要输出。
ITS,目经常涉及下列风险:缺乏用户的参与、缺少高级管理层的支持、不明晰的要求、拙劣的计划编制,等等。由斯坦迪什集团、麦克法兰和其他组织开发的风险列表,有助于识别IT项目的潜在风险。在项目管理知识领域的一般风险条件列表也会很有帮助。
量化风险的工具和技术包括期望货币值(EMV)、计算风险因子、PERT估计、模拟和专家判断。期望货币值有助于你根据项目的预期价值来评价潜在的项目。风险因子代表了具体事件的风险,它基于其发生的概率和如果发生时所造成的后果。PERT估计需要收集乐观估计值、悲观估计值和最可能估计值。模拟是一种与PERT相比更加复杂的估算方法,它有助于你确定满足具体项目进度或成本目标的可能性。专家判断也是一种评估项目风险的有价值的工具。
三个应对风险的基本措施是:规避、接受和减轻。风险规避涉及根除具体的威胁和风险。风险接受意味着如果风险发生接受风险产生的后果。风险减轻是指通过减少风险发生的概率来减轻风险事件的影响。
风险管理计划记录了管理整个项目过程中相关风险的步骤。项目团队也会准备应急计划,这样,如果一项已识别的风险发生时,他们就知道应该采取什么措施。项目发起人经常提供应急储备来帮助应付项目范围或质量上的可能变更,从而减轻整体上的成本或,和进度风险。
风险控制涉及执行风险管理过程和计划来应对风险事件。“十大风险事项追踪”是一种在整个项目生命期始终保持风险意识的方法。
几种类型的软件在风险管理过程中会起到辅助作用。蒙特卡罗模拟软件是一种特别有用的工具,有助于更好地理解项目风险和风险或风险驱动者的几大来源。
项目管理是管理学的一个分支学科,对项目管理的定义是:指在项目活动中运用专门的知识、技能、工具和方法,使项目能够在有限资源限定条件下,实现或超过设定的需求和期望的过程。项目管理是对一些成功地达成一系列目标相关的活动(譬如任务)的整体监测和管控。这包括策划、进度计划和维护组成项目的活动的进展。
“项目是在限定的资源及限定的时间内需完成的一次性任务。具体可以是一项工程、服务、研究课题及活动等。”
“项目管理是运用管理的知识、工具、技术于项目活动上,来达成解决项目的问题或达成项目的需求。所谓管理包含领导(leading)、组织(organizing)、用人(staffing)、计划(planning)、控制(controlling)等五项主要工作。”
扩展资料:
项目管理工程包括:开发管理(DM)、项目管理(PM)、设施管理(FM)以及建筑信息模型(BIM)。
而项目管理则又分为三大类:信息项目管理、工程项目管理、投资项目管理。
1信息项目管理
是指在IT行业的项目管理。
2工程项目管理
主要是指项目管理在工程类项目中的应用,投资项目以及施工项目管理。其中,施工版块主要是做到成本和进度的把控。这一板块主要使用工程项目管理软件来把控。
3投资项目管理
主要是用于金融投资版块的把控,偏向于风险把控。
IT项目管理:问题、体系、方法
摘要:无论是在国内还是国外,项目管理的学科、技术和应用的普及与发展已经进入了一个飞速发展的时代,信息技术(Information Technology,简称IT)的发展又将IT项目管理推向了全新的应用高度。本文分析了IT项目管理技术及其应用与发展的关键问题,提出了基于系统集成理念构建的IT项目管理的体系结构和技术框架,肯定了IT项目管理的总体指导思想和实施策略是“需求牵引、效益驱动、总体规划、分步实施”。
关键词:信息技术 项目管理 体系结构
引言
人类进入21世纪,信息化成为我国全面构建和谐社会、快速发展国民经济的着眼点。党的十五届五中全会就明确指出:“大力推进国民经济和社会信息化,是覆盖现代化建设全局的战略举措。以信息化带动工业化,发挥后发优势,实现社会生产力的跨越式发展。”党的十六大再次明确:“信息化是我国加快实现工业化和现代化的必然选择。坚持以信息化带动工业化,以工业化促进信息化,走出一条科技含量高、经济效益好、资源消耗低、环境污染少、人力资源优势得到充分发挥的新型工业化路子。”目前全国上下各行各业、各个领域、各个层面的信息化建设正在如火如荼地进行着。
信息化项目的开展是以信息技术为支撑,以业务活动为主体,以现代化管理为指导思想的一项全新的、复杂的系统化工程。全新在于信息技术这一新生事物的飞速变化与发展,复杂在于信息技术、业务工作、项目管理思想的一体化融合与集成化应用,这正是IT项目管理问世的缘由。信息化建设的成功经验告诉我们,结合信息化应用特点,采用项目管理技术而开发的专用方法对IT项目在计划落实、质量跟踪、成本管理和风险控制等方面进行管理,是保证IT项目达到预期目标的有效手段。
本文在项目管理知识体系的基础上,介绍了IT项目管理的特殊性,回顾了学术界和工业界在不同方向上为解决这些问题所做的努力、获得的成果。在系统集成理念的指导下,探讨IT项目管理的体系结构和模型驱动的集成技术与方法。
1 IT项目管理的特殊性
信息技术发展快、渗透广等特点,使得IT项目与一般工程项目存在着明显的差别,这种差异性造成了基于工程项目管理理论与经验基础上发展起来的项目管理知识体系在处理IT项目时面临诸多的难题。
第一,IT项目的需求来源广泛,涉及国民经济的各个领域,几乎所有领域都能够和信息技术相结合而构成信息化项目。信息技术可以支持多种业务需求的发展:
(1)市场要求,如商业银行提供网上支付业务,以支持越来越频繁的电子商务活动。
(2)环境需求,如企业为了应对各国越来越严格的环境标准中对产品回收再利用的要求,启动一个构建产品全生命周期管理系统的项目。
(3)经营需要,如一个传统的大型商业企业开展网上销售业务,以扩大其销售收入。
(4)技术发展,如飞机制造企业为了提高设计水平而开展虚拟制造系统的项目。
(5)用户要求,如快递公司要构建一个物流管理系统,以满足顾客对跟踪其委托的快递物件过程状态的查询需求。
(6)法律需求,如一个城市为了减少合同犯罪的数量,而启动企业印鉴信息系统;为了杜绝文凭的泛滥而建立文凭查询信息系统。
正是由于信息化项目涉及到了几乎所有的经济领域,因此很难形成有针对性的规范和标准,这无疑增加了项目管理的难度。
第二,与一般工程项目所涉及的领域经过了长时期的发展、技术相对成熟不同,IT领域是目前发展最快、最活跃的领域,新的技术层出不穷,技术更新也非常迅速,因此IT项目开展过程中会具有更多的风险因素。有统计表明,每18个月,CPU的速度就会翻一番,与之关联的计算机体系结构、软件架构等也发展非常迅速。例如早期的集成信息系统采用大型主机带终端的结构,随着网络技术和分布式计算技术的发展,出现了Client/Server结构的信息系统,而目前流行的架构则是在互联网上基于Browser/Server结构的信息系统,C、C++、Java等各种开发工具更是一代代迅速更迭,各类 *** 作系统、协议、标准等都是IT项目必须面对的,这些都会增加项目过程中的风险。
为了处理好技术发展迅速所带来的问题,IT项目团队必须在先进性、实用性、经济性、成熟性等诸多方面进行权衡,片面追求技术的先进性往往会事与愿违。在保证项目所采取的技术具有相当的前瞻性、先进性和可扩展性、可集成性的同时,从需求出发,注意技术的可靠性、成熟性和经济性。
第三,信息技术的应用主体在管理领域,管理信息系统包含了特定的管理理念,将这些管理理念同企业的发展战略与业务逻辑进行整合是信息系统实施的关键任务。IT项目的阻力75%以上是来自人和管理的因素,因此,IT项目特别强调技术、管理与人的集成。如何处理好信息系统所涉及的人的问题是成功管理IT项目的关键。
从更深层的角度而言,经典项目管理理论是构建在土建工程项目的研究和实践基础上的,基本的项目管理方法并不能解决IT项目的特殊问题,例如:
(1)如何衡量项目进度的问题,土建工程使用完成土石方的量来标识工程进度,但是完成软件90%的代码编写工作并不意味着还有10%的时间就可以完成软件开发项目了。业界普遍认为在工程项目中广泛使用的挣值法在IT项目中缺乏适应性。
(2)在计划的调整方法上,土建工程在计划拖期时,可以通过增加资源的方式来加快进度,但是对于一个软件开发项目,如果出现同样的问题,寄希望于增加编程人员的数量来追赶工期,只能造成更大的麻烦。
另外,除了信息技术之外,IT项目还涉及信息系统应用单位的组织、管理的调整与经营过程/业务流程的重构,单靠信息技术是无能为力的。因此,要成功管理IT项目,要成为IT项目的合格从业人员,需要一套全面的IT项目的知识体系与方法的支撑,它的内容将覆盖项目管理、信息技术、现代管理技术、系统集成技术、软件工程技术等多学科领域,这正是IT项目管理技术研究和实践的目标与方向。
2 IT项目管理技术的发展脉络
目前在信息化领域的不同方向,许多学者开发了针对不同方面的项目管理方法,其中比较有代表性的是软件项目管理和广义的IT项目管理。
软件项目管理是软件工程和项目管理的有效结合,将项目管理中重视过程、重视计划控制的观点引入软件工程领域,目的是控制软件开发项目的成本、进度、质量、风险等问题。近几年IT领域进一步引进全面质量管理理念,认为软件开发企业自身质量控制体系和控制能力的优劣,将会极大地影响软件产品的质量,这就要求软件企业从修炼内功入手,也就是确认质量是控制出来的而不是检测出来的,从根本上保证软件产品的质量,由此提出了软件过程改进和软件能力成熟度模型(CMM)的概念。CMM基于经典的产品质量原理,建立了定量控制软件过程的项目管理和项目工程的基本原则,与此同时,CMM有关能力成熟度的 *** 作方法也被引入经典项目管理领域,用以测评承担项目的组织的项目管理能力。
广义IT项目管理是目前业界讨论比较多的,也出了不少这方面的专著,其基本思路是将IT项目当做一般工程项目,使用PMBOK的方法体系,结合一些信息技术项目的案例,研究如何在信息技术项目中应用项目管理方法。
广义IT项目管理是将所有与IT有关的项目不加区分地通盘考虑,包括IT产品开发项目的管理和IT应用项目的管理。实际上广义IT项目可以细分出多个类别,各个类别之间的差距是非常巨大的。计算机硬件开发项目与一般家用电器产品的开发设计具有非常高的相似度,而软件设计开发则完全不同,信息技术应用项目与上述两个分支领域更是存在巨大的差异,因此广义的IT项目管理实际上是在经典项目管理知识体系的基础上,尝试解决IT项目的具体问题。目前来看这种处理方式比软件项目管理体系的针对性差很多,对其进行细分研究具有非常重要的意义。为了提高IT项目管理的针对性,提高解决方案的系统性,学术界和企业界在企业信息化、数字化城市与电子政务、数字化军工、供应链与物流、电子商务等不同领域分别开展了体系结构、实施指南、参考模型等的研究和实践,取得了一定的成果。
3 IT项目管理的体系结构与方法论
系统参考体系结构是“一组用以描述所研究系统的不同方面和不同开发阶段的、结构化的、多层次多视图的模型和方法的集合,体现了对系统的整体描述和认识,为对系统的理解、设计、开发和构建提供工具和方法论的指导”。
系统参考体系结构为IT项目的管理提供了体系参考和方法论,经过各国专家的努力,已经形成了一批相当有代表性和广泛影响力的体系结构及其建模方法,并进行了大量的工业实践,如CIM开放系统体系结构(CIM-OSA)、GRAI集成方法论(GIM)、IMPACS、普度参考体系结构(PERA)、集成的信息系统体系结构(ARIS)、通用企业参考体系结构与方法论(GERAM),以及在我国提出的阶梯形CIM系统参考体系结构(SLA)等。
在信息化项目管理过程中,系统的认识和构建是阶梯上升的,在概念定义阶段需要明确企业的战略目标,并据此形成集成系统的目标,然后围绕系统目标,从组织、资源、信息、产品、功能和经营过程等角度描述企业的现状,形成对企业基本框架和运行机制的完整描述。在这些描述的约束下,采用合适的模型分析手段进行分析,找出现有系统中的问题进行改进,然后构建目标系统,形成多视图的目标系统的描述。在形成目标系统描述时,除了使用各个视图的描述方法外,还可以应用其他建模方法,以便提供对系统更为完整的描述。完成基于模型的设计后,就是在构建工具集的帮助下,将设计转化为实际系统构建的技术说明,并构建实际系统。系统描述对于系统的运行仍然能够发挥作用,可以作为实际系统运行的参考,并据此进行系统的优化与调整。
一方面由于信息化项目的多专业性,为了解决沟通和分析设计的问题,需要借助建模的手段实现对被处理对象系统的描述;另一方面由于信息化处理对象的复杂性,依据“化繁为简、分而治之”的原则,使用多层次多视图的模型来描述目标系统。视图的划分包括反映结构信息的信息视图、资源视图、组织视图、产品视图,反映系统时间和逻辑特征的过程视图,结合反映系统功能结构和功能关系的功能视图,以及反映企业经济性和目的性的经济视图。静态结构反映了系统的存在,行为结构给出了系统的属性和运行方式,而评价结构则将系统和它的目的性关联在一起。透过多视图,为IDEF、ARIS等其他建模方法和工具的集成,对于制造企业原模型和企业本体的开发提供了技术框架。利用模型技术解决IT项目的交流、设计、技术转移、系统构建乃至运行维护的问题是目前学术界和业界的普遍看法,模型驱动的体系结构是目前的一个研究和实践的热点。
4 结论
随着信息技术的发展和应用范围的不断扩大,IT项目管理越来越具有普遍性。分析IT项目的内在特征和特有问题,在项目管理知识体系的架构下,有针对性地开发适应性的理念和方法,将是IT项目管理领域的发展方向。
需要强调的是,信息技术本身的发展并不是IT项目的目的,满足应用对象的需求和战略目标才是其出发点,因此需要切实做好项目的需求分析,一切从业务工作的实际需求出发,在集成理念的指导下,充分考虑整个系统的集成要求,并在此基础上选择相关的成熟技术、应用系统和产品,同时做好项目的技术经济分析,才能保证信息化项目发挥实效。国家863计划CIMS主题专家组在大量信息化工程实践的基础上提出的“需求牵引、效益驱动、总体规划、分步实施”的策略是IT信息化项目管理的总体指导思想。
项目开发方面
项目应以需求为核心。一个项目是否能够成功,对需求的准确把握在成功因素中要占上60%的比例。不管系统的架构设计、团队管理有多么的成功,如果需求出现偏差,仍然是南辕北辙。由于eas项目的特殊性,项目开发过程中能够与客户建立有效快速的沟通渠道,是项目成功的关键。
需求必须获得客户的确认。通过需求调研与分析后获得的用户需求说明书,以及软件需求规格说明书都必须得到客户的签字确认。确认的内容包括项目的目标、范围以及项目需求功能点(用例)。eas项目在前期对需求不够重视,导致在需求理解上出现了一些偏差,从而影响了项目的进度。幸而得到了及时的纠正,在项目管理部的协助下,所有需求都得了客户或客户代表的签字确认。从而使得项目在客户验收时,有了充分的保证。
项目应确立专门的需求分析师。公司没有专门的需求分析师,不能不说是人员配备上的一大弊端。(软件开放工作细分的第一步就是要有专门的系统分析员或需求分析师)从eas项目的开发过程中,我们就充分地认识到这一问题的严重性。需求的不断更改,客户迟迟未签字确认,原因正是在于我们没有专门的具有丰富经验的需求分析师。普通开发人员在调研需求以及撰写需求规格说明书时,总是会出现偏差或理解错误的地方。软件需求分析是一项重要且负责的技术,没有经过专门训练的需求分析师,通常会给项目带来隐患。
项目应指定各个模块的需求接口人。只有这样,才能有效地保证项目组与客户的及时沟通,快速响应客户的请求与反馈。eas项目在开发早期及时地确立了需求接口人,在一定程度上规避了需求变更给项目带来的风险。但是,确立的需求接口人未经过系统培训,在需求调研以及与客户沟通的过程中,工作表现只能说是差强人意。
注意维护需求调研记录以及需求跟踪表。这一工作做得不够好。由于需求调研人不够专业,而项目经理以及需求分析负责人对这一过程还欠缺足够的重视,同时没有好的工具或流程来监控这一过程,使得需求调研记录没有发挥更大的作用。此外,需求跟踪也非常重要,毕竟,任何项目的需求都不是固定不变的,需求随时会发生变更,而开发人员实现的需求也可能会与客户的要求偏差。
注意维护需求矩阵。项目经理对这一内容缺乏足够的重视与理解,项目开发过程体系中也缺乏好的需求矩阵文档模板。但是在项目中后期,项目及时撰写了eas项目需求功能列表,并结合交付版本与客户进行了沟通和协商,从而规避了需求偏差的风险。(需求追踪,任何原始需求来有头就有尾。原始需求->用户需求->产品需求->软件需求->设计->测试等一系列的追踪。需求追踪的目的一方面是检查需求是否都已经实现有无遗漏,更多的是为了做变更影响分析使用)
控制需求变更。重视ccb的作用,同时应建立需求变更的响应机制。eas项目组对于需求变更的响应还不够及时,这一点项目经理与项目管理小组要担负一定的责任。(范围管理中范围控制的内容,变更管理是配置管理的一个重要内容。需求必须要受到控制,否则容易引起计划的频繁调整而发生混乱)
设计
重视架构设计。eas项目的成功,一定程度是源于我们有个优秀的框架开发小组,我们在项目立项之初就基本确定了整个系统的架构。其中虽然发生了一些变化,但核心架构仍然没有发生大的变化。由于,我们建立了稳定、简单的系统框架,可以极大地提高开发效率,规避了对框架的重复编码。(软件开发的第二个重要分工就是最好有专门的架构设计人员,架构设计和总体设计要由1-2个人来完成,以保证高度的概念完整性和设计统一)[1][2][3][4]
善于对设计作出取舍。项目开发的三要素是成本、质量与进度。在保证质量的前提下,为了项目进度不出现大的偏差,eas项目组并没有过分强调技术,特别是在考虑进度的情况下,牺牲了系统的部分可扩展性。虽然这为系统的后期维护带来一定隐患,但却能够有效地保证项目的进度。从eas最初的架构设计来看,我们引入了 castle与aop,试图简化orm以及横切关注点例如日志、异常、权限、事务等功能的实现。同时,希望采用wcf,利用soa思想建立松散耦合的面向服务应用程序。但随着客户需求的变化,我们果断地放弃了采用wcf的构想,同时又克服了技术困难,坚持了对castle与aop的使用,并为此成立了框架开发小组。事实证明,在技术的抉择上我们作出了正确的决定。
重视ui原型设计。系统的原型设计与需求分析相辅相成。如果有好的原型版本交付给客户,则客户更能够理解系统的实现,促进沟通的有效性与准确性。在eas项目中,我们从一开始就确立了原型设计小组,并在分析需求阶段,就开始了原型设计。这一做法无疑在客户沟通、需求确认、ui设计等方面都发挥了很大的作用。但是,我们在这一点上,由于缺乏专门的ui设计人员,因此,这一工作还存在很大的缺陷,甚至于ui的设计为迭代版本的交付带来了很大的障碍。在项目后期,关于ui的bug是最多。因此,我们认为在开发类似的web应用程序时,应尽早确立ui设计规范,以约束所有的ui设计。同时,必须培养专门的ui设计师,在开始原型设计时,就尽快完成ui交互的设计。并且,必须成立专门的ui 设计小组,在需求阶段与需求分析师合作,在编码阶段与开发人员合作。(原型设计是加强前期用户需求挖掘和减少后期需求变更的重要手段,不一定需要专门的ui设计人员,原型设计可以由需求分析师来完成)
测试
测试成员应了解需求。如果不了解需求,测试人员无法编写正确的测试用例,同时在测试过程中,也可能因为错误地理解需求,从而导致报告错误的bug,影响开发人员效率。加强开发人员与测试人员的合作。开发人员必须及时响应测试人员提交的bug。而测试人员也应跟踪开发人员对bug的修复情况。(测试人员应该要意识到自己和需求分析人员的区别,测试人员不用想需求分析人员一样分析和开发业务,但是他们必须和需求分析人员一样对已经分析出来的需求和业务高度熟悉)
测试之初必须确定测试原则,对bug的严重程度进行分级。同时,必须确定修复bug的优先级别。
进度管理
保证项目进度不出现大的偏差的前提是制定一个好的项目计划。必须根据项目规模,成员情况,技术难度等多方面考虑整个项目计划。如果项目的deadline已经确定,则必须采用一些方法来保障项目计划的完成。首先是选择符合项目的软件开发生命周期。通常情况下,并不建议采用瀑布开发方式。最佳的办法,应该是 rup或者敏捷开发,然后结合原型法制订项目计划。这样可以规避因为需求变更产生的风险。
其次,要每日跟踪项目的进展情况。可以通过晨会、周会以及项目日报、项目周报了解项目进展情况。同时,需要为各个小组指定进度跟踪人,根据各个小组长的日报,判断实际的进度是否与计划出现偏差。
要制定项目进度偏差的应对方法。一旦项目进度出现了偏差,必须采取相应错误解决问题。或者通过加班、增加人手、申请项目进度等方法及时作出响应。
及时向项目成员汇报项目进度情况。只有让各个项目成员了解到项目现状,才能够给每个成员增加压力,不至于松懈。同时,也能够使得每个成员能有一个目标,而不至于茫然失措。
制定项目计划时,必须考虑阶段评审与同行评审的时间。这一点在eas项目中做得不够好。其中原因也是由于项目进度本身较紧的缘故。注意维护项目进度跟踪表与项目进度偏差跟踪表。让项目管理部以及qa及时掌握项目进度,有利于对项目进度的管理。
变更管理
变更包括需求变更、人员变更。如果不控制好,两者对项目的进展都会带来灾难性的后果。需求变更在前面已经叙述,而eas项目中发现人员变更的情况也非常严重,因此这里重点介绍关于人员变更的管理。
如果发生人员进入的情况,那么对项目带来的通常都会是好的影响。但我们也必须注意如何让新成员更快地融入团队。整体上讲,如果需要新成员加入,发生变更的最佳时机是项目前期。如果在项目中后期加入新成员,无疑则意味着项目出现了灾难性的后果。而新增加的成员,由于不熟悉项目,所能带来好的影响也是有限的。如果不处理好新成员与老成员之间的合作关系,反而会带来负面影响。
人员的退出很多时候是不可控的,同时对项目带来的影响也是不可估计的。为了将这些影响降到最低,就必须在项目开始之初就要确立编码规范。同时,还应该重视对文档的维护与更新。而在人员退出时,必须做好交接工作。同时,还应对这种变更进行合理的评估,并及时报告项目管理部,并与客户及时沟通。如果对项目进度有严重影响,应争取最大的努力取得客户的理解,提出项目延期的申请。
风险管理
要在项目开始之初就考虑到项目过程中可能出现的所有风险,是不现实的。但是,我们必须考虑对风险的管理,尤其是在制订项目计划以及创建团队的时候,考虑这一因素。风险有很多,包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划,而一旦发生了风险,则必须及时响应,组织相关人员解决风险。不能忽略任何一个小的风险,否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。
成员管理
不团结的项目组是无法保证项目的成功地。项目经理与项目组长在管理团队成员时,必须时刻注意成员状况,即使处理工作出现的矛盾与摩擦,随时保证团队合作精神得到最大程度的执行。
持续地保证项目成员的士气非常重要。项目每取得一个阶段性的进展,必须告知全体成员,如此才能收获成功的信心。项目开发过程需要注意劳逸结合。一味地强制性加班,只能降低项目成员的工作效率。项目过程中,如能适当地开展一些活动,无疑能够让团队成员感受到项目组的集体气氛。在阶段实现的重要时刻,项目经理必须注意通过文字、语言等激励项目组成员。而项目经理的自信也是保证成员士气的一个关键。
必须注意了解团队成员的心理状态与工作状态。项目成员的战斗力除了是个人的能力发挥之外,一个好的领导也是至关重要的。因此,必须选择合适的项目组长,通过他们掌握整个项目团队成员的工作进展。同时,还要了解每个成员的能力,以安排合适的角色与岗位。
重视开发组与测试组以及项目管理小组的合作。项目组是一个整体,每个成员的角色不同,但大家都是团队的重要一员。
作者:张逸具有多年的软件开发与设计经验,他是两届微软最有价值专家(mvp),著作/译作包括《软件设计精要与模式》、《wcf服务编程》。张逸熟悉c#,asp,wcf等技术,同时深谙面向对象领域的相关技术。目前,他主要从事 soa企业信息解决方案的设计与研究,以及敏捷方法的推广与实践。张逸是捷道·敏捷堂的创始人。
导语:项目是指一系列独特的、复杂的并相互关联的活动,这些活动有着一个明确的目标或目的,必须在特定的时间、预算、资源限定内,依据规范完成。以下是我分享给大家的部分关于项目管理的一些经验,欢迎大家前来查阅!也希望文章能够给解决大家的烦恼!
项目管理经验分享企业项目管理体系建设的核心是建立企业的项目管理方法,目前,大部分组织缺乏系统的、统一的项目管理方法。在我们咨询的几家公司中,我们常常会听到这样的质疑声:一套方法怎么可以管所有的项目吗特别是IT项目,技术过程都不统一,如何用一套方法来管所有的项目,由此我们也看到很多朴素的管理方法在各个项目组织中自由成长,但在一个企业内,项目间的联系是不可避免的,相互间的协作、配合由于缺少系统的管理方法,往往顾此失彼,矛盾此起彼伏,项目经理和公司领导成为消防队员,责权不明,协调不畅, 常常陷于项目经理无法,公司管理层无奈,项目成员无所适从的状态,给项目成功实施带来了潜在的风险。是什么原因导致这样的问题呢,是否有可行的办法来解决这个问题呢
一个完善的项目管理体系建设是与企业本身的行业背景、业务领域是分不开的,出现上面的问题的根本原因就在于项目管理和业务流程的交叉,导致项目管理过程复杂化,不可控,这也就是为什么大家说一套方法不可以适用所有的项目的根本原因。
企业的项目运作包括业务流程、项目管理、技术工作三个方面,业务流程是如何运作业务,是由企业的行业特点、业务背景所决定,项目管理是如何管理项目,而技术工作则是实现项目目标所需要的技术手段。对于一个企业而言,建立企业的项目管理方法论就需要依照企业的业务流程、技术手段来设计相应的管理方法。
项目管理方法是一个结构化的方法,是可以在大部分项目中应用的方法,具体实践过程中,项目管理方法需要针对行业特点,建立适合行业特色的项目管理体系。
依照项目管理理论,项目管理过程按阶段划分为启动、计划、实施、收尾,对于任何一个项目我们都可以依此进行阶段的划分,这是项目的共性,而对于项目中的个性就是项目的业务和技术层面,对于具体的企业,项目阶段划分就需要由业务流程和技术方法决定,在实施过程中,针对具体的项目进行客户化,项目管理方法论的核心就是综合所有项目的特点,建立一套包括技术、工具、管理技巧在内的一站式服务的指南和模板。这种将项目管理方法和业务流程相互配合,并在实践中进行优化的管理方法,就是项目管理方法论。
项目管理体方法论的重要表现形式是项目管理手册,这是组织规范项目标准管理过程的重要手段,通过正确的决策、高效的流程、标准的 *** 作、可控的过程,确保项目的有效实施。
企业项目管理手册编制的基本方法可分为三个层面,一是项目管理理论知识体系,目前世界范围内比较通用的主流项目管理知识体系,包括美国项目管理协会(PMI)推出的《项目管理知识体系指南PMBOK》,英国商务部开发的项目管理方法《PRINCE2成功的`项目管理》可作为理论支撑。二是在管理方法上跨国企业实施项目的管理方法,中国著名企业的项目管理经验可作为最佳实践基础,在此基础上则是对企业本身项目管理实践经验的总结。从三个层面对企业的项目管理过程进行梳理、定义、借鉴,即可固化出企业本身的项目管理方法。
具体到项目管理手册内容就是描述项目输入转变为输出的过程。通过项目阶段过程的定义,将项目管理过程、项目实施支撑、项目监控方法及项目作业指导,系统化地与项目管理理论及产品要求融入到具体的 *** 作实践过程中。
具体包括以下主要内容:
1 项目过程控制阶段划分:通常需要考虑两类过程,一是按照项目的管理过程,对项目过程进行阶段划分;另外是按照项目的技术过程,将项目过程进行阶段划分。企业的业务流程,主要关注项目的管理阶段划分,而项目经理执行和管理项目时,必须将项目的管理阶段和项目的技术阶段划分结合起来,进行项目管理。
2 阶段输入和输出:包括数据和信息、计划和报告、风险及可以交付的成果等;
3 过程控制:包括工作流程,工作方法、 *** 作规则和作业指导;
4 角色职责:在实践中,项目管理职责,不能简单归于项目经理一个人,而是由一组角色共同完成,包括职能部门和角色对项目阶段和实施步骤的贡献。
依照项目管理方法论编制的项目管理手册,将项目实施过程中的项目管理方法与企业的业务流程、技术方法有机地集成起来,从而建立以项目管理为核心的业务流程。
不可错过的优秀项目管理者经验分享执行计划
在完成计划编写之后,项目经理需要将计划分发给每个团队成员,然后给成员提供需要的资源,由成员开始执行计划。此过程除非项目经理还兼职技术角色,通常需要做的事情不多,假如你在此阶段非常辛苦,通常是因为计划作的不够好。在晚餐项目中,因为我还兼职小工,所以比较忙,这会儿已经开始淘米、下米、洗菜、切菜等活动。
团队建设
首先,项目经理需要懂得团队发展的阶段(形成、震荡、规范、成熟),其次项目经理必须熟悉各种领导(指导、教练、支持、授权)、管理风格(民主、独裁、自由、官僚),并在合适的时机采用合适的风格。此外,项目进行中,难免出现困难、挫折和打击,团队成员的士气会低落,严重影响项目绩效。此刻,项目经理需要采用各种手段激励团队,让团队充满干劲。激励的关键有几点,第一点,要想激励别人先激励自己;第二点,必须懂得人们做事的动机;第三,要根据团队成员的特定采用恰当的激励手段;第四,在恰当的时机来激励。
在晚餐项目中,因为我们就两个人,彼此非常熟悉,所以团队震荡期非常短,形成后迅速到达规范期。启动项目时我采用了自由式的风格,大家各抒己见,来讨论各种可能性;我做计划的时候采用了民主式的风格,因为我爱人属于做饭方面的专家,民主式可以广泛征求团队成员的建议;在执行中,我采用了独裁式,严格要求我们执行既定的计划;在接近工作完成,我采用了官僚式的风格,对晚餐执行中的问题、经验、进行了记录和总结。关于激励,是每时每刻必做的事情,我爱人不断赞美我洗菜的专注、切菜技术的进步;我也时刻保持谦虚谨慎,用求知的眼神向她请教、用崇拜的目光欣赏她的成果。总而言之,我们保持了优良的团队作风,大家充满激情的、充满快乐的完成项目的工作。
管理团队
再熟悉的成员,也会有摩擦,再好的团队,也会有冲突。项目经理必须了解冲突常见原因,熟悉冲突常用解决策略(问题解决、强制、撤退、妥协、调和、合作)和使用时机,能够迅速的解决团队中出现的冲突,并且注意及时、私下、合作这些基本原则。及时就是越早越好,因为冲突开始的时候大家不会情绪化;私下就是不要在正式场合,给对方面子,不让对方下不来台;合作就是本着解决问题共同进步的态度,不是要追究谁的责任、证明谁是对的、谁是错的。
在完成项目执行期间,我和我爱人发生了二个冲突,分别采用了不同的措施进行解决:第一个,在做花生黄瓜时,我想用刀切,而不是拍黄瓜。我爱人指出来必须拍,我问为什么,她解释拍出来的味道鲜美,用刀切味道会受菜刀的影响。因为她是专家我听她的,问题得到解决;第二个,在洗菜过程中,我突然想起来需要写点东西,于是擦手计划去电脑旁边,我爱人根据计划指出来,我洗菜必须按时按质量完成。我不服还想去写东西,我爱人采用了强制的手段:如果我去写东西,这饭就不做了。我采用了撤退的策略,放弃写东西的念头,乖乖继续洗菜。
验收成果
很多人会误解,以为项目成果的验收是项目收尾的事情,其实不然,在执行过程中,可以随时对完成的成果进行验收。验收包括两个步骤,一是质量是否符合要求,二是得到干系人(通常是上级)认可。在实际项目中,得到认可非常重要,因为认可后的才可以要求付款。
在晚餐项目中,我们随时进行验收,如淘米工作完成时,我对淘完的米进行检查,我爱人进行认可;洗菜完成时,我对洗完的菜进行检查,我爱人进行认可;切好菜之后,我对菜切的大小数量进行检查,我爱人进行认可;在炒菜工作完成时,我爱人自己品尝咸淡对菜质量进行检查,我进行认可;这些都属于阶段性的成果验收。
监控风险
在项目执行过程中,项目经理需要密切关注已经识别的风险是否发生发生的风险是否应对应对的效果是否达到同时还需要识别新的风险。实践中,需要定期召开风险会议来实现上述目标。具体会议召开的次数,需要看项目的阶段、项目的规模来确定。
在晚餐项目中,因为我们识别了可能的风险,并采取了应对措施,基本没有出现新的风险。在项目执行和监控中,项目经理需要做两类事情,一是管项目,对项目绩效的管理;一是管人,对团队的管理。第一类事情比较容易,只要懂得必要的技术知识、制定了完整的项目计划,按计划进行即可。最难的是第二类,如何管理项目团队 。由于我们国家的发展背景,目前大多数企业中项目管理 者都是技术出身,对技术很熟悉,对管理很陌生。面临的最大挑战就是如何由技术到管理、如何在思想、能力、行为方面做出转变。
在此过程对项目经理的要求,知识方面需要具备心理学、领导模式、管理模式、团队规律等方面知识;能力方面需要懂得沟通、激励(当团队遇到困难时)、说服(在变更发生时)、谈判(随时随地)、领导(指明方向)、管理(协调资源)、问题解决(解决冲突、控制风险)等能力。
应对变化
在项目进行中,项目的环境可能发生变化,如此前的假设不再成立,或者因为发生了风险,项目的计划可能需要调整。变化是必然的,为了应对变化,在必要的情况下我们需要变更项目计划。这需要在项目启动时,就确定变更的流程、变更审批的组织(在大型项目中通常由高层组成变更控制委员会ccb)、变更的文档。
案例分析:软件项目管理工作经验总结
软件项目最大的特点就是不确定性。这是指软件项目不可能完全在规定的时间内,按照规定的预算,由规定的人员完成。
因为这种不确定性,导致了计划赶不上变化,也导致了平时的工作中的2种倾向:1、变化太快,索性不制定计划。2、过度强调计划,往往要将项目中非常琐碎的事情都考虑的非常清楚之后再启动项目。第一种倾向,在我做过的项目里占了2/5,都是在项目开始时制定一份计划,项目一启动就丢到一边,项目过程中完全不理会,个人能力强的PM大致还能把握方向和进度,但是问他之前做了些什么额外的工作时,往往回答不出来,等到项目结束,再把当初的计划改改,做个大概的统计也就了事。而项目过程中的一系列的常见问题也是导致项目失败的原因(以下的原因是我做过的项目中总结出来的影响最大的5点,按照影响程度的严重性,从高到低排列。)
1、项目经理的管理能力不足
项目经理的管理能力不足之所以放在第一位,我想大家都清楚原因。项目经理作为一个项目的灵魂,对于进度的把控、团队成员的组建以及积极性的调动、成本的控制、和客户的沟通、需求变更的把控、重大事情的决策。。。这些任何一个都能左右一个项目是否成功。我遇到的几个项目中都是由于项目经理的能力不够,直接导致项目失败,而且使得项目成员在项目过程中也疲惫不堪,怨声载道。其实现在很多项目的项目经理都是由技术骨干兼任,因此他们往往习惯于关注技术开发,而忽视了项目管理工作。项目,本身就是为了盈利而生,所以不排斥项目经理兼任项目技术主管或业务咨询,但是必须要有将项目管理工作区分开来的意识和责任感。如果没有这样的意识,就会造成疏忽项目计划的制定、上下左右的沟通、专业资源的分配、项目组织的调整、成本的控制、风险分析等。项目管理工作的忽视,必然导致项目失控。
2、需求不明确,变化多
需求的多变是必然的。由于用户对计算机系统认识的不足,加上一个东西的从无到有,所以往往需求开始都是模糊的,只有随着项目的发展和反复的沟通,才能逐渐的明确。如何尽早的引导客户把需求明确,是项目经理、需求分析人员的工作,是保障项目可以顺利实施下去的前提保障,它是一门技术,也是一门思维沟通艺术。需求调研清楚了不代表着万事大吉。同一个东西,不同的人有着不一样的理解。开发人员和客户之间隔着需求人员这么一层,如何把客户的意思明白、清楚、不变形的传递给开发人员,这也是大部分项目中头痛的问题。我们经常可以看到在产品开发的差不多的时候,需求、开发、测试聚在一起吵架,责任互推。
3、工作量估计过低
工作量的估计不足,会直接导致项目延期。要对每项任务,甚至整个项目给出一个合适的工作量估计,需要综合开发的技术、人员的生产效率、工作的复杂程度、历史经验等多种因素。我遇到的几个项目中,计划制订者往往是凭个人经验,个人拍脑袋给出来的,问他的凭据是什么,回答往往是个人经验,有时里面也会包含其个人对自己的自信或自尊心问题,怕给出的时间过多而显得自己能力不足。抛开这些,我们还应该注意一些平时不可见的工作量,如人员的培训时间、各个阶段的评审时间等等。制定工作量时,不能被客户给的时间期限或上级的压力所限制,否则往往是以失败结束。
4、项目团队水平不足
技术人员的水平如果不能与项目的要求相适应,对项目需求或新技术不是很熟悉,对项目的质量、成本、进度都会产生影响。当进度开始滞后,项目经理最常用的方法就是增加人手。我之前的一个项目就是如此,由于项目经理不能把握需求,需求不断的增加,于是开始不断的加班,在这种折磨中,老员工开始纷纷离开,新来的员工不熟悉,进度进展缓慢,项目经理开始大量的加人,但是对系统代码和需求的不熟悉,往往3、4个人新员工都抵不了1个老员工。于是,开始无限制的加班,在加班的折磨下,新员工又纷纷离开,于是又加人。恶性循环,项目被无限的延期。这样的项目相信大家遇到过不少。导致项目失败的因素还有很多,对于一个团队来说,一个好的管理者是一个好的开始,但并不等于项目成功。加强自身能力的提升,是每个项目管理者必须有的意识。
5、计划不充分
计划不充分,分为计划太粗或太细。制定的计划不严谨,随意性太大,会导致可 *** 作性差,在实施中根本无法遵循,也就失去了计划的作用。有的人会抛弃全局计划,采取每周制定下周的计划,这样也是不可取的,毕竟计划没有一个长远的目标或宏观上的掌控,只局限于眼前的一点点事情,往往会致使项目失控。我一般采取先制定全盘计划,再每月制定详细计划,当月快结束时,根据实际情况调整下个月的计划,这样既有了较长期的把控,也有了和项目目标的对比,同时也不会把自己陷入无止境的修改计划中。
以上就是关于解码IT项目管理全部的内容,包括:解码IT项目管理、项目管理:IT软件项目管理、《IT项目管理》总结:项目风险管理等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)