project-management - 「変更管理」はどこで終わり、「プロジェクトの失敗」はどこから始まりますか？

Question

最近、「プロジェクトの失敗」について上司とちょっとした議論をしました。3年後、コードベースを新しいプラットフォームに移行するプロジェクト（1.5年間行っていたプロジェクトですが、チームリーダーは数か月しかいませんでした）が稼働しました。彼は、私の会社とクライアントの両方の上級管理職（私はあなたがよく耳にする神々しいコンサルタントの一人です。私の関与は「アプリケーションアウトソーシング」です）とともに、プロジェクトが成功したと宣言しました。私が見つけた古いプレゼンテーションでは、元のスケジュールと比較して、展開の遅延は数か月で測定するのが最適であり、数年で測定できる可能性があることを示していることに同意しませんでした。プロジェクトの失敗について私が知っていることと、失敗率の背後にある研究と統計について説明しました。彼は、それはすべて学界であり、彼が主導したプロジェクトは失敗しなかったと答えました。

このようなコンサルティングは他のプロジェクトとは異なるかもしれませんが、時間通り、予算内、または完全な機能で提供できなかったという汚名を避けるために、これはより美しい名前に包まれた失敗のようです。私の会社が最大の予算内でプロジェクトを完了するために無料で何時間もの仕事を与えたと彼が説明したという事実は多くを語っています。

だから私はあなたにこれを尋ねます：

• 変更管理とは何ですか？それはプロジェクトにどのように適用されますか？
• 「変更管理」はどこで終わり、「プロジェクトの失敗」はどこから始まりますか？

---

@ shog9：
特にこの場合、私はコンサルタントを代表しているので、私はコンサルタントとの非難ゲームについて質問していませんでした。必要な機能が最終的に実装されたかどうかに関係なく、プロジェクトが「失敗」したと見なされる時期についての見解を探していました。
「これは実際には私たちが思っていたよりも少し複雑で、もう1週間になるでしょう」と、「プロジェクトの失敗」との違いを探しています。ただし、失敗を定義したいと思います。違いもありますか？このマイナーレベルのスケジュールのずれは、統計的な「プロジェクトの失敗」を構成しますか？

Answer 1

ほとんどの場合、私たち開発者は、私たち全員が行うことは、結局のところ、忙しさについてであることを忘れていると思います。

その観点から、クライアントがそれに対して支払うことをいとわない間、プロジェクトは失敗ではありません。それはすべてクライアントに依存します。一部のクライアントはより忍耐強く、ソフトウェア開発のリスクをよりよく理解しています。他のクライアントは、大幅な遅延が発生した場合に支払いをしません。

とにかく、あなたの質問について。プロジェクトを発展させるときはいつでもリスクが伴います。プロジェクトの終了を特定の日にスケジュールするかもしれませんが、予想よりも6か月ほど長くかかります。その場合、あなたはあなたがすでに費やしたものとあなたが取っているリスクに対してあなたが得なければならないもののバランスをとらなければなりません。実際には、ソフトウェアレベルでそれを研究する「意思決定」と呼ばれる科学全体があるので、上司はまったく間違っていません。

いくつかの質問を見てみましょう。クライアントはプロジェクトを待つ気がありますか？彼は特定の超過費用を引き受ける気がありますか？彼がそうしなかったとしても、すでに行われたすべての作業を捨てるのではなく、追加のコストを想定してプロジェクトを完了する価値はありますか？会社はすでに失われたものを想定できますか？

あなたの問題に対する本当の答えは、その質問の背後にあります。ポイントを確立して、ここで、プロジェクトがこの時点までに完了していない場合、それは失敗であると言うことはできません。あなたの特定の状況については、誰が知っていますか？あなたの上司はおそらくあなたが持っているより多くの情報を持っているので、あなたの仕事はプロジェクトがどのように進んでいるのか、どれくらいかかるのか、そしてどれくらいの費用がかかるのかを彼に伝えることです（あなたが望むなら時間/人で）

