失敗したプロジェクト：いつ呼び出すか？

数か月前、私の会社は、プロジェクトの白熱した緊急事態に手を出し、6人のチーム全員が基本的に5週間の「クランチウィーク」を終了しました。本番開始の48時間前に、私はそのうちの41人、2人で徹夜で作業しました。その真ん中に、これまでで最も成功した質問を投稿しました。

その間、「失敗」の話はありませんでした。それは常に「痛みに関係なく、成し遂げられる」ことでした。

事態は終わり、私たちは組織としてしばらくの間、学んだことをじっくりと検討する時間がありましたので、1つの質問がありました。「失敗」したと言うプロジェクトに参加したことがあるとは言えません。予算が遅れたり予算を超過したものもありましたが、悲惨なものもありましたが、私は常に何かを提供することになりました。

それでも、私は常に「失敗したITプロジェクト」について耳にします。私はそれに関する人々の経験について疑問に思っています。「失敗」を定義したパラメーターは何ですか？コンテキストは何でしたか？私たちの場合、私たちは外部クライアントを持つソフトウェアショップです。大企業の内部にあるプロジェクトには、「失敗」する余地がありますか？いつ電話しますか？するとどうなりますか？

私たちがやったことをやるのは賢明なビジネスの動きだとは全く確信していません。それは私の電話ではありませんでした（私は単なるコードモンキーです）が、損失を削減し、配信しないと言って先に進む方が良いのではないかと考えています。長時間の刺し傷のために、会社はプロジェクトでシャツを王室で失い、さらに従業員の士気と忠誠心に関する会社の無形の費用が大きかったとは言いません。このような注目度の高いプロジェクトを提供できなかったというPRヒットに反する要因は...そして、私は正しい答えが何であるかわかりません。

失敗の概念は、実際にはビジネス関連の呼び出しです。商業プロジェクトがもたらすお金よりも費用がかかる場合、そのプロジェクトは失敗とみなされます。オープンソースプロジェクトが、コードの周りにコミュニティを構築して、それを維持し、世話をするのを助けることができない場合、そのオープンソースプロジェクトは失敗しました。

私はプロジェクトに関与してきましたが、すべてを期日どおりに予算内で提供しましたが、ビジネス開発チームは仕事をフォローできませんでした。ビジネスの観点からは、プロジェクトは失敗しましたが、私たちが提供したものは好評で好評でした。

あなたのような状況では、会社は厳しい決断を下さなければなりません。プロジェクトを成功させるには、いくつかのレッスンを学ぶ必要があります。

• 適切に計画しないと、チームに過度のストレスがかかり、最終的にプロジェクトが失敗することになります。
• ストレスのかかったチームは高い離職率で報復します。そして最終的には、優秀な人を会社に参加させることができなくなります。
• 緊急事態が発生しますが、緊急事態の原因を見つけ、今後その緊急事態を避けるためにあなたの慣行を変更します。

間違いから学ばない会社は、かなり頻繁に歴史を繰り返します。私はそれを、別の会社を見つける時が来たという兆候だと思います。

失敗は、目標が達成されていないことを説明できるものです。

つまり、目標を定義するとき、そのコンテキストで何が失敗するのかも定義します。

あなたが言及した文献では、失敗は予算を超過している、および/または期限に間に合わなかったプロジェクトです。

これは、製品が使用されないという意味ではありません。これは、予想よりもはるかに多くの痛み、お金、時間を費やした開発者であることを意味します。

When you should cancel a project？新たな2回目の支出がその費用よりも少ない価値をもたらすと確信している場合。

これは、サンクコストジレンマと呼ばれます。

主題に興味がある場合は、Edward YourdonのDeath Marchをお勧めします。本当に素晴らしい本。

プロジェクトが「失敗」する可能性のあるさまざまな方法があります。そして、私が取り組んできたかなりの数は失敗でした：

