プロジェクトの価格設定とスコープクリープの管理方法

公開: 2022-03-10
簡単な要約↬デジタルプロジェクトのスコープ、見積もり、および実行は、多くの場合、無駄の練習のように感じることがあります。 この記事では、Paul Boagが、プロジェクトを管理可能なフェーズに分割し始める必要がある理由と、それが大きなメリットを達成するための最良の方法である理由を説明します。

正確な見積もりを魔法のように作成できる価格設定への科学的アプローチがあることを示唆する非現実的な記事を読んだことは間違いありません。 また、スコープクリープは絶対に避けなければならないと思われるかもしれませんが、現実の世界では常に起こります。

今こそ、このばかげたゲームのプレイをやめ、ギャンブルではなく、堅牢で信頼性の高いプロセスに従うような方法でプロジェクトの実行を開始するときです。

私は誇張していますか? 可能性はありますが、デジタルプロジェクトで問題が発生することが多い場所を見てみましょう。

プロジェクトプロセスの問題

私の経験では、あらゆる業界のほとんどの組織がほぼ同じ方法でプロジェクトを実行しています。

  1. 管理者の誰かがプロジェクトの完了を要求します。 残念ながら、このリクエストには成果物に関する詳細が欠けていることが多く、漠然とした目標しか持たない傾向があります。
  2. 利害関係者の委員会が集まって、プロジェクトを詳細に定義し、範囲を決定します。
  3. 次に、詳細な範囲がそれを構築するチームに渡され、彼らはそれがかかる時間と費用を見積もるように求められます。
  4. プロジェクトは仕様どおりに納品され、時間と予算内での納品に重点が置かれます。 その結果、スコープクリープが敵になります。
  5. プロジェクトが配信され、全員がタスクリストの次のプロジェクトに進みます。

このアプローチは、特にデジタルプロジェクトにとって、理想からはほど遠いものです。 Digitalは、ユーザーの行動に関する前例のないフィードバックを提供し、(物理的な製品と比較して)変更を比較的簡単に実装できるようにします。 しかし、スコープが定義され、見積もりが提供されると、プロジェクトはロックダウンされ、プロジェクトの進行に合わせて誰もが変更を加えることを躊躇します。

しかし、必然的に、主に利害関係者が構築されるものについてさまざまな解釈を持っているため、またはプロジェクトの途中で重要な要素が間違っていることに気付いたために、範囲が変更されることになります。

実は、スコープクリープには何の問題もありません。 柔軟性を維持し、学習しながら適応することは、優れたデジタルサービスを作成するための基本です。 問題はスコープクリープではなく、プロジェクトの実行方法にあります。

残念ながら、期限とコストが合意されているため、これらの変更をこれらの制約内で提供しようと試み、コーナーを削減します。

そもそもタイムラインとコストが正確だったわけではありません。 デジタルプロジェクトは複雑で、多くの場合、専門家と利害関係者が協力して作業します。 その結果、正確に見積もることが難しいことで有名です。

正確に見積もるための方法論を提案する多くの記事を読みました。 ただし、ほとんどの場合、適用するには時間がかかりすぎるため、現実の世界では実用的ではありません。 プロジェクトの見積もりは、直感、経験、および知識に基づいた推測に帰着します。

いつでもこの分野で働いたことがある人なら誰でも言うように、ほとんどの見積もりはフィクションの作品です。 私たちは通常、適切なソリューションが何であるか、またはユーザーがそれにどのように対応するかを判断するためにさえ、事前に十分なことを知りません。 したがって、プロジェクト全体を事前に正確に見積もることは不可能です。

残念ながら、このあいまいさは、プロジェクトが必然的に期限を過ぎて予算を超過した場合に、非難を不当に分散させることにつながることがよくあります。

幸い、正確な見積もりを提供し、実行プロジェクトの変更を伴うスコープクリープを管理する方法があります。 その秘訣は、プロジェクトを小さなチャンクに分割することにあります。 このアプローチは、大規模で複雑なプロジェクトを引き受けることを回避します。

ジャンプした後もっと! 以下を読み続けてください↓

プロジェクトを一連の小さなエンゲージメントに分割する

この時点で明確にする必要があります。 私は野心的な仕事のプログラムが間違っていることを示唆しているのではありません。 私は大規模なクライアントのために、充実したWebサイトや広大な仕事のプログラムで働いています。 ただし、これらのエンゲージメントを単一の大きなプロジェクトとして扱うことはめったにありません。 代わりに、私はそれらを、一度に1つずつスコープするより管理しやすいプロジェクトに分割します。

