打开微信扫一扫
志学者
本文是关于项目管理最佳实践系列的第二部分。您可以在这里浏览第一篇文章:“实行项目管理最佳实践”。 作为一个项目管理师和项目管理培训师,我常常会听到的一个问题就是适用于大型项目的管理最佳实践是否也适用于小型项目。小型项目是否需要采用项目管理的最佳实践是每个项目管理者都必须面对的一个重要的问题。 注重项目交付 不建议采用项目管理方法的一个主要论据是:以流程为中心的实践会产生大量的文书工作,而这些对于小型项目来讲是不必要也是不可行的。这是一个非常有力的论据,它使得任何注重文档记录的方法成为交付实际商业收益的阻碍。毕竟项目管理的目的是为了实现项目业务目标,而不是造就档案王国。 目前在软件开发领域,关于软件开发最佳方法的讨论十分活跃。最近,一些专业软件师提出了几个灵巧有效的软件开发方法,因为传统的方法太过着重于文档记录。 这些灵巧的新方法注重于交付软件产品而不是文档记录。了解到这一点,我认为项目管理者们可以从这些用于软件开发的新方法中学到一些东西。简短来讲,它引导我们把管理的重点放在项目交付,而不是项目中的文档记录上。当然,项目管理者们仍然要面对一个问题,就是项目中到底需要多少文档记录? 采纳最佳实践 我坚信“需要决定结果,过犹不及”的道理。可以用一个很简单的方法来测试:如果有助于实现项目的业务目标,那么我们就可以采用这些方法并且记录归档;相反地如果对于实现业务目标没有帮助,那么就不需要在这上面浪费时间。只要明白了这一要点,我相信在所有的项目上,我们都可以在最小程度上实行最佳实践。 下面我们来依次讨论最佳实践的几个要素,看看采用这些最佳实践所带来的收益是否多于其产生的消耗。 定义项目的范围和目标 我们所讲的最佳实践的第一个要点是定义项目的范围和目标。即便是最小型的项目也有它必须要实现的目标。作为一个项目经理,识别出这些目标恐怕也是你的利益所在,因为项目最终是否实现了这些目标是对你的工作的一项重要评估标准。因此,定义并且实现项目的目标是你的职责。 假设你没有定义并且记录下来这些目标,那么你能依赖的仅仅是你上司的仁慈。当你的上司检查你的工作并且认为你没有完成项目的预期目标的时候,清楚地定义和记录下来的目标就是你的一份依据和保险。 关于项目范围的定义也是一样。如果你没有对项目范围给出定义,最可能产生的后果就是你的项目会在行进过程中变得越来越大;尽管在开始的时候你可能在管理一个小型项目,不久以后你就发现这个项目已经大得超出你的预计。 在小型项目中,你仍然需要识别并且记录项目的利益相关者。只有识别出了所有的利益相关者,你才能够保证你的项目目标和交付物包含了他们所有的需要。 定义交付物 总要有人负责实际的工作来实现一个项目的交付物。尽管有时交付物不需要很多时间来完成,我们仍然需要做好必要的记录。让其他人来回顾这些完整的记录有助于发现并且改正其中的错误。 负责实际生产的项目成员会使用这些描述来帮助实现交付物。尽管有时这些描述的长度不会超过一页的篇幅,清楚无误的描述仍然是很重要的。缺少必要的描述只会导致负责生产的成员对交付物产生不定向地理解,最终造成大量的时间浪费在后期对错误的改正上。因此,定义和记录交付物是我们项目管理最佳实践的第二个重要方面。 项目规划 最佳实践的第三个部分是项目规划。假设你要登上一座山峰,你不可能在没有做任何计划的情况下就动身的。即便是爬上你的住所背后的小山坡,你可能也会做一些必要的计划:比如什么时候去爬?需要携带什么必需品?无论管理多么小的项目,你仍然要考虑:需要通过那些活动来完成交付物;估算出这些活动所需的时间;决定所需的人力和其他资源并且对活动和责任进行合理配置。 所有上述内容都需要书面记录,并且在团队成员中进行沟通交流。我见过很多人在这一步遇到阻滞,认为可能需要使用一些项目规划软件,比如Microsoft Project。这其实是一项不必要的开支。一个很常见的现象就是项目管理者浪费大量的时间在怎样使他们的Microsoft Project计划表更美观上,而忘记了使用这个软件以及项目规划的真正目的。 相反地,我认为使用Microsoft Excel的条形表来计划小型项目是最好的方法,因为这个方法即简单又足够。首先在表格的最上面一行填入项目的一些关键日期;然后在左边第一列填入项目的一系列任务;最后在每一个任务的对应位置标出它的起始和完成时间。这样一来每一项活动所需的时间就一目了然了。 除了条形表之外,你需要把项目中的一些重要事件(里程碑)记录下来。这些里程碑代表了一些关键日期,比如完成一些交付物的日期,或者某些主要活动完成的日期等。每一个项目成员的责任也必须明确地记录在项目计划里。 沟通及项目沟通计划 即使是在由两个人组成的项目团队中,项目经理仍然需要将任务和责任分配给另外一个人。项目经理不可以主观地认为即使没有有效的沟通,其他人也明白自己应该做什么。如果项目经理没有给其他人分配具体的工作,那么他们很可能会去做他们自己认为需要的事,而不是项目需要的工作。这样的话结果只有两种可能:或者项目完成的交付物不合要求,或者更多的时间用在完成那些原本应该已经完成的任务上,从而导致项目延迟。 你可以选择通过电子邮件的形式来与其他项目团队成员交流项目计划,或者将计划打印出来然后分发给每个人;或者更好的是你可以召开一个团队会议然后和其他成员一起浏览讨论项目计划。需要记住的一点是,如果项目计划有变更,那么你也需要就这些变更与其他成员沟通。 从根本上来讲,一个项目沟通计划描述了在整个项目过程中每一个利益相关者的信息需求。你的沟通计划需要包含一个矩阵表格,表格中列出每一个利益相关者、在项目过程中他们需要得到的信息、提供这些信息的团队成员的姓名、以及交流沟通的频率和方式等。比如说,项目主办商可能会需要项目经理在每个月的执行会议上做一个口头项目报告。项目沟通计划可以确保每个利益相关者能够及时地从相关的团队成员那里获得正确的信息。 项目跟踪 最佳实践的另外一点是对项目成本、工期和范围的监视跟踪。如果还用之前的两个人的团队的例子来说,那么在这里项目经理就需要知道另一个成员工作的进度。这一点可以通过几种方法来实现,每天用一封电子邮件列出完成的工作内容、未完成的工作、以及一系列遇到的问题等是方法之一。在大多数情况下这个方法是很有效的。 同样的,一个15分钟的面对面的交流也可以达到这个目的。两种途径的结合使用可能是最好的方法。无论如何,项目经理都需要完全掌握项目工作的进程,以便于对项目进行有效地跟踪。 变更管理 变更管理是我们需要在小型项目工作中采用的另一个最佳实践内容。即便是在之前提到的二人项目中,变更也是很有可能发生的。变更方面的要求通常是由项目的利益相关者提出的;而作为项目经理,你需要估计出采用这些变更可能对项目造成的冲击。具体来讲,你需要对变更产生的额外消耗和成本做出可靠的估算。采用某些变更可能会影响到项目的工期,因此你必须对项目的工期和预算了如指掌以便能够正确决定是否采用这些变更。 在小型项目中,变更管理并不需要一个很别致的变更控制面板来帮助你做决定。如果你已经对成本和工期的变化有所估计,那么跟关键的利益相关者的一个快速的讨论可能就足够了。 恐怕在变更问题上你最不应该做的一件事就是轻易地接受变更。即使你认为某些变更很小,在完全掌握它们可能对成本和工期造成的影响之前,你是不可以决定采用这些变更的。这就是我们所说的项目“范围蠕变”,指的是当我们不断的采用变更的时候,项目的范围也悄无声息的不断变大。你的小项目可能在你浑然不知的情况下变得很大,而你也不可避免地无法按时、按照预算完成交付。 风险管理 风险管理是我们运用在小型项目中的最佳实践的最后一个部分。再小的项目也有风险。你必须确保在项目工作之始就考虑到所有的潜在风险,并且每周定期监视10个最重要的风险(如果风险总数不多的话,就监视前5个),同时还要对可能产生的新的风险保持警惕。不恰当的风险管理常常是导致项目失败的一个主要原因。 风险管理的费用是非常低的。在最近的一个项目中,我列出了一个项目中的潜在风险的清单。在10个风险当中,有5个风险是比较重要的。我随后就如何最大程度降低或避免这些风险做了一个计划。完成这些步骤一共只消耗了我几个小时的工作时间。在之后的每个星期,我会用大概半个小时的时间来回顾这些风险同时考虑是否有新的因素。在项目的最后阶段,虽然有的风险的确发生了,但是由于我在项目开始的时候就已经做出了适当的计划,这些风险对项目所造成的影响是很小的。 因此,在项目开始和行进过程中的小小努力会给你带来丰厚的回报。 概要 这篇文章阐述了如何在小型项目中采用项目管理最佳实践,而又避免造成大量的文书工作和费用消耗。这些最佳实践是无数的项目管理者在成千上万的项目工作中的实践所得。它们之所以被称为最佳实践是因为它们总能够帮助管理者实现最佳项目成果。 不要主观地认为管理小型项目就不需要考虑最佳实践,因为等到项目陷入困境的时候就悔之晚矣。
举报
致知者
在工程项目管理中,有众多的国家、地方法规,甚至是业主的要求在制约着项目管理实践。而软件项目管理,相对而言是比较宽松的,只是业主的要求更难以描述。
不过对于项目管理实践而言,除了需要的专业知识和技术有别外,大致的实践技能和技巧是相通的。
诚意者
本版积分规则 写好了,发布 Ctrl + Enter 快速发布 回帖后跳转到最后一页