总论
事物事实上是在这个流程中得以制造的。它很简单但对情境非常敏感。开发流程的原则可以运用于任何工作范围,其核心就是一个授权流程,从组织架构的一个层面到另一个层面。
在某些情境中,这可能被专业方式替代,比如,在敏捷项目中, 可能被scrum开发流程替代。
该流程的目标是:
- 移交工作包的职责;
- 执行工作包;
- 移交已完成产品的所有权。
验收工作包
工作包可以采用很多形式。它可以是由项目群管理团队授权给项目管理团队的一整个项目;或由项目管理团队授权给供应商的子项目;或授权给一个小团队的一个单一的工作包。
无论工作包的规模如何,原则是完全一样的。必须对它的范围和绩效标准进行适当的定义。移交的双方必须清楚工作包到底是什么、接受工作包的人员执行的能力如何。
当移交涉及项目群授权的项目的时候,授权工作的活动可能就是项目任务书的问题、或是项目概述文件的问题。在后者的情况下,授权工作的活动其实是与识别流程一样的。
当移交涉及项目或项目群团队授权工作给供应商的时候,通常有合同的影响,包括涵盖范围与绩效的合同条款谈判。
当授权规模比较小的时候,就变得更像是个人的活动了。它取决于经理对接受工作包的团队成员的技能与可获得性的理解。
无论情境如何,接受工作包的团队或个人,都有责任确保他们理解要求是什么,并且具有执行工作的方法。正式的接受(工作包)可以避免后续的错误理解。
回到图表
执行工作
该活动主要是关于产品的创建。大多数的努力是关于技术功能与流程,而非任何对于项目、项目群与项目组合管理而言独特的内容。在此重要的是协调和监督流程的双向连接。
对工作包具有主要职责的人,需要计划工作并承担适合工作包范围的管理职责。当执行工作时,这位人员要按照工作包接受文件中所明确的质量、进度、资源、成本与风险,监督所有方面或其中一些方面。进度信息必须反馈到上一层级以便与来自其他工作包的信息进行整合。
这是一个双向的活动。来自上一层级的信息,可能会影响工作的执行。例如,批准的变更、相关联工作的延迟、优先排序的变更等等。
在项目、项目群或项目组合不同层级的这种监督与控制之间的联系,是管理组织的重要特征。
回到图表
交付产品
由开发者完成的工作包中产品的交付,与初始的授权一样,受到情境变化的限制。在有些情况下,交付产品活动可能实际上是一个完整的收尾流程。在其他情况下,它包括结束合同或也许只是接收、测试与验收由单个人员开发的产品。
应该加以记录,以确认产品已经被满意地完成与移交。
回到图表
项目与项目群
Praxis中的项目与项目群流程,用于不同的情境。在小项目中,可能不要求单独的开发流程。在大项目中,交付流程可以代表授权给一个团队或外部承包商的工作。在项目群里,交付流程实际上是项目生命周期的概括版。如下所示:
如要获得更多细节,请在图表要素上点击。
在此情境里,项目群层面工作的授权,可能与其构成项目的识别流程与/或定义流程一样。一旦由项目管理团队接受,他们就开始执行工作,即交付流程。最后,项目交付它的产品,由项目群验收,并执行收尾流程。
这表明,生命周期不同阶段的基本顺序及其相关的流程,对所有情境是相同的。区别在于:在复杂的工作中,有更多迭代嵌套的生命周期层面。