プロジェクト計画管理についても

Thread Content

白雲帆自身が書いたものを、みんなで一緒に議論しましょう。 昨日、フレンドサークルでプロジェクト計画管理についての投稿を見ました。そこでは、設計、調達、施工、監理といったさまざまな側面からプロジェクト計画管理に与える影響について述べられ、いくつかの対策も提案されていました。 一見すると、なかなか理にかなっているように思える。しかしよく分析してみると、これらは実際には、計画が予定通りに進まない場合に計画担当者たちがよく使う言い訳に過ぎないのである。 多くの人々は、計画に対する理解を進捗、品質、コストという三角形の関係にとどめており、それこそがプロジェクトマネジメントの真髄だと考えて喜んで語っている。このような理解は、品質、進捗、コストを一方的かつ人為的に対立させるもので、プロジェクトマネジメントの表面的なレベルにとどまっている。 私個人の見解では、良い計画とは、進捗上の問題を解決するだけでなく、品質と進捗との間の矛盾も同時に調整できるものです。 では、一体計画とは何でしょうか？ 英語では、計画はPlanと言いますが、Planには計画という意味だけでなく、案という意味もあります。つまり、計画は単なる簡単な時期の一覧にとどまるべきではなく、計画は、そして必ずしも案と一体化している必要があるのです。実施案を考慮しない計画は、単なる机上の空論に過ぎないゴードン・バッハの仮説にすぎない。 計画とは、一体どのように策定すべきなのか？ 国内の多くの教科書では、計画の階層化が強調されており、通常は一次計画から二次計画へ、そして三次、四次といった、上から下へと分解していく形を取っています。言わせてもらえば、このような計画の立て方は、計画自体の原則や意義に反しており、必然的にゴードバッハの予想のような計画につながるのです。なぜですか？理由は簡単です。もし第一段階の計画自体が非現実的だったらどうでしょう？あるいは、あなたの第二計画の中のどこかの段階自体がナンセンスなのでは？ PMPでは、計画策定の一般的な手順が示されている。計画策定の基礎作業は、業務範囲の確認であり、これはコスト管理の範疇に属します。作業範囲はある種の関係に基づいて階層的に分けられ、その後ワークパッケージが形成される。なお、ワークパッケージ自体にはプロジェクト管理自体が含まれるべきである。なぜなら、各ワークパッケージにはコスト管理のためのアカウントが対応しており、それがコスト管理の基盤だからである。ワークパッケージ自体は、発注者と作業範囲およびプロジェクトコストを決定するための基盤となるべきである。 ワークパッケージを基に作業を細分化する段階で、これは実際には実施計画を詳細化するフェーズです。この段階では、各ワークパッケージに含まれる作業を詳細に分解する必要があります。同様に、プロジェクトの規模に応じて、最終的な分解対象となる作業の粒度を、5人日を超えないか、あるいは10人日を超えないように定め、実行計画に従って詳細化された作業を順序付けることができる。 ワークパッケージの分割や作業の詳細化を行う過程において、必然的にいくつか不確定な要素が存在します。これらの事項は、プロジェクトリスク登録簿に記載し、プロジェクト計画の策定および実行過程における重点的な監視対象とすべきであり、必要に応じて代替案の策定を行うべきである。 作業時間計画を作成した後でなければ、計画エンジニアは本格的に業務に取り組み始めず、各作業の作業種別を集計し、人材需要計画図を作成し、人的資源供給を最適化するために案について検討を行う。 排出される計画を分類して集計することで、初版の作業計画が得られます。この基盤の上で、プロジェクトの重要なタイミングを照らし合わせて検討・最適化を行い、必要に応じてプロジェクトのタイミング自体を調整する。最後に、プロジェクトの実際の状況に基づき、プロジェクトの案を最適化し、作業計画を調整して、バージョンアップされたまたは最終的な計画を策定する。 各案ごとの人件費や材料費などは、すでにワークパッケージおよびその詳細な作業リストに記載されているため、計画自体にコスト管理が含まれている。 計画自体でプロジェクト管理がワークパッケージとして詳細化されているため、プロジェクトの品質管理も計画に組み込まれ、関連するリソースが割り当てられている。リソースとコストについて議論する過程で、案は既に初期の検討と確定がなされ、リスクも特定されているため、この計画策定のプロセス自体がリスク管理のプロセスとなっているのです。プロジェクトのリスクを無理やり分析するのではなく。 計画策定プロセスにおける仮定条件のリスト、および計画策定自体の考え方が、プロジェクト計画の実現可能性を決定する。計画として承認されると、プロジェクトマネージャーの焦点は、各段階におけるリスク管理へと移る。プロジェクトの実施段階において、一方ではプロジェクト計画の策定における前提条件、つまりリスクを重点的に管理すべきであり、もう一方では未完了のタスクを分析し、残りの計画を適切に調整する必要がある。 はい、計画は調整可能であるべきであり、また調整しなければなりません。調整できない計画は、馬鹿げているか見栄を張っているだけだ。なぜなら、計画とは各自が毎日の仕事を整理するためのガイドだからです。しかし、あなたの計画が既に事実と長期にわたって深刻な乖離を生じているのであれば、どうやってそれが引き続きプロジェクトの実施を指導できるのでしょうか？私の個人的な見解では、これは非常に深刻でない問題です。真剣でない計画とは、尊厳のない計画であり、尊厳のない計画は必然的に失敗したプロジェクトにつながる。 海外では、「Lessons learned」というプロセスがあり、これは実際には品質管理のPDCAの普及と応用です。これは、計画管理においても同様に適用されます。バイアスの状況を分析することで、プロジェクトの今後の実施過程において注意すべき多くの点をまとめ上げることができ、それによってプロジェクトのリスクを最小限に抑えることができる。 外国人、特にアメリカ人から見ると、プロジェクトとは単に計画を立て、その計画に従って一歩ずつ実行していくだけのものだ。Planを策定するのはプロジェクトの上級職の人々であり、これらのPlanを実行する人々には、それほど高い知能は必要ないようだ。 急に何か書きたくなって、つい長々と書いてしまった。