1. シュリンクラップソフトウェアは、新しい法規制規則に合わせて書き直す必要がありました。ミスマネジャーは、ワークロード、特に私たち全員に欠けているスキルを支援するために、新しい人を雇うことを避けました。この製品には新しい必須機能がなく（電子ファイリングを特定の方法で行わなければならなかった）、市場から撤退する必要がありました。この製品は、当社のオフィス収益の約5％を生み出しましたが、同様の規制の変更が行われ、収益の60％を生み出した製品に影響を及ぼしました。開発者は、必要なスキルを習得するためにそれを採用しましたが、ミスマネージャーは、必要な変更の実装を開始するには遅すぎるまで待つことを選択しました。この規制変更のサーバー側で入札しようとしたときにこれらの変更が来ていることを3年間警告し、企業は入札の提出を正当に禁止しました。私たちのミスマネジャーは、作業を許可される前に、切り替えの8か月前まで待機することを選択しました。

2. このプロジェクトはすでに予算を超えており、完成させるために私を連れてきたときには期限が過ぎていました。いくつかのレベルのマネージャーは、プロジェクトに必要なROIを確保するには埋没費用が高すぎると判断したため、プロジェクトはキャンセルされ、関係者全員が解雇されました。グループが解雇される前の1週間（私を含む）働いたのは、私が今までに職場で働いた中で最も短い時間でした。

3. 内部プロジェクトの完了には非常に時間がかかったため、プロジェクトスポンサーは既成のソフトウェア（この場合はMicrosoft Office）を購入し、仕事を遂行するために独自のVBAを作成しました。開発チームのリーダーは月を約束し続け、プロジェクトが既にキャンセルされたという経営会議で聞くことを拒否しました。6人が約1年間働いて、使用されることのないシステムを完成させました。

私がプログラマーとして、またはPMチームの一部として関与した唯一のプロジェクトは、Ricochetであり、Metricomの破産に追いつきました。全国で文字通り何千人もの請負業者がそれに取り組んでいます。CFOが辞任したとき、プロジェクトは文字通り停止しました。清算人が降りるにつれて、オフィスから家具が取り外され始めました。

私たちの多くにとって、該当する用語は「失業」でしたが、ラメダックは適切な説明です。多くの場合、キーパーソンは検死/清算プロセスが完了するまで継続する必要があります。これは、後継者が入る前に任期を終了するために数か月間在職する一部の政治家と同様です。

通りのOtavioDécioが示されている、私はプロジェクトは、ドットコムブーム以来、放棄のポイントに失敗見ていません。

これは一般的な問題であり、プロジェクト管理に関するいくつかの書籍でも言及されています。プロジェクトが「失敗する」ことはありません。たとえそれが提供するすべてが「次回の回避策」エクスペリエンスであるとしてもです。

IMO、プロジェクトをやらなければ、プロジェクトは失敗に終わります。たとえば、製品の寿命が5年と予想され、会社を10万pa節約できた場合、製品の作成に50万以上かかった場合は失敗になります。（私はそれをより簡単にするためにここの金利でごまかしています）。一部の人々は、コストや時間のオーバーランがあるすべてのプロジェクトが失敗であると主張しますが、IMOはこの定義が正しい見積もりと計画に重点を置いているため、ほとんど意味がありません。

また、「失敗した」プロジェクトには一切参加しませんでしたが、コストと時間のオーバーランを伴う多くのプロジェクトがありました。問題は、クライアントも請負業者も、責任を含め、あらゆるプロジェクトが失敗とみなされることを望んでいないことだと思います。

ですから、実際に「失敗したITプロジェクト」と聞いたとき、これらは「時間内または予算内で限界を超えたプロジェクト」であると思います。

結局のところ、あなたが知っている何人の人または会社がきれいになって「失敗した」と言うでしょうか？

それでも、私は常に「失敗したITプロジェクト」について耳にします。

「失敗」を定義したパラメーターは何ですか？

