2021年5月5日星期三09:00

第三部分:确定IT项目复杂性的简化方法。通信和IT项目复杂性。

写的
第三部分:确定IT项目复杂性的简化方法。通信和IT项目复杂性。

摘要

本文研究了项目沟通的主题相对于项目复杂性的主题。

它检查了沟通在项目中扮演的角色,它对项目复杂性的影响,以及如何以及为什么应该组织团队来最大化沟通的价值。本文是关于项目复杂性这一主题的系列论文的第三部分。这些论文见参考部分。

关键字

项目沟通,项目复杂性,项目风险,项目管理,项目难度,风险管理

介绍

项目复杂性是一个最初在90年代中期提出的研究主题,自那以后有数百篇关于该主题的论文。出于上下文目的,术语“项目复杂性”与“复杂项目”不同。下面是术语“项目复杂性”的一个普遍接受的含义。

“两者之间的区别是项目系统元素之间关系的本质(Kiridena, S. & Sense, A.,2016)”,查普曼解释道。例如,大型工程和建筑项目被认为是复杂的项目,但它们不一定是复杂的项目(前提是与环境的相互作用和影响是微不足道的或相当可预测的)。如果一个项目的各种元素之间的关系本质是非线性的,因此,将导致系统的突发行为,那么它就被称为“真正的”复杂项目(Whitty & Maylor, 2009;Maylor等人,2008)”。

定义通信

沟通是项目成功的关键。其中一个网站提供了21个项目交流的例子(John Spacey, 2017)。该来源列出了以下交流的例子:项目启动:变更管理、需求、评估、计划和调度、风险、问题、设计、状态、治理、财务、采购、供应商、冲突、性能、涉众、控制、执行、测试、启动和结束。下面的网址是引用在参考部分。

https://simplicable.com/new/project-communication

将典型IT项目中不同角色所引用的例子映射出来(下面的图一),就可以理解一个成功项目所需要的纯粹的通信规模。基本上,项目中的每个人都需要一个沟通渠道,因为一个或多个特定的原因。但正如我们所看到的,并不是所有的交流都与团队中的每个人相关。交流开始时只是狭隘的集中,然后随着项目从初始阶段转移到计划阶段,并在执行阶段达到顶峰,交流就会逐渐加强。如果一个大项目中的每个人都必须参加每一次会议并听取所有发言,这将是一种巨大的时间浪费,否则这些时间可以用于富有成效的活动。另一方面,团队成员不参加与其职责相关的会议可能导致信息丢失,并对项目产生负面影响。沟通过多或过少都会导致时间的浪费,并增加风险和问题发展的可能性。

partthree1

一般来说,团队中需要的交流越多,对项目复杂性的潜在影响就越大。图表二描述了复杂性和通信之间的关系。在图表的右上角列出了一些增加复杂性的因素,在左边列出了降低复杂性的因素。从图表中我们可以看到,右边的用户基础越大,沟通水平就越高,也就越复杂。在左侧,关注的是较少的观众,比较简单。量表也适用于其他因素。如果需求没有被很好地理解,那么更动态的项目可能会增加更多的沟通和复杂性。这就是为什么大规模的公司范围的软件开发项目比已经开发和测试的打包软件要复杂的原因。

parthree2

考虑到项目中交流的规模和复杂性,很容易看出为什么战略性地管理项目中的交流是至关重要的。

组织子团队来降低复杂性

无论项目团队的规模或复杂程度如何,都必须对沟通进行管理,以便适当地传递和过滤重要的信息。这样做可以增加通信的价值并降低项目的复杂性。管理层将采用的一个这样的策略是在称为子团队的项目中创建团队。它们通常按角色、功能或关注特定目的的逻辑分组进行组织。为了说明为什么项目上的沟通会增加复杂性,下面的图表III描述了一个项目上由8(8)个资源组成的团队,这些资源具有可能的沟通渠道。通道数的公式是R (R-1)/2,其中R =资源的#。


广告

partthree3

一个8人的团队有28个沟通渠道。人们很容易想象混乱的可能性。在开会、想法公开交换的情况下,事情可能会很快失控。团队增加1人,沟通渠道增加到36人。

现在,如果我们使用相同的8(8)种资源,并按照下面的图表IV组织它们,分成两个(2)子团队,中间加上一个“过滤器”,我们可以将沟通渠道的数量减少一半以上,从28(28)个减少到13(13)个。此图中的“过滤器”表示捕获并在子团队之间共享相关信息的资源。这种组织团队的方式提供了更少的复杂性和更大的关注点。

