IT项目管理(原创培训课件)

项目目标不 清晰
• 需求过多；需求不完整；需求不稳定；需求模棱两可； • 大量的返工，造成资源更加紧张 • 错误的需求往往在项目生命周期的晚期才被发现
人员 未到位
• 团队的成员构成大多是凸现个性，追求随意 • 项目经理的错误人选； • 缺乏支持的高层管理
拙劣的质量 管理
。。。
• T产品工程的质量没有被贯彻到项目实际活动中 • 不成熟的技术 • IT产品的质量工程活动本身的不完善 • 。。。
• 分析需求背后的需求，切忌头痛医头，脚痛医脚。 • 深入分析和发现客户的阴性需求，通过各种方式手段平衡
满足客户需求；
第四部分：沟通、还是沟通
沟通和互动是项目成功的基础
公司
客户
项目经理
分包商/ 供货商
形式多样 沟通及时、多渠道 认真倾听 真实汇报 / 反馈 明确指示
员工 管理就是沟通、沟通再沟通。
矩阵式组织的每个人员都涉及到双线汇报关系，项目组会着 重于眼前任务的完成，而职能部门会关注长期的能力提高， 当产生冲突时，如何平衡？
优点：有效利用资源、职能专业知识可 供所有项目使用、促进学习、交流知识、 沟通良好、注重客户。 缺点：双层汇报关系、需要平衡权利 矩阵式组织结构的管理难度有时足以抵 消其成本和易获得广泛的技术支持带来 的好处。
张辉的项目失败原因？ 张莉的项目成功原因？
第五部分：团队建设
团队管理要素
明确的项目目标和范围 健全的项目组织结构 清晰的项目职责分工 简明有效的项目流程 和谐创新的工作氛围 开放互动的学习环境
协作意识
积极参与 坦诚交流 互相关心 相互学习 经验共享 风险共担
每个干系人（Stakeholder）都成为获胜者（Winner）！
Stakeholder在项目管理专著中往往译为“干系人”，指所有与项目成败有直接间接 利益关系的个人或团体。在软件项目中，往往企业的投资者、各级管理者、系统 使用者、公司客户，甚至包括企业的合作伙伴和竞争对手
W理论好处
• 明确项目的目标：共赢； • 影响项目经理思考决策问题的出发点（冲突）； • 将项目管理关注度转移到“人”上来；（角度全面，
5 个过程
• 启动 • 计划 • 控制 • 执行 • 结束
Initiating Processes
Monitoring & Controlling Processes
Planning Processes
Closing Processes
Executing Processes
9个 知识领域
• 项目综合管理 • 项目范围管理 • 项目时间管理 • 项目成本管理 • 项目质量管理 • 项目人力资源管理 • 项目沟通管理 • 项目风险管理 • 项目采购管理
—项目管理关键要素
• 课程约束 – 按时出席 – 手机调至静音 – 积极参与课程案例讨论, 可随时提问及分享
• 课程假设 – 学员曾经直接或间接接触过IT项目
• 课前准备 – 分组，并选出小组队长
调查：参与或管理过IT项目的请举手！
互动：选定一个参与度最高的项目，说出你在项 目中的角色，你认为此项目是成功的还是失败的， 然后阐述下你认为重要的影响因素；
第三部分：需求管理
需求理论中著名的理解偏差漫画
需求作为其他活动开展的基础，如果工作在一个低质量的需求上，其产品质量问题 将是致命的，其最好的结果是制造了一个用户不需要的低缺陷率产品
我们需要特别关注需求的准确性 缺陷被修复的代价 COPQ: Cost of Poor Quality
缺陷被发现的阶段
2000 28 0%
23 50%
49 100%
为什么会导致IT项目的高失败率
项目进度不 切实际
• 大多数IT项目进度由不具备准确估算的人作出的（市场人员或客户），死亡之旅 • 只关注快速实现，忽略过程验证；只考虑功能，忽略了性能；只关注现在，忽略了后期维护铺垫 • 构建系统80%在前80%进度内完成，而后20%同样花费相同的工作量
成功的IT项目管理
学习了项目管理体系就可以成功的管理项目了吗？我们还需要 关注什么？
• 体系性知识体系可通过阅读书籍获得； • 个人参加项目管理培训感受；（理论+实践+意识）
课程重点关注：
• 项目管理关键要素； • 实战经验、失败教训； • 通过实际案例学管理；
Skills vs. Competencies like the iceberg...
关注最终点）
将项目成功的标准 关注点转移到人上来，让 人满意是最为重要的！
影响IT项目管理成功的关键要素
是否建立了良好 的、积极的、团 队合作的文化氛
围；
项目的目标、范围 是否明确；
是否具有有效、 全面的项目管理， 严格的变更控制；
项目可行性研究 和计划是否完整
和适当；
项目的组织是否 健全、稳定；
——通用电器公司总裁杰克·韦尔奇
沟通和互动是项目成功的基础
• 决定项目成败真正因素大部分是沟通能力而不是技术能力
• 让客户满意方式：尽量满足客户所有需求、合理降低 客户期望值；
• 要使客户满意项目，就要及时和客户做沟通，使客户知 道项目的进度，以便决定是否改变期望的目标程度；
• 项目管理，不是你做了些什么，而是客户方、你的领导 知道你做了些什么；
项目经理思维模式：一切项目活动首先着眼于干系人
• 项目管理首要且重要任务，识别项目干系人及其角色 • 了解、分析和确定他们的需求和期望 • 设法满足和影响这些需求、期望以确保项目能够成功 • 项目经理必须从只关心做事转移到非常关注干系人 • 项目全过程要树立干系人思考模式，切忌头痛医头脚痛医
脚
摸清底细
• 沟通是具有目的性的，保障每一次沟通的有效性都是最重 要的事
• 注意非正式沟通，是正式沟通的有力补充
客户满意度曲线
满意度
什么是幸福？什么是满意？
有意识的“降 低客户期望”， 至少不随意的 提高客户期望， 从而变相的达 到提高客户满 意度的目标。
启动
过程中
验收
时间
案例分析三：十分钟
两个软件项目案例：过程相似，结果却大相径庭
• 什么是可以预见的项目背景和存在的问题？
• 项目提出人（或客户）期待什么样的成果？
• 完成所需项目资源匹配情况？
• 项目干系人？
案例分析二：五分钟
识别项目干系人失败的案例
项目干系人分析的四步法：
• 步骤一：无遗漏地识别出项目干系人 • 步骤二：按重要性对干系人进行分析 • 步骤三：按支持度对干系人进行分析 • 步骤四：项目干系人分析坐标格
关注需求：理解客户需要解决的问题
正确理解客户需求：在需求收集活动中，最容易犯的错误是把需求收集的目标理 解为：用户打算要什么产品？而需求收集活动真正的目标是：用户拿产品做什么？
需求收集记录下用户期望如何使用产品去解决客户的真 正问题，才会真实而完整地记录下客户明确的和隐含的 需要。在项目需求还不是十分清晰的早期阶段，直接把 需求理解为产品功能，会由于技术域和问题域的“鸿沟” 产生不完整的和错误的需求。也就是说你必须站在客户 的角度去真正理解产品完成后，被应用的场景，而不要 太关注产品本身。
课程提纲：
第一部分：什么才是成功的软件项目 第二部分：摸清底细 第三部分：需求管理 第四部分：沟通，还是沟通 第五部分：团队建设 第六部分：平衡的艺术
第一部分：什么才是成功的软件项目
IT项目失败率居高不下
1994 18
29
53
1996 27
40
33
1998 26
28
46
Success Challenged Failed
关键：明确团队成员向谁汇报，对什么职责 或任务进行汇报，因此在一个矩阵组织中， 是项目经理与职能经理各自明确自己的职责 很重要。明确绩效考核。
是否建立了有序的、 有效的、良好的沟
通渠道；
是否获得领导的积 极支持；
第二部分：摸清底细
案例分析一：十分钟
一个售前项目的策划：M省移动传输网项目
项目分析要素：
商业目标 建立客户关系
实施策略 以客户为中心
进入新市场
关注质量
• 项目的来龙去脉？
获得利润
关注成本绩效
• 项目对公司目标是什么？
• 项目带给客户的价值是什么？
对于项目经理： 一个IT项目成功的项目衡量标准是什么？项目经 理从哪些关键行动要素保证项目成功？
本次课程重点：不包括以下部分
• 项目定义：为完成某一特定的产品,服务或结果所做的一 次性努力
• 项目管理定义：在项目活动中运用知识、技能、工具和技术 来达到项目的要求
• 项目管理知识体系PMBOK：对项目管理所需的知识、技能和 工具进行的概括性描述
什么才是成功的软件项目？
• 依据合同完成项目 • 满足客户的要求 • 不超预算 • 学有收获 • 赢得信誉，建立品牌 • 成为公司的优势
• 符合时间、质量、成本，不一定是成功的项目； • 不同角色角度定义的成功标准不同； • 最难定义的是项目经理这个角色，满足多角色目标（
公司、团队、个人）；
软件项目成功标准：W理论
平衡一：时间、质量、成本的平衡
时间
成本 范围
质量
• 又快、又好、又便宜 • 如何实现这三者的平衡？项目干系人思维
平衡二：所有干系人需求和期望的平衡
• 现状：项目涉众的要求和期望不同，可能很多都是冲突的
• 项目管理不是使项目干系人的满意度达到最佳，而 是在项目投入限度内达到相对满意即可
• 项目管理要做出权衡，整合他们的需求，使项目目 标被所有的干系人赞同或接受
需求控制பைடு நூலகம்验证和确认 (V & V)
• 验证：正确的构造了产品
– Verification: Build the product right
• 确认：构造了正确的产品
– Validation: Build the right product
第26页
确认活动目的在于让客户可以确认其要开发的最终产品是满足客 户期望的。一方面，可以通过完成后的最终产品进行确认，但是 制造一个“错误产品”的代价是极其高昂的，所以开发过程中的 确认，特别是早期的需求确认活动是十分关键的
需求控制要领：抓住客户的两点担心，花钱和麻烦
• 作为项目经理一定要合理限制用户需求，避免需求泛滥； • 需求一定要与成本投入有显性联系联系（建立在需求基线
基础上，前期达成共识）； • 需求变更一定需要经甲方项目组书面认可； • 小的需求也需要经过正规管理流程； • 建立合理有效的需求变更流程，（重点事前建立需求变更
尽
三：不重要但紧急
交
1、处理一般性文件。
量
1、造成干扰的紧急事件。
给
2、看电视消磨时光。
别
3、归档本周所有文件。
去 做
2、打若干个沟通的电话。 3、帮助客户解决一个难题。
别 人 去
做
• 难点，如何区分是否重要、是否紧急；
• 技术型项目经理容易烦的错误，优先做喜欢的事情
平衡四：矩阵式项目组织和职能部门冲突
平衡三：要干的事情那么多，时间却那么少
重要性
二：重要但不紧急
一：重要而且紧急
1、准备工作、编制计划、维持关系。
2、去拜访VIP客户。
有
3、计划给员工进行培训。
计 划
4、回访客户。
去
做
1、紧急状况、迫切问题、限期完成。
2、一会儿要参加重要会议。
立
3、与客户沟通要做合同。
即
去
4、准备事项。
做
紧迫程度
四：不重要且不紧急
关注执行
项目中间的大多数问题是出在执行层面，而不是计划层面 项目成功的关键不是编写出一个伟大的计划和蓝图，而是目标和计划
可以被落实，使得项目可以坚持到终点
第六部分：平衡的艺术
何为优秀的项目经理：
不是给你绝对充足的资源让你将项目做得尽善尽美，而是 在一定的资源范围内，是否取得了最大价值的结果（让更 多、更加重要的的干系人满意）；
流程，让客户感觉到你的专业性，切忌客户提出需求时， 才开始和他提到流程 • 尽量避免现场开发模式（多个失败案例的惨痛教训） • “放入二期实现”自己和客户都能轻重缓急； • 让每一个额外需求变更，都显得有价值和意义；
隐性需求：非软件需求，重点关注和考虑的
• 人们只会告诉你问的东西，而不会告诉你他想的东西 • “说出来的需求只占项目总需求的20%”--中国特色
• 弄清具体情况，无论是在项目前期，还是在项目进展过 程中；
• 针对总体制定规划，针对具体事务避免头痛医头脚痛医 脚；
• 少猜测，探求更多的信息，信息就是力量，“聪明反被 聪明误”；
• 留出时间来思考、分析； • 大忌 “我们就开始开发吧”，习惯“预备、瞄准，放！
”
回顾及总结：
W理论：每个干系人（Stakeholder）都成为_获__胜__者__。 弄清底细：留出足够时间__思__考___与__分__析___ 。 项目管理思维模式：一切项目活动着眼于_项__目__干_系_。人