IT项目管理
第一章项目与项目管理概述
1、何谓IT
信息技术（英语：Information Technology，简称IT），是主要用于管理和处理信息所采用的各种技术总称。它主要是应用计算机科学和通信技术来设计、开发、安装和实施信息系统
及应用软件。它也常被称为信息和通信技术（Information and Communications Technology, ICT）。2、IT相关的企业
? A、IT类企业
–裁缝铺型，为客户做项目。
–服装厂型，自己做产品并销售。
–服装租赁型，运营IT服务。
核心部门盈利方式产品特点典型企业
裁缝铺型为客户做项目的IT企业中市场和技
术是两个核心部门，通常由市场部门
拓展客户
幵获得客户建设新项目的机会，然后
由技术部门实现。
主要的赢利斱式就是客
户支付的项目费（通常
承诺免费售后，但会有
升级费用）。
?早期这类企业什么行业、
什么类型的项目都做，后来
逐步収展为深挖某（几）个
行业的项目。
东软、
InfoSys等
服装厂型做产品并销售的IT企业中产品、销售
和技术是核心部门，通常由产品部门
设计出各种软件产品需求，由技术部
门研収，然后由销售部门销售给用户。
主要的赢利斱式就是客
户/用户购买产品的费
用
（可能会有售后服务
费）
软件产品一般具有通用性
特点，能够适用于大众用户
戒广泛与
业类用户。
用友、微软
等
服装租赁型运营服务的IT企业中技术、运营、营
销是核心部门，通常由技术部门研収
出各种IT服务，交由运营部门运营
，同时由营销部门推广。
主要赢利斱式就是用户
支付的服务费或广告商
等。
IT服务运营依赖于互联网
和通信网的成熟，三网合一
也将催生
更丰富的运营服务出现
百度、
等
? B、非IT企业，但IT为其核心支撑。如淘宝，网上银行。
3、项目在企业发展中的价值：
4、什么是项目?
项目[Project]是―为创造独特的产品、服务或成果而进行的临时性工作。具备如下特性：独特性，临时性，渐进明细。
5、IT项目的特征：
?目标不明确。需求变化频繁。智力密集型。
6、什么是项目管理?
项目管理[Project management]：将知识、技能、工具与技术应用于项目活动，以满足项目的要求。
7、项目管理框架：
8、项目经理：
项目经理[Project managers] 和项目发起人、项目团队及不项目相关的其他人一起为达到项目目标而努力工作。
项目经理经常会扮演领导者和管理者的双重角色
–领导者[Leader]在激劥人们达到目标时与注亍长期以及整体的目标，做正确的事情；
–管理者[Manager]关注为达到具体目标所需要的日常绅节，正确地做事情；
项目经理的价值：
9、项目经理应该具备的素质：项目管理知识（木）、通用管理素养（水）、应用领域知识（金）、项目环境（土）、软技能（火）。
10、项目管理认证：
PMI 提供项目管理与家[Project Management Professional (PMP)]的认证。
工信部信息系统项目管理师、系统集成项目管理工程师。
第二章项目立项与启动
1、项目管理的过程：
直观但不准确的项目管理过程可以理解为：立项?启动?规划?实施?监控?验收?收尾
下图显示的是真实而准确的项目管理过程：
2、识别项目机会：
项目机会通常来自于：
–客户要求–市场需求–技术进步–法律要求–社会需要–竞争对手–产品升级换代–
公司的组织结构课整
?本阶段的输出：
–《项目机会描述》或《项目立项申请》
3、分析项目机会（成果为商业论证报告）
?在发现项目机会后，需要对机会进行适当的分析研究，以决定是否需要启动该项目。通常包括如下工作：1、可能的解决方案2、进行风险分析3、估计资源需求4、分析投入和产出5、形成分析报告。
注：
、解决方案不一定是一个高投入、高技术的IT系统，关键是能解决业务问题;
、风险分析：风险是一种不确定事件或状况，如果发生将会对至少一个项目目标（如时间、成本、范围戒质量）产生正面或负面的影响。
、估计资源需求：
项目资源包括：
–人员，以及所需要的技能
–资金
–设备
–设施
–信息
–技术
在估计资源需求时，将风险因素考虑进去
这个阶段主要依靠经验做粗粒度估计，便于决策判断
D、.分析投入/产出（财务分析）净现值分析(NPV) 投资回报率分析(ROI) 投资回收期分析
E、项目生命周期与产品生命周期。项目的财务分析必须考虑完整的生命周期。
–若项目的成果是产品，则产品会有销售生命周期；
–若项目的成果是服务，则产品会有运营生命周期；
4、净现值分析
净现值[Net present value (NPV)] 分析是投资所产的未来现金流的折现值与项目投资成本之间的差值? 折现率：将未来有限期预期收益折算成现值的比率。（观点：资本的时间价值: 今天的一元钱 > 明天的一元钱）
如果财务价值作为选择项目的一个关键标准，那么组应该只考虑那些能产生正净现值的项目
仅从财务角度看，NPV越高的方案越好；
NPV计算步骤：
1、确定项目和产品生命周期以及预计的成本和收益
2. 确定折现率[discount rate]
3. 计算NPV (具体参见教材74-77页)
1. 计算折现因子：r是折现率，t是第几年
2. 将每年收益与对应的折现因子相乘后累加，减去依此算出的成本累加，即得到
NPV=∑t=0…n预计收益t/(1+r) t —∑t=0…n预计成本t/(1+r) t
4. 注意:有些组织将项目成本的投资年作为第0年，而不是第1年，并且对第0年的成本并不折现；有人以负数形式记录成本，而有些则不是。
? 注意自己所在组织采用的参数标准
净现值分析是一种适用于对跨越多个年份的项目比较现金流的方法。
实例：
5、投资回报率：
?投资回报率[Return on investment (ROI)] 是项目收益减去成本后，再除以成本的结果– ROI = (折现收益总额–折现成本总额)/折现成本总额
ROI越高越好
?许多组织都有必要回报率[required rate of return] 的要求，是最低可接受的投资回报率
?课查显示：投资项目时，约有50%的组织需要投资回报率数据
6、投资回收期分析：
投资回收期[payback period] 是以现金流的方式，将在项目中的总投资全部收回的时间。
–回收期也就是不断增长的收益超过不断增长和继续花费的成本时经历多长时间
回收期越短越好许多组织都希望IT项目的回收期尽可能短
7、形成分析报告（商业论证）
分析报告是对“分析项目机会”过程的一个总结，提交给公司管理层用来进行项目决策。
主要目的：
–应该回答“为什么我们要实施这个项目？”；
–证明此项目是经过深思熟虑的，而不是一时脑热的结果；
–分析在整个项目周期中，项目的成本和估计的项目收益；
分析报告通常包括：
–业务问题/机会描述
–可能的解决方案
–费用估计和人员投入
–项目里程碑
–风险应对措施
–其它假设前提条件
8、评估和批准项目
评估可能基于–投资/收益–项目实施周期–技术先进程度–技术复杂与难度–项目风险
9、项目启动
、任命项目经理
、干系人分析：识别所有受项目影响的人员和组织，并记录其利益、参与情况和对项目成功的影响力。注意以下原则：
1. 尽早识别干系人
2. 制定一个策略，尽可能提高他们的正面影响，降低潜在的负面影响。在项目执行期间，应定期分析和审查此策略，做出必要课整
3. 对干系人进行分类，项目经理应集中精力管理重要的干系人
干系人[Stakeholders]是积极参与项目或其利益可能受项目实施或完成的积极或消极影响的个人或组织?干系人包括:
–项目发起人[The project sponsor]
–项目经理[The project manager]
–项目团队[The project team]
–支持人员[Support staff]
–客户[Customers]
–用户[Users]
–供应商[Suppliers]
–反对者[Opponents to the project
方法：
第一步。识别全部项目潜在干系人及其相关信息
第二步。识别每个干系人可能产生的影响戒提供的支持，并把他们分类，以便制定管理策略
–权力/利益方格
–权力/影响方格
–影响/作用方格
–凸显模型
第三步。评估关键干系人对不同情况可能做出的反应或应对，以便策划如何对他们施加影响，提高他们的支持和减轻他们的潜在负面影响。
C、识别干系人输出：
?《干系人登记册》
–基本信息：姓名、职位、项目中的角色、联系方式
–评估信息：期望、对项目潜在影响
–干系人分类：内部/外部，支持者/中立者/反对者
?干系人管理策略相关的信息并纳入公开文件中。对公开的信息要注意控制其详细程度
D、确定项目发起人
项目发起人对项目的成功负有最终责任
–确保实现项目预定业务目标，解决业务问题
–责任包括：? 提供项目资金支持? 批准项目范围和所需资源? 批准变更? 任命项目经理
? 解决项目经理无法控制的问题
E、.组建项目核心团队：?项目经理需求专家软件架构师/设计专家质量（测试）专家[采贩负责人]
F、制定项目章程：
项目章程的作用：–明确项目目的–建立对项目的理解的基本共识–为项目及项目经理提供管理支持–建立项目经理的决策及领导权力
《项目章程》内容一般包括：–项目背景–项目目标–项目范围、进度和交付成果–项目经理
项目章程通常由项目经理起草，由管理层确认并发布。
G、召开项目启动大会
?项目启动会的目的：
–表示项目正式启动
–明确组织结构，并责任到人
–让高层领导，一般是老总或者副总，高调表示支持项目，并且各级领导和员工都要大力支持（这一点非常重要）
–明确项目实施计划及项目概况，让所有相关的人至少明白各自的责任，并知道这个项目是怎么回事，这为项目后期执行时，可以扫清很多障碍。
10、约束条件
约束（事业环境因素）：围绕项目或能影响项目成败的任何内部和外部环境因素
–这些因素来自任何或所有项目参与单位。
–可能提高或限制项目管理的灵活性，并可能对项目结果产生积极戒消极的影响。
–约束因素包括：? 组织结构? 政府或行业标准? 基础设施? 现有人力资源状况? 人事管理制度? 市场条件? 政治氛围? 商业数据库? 项目管理信息系统（PMIS）
11、组织结构对项目的影响
有三种基本的组织结构
–职能型[Functional]: 职能经理对CEO负责；
–项目型[Project]: 项目经理对CEO负责；
–矩阵型[Matrix]: 介于职能型和项目型之间;
? 员工通常有两个老板
? 这种结构通常分为弱矩阵、平衡矩阵和强矩阵
职能型：
项目型：
矩阵型组织结构
职能型组织结构和项目型组织结构各有优缺点，职能型组织结构的优点与缺点正好对应项目型组织结构的缺点与优点。矩阵型组织结构既有两种组织形式的优点又能避免各自的缺点
–特点：将按照职能划分的纵向部门不按照项目划分的横向部门结合起来（微软公司就是采用这种方式）矩阵型组织结构中的职责分配
–项目经理在项目活动的“什么”和“何时”方面，即内容和时间方面对职能部门行使权力
–各职能经理决定“如何”支持。
矩阵型组织结构中的责任分配
–项目经理向最高管理层负责，并由最高管理层授权
–职能部门则从另一方面来控制，对各种资源作出合理分配和有效的控制课度，职能部门负责人既对直线上司负责，也要对项目经理负责
根据项目协课人员职责不权力的大小分为：
–弱矩阵型组织结构–强矩阵型组织结构–平衡矩阵型组织结构
复合型组织结构
12、支持分析
支持因素（组织过程资产）：包括任何或全部与全部与过程相关的资产，可来自任一或所有参与项目的组织，用于帮助项目成功。
–包括正式和非正式的计划、政策、程序和指南
–包括组织的知识库，如经验教训和历史
–组织过程资产包括：
? 流程与程序–组织的标准流程、模板–变更控制程序–风险控制程序
? 共享知识库–历史信息与经验教训数据–问题与缺陷管理数据库
第三章项目规划
1、规划的价值
为了使项目成功，必须有良好的规划和控制
规划是对即将进行的实际工作的一次纸面模拟(包括规划本身的跟踪和控制)
–对各阶段做什么、怎么做、交付什么在纸面上写出来
2、计划和控制需要消耗资源，包括人力、成本和时间
项目总成本=任务执行成本+管理成本
3、九大知识领域在规划阶段的逻辑关系：（重点）
4、规划范围
规划范围回答的是“项目做什么和得到什么结果？”的问题，这是一切后续工作的前提
5、规划范围通常经过如下三个步骤：1、收集需求2、定义范围 3、创建工作分解结构。
1. 收集需求：?由需求专家主要负责，项目经理承担组织协调工作，成果为《需求说明书》，详细描述了客户的期望，包括：? 功能性需求? 非功能性需求
2. 定义范围：产品范围。由架构/设计专家主要负责，项目经理承担组织协调工作，成果为《详细设计说明书》，描述了实现需求的解决方案细节。
定义项目范围：项目范围。由项目经理主要负责，其它团队成员配合，成果为《项目范围说明书》，描述了要交付承诺的成果给客户而必须完成的所有工作。可交付成果。项目提交的最织产品（或服务、或成果）及与之相关的资料（文档等）。
3. 创建工作分解结构[WBS]
WBS的重要意义：
–项目规划与控制的手段。时间、成本、资源等只有在工作包一级进行规划和控制才更有意义; –信息沟通的共同基础。各个项目干系人对项目范围疑惑或产生分歧时，最好的沟通工具就是WBS（范围说明书太厚，不易查看 ）;
?没有WBS，就没有项目管理。
WBS详解
工作分解结构(WBS，Work Breakdown Structure)：以可交付成果为导向对项目要素进行的分组，它归纳和定义了项目的整个工作范围，每下降一层代表对项目工作的更详细定义。
?工作包, WBS最底层的组成部分。
?控制账户,高层管理人员的控制点，比WBS工作包粗得多，主要用于核算项目成本，考核项目绩效。
创建WBS
由项目经理主要负责，其它团队成员配合，主要成果为《WBS》、《WBS词典》，典型过程为：
1. 得到范围说明书；
2. 召集有关人员，集体识别和分析可交付成果及相关工作；
3. 确定工作分解结构的编排方法与结构（列表式、组细结构图式、鱼骨图式等）；
4. 自上而下逐层细化分解（80小时原则），工作包必须详细到可以对其进行估算(成本和时间)、安排进度、做出预算、分配负责；
5. 为工作分解结构组成部分制定和分配标志编码；
6. 核实工作分解和程度是必要且充分的（100%规则）；
WBS编排方法：? 按可交付成果分解按照实施过程分解
WBS词典：?WBS词典通常包括工作包描述、进度日期、成本预算和人员分配等信息。对于每个工作包，应尽可能地包括有关工作包的必要的、尽量多的信息
创建WBS的基本要求
某项任务应该在WBS中的一个地方且只应该在WBS中的一个地方出现。
WBS中某项任务的内容是其下所有项的总和(100%原则)。
一个WBS项只能由一个人责任，即使许多人都可能在其上工作，也只能由一个人负责，其他人只能是参与者。
WBS必须与实际工作中的执行方式一致(范围的另一种描述)。
应让项目团队成员积极参不创建WBS，确保WBS的一致性。
每个WBS项都必须文档化(WBS词典)，以确保准确理解已包括和未包括的工作范围。
WBS必须在根据范围说明书正常地维护项目工作内容的同时，也能适应无法避免的变更。
WBS的价值（非重点，了解）
?防止遗漏项目的可交付成果。
?帮助项目经理关注项目目标和澄清职责。
?建立可视化的项目可交付成果，以便估算工作量和分配工作。
?帮助改进时间、成本和资源估计的准确度。
?帮助项目团队的建立和获得项目人员的承诺。
?为绩效测量和项目控制定义一个基准。
?辅助沟通清晰的工作责任。
?为其他项目计划的制定建立框架。
?帮助分析项目的最初风险。
6、范围基准
?意义：确保项目不出现缩水或蔓延的重要手段；
?内容：范围说明书 + WBS + WBS词典；
?要求：所有主要干系人都签字确认；
?变更：必须遵循严格的变更管理；
7、规划时间：规划时间回答“项目做多久？何时做什么？” 的问题。通常由项目经理主要负责，其它团队成员配合，经历如下五个步骤：
7.1定义活动：?
活动。将WBS中的工作包进一步细分为更小的组成部分，是为完成工作包而必须开展的工作;
活动是开展估算、分配资源、编制进度计划以及执行和监控项目工作的基础；
活动、WBS工作包和控制账户的关系：?项目->可交付成果->控制败户->工作包->活动。
活动、WBS工作包和控制账户的关系：
通常规划时间、成本、资源的粒度至活动级，指导执行；
通常监控工作的粒度至工作包级；
通常汇报工作的粒度至控制败户级；
定义活动的成果：《活动清单》
? 分解WBS工作包为更绅致的活动，用于分配时间、资源、成本；
? 注意：在实际工作中，不需要单独的活动清单文档，活动的所有信息直接在MS Project文件中管理既可；
7.2排列活动顺序
识别和记彔项目活劢间逡辑关系。例如编码活劢应该位于单元测试活动前面；
–除了首尾两项，每项活劢都至少有一项紧前和一项紧后活动；
–为了使项目迚度计划现实可行，可能需要在活劢间加入时间提前量戒滞
后量；
紧前关系绘图法（PDM）
用方框戒矩形（称为节点）表示活劢，用箭线（表示活动之间的逻辑关系）连接活动的项目进度网络图绘制法，也称为节点法（AON，Activity-On-Node）
?PDM包括4种依赖关系戒逡辑关系：
完整的PDM节点表示法：
排列活动顺序的其它技术?确定依赖关系（?强制性依赖关系选择性依赖关系压缩进度时重点考虑外部依赖关系）利用时间提前量与滞后量，
排列活动顺序的输出：?《项目进度网络图》
7.3估算活动资源
估算每项活动所需材料、人员、设备或用品的种类和数量。常用的方法是集体认论结合自下而上估算。
估算活动资源的成果：活动资源需求。工作包中的每项活动所需的资源类型和数量，然后汇总这些资源需求，得出每个工作包的资源估算
7.4 估算活动持续时间
根据资源估算的结果，估算完成单项活动所需工作时段数–应由项目团队中最熟悉具体活动的成员，依据活动的工作范围、所需资源类型、所需资源数量，开展估算
估算活动持续时间的方法：–类比估算–参数估算
估算活动持续时间的常用技术：
A、三点估算。考虑估算中的不确定性和风险，提高估算的准确性。采用3种估算值：
–最可能时间(tM)–最乐观时间(tO）–最悲观时间(tP)
–对以上三值进行加权平均，获得估算的活劢持续时间(tE)
三点估算法中的标准差与保证率：?标准差（SD）计算公式：
B、?储备分析。在进行持续时间估算时，需考虑应急储备，并将其纳入项目进度计划中，用来应对进度方面的不确定性。–应急储备可取活动持续时间估算值的某一百分比，某一固定时间段等–随着项目的开展，可以动用、减少或取消应急储备。
估算活动持续时间的成果：活动持续时间估算。是对完成某项活动所需的工作时段数的量
化估计–可以指出一定的变化区间，例如2周±2天
7.5制定进度计划
?分析活动顺序、持续时间、资源需求和进度约束，编制项目进度计划
–确定项目活动计划开始日期与计划完成日期，并确定相应的里程碑
–进度计划必须得到批准，才能成为基准
–随着项目推进，应在整个项目期间持续修订进度计划，以确保进度计划始终现实可行滚动式规划：非常适用于不确定因素较多的IT项目规划
资源平衡：?如果已出现资源过度分配（如同一资源在同一时间被分配至两个甚至多个活动，或者共享戒关键资源的分配超出了最大可用数量或特定可用时间），就必须进行资源平衡
?资源平衡往往导致关键路径的改变
–关键路径是指网络中活动序列，该序列具有最长的总工期并决定了整个项目的最短完成时间；
–关键路径的工期决定了整个项目的工期。仸何关键路径上活动的延迟将直接影响项目的预期完成时间；–一个项目可以有多个，并行的关键路径；
进度压缩：赶工（只适用于那些通过增加资源就能缩短持续时间的活劢）快速跟进（只适用于能够通过并行活动来缩短工期的情况）
制定进度计划的成果：《项目进度计划》。包括每项活动的计划开始日期与计划完成日期
–里程碑图–甘特图–项目进度网络图
?进度基准。经项目管理团队认可并批准的进度计划
进度数据。进度里程碑、进度活动、活动属性、进度应急储备、资源直方图等
8、规划成本
规划成本回答“花多少钱及怎么花钱” 的问题。由项目经理主要负责，其它团队成员配合。基本工作包括：1、估算成本 2、制定预算
8.1 估算成本
对完成项目活动所需资金进行近似估算;项目成本的主要组成部分包括：
–直接成本。不创造项目成果直接相关的成本，例如项目成员的工资，项目使用的硬件设备、材料等；–间接成本。不创造项目成果间接相关的成本，例如企业的水电费，管理费分摊；
–储备。为应对未来的风险而预留的成本；
? 应急储备。应对部分可以预测的风险，例如外购软件的价格浮动；
? 管理储备。应对事先毫无预测的风险，例如自然灾害、法律变更等；
估算成本的主要技术：
?三点估算
?类比估算
?参数估算
?自下而上估算
?储备分析,通常直接占总成本的10-20%
?质量成本。估算活动成本时，要考虑质量成本
质量成本（CQQ）：包括在产品生命周期中为预防并符合要求，为评价产品或服务是否符合要求，及因未达到要求（返工），而发生的所有成本
估算成本的成果：《活动成本估算》《估算依据》。成本估算所需的支持信息的数量和种类，因应
用领域而异。应该清晰完整地说明成本估算是如何得出的。
8.2制定预算
汇总所有单个活动或工作包的估算成本，建立一个经批准的成本基准。
–成本汇总。以WBS中的工作包为单位对活动成本估算进行汇总，然后逐层向上汇总，最终得出整个项目的总成本
制定预算的输出：《成本绩效基准》。经过批准并按时间段分配资金的完成预算（BAC），用于测量、监督和控制项目的总体成本绩效
–是每个时间段预算之和，通常用S曲线表示《项目资金需求》。根据成本基准，确定总资金需求和阶段性（如年、季度等）资金需求
估算是决策的依据，预算是花钱的计划；
规划质量
规划质量回答“项目及项目的可交付成果做到什么程度” 的问题。由质量(测试)与家主要负责，项目经理承担组织协调工作，目的是识别项目及其产品的质量要求和标准并书面描述如何达到这些要求和标准；
IT项目规划质量的成果通常为：
–《测试计划》，详绅定义将如何实施测试过程；
–《测试用例》，详绅描述对于功能性和非功能性需求的测试标准、方法、步骤、预期成果等；
9、规划人力资源
规划人力资源回答“需要什么样的人，如何招募、管理、激励他们分工协作”的问题，由项目经理负责，其它成员配合。成果是：
–《人力资源计划》,团队的结构、角色、职责、所需技能;
–《人员配备管理计划》,团队成员的进入、培养、奖惩、离开;
组织机构图与职位描述：
可采用多种格式来记录团队成员的角色与职责，确保每个工作包都有明确的责任人，确保全体团队成员都清楚地理览其角色职责。常见的类型有：层级型组织机构、责任分配矩阵（采用责任分配矩阵（RAM）显示工作包或活动与项目团队成员之间的联系，可反映与每个人相关的所有活动以及与每项活动相关的所有人员）、文本型描述
人员配备管理计划：人员招募、资源日历、人员遣散计划、培训需要、认可与奖励、合规性、安全
10、规划沟通
规划沟通回答的是“如何交流合作”的问题，由项目经理负责，其它成员配合，制定《沟通管理计划》，主要内容包括：–需要沟通的干系人。例如发起人
–干系人对于沟通的需求。例如项目进度
–沟通信息的要求。例如进度报告
–沟通的时限和频率。例如每周一次
–沟通的负责人。例如项目经理
–信息传递的形式。例如电子邮件
–沟通所需要的资源。例如占用时间2小时
?成果：《沟通管理计划》
11、规划风险
规划风险回答的是“怎么解决计划赶不上发化”的问题，由项目经理负责，其它成员（包括客户和用户）配合，进行风险分析，制定《风险登记册》。基本工作包括：
定义：一旦发生，就会对项目目标产生积极戒消极影响的不确定亊件或条件。
风险4要素：亊件、原因、发生概率和后果
已知—未知风险：已识别，但概率和后果还丌清楚，通常用应急储备应付，例如供货商延期交货
未知—未知风险：过去从未遇到过，完全未知的风险，通常用管理储备应付，例如非典
12.1 识别风险
判断哪些风险会影响项目并记录其特征：–文档审查。–信息收集技术（? 头脑风暴
? 德尔菲技术? 讲谈? 根本原因分析。找到深层原因并制定预防措施）–核对表分析。
风险分解结构（RBS）RBS是按风险类别和子类别来排列已识别的项目风险的一种层级结构，用来显示潜在风险的所属领域和产生原因
12.2定性风险分析
评估并综合分析风险的发生概率和影响，对风险进行优先排序。
概率影响矩阵。用于评估每个风险的重要性和所需的关注优先级，根据概率和影响的各种组合，把风险划分为低、中、高风险
12.3规划风险应对
?针对项目目标，制定提高机会、降低威胁的方案和措施
消极风险或威胁的应对策略：–回避。–转移。–减轻。–接受。
积极风险或机会的应对策略：?开拓。分享。?提高。?接受。
12.4规划风险的成果《风险登记册》
12、规划采购
规划采购回答“怎么可靠地买东西”的问题，由项目经理和采购负责人负责，其它成员配合，成果为：《自制/外购决策》、《采购文件》，记录项目采购决策、明确采购方法、识别潜在卖方。
合同类型：买卖方的风险分担由合同类型决定。通常，人们比较喜欢固定总价合同，但在有些情况下，其他某种合同类型可能对项目更加有利
选择的合同类型以及具体的合同条款和条件，决定着买卖双方各自承担的风险水平
通常可把合同分为两大类，即总价和成本补偿类
总价合同：为既定产品或服务的采购设定一个总价
–固定总价合同（FFP）
–总价加激励费用合同（FPIF），例如提前1月完工给予项目总费用的1%作为奖励
–总价加经济价格调整合同（FP-EPA），适用于持续周期较长的采购
总价合同：适用于范围明确的合同，如果出现范围发化，通常也伴随着合同价格的调整
成本补偿合同：?向卖方支付为完成工作而发生的全部合法实际成本(可报销成本)，外加一笔费用作为卖方的利润
适用于工作范围在开始时无法准确定义，或项目工作存在较高的风险
采购方式：公开招标、邀请招标、议标。
规划采购的成果：自制或外购决策。采购作说明书。
13、规划整合
制定项目管理计划。
–项目总览；
–项目组织；
–管理过程计划；
–技术过程计划；
–支持过程计划；
?项目管理计划包含各项基准和子计划–范围基准–进度基准–成本绩效基准–需求管理计划–过程改进计划–变更管理计划–配置管理计划
–其它八大知识领域的管理计划
第四章项目执行与监控
1、组建项目团队：
由项目经理主要负责，招募（内外部）需要的人员组成项目团队，IT项目团队通常包括如下类型成员：开发、测试、部署、用户体验
组建项目团队的成果：所有任务分派到相应的成员；对于多项目共享成员的情况，需要标记项目成员的资源日历；
2、指导和管理项目执行
?依据计划开展具体执行工作，完成可交付成果；
IT项目执行过程中的最佳实践：流程整合持续集成每日构建其它……
项目管理信息系统：?自动化工具，如进度计划软件、配置管理系统、信息收集与发布系统等
项目范围说明书中定义的可交付成果；
–执行过程中需要不断跟踪各项重要指标（范围、时间、成本、质量、人力资源、风险等）的绩效情况，产生绩效信息；
–如果某指标的绩效出现严重偏差，就需要提出变更请求；
3、实施质量控制(软件测试)
软件测试的成果：《缺陷报告》《测试报告》
4、建设和管理项目团队
建设团队：提高工作能力、促进团队互劢和改善团队氛围，以提高项目绩效；
管理团队：跟踪团队成员的表现、提供反馈、解决问题并管理变更，以优化项目绩效；
4.1团队发展阶段：形成、震荡、规范、成熟。
4.2建设团队：
人际关系。（了解项目团队成员的感情、预测其行劢，了解其后顾之忧，并尽力帮助解决问题，可大大减少麻烦并促进合作;）基本规则。培训。集中办公。认可与奖励。（对成员的优良行为给予认可与奖励）。团队建设活动
4.3管理团队
?观察和交谈；
?典型的管理团队内容：(–澄清角色与职责；–向团队成员提供建设性反馈；–发现未知或未决问题；–制定个人培训计划；–确立未来各时期的具体目标；)
冲突管理：–解决问题–合作–妥协–缓解–强迫–撤退
权力：
参照权力、专家权力、奖励权力、合法权力、强制权力
?管理风格：
建设和管理项目团队的“成果”：
?团队绩效评价。随着项目团队建设工作的开展，项目管理团队应该对项目团队的有效性，进行正式或非正式评价–个人技能的改进；–团队能力的改进；–团队成员离职率的降低；–团队凝聚力的加强；
变更请求：主要是人员配备变更，例如把人员转派到其他任务、替换离开的成员等；
5、发布信息
在整个项目生命周期和全部管理过程中，按沟通管理计划向项目干系人提供相关信息，例如：向发起人汇报项目的进度情冴、成本情况；–向客户展示当前完成的成果；–提供各种模板给团队成员
发布信息的常见内容：项目报告项目演示资料项目记录干系人反馈意见经验教训文档
6、管理干系人期望
为满足干系人的需要而不乊沟通和协作，并解决发生的问题。
管理干系人期望的技术：人际关系技能、管理技能。?沟通方法；
管理干系人期望的成果：变更请求?更新干系人登记册?问题日志。
7、实施采购
获取卖方应答、选择卖方并授予合同。
实施采购的成果：选定的卖方；?采购合同授予；?资源日历；?变更请求；
8、监控各项指标
?范围；时间；成本；?风险；
9、控制范围
监督项目和产品范围状态，管理范围基准变更：
–控制范围的目的是为了保证项目中应该做的工作得以完成，同时保证项目团队没有在不必要的项目外工作上花费项目资源（既无镀金，也无缩水）；
–控制范围应该从WBS的最底层开始，一步一步向上整合，直到完成了整个项目；
–项目团队以项目范围管理计划为基准，结合有效的变更控制流程对项目范围进行控制；
偏差分析：
利用项目绩效测量结果，来评估偏离范围基准的程度，并决定是否需要采取纠正或预防措施：1. 分析范围偏差原因；2. 确定对既发范围偏差的态度；3. 执行纠正范围偏差的措施；
1、分析范围偏差原因
通过不责任人交谈、邀请技术专家重审实施过程、采取测试和实验等手段定义偏差发生的原因。
项目范围偏差分析可以从两方面考虑
–范围镀金或缩水；
–不达标；
2、确定对既发范围偏差的态度
3、执行纠正范围偏差的措施
控制范围的成果：
工作绩效测量结果，实际不基准的比较结果；
变更请求；
更新范围基准（+其他基准、计划）；
10、控制进度的意义
?如果不能对进度偏差进行及时有效的管理，可能会造成比偏差本身更加严重的影响。
控制进度：?
监督项目状态以更新项目进展、管理进度基准变更。包括：判断项目进度的当前状态；
对引起进度变更的因素施加影响；确定项目进度是否已发生变更；在变更实际发生时对其进行管理；
控制进度的方法：
A、项目管理软件，可直观快捷跟踪和对比迚度，例如微软的Project软件；
B、偏差分析。分析相对于进度基准的偏差原因不程度，并确定是否需要采用纠正或预防措施。–项目团队内部原因–项目执行组织的原因–客户原因–外部原因
C、进度压缩。采用赶工或快速跟进，使进度落后的活动赶上计划
控制进度的成果：工作绩效测量结果。?变更请求。项目管理计划（更新）
11、控制成本
监督项目状态以更新项目预算、管理成本基准变更。
挣值管理(EVM)（重点）：是一种常用的绩效测量方法，综合考虑项目范围、成本与进度指标，就是在既定的范围之下综合考虑进度和成本绩效；
挣值管理中的重要概念：
计划价值(PV)。截止某时点计划要完成的工作的预算价值：PV=计划要完成的工作量× 预算单价
实际成本(AC)。截至某时点实际已完成工作的实际成本：AC=实际已完成的工作量×实际单价
挣值(EV)。截至某时点实际已完成工作的预算价值：EV=实际已完成的工作量×预算单价
完工预算(BAC)：整个项目(或工作包)的成本基准，除非已批准变更，否则不能改变；
完工工期(BDAC)。整个项目(或工作包)的进度基准，除非已批准变更，否则不能改变；
挣值分析法操作步骤：
适用于仸何行业的仸何项目，操作步骤为：
1. 针对每个工作包(或控制账户)，某个时间点或分阶段(周或月) 的累计值，计算并监测3个关键指标：计划价值PV、挣值EV、实际成本AC；
2. 通过以上三个指标计算进度和成本绩效的考查指标：成本偏差CV、成本绩效指数CPI、进度偏差SV、进度绩效指数SPI；
3. 如有必要，还需进行预测，计算如下指标：完工尚需估算ETC、完工估算EAC、完工尚需绩效指数TCPI；
挣值管理法练习：
题目：某仸务的总预算成本为1000元、基准工期6周，截至今日按计划应该完成80%工作量，但实际只完成了50%的工作量，实际支出为300元，则：
PV=1000 * 80% = 800 PV=计划要完成的工作量×预算单价
EV=1000 * 50% = 500 EV=实际已完成的工作量×预算单价
AC=300 AC=实际已完成的工作量×实际单价
BAC = 1000 完工预算(BAC)：整个项目(或工作包)的成本基准，除非已批准变更，否则不能改变；
BDAC = 6周完工工期(BDAC)。整个项目(或工作包)的进度基准，除非已批准变更，否则不能改变；
CV（成本偏差）=EV-AC = 500-300=200 （成本偏差正值节约，负值超值）
CPI（成本绩效指数）=EV/AC=500/300=1.7 (实际花一元钱，做了多少钱的事，大于1好，小于1不好) SV （进度偏差）= EV-PV=500-800 = -300 （进度偏差，正值提前，负值落后）
SPI（进度绩效指数）=EV/PV = 500//800=0.625(实际进度是计划进度的百分比，大于1好，小于1不好) EAC(完工估算) =BAC/CPI=588 (重新估算完成整个项目所需要的成本)
EDAC(估计完工工期)=BDAC/SPI = 9.6周(重新估算完成整个项目的工期)
挣值管理中EV的估算方法:50/50规则：工作一旦开始，就认为已经完成了50%的工作量；而后，在整个工作全部完成后，计算另外50%；
? 20/80规则：工作一旦开始，就认为已经完成了20%的工作量；而后，在整个工作全部完成后，计算另外80%；
? 0/100规则：工作开始和执行过程中丌计算仸何工作量，在整个工作全部完成后，计算100%工作量；
控制成本的其它工具:偏差分析。?预测。随着项目迚展，可能BAC已明显丌再可行，项目团队可根据项目绩效，对完工估算(EAC)迚行预测。一经批准，EAC将取代BAC，成为新的成本绩效目标；
控制成本的成果:?
工作绩效测量结果。针对WBS各组成部分，特别是工作包与控制帐户，计算出CV、SV、CPI、SPI，并记录在案，传达给相关干系人；
成本预测。记录EAC，并传达给相关干系人；
变更请求。可能会对成本绩效基准或项目管理计划的其他组成部分提出变更请求；
项目管理计划（更新）
–成本基准（+其它基准、计划）；
12、监控风险
?在整个项目中，实施风险应对计划、跟踪已识别风险、监控残余风险、识别新风险和评估风险过程有效性：
1. 随时关注项目本身和外部条件的变化，审查以前识别出的风险是否还存在，是否又有新的风险因素出现；
2. 对新的风险因素制定应对计划，并丏补充到风险应对计划中；
3. 监视风险因素出现的征兆，及时根据风险应对计划采取预防或补救措施，并跟踪结果；
4. 根据实际情况评估应对措施的效果，并做出适当的调整；
监控风险的方法：
?A、风险再评估。定期识别新风险，对现有风险进行再评估以及删去已过时的风险；
?B、状态审查会。风险管理应该是定期状态审查会中的一项议程–项目成员可以根据自己的判断补充风险因素，最好同时建议风险缓解措施；–同时，也可以为别人提出的风险因素提供风险应对措施；
C、储备分析。在项目的仸何时点比较剩余应急储备不剩余风险量，从而确定剩余储备是否仍然合理
监控风险的成果：?风险登记册（更新）?变更请求；?项目管理计划（更新）；
13、报告绩效
收集并发布绩效信息（包括状态报告、迚展测量结果和预测情况）：
–偏差分析。事后审查，找出导致基准不实际绩效乊差异的原因。通常的步骤是：
1. 验证所收集信息的质量，确保其完整性、可靠性；
2. 把实际信息不项目基准迚行比较，确定偏差；
3. 确定偏差对项目成本、进度及其他方面的影响；
–预测方法。以截至目前的实际绩效为基础，预估未来的项目绩效；
–沟通方法。项目经理通常采用推式沟通技术来发布绩效报告；
–报告系统。便于获取、存储和向干系人发布项目成本、进度和绩效信息的标准工具；
报告绩效的成果：绩效报告。对收集到的信息进行组织与归纳，并通过与绩效测量基准比较，来分析和展示绩效。
绩效报告应该定期发布，其格式可是仅显示“完成百分比”的简报告；也可以是详细的描述报告，通常包括：? 绩效分析；? 本报告期完成的工作；? 下一报告期将要完成的工作；? 当前的风险和问题状态；? 本期批准的变更汇总；
? 预测的项目完成情况（包括时间和成本）；
变更请求；
14、实施整体的变更控制
审查所有变更请求，批准变更，并管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更的过程。包括：
–对规避整体变更控制的因素施加影响，确保只有经批准的变更才能付诸执行；
–迅速地审查、分析和批准变更请求。延误决策时机可能给时间、成本或变更可行性带来不利影响；
–管理已批准的变更；
–仅允许批准的变更纳入项目管理计划和项目文件中，以此维护基准的严肃性；
–完整地记录变更请求的影响
实施整体的变更控制的成果：
?变更请求状态（更新）
–如果变更请求可行，就批准该请求，并由“指导不管理项目执行过程”加以实施；
–如果变更请求丌可行，则否决该项变更请求，并可将其退回请求方，以便请求方补充信息；
–批准的变更实施完成后，必须经过质量部门确认，完整的变更流程才算结束；
?项目管理计划（更新）
15、核实范围
?正式验收项目已完成的可交付成果的过程：
–不客户或发起人一起审查可交付成果，确保可交付成果已圆满完成，并获得客户或发起人的正式验收；?核实范围的方法：检查。开展测量、审查不核实等活动，来判断工作和可交付成果是否符合要求及产品验收标准；
核实范围的成果：验收的可交付成果。符合验收标准的可交付成果应该由客户或发起人正式签字批准；变更请求。
第五章项目收尾
1、组织过程资产：?组织过程资产：仸何不项目过程相关的资产，可来自所有参与项目的组织，用于帮助项目成功。
–组织过程资产包括：
? 流程与程序
–组织的标准流程、模板
–变更控制程序
–风险控制程序。。。
? 共享知识库
–历史信息与经验教训数据库
–问题与缺陷管理数据库
2、项目收尾阶段的重点工作
1. 达到项目完工或退出标准，主要是客户验收确认；
2. 向客户（或运营部门）移交项目的产品、服务或成果；
3. 收集项目或阶段记录、收集绊验教训和存档项目信息（供组织未来使用）；
4.客户满意度调查；
5. 项目后评估。在财务部门和项目管理办公室的支持下，审查项目关键指标是否达到公司的预定目标，如利润率；
6. 项目客户报告大会，和客户、项目团队等一起回顾总结项目的实施过程和结果；
7. 颁布项目结束通知书，项目团队解散；
3、项目交接
项目完成后，由售后维护（或内部运营）部门接手后续工作，项目团队必须不其共同进行正式的交接工作，提供相应的交接文件；
交接工作一般包括以下内容：
–项目团队成员名单及联系方式；
–客户联络名单和联系方式；
–分包商名单和联系方式；
–项目介绍，包括总体结构、配置情况、软件版本等；
–项目验收测试结果报告；
–项目遗留问题、承诺解决日期和负责人；
4、团队内部总结
?方式：
–请项目成员以署名或匿名的方式填写项目绊验总结表；–项目绊理一对一不成员交流，听叏他们对项目的宠观评价和未来项目的建议（注意：多听少说，不做仸任何辩解和解释）；
–召开团队集体的内部总结会议，鼓励畅所欲言；
内容：
–总结本项目数据，形成对新项目估算的依据；–总结实施过程中出现的问题；
–总结流程的作用和改迚建议；–总结关键的成功因素
5、客户满意度调查
目的是了解不足，而不是得高分。?调查内容应该包括：质量、性能、性价比、服务质量、技术支持等方面；
6、项目后评估
A、项目完成情况的评估。主要评估项目结果是否达到了公司管理层对项目的预期目标。以项目管理计划为依据，通常要包括对项目的范围、迚度、质量、成本等方面的评估；
B、对项目绊理和项目团队成员的绩效评估：
7、项目客户报告大会
作为同客户的最后一次正式沟通会，也可以以项目庆功大会的形式进行。这种方式，可以巩固和加强宠户的友好关系，为将来的合作打下良好基础；
参加者包括：客户方管理层、客户方项目绊理和参不过项目的其他客户方人员；项目实施方的管理层、项目绊理、团队成员、销售经理等；
?主要议程包括：
–双方管理层(项目经理)总结项目，肯定成绩，提出不足，并感谢对方的配合；
–项目经理总结项目实施的过程和结果；
–表彰双方有贡献的人员（兑现各种奖励）；
–向客户介绍项目交付后的售后服务流程、主要负责人和联系方式；
–感谢客户并提出希望继续合作的意向；
8、颁布项目结束通知书，解散项目团队
9、结束项目或阶段的成果
A、最终产品、服务或成果移交；
B、组织过程资产（更新）：–项目档案。–项目收尾文件–历史信息
10、结束采购
?完结项目采购–需要确认全部工作和可交付成果均可验收；
–包括一些行政工作，例如：处理未决索赔、更新记录、把信息存档等；
结束采购的主要工具和技术：采购审计、协商解决。
结束采购的成果：?1、买方向卖方収出关于合同已绊完成的正式书面通知；
2、组织过程资产（更新）–采购文档；–可交付成果验收；–绊验教训文档；
IT 项目管理经典案例
1、拯救项目团队 徐家龙最近被公司任命为项目经理，负责一个重要但不紧急的项目实施。公司项目管理部为其配备了七位项目成员，这些项目成员来自不同部门，大家都不太熟悉。徐家龙召集大家开启动会议时，说了很多谦虚的话，也请大家一起为做好项目出主意。一起来承担责任，会议开得比较沉闷。 项目开始以后，项目成员一有问题就去找项目经理，请徐经理给出意见，徐经理为了树立自己的权威、表现自己的能力，总是身体力行；其实，有些问题项目成员之间就可以互相帮助，但是他们怕自己的弱点被别人发现，作为以后攻击的借口，所以他们一有问题就找项目经理，其实徐经理的做法也不全对，成员发现了也不吭声，因为他们认为我是按你说得作的，有问题你经理负责。 团队成员之间一团和气，“找徐经理去！我们听你的；成为了该项目团队的口头禅，但是随着时间的推移，这个貌似祥和团结的团队，在进度上很快就出了问题。该项目由重要但不紧急的项目变成了重要还紧急的项目！ 项目管理部意识到问题的严重性，派高级项目经理张一峰指导该项目的实施。 1.1问题 问题出在哪儿？ 张一峰怎么做？
2、C公司的变更管理 C 公司是一家主要为交通部门从事系统集成业务的公司。 2007 年 3 月底该公司承接了 L 市数字指挥系统的建设工作，公司任命王莽为项目经理。合同金额 300 万交付日期为 7 月 1 日。 王莽组建完团队后，召开了内部的项目启动会议，宣布 4 月 1 日正式开工；大家干劲很高；王莽带领项目团队绘制了项目的生命期模板，分解得到了项目的 WBS ，在此基础上得到了项目计划，然后团队严格按照项目计划执行。a 很遗憾的是：很快项目团队就发现所需的采购设备的项目资金，被公司挪作它用不能及时供给资金。另外这时交付给客户X 模块，虽然用户签收了，但是客户认为项目团队没有领会好他们最急需的需求，希望他们在 4 月底前尽快完成 Y 模块的工作。而项目团队的计划是在 5 月底完成 Y 模块，王莽认为这是客户的变更，需要填写客户变更申请书，客户不承认这是变更，于是引起争执也未填写变更申请书。b 项目团队努力按照计划继续执行，但发现计划越来越难执行；交通部门的意见越来越多，王莽底下的成员看见项目经理已经与客户闹矛盾了，为了缓和关系底下的几个成员；开始不情愿地接受客户的意见，认为能随手改的就改了。公司认为这样作是对的，有助于提高客户满意度，这样到 5 月初时项目计划已经形同虚设。c 随着项目的进行，王莽和项目成员变成了救火队，用交通部们的话说是很好指哪打哪；但是王莽和项目成员发现：自己已经疲于奔命，客户的需求追加了不少，随意的变动也很多。甚至交通部门有的用户上旬说这么改，中旬说那么改，到了下旬说还是上旬作的对，改回去吧！王莽认为这样做下去，自己累死不算，利润率肯定为负数，结局是不讨好的。于是王莽和几个骨干在 5 月底，宁愿不要当月薪水，先后辞职离开了公司。 2.1问题 怎么回事？王莽、管理者各有哪些错误？分步骤的应对措施是什么？ A、启动阶段 B、矛盾初起(争执未起) C、计划形同虚设。
IT项目实施与管理方案-投标书
1.1项目实施与管理 1.1.1项目实施方法论 针对南京银行企业服务总线系统项目，高伟达公司基于对客户需求、业务目标、业务能力和IT环境的理解，结合多年的软件开发和系统实施经验，将项目的实施周期划分为六个活动阶段，保证在项目生命周期内，应用合理的项目管理和控制技术。通过专注于使客户投资回报最大化，和使客户的投资风险最小化的关键战略和战术领域，加快项目实施速度，使得项目成功地完成。这些阶段的特性是可循环往复性，使客户可以尽快地获得新的应用系统所带来的好处。 1.1.1.1项目定义阶段 在这个阶段, 所有与分期实施相关的项目活动都被明确定义, 项目的"项目利益相关者"被指定，项目经理和客户项目经理的角色和职责被传达给所有的"项目利益相关者"。管理项目所需的项目控制结构被定义,所有需要的项目规划文件被创建, 客户的业务问题和被用来衡量项目成功的衡量标准被确认。 制定解决方案范围，在一个高级别上定义哪些模块将被实施，估算预期需要的客户化程度, 以及勾画出在产品之外需要开发的内容和要提交的技术成果。解决方案范围文档包括解决方案范围概述, 功能范围, 流程范围, 客户化问题, 其他风险, 外部依赖条件以及假设。这个工作为未来项目决策, 统一或达成"项目利益相关者"之间就有关项目参数的共识，提供书面的文档。它阐述以SOW为基础的业务需求，并且把它转化成产品模块实施信息。 简而言之, 这个阶段组建项目团队，保证客户实施项目的成功。公司人员与客户人员一道，组建项目团队, 设定项目方法和范围，并建立项目管理控制。主要交付的成果有，解决方案范围和项目管理控制。制定了项目质量检查计划。 1.1.1.2需求分析阶段 在需求调研阶段, 在项目管理小组的指导下, 由公司和客户组成的统一的项目团队将识别并且书面记录在开始设计客户解决方案之前所必须弄清楚的，需
IT项目管理读后感
李沙沙0906014 老师推荐给我们看的几本书让我受益匪浅。特别是《你的灯亮着吗?》。看进去之后方才知道老大的用心良苦，自己在处理工作 中的事情时，不管用户是非对错，用户提出问题，我的思想老是照着用户的问题去解决问题。在这本书中针对我目前的情况有详细的解析。 这些书带给我的启发不仅仅是关于高级IT项目管理这门课程的，也给我今后的人生上了重要的一课。正如项目经理案头手册中提到的J.M.朱兰将一个项目定义为一个计划要解决的问题。该定义使我们认识到，项目管理是在大的规模上对问题的处理。我们生活中也在不断的遇到各种各样的问题，在进行项目管理的过程中，随着工作的进展，也给我们生活中解决问题指明了一条正确的思路和方法。项目问题就是人的问题，这些书启发我们在做事的时候不要怨天尤人，惟有付之行动，生活才会回报付出者；没有计划，就没有控制；要积极主动，不要被动反应；承担责任，争取权力；所有的行为只有从执行者的视角来理解才有意义；人最害怕的是被拒绝，最需要的是被接受；沟通技能是项目经理最应具备的技能之一。 书中有说到一句：“问题其实就是你期望的东西和你体验的东 西的差别”。对于我工作中，用户正常使用TAJIMA的流程，就是我期望的东西，而体验到的东西都是，用户不按正常流程执行。问题就在于，用户更本不按流程走。而对于用户来说：用户期望的是可以直接改个供应商或直接改个单价就可以满足采购或财务的需要，而体验到的是在系统中供应商无法更改，单价在采购单更新后，财务部那边的出入库金额数据无法更新。所以用户的问题就是：采购单无法更新供应商，单价更新了无法满足财务的需要，怎么办？到
底是谁的问题？当出现这种情况，我往往把用户的问题定义成了问题。想尽方法帮用户解决。书中还有说到：“在寻找问题定义的道 路上疲倦地游荡时，不要忘记随时都回头看看，看看你是不是已经 迷路了”，在工作中我经常帮用户想解决方法，哪种解决方法对于 用户目前是最简单的？回头想想，有的时候真的帮用户解决到问题吗？没有！因为我在找解决方法的过程中，已经错误的定义了我在 解决的问题。用户入库拒收的库位选错了，入错了库位。我首先将 问题的定义为：将入错库位的数据调整至正确的库位。一股脑的想 如何去调整，用哪种调整方案最简单？结果表面上是以经解决了， 可过不了多久此类情况又会发生。其实遇到这种问题应该先想想， 库位选错的原因是什么，是不是之前的培训没有到位？如何杜绝这 种情况再次发生？现在该做些什么？应该教会用户在开单时就先确 认库位。如在开单时就选错库位就点选取消，重新开过单据。还有 一次，财务部提出采购部在采购单上更新了价格，但出入库记录的 金额还是没有，希望我们帮忙解决。我首先想到的就是帮财务部将 采购单上更新的价格导出给财务部，方便快速。但没有想到问题的 起源是：采购部在入仓之前没有输入价格，而要在入库之后才补上，导致现在这种问题。要解决这个问题的方法是让采购部在入仓之前 就把价格填上，在入库的时候就会自动获取价格，而不是给财务部 导出价格。 书中有个章节“什么是真正的问题？”里面有指出：“每种解 决方法都会带来新的问题”，回想过去的工作，的确存在很多问题 解决之后，产生了更大的问题。针对这种现象,书中指出：“问题最难以处理的部分恰恰是去意识到它们的存在”,因为用户养成的习惯，
文件1《IT项目立项流程》
IT项目立项流程 信息管理部 2004.4
目录 前言 (3) 一、中外运IT项目的分类 (4) 二、IT项目的立项流程 (5) 2.1项目评估小组 (5) 2.2立项流程 (6) 2.2.1 第一类项目立项流程 (6) 2.2.2 第二类项目立项流程 (6) 2.3 立项报告的要求 (7) 2.4 立项过程中的IT投资管理要求 (8)
前言 中外运对IT的投资是通过各种类型的IT项目来实现的，通过实施IT项目体现对IT投资的效果，因此有必要对IT项目制定相关的流程和规范。IT 项目分为两个阶段：立项阶段和项目实施阶段。本文只涉及立项阶段的流程，项目实施阶段按照《IT项目管理办法》执行。 本流程的适用范围为股份公司总部。
一、中外运IT项目的分类 1.项目：在规定的时间和预算内完成的某种具有特定质量性能要求的 一次性、多任务的工作。 2.中外运IT项目分类如下表所示。 表IT项目的分类
二、IT项目的立项流程 中外运的IT项目分为两个阶段：立项阶段和项目实施阶段。本文只涉及立项阶段的流程，项目实施阶段按照《IT项目管理办法》执行。 立项阶段需要明确：项目评估小组、立项流程和立项报告。 2.1项目评估小组 项目评估小组成员： ●组长：公司主管领导。 ●成员：企划部、财务部、运营部、信息管理部等部门的总经理或 副总经理及涉及到的相关部门的负责人员。 项目评估小组的职责： ●对项目是否符合公司的业务发展战略进行评估；对投资的可行性 和风险进行分析；评估项目预算。 ●对项目可能遇到的技术风险和障碍进行分析；对IT技术和IT管 理的提出意见和建议。 ●对业务需求进行确认。
It项目管理概述
第一章项目管理概述 学习目标 1. 解释什么是项目，并且举出信息技术项目的具体例子 2. 了解项目管理与其他学科的关系 3. 了解项目管理的发展历史 4. 认识不断增长的对项目管理――特别是信息技术项目管理――进行改进的需要 5. 知道什么是项目管理，论述项目管理基本框架的关键因素 6. 初步了解项目管理资格认证 1.1 简介 项目管理的好处： 1. 控制财务、资源 2. 改进客户关系 3. 缩短开发时间 4. 降低成本 5. 提高利润、生产率、产品质量和可靠性 6. 完善公司内部协调 1.2 什么是项目 项目是为完成某一特定的产品或服务所作的一次性努力。其属性定义如下： 1. 有一个独特的目的 2. 项目是一次性的
3. 项目需要使用资源，例如人、硬件设施、软件配置 4. 项目要有一个主要发起人或者客户 5. 项目具有不确定性 三约束：范围、时间、成本。 范围λ 项目的任务是什么？发起人要通过项目获得什么样的产品或服务？时间λ 项目需要多长时间？进度如何安排？ 成本λ 项目需要花费多少？ 1.3 什么是项目管理 项目管理是指“在项目活动中运用专门的知识、技能、工具和方法，使项目能够实现或超过项目干系人的需要和期望。” 项目干系人是指参与项目和受项目活动影响的人，包括项目发起人、项目组、协助人员、顾客、使用者，甚至项目反对人。 知识领域是指项目经理必须具备的一些重要的知识。项目管理中四大核心知识领域是：范围、时间、成本和质量。 第二章项目管理的环境和过程 学习目标
1. 系统了解项目管理基期如何在信息技术项目中得以应用 2. 解释项目生命周期的4个一般阶段 3. 区别项目开发和产品开发的不同之处 4. 运用4种组织形式分析一个正规的组织 5. 解释功能性、矩阵型和项目型组织结构的不同点 6. 列举一个优秀的项目经理应该具备的技能和素质 7. 描述项目管理的5个主要过程组，一般情况下各个过程组的活动水平及相互关系 8. 对项目过程组与项目管理知识的关系有一个初步认识 2.1 项目管理的系统概念 以整体的视角看待项目和项目运营的组织环境就是所谓的系统思维。系统方法是解决复杂问题的一种整体分析方法，包括系统观念、系统分析和系统管理。 系统观念是支一整套系统的思考事物的思维模式。 系统分析是一种问题的解决方法。这种通过确定问题的研究范围，将其分解为各个组成要素，然后识别和评价各要素存在的问题、机会、
软件项目开发管理流程
研发中心项目开发管理流程 1，新项目开发管理流程 按照项目管理规范，项目管理分为：项目启动—》项目计划—》项目执行—》项目控制—》项目结尾。5个阶段。根据该管理流程和我公司实际情况，将新项目开发的管理流程制定如下图：
1.1 项目立项 项目立项阶段，首先由的项目经理编写《项目立项报告》。研发项目立项报告模板.doc 1.2 立项评审 《项目立项报告》编写完成后，交由项目管理委员会进行立项评审，评审通过后由副总经理签字确认立项。确定需求分析和项目设计阶段的时间和人员安排。 1.3 需求分析 需求分析阶段，需要与用户交流，双方对软件需求取得共同理解基础上达成 的协议。编写并完成软件需求说明书：也称软件规格说明书。软件需求说明书模 板 .doc 1.4 系统设计阶段 常规的系统设计需要依次完成《概要设计说明书》，《详细设计说明书》。以下是文档的简要说明： 概要设计说明书：该说明书是概要设计阶段的工作成果，它应说明功能分配、模块划分、程序的总体结构、输入输出以及接口设计、运行设计、数据结构 设计和出错处理设计等，为详细设计奠定基础。概要设计说明书.do c 详细设计说明书：着重描述每一模块是怎样实现的，包括实现算法、逻辑流程 等。详细设计说明书.do c 详细设计说明书编写完成后，项目经理应该依次编写安排项目开发工作计划。工
作计划安排可以根据项目经理的习惯进行工作计划编写。建议采用project 。附 件为综合考务平台的工作计划安排，可以供参考： 考试考务综合管理平台工作计划.mpp 。并且确定里 程碑，以便在后期项目执行过程中，对其进行确认。 对于大项目，建议按照项目设计流程，先进行概要设计，再到详细设计。但 是对于特殊项目（项目周期较短，小项目），可以讲概要设计和详细设计阶段合二为一，编写功能，接口方案。但是值得注意的是，该方案中，仍然需要涵盖项 目模块功能，用户权限和各模块实现逻辑，接口等。 项目设计开发方案. docx 。 1.5 项目设计评审 设计阶段完成后，项目经理填写《项目设计评审表》，将相关文档交由项目 管理委员会进行项目设计评审。通过评审后，方可进行编码工作。 项目设计评审表.do cx 1.6 编码和测试用例编写阶段 项目编码阶段，项目经理需要对项目执行情况进行控制和监督，其中包括（项 目输入，项目输出，里程碑）。如果由于特殊情况，如：需求变化，人员临时调配，或者其他原因导致的项目范围和时间，计划等变更，项目经理应该及时填写变更申请。并提交给项目管理委员会。作为之后项目输出验证的重要依据 项目变更申请书.do c 。 在此阶段，测试人员应该根据《需求说明书》，《概要设计》和《详细设计说 明书》的内容，编写相应的《测试用例》。
企业IT项目管理办法
企业IT项目管理 对一个IT项目来讲最重要得部分就应该就是项目得启动阶段，项目只有真正启动了才谈得上IT项目得管理方法与技巧，项目启动阶段准备得充足与否往往决定着一个项目得成败，所以对项目启动管理形成统一得认知，对于甲方实施IT项目来说有着非常重要得意义。一般来说，项目得启动管理可以划分为以下几个阶段： 一、意向提出阶段 在意向提出阶段，业务部门发现需要由信息化手段来实现得业务需求，并提出建设信息化系统得期望。由于信息化项目得意向伴随着业务发展得全过程，因此，对于意向得统筹管理与规划对企业得信息化部门始终就是一个难题。 对于有集中业务规划期间得企业，意向得产生经常集中在业务规划期间，比如：财年末，业务对自身得模式进行盘点期间，往往产生业务模式得改进或改革得需求，从而对信息化工具产生需求。在这一时间产生得想法或需求，往往不就是很成熟，不确定性很大，后期变化得风险也很高。但这一时期，也就是意向最集中，最易于统筹规划得时期。信息化部门通常在这一时期，对所有得意向进行收集，分类整理，初步形成项目建设清单。并考虑公司战略重点与资源投入得约束，对项目进行排序，以确定建设重点。 对于不在集中规划时期提出得项目意向，正如案例中出现得一样，往往会影响到原有得整体规划与计划，各方面得论证更应谨慎，比如，项目得必要性、投入得合理性、资源到位得可能性，对已建与在建系统得影响等等。信息化管理部门可以通过建立一些制度与流程，对业务需求得意向进行引导，尽量使意向在集中规划时期提出。 意向提出作为项目启动得一个阶段来管理，其意义就在于：对意向进行统筹规划，保证系统建设得整体合理性。 二、需求分析阶段 在受理了项目得意向以后，就进入对项目需求得分析阶段。这一阶段需要有信息化人员与业务人员组成得小组，对业务需求进行详细得调研与分析。采用得方法主要包括各业务层次人员访谈、会议。 在这一阶段，往往出现案例中得情况，信息化人员可能认为业务得需求不清晰，而业务认为自己得需求已经十分清晰。解决这个矛盾得关键在于，要有详细得管理控制方法，引导业务人员进行需求得细化。如，制定需求分析报告得框架，针对关键点形成文档。一般来说，需求分析包括以下内容： 当前业务流程分析、未来业务流程分析、当前业务与未来业务得差异分析、信息化功能点需求、对将来系统得非功能需求，如：性能需求，环境需求，安全需求等、需求得优先次序、需求分析报告形成以后，还需要组织对需求得评审，以达成项目关系人对需求得一致认可。
IT项目管理办法2019
信息系统项目建设项目管理文档 1.项目管理 1.1项目范围管理 （1）概述 项目范围管理就是要明确项目目标是什么，界定哪些工作必须做，并将项目目标分解到可以独立分包的程度，形成工作分解结构（WBS），并以此作为控制项目范围变更的基准。即项目范围管理是确保项目包含且只包含项目所必须完成的工作。 很多项目经常由于有做不完的报表、解决不完的问题而导致项目无法验收，很大一部分原因就是因为项目的范围没有定义清楚或者项目范围经常发生无可控制的变更所致。事实证明，缺少正确的项目范围定义和范围的核实是导致项目失败的主要因素。 因此，项目管理最重要的也是最难做的一项工作就是确定项目范围，并使项目范围在控制中，这就是项目范围管理的范畴，即项目范围管理就是项目该做什么，不该做什么，以及确保该做的事情必须做到，不该做的事情不能做。 在项目的规划阶段和蓝图设计阶段的前期，我们通过售前阶段的资料和项目现场的需求调研，确定项目该做什么，这就是经常说的定义项目范围。 （2）管理内容 1、定义项目范围 1）定义项目范围重要的参考资料和依据一般如下： ●项目售前实施方案； ●项目主合同； ●许可软件通用条款及清单； ●咨询实施服务和工作任务书； ●支持服务条款；
●战略合作承诺书； ●建设单位内部正式发问的项目实施意见书。 2）口头承诺 定义范围除了依据上述可见的项目资料外，售前阶段的一些口头承诺也是定义项目范围的重要信息来源，因此在项目准备阶段与售前进行内部交接时，一定不能忘记交接口头承诺的内容，实践证明，口头承诺的往往是在项目实施过程中难以交付的或者需求范围不好清晰界定的，正是范围管理的难点。 通过范围定义，可形成详细的范围说明书，以及对项目管理计划进行更新。 2、项目范围 范围是指项目所提供的产品或服务的总和，它包括以下两种含义： ●产品范围：产品或者服务的特性与功能，其衡量标准为产品要求，即产 品需求说明书。 ●项目范围：为交付所需产品（具有特定属性和功能）和服务而必须完成 的工作，其衡量标准为项目管理计划、项目范围说明书、WBS及WBS词汇 表。 项目实施的产品范围的描述一般应该通过两个维度，即产品功能模块和公司范围两个维度，清晰的描述出哪些公司具体实施、哪些产品的功能模块，对于集团型企业一定要以企业法人作为实施的公司范围。借用EXCEL建立功能模块与法人公司的二维表格来描述项目实施范围更加清晰。 3、工作分解结构 1）工作分解结构概念 项目实施过程中，最能清晰描述和界定项目范围的工具是工作分解结构（WBS），这是一种以结果为导向的分析方法，用于分析项目所涉及到的工作，所有这些工作构成了项目的整体范围。也是制定项目管理计划重要的基本文件，因为它是制定和管理项目进度、成本和变更控制的基础。一些项目管理专家认为，未包含在WBS里的工作是不应该做的。 WBS通常被表示为一个以任务为导向的活动家谱图。通常围绕项目产品或者项目阶段展开，我们公司实施方法论已经把信息实施项目的实施过程划分了五个阶
IT项目管理案例一个具体例子解答
项目管理综合案例分析 1.项目背景 东方建筑设计院一直采用人工进行档案管理工作，档案管理人员经常报怨劳动强度大，效率低下，为节省人力和财力，节省借阅人员的等待时间，设计院决定引入计算机管理，拿出专项经费，委托软件开发公司开发一套功能齐全的档案管理软件。 于是在2010年3月，在院长的指示下，由档案室牵头，项目管理专家参与，起草了一份《东方建筑设计院档案管理软件开发项目需求建议书》（即招标书），并在报纸上公布。在需求建议书中，给出了以下主要信息：东方建筑设计院向软件开发承约商征求档案管理软件开发；承约商必须最迟在2010年4月30日前向东方建筑设计院提交《东方建筑设计院档案管理软件开发项目申请书》（即投标书）；东方建筑设计院将在5月15日前选中一家承约商；该项目完成的期限为6个月，从7月1日到12月31日，所有的交付物必须不迟于12月31日提供给东方建筑设计院；合同必须以一个商定的价格，向满足建议书要求的承约商付款。 多家软件开发公司在报纸上看到项目需求建议书后，纷纷编制申请书，并寄发给东方建筑设计院。最后，亚华软件开发公司经过激烈竞争，以35万元的价格承接了此项目。亚华软件开发公司经过研究，决定由张强出任此项目的项目经理。 2.项目章程 2.1项目名称：开发一套功能齐全的档案管理软件 2.2项目重要性： ◆节省人力和财力，提高档案管理人员的工作效率 ◆节省借阅人员的等待时间 ◆有利于提高建筑院的核心竞争力
2.3项目目标 总目标：为东方建一套筑设计院开发一套劳动强度小，效率高，节省人力和财力，节省借阅人员的等待时间的工作方法 分目标：开发一套20用户、运行在Windows98版本以上功能齐全的档案管理软件 2.4项目主要可交付成果 交付物：东方建筑设计院档案管理软件、软件文档、用户手册（修改）2.5项目经理及职责 项目经理：张强 项目经理的职责：计划并执行整个项目，同潜在用户进行交流，需求分析，界面设计 2.6主要项目主要干系 主要内部干系人：吴斌、刘丽 主要外部干系人：谢红、张辉 2.7项目总体进度计划及主要里程碑 项目开始时间：2010年7月1日 项目结束时间：2010年12月31日 主要里程碑安排： 2010年7月1日~2010年7月10日：方案设计 2010年7月11日~2010年7月20日：用户需求调研 2010年7月21日~2010年12月10日：软件开发 2010年12月11日~2010年12月31日：BETA测试 2.8项目总体预算 项目总体预算：35万元以内 2.9各职能部门应提供的配合 1.设计院项目领导和负责人能及时处理工程建设过程中遇到的问题，无相互推诿，延时响应等延误工期的情况发生。 2.能及时向上级部门上报工程建设进度及建设过程中遇到的问题 2.10项目审批要求：符合讨论中的标准 2.11章程的批准
IT项目管理案例及解答
IT项目管理案例及答案 案例10 如何启动项目 海正公司的赵晓东最近心里挺烦。公司前一段签了一个100 多万的单子，由于双方老板很熟，且都希望项目尽快启动，在签合同时也没有举行正式的签字仪式。合同签完，公司老总很快指定赵晓东及其他8 名员工组成项目组，由赵晓东任项目经理。老总把赵晓东引见给客户老总，客户老总在业务部给他们安排了一间办公室。项目进展开始很顺利，赵晓东有什么事都与客户老总及时沟通。可客户老总很忙，经常不在公司。赵晓东想找其他部门的负责人，可他们不是推托说做不了主，就是说此事与他无关，有的甚至说根本就不知道这事儿。问题得不到及时解决不说，很多手续也没人签字。项目组内部问题也不少，有的程序员多次越过赵晓东直接向老板请示问题；几个程序员编的软件界面不统一；项目支出的每笔费用，财务部都要求赵晓东找老板签字。赵晓东频繁打电话给老板，其他人心里想，赵晓东怎么老是拿老板来压人。由此，赵晓东与项目组其他人员和财务部的人员产生了不少摩擦，老板也开始怀疑赵晓东的能力。赵晓东的遭遇相信很多项目经理都亲身经历过，尤其是刚刚开始做行业客户的公司，往往是公司的老板和客户单位的某个主管关系不错或业务人员关系做得很到位，公司老板希望赶紧做完项目，因此，常常跳过项目启动环节，直接指令项目经理进入实施阶段。结果项目刚开始就麻烦不断。参考讨论题：参考讨论题： 赵晓东遇到了什么问题？内部问题：赵晓东遇到了什么问题？内部
问题： 1、项目内部成员越过项目经理直接请示老总； 2、项目内部人员对建设标准出现不统一情况； 3、项目支出财务部要求赵经理找公司老总签字。 结果：结果： 1、项目组成员、财务部人员与赵经理产生摩擦； 2、公司老总怀疑项目经理的能力。 外部问题：外部问题： 1、什么事情都与客户老总沟通，但老总很忙； 2、客户部门负责人推托，手续没人签字。 结果：结果： 在客户端的工作无法正常开展。 做项目启动的目的是什么？做项目启动的目的是什么？建立项目管理制度、整理启动会资料等。1. 项目启动会的任务有哪些？项目启动会的任务有哪些？ 阐述项目背景、价值、目标；项目交付物介绍；项目组织机构及主要成员职责介绍；使双方人员彼此认识，清楚各个层次的接口；项目初步计划与风险分析；项目管理制度；项目将要使用的工作方式。2. 3. 在项目启动时应该注重哪些问题？在项目启动时应该注重哪些问题？为什么说“好的开始是成功的一半” 为什么说“好的开始是成功的一半”？做项目启动是为了形成一个良好的沟通体 系，让所有与项目相关的人都理解项目的重要性，同时形成一个由双方
互联网IT行业项目管理规章制度守则
精心整理 互联网IT 行业项目管理制度 一、制度目的 为规范项目研发、加强项目管理，保证信息系统符合业务一致性、内控合规性、系统稳定性、系统安全性，使我公司新产品开发能够严格遵循科学管理程序进行，板。四、主要角色及职责
（1）需求申请人提交《产品需求申请单》（详见附件1）至业务归管部门进行业务评审，评审通过后，报至产品技术中心。 （2）产品技术中心根据产品需求进行分析，形成评审报告进行内部评审，评审通过后列入部门工作计划，并提交至公司中高决策层。评审报告内容主要包括预计工作量和成本、风险、可行性分析等（详见附件2：《产品需求文档（PRD）模板》）。
（二）立项管理 经评审确认后的产品需求由产品技术中心提交公司中高决策层，讨论通过后立项。 （三）项目计划与监控 对于产品需求，软件开发采用项目形式管理，项目经理负责整个项目的计划、 形成《评 5.对已确认的系统设计进行修改，需项目经理及技术组负责人及测试负责人审批。 （五）系统实现 1.系统实现包括程序编码、单元测试和集成测试。
2.在系统实现时保证开发、测试和生产环境独立，为各环境建立访问权限控制机制，并明确项目成员的职责分工。对生产环境、测试环境与开发环境在物理或逻辑方面应该做到隔离。 3.项目组进行单元测试和集成测试，出具《单元测试报告》、《集成测试报告》和《系统测试用例》，测试人员签字确认测试结果（详见附件3：《×××系统_测 1.网络运营中心根据项目规模及影响决定试运行策略。 2.研发事业部组织制定《试运行计划》并提交网络运营中心审批。 3.研发事业部进行相关系统部署工作，准备培训资料，对相关用户和信息技术人员进行培训。
IT项目管理心得体会
《IT项目管理》心得 随着经济全球化和市场竞争的日益加剧、竞争的加剧以及企业业务的复杂化，信息技术的应用已成为社会各行各业所不可或缺的，成为了企业发展的重要因素之一，信息化已经成为企业实现战略目标的迫切需要和必要保证。越来越多的企业认识到只有通过信息化建设才能够增强企业的核心竞争力，并在企业体制、技术、管理等方面实现创新，以此来在弱肉强食的环境中生存发展。由此项目管理的思想已经被越来越多的IT领域中的企业所接受，IT 项目建设逐渐成为企业资源投入的重中之重。而企业为了使IT项目能够按照预定的成本、进度、质量顺利完成，从而对成本、人员、进度、质量、风险、文档等进行分析、管理和控制。 目前，项目风险管理已被认为是减少IT项目失败的一种重要手段。项目必须事先有风险预控方案，事前控制永远要好于事中和事后控制，而要在项目开始之初就考虑到项目过程中可能出现的所有风险，是不现实的。但是我们必须考虑对风险的管理，尤其是在制订项目计划以及创建团队的时候，考虑这一因素。风险有很多，包括需求的风险、进度的风险、质量的风险以及技术风险等。必须制定一套完整的风险管理计划，一旦发生了风险，则必须及时响应，组织相关人员解决风险。不能忽略任何一个小的风险，否则一个小的风险到最后会造成大的灾难。风险的把握必须要有项目经理与系统架构师把关。 项目风险管理的实质，就是针对项目进行过程中各种各样的风险事件，在合理分析评估的基础上采取合理的对策，促进项目管理目标的实现。如果要真正搞好IT项目的风险管理，树立正确的项目风险意识尤为关键。就是要确立具体的目标，制定具体的指导原则，规定风险管理的责任范围，从认知、分析、防范等各个方面做好工作，采取主动行动，合理的使用回避、减少、分散或转移等方法和技术对活动或事件所涉及的风险实行有效的控制，妥善地处理风险事件造成的不利后果，以合理的成本保证安全、可靠地实现预定的目标，事无巨细都要谨慎处理。特别是在IT项目的可行性研究和计划阶段，风险管理的应用尤为重要。在IT项目的前期阶段面对的不确定因素较多，因此在这一环节推行风险管理对提高项目计划的准确性和可行性有极大的帮助。 风险有诸多因素构成，比如不合格的人力资源、缺乏客户参与、过于乐观的计划、流于形式、管理控制不力、次品频出、过于依赖技术、企业无法承担项目费用、市场定位错误等。其中，我认为自于项目人员的组织有效性，企业如何组建项目团队、其他部门如何配合项目
4、IT项目管理十大流程(精)
IT项目管理十大流程 只要流程界定清晰,项目经理就能保证项目的发展方向与最终目标相契合。广义而言,要掌控各种类型项目的发展,首先要关注十个关键的流程。 一、生命周期与方法论 项目的生命周期与方法论,是项目的纪律,为项目开展划出了清晰的界限,以保证项目进程。生命周期主要是协调相关项目,而方法论为项目进程提供了持续稳定的方式方法。 生命周期通常由项目的阶段组成(包括:开始、规划、执行/控制、完成,或由工作的重复周期构成。项目生命周期的细节一般都会随具体业务、项目、客户要求而改变。因此即使在同一个项目中,周期也会有多种可能的变化。对工作细致度、文件管理、项目交付、项目沟通的要求体现在生命周期标准和考核的方方面面。大项目的阶段一般更多更长,而小项目的阶段少,考核点也少。 与生命周期类似,项目方法也因项目而易,细节关注程度高。产品开发项目的方法经常涉及使用何种工具或系统,以及如何使用。信息技术项目的方法包括版本控制标准、技术文档管理、系统开发的各个方面。 项目方法往往不是由项目团队自行确定,而由公司为所有项目设定。采用与否,其实项目团队没有太多选择。公司管理层设定的方法本身代表权威,也是你作为项目领导获得项目控制权的一个途径。考虑项目方法某方面的作用时,始终要把握其对项目人员管理的效率,即在可能出现问题的地方争取正面效应。 二、项目定义 清晰的项目描述决定了你的项目控制能力,因为接下来所有工作都在描述范畴之内。不管你如何并为何要进行描述,你要对你的项目进行书面定义,让项目各方和项目组随时参考。
项目定义的形式和名称各式各样,包括:项目章程、提案、项目数据表、工作报告书、项目细则。这些名称的共同点在于,项目主管方和其他相关各方面从上而下地传达了他们对项目的期待。清晰的项目定义还包括以下方面: ?项目目标陈述(一小段文字,对项目交付成果、工期、预期成本或人力进行高层次的描述 ?项目回报(包括商业案例或投资分析的回报 ?使用中的信息或客户需求 ?对项目范围进行定义,列出所有预期的项目成果 ?成本和时间预算目标 ?重大困难和假设 ?描述该项目对其他项目的依赖 ?高风险、所需的新技术、项目中的重大问题 努力将尽可能多的具体信息,囊括在项目描述或章程中,并使其在项目主管方和相关方面获得认可,进而生效。 三、合同与采购管理 不管你在你的组织内有多大的影响力和权力,你对受雇于其他公司的项目成员的影响会比较小。虽然不一定普遍适用,但你可以尽量不将项目工作外包,这是提高项目控制力的一个技巧。 在考虑启用合同商或外部顾问之前,对整体采购流程进行重检。寻找有服务合同起草经验并可以帮助你的人。
IT项目管理 (1)
风险管理计划 1 引言 1.1本文件的范围和目的 适用于本项目所有风险控制，目的是辨识、描述和消除风险因素，以免它们威胁项目的成功运作 1.2概述 1.2.1目标 进行有效的风险管理，提高项目的成功率；增加团队的健壮性，与团队成员一起进行风险分析让大家对困难有充分估计，对各种意外有心理准备，提高组员的信心，从而稳定队伍；，将主要精力集中于重大风险，将工作方式从被动救火转变为主动防范。 1.3组织 1.3.1领导成员 组长：管理者代表 副组长：项目部主管 组员：各部门主管 1.3.2责任 对风险予以控制，以避免或减少不利影响，增强有利影响，持续改进管理质量体 系，确保质量管理体系能够实现其预期效果 1.3.3任务 2风险识别 2.1风险情况审查、风险来源等 需求风险 ①需求已经成为项目基准,但需求还在继续变化;②需求定义欠佳,而进一步的定义会扩
展项目范畴;③添加额外的需求;④产品定义含混的部分比预期需要更多的时间;⑤在做需求中客户参与不够;⑥缺少有效的需求变化管理过程。 计划编制风险 ①计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;②计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态";③计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上;④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大;⑤完成目标日期提前,但没有相应地调整产品范围或可用资源;⑥涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。 组织和管理风险 ①仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;②低效的项目组结构降低生产率;③管理层审查决策的周期比预期的时间长;④预算削减,打乱项目计划;⑤管理层作出了打击项目组织积极性的决定;⑥缺乏必要的规范,导至工作失误与重复工作;⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。 人员风险 ①作为先决条件的任务(如培训及其他项目)不能按时完成;②开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;③缺乏激励措施,士气低下,降低了生产能力;④某些人员需要更多的时间适应还不熟悉的软件工具和环境;⑤项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;⑥由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;⑦不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;⑧没有找到项目急需的具有特定技能的人。 开发环境风险 ①设施未及时到位;②设施虽到位,但不配套,如没有电话、网线、办公用品等;③设施拥挤、杂乱或者破损;④开发工具未及时到位;⑤开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;⑥新的开发工具的学习期比预期的长,内容繁多。客户风险 ①客户对于最后交付的产品不满意,要求重新设计和重做;②客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做;③客户对规划、原型和规格的审核决策周期比预期的要长;④客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;⑥客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。 产品风险 ①矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;②开发额外的不需要的功能(镀金),延长了计划进度;③严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;④要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;⑥开发一种全新的模块将比预期花费更长的时间;⑦依赖正在开发中的技术将延长计划进度。 设计和实现风险 ①设计质量低下,导致重复设计;②一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能;③代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;④过高估计了增强型工具对计划进度的节省量;⑤分别开发
IT项目管理表格-前言
前言 一个值得深思的事实是，到2002年底为止，已经信息化的企业在IT上的投资超过了未信息化的企业在IT上的投资！这意味着什么？ 这意味着IT项目的投资已经由厂商驱动向用户驱动转变，以往什么利润高IT厂商就说什么好，用户就低着头掏腰包的时代过去了！现在大多数的用户都经历过信息化，没成功过，也失败过，经验教训都有了许多。用户更加重视企业信息战略的规划、IT投资的实实在在的效益，更加重视对已有投资的保护与对未来发展的适应。用户聪明多了，也精明多了！ 正是因为上述事实，IBM推出了ON DEMAND（随需应变），HP推出了Adaptive Enterprise（动成长企业），联想推出了关联应用。作为旁观者，笔者认为这些理念都是要“一切为了用户，一切为了用户的将来”。 另一方面，能够为用户提供IT能力的厂商如雨后春笋般成长，这些企业为了生存，竞争手段花样百出，竞争也日趋白热化。为了规范市场，信息产业部推出了软件企业的认证、系统集成企业的认证、系统集成项目经理的认证，使IT应用市场健康有序的发展。即使这样，整个IT行业的平均利润率在下降确是不争的事实。IT行业暴利的时代已经过去，作为一个行业，它正在走向成熟，它将像电力、石油等行业一样，非常、非常重要，但是发展平稳。 那么，作为IT企业，要想在竞争的市场上持续发展，就必须提高自己的核心竞争力。IT 企业的竞争力体现在两方面：一是IT解决方案的技术水平，一是IT项目的实施能力。相对于前者，后者在短期提高利润率方面更能显示出威力。因为项目管理水平的提高，意味着项目能得到更好地控制，成本能得到更多的节约，人力资源能得到更加合理的安排，客户的需求能得到更好地满足。节约1元钱就是1元钱的利润，而销售额增加1元能增加2毛钱利润就不错了。显然，IT厂商应该下大力气提高企业内部的管理水平，特别是项目管理水平。 现在学者们从多个角度研究了信息化的规律和得失，大家总结出IT项目失败的主要原因是非技术方面的原因，比如领导不重视、项目管理不当、员工不配合等等，表面原因是各种角色“认识不到位”。其实，“认识不到位”的深层次原因之一是缺乏信息化和IT项目管理方面的知识，因而，要解决认识不到位的先决条件是“知识要到位”。 “知识要到位”意味着需要给企业信息化中相关的主体或角色转移相应的知识。如果参与信息化的企业能有效的实现知识转移，将较大幅度地提高IT项目的成功率。考虑到“十五”期间的万亿级IT投入，即使成功率由目前业界认同的的“三七开”①提高到“五五开”，也将会带来巨大的经济效益。因而重视知识转移对于我国即将展开的信息化高潮具有鲜明的实践性。 在企业信息化知识的转移过程中，过程知识和结果知识同样重要，甚至更重要。大多①上世纪90年代初国内信息界曾经有两个著名的80/20估计：80%的信息化项目都失败了，只有20%的信 息化项目是成功的；在失败的项目中，80%是由于非技术原因导致的，只有20%是由于技术原因导致的今天，业界普遍认同的成功率估计为30%，即成功与失败变为“三七开”，两个80/20估计也变为两个70/30估计。尽管成功率估计上升了10%，但失败率还是很高的。
IT项目管理
软件项目成本管理研究 随着信息技术的飞速发展，软件企业在我国高新技术产业中扮演着越来越重要的角色。软件企业进行项目管理有利于将开发人员的个人开发能力转换为企业的开发能力，软件企业的软件开发能力越高，表明这个企业的软件生成越趋于成熟企业越能够稳定发展。软件项目管理是软件软件企业提高竞争力的重要手段，成本管理系统是软件项目管理系统的一个子系统。有效的软件项目管理和成本控制可以更好的为软件企业积蓄财力，可以增强软件企业的竞争力。 软件项目成本管理就是根据企业的情况和项目的具体要求，利用公司既有的资源，在保证项目进度、质量达到客户满意的情况下，对软件项目成本进行有效的组织、实施、控制、分析和考核等一系列的管理活动，最大限度的降低项目成本，提高项目利润，实现客户、公司、员工三赢，获得更稳定的客户群，更多的公司利润和更稳定项目队伍。 软件项目管理概述 在传统的项目管理软件中，一般都是进度安排和跟踪控制，大多说都不能进行软件成本估计，缺乏事先成本控制，部分项目管理软件虽然具有一些成本管理的功能，但这些项目管理软件多数是面向工程项目来设计的，真正面向软件项目的项目管理软件很少。由于软件项目自身的特殊性，导致了在应用工程项目管理软件在管理软件项目时会出现很多的问题。 软件项目成本估算 成本估算——编制完成项目活动所需资源的大致成本。 成本估算师成本管理中的主要部分。软件项目成本主要包括硬件成本、软件开发成本、人员培训费用、项目管理费用等。软件项目成本估算就是根据待开发软件的特征、用户环境及以往同类或相近项目的基础数据进行软件规模测算；由系统软件的成本构成，结合成本影响因素、环境因素以及以往同类或相近项目的数据分析，进行软件成本测算；以
IT项目管理总结报告
IT项目管理总结报告 引导语：IT项目管理对于信管来说，应该是一门重要的专业课，只有掌握了其中的分析方法，才能在以后的项目开发中，对项目进行科学，全面的管理，提高项目的质量。下面是小编为你带来的IT项目管理总结报告，希望对你有所帮助。 篇一：IT项目管理总结报告 一、学习到的知识 通过本次课程的学习加之实习，首先，我知道了什么是项目，以及IT项目的定义什么，知道它是为解决信息化需求而产生的软件、硬件、网络系统、信息系统、服务系统等一系列与信息技术相关的项目，同时，我了解到了IT项目的主要特点分为7个，即明确的目的、独特性、时限性、目标渐进性、时效性、高风险性和智力密集型。在充分了解了定义之后，老师又详细讲解了项目的生命周期和管理模式，从项目4大阶段：启动、计划、执行、控制和项目管理9大知识领域：范围、时间、成本、质量、人力资源、沟通、风险、采购进行全面的解析。下面我就分别讲述在这几个方面自己学到的东西。 其中4大阶段中，掌握的比较好的就是前两个方面，在启动方面，我觉得就是要预先考虑到项目实施过程可能出现的问题，进行提前的计划，说到底就是未雨绸缪，里面最重要的就是可行性分析，它是作为项目能否开发的重要依据，提供需求、盈利、运行环境等多方的分析资料。另外一个，我掌握到的重要知识，就是WBS技术，我学会了如何对认为进行分解，将一个复杂的项目分成多个子项目，分别进行多次深度划分。项目时间管理是我听得最认真的内容，因为要作图，里面我主要是针对网络图进行了认真的学习，知道网络图的意义以及如何绘制网络图，在网络图的基础上，我学会了用个Project 软件生成项目的甘特图，并且能够从给出的甘特图中读取项目的信息和进度计划。最难的是活动历时估计中的关键路法，通过结合PPT，我掌握了如何根据给定的表格数据，推算出最早开始时间、最早结束时间、最迟结束时间、最迟开始时间、总时差，并在做完图后，从中找出其关键路径，即总时差为零的活动路线。 后面9个领域，都学的比较粗条，主要针对了成本、质量和风险管理。在成本管理方面，理论掌握的不好，主要就是知道了如何用Project软件对项目分配资源，并且知道了如何解决资源冲突的几种方法。 在项目质量管理方面，我通过实习，知道了IT质量管理的概念，整个体系，并且通过实习，知道了从哪几个方面入手去编写IT 项目质量计划，从而了解了一个项目团队如何去保证其项目的质量，特别是实施计划中，知道了一般性项目质量管理的工作计 划，和高层领导以及项目经理如何去评审一个项目以及各部门的任务分工和之间如何协调。 风险管理因为时间近，所以知识点记得比较多，最深刻的就是项目风险的评估分析。在里面，我主要掌握了如何定性的估计风险，学会了风险评定的等级划分，和结果划分。 二、感悟与体会 IT项目管理，其实自己没有多少重视，总感觉学到的理论偏多，让我值得欣慰的就是，我们在课程一开始就成立了分组，通过一个小组的整体协作，把整个项目过程都全部的经历了一遍，在完成的过程中，我发现，书上写到的只是冰山一角，远远满足不了你完成作业的标准，我很多时候都是拿到分配下来的题目，一阵发愁，然后翻了N遍书，还是不知道从何下手，可能是从来没有接触到类此的东西，缺乏思路，不知如何进行，只能在百度里寻找，希望找到材料，要是完全一样的就更好，没有的就东拼西凑，虽然其中有一些copy的影子，但自己也是阅读了大量的资料，整合了各种数据，在不知不觉中，理解该方面也越来越深刻，至少一开始的迷茫感没有了，其中让我印象最深的就是制作WBS，书中只是讲述了WBS的基本概念，没有一点制作的方法和步骤，完全是盲人摸象，一路磕磕碰碰，幸好在强大的搜索引擎下，在参考了无数公司优秀的案例下，制作了一个让自己非常满意的WBS图，当然，其中会有各种错误。 还有一个就是在合作的过程，我觉得一个项目想要合理，高质量的完成，各小组间的沟通即为重要，这里面包含了项目组长的领导能力和人格魅力，像我们组来说，我感觉就有点分崩离析的味道，就是个人管个人，组长分配啥，做了就好，没有形成一个小组间的共鸣，不知道其他组的进度和完成情况内容，所以内容应该有些分散，给组长也增加了很多的后期整理压力。 三、提出的建议