读哈佛项目管理手册

这是一份由哈佛商学院Harvard Business School)在1996年出版的项目管理手册(Project Management Manual)。这是一份专门针对项目（Project）的手册，手册中没有对”项目”进行分类，因而在这里不存在项目的营利与非营利的区分。开头是下图 所示的项目计划和管理的流程图：

流程图明细：

1.Define and Organize the Project
项目定位和确立团队

1.1 Establish the Project Organization
建立项目团队

1.2 Define the Project Parameters
确定项目要素

1.3 Plan the Project Framework
制定项目框架

1.4 Assemble the Project Definition Document
项目概念文件管理

2. Plan the Project
项目计划

2.1 Develop the Work Breakdown Structure
开放工作细分构成

2.2 Develop the Schedule
制定项目日程

2.3 Analyze Resources
项目资源分析

2.4 Optimize Tradeoffs
优化共商决策

2.5 Develop a Risk Management Plan
制定风险管理规划

3. Track and Manage the Project
项目监测与管理

3.1 Collect Status Information
收集项目进展信息

3.2 Plan and Take Adaptive Action
制定可适性计划并进行调整

3.3 Close Out the Project
项目结束

___________________________________________

在整个阅读过程中，个人觉得最有用的收获就是手册中每一个流程里的Key Questions（关键问题）。这些问题在项目的管理过程中应该被一问再问。下面试翻译一些：

1.1. Key Questions for Establish the Project Organization 在组建项目团队时的关键问题

• Who is the project manager? 谁是项目经理？（确定负责的人）
• What are the project manager’s responsibilities? 项目经理的职责是什么？（确定负责人负的是什么样的责任）
• In which areas does the project manager have decision-making authority?项目经理在哪一个方面具备决策权？ （确定负责人的权力范围）
• Have the project manager’s responsibilities and authority been agreed to, written down, and distributed to the team? 项目经理的职责和权力是否经过了团队的同意，且已经成文并分发到团队成员手上？
• Who is on the team? 团队里都有谁？
• What is each team member’s expertise? 团队成员的专长是什么？
• Is everyone who is performing work for the project identified? 是否团队成员都对项目知根知底？
• What are the team’s responsibilities? 项目团队的职责是什么？
• Has a team roster been completed? 团队的成员列表是否已经做好？
• Who sponsors the team? To whom does it report? 谁为团队出资？这个团队又向谁汇报？

#在组建团队时：要分清团队成员的职责及权力范围。而且，团队成员要对彼此相互了解（特长）。重要的是，这些东西都必须是成文的，写下来的。

那一个好的项目经理（Project Manager）应该是什么样的？手册给出一些参考，他应该：

• 是一个很好的激励者、领导、教练和教师；
• 顾全大局；
• 高效的沟通；
• 一个良好的组织者；
• 目标为导向；
• 熟悉并致力于使用项目管理流程

详细地，表现如下：

• 确保让团队成员理解并实践于项目的管理；
• 确保让团队成员都明白并接受其职责；
• 让团队的资源集中于制定、执行项目计划；
• 对项目计划进行及时的调整；
• 项目文档的维护；
• 仲裁和解决冲突；
• 向团队成员和其他人回报项目进展；
• 记录问题日志（maintaining an issues log.记录问题及商议出来的解决方式，便于日后参考）

同样地，在组建项目团队这一环节中，手册谈到如何保证让团队成员对项目持有”拥有感”，以下是项目团队的一些首要职责：

• 明确项目管理的过程和工具；
• 共同制定项目计划；
• 承诺共同致力于项目的成功（being committed to the project’s success）；
• 执行项目任务；
• 汇报项目的进展、风险、问题和难题；
• 作出有效的项目调整；

 

1.2. Key Questions for Define the Project Parameters 确定项目目标的关键问题

• What is the scope of the project? 项目的规模是什么？
• When will the project be completed? 项目什么时候完成？
• What resources will be allocated to the project? 项目可支配的资源是什么？
• Is there a clear, concise Project Objective Statement of 25 words or less? 项目的目标能否用25个字（或者更少）来阐明？
• What are the project’s major deliverables or outcomes? 项目的主要产出是什么？
• Are the major deliverables well defined? 项目的主要产出是否已很明确？
• Is there a written “Is/Is Not” list for each major deliverable? 项目的每个主要产出是否有一个『是什么/不是什么』列表？
• Do the major deliverables have target completion dates? 项目的主要产出是否有明确的完成日期？

那么，一个有效而明确的项目目标描述（Project Objective Statement，POS）会是什么样？

• 用25个单词甚至更少的词写成；
• 用简洁的语言，不用行话和缩写；
• 明晰而精确；
• 理想情况下，它是显性（可见）的，可以创造一个挑战并让人振奋（Ideally, it is visionary, creating a challenge and generating excitement.）

 

