ポイント2 どんなタイミングで褒めればよいのか？
褒める基準が明確になったら、次にどんなタイミング（When）でメンバーを褒めるべきかを考えてみよう。
褒めるタイミングは、メンバーの置かれている状況に応じて臨機応変に変えるしかない。以下では、大きく二つのケースを想定してみよう。
最初のケースは、システム導入プロジェクトだ（図4）。この場合は、フェーズによって褒めるタイミングを調整しなければならない。
先に挙げた褒める目的に照らすと、組織貢献が明確になったタイミング、自己成長と次ステップへの挑戦のタイミングがベストである。つまり、こうしたタスクが完了したタイミングで褒めるのが、最も効果的である。
例えば、システム導入に関する構想策定やシステム設計を行うフェーズの場合、組織貢献の評価が明確に分かるのは「計画書」や「設計書」といった成果物が完成するタイミング（マイルストーン）だ。リーダーは、この絶好のタイミングを逃すべきではない。
特にこのタイミングはフェーズの切れ目であり、タスク内容が大きく変わる。その意味では自己成長や次ステップへの挑戦という捉え方がしやすい。逆に各フェーズ内でもう少し短いスパンで褒めようとすると、どうしても組織貢献や自己成長を感じづらくなる。また、途中段階で褒めると褒める効果が小さくなる点にも注意が必要だ。
後続の開発・テスト・移行・教育といったフェーズにおいては、設計フェーズまでとは褒めるタイミングが変わってくる。これらのフェーズでは、ミスなく確実にスケジュールを守っていることが求められるからだ。大きなタスクとして捉えるのではなく、個々のシナリオやプログラム単位でのタスクができたタイミングを押さえたい。
開発以降は、フェーズの切れ目が分かりにくいのが特徴だ。実質的に、本番稼働まで切れ目が明確になっていない状況は少なくない。これでは褒めるタイミングがなくなってしまう。また、時間とともに新たな挑戦が待っているわけでもない。着実な作業の遂行が求められるので、モチベーションの維持が難しいという特徴もある。
したがって、開発・テスト・移行・教育フェーズでは、ある程度詳細なタスク単位、もしくはプログラム単位で完了するたびに褒めるのが望ましい。ここでは開発やテストを担当するメンバーのモチベーションダウンが起きやすい。それは、不具合の見落としなどを招き、大幅なスケジュール遅延を引き起こす要因となる。そのようなことが起きないように、組織貢献という目に見える形で結果が出たタスクの完了ごとに褒める。これにより、モチベーションの維持につなげていく。
