原文英文,全文已翻译并缩减节选内容,供HR及技术部门招聘审核用。
文章撰写日期:2022年7月20日
导师:
IT项目研究背景:
第一章项目管理导论
项目目的:
本案中正在进行的项目是联邦调查局信息技术升级项目或FITUP。然后,《FITUP》被分为三个部分,并命名为三部曲。该三部曲的创建是为了升级该局的“56个外地办事处和22000名特工和支持人员,配备新的台式机和服务器,支持网络的一些最重要的调查数据库系统,最重要的是虚拟案件文件(VCF)系统”(Goldstein,2005)。VCF系统的目的是翻新旧的基于纸张的自动案件支持系统(ACS)。新的VCF系统将允许联邦调查局“美国任何地方的特工”(Marchewka,2010)访问和搜索各种文件,还允许他们将一个案件的可能线索连接到另一个案件。它还将消除将硬拷贝文件扫描到计算机文件中的需要。该项目在提高工作流程效率的背景下,推动了变革,为该局创造了价值。该项目的目的是独一无二的,因为它需要升级一个高级安全政府机构的it基础设施。它需要许多各方和利益攸关方的合作才能取得成功,但事实并非如此。
涉及的利益相关者:
该项目的利益相关者在其生命周期内发生了变化。该项目在当时担任联邦调查局局长的路易斯·弗里的监督下开始。罗伯特·穆勒随后接替了他。罗伯特·穆勒聘请了罗伯特·基亚拉迪奥,后者随后聘请了拉里·德普。穆勒和基亚拉迪奥都聘请了C.Z希金斯,希金斯后来任命拉里·德普为三部曲的项目经理。2003年12月,Zalmai Azmi被任命为联邦调查局代理首席信息官,负责该项目。因此,利益相关者名单随着时间的推移而变化,但一个一致的利益相关者是国家工商总局或科学应用国际公司,该公司被联邦调查局外包用于系统的开发。联邦调查局的现场特工和支持人员也是利益相关者,因为他们依赖于项目的成功。负责交付台式机硬件的承包商也是利益相关者。另一个利益相关者是为该项目提供资金的美国国会。此外,航空航天公司是一个独立的利益相关者,因为他们的唯一目的是审查和“评估系统要求是否准确和完整”(Marchewka,2010)。
管理问题:
对本案例研究影响最大的因素是管理。在整个VCF系统开发过程中,联邦调查局局长一直在变化。该项目在联邦调查局局长Louis Freeh的领导下开始开发。然而,在9/11袭击事件发生后,罗伯特·穆勒接替路易斯·弗里担任联邦调查局局长。由于9/11袭击事件,穆勒面临着外部和内部的压力,这促使他加快了项目的进度。穆勒随后聘请罗伯特·基亚拉迪奥担任行政执行助理主任。Chiaradio随后审查了该计划,并得出结论,该计划不会为联邦调查局特工提供任何价值。Chiaradio随后聘请了Larry Depew,后者也得出了同样的结论。然后Chiaradio和Depew都让Muller相信他们的结论是正确的。我认为,这是管理层犯下的错误。这阻止了上汽集团为ACS中期项目开发基于网络的界面,并使他们从头开始开发一个全新的应用程序。稍后将讨论的另一个原因是对上汽集团的要求发生了变化。
之后,Muller和Chiaradio聘请了C.Z Higgins,他是一名IT专业人士。希金斯的第一个决定是任命Depew为VCF的项目经理。然而,Depew没有项目经理的经验,却被派去管理一艘正在沉没的船。他没有项目管理技能,也不知道时间、成本、质量或沟通等方面。他不具备管理利益相关者之间关系并帮助他们理解项目的技能。正如你所看到的,管理层确实对这个项目的失败负有责任。联邦调查局没有人力资源来管理这个项目。正如研究所述,他们没有合同经理、项目经理或IT高级人员来指导项目。
联邦调查局三部曲的管理系统是矩阵结构,因为个人必须向多个老板报告。这是有道理的,因为在项目的整个生命周期中,管理层都在不断变化。除此之外,上汽还表现出了邪教般的行为。当安全、信息和决策系统领域经验丰富的专业人士Matthew Patton向上汽集团提供反馈时;他们告诉他“不要捣乱”(Goldstein,2005)。公司对他的意见缺乏兴趣,这充分说明了事情是如何出错的。报告稍后将对此进行更深入的讨论。
第2章项目管理和信息技术背景
资金和成本考虑:
Trilogy项目面临范围、时间和成本等限制。联邦调查局已获得3.798亿美元,用于在3年内完成该项目;该项目已承包给上汽集团。在整个过程中,联邦调查局在该项目上花费了5.81亿美元,但该项目随后被放弃。《三部曲》项目的资金是一个问题,如果马修·巴顿的建议得到考虑而不是被忽视,这个问题本可以避免。他表示,国家工商总局“没有试图控制200名程序员的成本,因为只有几十名程序员就足够了”(Marchewka,2010)。他还表示,上汽集团正在为VCF系统编写代码,而没有考虑Novell的GroupWise电子邮件系统等现成产品;该机构已经在使用。此外,Patton提到,上汽试图在没有真正了解他们想要系统做什么的情况下设计整个应用程序逻辑和设计布局。他还指出,上汽的“态度是,这是别人的钱,所以他们会随心所欲地挥霍”(Eggen&Witte,2006)。然而,巴顿的担忧被联邦调查局管理层忽视了,他被雪莉·希金斯公开嘲笑。因此,如果所有这些问题都得到解决,资金本可以节省。然而,该项目现已超出预算,仍有工作需要完成。
时间限制考虑:
此外,整个项目的时间也是一个管理不善的制约因素。为了进一步阐述马修·巴顿的观点,上汽从事三部曲项目的人数远远超过了需求。如果只有几十个程序员在做这个项目,时间限制是可行的。相反,大约有200名程序员负责这个项目。因此,从理论上讲,它应该更快。此外,当“穆勒指示加快三年计划”时,三部曲的时间表发生了变化(Verton,2003)。这意味着项目进度正在加快,导致上汽集团更快地开发软件。因此,从长远来看,可交付成果是未完成和不完整的。更糟糕的是,Chiaradio和Depew在审查了该项目的计划后,说服Muller需要对VCF系统进行全面检修,并且目前的项目对代理商来说还不够。随后,国家工商总局被指示停止ACS网页界面的开发,并开始开发一个全新的应用程序。
然而,这并不是唯一一次发出变更请求。2003年,“大约提出了400项变更请求”(Marchewka,2010)。这些请求将对软件的不同组件产生各种影响。因此,该项目需要更多的时间和资金。这里的错误再次在于管理层。如果在项目开始时就正确明确地定义了需求,那么就不需要不断重新定义需求。根据美国政府问责局的Randolph C.Hite的说法,“如果有一个架构,这些需求问题的可能性就会大大降低”(Goldstein,2005)。如果Larry Depew在一开始就制定了指导方针,这个问题可能就可以避免了。请求的变更不仅影响了成本和时间,还影响了项目的范围。
范围约束考虑:
该项目最初旨在升级硬件和软件,并开发一个支持网络的系统,这将改善工作流程,减少该局员工的时间。其中最重要的是VCF系统。该系统将通过消除对纸质文档的需求和将所有内容数字化,实现旧ACS系统的自动化。简单地说,VCF系统的目标是用新的外观和功能改造旧的ACS,但旧的ACS系统仍将作为骨干新系统。然而,在FITUP提案启动时,甚至在获得资金批准后,“联邦调查局没有首席信息官、现有系统的文件或翻新计划”(Goldstein,2005)。这意味着项目从一开始就没有设定需要满足的要求或目标,甚至没有参考的时间表;这最终导致了它的失败。后来,项目开发Chiaradio和Depew说服Muller,对VCF系统进行全面检修是最好的,目前的项目对代理商来说还不够。这彻底改变了三部曲的范围。
最初,它只是用新功能对当前系统进行改造,现在它是一个全新的应用程序,需要“改进的用户界面和数据库管理系统”(Goldstein,2005)。这改变了项目的要求和目标。此外,在开发后期,提出了400多个更改VCF系统组件的请求。因此,这说明了设定要求和目标以及创建时间表以保持一切顺利运行的重要性;这个案例研究已经证明了这一点。
用户测试考虑:
为了进一步阐述我之前的观点,Depew还与SIAC举行了会议,为所需的系统提出了新的要求。他想采用一种称为闪光切换的高风险策略。这涉及联邦调查局特工在一天结束时注销ACS软件,然后在第二天早上登录新系统。作为一个项目管理知识有限的人,这是一个人可能承担的危险风险之一。更糟糕的是,没有对新系统进行用户测试。缺乏用户参与导致难以实际理解所请求的要求是否得到了满足。如果没有对原型进行用户可用性测试,就不可能确定VCF系统是否正常工作。在案例研究的后期,一直使用这种新系统的代理人表示,该系统增加了他们的工作量,而不是减少了工作量;这是它的预期目标。
第3章项目管理过程组
如果将过程组直接应用于项目的各个方面,三部曲项目的核心不平衡和无组织问题本可以很容易地得到解决。在规划过程开始时,他们决定将开发团队分成小组,“为了加快开发,上汽集团将其VCF开发团队分为八个小组,以便他们可以在系统的不同组件上并行工作。”(Goldstein,2005)。尽管这可能对项目有很大帮助,但外部因素压倒了他们的青睐,例如新任命的VCF项目经理Depew没有IT项目管理经验。
至于规划,在整个案例研究中,很明显,沟通不畅是导致项目失败的主要原因,“一旦他们看到我们编写的代码的产品,他们就会说,‘哦,我们必须改变这个。这不是我的意思。’这导致2003年提交了400个变更请求。这些持续的变化不仅对程序,而且对员工士气都产生了重大影响,因为大多数这些变化都是在代码已经呈现之后发生的。这个项目的规划似乎是由一个对IT基础设施没有充分了解的人完成的,“问题因……低估了同时让所有22000名用户上网会给网络带来多大压力而变得更加复杂。”(Goldstein,2005)。这些不切实际的目标与不明确的要求相匹配,极大地影响了项目和国家安全。
2004年,当阿兹米被任命为联邦调查局首席信息官时,他成为唯一一位每天参与新的国际奥委会项目工作的首席信息官。他实施了开发计划并应用了控制机制。然而,仍然认为系统要求不能满足用户需求。
在项目的执行阶段,很明显规划阶段没有得到应有的重视。由于缺乏规划,出现了许多意想不到的问题。这导致了时间表的严重延误,并使纳税人用于该项目的资金遭受了巨大损失。
由于管理层的许多变化,对项目进度的持续监督变得越来越困难,“联邦调查局有四个不同的首席信息官和14个不同的经理。”(Hayes,2005)。不断变化的监督是导致与员工沟通不畅和方向错误的一个重要因素。当项目中途需要实施不同的想法时,他们的很多努力都会付诸东流。
流程开发的最后阶段做得很好,因为似乎许多相关人员都从这个案例的失败中吸取了项目管理方面的教训。许多警告信号被忽视,由于几乎没有风险规划,项目的失败是不可避免的。
敏捷方法肯定会对项目有所帮助,因为设定更小更现实的目标将有助于更快地达到里程碑。例如,选择编写一个新的电子邮件应用程序而不是使用现有的应用程序是一个不必要的更改,导致许多安全问题在报告时被忽略。尽管看起来大多数项目的问题源于对it基础设施缺乏了解。
第四章项目集成管理
在项目开始时,为项目选择过程概述了许多目标。它的重点是为所有代理人和工作人员提供新的台式机和服务器,并重新设计案件系统,使其更容易访问文件。虽然没有使用加权评分模型,但从一开始就设定了主要目标,并在整个计划制定过程中实施了许多更改。另一个目标是建立一个更容易的文档搜索系统,使员工能够将潜在客户与来源联系起来。案件和记录管理系统也需要完全数字化。
虽然本案中没有提到项目章程,但正式的变更请求不断发送给利益相关者,要求对项目进行所有变更。有时,它会与更多资金的请求一起发送。最初的3年计划被多次推迟,导致缺乏资金。
项目工作由上汽集团直接管理,上汽集团对项目有很强的控制权,他们不愿意接受员工的批评。当巴顿意识到创建这个项目所面临的风险时,他受到了威胁,不再进一步推进,只是做自己的工作。由于项目的紧迫性,许多风险都是在没有风险控制的情况下承担的,例如病例系统,“特工在回家前会从ACS注销……然后第二天早上登录新系统。如果新系统不起作用,就没有回去或备份计划。”(Goldstein,2005)。员工必须立即适应这些新变化。
第五章项目范围管理
VCF不遵守项目范围管理规则。最初,其初步范围计划的失败之一是该团队没有为详细的项目范围声明做好准备。项目经理未能确保所有需求都得到适当的分析、管理和记录。团队积累了大量的用户需求,项目的设计范围过于宽泛和庞大,导致范围蔓延。也就是说,计划永远无法跟上新要求的变化,因为“基于承包商知道其内部工作要求的毫无根据的信息提出的要求[…],而不是同意做他们知道无法完成的工作”(Dreitlein等人第30节)。而且,它缺少检查需求的迭代方法。第三,项目经理没有正确定义需要详细项目范围声明的范围。因此,该项目尚未满足范围描述、产品用户验收标准及其所有可交付成果的详细信息,正如联邦调查局所提到的“当时,IT系统的采购流程尚不清楚。联邦调查局没有向国家工商总局提供一套明确的要求”(Dreitlein等人31中的问题)。此外,VCR未能创建和维护定义项目整个范围的工作分解结构(WBS)。团队没有通过不同的方法通过分解或工作包创建清晰的WBS。WBS任务模糊且估计错误,因此利益相关者不知道他们必须实现什么;而且,没有WBS字典和改进。此外,它具有错误的范围验证和控制。计划上的更改已失控,团队无法处理请求、管理和控制这些更改。具体来说,Golstein澄清说:“就在那时,我们开始一个接一个地记录更改请求”(Marchewka中的qrt.,6)。正如Rosencrance所暗示的那样,没有合适的解决方案“联邦调查局没有使用现成的解决方案,而是要求上汽从头开始开发该应用程序,大大低估了该项目的成本和复杂性”(Marchewka,9)。
第六章项目时间管理
计划进度管理:
这个项目始于1990年,联邦调查局特工意识到他们的数据库需要升级。在升级IT基础设施的项目中,整个联邦调查局都希望访问其核心数据库中的数据。VCF应该与他们的主要软件系统、自动化案件支持系统、刑事执法应用程序、集成智能信息应用程序集成。
定义活动:
对于联邦调查局的VCF项目,没有监测指南和任何指标来制定项目计划。根据IT部门和代理商的说法,Trilogy的总成本没有提到实施的关键指标和与这个高调项目相关的挑战。“它不需要具体的完成里程碑,不包括关键的决策审查点,如果没有达到里程碑,也不提供处罚。”联邦调查局IT部门没有优先监控项目进度,因此联邦调查局无法立即采取行动解决Trilogy的问题。在该时期结束时,在进入该项目两年多后,联邦调查局聘请了一名承包商来履行这些项目集成职责,因为很明显需要一名专业的项目集成商来有效地完成这个项目。”
顺序活动:
关于这个项目,存在大量的不明确之处。该项目的具体目标和时间表没有得到落实,导致领导该项目的联邦调查局人员和承包商之间存在几处分歧。这最终导致联邦调查局特工和承包商因该项目的问题而相互指责。项目需要具体的愿景,但这里的愿景对于项目的目标要求并不明确。最初的设计要求失败了。Trilogy项目管理的不一致性和低效性给其技术和时间管理带来了困难。有功能性的骰子.
估算资源:
VCF项目的目标是提供和升级案件管理系统,实施证据管理系统和记录管理系统。在这个项目下,联邦调查局希望从头开始创建数据库,然后他们想对其进行定制。
实施这些系统的目的是消除联邦调查局员工将硬拷贝文件扫描到计算机文件中的需要。
时间 |
实施 |
分析 |
2000年9月 |
国会为联邦调查局信息技术升级项目(FITUP)提供3.798亿美元 |
预算应根据适当绘制的时间表通过,并实现与所有要求相关的项目目标和成本 |
2001年1月 |
国会额外提供7800万美元
|
为什么在一开始就提供额外的资金 |
2001年6月 |
上汽集团授予1470万美元用于软件升级
|
指标与此次升级有关——合格的员工、现实的时间表和适当的基础设施。在我看来,这是缺乏的。 |
2001年9月 |
Robert S.Muelier任命了联邦调查局局长,Larry Depew聘请了特工,Trilogy也加入了这一行动。 |
他们有工程能力吗 |
2001年10月 |
罗伯特·基亚拉迪奥被录用了。Chiaradio和Depew说服Mueller FBI需要新的数据库管理系统。 |
他们没有正确评估遗留系统、安全需求和正确建立企业架构。 |
2001年12月 |
美国联邦调查局告诉要求开发VCF |
为什么他们在启动一个项目一年后决定这样做。 |
2002年1月 |
联邦调查局向国会申请7000万美元,批准7800万美元
|
完全低估了进度和预算。
|
2002年1月 |
Sherry Higgin被聘为项目管理办公室
|
为什么他们一开始没有注意到这一要求。
|
2002年1月 |
JAD与Depew团队和SAIC工程师一起定义了新VCF系统的要求
|
这是一团糟。无效的工程和时间管理。
|
2002年7月 |
参议员们对希金斯印象深刻
|
|
2002年9月 |
上汽集团聘请Matthew Patton审查VCF设计文件
|
现有的网络和对如此复杂的实施难度的低估导致该项目聘请上汽集团进行审查。 |
2002年12月 |
国会增加资金=1.232亿美元
|
公共资金因项目管理不善而浪费
|
2003年1月 |
上汽集团正在处理联邦调查局提交的变更请求
|
59个问题,相关问题源于原17个不足之处。基于需求变更和FBI故障,出现了19个问题。另外40个是上汽集团的问题。
|
2003年11月 |
Zaimani Azmi被任命为临时首席信息官
|
|
2003年12月 |
上汽交付原型VCF=17个缺陷
|
所有事情都导致了FBI和SAIC相互指责 |
2004年4月 |
DynCorp延迟两年交付Trilogy的基础设施
|
|
2004年6月 |
Azmi与SAIC共同启动了IOC项目,航空航天公司被要求评估VCF。希金斯和德佩辞职了。 |
|
2004年6月 |
Azmi要求SAIC更改VCF的电子溢流功能,初始运行容量(IOC)=1640万美元
|
联邦调查局要求获得1640万美元的初始作战能力
|
2005年1月 |
国际奥委会测试和航空航天公司提交报告 |
|
2005年2月
|
监察长办公室作出报告和参议院听证会 |
|
2005年4月 |
VCF项目结束=1.7亿美元
|
我对这个项目失败的最后总结是:他们没有定义所有任务并设定顺序,这是产生项目最终交付成果所必需的。 一开始没有确定资源。完成任务的持续时间,并估计整个项目时间表的持续时间。他们没有开发缓解风险,也没有在项目执行时解决项目进度的变化。
|
如案例研究表 1 中的 RPA 收益指标所示,成本效益(相对于员工)和周期时间处理(相对于时间)是衡量标准。考虑到这一点,早期进行了许多节省成本的改进,例如将之前由员工负责的工作实现自动化。这带来了更好的质量管理、更高的生产率等。在启动阶段,强调尽可能多地实现工作自动化。对大多数工作的这种自动化几乎保证了更高的质量标准和更可预测的结果。这也使员工能够从事更多高回报的工作,减少重复性任务。
质量管理的一个重要部分是在监控和控制阶段,因为这是发现问题所在从而需要改进的时期。项目团队通过在整个阶段持续每天开会并相应地审查项目计划来执行质量保证,“……该组织使用微软办公工具来管理项目,以实现沟通和解决问题的目的”。他们还监控团队成员的技能,比如他们的习惯、态度以及彼此之间的行为。对这些行为进行改进能打造一个更强大的团队,这对任何项目的成功都至关重要,而且很容易根据输出的工作质量来察觉。
在收尾过程中,通过一份反思文档来保证质量,该文档记录了团队所吸取的经验教训。此外,还创建了一份客户调查问卷以获取反馈。团队还反思了他们与竞争对手的不同之处,这对于了解自身在哪些方面可以改进以及哪些方面已经做得比别人好至关重要。TECHSERV 在评估自身在哪些方面可以提高质量、降低成本以及提升生产力方面做得非常出色。
第 9 章:项目人力资源管理
以下表格对详细的资源管理计划、主要人力资源问题的评估以及领导力、情商、激励、权力和影响力方面的识别进行了分析。并且,该过程主要涉及项目资源规划、分配、劳动力规划的协调、执行、早期指导以及监控和控制。
(有个很长的表格)
第 10 章:项目沟通管理
i) 规划沟通管理:TECHSERV 项目管理西班牙和中国团队通过规划分配到五个过程组的活动和任务来启动项目。这些小组成功地完成了从启动、规划、执行、监控和控制到收尾的 RPA 项目。向项目顾问提供了适当的项目信息和更新。
ii) 管理沟通管理:
项目团队在整个项目期间执行各种假设情景分析。项目组通过适当的渠道传播信息。他们还注重从用户验收测试中收集反馈。
1) 沟通管理计划:
2) 企业环境因素
3) 组织过程资产
4) 记录
5) 项目管理计划
iii) 监控与控制沟通管理:
在监控与控制沟通管理中,需要考虑以下因素和问题。
需要哪些信息以及如何收集这些信息?
答案:TECHSERV 让其项目组能够花更多时间分析数据、了解业务需求,并推动更具预测性的结果,以实现此项目的目标。在启动此项目之前,他们投入了适当的时间和精力来支持 RPA 技术。范围满足项目目标和组织需求。
应在何时(以及以何种频率)收集这些信息?
答案:TECHSERV 定义了此项目的不同阶段,并在每个阶段分配任务。项目组让利益相关者参与进来,与西班牙和中国的不同团队进行有效沟通。他们还创建了子流程,集中精力并及时执行。
“此子流程侧重于验证产品退货发票以及随附信息,例如到货死亡编号”
(表格)
从报告的角度来看,这些信息应该如何呈现?
答:项目团队对范围、质量以及风险和机遇进行了有效监控和控制。
谁应该准备和接收报告?
答:该项目的高级项目顾问定期收集团队的数据和更新。
第11章:风险管理
TECHSERV 的机器人流程自动化 (RPA) 已使风险管理计划、风险识别和分析、风险应对计划和控制流程达到最佳性能。最初,由于团队已经对所有可能的挑战、威胁或风险进行了数值评估和列出,因此,关于项目经验不足、结构/流程、财务、人员和应用于项目的新技术的定量风险分析可以通过风险分解结构等特定技术来解决。具体而言,缺乏技术技能和项目管理领导力,以及无法运用云计算、可视化和流程机器人等尖端技术,都可能对项目的成功构成潜在的负面风险,正如案例研究中所述,“已识别的风险包括缺乏员工对重新装备的认同、机器人无法按预期运行[...]、新角色不明确以及缺乏关于RPA影响的沟通”(Carden等人,79)。事故的发生可能造成巨大的资源浪费。案例研究指出,事故主要发生在项目执行过程中,“其他风险包括试点期间的运营中断,以及由于与软件和硬件资源相关的新安全方法而导致的与破坏内网安全相关的外部威胁”(Carden等人,79)。此外,项目团队可能已经进行了分析,根据风险发生的概率和影响对风险进行了定性优先级排序,但案例研究尚未直接揭示这一点。此外,为了消除这些风险并将其对系统的影响降至最低,需要制定适当的风险应对计划。例如,团队聘请经验丰富的外包专家作为应对技术风险的一种解决方案,以便首先迭代解决最棘手的问题。案例研究指出,“缓解运营中断的应对计划包括项目团队对运营进行测试[...],聘请接受过安全漏洞培训的IT专家和工程师,以在实施期间和实施后防范外部威胁”(Carden等人,79)。之后,组织执行控制流程,并持续更新项目文档,以避免风险分析中列出的潜在风险,包括工作绩效、变更请求和组织流程资产。
第12章:采购
RPA的采购项目管理可以通过采购计划提供独特的视角。由于RPA是团队过去持有和处理过的新系统,因此组织最初计划通过采购外包和自主研发分析来应对潜在的负面风险,尤其是缺乏技术和项目经验;因此,该系统需要外部有偿援助的领导、培训、指导和其他技术参与,因为“外部顾问提供项目领导,包括项目团队成员提供日常项目管理,包括解决问题、消除障碍和审查可交付成果”(Carden,et al。74)。并且,这些采购活动不仅被视为相应风险的应对措施,也被视为对内部和外部威胁的预防。此外,团队成员已应用来源选择标准对项目提案进行评分。也就是说,他们从一开始就与潜在卖家建立关系,因为“组织选择供应商协助实施并利用其提供商在项目内开展开发活动”(Carden,et al。74)。因此,该项目提供了被认为是 RPA 系统最佳选择的供应商或厂商,这也是与卖家签订采购合同的标志。虽然案例研究暗示可能涉及成本补偿合同,但主观上RPA可以根据不同情况和变化涵盖所有其他三种合同类型,例如固定价格、工料合同和单价合同。采购完成后,团队实际上会生成工作说明书(SOW),其中描述了该项目所需的工作流程和合同信息。之后,采购控制已启动。所有外包项目都受到进一步的组织需求和利益相关者需求的严格管理和控制,正如案例研究所暗示的那样,“一旦内部资源……就不会使用外部顾问来执行第二个试点项目”。
结论:
总而言之,TECHSERV 的机器人流程自动化 (RPA) 项目在成本、人力资源、质量、沟通、风险和采购管理方面取得了相当大的成功。事实上,这些管理措施最大限度地降低了风险和资源利用率,并优化了项目效益和效率;而且,这些管理措施可以跨职能运作。合理的成本管理可以减少项目预算,提高有限资源的利用效率。人力资源管理和和谐的沟通可以确保工作量,避免团队成员之间的冲突。质量管理可以生产符合质量标准的产品和服务,并确保任务的一致性。充分的风险识别和灵活的应对措施不仅可以提供内部解决方案,还可以合理地采购外部资源,从而最大限度地减少对 RPA 的损失和影响。此外,撰写更佳项目分析的关键在于团队凝聚力和沟通能力,以及良好的写作和批判性思维能力,团队成员必须牢记这些才能取得更好的学习成果。与 FBI VCR 项目失败的分析相比,RPA 在很多方面都展现出了卓越的项目管理能力。此外,这两个案例通过逆向的策略和战略管理形成了有趣的对比,引发我们重新思考和反思项目管理的重要性。最重要的是,它们各自都实现了优化并达成既定目标的最佳实践。