一分钟项目管理总共7期汇总(一分钟项目阐述内容)

—— 本文内容结构 ——

第一期 7±2原则

一、原理解读

二、适用场景

三、优势好处

第二期 需求

一、词语本义

二、项目需求

三、需求类别

①业务需求

②技术需求

③财务需求

④质量需求

⑤管理需求

四、相关关系

第三期 十五至尊图

一、含义

二、组成

1.五大过程组

2.十大知识领域

3.49个活动

三、使用场景

第四期 风险评估

一、含义

二、组成

1.风险概率评估

2.风险影响评估

3.风险等级评估

三、风险评估矩阵

第五期 项目范围

一、定义

二、呈现方式

三、范围管理

①蔓延

②镀金

四、管理策略

第六期 专家判断

一、定义

二、渠道来源

三、应用场景

1、项目需求解读

2、项目变更评审

3、项目验收评审

4、项目管理咨询

第七期 虚拟团队

一、定义

二、范围

三、分析

1、优势方面

2、缺陷方面

第一期 7±2原则

一、原理解读

7±2是项目管理常用的量化工具,一般默认量化数字在此范围内符合最优化状态,即“不多,也不少”

二、适用场景

1.WBS编写中关于分解的模块数,可以在此范围内

2.工作汇报模块数可以参考此范围

3.工作小组、项目组,能够扁平化管理的人员数可以在此范围

4.同一时间段(每天、每周期)并行处理工作分解数可以在此范围

5.人脑并行处理、记忆的最佳范围

6.归纳、总结、提炼方法论或体系化模块可参考此范围

三、优势好处

1.符合大脑思维逻辑和方式,不会劳累或不饱和

2.量化参考依据,如果超出范围则需要整合、折叠一部分,如少于这个范围,则需要警惕是否缺少模块,还需进行拆分

3.不绝对遵守,结合实际情况判定

第二期 需求

一、词语本义:因为需要而产生的要求

二、项目需求:因项目需要而产生的的要求,主要来源于项目的需求方(甲方组织,客户方、用户方等),对项目在进度、成本、质量、交付物等各方面的要求。可以拆分为业务需求、技术需求、财务需求、管理需求等部分

三、需求类别:

①业务需求:业务相关的工作模块、流程步骤、需要达成的目标、涉及的角色以及具体的运行过程等,一般为客户方、用户方提出。

②技术需求:基于用户、客户提出的业务需求,在技术层面的关联转化,即将业务需求转化为信息化语言,通过技术手段将业务需求具体实现;此部分为项目经理的重点工作内容之一

③财务需求:贯穿项目交付过程的财务相关需求,在项目和交付阶段需提交的文件、流程手续以及款项的出入要求

④质量需求:项目经理需重点掌握的,客户无法提出的、但是隐性存在的、贯穿项目交付始终的需求。如不符合质量需求,大概率将发生返工或变更

⑤管理需求:客户方与项目方需达成共识并且共同推进的需求工作,在项目初期会规定一部分(项目计划、进度、里程碑等),在项目实施过程也会渐进明细,逐步细化,覆盖项目交付所有需遵守的规范、需履行的流程、需提交的文件等相关工作

四、相关关系:

①项目想要成功交付,业务需求与技术需求必须一一对应,而且,技术需求应实现业务需求中“隐性”(无法用语言表达出来的)的部分

②业务需求、技术需求的描述文档一般为需求规格说明书,需要不断跟客户确认(最好有签字),并在验收时交付出来,也是需求变更的参考文件

③质量需求、管理需求一般以项目制度规范呈现,包含目标、覆盖范围、流程及要求,项目经理需格外重视,在项目初期进行规划能少走弯路

④财务需求需符合项目内部公司财务或采购部门的要求,关键决策点需与客户进行核实

第三期 十五至尊图

一、含义

基于PMBOK的内容,将项目管理标准化组成中的内容提取出来,即“五大过程组、十大知识领域”共同组成的包含工作分解(活动)的矩阵名称

二、组成

十五至尊图:

1.五大过程组:启动、规划、执行、监控、收尾

2.十大知识领域:整合、范围、进度、质量、成本、风险、资源、沟通、采购、相关方

3.49个活动:基于五大过程组、十大知识领域分解的具有明确输入、输出、推荐工具的活动

三、使用场景

1.十五至尊图涵盖了项目管理涉及的全部内容,可以从整理角度查看项目管理所涉及的工作范围

2.基于五大过程组和十大知识领域分解的活动具有明确的输入、输出及工具,为规范项目管理工作提供了详细的参考

3.十五至尊图是项目管理入门的最基础内容,需不断揣摩、吸收。如需在项目上落地,可以结合项目实际情况进行“裁剪”

一分钟项目管理总共7期汇总(一分钟项目阐述内容)

第四期 风险评估

一、含义

风险评估是在项目执行过程中,在各个阶段、渐进明细地完成关于风险概率、风险影响、风险等级以及风险应对的评估工作

二、组成

风险评估包含三部分内容:

1.风险概率评估:风险发生的可能性评估,一般分为5个级别:

①几乎不可能-1:发生的可能性为1%-20%

②可能性低-2:发生的可能性为21%-40%

③可能-3:发生的可能性为41%-60%

④可能性高-4:发生的可能性为61%-80%

⑤接近肯定-5:发生概率为80%-100%

2.风险影响评估:风险对项目的影响进行评估,也是分为5个级别:

①非常低的影响:1

②低影响:2

③中等影响:3

④高影响:4

⑤非常高的影响:5

3.风险等级评估:基于风险概率、风险影响的评估,设定具体的计算公式,并进行组合、计算风险的严重性,形成风险评估矩阵

