報告書の前書きにもあるとおり、ＩＴのプロでない経営者が、IT 投資をいかに捉えるかということを想定している。報告書の構成は、経営におけるIT 投資マネジメントのポイントと、個別プロジェクトのIT投資価値のポイントを、それぞれ解説している。
以前公表されたJIPDECの『IT投資マネジメント評価指針に関する調査研究報告書』は経営の観点も多く含まれていたため、経営とITの整合性が取れる反面、簡単には使えない印象があった。それに対し、経済産業省の『ＩＴ投資価値評価ガイドライン』はITの視点が多く、この資料の参考に出来るところだけ利用することも可能であり、活用しやすそうな印象を受けた。時間のない経営者はチェックリストだけ参考にしても有効そうである。

ただし、誰でも理解できるほど容易ではない。簡単に書いていながら、非常に含みの大きい項目もあり、読み手の見識によって達成度合いの評価は大きく異なりそうである。

　最近、関与したプロジェクトでは、この多重請負を意識するあまり発注元に管理負荷が集中し、結果としてプロジェクトが破綻した例がある。複数の請負元が多重請負の禁止でマイナス面が改善される一方、プラスの面も消えていくことを忘れてはならない。

　しかし、そうは言ってもこの流れは変わらないだろう。であれば、発注元・発注先共に、それに合わせた人材育成や品質保証の仕組みづくりを考えなければならない。「内製化をすすめることで、対応する」などというきれいごとが通じるケースは良いが、「内製化を進めるにも人材不足、開発能力もプロマネとしてのスキルも流出してしまっている」という発注元は多いのではないだろうか。

スケジュール管理を例にとって見る。
スケジュール管理はプロジェクト内の作業状況を管理するものである。作業漏れを防止（Ｑ）するためにＷＢＳを作ったり、作業進捗を管理（Ｄ）するためにガントチャートを作ったりもする。また、コスト（Ｃ）が適正かどうかを図るために、作業進捗度合いと投入人員数を計算したりもする。
このような管理を行うためにさまざまな管理表を作成するが、スケジュールに十分な余裕があるのに何時間もかけてガントチャートを作らせたり、コスト的に問題とならない程度の作業でも細かな進捗管理を行ったりすることは、目的を逸脱していると言わざるを得ない。

あくまでもＶａｌｕｅの実現を阻害する要因があるから、それを回避しようとＱＣＤの管理をするのである。極論になるが、まったくリスクがなければ管理は不要である。

システムを構築するプロジェクト要員に「会社全体での収益向上が目的である」といっても具体的に何をすればよいかはわからない。そこで、実作業レベルに噛み砕いた目標としてＱＣＤが使われることが多い。

プロジェクトマネージャーの役目は、「プロジェクトを無事に遂行させること」であるが、そのプロジェクトを遂行することは経営に直結するＶａｌｕｅを実現するということを忘れてはならない。
ここで、より全社レベルでの視点を持ってプロジェクト運営しているのがＰＭＯ、現場のプロジェクト運営寄りの視点でプロジェクト運営しているのがプロジェクトマネージャというわけである。

なお、Ｖａｌｕｅ＝金銭的価値であるとは限らないが、今後は話を判りやすくするためにＶａｌｕｅ＝利益として話を進めたい。

しかし、現実を見ると「PMOという名の兼任プロマネ」だったり、「技術力はないが口うるさく役員の受け皿」となっていることもある。
これはPMO自身の問題ではなく、PMOというものを誤解して導入した経営層の責任であることが多い。

なぜ、プロジェクトマネージャではなく、PMOなのか。その意味を理解しないと、逆にプロジェクトは失敗しやすくなる。