Earned value ：出来高
プロジェクトの規模が大きくなればなるほどプロジェクトマネジメントが大事なものになります。
なぜなら大勢の異なる価値観を持った人たちを同じ目標に向かって仕事をしてもらうことがとても大切なことだからです。
そして、その仕事に対する価値観もそれぞれです。
極端な話とすると、ほとんどの人が生活の為に仕事をしているのです。
1人で、１から10まで、つまり全部の仕事をこなす場合は、その仕事をやる人の責任でやれば良いわけで、納期通りに仕事を全うすれば報酬が発生するわけですから。
ところがチームで仕事をする場合、これはプロジェクトとなるわけです。当然チームの足並みがそろわなければ仕事は全うできません。
さらに複数のチームからなるプロジェクトの場合はなおさらです。例えば5人１チームで３チームの仕事があったとしましょう。（大抵のプロジェクトは大人数で複数のチームからなります）
チームの仕事には分担があり、各チーム内の結束が固いだけでは、仕事は進みません。例えば各チーム間の仕事の内容は独立していたとしても、プロジェクトにおける仕事は、各チーム間で関連していたり、片方のチームの仕事の進み具合に依存するものだったら。どうなると思いますか？
ここまで抽象的な話をしてきましたので分かり辛かったかも知れません。具体例を挙げてみましょう。
Ａチームは何らかのものを作るための設計をするのが仕事です。
ＢチームはＡチームが設計した設計書に基づいてものを作るのが仕事です。
Ｃチームは仕様通りにできているかテスト・検査するのが仕事、そしてＤチームは最終納品に向けて実用的かどうかを含め最終検査をするという分担としましょう。
各チームの作業内容は異なりますので、完了基準も違います。チーム内では共通の言語であっても、チーム間は違います。（単純に「完了しました」の報告だけでは済まないからです）
ここで各チームバラバラの完了報告基準で計画を立てたら、プロジェクト管理は成り立ちません。
プロジェクトマネージャは各チームのリーダーから異なる基準・言うなれば違う言語で報告を受けることになるからです。
想像してみてください、多数の言語で説明されたら難解なだけでなく聞き間違いや理解の仕方・翻訳ミスなどが発生します。これが課題になったりひどいときには新たな問題になります。
そして実際のプロジェクトでは、A ➡ B ➡ Cの様に直列に仕事をする訳ではありません。
多くの並列ジョブがあったり、交錯したり、片方のジョブは、もう片方あるいは複数のジョブの完了待ち（依存関係）であったりするのがほとんどです。
だから、プロジェクトの進捗管理には、共通の言語が必要となるわけです。
それが成果基準です。
予算および予定の観点からプロジェクトがどのように遂行されつつあるかを定量的に評価し進捗を測るための共通の言語、それが出来高で報告することです。
EVM出来高管理
期日内の計画に対してどれだけ出来上がったかを評価するのです。
- 計画とは予定工数（WP）と、計画完了数（PV：Planned Value）です。
- 実績は、実績工数（WP）と、出来高（EV：Earned Value）です。
そして期日内での結果が
× PV > EVなら進捗遅れ
〇 PV = EVなら予定通り（計画通り）
◎ PV < EVなら予定以上の成果を出せたことになります。
EVMの大まかな流れ「計画立案」と「現状把握」
計画立案
プロジェクト全体を細かい作業に分割（※）した構成図を作成する
WBS（Work Breakdown Structure）などの手法を用いて、プロジェクト活動を複数の工程に分割します。
（※細分化は、WBSの最下層タスク、WP(ワークパッケージ）レベルまで落とします。）
そして、各工程で必要な予定工数、「出来高計画値（PV:Planned Value）」を算出します。
現状把握
その時点までに完成した成果物を「出来高実績値（EV:Earned Value）」に換算し、
実際の「投入実績値(AC:Actual Cost)」を把握します。
PVとEVの差がスケジュールのズレ、EVとACの差が工数のズレ、
※．現時点の進ちょくを基にして、プロジェクトの完了時期や発生工数の推定ができます。
進捗把握
■ スケジュール差異 ：SV ＝EV－PV
SV (Schedule Variance)
■ コスト差異 ：CV ＝EV－AC
CV (Cost Variance)
■ スケジュール効率指標：SPI＝EV÷PV
SPI (Schedule Performance Index)
SPIが1以下の場合は遅れ
■ コスト効率指標 ：CPI＝EV÷AC
CPI (Cost Performance Index)
CPIが1以下の場合はコスト超過
グラフで表しましょう。
コスト／時間
工数／時間
EVMの実際
以下は筆者が実際に経験したプロジェクトでPMOの立場でまとめたものです。
EVMの実態(実績) クリックで個別表示が可能 （この値は実際のプロジェクトでの数値です）
ここでは、計画段階のEVMではなく、実施過程でのEVMの推移から
計画の立て方を後から検証する意味でのEVMの実態を示します。
チーム03
チーム03.PV vs EV 進捗
PVとEVの関係で2/27から3/13の間に乖離がみられます。この時点でのWPはどうでしょうか？
2/27から3/13の間はそれほどではありませんでした。しかし6/5-6/12と6/28-7/3にWPの乖離が見受けられました。
計画が粗いケースでは、実績はそれなりの推移
計画：1週間で10
実績：1週間で05
※.但し、PV/EVの推移とのズレが存在する為、WP数の設定が適切ではなかったと言えます。
チーム08
チーム08.PV vs EV 進捗
（計画に無理がある（3/27～5/8の期間）ケース：結果として 計画 ＞実績
この場合のWPは
WPでも計画と実績に乖離があることが判る（当初計画に無理がある。3/27～4/24の期間 計画 ＞実績
チーム10
ワークパッケージは
※.前のPV/EVのグラフでは、それ程の乖離は見受けられない（5/8週、6/5週）
これは、計画段階のWPの設定数が適切ではなかったものと考えられます。
EVM特徴の一つ
活動の進捗状況だけでなく、コストの発生状況なども合わせて指標に換算して同一のグラフで管理できること。
上図の実際のグラフでもお分かりいただける様に、各チームのPV/EVの単位、PWのボリュームもチームごとの数値です（決して同じボリュームではありませんし、仕事の内容も異なります。しかし同一期間内に終わらせなければならない共に依存関係のあるものを共通の尺度で定量化で表すことにより進捗が一目でわかります。これがEVMの良さです。
EVMを活用する主な狙い
狙いは二つ（単純な場合）
一つは、ベンダーなどの 受注者が自らの作業の進捗状況を管理するため。
もう一つは発注者がベンダーなど 受注者に進捗状況を報告してもらうため。
これにより、プロジェクトの遅延やコスト超過を早期に発見することができるなどの効果が期待されます。