失敗を保証する7つの要因

従業員に感謝したり、複雑さを過小評価したり、神話に頼ったりしないでください。 これらの要因やその他の要因を考慮に入れると、プロジェクトは確実に失敗します。

知っていますか？ プロジェクトマネージャーは、何週間も何ヶ月もの間、自分のプロジェクトについて報告します。 もちろん、クラシックなステータス ランプも見逃せません。 そして、これは常にグリーン上にあります。すべて問題ありません。 しかし、ある日突然信号が赤に！ その結果、責任者にとって非常に不快な処理プロセスが始まります。 ほとんどの場合、最初の質問は犯人に当てはまり、2 番目の質問は原因に当てはまり、1 つは考えられる解決策にのみ当てはまります。

以下は、ほぼ確実に失敗する 7 つの典型的な要因です。

要因 1: 人的要因を無視する

開発者、プロジェクト マネージャー、コーチ、および危機管理マネージャーとして長年にわたり、私は対人関係の緊張が IT プロジェクトの実施における最大の障害であることに気付きました。 逆に言えば、従業員間の化学反応は正しく、オープンでフォールト トレラントな雰囲気があり、危機的な状況であっても、あらゆる困難に対して解決策を見つけることができます。

衝突を避けるのは人間の本性です。 そのため、人々 (プロジェクト マネージャーなど) が完全に無視したり、あまりにも長い間目をそらしたりするのは当然のことです。 しかし、紛争は通常、自然に解決することはありません。 節度と、少なくとも変化または解決策の展望として、調査が必要です。

従業員の新しい仕事など、小さなことが大きな影響を与えることもあります。 ただし、プロジェクトに再び平和をもたらすには、チームの再編成など、より大きな費用が必要になることがよくあります。 しかし、最悪の選択肢は人的要因を無視することです。

要因 2: 大きく考えすぎたり、小さくしすぎたりする

プロジェクトを引き継ぐ会社もあります。 彼らは、複雑さ、リスク、膨大な人的および物的労力を過小評価しています。 コストに関係なく、私の組織は 100 人の従業員がいるプロジェクトを管理できますか? 仕事、会議室、ネットワーク容量、開発サーバーなどは十分ですか?

会社は、継続的インテグレーション/デリバリーを含む開発およびテスト トラックに対する大規模なアジャイル開発チームの要件を満たすことができますか? そのような質問を予測して、ビジネスケースは現実的に計算されているはずです。 巨大なプロジェクトが開始される直前に、結果として得られるシステムが会社のビジネス モデルに適合しないため、実際には必要ないことが明らかになったのを何度か見てきました。 残念ながら、これまで誰もそれに気づいていませんでした。

もう 1 つの認識可能なパターン:主人公は、たとえば名声上の理由や従業員の活用などのために SW を実現したいと強く望み、コストを無視できると計算します。 後任のプロジェクト マネージャーが、意思決定機関のコンテキストで矛盾を提示するほど強力でない場合、これは大きな危機の可能性を生み出します。

要因 3: 見積もりと計画に 100% 依存する

広く行き渡っている神話は、見積もりと計画の信頼性です。 プロジェクトのコンセプトは、その独自性によって定義されます。 似たようなプロジェクトはすでにあったかもしれませんが、原則として、企業はすべてのプロジェクトで新しい領域に入っています。 これは、見積もりは、現在のプロジェクトに関するクリエイターの経験と適応スキルと同じくらい良いものにしかならないことを意味します.

ただし、計画には、自然発生的なイベント、要件、テクノロジに関する変更、または予期しないリスクの導入を含めることはできません。 結局のところ、見積もりとそれに基づく計画は、未来への賭けにすぎません。 この事実を受け入れることが第一歩です。 規律、勇気、およびシステムは、起こりうる危機を防止または軽減するのに役立ちます。

要因 4: 魔法の PM トライアングルは一貫して無視されている

コンピューター サイエンスを学び、1 学期、最初の講義のプロジェクト管理: 「魔法の PM トライアングル」 . 管理タスクに関心のある人は、非常に早い段階でこの三角形の法則を紹介されます。 これらは、3 つのパラメーターの 1 つを変更すると、他のパラメーターの少なくとも 1 つの結果が必然的に生じることを示しています。

