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

Question

私は最近、「プロジェクトの失敗」について上司と一緒にミニアーグメントに入りました。 3年後、コードベースを新しいプラットフォームに移行するプロジェクト（私が1。5年間続いていましたが、私のチームのリードはわずか数ヶ月間続いていました）が公開されました。彼は、私の会社とクライアントの両方の上級管理職とともに（私はよく耳にするひどいコンサルタントの一人です。私の契約は「アプリケーション アウトソーシング」です) プロジェクトは成功したと宣言されました。私はこれに反対し、私が見つけた古いプレゼンテーションでは、当初のスケジュールと比較して展開の遅れは月単位で測定するのが最善であり、場合によっては数年単位で測定できることが示されていると述べました。プロジェクトの失敗について私が知っていることと、失敗率の背後にある研究と統計について説明しました。彼は、それはすべて学術的なものであり、変更/リスク管理の素晴らしさのおかげで、彼が主導したプロジェクトは失敗しなかった、つまり遅れを説明し、新しいデータに基づいてスケジュールを再評価することに尽きると答えた。

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

そこで私はあなたにこう尋ねます。

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

---

@shog9:
私はコンサルタントとの非難合戦について尋ねているわけではありません。特にこのケースでは、 代表する コンサルタントたち。必要な機能があるかどうかに関係なく、プロジェクトがいつ「失敗」とみなされるべきかについての見解を探していました だった ついに実装されました。
私は、「これは実際には私たちが思っていたよりも少し複雑で、あと 1 週間かかります」という典型的なものと、「プロジェクトの失敗」との違いを探しています。失敗の定義はどのようにしても構いません。違いはありますか？このような軽微なスケジュールの遅れは、統計的に「プロジェクトの失敗」に該当するのでしょうか?

Answer 1

私たち開発者は、ほとんどの場合、自分たちがやっているのは結局のところビジネスであることを忘れていると思います。

その観点からすると、クライアントが喜んでお金を払う限り、プロジェクトは失敗とは言えません。すべてはクライアント次第で、より忍耐強くソフトウェア開発のリスクをよく理解しているクライアントもいますが、大幅な遅れが生じた場合に料金を支払わないクライアントもいます。

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

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

あなたの問題に対する本当の答えは、その質問の背後にあります。要点を定めて、「この時間までにプロジェクトが完了しなければ失敗だ」と言うわけにはいきません。あなたの具体的な状況については誰にも分かりません。あなたの上司はおそらくあなたが持っているより多くの情報を持っているので、あなたの仕事はプロジェクトの進捗状況、それにどれくらいの時間がかかり、どれくらいの費用がかかるかを上司に伝えることです（必要に応じて時間/人員の単位で）

Answer 2

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

いくつかの概念をコードに取り込むだけで成功となる人もいますが、すべての投資を回収して利益を上げることを成功と評価する人もいます。失敗の 2 つのよく知られたモードは、スケジュールの遅延と品質の低下ですが、現実の世界では、人々はそれらをあまり気にしていないようです。

スケジュールを遅らせる簡単な方法は、マネージャーが好きなときにリクエストを作成できるようにし (機能が追加される)、プログラマーが正しいと感じるものはすべてコーディングできるようにする (カウボーイ コーディング) ことです。変更管理プロセスなど スプリント計画 スクラムと 企画ゲーム XP などはその一例です。これらは、信頼できる製品を予定通りに出荷するための経営者と開発者の試みの一部です。いずれかの当事者が信頼性や納期厳守に関心がない場合、変更管理は役に立ちません。

Answer 3

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

Answer 4

アンディ・ラトリッジ 成功に関する非常に興味深い記事を書きました。タイトルですが、 入札前のディスカッション, 、記事では次のように定義されています プロジェクトが成功していること, これはアンディにとって次のことを意味します。

1. 私または私のチームは最高の成果を最終結果にもたらすことができますか?
2. クライアントはプロジェクトに適切に取り組む準備ができていますか?
3. クライアントはこのプロジェクトを開始する準備ができていますか?
4. クライアントは私または私のチームのアイデアを信頼する準備ができていますか?
5. 私または私のチームはプロジェクトの要件を満たす、またはそれを超える準備ができていますか?

この記事は、成功したコンサルタントであるオビー・フェルナンデス氏の著書で指摘されました。 ハッスルをする コンサルティングに関するカンファレンス。

Answer 5

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

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

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

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

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

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

プロジェクトが承認された範囲、スケジュール、予算を達成できれば成功です。

ただし、それでも失敗とみなされる可能性があります。導入後のレビューは、関係者 (上司だけでなく) とともにこれを評価するための優れたツールです。また、利益の実現は、プロジェクトのブラックボックスの外側とビジネス全体への影響を確認するために検討する価値があります。