partthree4

另一方面,如果过滤器不能正常工作,重要的信息可能会丢失。这种情况经常发生在变更控制领域,在这个领域中,变更是在没有与整个项目团队沟通的情况下进行的,而影响分析是在没有考虑业务的所有领域的情况下进行的。即使有优秀的团队沟通,这也是一个挑战。显然,创建子团队有它的目的,当焦点是特定的角色时,其他人不需要参与或增加任何价值。可以说,对子团队的输入可以局限于子团队,但是来自团队的输出应该进行全面的沟通,以便每个人都能意识到潜在的风险或问题。由于这个原因,我们可以明确地指出,子团队通信的总和并不等于整个项目所需的通信。此外,这就是为什么即使在最有效地组织团队的情况下,一个项目的整体复杂性仍然较高的原因。

partthree5

组建项目组

从图V可以看出,将项目团队组织成逻辑分组是一种沟通渠道和降低复杂性的方法。这只是一个例子,图表并不意味着所有的项目团队都应该有一个指导委员会或SMEs。项目可以使用瀑布方法或敏捷方法。例如,项目管理子团队可以是一个或多个Scrum master。在阴影椭圆中表示的是团队中的所有通信,包括子团队。子团队之间的一些交流是经过筛选的,非常重要的是每个子团队内部发生的交流没有在此图表中描述。不是所有的通信都可以被过滤。一些未经过滤的交流是团队成员之间的非正式交流,对所有团队成员的一般交流,以及其他不特定于子团队的交流。大多数项目都有与解决问题或深入研究特定主题的细节有关的会议。一些未经过滤的交流是必要的; some of it may not be. In addition, some of the sub-team resources could be working on other projects. In this example, a Steering Committee could be overseeing all projects, like a PMO board. Departmental Management VP/Director/Managers only get involved to resolve issues or risks and are generally not on the formal project team. SMEs could be used to seek advice on requirements or design and usually consulted sparingly. External resources could be vendor consultants. The sub-team that poses the most risk to the project is Shared Resources. Those resources might be required to execute a set of tasks, potentially working for a sub-team. An example might be installing a server, network equipment, database creation, or even establishing a firewall rule. Most likely, as the name implies, they are multi-tasking for a variety of initiatives, not necessarily confined to just project activity.

虽然图表V描述了子团队在一个(1)项目中主要进行交流,但在图表VI中经常会出现这样的情况:团队中的每个人在其他项目中都是多任务处理的。资源在项目(阴影区域)中进行沟通,对于其他项目也是如此。

partthree6

不仅有相同数量的内部沟通正在发生,而且同样的资源正在为其他项目进行沟通。这种情况会给某些资源和整个项目团队增加很多压力。我们可以很容易地看到为什么多任务处理会显著地增加交流,增加项目的复杂性和风险。

结论

项目中的沟通服务于多种目的,对项目的成功至关重要。一个成功项目的整个生命周期,从开始到结束,依赖于各种有目的的交流。为了减少项目的复杂性,必须将资源组织成更小的子团队,这可以减少交流的总数,但同时,通过适当地疏导和过滤信息流,增加交流过程的价值。

参考文献

史派西,约翰。“项目沟通的21个例子。”Simplicable2017年10月25日。

https://simplicable.com/new/project-communication

Kiridena, S. & Sense, A.(2016)。项目复杂性分析:来自复杂性科学和项目管理文献的见解。项目管理学报,47(6), 56 - 74。

C. macue(2021年3月)。确定IT项目复杂性的简化方法。项目时间。//www.worldcup-bet.com/articles/a-simplified-approach-to-determine-it-project-complexity.html

macue, C.(2021年4月)。第二部分:简化IT项目复杂性的方法。项目时间。

//www.worldcup-bet.com/articles/part-ii-a-simplified-approach-to-determine-it-project-complexity.html

康拉德MacCue

Conrad MacCue是IT管理专业人士,在IT领域拥有超过30年的经验。最近,他是Bed Bath and Beyond的项目管理总监,也是Symbol Technologies, Inc.的IT高级总监。在此之前,他曾在位于华盛顿特区的通信卫星公司(Communications Satellite corporation)担任多个职位。他目前拥有自己的IT管理咨询业务。

德赢vwin开户

麦格雷戈标志白色网