8ソフトウェアプロジェクトが失敗する一般的な理由と成功する方法

ITプロジェクト管理|Duncan Haughey著|時間分を読む

画面上の黄色のマーカーペンで成功のために失敗を横切ります

いくつかの心配な統計から始めましょう。 2015年のStandish Groupの報告書によると、ソフトウェアプロジェクトの成功率は29%、挑戦率は52%(コスト超過、予算超過、コンテンツ不足)、失敗率は19%となっています。 これらの調査結果は数年前に最初に現れましたが、その結果は今日ではあまり真実ではありません。

さらに、お客様が価値があると考えられるプロジェクトの割合は59%であり、お客様が満足と考えられるプロジェクトの割合は56%である。

不満足なプロジェクトの結果は、顧客が結果に満足していなかったIT業界の標準となっています。 だから我々はそれについて何ができますか?

良い出発点は、ソフトウェアプロジェクトが失敗する重大な理由のいくつかに対処することです。

理由1:時間が足りない

多くの場合、プロジェクトが開始される前に締め切りが決定され、交渉できません。 この期限は、仮定に始めるために真っ逆さまに急いで結果、早くあなたがコーディングを開始し、早くあなたがプロジェクトを終了します。

コーディングを開始するために急いでは、ほとんどの場合、間違ったアプローチです。 良いデザインを作成するために時間を費やすことが不可欠です。 良い設計をしていないと、開発段階を通して継続的な変更につながります。 これが起こるとき、時間および予算は急速な率で消費されて得る。

:

  • まっすぐに跳び、コーディングを始めるように誘惑されてはいけない。
  • 良いデザインを作成するのに十分な時間を割り当て、プロジェクトの残りの部分ははるかに良く実行されます。

このアプローチは、顧客の期待を満たし、初めて正しく動作するものを提供するときにあなたの評判を向上させます。

理由2:予算不足

多くのプロジェクトは、プロジェクトの要件に基づいていない、最低価格、最も成功したサプライヤーポリシー、または非現実的に低予算 これが起こると、すべてが遅くなります。 資源は着くために遅いか、または決して着きません;コーナーは切られて得、質は苦しむ。

:

  • 予算について現実的であり、完全な条件に基づかせていなさい。
  • サプライヤーの選択は最低価格のみに基づくことは避けてください。
  • 予算内で納入実績のあるサプライヤーまたはチームに行きます。
  • プロジェクトに適したサプライヤーを見つけるには、以下のようなサプライヤー選択チェックリストを使用します。

サプライヤー選択チェックリスト紹介ページ

理由3: コミュニケーションが悪い

“何も想定しない”という格言があります。 プロジェクトを成功させるには、顧客、ユーザー、開発チームとの良好なコミュニケーションが不可欠です。 自分自身に三つの質問をする:

  1. チームの全員があなたを理解していますか?
  2. 彼らはあなたが彼らに期待していることを知っていますか、それとも彼らが知っていると思っていますか?
  3. ユーザーや他の部門とのコミュニケーションはうまくいっていますか?

:

  • 今、任意の通信の故障を見つけます。 これらは、プロジェクトの後半で混乱や合併症につながる可能性があります。
  • 誰もがプロジェクトで起こっているすべてを理解していると仮定しないでください。
  • 通信がアクセス可能で、オープンで頻繁な環境を作るために時間をかけてください。

理由4:プロジェクトの進捗状況を確認しない

プロジェクトが進行するにつれて、物事が変化し、プロジェクトに大きな影響を与えます。 課題を早期に克服し、可能性のある遅延や成果の変化の利害関係者に警告するために、プロジェクトの進捗状況を調べ続けることが重要です。

:

  • プロジェクト中にチームや利害関係者との進捗状況を確認するために、常にマイルストーンを設定します。 コースに滞在するために必要に応じて調整します。
  • 何が起こっているのか、彼らが直面している課題を理解するために、あなたのチームの近くに滞在します。

理由5:不十分なテスト

配信する圧力がオンになっているとき、テストはしばしば苦しんでいます。 テストは、テストに費やされる労力を最小限に抑えて、開発サイクルの終わりまで放置されます。 通常、結果はバグと不幸な顧客で満たされた製品です。

:

  • 開発ライフサイクル全体を通してテストを行い、各モジュールまたはコンポーネントを開発時にテストします。
  • は、開発ライフサイクルが終了するまで統合テストを残すだけで、ストレスが少なく、より良い製品が得られます。

理由6:本番環境でのテスト

本番環境で製品をテストする組織の数は驚くべきことです。 実稼働環境を使用することは、テストなしでセキュリティ侵害や偶発的なリリースにつながり、実稼働システムを混乱させるリスクの高い戦略です。

:

  • 品質保証と新しいソフトウェア製品のリリースのためのプロセスを開発します。
  • テストやバグ修正のために、本番環境とは別の環境を提供します。

理由7:品質保証の欠如

多くの場合、ソフトウェアを提供するために私たちの急いで、品質保証が苦しみます。 コードの変更のための文書は不完全であり、設計に欠陥が含まれており、実装は未完成である可能性があります。 これらはすべて、手直し、失われた時間、そして最終的に不幸な顧客につながります。

:

  • リリース前に品質チェックと文書ソフトウェアに時間がかかります。
  • レビュー Michael L Young article6プロジェクト品質を管理するための成功要因

理由8: 業界標準に準拠していない

World Wide Web Consortium and International Organisation for Standardisation logos

ソフトウェアプロジェクトにおける業界標準に準拠することは、優れたアクセシビリティ、移植性、使いやすさ、堅牢性を確保し、現在および将来の問題を軽減することによって有益であることが証明されます。 World Wide Web Consortium(W3C)や国際標準化機構(ISO)などの機関は、挑戦するのが難しいオープンな標準を開発しました。

:

  • あなたのプロジェクトのための標準的なアプローチを導入するのに時間をかけなさい。
  • うまくいくものを見つけて、それを続けてください。
  • 動作していないものを変更します。
  • 定期的に基準を見直し、更新してください。

次回ソフトウェア開発プロジェクトをプロジェクト管理するときは、このリストを確認し、成功を確実にするために必要なものを思い出させます。 あなたは驚かれることでしょう;それは違いがあります。

推奨される読み取り:ホルヘ-ドミンゲスによるカオスレポート2009の好奇心のケース。

コメントを残す

メールアドレスが公開されることはありません。