これは、プロジェクトが変更されたときによく使用される軽jor的な用語です。多くの人は、変更を「失敗」とラベル付けすることを好みます。理由はわかりませんが、失敗を特定することで、それらが何らかの形でより強力または重要になります。

いくつかのプロジェクトは本当にお金を失い、価値のないものは生み出されません。しかし、それらはまれです。

動作するソフトウェアを提供したことのないプロジェクトでさえ、やるべきでないことの学習経験です。価値を創造しました。予期しない値が作成されたため、ユーザーが希望するラベルを付けることができます。一部のサークルでは、「失敗」は「してはいけないことを学んだ」と同じくらい良いです。

本当の質問は、「価値はコストに見合っていたのか」ということです。そして、それでも、その値を測定するのは非常に難しいので、答えは完全に政治的または主観的です。

大企業の内部にあるプロジェクトには、「失敗」する余地がありますか？

おそらく。「失敗」は政治用語です。スケジュール、予算、または範囲の変更は、「変更」または「失敗」としてラベル付けできます。また、「私たちのチームがWebサーバーを作成できないことについて重要なことを学んだ」というラベルを付けることもできます。または、さらに積極的に、「再試行する前に、必要なスキルを学習しました」。

多くの場合、外部プロジェクトは、販売および配達の担当者、会計士、プロジェクト管理者からより多くの監督を受けます。内部プロジェクトでは、多くの場合、監視が少なくなります。

いつ電話しますか？するとどうなりますか？

あなたが彼らに同意しなかったために、誰かが組織から圧力をかけられることが都合が良いとき。プロジェクトに「失敗」というラベルを付けて、別の人に割り当てられるように再割り当てします。

プロジェクトが完全に失敗する唯一の方法は、犯罪詐欺です。学んだ教訓がなく、何も改善できず、犯罪者が解雇されて投獄され、組織は何が起こったのか分からないままになります。

そうでなければ、常に何らかの価値があります。

本当の質問は、「価値はコストに見合っていたのか？」です。

したがって、このワークアウトを請求していたあなたの会社は、あなたと他の5人を5週間死亡させました。彼らはあなたの苦労からまだ利益を得ています。仕事のセキュリティは最近ではなく、たくさんの仕事があるので、何かを得たことを願っています。（あなたが仕事を必要とし、有能なプログラマーであるなら、恥知らずのプラグは私に連絡します、私は必死に助けを必要とするいくつかの場所を知っています）。

そうは言っても、もしあなたの会社が実際にその仕事すべてと、実際に稼働する41時間前にあなたに支払いをしなければならないとしたら、彼らはお金を失います。

あなたの管理者は座って、これが再び発生した場合に支払われるべきであるという説明が必要です。彼らはいつプラグを抜くかに関してより良い判断をする必要があります。

私も、ここにいる多くのレスポンダーと同様に、時間と予算をかけて実行されたいくつかの大規模なプロジェクトに関与してきました。最悪のシナリオ（10年半のシナリオ）には、壮大なスコープクリープだけでなく、神秘的な月間の狂気が含まれていました。とは言うものの、それは決して放棄されたものではなく、彼らは今やいくつかのクライアントを引き受け始めています。しかし、当初の期待（古くて時代遅れのシステムに代わるクリーンで適切に設計されたシステム）と比較的控えめな予算とタイムラインは、長い間粉砕されてきました。

また、ここにいるほとんどの人々とは異なり、私はプロジェクトが完全に失敗するのを見ました- 放棄のポイントまで。coの最後の釘は2010年初頭に来ました。これはシナリオでした：

中小企業向けにカスタムERPソリューションを提供する小規模企業（約30人）。彼らは、オーストラリアの採掘会社と比較的有利な物流施設をいくつか持ち、米国ではトラック用品をいくつか持っていました。プラットフォームは、J2EEの上に構築されたカスタムの社内フレームワークでした。実際には比較的カスタマイズ可能でよくできています-シンプルな新しいインストールはかなり迅速に構築できますが、必要なカスタマイズのレベルが非常に複雑な場合（あまりにも多くの最大のクライアントの場合のように）あまりスケールしませんでした。

