オルタナティブ・ブログ > トラパパ@TORAPAPA >

IT、特にコンサルに携わる方々を癒すメッセージを、ついでに趣味のダーツ話も交えて・・

「開始遅延」なき「終了遅延」はそうそうあるもんじゃない。

»

或る時或るところで、「どうして遅れてしまったんだろう」という議論になったのですが、経験的に思いだすことがありました。

 

作業が遅延していることを認識した時点で、その遅延は軽微と思うことなかれ、です。

感覚的に、作業者は軽微だったら遅延の報告はしません。重大なので報告があったり、遅延がばれるのです。なので遅延認識時点で、状況はとてもクリティカルです。

そして、その時点での状況はともかく、大抵においてその作業はきっとそもそも序盤から「開始遅延」を起こしています。

 

自分の定義で正確に言うと、「作業着手に遅れた」ケースと、「作業着手後の序盤で必要だったスタートダッシュに失敗した」ケースの2種類があります。どちらも問題は問題です。

一度遅延し始めてしまったら、キャッチアップはそもそも難儀なわけです。予定の作業に加えてそれまでの遅れを挽回するわけだから。だから私は作業計画段階で「いかに確実に目標タイミングで開始するか」「いかに効果的にスタートダッシュしてバッファを作るか」がポイントだと思っています。

進捗度合いをリニアに考えるとこういう配慮がよく漏れます。進捗は著書にも書いたようなドラフト作成のコツのごとく、できるだけ前倒しに進捗させてあとあとの有事に備えてバッファを稼いでおくべきです。

 

期日管理について終了期限ばかり気にするケースは意外にもいまだに多く、開始期限や開始条件を熟考して作業計画を作る習慣付けがまだまだな気がしています。

冒頭の事例は「たられば」の議論でもあったので、そこをちまちま批判することにはあまり意義はないなと思っていましたが、そして今後初期作業計画ステージでの助言機会では、できるだけこのポイントに留意していきたいとあらためて思いました。

(おしまい)

Comment(2)