ただし、これらの法律は、実際には無視するにはあまりにも幸せです。 見積もりと計画の文脈ですでに述べたように、プロジェクトはいくぶん独特であり、計画外の影響の可能性は非常に高くなります。 そのため、遅かれ早かれ、ほとんどすべてのプロジェクトで、責任者がこれらの影響に対応する必要があります。 ただし、すべてのパラメータが固定されている場合、つまり、顧客が時間、予算、およびコンテンツの順守を要求し続ける場合、失敗は時間の問題です。

要因 5: すべてを文書化する

フランツ・ベッケンバウアーの後にフリー： 「私たちはそれをクラシックと呼んでいます！」 ますます多くの企業がアジャイル手順 (主にスクラム) に依存していますが、作成するソフトウェアよりも広範なドキュメントを重要視する組織やプロジェクトがまだ見つかっています。 これは、特に大規模なプロジェクトではリスクが高くなります。 多くの場合、何千ページにもわたるコンサルタントや部門の専門家からの調査は、多くの場合、数か月または数年にわたって機能し、後で SW の別のチームによって翻訳されます。

ドキュメントが広範になればなるほど、実現に時間がかかり、SW がユーザーの実際の要件に対応する可能性は低くなります。 市場の変化への対応は不可能であるか、多大な努力と一時的な譲歩がなければ可能ではありません。 ドキュメントは、製品を削除できる根拠を提供します。 残念ながら、書かれていることは必ずしも明確ではなく、結果は当初考えられていたものとは異なります。 部門のスタッフやエンドユーザーから、「ああ、想像していたものとはまったく違うものだった!」という言葉を何度聞いたことがありますか。 .

要因 6: バランスのとれたプロジェクト組織がない

20 人の開発者と 1 人の技術担当者のチームですか? この構造が遅かれ早かれ失敗することを認識するための専門知識は必要ありません。 プロジェクトの開始時には、ウォーターフォールであれアジャイルであれ、開発者がフレームワークや環境のセットアップで忙しいため、まだ機能している可能性があります。 しかし、すぐに従業員が質問をするようになります。集中的な専門家のサポートが必要です。

1 人の主題の専門家は、この時間的および感情的なプレッシャーに耐えることはできず、人員および実装プロセスの両面でサポートを必要とします。 しかし、コミュニケーションの制限で人員のボトルネックに対抗するのは非常に悪い考えです。

また、一般的なアイデアであり、典型的な管理エラーの規模の最前線です。従業員が開発者の質問を収集し、技術担当者と話し合い、回答を返します。 このようにして、卓越したボトルネックを作成し、非常に高いエラー率を引き起こし、開発を大幅に遅らせます。

要因 7: カエルをゆっくり加熱する

この話を知っていますか？ 水を入れた鍋にカエルを入れて加熱し続けても、カエルは逃げようとしません。 熱湯に直接放り込むと、すぐに飛び出します。

ここ数年の私に関する最も重要な知識の 1 つは、IT プロジェクトの従業員が失明の期間が長くなるにつれて死亡するということです。 一度確立されたプロセスは、振り返ってみると疑問視されるかもしれませんが、実際に抜本的になることはめったにありません。 人々が変化に反応する能力は、プロジェクトの期間に比例して失われます。

したがって、散発的な照明 (ヘルス チェック) は、外部の、以前は関与していなかったコンサルタントによる (大規模な) プロジェクトで推奨されています。 遅くとも本格的な危機を認識した時点で、既存のスタッフだけで立て直しを図ることはほぼ不可能です。

だからそれは可能です

ここに記載されている典型的な管理エラーは、SW 開発プロジェクトの成功を妨げている、あるいは妨げさえしている、私の個人的な行動パターンのヒット リストのごく一部にすぎません。 プロジェクトの初期段階で、問題を認識して修正するのは簡単であるという印象を遠方から受ける可能性があります。 しかし、おそらく不動のフレームワーク条件と言及されている盲目は、正しい決定を下すことをしばしば困難にします. 冒頭で述べたスタンディッシュ・グループの統計は、毎年この年を示しています。

プロジェクトに問題が発生した場合は、外部の危機管理者が客観的に分析して行動できるようにすることを強くお勧めします。 プロジェクトの人々に耳を傾ける専門家の唯一の参加は、すでにプラスの効果をもたらす可能性があります。 適切な手段の選択も変革に成功し、最終的には好転します。