Answer 2

プロジェクトの最初に目標が明確に述べられていない限り、「成功」と「失敗」の間に明確な境界線はありません。多くの場合、プロジェクトの成功/失敗の程度はさまざまです。

一部の人にとっては、コードでいくつかの概念を取得するだけで成功する場合もあれば、すべての投資を回収して利益を上げることとして成功を測定する場合もあります。よく知られている2つの障害モードは、スケジュールのずれと品質の低下ですが、実際には、人々はそれらをあまり気にしていないようです。

スケジュールを遅らせる簡単な方法は、マネージャーがいつでもリクエストできるようにし（機能が這う）、プログラマーが正しいと思うものをコーディングできるようにすることです（カウボーイコーディング）。スクラムのスプリント計画やXPの計画ゲームなどの変更管理プロセスはその一例です。これらは、管理者と開発者が信頼できる製品を時間どおりに出荷するための試みの一部です。どちらかの当事者が信頼できるまたは時間通りに関心がない場合、変更管理は役に立ちません。

Answer 3

プロジェクトがどれだけ成功するかは、クライアントが誰であるかによると思います。クライアントが会社の取締役であり、彼らが満足している場合、プロジェクトは途中で失敗したにもかかわらず成功しました。

Answer 4

変更管理とは何ですか? プロジェクトにどのように適用されますか?

変更管理とは、変更が発生する前にプロジェクトへの変更を承認して伝達することです。プロジェクトの誰か (ユーザー、スポンサー、チーム メンバーなど) が機能を追加したい場合、その変更を文書化し、その効果を分析する必要があります。範囲、予算、およびスケジュールの結果として生じる変更は、変更を行う前に承認する必要があります。これらの変更は通常、スポンサー、運営委員会、またはクライアントによって承認されます。

変更が承認され、承認されると、それが新しい計画になります。当初の予算やスケジュールは関係ありません。

プロジェクトの変更管理は、すべて「ノーサプライズ」の原則に関するものです。適切な担当者 (変更管理委員会) が、スコープ、スケジュール、および予算の変更を実行する前に承認する必要があります。

覚えておくべきことの 1 つは、変更に対する特定の明示的または暗黙的な制約と許容範囲が存在する可能性があることです。政府の規制要件を満たすために、特定の日付までにプロジェクトを提供する必要がある場合があります。または、プロジェクトの予算が元の予算の 30% を超えると、「C」レベルに移行する必要があるか、プロジェクトが中止されるというしきい値が組織にある場合があります。これらのしきい値と許容範囲を事前に調査して明確に述べることが、プロジェクトをより成功させる良い方法です。

「変更管理」はどこで終わり、「プロジェクトの失敗」はどこから始まるのでしょうか?

プロジェクトが承認されたスコープ、スケジュール、および予算で提供された場合、プロジェクトは成功です。

ただし、それでも失敗と見なされる場合があります。実装後のレビューは、関係者 (上司だけでなく) とこれを評価するための優れたツールです。また、ベネフィット リアライゼーションは、プロジェクトのブラックボックスの外側とビジネス全体への影響を調べる価値があります。

Answer 5

Andy Rutledgeは、成功に関する非常に興味深い記事を書いています。タイトルはPre-bid Discussionsですが、この記事ではプロジェクトを成功させることを定義しています。

1. 私または私のチームは、最高の仕事を最終結果に持ち込むことが許されますか?
2. クライアントはプロジェクトに適切に参加する準備ができていますか?
3. クライアントはこのプロジェクトを開始する準備ができていますか?
4. クライアントは、私または私のチームのアイデアに信頼を投資する準備ができていますか?
5. 私または私のチームは、プロジェクトの要件を満たす、または超える準備ができていますか?

この記事は、成功したコンサルタントである Obie Fernandez がコンサルティングに関するDo the Hustleカンファレンスで指摘したものです。