1.3. Key Questions for Plan the Project Framework 项目计划框架的关键问题

• Has the team specified when and where it will meet, who will attend meetings, and what
  topics will be discussed? 项目团队是否已经明确地得知什么时间、什么地方、谁将出席讨论什么样的主题？
• Have attendance rules been established? 是否已经制定了会议规则？
• Have participation guidelines been established? 是否有参与指南？
• Is the team regularly logging all issues? 团队是否会记录所有问题？
• Is the issues log being regularly updated and reviewed? 问题纪要是否已经更新并得到讨论回顾？
• How will the team resolve disagreements and conflicts? 如果团队内出现争论和冲突该如何处理？
• Is there an escalation path for unresolved issues? 未解决问题是否有升级（恶化）的途径？
• Who owns and maintains the project file? 谁负责保管和记录项目文档？
• Where will the file be stored? 项目文档保存在何处？
• How will the team communicate (e-mail, telephone, etc.)? 团队内如何沟通（电邮、电话等等）
• Have these agreements been written down and stored in the project file? 以上协议（达成一致的问题）是否已经写下来并存档到项目文档中去？

在很多的操作性流畅中，以下一些问题可能尤其重要：

• 会议以及会议管理；
• 问题管理（包括可能会出现”升级”的问题）
• 项目文档管理；
• 沟通流程；

手册中还提供了一个表格，特别用来处理那些会”升级”（恶化）的问题：

序号	日期	谁提出的	问题描述和影响	谁来负责解决	截止日期	进度或者解决方案

在这里，又有一些Key Question要注意：

• 在会议管理流程上达成一致后要写下来；
• 主动地对问题做出处理，使用问题纪要（Manage issues aggressively, using a formal issues log.）
• 对于项目文档，指定管理者、保存场所和阅读权限；
• 确定沟通策略后要写下来；

 

2.1. Key Questions for Work Breakdown Structure 工作细分构成的关键问题

• Are all tasks identified? 是否所有任务都已经明确？
• Are often-forgotten tasks such as planning the project, approval cycles, testing, printing,
  and so forth, included? 一些常常容易忘记的工作内容诸如计划、审核批准流程、打印等是否已经包含在内？
• How long will the tasks take? Hours? Days? Weeks? 这些任务将要花多长时间？明确到小时？天？周？
• Have owners been assigned to the lowest-level tasks? 最底层的任务是否已经被分派好？
• Is there only one owner per task? 是否每个任务只有一个人？

在这些问题下面，关于最底层的任务，有两个小提示：

• 这些任务大概需要2天到2周时间（分解成这样的任务）；
• 单一的负责者；

 

2.2. Key Questions for Develop the Schedule 制定项目日程的关键问题

• Have all “dependencies” been identified? 是否所有的”任务依存关系”（见下图）都已经确认？
• Were any new tasks identified that need to be added to the plan? 是否有新的任务被识别出来并要添加到计划中去？
• Was a network diagram created? 是否已经网状的图解？
• Were durations assigned to the lowest level-tasks? 最底层的任务是否都已经分配好时间段？
• Were estimates for longer or more ambiguous tasks reviewed by the team? 团队是否就长一些或易混淆的认为进行了审核、估计？
• Was a Gantt Chart created? 是否做好了甘特图？

在这里，特别提到了两个概念：

• Dependencies 任务间的依存关系：FS关系（A任务结束，B任务接替之。即A完之后才能开始B）、SS关系（A任务和B任务同时开始）、SS-Lags关系（A任务和B 任务并非同时开始，但一段时间后会在进程上重叠）。一般情况下，SS-Lags关系的任务可以通过分拆可以将其转换称FS关系。
• PERT [Program Evaluation and Review Technical] （见范例）

Dependencies

PERT sample (1024 px) link

一个有效的任务估计（Effective task estimateion）应该是这样的：

• 完全的工作内容细分（WBS，work breakdown structure）；
• 能快速地在最底层面来估计任务期限（quickly approximating task durations for the lowest-level tasks.）

在做项目日程时，这是一些Tips/ Key Actions for Develop the Schedule

• Use the WBS Post-Its® to create a dependency diagram from the lowest-level tasks. 使用便易贴来分解最底层任务，并建立任务关系图表（如上PERT sample）
• Quickly approximate task durations (in hours). 快速估计任务所需要时间（以小时计）
• Create a Gantt chart showing the schedule 制作甘特图

 

2.3. Key Questions for Analyze Resources 项目资源分析的关键问题

• Is one resource carrying a disproportionate amount of the workload? 是否某一个资源承载了其不成比例的负荷？
• Are any resources underutilized or overlooked? 是否有资源未被利用或过载（过度利用）？
• Are any resources affected by parallel work? 并行的工资是否影响到某些资源？（即某个人需要对并头进行的工作负责，是否会受到影响）
• Do all task owners have the requisite skills to perform the work? 是否所有的任务负责人都有工作所必须的技能？

