Project组合项目案例分享...

显示全部楼层 · 2015-5-19 13:12:21

Project组合项目案例分享

千问 · 2015-5-19 13:12:21

摘要：
本文是作者参与并执行的一个多项目组合管理案例，案例中描述了如何应用信息化的方式建立多项目管理的标准和模板，并能够有效处理多项目之间的复杂关系，本案中所应用的信息化辅助工具是微软Project 2010。
多项目组合管理是项目管理成熟模式的优秀表现，是企业战略选择和实现利益最大化的有效手段。组合管理是将日常管理工作和项目集、项目等相结合，有效调用组织可用资源，并合理安排资源的去向，在最佳的范围控制内，实现组织最大目标、各级中小目标的一些列过程。
Project 2010所提供的三个应用版本（Standard、Professional、Server）中，分别对不同规模的项目提供了建设方法，其中作为承上启下的Project Professional 2010，既可以满足单项目管理的要求，同时能够满足组合项目和多项目管理的要求，本文以下内容将重点围绕如何应用专业版和服务器版实现组合项目管理的应用。
正文：
2011年5月上旬，本人有幸参与某国际知名电子设备生产企业A公司的组合项目管理。A公司在实施此组合项目之前，其项目管理主要以单项目管理为主，单个项目分别由来自不同的职能部门执行，部门之间的合作关系仅限于日常运作中的职能关系，并无项目关系。这种结构导致了项目之间在建立组合的过程中很难实现接口的完整性，且可共享的部门资源也无法得到高效应用。整个大项目的最终可交付成果往往受到单项目或部门的因素而无法保证工期和质量，A公司希望能够建立一套比较合理的模板，以项目或部门为分解结构，实现顶层的大项目管理。
在此要求下，我们提供了可供借鉴的两套体系，并从中筛选最优体系之一供A公司参考，具体过程如下！
一、问题的本质是“有效集成”
现代项目管理的最大困难之一是如何有效的将项目不同部分有效集成，使项目的最终结果处于平衡状态，避免虎头蛇尾的结局。这也正是为什么PMI在其各个项目管理知识体系教材中集成管理总是在其他知识领域的最前面，其目的之一就是希望项目管理者首先是能够站在整体的角度看问题。A公司单个项目的管理如果以部门为单位来看，各个部门都以非常专业的项目结果呈现给企业，比如IT部、采购部、财务部、研发部、生产部、质量保证部等，都将站在自己的部门角度看问题，是典型的职能式项目管理，符合小项目和沟通简单的、资源利用不高的项目特征。最大的问题是部门之间的关系可能导致大量资源的无法有效应用、彼此间的少量沟通使得项目潜在风险的增加，这都是严重制约项目集成的因素。
A公司希望能够给出建议，将这种模式转变为可供项目组合利用的有效途径，我们提供的建议是：第一步：必须打破部门之间的“隔阂”，建立有效的会议机制和有效的资源共享机制；第二：为了能够更快更好的响应这项措施的执行，必须由高级管理层来直接管理和处理第一步所提出的建议；第三：统一接受人力资源的新规定，即统一建立培训机制，为整合资源和建立项目管理标准奠定有效基础；第四：学会使用信息化手段处理日常项目管理工作，将项目管理逐步过渡到与企业同步的项目化管理过程中来；第五：以项目型组织和职能式组织的混合方式建立一套模板，在未来的项目管理中以此模板为基础，实施企业组合项目管理目的。
作为整个建议的第一步，企业需要认识集成的必要性和重要性！

千问 · 2015-5-19 13:12:21

二、建立符合企业要求的项目管理模板
我们根据对A企业的分析，提出两套方案：第一、企业副总裁、或诸如此职能职位的管理者担任项目经理，各个部门作为实施方，由项目经理统一调用，按照项目管理过程中的启动、规划、执行、监控、收尾过程组来实现项目的最终可交付物，这样就弱化了部门之间强有力的职能性，打破了部门之间的沟通障碍，项目的完成将严格按照流水线走下了，更加强调了项目型组织的特征。第二、同样是企业副总裁担任项目经理，但各部门之间仍然以部门为单位，项目被划分为几个独立的子项目，各级部门实现各自的项目成果，最终由项目经理来负责接口处理，实现项目目标。其实第二种方式存在的问题仍然是接口（整合）和沟通，这给项目经理提出了挑战。但这种方式可能在责任分配上更占优势，大家比较明确各自的职责范围。
在权衡了两种备选方案后，我们针对A企业建立了第一套标准，我们分析了其中的优点和缺点:。（1）优点在于：a、项目的目标性和整体性更强，不存在大的接口问题；b、资源利用率明显提升，跨部门的调用成了可行方案；c、沟通明了，部门之间的合作加强；d、大家可以很清楚看到项目进展情况，整体项目更多的体现在“一维时间”上等。（2）缺点在于：a、可能在具体实施细节上无法快速建立合作关系；b、任何一个环节的不到位都可能增加项目的工期和范围、成本等风险；c、打破了传统职能的习惯，团队制度上迎来新的挑战等！
所以我们在缺点方面提供了应对措施：a、必须加强每周或定期的碰头会，尤其对除外责任方面的有效界定；b、对团队实施定期培训，加强主人翁精神，让团队深切体会作为一线干系人的重要性；c、在工作制度和考勤方面提出了新的规定，由高级管理层通过行政权力坚持对此制度的执行。
满足了以上软性方面的要求外，接下来需要具体建立文本标准，并将文本计划通过数据导入，在Project中完美展示出来。因为涉及到的项目数量众多，人员结构复杂，我们并不建议直接将数据通过手动方式输入Project中，而是首先在Excel或Word中建立初步计划、在进行详细审核、逐步细化到模板基准，最后将基准输入到Project中，当然，变更是无法避免的，在建立模板基准的时候，需要考虑变更造成的影响，并能够提供方便变更的措施（虽然我们不推崇不必要的变更）。

