マスターボリュームの方法と指標の実用的な解釈

1.はじめに

Earned Volume Technique（MOO） 1 2-技術は慣らし運転されており、間違いなく効果的です。 ただし、適用することを決定する場合、その効率の効率係数を大幅に低下させるいくつかの明白でよく知られている制限を念頭に置く必要があります。

まず、プロジェクトの一部が完了した後にのみMOOを適用する必要があります（約15％-20％ 3。 / CPI、安全に信頼できます。

第二に、プロジェクトの相互接続性と不可抗力イベントが監視対象プロジェクトと将来のタスクの結果に与える影響を考慮しないのは、MOOの基本的な指標です。 たとえば、主要な開発者が突然病気になったり、緊急事態に予期せずに出て行ったりすると、現在のプロジェクトの期限が混乱し、計画されているがまだ監視されていない後続の作業の期限が変更されます。 計画されたタスクは「将来」のカテゴリに属する​​という事実により、それらの指標は測定されません。 それにもかかわらず、将来発生した障害もそれらに影響します。

そのため、MOOを実際に適用する場合、これらのリスクを考慮し、上記で特定された制限を削除する必要があります。 この原則は、顧客の利益のためにプロジェクトの実施に従事している特定のIT会社の例として考えてください。

1つの短い記事では、プロジェクトマネージャーと生産部門が日常業務で直面するあらゆる範囲のリスクに適合することは不可能であることは明らかです。 ただし、この例では、実際に注意深くレイアウトされた「レーキ」を事前に確認し、生産プロセスを中断することなくそれらを回避する方法を学習できます。

2. IT企業のプロジェクト活動のモデル

簡単にするために、設計部門が次の部門で構成される会社を考えてみましょう。

• アナリストおよびアーキテクト部門。
• 2つの開発部門。それぞれが会社のプロジェクトで使用される独自の製品セットを開発します。
• テスト部門;
• 実装部門。

会社のポートフォリオにはN個のプロジェクトがあり、その数は「従業員に過負荷をかけずに一度に実行できる量」の原則に従って客観的に決定されます。 プロジェクトの各段階での作業条件と実装の期間が決定されます。 部門のリソースもプロジェクトのタスクに関連付けられています。

会社のプロジェクトオフィスは少なくとも2人で構成され、それぞれがプロジェクトポートフォリオの一部を担当しています。

3.プロジェクトのポートフォリオの実施における主なリスク

このモデルをリーダーの立場から見てみましょう。 作業の過程でどのような問題が発生する可能性があり、それを回避するために何ができるかを尋ねることは論理的です。
ほとんどすべての設計組織の惨事は、予算と指定された期限からの「出発」です。 興味深いことに、発表された日付よりも大幅に遅れて予算を超過することは、かなり予測可能な理由で発生します。

1つ目の理由：現在のプロジェクトと将来の作業の量とコストは、潜在的な不可抗力や特定の（抽象ではない）プロジェクトの複雑度を考慮せずに、楽観的なモデルを使用して推定されます。 会社がちょうど1か月で10のプロジェクトを正常に完了したとしましょう。 マネージャーは11番目のプロジェクトを担当し、以前に完了したものと同様の期限を設定します。 プロジェクトの複雑さがより高い場合、または作業中に不可抗力が発生した場合、指定された用語は中断されます。

2番目の理由：外部作業への資金提供の遅れ。その結果は、プロジェクトの成功全体にかかっています。

3番目の理由：さまざまなリソースの競合（すべての種類のリソース、労務費など）。

4番目の理由：プロジェクトに割り当てられたリソースのどの部分が回復不能なほど失われるかによるエラー。 たとえば、彼らは突然予算を削減したり、パフォーマーは機器を購入したり、第三者の仕事にお金を払ったりする必要があり、その結果、価格を引き上げました。

これらのリスクの1つ以上がトリガーされると、リソースと時間のプレッシャーが不足するため、顧客と開発者は「最悪から最良のソリューション」を緊急に探し始めます。 状況は効果的ではなく、不快であり、誰もそれを繰り返したくない。 それにもかかわらず、彼女はいわば、それを防ぐための指導者のあらゆる努力にもかかわらず、繰り返しがちです。

4.反対側から状況を見ます。

映画「コーカサスの囚人」では、典型的な間違いを特定するためのモデルを完全に説明するフレーズが聞こえました。「私たちを悩ます人が私たちを助けてくれます。」 したがって、多くのプロジェクトで、次の一般的な機能に気付くことができます。

1. タスクの計画と分析の段階では、通常、同じ従業員が同じレベルの能力で評価されます。そのため、エラーの割合または期限の「脱落」の可能性を事前に予測でき、安定した指標になります。

   
   

2. 実装段階では、人々は同じタイプのタスクで平均して安定して作業し、作業計画に安定した間違いを犯します。

   
   
