どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
CCPMのおはなし2-8(原理編8):プロマネで発生しやすい問題:管理編
CCPMのおはなしシリーズです。
今回も原理編です。プロジェクトマネジメント知識体系を取り入れたプロジェクトで発生しやすい典型的な問題を紹介してみます。こちらがCCPMにて解決を行う対象となります。
プロマネで発生しやすい問題についての説明が続きますが、今回は管理編となります。

-----------------------------
<参考情報>
本内容は連載的に紹介しております。本記事の前提や全体的な構成についてはこちら(リンク)を参照ください。
現在記載の内容は原理編です。こちらの前提や構成に関してはこちら(リンク)を確認ください。
-----------------------------

前回までの2回で、タスク編として個々のタスクには「個別バッファ(安全余裕)」を含んでしまうのですが、最終的に「タスクの完了はギリギリか遅れる」という状況について紹介を行いました。
今回は、紹介したタスクの遅れに対して、マネージャが行うことが多い管理上の問題点を紹介します。

※注:本内容はプロジェクトマネジメントの知識体系をけなしている訳ではありません。CCPMが解決する対象となる典型的な問題点をまとめることを意図した内容ですのでご了承ください。


■タスクの遅れによる影響:タスクの従属性

おさらいですが、「個々のタスクの完了はギリギリか遅れる」という状況が発生します。
おさらい!
※クリックで拡大

個々のタスクが遅れることによって、プロジェクト全体にはどのような影響があるでしょうか?
プロジェクト全体としてはタスクの繋がりについては複雑になりますが、それぞれの部分を取り出すと「直列」もしくは「並列」に繋がっているはずです。

A) 直列のタスク繋がりに対して遅れが発生すると…?
直列つなぎ
※クリックで拡大

B) 並列のタスク繋がりに対して遅れが発生すると…?
並列つなぎ
※クリックで拡大

どちらにしろ、1つのタスクの遅れがプロジェクト全体の遅れに伝搬してしまう状況が分かります。これは、タスク間には繋がりがあり1つの遅れは全体に影響するという仕組みのためです。

これを「タスクの従属性」と呼びます。

タスクが並列に並んでいるとき、直列に並んでいるとき、双方とも遅れの影響はプロジェクト全体に影響してしまいます。
タスク完了の前提を「ギリギリ(間に合う)」もしくは「遅れる」が各50%で発生するのであれば、直列3つのタスク例では間に合う確率は(1/2)^3=1/8=12.5%となります。
じゅうぞくせい


■タスクの遅れによる影響:全てを早く始めると…?

それでは、「遅れる」前提であれば全て早く始めてしまおう!という解決策を思いつくと思います。実際にこれを行ってみるとどうなるでしょう?
最後に爆散
※クリックで拡大

担当者を変えずに行おうとすると、並列のタスクが増えてしまいます。
結果として、(バッド)マルチタスクによる担当者の分割度合いが進んでしまうことになってしまいます。悩ましいですね…


■問題の優先順位判断

ここで一旦話を切り替えて、問題の優先順位の判断に移ります。
現場では全員が何らかの問題を毎日抱えており、それを解決しながら活動を進めております。
みんなのもんだい
個人では解決できない/時間のかかる問題に対してはチームで解決するため、情報を集めて解決を行います。

チームで解決すべき問題はマネージャが判断してリソースを割り当てるとして、「目先の」「気になった」問題を解決している状況は正しいのでしょうか?
メンドイ朝会
※クリックで拡大

例えば3人が並列して作業している状況に対して、解決する対象の人を間違えている可能性も有ります。
実際は…?
※クリックで拡大

この例では、「青」の問題を解決しようとしていますが、残り作業日数が多いのは「赤」になります。全体の作業完了を早くしようとするのであれば、優先して問題を解決すべきは「赤」の問題になります。


■(解決策の一部)優先順位の判断方法:クリティカルパス

この記事では問題点だけまとめる想定でしたが、1点だけ解決策を記載してみます。
上記の問題の優先順位判断方法ですが、「プロジェクトがより早く完了する」ことを重要視すると優先判断が明確になります。

プロジェクトの期間を決めるのは最も長いタスクの列である「クリティカルパス」になります。単純に考えると、クリティカルパス以外の遅れを最優先で解決しても進捗への効果は薄いことになります。
クリティカルパス
※クリックで拡大

そのため、クリティカルパスに影響する問題が優先されるように上手く判断する必要があります。


■リソース制約の考慮:クリティカルチェーン

クリティカルパスの重要性を一旦紹介しましたが、プロジェクトマネジメント知識体系では(PERT図/アローダイヤグラムで)タスクの前後関係を明確にすることを強調しております。
この「タスク前後関係」を意識したクリティカルパス・期間は、実際にはリソースを割り当てると以下の図のようになる場合があります。
リソースによる制約
※クリックで拡大

タスク前後関係のみ検討した場合とリソースを考慮した場合で期間が変化します。
実際にはタスク前後関係だけは決めていますが、リソースを後で決めるような業務の進め方をする場合も有ります。この場合でも、リソースが確定した時点で期間を見直しする必要が発生します。

このリソース制約を考慮した最も長いタスク列について、(クリティカルパスと明確に違うものであるという認識に繋げるため)CCPMでは「クリティカルチェーン」と呼んでおります。

※注:プロジェクトマネジメント知識体系にリソース制約について書いてはいるのですが、あまり強調されていないので気付きづらいのです。

実際にリソース制約を考慮することで期間が変わる例を以下に示しておきます。
<例 Э佑リソース制約の場合>
皮算用はあたらない
※クリックで拡大

<例◆Я置がリソース制約の場合>
皮算用はあたらない
※クリックで拡大

このような、リソース制約を考慮したスケジュールを作り、リソース問題を回避することで停滞を防ぐ/停滞期間を明確にすることが出来るようになります。(「山崩し」と呼ぶことも有ります)


■管理編まとめ:キーワード整理

CCPMが解決するプロジェクトマネージメント上の問題、管理編は以上となります。
タスク編同様にキーワードをPickUpしておきましょう。

タスクの遅れ(ギリギリか遅れる傾向)による影響
・タスクの従属性による遅れの影響
・早く始めると(バッド)マルチタスクが増大

問題の優先順位判断方法
・目先の問題解決は全体に影響しないことも
・クリティカルパスの問題を優先

リソースの考慮
・クリティカルパスにリソース制約を考慮

管理側の問題点としては、全体の進捗に影響しない問題点を解決しようとしてしまうことが多いこと、リソースを考慮しないクリティカルパスにより遅れが発生してしまうこと、といった点が挙げられます。


さて、以上で(ようやく)CCPMが解決するプロジェクトマネジメントにおける問題点の紹介が終わります。
長々と説明したこれらの問題点をCCPMで解決を行うことになります。


次回は、問題の関連性整理とCCPMでの解決策の概要(ポイント)を紹介してみます。
| TOC/TOCfE/CCPM | 21:47 | comments(0) | - |









1234567
891011121314
15161718192021
22232425262728
293031    
<< July 2018 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