千问 · 2015-5-19 13:12:21

三、建立企业项目管理模板
模板可以是项目基准，当然可能还涉及计划中的其他未定因素。在对项目管理计划进行多方面确认后，可以建立初步基准信息。A企业在未来很长一段时间都将执行类似“产品组合项目”的项目管理。A企业提供的产品组合项目的范围比较明确，这给基准计划提供了前提，根据范围定义，可以建立范围说明书，范围说明书包括了诸如：具体做哪些事情的项目范围；最终实现的产品结构和特征的产品范围。根据范围描述，定义工作分解结构，这个环节是重点，工作分解结构的制作是以项目的过程为第二层的控制账户（或下一层为控制账户，但第二层必须是过程级的，顺序必须保持一维），而非部门，这里需要特别强调项目的实施过程必须是之前所提供建议的方案一，即第一层是“产品组合项目”，第二层是按照项目的启动、规划、执行、收尾的过程展示，其中监控作为每个控制账户和工作包的信息记录在工作分解结构词典中，或直接在控制账户上标记说明。第三层是具体细化下的过程组，这里将包括：
（1）启动过程组中，需要明确每个项目在每次执行情况下的概要目标，概要预算和日期，并明确副总作为项目经理统领整个项目，各个阶段或子项目的子项目经理的任命，资源的可用和概述等。同时需要记录在每次项目实施过程中需要涉及到的干系人信息，争取在项目启动阶段把具体可能涉及到的人员分析到位，避免后面的工作受此影响。这里需要注意的一点是，A公司所使用原材料的采购来源于外部，可能的情况是作为采购部将在项目启动阶段需要做更多工作，比如对采购信息和采购材料的各种分析，供货商的供货要求，采购部门可能要站在甲方的位置强调此过程的项目管理重要性。好在此项目大部分是内部项目，一些对外的行政和行销将不是本文讨论的重点。
（2）规划过程中将是对未来需要执行的工作进行详细计划的过程，这个过程是A公司进行组合管理的重点。通过详细的规划，在执行中得到验证后，便可成为拥有基准作用的模板。规划中需要处理的事情包括，具体需要做哪些事情，即项目范围管理的除外责任界定，各种制约和限制因素（风险方面）的考量，具体需要执行的工作包的细化；项目活动的定义，活动的持续时间和所需资源统计，活动与活动之间的关系建立（本部分内容是A公司项目最为强调的内容，因为涉及多个部门对多个错综复杂的任务进行协同作战，极容易出错），建立进度网络图（稍后会说到如何通过Project建立进度网络图）；资源的建立过程中，需要考虑外购和内部两块资源，对来自采购、人工费率、内部消耗资源折算费率、应急储备费率都需要进行统计，形成项目预算（BAC），需要注意的是，我们在这里没有将管理储备作为整个预算的一部分，因为管理储备不作为项目预算的一部分，他是项目以外的，由管理层对其他非项目因素引起的项目问题的可以考虑的间接成本。在质量保证方面，我们通过制度的建立，来保证项目实施的过程质量，对产品质量，A企业已经拥有非常成熟的考核和审计标准，我们将A企业质量管理方面的内容全部接纳到整个计划中来；人力资源方面，我们对内部的各级部门人员的责任分配与绩效考核作为主要的目标，记录在整个项目管理计划中；沟通作为硬性指标，必须以周期性方式定期开展碰头会；风险是在启动过程中就应当意识到的，在项目范围制定的过程中，其中的制约因素和假设我们都作为真实要发生的信息全部记录在风险登记册中，以便将来定期观察核实和更新；采购部分我们接纳了采购部所提供的建议（已经趋于成熟），我们将此环节与其他过程组进行了整合。
（3）将规划过程内容输入Project中,本部分内容作为A公司项目组和我们一起负责实施前将数据导入Project的过程，我们将经过详细编制出来的计划通过导入和手动输入的方式，在Project Professional 2010建立了初步计划，建立了以阶段和顺序为主的子项目。这里涉及到了近300个子项目，每个子项目近500条任务，庞大的数据极容易出错，为了减少出错，我们通过团队成员就最熟悉的环节进行编辑，然后整合，对意见不确定的活动，我们采用了德尔菲技术，在无法进一步思考的问题上，我们借助Mindmanager进行了思维发散讨论，得到了初步的活动列表。这里需要强调的一点是，300个子项目我们是通过分开的方式编辑，并没有在一张Project Professional上编辑，虽然在一张上编辑是可行的，但为了避免繁琐的信息出错，我们还是通过自下而上的方式来整合整个项目。A公司20多个部门所提供的资源都将以项目为优先级，所有资源的记录基本也没有问题（人力资源）。
（4）建立任务和资源关系是A公司核心内容之一，我们的实施通过以下几步实现：第一是先在300多个单个子项目之间建立初步的任务关系，这种任务关系是初级的，因为可能涉及到此子项目与其他子项目更深层次的链接关系，我们只是把各自子项目中任务的强制性关系建立了连接，选择性和外部连接关系将通过组合后来实施；第二是通过Project Server 2010实现客户端子项目的集成，在PWA上建立更进一步的项目关系，这里我们首先将子项目之间的关系建立起来（同样通过强制性、选择性、外部三种连接方式），然后在各自有关系的子项目之间再寻找有关系的任务，这种任务按照排列组合下来是非常庞大的，但我们尽量避免蜘蛛网的出现，因为极有可能会因为一个蚊子的出现而使得整个蜘蛛网颤抖。所有任务之间都是FS、SS、SF、FF的关系，我们必须认真考虑这些关系的合理性和可用性，并且我们也需要考虑利用这种时间提前量和滞后量造成的影响，我们同样考虑了对于诸如进度压缩、范围调整、资源受限下的突发事件应对（如众多条关键路径出现的可能影响，资源受限下的关键链的影响等）。另一个核心问题是，任务的建立还需要考虑此任务到底是以什么形式存在，微软Project提供了三种任务类型，即固定单位、固定工期和固定工时，这些都将因为资源的不同而影响任务的工期或工时，比如定期的碰头会，我们必须要采取固定工期来限制此任务。每一条任务都将通过这种关系来设置，当然，可能的情况是批量的任务都保持同一种任务类型（这种任务或许更为简单一些）。在数据库中导入企业资源，可以想象，庞大的任务关系下企业资源显得格外渺小，要很好的将这些资源有效的分配到这些任务中去，而且要不出现冲突和闲置，是相当有难度的，好在我们坚持了下来。
（5）对模板的演示是接下来需要做的事情。我们在此之前并没有采用原型法提供最初的雏形，因为A企业一些成熟的环节还是值得我们直接切入正题的。在经过数周的任务和资源建立，PWA上所呈现的是一个比较完整的组合项目管理（项目群和其他日常工作的结合，比如采购或行政部将以职能的方式参与所有项目过程），PWA上分别呈现了300多个项目的概要或细节，根据具体要求可以一览全局。我们对我们所建立的模板进行了为期七个工作日的演示，从中再更新项目计划和模板中的不合理数据，这符合项目渐进明细的特点。经过测试我们重新肯定了我们所努力的成果，整个模板符合要求。

千问 · 2015-5-19 13:12:21

四、实施项目和监控
我们所建立的模板进过测试后投入运营，服务器必须要技术上的大力支持，避免服务器出错而导致整个链条的变化。此次项目的具体实施将由A企业全体参与项目的人员共同执行，也是本模板投入使用后真正意义上的第一次应用，有惊喜，也有挑战。我们可能面临对新技术的接纳需要一个过程，也可能面临对新管理制度的接纳而任重道远，总之，这个过程将是从艰难到熟练的过度。
在监控方面，我们强调了变更控制的严格程度，所有变更都将必须以正式文件的方式记录并保存，并对变更后的结果进行跟踪记录，核实变更是否合理，我们也建议任何人都可以站在技术或管理的角度提出建议，并通过在Project上来进一步细化和建立新的模板，对旧有基准进行保存，以备未来新项目的借鉴。
结束语
在经过对A企业项目组合管理的实施，我们得出了组合管理最大的特点：一是把握好集成管理至关重要；二是资源的合理利用，即利益最大化；三是所有信息化辅助手段，都将依赖项目管理知识体系和企业的管理制度，否则将无法开展企业信息化项目管理，当然，还涉及其他众多要求和领域。

千问 · 2015-5-19 13:12:21