問題描述
“變更管理”從哪裡結束，“項目失敗”從哪裡開始？ (Where does "Change Management" end and "Project Failure" begin?)
我最近與老闆就“項目失敗”發生了小爭執。三年後，我們將代碼庫遷移到新平台的項目（我參與了 1.5 年的項目，但我的團隊領導只參與了幾個月）上線了。他與我公司和客戶的高級管理人員（我是您經常聽到的那些可怕的顧問之一。我的參與是“應用程序外包”）宣布該項目是成功的。我不同意，指出我發現的舊演示文稿表明，與最初的時間表相比，部署延遲最好以月為單位來衡量，並且可能以年為單位來衡量。我解釋了我對項目失敗的了解，以及失敗率背後的研究和統計數據。他回答說那都是學術界，並且他領導的任何項目都沒有失敗，這要歸功於變革/風險管理的奇蹟——這似乎可以歸結為解釋延誤和根據新數據重新評估時間表。
也許像這樣的諮詢會有所不同來自其他項目，但這似乎只是用一個更漂亮的名字包裝的失敗，以避免因未能按時交付、未按預算交付或未提供完整功能的恥辱。他解釋說我的公司為了在最大預算內完成項目而免費提供數小時的工作，這一事實說明了很多。
所以我問你這個問題：
- 什麼是變更管理，它如何應用於項目？
- “變更管理”從哪裡結束，“項目失敗”從哪裡開始？
@shog9： 我並不是在問與顧問之間的責備遊戲，尤其是因為在這種情況下，我代表顧問。我一直在尋找關於何時應將項目視為“失敗”的意見，無論所需的功能是否最終實現。 我正在尋找“這實際上更多一點”之間的區別比我們想像的要復雜，這將是另一個星期”，我認為這有點典型，而且“項目失敗”——但是你想定義失敗。甚至有區別嗎？這種輕微的進度延誤是否構成統計上的“項目失敗”？ em>代表顧問。我一直在尋找關於何時應將項目視為“失敗”的意見，無論所需的功能是否最終實現。 我正在尋找“這實際上更多一點”之間的區別比我們想像的要復雜，這將是另一個星期”，我認為這有點典型，而且“項目失敗”——但是你想定義失敗。甚至有區別嗎？這種輕微的進度延誤是否構成統計上的“項目失敗”？ em>代表顧問。我一直在尋找關於何時應將項目視為“失敗”的意見，無論所需的功能是否最終實現。 我正在尋找“這實際上更多一點”之間的區別比我們想像的要復雜，這將是另一個星期”，我認為這有點典型，而且“項目失敗”——但是你想定義失敗。甚至有區別嗎？這種輕微的進度延誤是否構成統計上的“項目失敗”？ 我正在尋找“這實際上比我們想像的要復雜一點，而且這將是另一個星期”之間的區別，我認為這有點典型，和“項目失敗” ‑ 但是你想定義失敗。甚至有區別嗎？這種輕微的進度延誤是否構成統計上的“項目失敗”？ 我正在尋找“這實際上比我們想像的要復雜一點，而且這將是另一個星期”之間的區別，我認為這有點典型，和“項目失敗” ‑ 但是你想定義失敗。甚至有區別嗎？這種輕微的進度延誤是否構成統計上的“項目失敗”？
參考解法
方法 1:
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)
方法 2:
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.
方法 3:
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.
方法 4:
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.
方法 5:
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.
(by AgentConundrum、Jorge Córdoba、Eugene Yokota、GateKiller、Christian Lescuyer、Mark Nold)