クライアントがデジタルプロジェクト(大小を問わず)を引き受けたいと私に近づいたとき、私は通常、それを次の順序で発生する4つの段階に分割します。

  1. 発見、
  2. アルファ、
  3. 最小実行可能製品、
  4. 進行中の反復と最適化。

各段階は、明確な成果物との個別の取り組みです。 したがって、私はプロジェクト全体にコミットするのではなく、最初のフェーズにのみコミットします。 これにより、スコープクリープの推定と管理がはるかに簡単になります。

たとえば、次のステージのスコープを定義するだけで済みます。 これにより、前のステージが完了した後、次のステージを定義するときにスコープクリープに対応できるため、スコープクリープをより適切に管理できます。

作業プログラム全体を見積もる代わりに、そのプログラムの次のプロジェクトを見積もっています。 また、前の段階を使用して、より正確に見積もることができます。

各段階は、発見から始まる次の段階を定義および推定するのに役立ちます。

1.発見

発見段階では、利害関係者と協力してプロジェクトを検証します。 プロジェクトの全体的なサイズに応じて、これは2、3回の会議のように単純な場合もあれば、作業プログラム全体の場合もあります。

通常、次のような要素が含まれます。

  • ユーザー調査の実施。
  • 競争の分析;
  • 主要業績評価指標の特定。
  • 成功がどのように見えるかを定義する。
  • 制約を理解する。
  • 利害関係者の意見を照合する。

アイデアは、発見フェーズで、ユーザーのニーズ、ビジネス目標、作成する必要のあるものなど、プロジェクトのより多くの情報に基づいた定義を提供することです。

最も重要なことは、プロジェクトが必要な価値を提供することを検証することです。

次に、この成果物を使用して、アルファフェーズで必要な作業を定義および見積もることができます。 そうすることで、見積もりがより正確になり、学習した内容に基づいて範囲が調整されます。

2.アルファ

アルファフェーズでは、デジタルサービス(Webアプリまたはサイト)がどのように機能するかを定義し、ユーザーがそれを使用して前向きな体験をするようにします。

これは通常、プロトタイプの作成を通じて行われます。 小規模なプロジェクトでは、これはいくつかの設計モックアップにすぎない場合があります。 大規模なプロジェクトでは、人々が試すことができる機能的なプロトタイプになる可能性があります。

いずれにせよ、アイデアはあなたが構築しているデジタルサービスを視覚化することです。

これを行う理由は3つあります。

  • まず、視覚化により、すべての利害関係者があなたが作成しているものについての共通のビジョンを持つことが保証されます。 ドキュメントはさまざまな方法で解釈できますが、プロトタイプではそれを行うのははるかに困難です。
  • 第2に、プロトタイプを使用すると、見落とされた可能性のあるものを簡単に特定できるため、対処に費用がかかる場合は、スコープクリープを回避できます。
  • 最後に、具体的なものがある場合は、ユーザーと一緒にテストして、本物を構築する費用をかける前に、目的に適合していることを確認できます。

テストが不十分な場合でも、予算を壊したり、タイムラインを台無しにしたりすることなく、次のフェーズの前に適応する余地があります。

発見フェーズと同様に、アルファを使用して次のステージで必要な作業を見積もることができます。 構築する必要があるものを視覚化することで、関係するすべての利害関係者にとって必要な作業の見積もりがはるかに簡単になります。 彼らは彼らが構築するように求められているものを見ることができます。

さらに、アルファのテストから学んだ教訓を使用して、作成するものを適応させることができ、プロジェクトを狂わせることなく、スコープを変更するためのスペースをもう一度作成できます。

アルファ版を入手したら、自信を持ってビルドに移行できます。正しいものを作成し、ユーザーがそれに積極的に反応することを知っています。

3.最小実行可能製品

私はこの段階を「ビルド」と呼んでいました。 ただし、関係者はビルドの完了とプロジェクトの完了を関連付けていることがわかりました。 実際には、デジタルサービスは、可能な限り効果的であることを保証するために絶えず繰り返される必要があるため、決して実行されません。

この問題を回避するために、私はこの段階を最小実行可能製品(MVP)と呼び始めました。 この段階では、デジタルサービスの初期バージョンを構築して起動します。