三、风险评估矩阵

1.风险严重性:基于特定公式计算形成

2.将矩阵中风险评估数值进行区分,形成风险等级划分,区别高、中、低不同等级的风险严重性

3.举个栗子:如严重性=P (2*I),可以计算出严重性数值为:3、4、5、6、7、8、9、10、11、12、13、14、15。可以定义高严重性风险等级为12-15,中严重性为9-11,低严重性为3-8(具体可以采用不同的计算模型,依据项目实际情况确定)

4.风险评估过程主要依据主观判断,可能会存在较大误差,需要不断识别、评估,贯穿项目交付始终

一分钟项目管理总共7期汇总(一分钟项目阐述内容)一分钟项目管理总共7期汇总(一分钟项目阐述内容)一分钟项目管理总共7期汇总(一分钟项目阐述内容)

第五期 项目范围

一、定义

项目范围是对项目所期望的最终产品和可交付成果的描述,主要包含两方面内容,一是工作范围,为实现该产品和可交付成果所需各项具体工作,二是功能范围,产品所具备的特征和功能。

二、呈现方式

明确项目范围是项目管理的核心工作,范围明确,交付目标明确,相关基线(进度、成本等)才能相应明确。

可以使用WBS工具,基于一个大的项目目标,逐步降维、层层分解至合适颗粒度的工作包。其中:

①纵向分解的工作阶段的描述即为工作范围,包含具体的工作模块、工作步骤。

②各工作任务的质量及交付要求的集合即为功能范围,包含了产品所具备的特征和功能。

三、范围管理

范围管理涉及两个维度的内容:

①蔓延:被动增加项目范围,即在甲方相关组织(客户、用户、客户职能部门等)需求下对项目产生的超出交付范围的变更。

②镀金:主动增加的项目范围,即在乙方组织(项目团队、乙方领导、销售/售前等)需求下对项目产生的超出交付范围的变更。

项目范围管理工作要尽可能杜绝蔓延和变更情况;一旦发生蔓延或镀金,走正规的变更评审手续。

四、管理策略

①重视范围管理工作,仔细研读项目合同、招投标文件等内容;如内部研发类项目,需重点关注项目需求以及产品功能。

②与关键相关方充分沟通,输出符合要求的WBS,保证各方在范围(工作范围、功能范围)理解一致。

③明确项目变更流程,保障变更过程规范、合规。引导甲乙双方对变更成本的理解一致性,降低随意变更的概率。

④正确引导/约束项目交付团队,有变更、风险管理观念,尽量减少引发改变原设计行为,任何变更需上报组织,共同研讨决策。

第六期 专家判断

一、定义

项目管理中最常用的工具(几乎没有之一),适用于绝大多数工作场景(质量管理领域除外)。

专家判断的原理,是利用专家的知识、经验、能力对模糊信息和不确定状态下的一种预测、判断、综合分析或者关键决策。通过专家的思考、推演、论证,能帮助项目组做出符合业内做法、最佳实践以及项目实际情况的决策,并对项目人员进行启发。

二、渠道来源

专家判断可来自具有专业知识或受过专业培训的任何小组和个人。可以通过以下渠道:

1、组织内的其他部门;

2、顾问、干系人,包含客户及发起人;

3、专业与技术协会;

4、行业团体;

5、主题专家(SME

6、项目管理办公室

三、应用场景

专家判断应用十分广泛,几乎覆盖全部知识领域(质量管理除外)。常见场景如下:

1、项目需求解读:对于项目上无法把握或界定的需求,可以咨询行业及业务专家,将技术需求和业务需求进行拉通,保持理解一致;

2、项目变更评审:针对项目涉及的工程、技术、人员变更,可以咨询专家,了解方案合理性、合规性,以及变更引发的风险识别;

3、项目验收评审:项目验收时,项目组或者甲方通常会邀请具有资格的专家对项目交付物及文档进行检查,确保项目符合验收要求;

4、项目管理咨询:项目实施过程中,应提前规划好可咨询的专家团队,定期沟通、咨询,为项目交付出谋划策,致力于探索最佳实践。

第七期 虚拟团队

一、定义

具有共同目标,在完成及角色任务过程中很少、或没有时间面对面工作的一群人。由于没办法长期面对面协作,因此更多采用现代信息化技术,借助互联网进行工作配合并沟通,完成既定工作任务。

二、范围

虚拟团队主要包含以下方面:

①地理位置分散的员工

②为项目团队增加特殊技能的员工

③在家办公的员工

④工作班次或者时间不同的员工

⑤行动不便或者残疾人

⑥因差旅费用过高而被否决的项目涉及的成员

⑦因外界环境原因导致必须分散办公(如疫情)

三、分析

相较于传统项目团队,虚拟团队有以下特点:

①团队更多借助互联网及信息技术

②沟通主要依赖语音及视频通话

员工管理难度较大,对项目管理成熟度提出新的要求

④项目经理需要更清晰职责与分工、配合、优劣势等方面,以便适应团队状态,提出更好的管理措施

1、优势方面:

①不局限于工作场景和形式,可以充分利用成员自己的资源

②不受时间、地理位置影响,更注重以成果为导向

③为招募团队成员提供了新的可能性

④人员成本可能会降低

2、缺陷方面:

①成员沟通尤为重要,可能产生误解

②成员之间不是完全熟悉,可能有孤立感,难以分享知识和经验

③信息化和通信技术成本增加,信息管理困难

最后,可以结合项目特点自由匹配项目团队类型,组合化管理,提升团队整体能力。(来源:一个酱缸 阿酱)

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2023年12月20日 上午8:30
下一篇 2023年12月20日 上午8:42

相关推荐