在回顾甘特图的时候，注意：

• 谁被列为大部分任务的负责人？（the same person listed as the owner of most tasks;）
• 谁被列为大部分并行任务的负责人？（the same person listed as owner of several parallel tasks;）
• 谁负责的任务最少（some people seldom listed;）
• 是否有很多任务并行地堆到一起？（many tasks stacked in parallel;）
• 那些无人负责的项目（tasks are ownerless.）

 

2.4. Key Actions for Optimize Tradeoffs 优化决策中的关键行为

• Are you within the POS? 你是否还在目标之内？
• Can you reduce scope? 你能否削减规模？
• Can you change the sequence? 顺序能否改变？
• Can you reassign or obtain more resources? 你能否再分配或争取到更多资源？
• Is there a way to work better and smarter to achieve the same result? 是否有更好、更快捷的方式来达到同一结果？

 

2.5. Key Questions for Develop a Risk Management Plan 风险管理计划中的关键问题

• Have risks been identified? 风险是否都已被识别？
• Have they been prioritized? 那些风险需要优先考虑？
• Have actions been taken to reduce the probability of risk? 对于优先级别的风险，是否已采取了行动？
• Have contingency plans been formulated? 是否构想好了意外情况发生时的计划？ （即所谓B计划）
• Who is responsible for managing risk? 谁来负责风险管理？

风险管理方案包括： 风险评估(Risk assessment)和风险管理(Risk management)。

Key Actions for Develop a Risk Management Plan 风险管理计划中的关键行动

• Identify and prioritize project risks. 识别风险，并对其排序；
• Create a risk management plan that includes preventive actions and contingency plans. 制定一个包含预防措施和意外事件计划的风险管理计划；
• Assign someone to manage project risks.专人负责管理项目的风险；

 

3.1. Key Questions for Collect Status Information 项目进展信息的收集

• How often will “collect status information” be formally done? 收集信息的频率
• How will it be done? 如何收集
• What information will be monitored? 收集监测那些信息？

一个良好的项目信息收集一般限于三个主题：项目日程状态（schedule）、存在的问题（Open issues，意思是”因有争议而没有确定答案/对错的问题”）和风险（Risk）。

日程状态一般包括：

• Have tasks scheduled to start in this time period started? 任务是否已经开始？
• If not, why not, and what can be done to get them started? 如果不，为什么？如何做才能让其开始？
• Have tasks scheduled to finish in this time period finished? 这时候是否已有任务被完成？
• If not, why not, and what can be done to get them finished? 如果不，为什么？该如何做才能让其结束/完成？

Open Issues：

• What is the status of all open issues? 问题的状态是什么？
• What can be done to close them? 如何解决？
• Are there any new open issues? 是否有新的问题？

风险：

• What is the status of the risk? 风险的状态是什么？
• Are there any new risks? 有没有新的风险出现？

Plan and Take Adaptive Action 计划调整阶段

在此阶段，一个团队应当：

• move items in the Is list to the Is Not list;将『是什么』的条目移动到『不是什么』列表（指的是项目目标）
• eliminate one or more major deliverables;剔除一个或多个主要期待产出；
• develop an alternative way to perform task work;开发一个替代途径去完成任务；
• alter dependencies;变更『任务依存关系』
• change resource allocations;改变资源分配
• accept new parameters.接受新的任务范围

在这一阶段，需要问的最终问题是：

• 决策是什么？
• 要采取的行动是什么？
• 这些决策和行动是如何得出的？

 

3.2. Key Questions for Close Out the Project 项目结束阶段的关键问题

• Which elements of project management were effective? 管理中哪一部分是最有效的？
• Which elements might be improved? 哪一部分需要改进？
• How might they be improved? 如何改进？
• Is all of the paperwork complete? 是否所有的文档工作已经完成？
• Has key learning been recorded in the project file? 关键的经验是否已经记录在项目文档中？
• How will key learning be used in future projects? 这些经验如何应用到未来的项目中去？
• Has the project file been archived somewhere? 项目文档是否都已归档？
• How will the project’s completion be acknowledged and celebrated? 项目的总结如何报告，以及如何庆祝？

一般的项目结束阶段的活动包括：

• 对于项目有效的实践/活动的评估；
• 对于那些没有达到如期效果的实践/活动的评估；
• 在未来项目中可能的改进措施；
• 对团队成员贡献的承认（acknowledgment of team members’ contributions;类似于鸣谢，以各种形式，比如会议、活动、印刷品扉页的感谢等等）
• 完成项目所需的报告、文档；
• 项目文档归档；
• 庆典会

附：

Havard Business School – Project Management Manual 下载链接