What is change management, and how does it apply to a project?
Change management is about approving and communicating changes to a project before they happen. If someone on your project (user, sponsor, team member.. whoever) wants to add a feature, the change needs to be documented and analysed for the effect. Any resulting changes to scope, budget and schedule must then be approved before the change is undertaken. These changes are typically approved by your sponsor, your steering committee or your client.
Once the changes have been approved and accepted that is your new plan. It doesn't matter what the original budget or schedule was.
Change Management on projects is all about the principle of "No Surprises". The right people (your Change Control Board) need to approve any changes to Scope, Schedule and Budget before they are acted upon.
One thing to remember is that there may be certain explicit or implicit constraints and tolerances for change. You may be have to deliver your project by a certain date to meet government regulatory requirements. Or your organisation may have a threshold that once a project budget is 30% over the original budget it must go to a "C" level or the project is killed. Investigating and explicitly stating these thresholds and tolerances up front are a good way of having better successful projects.
Where does "change management" end, and "project failure" begin?
If a project delivers on the approved scope, schedule and budget then it is successful.
However it may be still viewed as a failure. Post Implementation Reviews are a good tool to qualify this with your stakeholders (not just your boss). Also Benefit Realisation would be worthwhile looking into to see outside the blackbox of the project and the impact on the business as a whole.
Andy Rutledge has written a pretty interesting article on success. Though the title is Pre-bid Discussions, the article defines having a successful project, which for Andy entails:
Will I or my team be allowed to bring our best work to the final result?
Is the client prepared to engage in the project appropriately?
Is the client prepared to begin this project?
Is the client prepared to invest trust in my or my team’s ideas?
Am I or is my team prepared to fulfill or exceed the project requirements?
This article was pointed out by Obie Fernandez, a successful consultant, in his Do the Hustle conference about consulting.
I suppose how successful the project is depends on who the client is. If the client were the company directors and they are happy, then the project was successful regardless of the failures along the way.
推迟进度的简单方法是让经理随时提出请求（功能蔓延），并让程序员编写他们认为正确的任何内容（牛仔编码）。 变更管理流程，例如 Scrum 的 冲刺计划 和 XP 的规划游戏就是一些例子。 这些是管理层和开发人员为按时交付可靠产品所做的一些尝试。 如果任何一方对可靠或准时不感兴趣，那么变革管理就没有用处。
Unless the goals were clearly stated in the beginning of the project, there are no clear lines between "success" and "failure." Often, a project would have varying degree of success/failure.
For some, just getting some concepts in code would be a success, while other may measure success as recovering all investments and making profit. Two well-known modes of failures are schedule slip and quality deterioration, but in real-world, people do not seem to care much about them.
Simple ways to slip the schedule are to let the managers make request whenever they want (features creep) and let the programmers code whatever they feel is right (cowboy coding). Change management process such as sprint planning of scrum and planning game of XP are some of the examples. Theses are some of the attempts for the management and the developers to ship reliable products on time. If either party is not interested in reliable or on-time, then change management would not be useful.
I think, most of the time, we developers forget this we all do is, after all, about bussiness.
From that point of view a project is not a failure while the client is willing to pay for it. It all depends on the client, some clients have more patience and understand better the risks of software development, other just won't pay if there's a substantial delay.
Anyway, about your question. Whenever you evolve a project there are risks involved, maybe you schedule the end of the project in a certain date but it will take like six month longer than you expected. In that case you have to balance what you have already spent and what you have to gain against the risks you're taking. There's actually an entire science called "decision making" that studies it at software level, so your boss is not wrong at all.
Let's look at some questions, Is the client willing to wait for the project? Is he willing to assume certain overcosts? Even if he doesn't, Is worth completing the project assuming the extra costs instead of throwing away all the already done work? Can the company assume what's already lost?
The real answer to your problem lies behind that questions. You can't establish a point and say, here, if the project isn't done by this time then it's a failure. As for your specific situation, who knows? Your boss has probably more information that you have so your work is to tell him how is the project going, how much it will take and how much it will cost (in terms hours/man if you wish)
发布评论
评论（5）
什么是变更管理，它如何应用于项目？
变更管理是指在项目变更发生之前批准并传达变更。 如果项目中的某人（用户、发起人、团队成员……任何人）想要添加功能，则需要记录更改并分析其效果。 任何由此产生的范围、预算和时间表的变更都必须在进行变更之前获得批准。 这些变更通常会得到您的发起人、指导委员会或您的客户的批准。
一旦更改被批准并接受，这就是您的新计划。 最初的预算或时间表是什么并不重要。
项目变更管理都是围绕“没有意外”的原则。 对范围、时间表和预算的任何变更都需要在采取行动之前得到合适的人员（您的变更控制委员会）的批准。
要记住的一件事是，可能存在某些显式或隐式的约束和变化容忍度。 您可能必须在特定日期之前交付项目，以满足政府监管要求。 或者您的组织可能有一个阈值，一旦项目预算超出原始预算 30%，则必须达到“C”级别，否则项目将被终止。 预先调查并明确说明这些阈值和容差是获得更好的成功项目的好方法。
“变革管理”从哪里结束，“项目失败”从哪里开始？
如果项目按照批准的范围、进度和预算交付，那么它就是成功的。
然而，它仍然可能被视为失败。 实施后审查是一个很好的工具，可以让您的利益相关者（不仅仅是您的老板）对此进行验证。 此外，“效益实现”也值得研究，以了解项目黑匣子之外的情况以及对整个业务的影响。
What is change management, and how does it apply to a project?
Change management is about approving and communicating changes to a project before they happen. If someone on your project (user, sponsor, team member.. whoever) wants to add a feature, the change needs to be documented and analysed for the effect. Any resulting changes to scope, budget and schedule must then be approved before the change is undertaken. These changes are typically approved by your sponsor, your steering committee or your client.
Once the changes have been approved and accepted that is your new plan. It doesn't matter what the original budget or schedule was.
Change Management on projects is all about the principle of "No Surprises". The right people (your Change Control Board) need to approve any changes to Scope, Schedule and Budget before they are acted upon.
One thing to remember is that there may be certain explicit or implicit constraints and tolerances for change. You may be have to deliver your project by a certain date to meet government regulatory requirements. Or your organisation may have a threshold that once a project budget is 30% over the original budget it must go to a "C" level or the project is killed. Investigating and explicitly stating these thresholds and tolerances up front are a good way of having better successful projects.
Where does "change management" end, and "project failure" begin?
If a project delivers on the approved scope, schedule and budget then it is successful.
However it may be still viewed as a failure. Post Implementation Reviews are a good tool to qualify this with your stakeholders (not just your boss). Also Benefit Realisation would be worthwhile looking into to see outside the blackbox of the project and the impact on the business as a whole.
Andy Rutledge 写了一篇关于成功的非常有趣的文章。 尽管标题是投标前讨论，但该文章定义了成功的项目，对于安迪来说意味着：
这篇文章是由成功的顾问 Obie Fernandez 在他的 Do 中指出的关于咨询的 Hustle 会议。
Andy Rutledge has written a pretty interesting article on success. Though the title is Pre-bid Discussions, the article defines having a successful project, which for Andy entails:
This article was pointed out by Obie Fernandez, a successful consultant, in his Do the Hustle conference about consulting.
我认为项目的成功程度取决于客户是谁。 如果客户是公司董事并且他们很高兴，那么无论一路上有多少失败，该项目都是成功的。
I suppose how successful the project is depends on who the client is. If the client were the company directors and they are happy, then the project was successful regardless of the failures along the way.
除非在项目开始时明确说明目标，否则“成功”和“失败”之间没有明确的界限。 通常，一个项目会有不同程度的成功/失败。
对于某些人来说，仅仅在代码中获得一些概念就已经是成功了，而另一些人则可能将成功衡量为收回所有投资并赚取利润。
两种众所周知的失败模式是进度延误和质量下降，但在现实世界中，人们似乎不太关心它们。
推迟进度的简单方法是让经理随时提出请求（功能蔓延），并让程序员编写他们认为正确的任何内容（牛仔编码）。 变更管理流程，例如 Scrum 的 冲刺计划 和 XP 的规划游戏就是一些例子。 这些是管理层和开发人员为按时交付可靠产品所做的一些尝试。 如果任何一方对可靠或准时不感兴趣，那么变革管理就没有用处。
Unless the goals were clearly stated in the beginning of the project, there are no clear lines between "success" and "failure." Often, a project would have varying degree of success/failure.
For some, just getting some concepts in code would be a success, while other may measure success as recovering all investments and making profit.
Two well-known modes of failures are schedule slip and quality deterioration, but in real-world, people do not seem to care much about them.
Simple ways to slip the schedule are to let the managers make request whenever they want (features creep) and let the programmers code whatever they feel is right (cowboy coding). Change management process such as sprint planning of scrum and planning game of XP are some of the examples. Theses are some of the attempts for the management and the developers to ship reliable products on time. If either party is not interested in reliable or on-time, then change management would not be useful.
我认为，大多数时候，我们开发人员忘记了我们所做的毕竟是关于业务的。
从这个角度来看，只要客户愿意为此付费，项目就不会失败。 这一切都取决于客户，有些客户更有耐心，更了解软件开发的风险，而另一些客户如果出现严重延误则不会付款。
无论如何，关于你的问题。 每当你开发一个项目时，都会涉及风险，也许你安排项目在某个日期结束，但它会比你预期的时间长六个月。 在这种情况下，您必须平衡您已经花费的资金和您必须获得的资金以及您所承担的风险。 实际上有一门完整的科学叫做“决策”，它在软件层面上进行研究，所以你的老板根本没有错。
我们来看几个问题，客户愿意等待项目吗？ 他愿意承担一定的超额成本吗？ 即使他不这样做，是否值得承担额外成本来完成该项目而不是扔掉所有已经完成的工作？ 公司可以承担已经损失的东西吗？
你的问题的真正答案就在这些问题的背后。 你不能在这里确立一个观点并说，如果项目此时没有完成，那么它就是失败的。 至于你的具体情况，谁知道呢？ 你的老板可能拥有比你更多的信息，所以你的工作就是告诉他项目进展如何、需要多少时间以及成本是多少（如果你愿意的话，可以按小时/人计算）
I think, most of the time, we developers forget this we all do is, after all, about bussiness.
From that point of view a project is not a failure while the client is willing to pay for it. It all depends on the client, some clients have more patience and understand better the risks of software development, other just won't pay if there's a substantial delay.
Anyway, about your question. Whenever you evolve a project there are risks involved, maybe you schedule the end of the project in a certain date but it will take like six month longer than you expected. In that case you have to balance what you have already spent and what you have to gain against the risks you're taking. There's actually an entire science called "decision making" that studies it at software level, so your boss is not wrong at all.
Let's look at some questions, Is the client willing to wait for the project? Is he willing to assume certain overcosts? Even if he doesn't, Is worth completing the project assuming the extra costs instead of throwing away all the already done work? Can the company assume what's already lost?
The real answer to your problem lies behind that questions. You can't establish a point and say, here, if the project isn't done by this time then it's a failure. As for your specific situation, who knows? Your boss has probably more information that you have so your work is to tell him how is the project going, how much it will take and how much it will cost (in terms hours/man if you wish)