簡単に言えば、最大かつ最もプロファイルの高いインストールのいくつかは、時間と予算を超えて実行されましたが、市場はそれを認識していなかったため、クライアントを獲得できませんでした。同社は基本的に1つのトリックポニーであり、このERPシステム以上のことはしていないため、そのキャッシュフローが枯渇すると廃業し、システムは放棄されました（GFCもその役割を果たした可能性があります） 。

（私はそこで2004年から2005年に9か月しか働いていませんでした。請負業者を雇うのではなく、基本的に彼らは新しい設備で仕事をやり取りするために雇い、余計な仕事をしていました。テクノロジーよりも不安定なビジネスモデルを使用します。）

元の要求が満たされるような方法でプロジェクトが展開された場合、プロジェクトを成功と呼びます。私にとって障害は、エンドユーザーがニーズを満たさなかったために、一般的に拒否されたアプリケーションを展開することです。または、さらに悪いことに、製品が実際にユーザーに展開され、ユーザーのニーズが満たされないうちにプロジェクトが終了します。

一般に、企業が外部のクライアントのために働いている場合、契約の問題（契約支払いの違反）があったり、PRが大ヒットしたりする可能性があるため、プロジェクトを撤回するという決定ではありません。場合によっては、契約違反のペナルティがある場合、契約を終了するコストは、契約違反のトークンコストよりも数倍少なく、トークンの金額を失うことをお勧めします。

長い目で見れば、企業は従業員のモラルを向上させてプロジェクト中のクランチ時間を補うか、ハードに追い込まれたために退職した従業員を交換することができますが、大きなプロジェクトの失敗から回復できない場合もあります（すなわち、倒産した商品を期日通りに配達できなかったゲーム会社を見てください）。

ビジネスケースが持続しなくなったとき。

それがPrince2（プロジェクト管理方法論）が使用する尺度であり、それは私にとって非常に理にかなっています。

基本的に、プロジェクトの各段階の終わりに、またはプロジェクトが特定の領域（スケジュール、コスト、品質）で特定の許容範囲を超えた場合、ビジネスケースのレビューが必要です。その時点で、現在の知識に基づいて予想される総コストと実現可能なメリットを検討し、プロジェクトがスタックしなくなると、プロジェクトは終了します。

私が見た多くのプロジェクトのこれに関する問題は、彼らが何を達成しようとしているかを前もって詳細に設定していないことであり、（a）それがまだ現実的であるか、または（b ）そこにたどり着くのに費やす費用に見合う価値があるかどうか。これらの状況でできる最善のことは、疑いが生じた時点でビジネスケースを作成して、疑いが正しいかどうかを理解できるようにすることです。

ビジネスケースをまとめることは大きな仕事である必要はありません。A4のいくつかの側面が行います。コストは比較的簡単です（大まかな測定として、プログラマーのコスト：（年sal * 2）/ヨーロッパでは1日あたり250、ここでの入力であるベネフィットが低く平均就業日数が多いため、おそらくアメリカでは少し少なくなります） ）。

利点はより困難ですが、悲観的にできるだけ正確に見積もった場合、ビジネスケースが積み重ならない場合（通常は、Xが50％になる可能性のある3年間のコストに対してx％の収益を上げる必要があるため、測定されます）そう）あなたはより詳細にそれを見ることができます。ライセンスとハードウェアのコストを忘れないでください（既存のハードウェアを使用している場合でも、一度取得すると他のハードウェアは使用できません）および継続的なサポート。

しかし、これの多くはプログラマーのものではなく、PMのものであり、ビジネスはプロジェクトチーム全体からのインプットで行うべきものです。