プロジェクトの立上げ期は忙しい。それが納期のある受注型プロジェクトとなれば、なおさらである。まず、プロジェクト・チームのコアとなる要員をアサインしなければならない。社内でプロジェクトの概要について説明する簡単な文書も必要である(それが「プロジェクト憲章」とか「Charter」と呼ばれていなくても、たとえA4サイズ1枚の紙切れでも、とにかくプロジェクトを正式化するための文書がいる)。それから会社のプロジェクト登録簿に登録して、正式なプロジェクト・コードを発番してもらわなければならない(そうしないとタイム・シートもつけられないし交通費も精算できない)。
さらに、受注型プロジェクトの場合は、見積提案書を出した後、客先とのネゴの過程でさまざまな追加要求やら変更やらが入るケースが多い。とくに不況で買い手の側の強い昨今はなおさらである。なんとか注文書をもらえた営業はにこにこ顔で帰ってくるが、プロマネとしては、相手と合意した詳細内容を盛り込んだSOWなり確定仕様書なりを作成して、契約書に添付して提出しないと危なくてしようがない。おまけに客先は下打ち合わせで顔を合わせるたびにまた違うことを言い出してくる。正式キックオフ・ミーティングを開催するまでは、しばらく放って置いてほしいものだが。 そしてもちろん、実行予算の設定と、プロジェクト・マスタ・スケジュールの立案である。概略予算や工程は見積時に検討したが、実ジョブとなるともっと確度の高い計画が求められる。そのためには、スコープにしたがってWBSを展開して、ワーク・パッケージを決めなければならない。おまけにこのごろは、リスク・レビューを実施しろとPMO(Project Management Office)がうるさく言ってくる。だがその前に、社内キックオフを準備する必要がある。客先との連絡窓口や調整手順を定めた業務遂行要領書も作らなくては・・ こんな調子で、最初の2週間かそこらは目が回りそうなスピードで時間がすぎていく。とはいえ、とにかくチーム員を動員したら、その人たちにまずは仕事の指示をしていかなければならない。でも、何から先に、いつまでにやらなければならないのだ? --それはもちろん、マスタ・スケジュールに規定されているはずである。だが、その肝心のマスタ・スケジュールがまだ出来ていないのだ! いったいどうすればいいのか!? そのための答えが、「フロントエンド・スケジュール」なのである。Front End Scheduleとは、文字通り、プロジェクトの最初の数週間のみをカバーしたスケジュールである。これをまず、最初に作る。そして、初動期間は、これにしたがって人を動かしていく。その合間に、本式のプロジェクト・マスタ・スケジュールを作成して、正式に配布するのである。 でも、なぜそんな二度手間をするのか? だったら、最初から全体スケジュールを作れば良いではないか--そう考える人もいるだろう(たとえばあなたの上司とか)。でも、そうは簡単にはいかないのである。プロジェクトの全体工程をカバーしたスケジュールを立案するには、上に述べたように、きちんとWBSを展開して、ワークパッケージを定義し、それぞれに必要な期間とコストとリソースを見積もらなければならない。しかし、まだ設計も要件も揺れ動いている段階で、これを作るのは容易ではない。それどころか、いったん作っても、すぐ変更になるのは目に見えている。なにしろプロジェクトというのは本質的に個別性が強いからだ。全く同じことを繰り返すプロジェクトというのは滅多にない(もしそれが頻繁にあれば、それはプロジェクトではなく日常業務だと言うことになる)。 ところが。じつは、同種のプロジェクトというのは、初動期だけを取り出すと、かなり似ているものなのである。やるべきことは、客先との要件固めと基本設計のすべり出し、そしてプロジェクト組織の立ち上げと計画立案作業等である。個別性でスケジュールに違いが強く出てくるのは、要件や設計がはっきりしてから以降のことなのだ。それは、力仕事的なアクティビティの数や量が変わってくるからである。いわば人間の頭と胴体の関係のようなもので、背の高さや体重は、人により2割も3割も違うが、頭だけ見るとそれほどの違いは無い。プロジェクトの初動期の姿も同じようなもので、プロジェクト全体のプロポーションとは比較的独立して決まるのである。 したがって、フロントエンド・スケジュールは、プロジェクトの種別にしたがっていくつかをあらかじめスケジュール・テンプレートとして用意しておき、実際に案件が開始したら、それを多少カスタマイズして使えばよい。これだったら、作成配布までにたいして日数はかからない。そして、人を動かすことも出来る。客先だって、当面は安心してくれるだろう。このように、マネジメントにおいては、案件の個別性に惑わされずに、できるかぎり普遍性・共通性を見つけ出す姿勢が肝要なのである。
by Tomoichi_Sato
| 2009-08-09 22:06
| B3 プロジェクト・スケジューリング
|
Comments(0)
|
検索
カテゴリ
全体 A 生産マネジメントとSCM A1 生産マネジメント全般 A2 生産計画と生産スケジューリング A3 在庫・調達計画 A4 コスト・品質・安全 A5 BOM(部品表) A6 サプライチェーン B プロジェクト・マネジメント(PM) B1 プロジェクト・マネジメント全般 B2 スコープ・WBS・プロジェクト組織 B3 プロジェクト・スケジューリング B4 プロジェクト・コストと見積 B5 プロジェクトの価値とリスク B6 プログラム・PMO・ガバナンス C システムとしての工場 C1 工場計画論 C2 スマート工場論 D 情報システムのマネジメント D1 製造業のITシステム D2 ITアーキテクチャ・データ活用技術 D3 ITって、何? E ビジネス・マネジメントと管理技術 E1 マネジメントの技術論 E2 設計のマネジメント E3 組織・経営・戦略論 E4 ビジネスのソフト・スキル E5 時間管理術 E6 メンタルと働き方のマネジメント F 考えるヒント F1 思考とモデリングの技法 F2 社会・言語・文化 G 書評 H English articles 未分類 最新の記事
記事ランキング
著書・姉妹サイト
ニュースレターに登録
私のプロフィル My Profile 【著書】 「世界を動かすプロジェクトマネジメントの教科書 「時間管理術 「BOM/部品表入門 (図解でわかる生産の実務) 「リスク確率に基づくプロジェクト・マネジメントの研究 【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
2026年 04月 2026年 03月 2026年 02月 2026年 01月 2025年 12月 2025年 11月 2025年 10月 2025年 09月 2025年 08月 2025年 07月 more... ブログパーツ
メール配信サービス by Benchmark 最新のコメント
ブログジャンル
画像一覧
|
ファン申請 |
||