3. 従業員は部門に特化しているという事実により、同様の原則に従って同様に計画されたタスクを実行します。

つまり、要約すると、 従業員は明日、今日と同じように働いています（1） 。

もちろん、この声明はケースバイケースで検証する必要があります。 タスクを完了するための計画および実際のタイムライン、および各部門に帰属する作業量を定期的に確認する必要があります。 計画と事実の関係が安定している場合、この仮説を使用できます。

2番目の、しかしそれほど重要ではない部分は、統合プロジェクト管理システムの構築に役立ちます。これは、プロジェクトを議論する時間と意見の相違の数を大幅に削減する、すべてのプロジェクトの将来の単一の図です。 これは、リソースの競合に関連する状況で特に当てはまります。 個々のプロジェクトとポートフォリオ全体の両方のステータスを全体として評価することは、従業員が入力したソースデータを使用する自動システムに基づいています。 これらのデータに基づいて、予測が形成されます（2） 。

この場合、使用量のインジケータが使用されます。 たとえば、次の画像に示すように。

-計画されたタスク
-予測タスク
-スケジュールされた支払い
-支払いの予測。

潜在的な問題を事前に予測できる次のポイントは、プロセスで実行されるタスクの接続性を理解することです。 つまり、マネージャーは、特定のタスクが実装にさらに時間とリソースを必要とする場合、それに続くタスクが自動的に再計画またはリソース不足のリスクに陥ることを理解する必要があります。

5.実際に開発されたボリューム方法論の適用について

ここで、抽象的なファブリケーションから方法論の実用化に移ります。 これを行うには、次のタスクを解決する必要があります。

1. 開発されたボリューム方法論を使用できる結果の防止のための主なリスクを説明してください。
2. 使用法に適した形式で、方法論自体とそのアプリケーションのアルゴリズムを策定する。
   主なリスクは次のとおりです。
3. 2つ以上のプロジェクトが同時にリソースを要求しているという事実から生じるリソースの競合。
4. 予定時刻にリソースが不足するリスク：労働、財政など プロジェクトは、タスクの実装に必要な商品またはサービスの提供の遅れに直面する可能性があります。
5. たとえば、結果に関係なく給与が支払われた場合、またはプロジェクトの期限に間に合わない場合に、リソースが十分に活用されないリスク。

これらのリスクを特定し、企業がそれらを回避する方法 まず、1日だけでなく、将来の状況を評価する必要があります。 問題が理論的に発生する可能性があることを想像してください。次に、この否定的な状況が発生しないように必要なアクションを理解する必要があります。

リスクを特定するために、開発されたボリューム手法を使用するのが最も便利です。 実際には、プロジェクトマネージャーには、プロジェクト活動のリスクを監視および管理するためのツールが必要です。 そのような制御のためのツールのリストに主要なポイントをリストします。

5.1財源によるプロジェクトのセキュリティ

支払いスケジュールの予測値に基づいて推定されます。 現在時刻からプロジェクトの完了予定時刻までの期間を推定期間とします。 タスクは、計画された支払いのスケジュールを表示し、支払いの実際の予測と比較することです。

予測時には、次のスケジュールされた支払いが遅れた場合のプロジェクトの予算の十分性、および期間間の資金移動のサイズがチェックされます。 とりわけ、将来的には、プロジェクトの完了後に予算内の資金のバランスを評価する必要があります。

5.2労働資源を伴うプロジェクトの提供

これは、同じ期間（現在の時刻からプロジェクトの完了の予測時刻まで）の労働リソースに対するプロジェクトのニーズの予測に基づいて推定されます。 評価中に、リソースプールの予測負荷と計画タスクの実装に必要な時間が重畳されます。

リソースプールのいずれかで過負荷が観察された場合は、プロジェクトマネージャーに実証する必要があります。 この段階でのタスクは、FIFOの原則に従って動作するようにされていないタスクを再スケジュールすることです。 同時に、予測される期限が以前にスケジュールされた完了日に対応している必要があります。

したがって、潜在的な過負荷がリソースプールのいずれかによって識別された場合、プロジェクトマネージャーはFIFOの原則に従って負荷を自動的に分散できます。

自動化された競合解決を使用できない場合、プロジェクトマネージャーはリソースプールの負荷を共同で再計画するように求められます。

6指標の実用化

個々のプロジェクトおよび統合ポートフォリオの場合、時事問題の状況と会社全体の業務を評価するレポートシステムを構築する必要があります。 プロジェクトマネージャーは、労働および金融リソースに関連するリスクの管理がはるかに容易になります。

6.1プロジェクトの評価

プロジェクトがほとんどの時間で正常に実行されていると仮定すると、プロジェクトの完了のマイナスの影響の程度を示す適切なカラーマーカーを使用して、そのタイムリーな完了に悪影響を与える可能性のある実装および予測状況の量の評価を通じて、プロジェクトのステータスを最適に表示します。

