初期の計画は大胆に、本番開始時の計画は詳細に

友人に登録を薦められたネットでの転職紹介サイトへの
職業経歴登録がやっと終わった。
37年間も働き、7社も会社を変わったので
書く量も多い。


一番乗っているときのモットーは
”スピードとダイナミズム”だった。


経歴を書いていくと、
実際には慎重に詳細に計画を練って
実行していったプロジェクトもあることに気が付いた。


詳細に計画を作ったのは、
システムのアップグレードなどの移行系の仕事が殆ど。
40数台のWindowsサーバの移行とか
45店舗のPOSアプリケーションのアップグレードなどだ。


この手の仕事は、終了後そのまま本番になるので注意が必要だ。
何か失敗、問題が発生して、代替案がないと、
本番に支障をきたすか、フォールバックさせるしかない。


だから発生する可能性のある項目を一つひとつ検討しておく。
殆ど起きそうもないことも対策を考えておく。
そうすると、殆ど発生しない。
発生の可能性を考えていないことが起きることは時々あるが、
詳細に移行計画をたてると、ほぼ上手くいく。


普通の私の仕事は、
提案とかプロジェクト計画とか立上とかが多い。
こういうケースでは、殆ど計画は大雑把。
皆がこれでいいのと思うほど大雑把。


長期プロジェクトの初期段階では、
始めの時期の計画だけ詳細化し、
後の時期のは大雑把に計画をたてる。


後半の時期にかんして
詳細なスケジュールを作ることは無意味。


なぜなら、長期に渡るプロジェクトの場合は、
状況が変化していくから。
余り詳細にスケジュールを立てると、
これに縛られて、状況の変化に対応できなくなる場合が出てくる。


客や、固い上司などに長期に渡る詳細スケジュールを提出すると
これに固執して、変化を受け入れない状況になることがある。


お客は上司などに、自分の上司はその上司に
説明している可能性もあり、
彼らが説明し直す必要があり、
中々変化を受け入れたがらない。


初期段階で全ての成果物を書き出せと言われたことがあった。
全く初めてのAPSを利用しての対処で、
どう対処するか判らないプロジェクトだったが
適当にお客に提出。


プロジェクト終了間際に、
初期に作成した成果物一覧と同じ成果物の作成を迫られたことがある。


不要だったが、適当な文章を作成して提出した。
早めに成果物を変更しておくべきであった。


最近のシステム開発などを見ていると、
スケジュールというと、
直ぐにWBSと言って、
Excelでタスクをリストアップしてくる場合が多い。


各時期で同じよな数のタスクが並んでいる。
直近も可也先の時期的も同じように並んでいる。


時期が経過しても、
元のWBSに固執して、
新たな作業とか変更をしようとしない。


システム開発ではお客の要求は変化していくことが殆どで、
作業項目、調査項目なども変化するはずなのに？


特にコンサル的な仕事の場合は、
調査が進んでいくと新たな問題が発生したいり、
顧客の要望がずれてきたりするので、
余り長期の予定/作業を詳細化できない。
できないというより、すべきではないと思っている。


その時期になったときに詳細化することが肝心。


状況変化に応じてダイナミックに変化していくべき。


スケジュールだけでなく、成果物などは
客が期待したものには対応が必要だ。