これを最小限の実行可能な製品と呼ぶことで、リリース後の反復があることを強調します。 これにより、スコープのクリープと予期しない複雑さに対処する方法が提供されます。これは、リリース後までスコープをプッシュバックすることによって実現されます。 これにより、プロジェクトは順調に進み、勢いを維持できます。

必然的にビルド中は、リリース後までいくつかのものを棚上げします。 これらの要素は、最終段階を定義するための基礎となり、リリース後の最適化の初期見積もりを行うことができます。

4.継続的な反復と最適化

リリース後のフェーズでは、MVPで対処しなかった機能、複雑さ、およびその他の問題を扱います。 この改善点のリストは、この時点で比較的簡単に調査でき、妥当な精度で見積もることができます。

ただし、この作業に加えて、デジタルサービスの有効性をさらに向上させる、監視、反復、およびテストの継続的なプロセスが必要です。

この作業のどれだけを行うかは、デジタルサービスのサイズと複雑さに基づいて見積もる必要があります。 見積もりは、プロジェクトの残りの部分への投資にも比例する必要があります。

プロジェクトをこれらの4つのフェーズに分割し、それぞれを個別に完了することで、従来のプロジェクト管理アプローチを使用するときに直面する多くの課題を取り除くことができます。

プロジェクトの分割が機能する理由

このようにプロジェクトを分解すると、次の4つの大きなメリットが得られます。

  • 各フェーズはより適切に定義されています。
    前のフェーズの成果物は各段階を定義するため、方向性の明確なビジョンがあることを意味します。 これは、利害関係者が物事がどこに向かっているのかを理解するのに役立ち、後で厄介な驚きを回避します。
  • プロジェクトはより正確に見積もられます。
    たとえば、かなりの数の未知数を含む重要で曖昧なプロジェクトを提供するのにかかる時間を推測する代わりに、次のフェーズを見積もり、前のフェーズの成果物に基づいて見積もります。
  • それはより良いデジタルサービスをもたらします
    プロジェクトのアイデアはユーザーによって検証およびテストされるため、最終製品が目的に適合することをより確信できます。 また、フェーズ間で範囲と機能を調整して、可能な限り最高の結果を提供できるようにします。
  • リスクの少ないアプローチです。
    デジタルサービスを委託する会社は、プロジェクト全体を事前にコミットする必要はありません。 発見フェーズでプロジェクトの実行可能性を検証できない場合は、わずかな損失でプロジェクトを削除できます。 同様に、アルファプロトタイプがユーザーに対して十分にテストされない場合は、物事が高額になる前に適合させることができます。

この最後のポイントは、外部のサプライヤーが初めて使用される場合に安心です。 彼らが提供できるかどうかを知らずに実質的なプロジェクトに代理店を登録する代わりに、クライアントは彼らがどのようなものかを見るために発見段階に彼らを従事させることができます。 彼らが良ければ、彼らは彼らと一緒に働き続けることができます。 そうでない場合、彼らは何も失うことなく別の機関に調査結果を持ち込むことができます。

あなたが代理店を経営している、またはフリーランサーであるなら、これは悪い考えのように聞こえるかもしれません。 当然のことながら、プロジェクト全体のクライアントにサインアップすることをお勧めします。 しかし、クライアントがそのような小さな初期投資でリスクを冒していると感じなかったので、私はこのアプローチで多くの競争入札を避けました。 また、私が気に入らなければ簡単に切り替えられるので、いろいろなサプライヤーと話す必要性を感じませんでした。

さらに、この段階的なアプローチを使用すると、次の固定価格プロジェクトの範囲と価格設定がはるかに簡単になります。 確かに、それは魔法のように見積もりを提供したり、スコープクリープを防いだりすることはありません。 ただし、一度に1つのパーツしかスコープしないため、見積もりがより管理しやすくなります。 また、スコープクリープを抑制しようとするのではなく、スコープクリープを操作できるようになります。

したがって、社内でも社外でも、大小のサイトで作業する場合でも、プロジェクトをフェーズに分割せずに見積もりとスコープを設定することをやめることをお勧めします。 代わりに、一度に1つのフェーズに取り組み、学習した内容を使用して次のフェーズに通知します。 そうすれば、より正確に見積もりを行い、学んだことに基づいて適応する余地があり、プロジェクト管理がより簡単であることがわかります。