先週末の土日は良い天気に恵まれたここ北摂地方ですが、今週はずーっと曇りか雨の予報です。まぁ梅雨らしいといったらそうなんですが、雨を楽しみながら今週のスタートといきましょう。
プロジェクト体制の狭間で -1-
プロジェクト体制について考えています。どんなＰＭにとってもプロジェクトの実行体制については頭を悩ませる問題です。まずＰＭにはプロジェクトの体制構築に関与できる場合とそうでない場合、つまり体制が固まって後にＰＭとなる場合があります。
前者の場合はそもそもプロジェクト実施主体の組織に所属しているＰＭの場合がほとんどで、後者はそれに加えて外部からＰＭやＰＭＯとして参画する場合もあります。プロジェクト体制は様々な要素を検討して作成する必要がありますが、前回も少し触れたようにその”要素”の中に
現在のビジネス状況などプロジェクトに関わる以外の、組織の歴史や文化やスキルなどの様々な要素が考慮されることになります。つまりプロジェクトにとって最適化以外の選択の圧力が働くという可能性があります。
このことは、プロジェクトの成功見込にとっては結構大きなインパクトがあるのですが、プロジェクトスタート時点では見直されることはまずありません。特にポリティカルな要因でプロジェクトにプレッシャーが掛かっているいる場合は特にそうです。これが見直されることがあるとすれば、プロジェクトが危機的な状況になりその原因が体制にあることが明白な場合となるでしょうか。
身もふたもない言い方をすれば、ＰＭには体制についてなんらかの決定をする余地はあまりないということになります。もちろん多少の意見を述べるチャンスはあるかも知れません。そのためにも我々は、プロジェクト憲章やプロジェクト計画書の中でプロジェクト遂行に必要な組織的なスキルセット（ケイパビリティ）が存在しているか検証することが重要となります。
ＩＴの業務アプリケーション開発の場合だと、業務要求を理解し引き出せる能力はもちろんのことですが、ネットワークインフラ、ハードウェア、セキュリティ、ミドルウェアなどの足回りを構築できる能力から、プログラム開発、テストの能力、はたまた利用マニュアルを作成するライターとしての能力などプロジェクトのライフサイクルに合わせた、スキルセットとその変遷のありようについて、設計することが必要になります。
このようにして設計した上でどうしても足りないスキルを発見した場合は、それをどのように調達するかを計画し、実施します。このようにプロジェクト実行に必要なケイパビリティと、その実態としての個人名を紐づける資料を作成することで、万一欠けるものがあれば、早期に人事権や予算執行権を持つ管理者に提示し、納得してもらうことになります。
さて、スキルセットの調達には通常２つの方法があります。一つはプロジェクトの外部から調達する方法で、もう一つはプロジェクト内部で教育を行う方法です。後者の場合は、教育のタイミングも合わせて計画する必要があるのは言うまでもありません。いずれにしても必要なタイミングで必要とする能力を投入できることが、プロジェクトの実行には欠かせないということです。
次回はしばしば見かける「歪な体制とそれへの対処方法」について考えることにします。