Monitoring an Active Project Plan

By Russ Finney

積極的なプロジェクト計画の監視

One of the biggest temptations for a project manager, especially if he or she is creating his or her own workplan, is to put a few extra hours in the plan (a little here, and a little there), just in case. The logic for this is: "if I underestimate the true duration or the required resources, I have built myself a cushion of time to fall back on. Since I am accountable for the budget, my behind is covered and I can sleep nights!" It is very rare to find a project manager who does not practice this "buffering" on a regular basis. Why? Because they are usually guessing in the first place! But is it really possible to work for an organization where plans don't have to be buffered? Absolutely! But in order for this to occur, the following conditions must exist:
プロジェクトマネジャーへの最大の誘惑の一つが、計画の (そこここに) 中に、念の為、何時間か余分に割り当てておく事だ。自分自身の作業計画を作る時は、特にそうだ。理屈はこうである：「実際の期間や必要資源を過少に見積もった時に備えて、時間的なクッションを作っておいたのだ。予算に対して説明責任があるが、これで、遅れは表面に出ず、枕を高くして寝られる！」この様な"バッファリング"を普段からやっていないプロジェクトマネージャは、極稀である。何故だろう？彼らは、そもそも勘に頼っているからだ！では、バッファを含まない計画を持つ組織が、上手くやる事は実際に可能だろうか？勿論！だが、その為には、次の様な条件が存在する。：

• Estimates must be based on development metrics which have been collected for past projects.
• A consistent development methodology should be employed so that factual comparisons can be made.
• The culture of the organization must change to recognize the true time consumption required for each development task.


• 見積りは、過去のプロジェクトから得られた指標に基づいた物でなければならない。
• 実績比較が出来る様、一貫した開発方法論を採用する
• それぞれの開発作業に掛かった実際の時間を報告する様に、組織の習慣を変える

Changes to these time factors should only be as a result of true improvements in development techniques, the technology supporting these techniques, or the experience of the team itself.
これら時間要素の変更は、開発手法、それらを支える技術、またはチームの経験などで、実質的な改善がみられた時にのみ行なわれる。

The organization should reward the project managers for tightening up the estimation process rather than punishing them for being bad guessers.
組織は、見積りの違いを叱責するのではなく、見積り作業を厳格なものにしたプロジェクトマネジャを賞賛すべきである。

Time Creates Enlightenment
時間管理は啓蒙につながる

A critical activity for all project managers is monitoring project progress. This is generally accomplished by capturing each team member's actual time utilization by task. The key point to consider in making the monitoring useful and accurate, is: the plan must be viewed as a living, changing document which reflects the current situation and the anticipated direction of the project at a moment in time.
全プロジェクトマネジャにとって、最も重要な活動は、プロジェクトの進捗監視である。一般的には、メンバー全員の作業項目毎の消費時間を把握するれば良い。この監視を正確で有益なものにする鍵は、：計画は文書だが、生きていて、その時々の状況と予想される方向を反映して変わり続けるものと、見なければならない事だ。

In order to make this a reality, several attitudes must be adopted by both the team and the executive client sponsors:
これを現実の物にするには、プロジェクトチームと(顧客側役員の)発起人双方が次の様な方針を採る必要がある。

• The project deadlines and staffing levels are the basis for team progress as long as the scope requirements and and project assumptions remain as defined.
• Actual time utilization should be reported for each task based on the way it actually occurred, not based on the way tasks were estimated.
• If new tasks are required to be performed which were not a part of the original workplan, they should be added to the updated workplan and subsequent time should be tracked for them also.


• 要件の範囲とプロジェクトの前提が、既に記述されたものから変わらない限り、プロジェクトの納期と人員配置が、チームの進捗のベースとなる。
• 実消費時間は、現実に発生した作業項目毎に有りのままを報告する。見積り時点の数字に合わせた報告はしない。
• 元の計画に無い、新しい作業が必要となった場合、計画の改定版に追加し、それに伴う時間はその作業区分で記録されなければならない。

Reporting Status
現状報告

At some point in the project, usually on a regular basis, someone is going to want to know how things are going. Unfortunately, this is just reality of system building. In most cases over the years, this has been accomplished through the use of the ever present, universally acknowledged, status report. Depending on the size of the project, this report may actually be presented at a status meeting. Over the years, the eternal quest of the project manager has been to find the answers to the following status related questions:
プロジェクトのある時点で、通常は定期的に、物事が如何に進行しているか知りたいと思う人間がいる。残念だが、以下がシステム構築の実際である。永年にわたって多くの場合、古くからずっとあって、広く知られた現状報告書が使われてきた。プロジェクトの規模にもよるが、この報告書は、実際、現状報告会に提出されている。長い歳月の間に、プロジェクトマネジャの果てしない探求は、次の様な状況報告にまつわる疑問に対する回答を見つけ出した。

• Who is really interested in the status of the project?
• How do you keep the status meeting from turning into a yawning contest?
• What information should actually be presented within the report itself?


• 誰が、現状報告書に本当に興味を持っているか？
• 現状報告会が、“あくびの出る退屈な会議”にならない様にするには、どうするか？
• 報告書には、実際どんな内容が必要か？

One thing is certain, if a status meeting approach will be utilized, keep the meeting short, and always end the meeting at the appointed hour. It seems that there is nothing that project managers enjoy more than sitting around for hours on end, discussing the status of their current project, while at the same time to designing the system's perceived inner workings on the back of an envelope. This is not the purpose of status reporting. The report itself should contain several key items, and the meeting should briefly cover these items and clarify any unusual circumstances or issues.
確実に言えるのは、現状報告会を開くなら、短く、常に決まった時間に終わる事だ。プロジェクトマネジャにとっては、何時間も端っこに座り、プロジェクトの現状について話をしながら、同時に、封筒の裏でシステム内部の詳細な機能設計をしている以外の何物でもない。これが、現状報告会の目的ではないはずだ。報告書自体が幾つかの要点を含んでいるので、会議は短くこれらの点に触れ、異常な事態や懸案事項を明確にするのに留めるべきだ。

Copyright © 1999, Russ Finney, All Rights Reserved