"变更管理"结束和"项目失败"从哪里开始?
最近,我与老板发生了关于"项目失败"的小争论。三年后,我们的将代码库迁移到新平台的项目(我从事了1.5年,但是我的团队负责人才进行了几个月)就开始了。他以及我公司和客户的高级管理层(我是我们听到如此多的令人敬畏的顾问之一。我的工作是"应用程序外包")宣布该项目成功。我不同意,指出我发现的旧演示文稿显示,与原始时间表相比,部署延迟最好以几个月为单位,并且可能以几年为单位。我解释了我对项目失败的了解,以及失败率背后的研究和统计数据。他回答说,这全是学术界,他领导的项目都没有失败,这要归功于变更/风险管理的奇迹,这似乎可以解释为解释延误并根据新数据重新评估时间表。
也许像这样的咨询与其他项目有所不同,但看来这只是用失败的名字包裹起来的失败,以避免因未能按时,按预算或者无法提供完整功能而造成的耻辱。他解释说我的公司免费提供了数小时的工作,以便在超出预算的情况下完成该项目,这一事实表明了很多。
所以我问你这个:
- 什么是变更管理?变更管理如何应用于项目?
- "变更管理"在哪里结束,"项目失败"在哪里开始?
@ shog9:
我并不是在问与顾问的责备游戏,特别是因为在这种情况下,我代表顾问。我一直在寻找关于何时应将项目视为"失败"的观点,无论最终是否实现了所需的功能。
我正在寻找"这实际上比我们想象的要复杂一点,而且还要再过一周"之间的区别,我希望这是典型的,而"项目失败"则是我们想要定义失败的区别。有什么区别吗?进度计划延误的这种微小程度是否构成统计上的"项目失败"?
解决方案
回答
我想这个项目有多成功取决于客户是谁。如果客户是公司董事,并且他们很高兴,那么该项目是成功的,而不管过程中的失败如何。
回答
我认为,大多数时候,我们开发人员忘记了我们所做的一切毕竟是关于业务的。
从这个角度来看,一个项目并不是失败,而客户愿意为此付出代价。一切都取决于客户,一些客户有更多的耐心并更好地了解软件开发的风险,而其他客户则在出现严重延误的情况下不会付钱。
无论如何,关于问题。每当我们开发一个项目时,都会涉及风险,也许我们将项目的结束安排在某个日期,但要比预期多花费六个月。在这种情况下,我们必须权衡已经花费的成本和要获得的收益与所承担的风险。实际上,有一门称为"决策制定"的整个科学都在软件级别进行研究,因此老板完全没有错。
让我们看一些问题,客户是否愿意等待该项目?他愿意承担某些超支吗?即使他没有,是否值得承担额外的费用而不是丢弃所有已经完成的工作来完成项目?公司可以假定已经丢失了什么吗?
问题的真正答案在于这些问题。我们无法在这里说出一个要点,如果此时尚未完成项目,那就失败了。至于具体情况,谁知道呢?老板可能拥有更多的信息,因此工作是告诉他项目进展如何,需要多少费用以及花费多少(如果我们愿意,以小时/人为单位)
回答
除非在项目开始时就明确说明了目标,否则"成功"与"失败"之间就没有明确的界线。通常,一个项目会有不同程度的成功/失败。
对于某些人来说,仅在代码中获得一些概念就可以成功,而另一些人则可以将成功视为收回所有投资并获利的标准。
两种众所周知的故障模式是进度表延误和质量下降,但是在现实世界中,人们似乎并不太在乎它们。
拖延进度表的简单方法是让管理人员在需要时提出请求(功能不断发展),并让程序员编写自己认为合适的代码(牛仔编码)。诸如Scrum的Sprint计划和XP的计划游戏之类的变更管理过程就是其中的一些示例。这些是管理层和开发人员按时交付可靠产品的一些尝试。如果任何一方对可靠或者按时不感兴趣,那么变更管理将无用。
回答
安迪·鲁特里奇(Andy Rutledge)写了一篇非常有趣的成功文章。尽管标题是"投标前讨论",但文章定义了一个成功的项目,对于Andy而言,这需要:
- 我或者我的团队将被允许将我们最好的工作带到最终结果吗?
- 客户是否准备好适当参与该项目?
- 客户准备好开始这个项目了吗?
- 客户是否准备对我或者我的团队构想投入信任?
- 我或者我的团队准备满足或者超过项目要求吗?
成功的顾问Obie Fernandez在其关于咨询的Do The Hustle会议上指出了这篇文章。
回答
什么是变更管理?变更管理如何应用于项目?
变更管理是指在变更发生之前批准和传达变更。如果我们项目中的某人(用户,赞助商,团队成员……某人)想要添加功能,则需要记录更改并分析其效果。在进行更改之前,必须对范围,预算和进度表进行任何最终更改。这些更改通常由赞助商,指导委员会或者客户批准。
一旦更改被批准并接受,这就是新计划。原始预算或者时间表是什么都没有关系。
项目的变更管理是关于"没有惊喜"的原则。适当的人(变更控制委员会)需要批准对范围,计划和预算的任何更改,然后才能采取行动。
要记住的一件事是,可能存在某些明确或者隐含的约束和变更容忍度。我们可能必须在某个日期之前交付项目,才能满足政府法规的要求。或者组织可能有一个阈值,一旦项目预算超过原始预算的30%,则必须达到" C"级别,否则项目将被终止。预先调查并明确说明这些阈值和公差是获得更好的成功项目的一种好方法。
"变更管理"在哪里结束,"项目失败"在哪里开始?
如果项目按批准的范围,进度和预算交付,则说明该项目成功。
但是,它仍然可能被视为失败。实施后审核是使利益相关者(不仅仅是老板)有资格进行评估的好工具。另外,Benefit Realization也值得研究,以了解该项目的黑匣子及其对整个业务的影响。