PMO（ProjectManegementOffice)とは、PM主導による開発ではPMの手腕により、プロジェクトの成否が左右されてしまい。なんとか食い止める為に、第三機関として管理する事を目的としています。
という事はPMの仕事を知っている必要があります。
- 顧客や上司、営業、協力会社の力のある人とネゴる。
- ごねる。
- 無視をする。
- 放置する。
- 一人でやる。
というような事は含まれていません。
顧客の要望を全て受け入れていたら、お金がいくらあっても足りません。
コストに合わせてできる事しか書かなかったら、仕事をもらえないか、喧嘩するしかありません。
問題、不具合、障害の定義とはなんでしょう。５年に一度しか使わない機能に重大なバグがあった時にどうするのか。
プロジェクトは可能性のある不具合とその影響度合いから、優先順位、検証の緻密さを決めなければいけません。
開発フェーズで保守フェーズのような事をしなくてはならない場合もある。開発は標準化、共通化、構造化を考え、コストリスクを軽減するものですが、１ヵ所の修正が多岐にわたったり、特別な対応は極力さけるものですが、保守では、変更内容が単純、影響範囲を極力小さくする。
１行の修正で済むが１００本のプログラムから呼ばれている場合、１行を修正するのが開発で１００本直すのが保守です。こんな、わかりやすい例は実際にはありませんが、どこかのタイミングで切り替えなければならない。
工程、スケジュール、要件のずれ、品質という数値から判断する事も大事ですが、PMの指針になってほしいと思ってしまいます。
１億の仕事を６０００万でやれと言われた時、どうしますか？
やらないという選択肢はありますが、もしやるのであれば、必要な５項目だよなあと思うのです。
そんなPMO指針がそろそろ出てきても、いいんじゃないかなあ。