少々雑多ですが、思うところだけを書き記します。
必要な期間が取れないことを逆手に取る
2:8の法則にのっとっれば、最初の2割の期間で8割のことが出来上がる。でも、多くの場合、残りの2割もパーフェクトにこなそうとして、残り8割の時間をめいっぱに使う。だが得てして、パーフェクトにはならないだ。
パーフェクトを得るために、あとどんだけ時間を積み上げればよいのか…といった考えを逆手にとって、期間をボックス化してマネジメントする。これを「タイムブロック・マネジメント」という。
スケジュールを変更するかしないか、どうやって判断するか
- 量や数の問題は、パワーを増やせるなら伸ばす必要はない
- 質の問題は、スケジュールを伸ばしても解決しない
- 理解や共通認識の問題は、状況に応じた双方向からの対処が必要
- 原因が分らない障害は、究明方法、対処法、代替手段などがあるかどうかによる
≪とにかく≫差し迫っているときは、スケジュールを伸ばすより、スケジュール内に逃げ切る方法を考えた方がよい
スケジュールが変更になった…まずすべきことは?
- 期限が先に延びて余裕ができる…例外なので扱わない
- 期限が前倒しになって、ますます厳しくなる…前提が壊れたわけだから、それを都合よく変えられるなら、逆手に取る方法を考えよう
- 工程への時間配分が変わったのなら、変更は気にする必要はない
はじめたらいきなり遅れ始めた…そんなときの対処法
・あわててはいけない。遅れを早く報告したがため、やぶへびになる場合がある
・のんびり構えてはいけない。アトで取り替えそうと思っても、その「アトで」というタイミングは決して来ないのだから
・単に「遅れている」というアバウトな把握ではなく、What-How-Whyで状況を正確に捉えよう
- 何が悪かったのかを疑え
- そもそもスケジュールに無理をしていなかったか
- 勝手に前提をつけていなかったか
- 予定通りのリソースはあるのか?
- 遅れるまえに、遅れる前兆があったはず…それはなにか
ドキュメント作成の進捗管理
基本的に難しい。なぜなら、「何ページ書いた」では本当に充分なものかどうか分からない。レビューや添削の過程でひっくり返る可能性を考えると、ページ数を進捗率の根拠にするのは難しい。
そうした場合、ドキュメント全体のコンテンツ〔構造〕をWBSに分解し、記載されるべき単元・章などの単位にスケジュール化するとよい。
スケジュール作成ツール
専門ツールとしては、Microsoft Office Project が一般的です。PERTやガントチャート、プレジデンス・ダイヤグラムなどが表現でき、所要日数、リソース(メンバーのスキル、頭数、稼働可能時間 etc.)、前提工程などが定義できます。進捗も表現でき、スケジュールや工程管理に必要な機能は一通り網羅しています。
その他のツール：モデリングツール、PM専用ツール(Decision、teamwork、アルテミス
ところが、IT業界の技術者、誰もが使っているかといえばそうでもありません。なぜでしょう。
- 価格が高い
すくなくとも個人で買うには覚悟が要る価格です。会社、プロジェクトで標準利用しているのでなければ、メンバー間の共通ツールとしては使えません。 - リソースと単位作業の所要時間から期間の長さが機械的計算で決められてしまう
⇒いわゆる、リスク、あそびを入れにくい - なので、わずらわしいと感じて、自動計算をオフにして使ってしまう場合が多い
- すると、たんなるスケジュール表のお絵かきツールになってしまう
- スケジュール表を書くだけなら、Excelなどでも十分描けてしまう
こうした理由がそれぞれ相まって、Excelで済ませてしまおうという発想が先行します。実のところ、スケジュール表を書くだけなら、Excelが手軽で便利なのは間違いありません。けれども、スケジュール表が、管理の仕組みそのものでないことは明白です。
スケジュール表をただ描いたのであれば、どう管理するかは自分で考える必要があります。管理に必要な要素や視点を設定し、管理するロジックをくみ上げ、計算式やマクロを駆使して、仕掛けを組み込む必要があります。ところが多くの人がそれをしません…そもそも、作表と管理とが別物であることに気づいていません。
・・・こうして、スケジュール表の「お絵描き」はできても、「管理」はできないプロジェクトが多発するわけです。
コメント