6.2ポートフォリオ評価

最も簡単な方法はパネルの形で視覚化されており、その主なアイデアはprojectprofiler 4で借用されており、各プロジェクトのポートフォリオとサマリー情報の一般的なステータスが強調表示されています。 SPI-CPI座標系（SPIはX軸、CPIはY軸）でプロジェクトの位置を計算するには、セクション7の式を使用して対応する値を計算します。

6.3財務リスク管理

財源の運用管理の原則：

原則1.「未使用資金のリリース」。 タスクが完全に完了し、プロジェクトマネージャーがこれらを完了し、実際に費やされた資金を明確にし、残りを利用可能としてマークすることを条件に、未使用の財務の可能性を定期的に評価する必要があります。他のプロジェクト。 これは、期間t + iのプロジェクト/ポートフォリオの予算の充足に関するレポートを作成することによって達成されます。i-現在の時間、 i-四半期の数-特定の支払日までの債務額と対応する日付までの支払スケジュールの差としてプロジェクトレベルで計算されます関連記事。

この場合：

• 現在の計画期間の終わりの金額の偏差（予測-計画）が（10-15％）以内であり、次の計画期間の終わりに（15-25％）以内であれば、それぞれのプロジェクトのマネージャーが計画を調整するよう招待されます予測値を許容可能なフレームワークに戻すような方法でプロジェクトを作成します。

  
  
• 偏差（予測-計画）が上記の値を超える場合-1人のマネージャーによるソリューションが失敗する可能性が最も高く、この決定の影響を受ける可能性のある全員がソリューションに接続されます。

原則2「赤字管理」。 タスク別の支出額を分析し、定量的および時間的な次元で資金不足を予測する必要があります。これに基づいて、プロジェクトの変更を保存または開始するためのアクションを実行するようプロジェクトマネージャーに提案します（承認するため）。

分析は、計算された計画期間の終了日に、記事の限度額とこの記事の予測費用額とを比較することによって実行されます。 記事の費用の推定額は、必要な費用、為替レート、仕入先の作業の料金、および支払いスケジュールのすべての予測値を考慮して、計画期間の終了時の対応する記事の支出額の予測値として計算されます。 この場合：

• 現在の計画期間の終わりの金額の偏差（予測-計画）が（10-15％）の範囲にあり、次の計画期間の終わりに（15-15％）の範囲にある場合、関連するプロジェクトマネージャーが招待されます。予測値を許容可能なフレームワークに戻すようにプロジェクト計画を調整するか、対応する期間の潜在的な節約を修正します。

  
  
• 支払い時に、偏差が固定されている場合（計画-事実> 0）、または現在の計画期間の終わりの金額の偏差（予測-計画）が上記の範囲外である場合、この偏差は対応する費用項目に応じて自動的に貯蓄としてマークされます。

6.4。 人事リスク管理

労働リソースの運用管理の原則：

原則1「負荷の平準化」。 タスクを遅らせる機会（空きリソースが予測される領域）が定期的に評価されます。1つのリソースプールは、次のように、前のタスクが終了した直後にこのプールに落ちます。

• プロジェクトタスクの初期計画中、タスクは計画された作業と実際の作業の完了に応じて調整されます。リソースの競合が発生した場合：

-原則2を使用しない再計画を考慮したタスク完了の期限がプロジェクト完了の計画期限内であれば、タスクは新しい日付に割り当てられ、WBSに反映されます。

-原則2を使用せずに再計画を考慮に入れてタスクを完了するための期限により、計画された時間内にプロジェクトを完了することができない場合、WBSはプロジェクトマネージャーの参加とリソース競合の解決の結果を反映します。

• 予測に基づくタスクのいずれかが計画よりも早く終了した場合、請負業者には次のタスクが順番に自動的に割り当てられ、WBSに反映されます。

原則2「リサイクル」。 健康に重大な損害を与えることなく、従業員は1日に2時間、1か月あたり4組の休日のうち3日間（各10時間）以内に短時間で処理できると想定しています。 したがって、プロジェクトの生産部門のプロジェクトマネージャー間の合意は、次の原則に基づいている必要があります。

• WBSプロジェクトへの相互影響の最小化。
• リソースの使用に対する公正な補償。

たとえば、「プロジェクト1」はCICスケジュールに戻るために90h / hを見つける必要があります。 この問題を解決するために、彼はすべてのリソースが適切に計画され、遅延がない「プロジェクト2」に目を向けます。 次に、「Project1」は追加料金を支払う必要があります。

• 標準レートでのリソース124h / h。標準レートで56時間/ h（7営業日）であり、（20_weeks +稼働日あたり14_processes）=ダブルレートで34 h / hです。
• 「プロジェクト2」88h / hを標準レートで使用して、平日の44h / hの処理を補償し、週末に処理します。

