カスタム検索
|
|
カスタム検索
|
|
プロジェクト全般 商談フェーズ 要件定義フェーズ 開発準備フェーズ 設計フェーズ 開発フェーズ 試験フェーズ 運用準備フェーズ 運用フェーズ メンテナンスフェーズ |
2007/12/10 No.037 ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ★ 実践プロマネのメールマガジン ★ （プロマネ経験からの実践的なアドバイス） ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ━━目次━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ［プロマネと組織の係わり］ ★☆ プロマネの立場 ☆★ ★☆ 責任と一定の権限 ☆★ ★☆ 組織的な支援 ☆★ ★☆ プロマネと組織 ☆★ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ プロジェクトはプロマネの全責任で推進されるべきものでしょうか。組織あ るいはプロジェクト責任者（組織の責任者、役員など）はプロマネを選任し、 メンバを与えることでひと安心することもあるでしょう。モチベーションが高 いプロマネは自身の役割を認識し、実現性の高いプロジェクト実行計画を立て ることができますが、プロジェクトは実行段階で計画どおりに進むとは限りま せん。プロマネには責任と一定の権限を与え、組織がいつでも支援できる状況 を作っておくことで、プロジェクトの成功の確率は高まります。 ★☆ プロマネの立場 ☆★ 《プロジェクトの立ち上げ》 プロジェクトの成否の５割はプロマネの力量で決まる。プロマネはプロジェ クト開始にあたりプロジェクト実行計画を立てる。開発対象の業務内容、シス テムの特性、開発規模、顧客特性等を把握し、作業項目（ＷＢＳ）を洗い出す。 詳細スケジュール、メンバの役割、プロジェクトの推進方法を決めてプロジェ クトに着手する。 《作業負荷と精神的圧力》 システム仕様の確認、全てのコミュニケーション（お客様、プロジェクト内、 協力会社、社内関係者）、作業進捗、課題・問題点の管理と対応など、全てプ ロマネ中心に進められる。１００人月を越える大規模なプロジェクトではプロ マネに掛かる負荷は相当に大きい。一般的な傾向として、プロマネは許される 限りプロジェクト管理作業に時間を費やす。時間を十分に掛けることだけで必 ずしもマネジメントが最適化されるわけではないが、あえて暇な時間は作ろう としない。精神的にも相当の重圧がかかる。 ★☆ 責任と一定の権限 ☆★ 《プロマネの責任》 プロマネの責任とはなんだろうか。担当したプロジェクトを高いソフトウェ ア品質を確保し、相当の利益を出し、納期どおり納めることは言うまでもない。 プロジェクト推進過程での活動にも期待されている。メンバのモチベーション を維持しつつ、業務ノウハウ、ＩＴ技術を学ばせ、マネジメント技術を指導す るなど人材育成も図らなければならない。お客様との良好な関係も築いていか なければならない。プロジェクト成否の結果だけでなく、そのプロセスも問わ れる。 《権限を与える》 責任ある活動をするには、一定の権限が必要である。お客様との交渉、人員 の調整（増員）、スケジュールの調整、一定範囲のコスト増、十分な開発資源 の確保などの権限がなければプロジェクトを正常にコントロールすることはで きない。プロマネには一定の権限を与えて、自らの判断で自由に行動できる幅 を持たせる。責任だけ与え、権限を与えなければプロマネは十分な活動できな い。大きな変化（例えば、メンバの突然の離脱、顧客担当の交代など）が起き たときに、プロマネの判断で即刻何らかの対応ができるように権限を与える。 上司（責任者）への報告は事後でもいい。 《時間ロスの排除》 例えば、５０百万円規模のプロジェクト推進中、設計フェーズ後半でお客様 の要件変更が多発したとしよう。プロマネはお客様担当者と相談してプロジェ クトの中断を決断する。納期を含めたスケジュールに影響するかもしれない。 それでも継続するよりリスクは小さい。もしプロマネに権限がなければ、上司 に相談したり、社内のプロジェクト点検でアラームをあげ、対応を乞うことに なる。上司、組織の責任者は詳細な状況判断から始め、これで１〜２週間のロ スが発生する。一定の権限は必須である。 ★☆ 組織的な支援 ☆★ 《ありがちな組織対応》 プロジェクト点検と称して、第三者機関、ＰＭＯやプロマネの上司、組織の 責任者が推進上の問題点だけを抽出することがある。問題ありそうな点を根掘 り葉掘りと尋ね、挙句の果ては指摘するだけで終わってしまう。答えに窮する 質問ができて満足するなど本末転倒である。プロマネは自身で問題点に気づき、 対策を講じている場合もある。これを指摘しても仕方がない。暖かく見守りた い。言いっぱなしと当たり前な指摘は点検ではない。 《語りやすい雰囲気づくり》 プロジェクト点検（分析と表現したい）は、＜状況を聴きだす＞のではなく、 プロマネに＜状況を語ってもらう＞場にしなければならない。コーチングの手 法でプロマネ自身に状況を整理させ、課題・問題を気づかせ、対策も自身で考 えさせてもいい。問題は整理されていて、対策に窮している場合にはプロマネ 自身の解決案を語ってもらう。費用が掛かりすぎる、時間が足りないなど現実 的でない解決案が出されることもある。これをうまくフォローできれば、最適 な解が得られるかもしれない。上司が修正案か代替案を出し、その会議の場で 必ず結論を出す。問題の持ち越しは禁物である。なんらかの形で上司の支援が 得られれば、プロマネは次回以降のプロジェクト点検でも積極的にプロジェク ト状況を語ろうとする。プロジェクト点検は問題のあぶり出しではなく、解決 の場である。これを参加メンバ全員が認識できればいい。 ★☆ プロマネと組織 ☆★ 《プロジェクトの成功》 組織がプロジェクトの問題を認識した時点で、既に手遅れになっていること も多い。これは正常なプロジェクト点検が行われていない証である。組織はプ ロマネを任命した責任があり、それを十分に支援する義務がある。プロマネは 組織の一員として自らの責任を果たし、大きな問題に直面したときは組織を動 かして対策を講じなければならない。プロマネと組織がうまく機能してプロジ ェクトは成功する。 ご意見ご質問のメールはこちらからお願いします。 ＩＴシステム開発の実践プロマネホームに戻る |
|
|
Copyright (c) 2007-2010 "ＩＴシステム開発の実践プロマネ" All Rights Reserved. |
||