原則3「一時的なリソースプールの拡張」。 固定された労働投入（低負荷のリソースはタスク期間ではない）、1つのリソースプールを使用してタスクの時間を短縮する可能性を評価し、プールごとに1つのタスクをより短い期間で実装できるようにする必要があります。そのようなタスクの結果はWBSに反映されます。

原則4「未割り当てリソースの解放」。 タスクの作業が完了し、この方法で見つかったリソースをプロジェクト計画で無料としてマークする場合、労働リソースの解放の機会を評価する必要があります。

原則5「客観的な遅延の修正」。 関連タスクの遅延の可能性を評価し、見つかった場合は、2人のプロジェクトマネージャーを接続して、タスクの再計画または2つのタスク間のリソース交換を提案する必要があります。

7.累積量を計算するための調整された方法論

7.1。 ソースデータ

マスターボリュームのインジケーターを計算するには、次のデータが必要です。

• プロジェクト予算：記事と計画期間の制限。
• カレンダーリソースプラン（WBS）。
• 現在および予測の為替レート（外国企業の商品または作品を購入する場合）;
• プロジェクトのタスクに関するデータ：タスクの完了、償却、および支払いをWBSタスクにリンクするための計画および実際の期限。
• 期間別のリソースプール％（労働リソース-労働）。

7.2。 予測値

主な仮説の場合

• （1）従業員の仕事の安定性（むしろ、計画エラーの分布の安定性）は、統計の検証によって確認されます。
• （2）世界の単一の写真についてなんとか合意した、
  その場合、労働リソースの使用予測に切り替えることを妨げるものは何もありません。その実装に含まれるリソースの計画/事実の指標に応じて、タスクの計画期間を調整します。 すなわち：

7.2.1。 WBSの予測プロジェクトタスク期間

プロジェクト内の番号kを使用して-実際の期間を反映する償却に基づいて計算されます このリソースプールでの作業のパフォーマンス 他のプロジェクト（これは正しい。従業員が同じチームを評価しても評価エラーが変わる可能性は低いため）。

計算は、関連するリソースプール（ i ）のコンテキストで、閉じられていないタスクの予測値を予備計算することによって行われます。
どこで -次のように定義された事実/計画比：

ここで、 q = 0、..、3は、現在の期間に関連して予測が行われる四半期の数であり、期限切れのタスクの場合はq = 0であり、 -過去3か月間の平均、すべてのタスクのスコア i番目のリソースプールが参加します。 閉じたタスクの場合 。

それは：

• 現在のタスクの現在のデータに基づいて評価が可能である場合-それが行われ、
• 関連データがない場合-3か月間のデータに基づく平均推定値、
• データがない場合、予測は計画と同一であると見なされます。

全体としてのタスクの予測終了は、次のように計算されます。
ここで、 iはタスクの実装に関係するリソースプールです。

タスクが完全に完了した場合、予測される終了時間は実際の時間と一致します。

したがって、各時点で、各WBSタスクの予測完了日が決定されます。

7.2.2。 プロジェクト完了期限

予測される完了日に基づいて、現在のWBSに基づいて計算されます。 計画値の代わりに使用 ：

。

7.2.3。 使用量の予測値

時間tで番号kのプロジェクトでは、このプロジェクトのタスクの実装における実際の/予測された進捗を計画されたものと比較することに基づいて構築されます。 計算は、プロジェクトの予測ボリューム値を事前に計算することにより行われます 、
どこで は、実際に発生または予測されたプロジェクトkの人件費を時間tまでに反映し、タスクの完了期限に焦点を当てています。段落を参照してください。 7.2.1および7.2.2）。

したがって、その時点でのプロジェクトのボリュームの計画値は、次の形式で計算されます。

、
ここには、プロジェクトの時間ごとの計画人件費が反映されています。

したがって、累積ボリューム（SPI）の値：

。

7.2.4。 コスト開発のダイナミクスの予測値

時間tで番号kのプロジェクト-支払いスケジュールの実行における実際の/予測された進捗、このプロジェクトと計画された進捗の比較に基づいて構築されます。 計算は、時間tまでに発生するプロジェクトコストの予測値を予備計算することによって行われます。

、

どこで タスクの予測完了日に基づいて、この時点までの為替レートの予測値を考慮して、時刻tに実際に発生または予測されたプロジェクトkのコストを反映します。段落を参照してください。 7.2.1および7.2.2）。 したがって、時刻tでのプロジェクトkの計画コストは次の形式で計算されます。

、

どこで この時点での為替レートの予測値を考慮して、時刻tでのプロジェクトkの計画コストを反映します。

したがって、ボリュームコスト（CPI）の開発のダイナミクスの値：

Revaz Bukhradzeと共同で書かれています。