プロジェクトの多くは釣り鐘状の曲線に従う。すなわち、プロジェクトの序盤にかけるリソースは少なく、リソースを増やすにつれて開発実行中のコストと工数も増大、プロジェクトが終盤に向かうと工数は徐々にゼロに収束していく。
しかし、プロジェクトマネージャの負荷は同じような曲線にはならない。プロジェクトの全期間を通じてずっと高いままだ。序盤は計画の策定に追われるものの、こなしきれないほどの負荷ではない。プロジェクトが実行および監視のフェーズに移行すると、たいていのプロジェクトマネージャはスコープ（プロジェクトの対象範囲）、時間、コスト、品質の管理や、状況報告、経営陣、リソース競合等々への対応に忙殺される。幸運なプロジェクトマネージャは、終盤に入ってようやくほっと一息つけるかもしれない。
プロジェクトの計画立案を行う時期を実行フェーズから本来の計画フェーズに移すことによって、こうしたサイクルは予測可能になり、うまくすれば回避できるようになる。少しでも早くチームに仕事を始めさせたい気持ちはわかるし、着手が早ければ早いほど予定通りに完了できる可能性が高くなると思う気持ちもよくわかる。だが、そのやり方は間違っている。結果につながらない無駄な工数を増やすだけだ。
この間違いに私が最初に気付いたのはもう何年も前のことで、Anderson Consulting社とわずかなGatewayスタッフと共にGateway.comの構築に携わっていたときである。私はVisual Basicのコンサルタントとして、カリフォルニア州ラホーヤにあるGatewayの拠点にいたAndersonのプロジェクトマネージャから指示を受けていた。Anderson側は我々に仕事を始めるように激しく催促してきたが、最初の週の時点では、我々の多くはPCや電話はもちろん、デスクさえ用意されていない状況だった。当のGatewayに発注したPCがすぐに届かなかったのは皮肉なことだ。2週目、Anderson側の方針変更に伴い、我々は自社に返された。3週目に我々が呼び戻されると、どうやら彼らは開発現場の準備を進めていたらしく、チームリーダが決まり、PC、デスク、電話、電子メール、ソース管理、データベースといった環境がすっかり整っていた。社外スタッフの利用は高くつくので、プロジェクトチームの作業環境は自前で準備し、社外スタッフには専門的スキルの発揮に集中してもらおうというわけだ。
実際の作業に着手したら、いよいよプロジェクトマネージャの腕の見せ所である。計画されたタスク群に基づき、プロジェクト計画の更新、定例会議、進捗報告など、管理計画の実行を進めていくと、計画時には取り上げなかった問題や予想もできなかった問題にぶつかることだろう。幸いなことに、未知の問題の発生件数は実行の監視から終了の段階にかけて減少するので、その頃にはプロジェクトや請負業務の終結に向けた仕事に専念できるようになる。
以下のタスク群は、 『A Guide to the Project Management Body of Knowledge, Third Edition』 （PMBOK、邦題：プロジェクトマネジメント知識体系ガイド第3版）がプロジェクトの実行フェーズ以前に終えておく必要があるとしているものである。
- プロジェクト設立許可書の作成
- プロジェクトスコープの事前定義
- プロジェクト管理計画の作成
- プロジェクトスコープ管理計画
- スケジュール管理計画
- コスト管理計画
- 品質管理計画
- プロセス改善計画
- スタッフ配置管理計画
- コミュニケーション管理計画
- リスク管理計画
- 調達管理計画
- マイルストーン一覧
- リソーススケジュール
- スケジュールベースライン
- コストベースライン
- 品質ベースライン
- リスクレジスタ
項目の多さに圧倒されるが、手に負えないほどではない。『How standards and a database can improve your project management』（標準とデータベースによるプロジェクト管理の改善、翻訳記事）という記事には、テンプレートの利用によって、通常は何時間もかかる計画立案に数分で取りかかれる方法が紹介されている。この記事ではあらゆるものをデータベースで管理するように奨励しているが、この時点でデータベースを作成する時間がなければ文書テンプレートを使って始めることもできる。なお、USDA（米国農務省）は管理計画の基本的なサンプルを用意しており、Government Rural Outreachも同様の取り組みを行っている。
一部の管理計画書では、チームにいる専門家のアドバイスが必要になる。でなければ、そうしたドキュメントを書き終えることはできないだろう。いったん計画に手をつけたら自分にできることをやり遂げ、チームのメンバーとの各計画のレビュー時に認識のズレを解消する。きっとチームのメンバーは、こうした計画の多くに見識に満ちた情報を追加してくれるだろう。
これらのドキュメントをまったく作らずに済ませようという誘惑に負けてはならない。そんなことをすれば、プロジェクトの納品対象物に正式に含まれているかどうかに関係なく、そうしたドキュメントが答えてくれるはずの多くの質問に煩わされることになるだろう。すぐにでも計画書を作ったほうが楽になれるのだ。大規模なプロジェクトになるほど、その苦労は報われやすい。短期のプロジェクトではリソースが非常に少ないこともあってそれほど正式なものは求められないが、非常に小さなプロジェクトでも管理標準から得るところはある。それがわかったのは、サーバアプリケーションの1つをアップグレードするために時間制コンサルタントの手配をマネージャから依頼されたときだ。スコープが狭かったため、3時間かかるソフトウェアのアップグレードに対するコンサルタントからの提示額は1時間につき100ドルだった。このことを伝えると、マネージャはその費用を承認してくれた。ところがアップグレード実施の前になって、マネージャはスコープを2倍にするような追加機能の話を3度も私に持ちかけてきた。すでに300ドルで承認したので、コンサルタント料はそのままでこの追加機能を含めるようにと言い張るのだ。確かにコンサルタント料は時間単位で支払うことになっていたのだが、マネージャに（スコープと料金に関する）基本的なことを納得させるのには苦労した。彼はやっとのことで当初のスコープでアップグレードを行うことを認めてくれ、コンサルタント料を追加請求されずに済んだ。プロジェクトのスコープとスコープ管理計画について一言でも明記しておけば、スコープ管理にこれほど手間取ることはなかっただろう。現在、私は短期的プロジェクトには簡素な管理計画を、長期的プロジェクトにはすべての要素を含んだ計画テンプレートを利用している。
こういった計画を作成する際には、詳細な部分にまで目を向ける。たとえば、プロジェクトスコープ管理計画には、チームによるプロジェクトスコープの定義、スコープ定義の詳細化、WBS図（作業分解図）の作成、スコープの検証および管理を行う方法を記述する。この計画書では、誰が変更要求を文書化するのか、変更管理委員会のメンバーが誰でどれくらいの頻度で開かれるのかなど、実行フェーズが始まる前に答えられるすべての質問に具体的に回答しておく必要がある。
入念に管理計画をレビューしたら、計画の実行に意識を向けてスコープ、時間、コスト、品質、プロセス、チーム、進捗報告、その他のコミュニケーション、マイルストーン、プロジェクトに対するリスクといった管理に移る。プロジェクトマネージャは、これらの計画に各利害関係者を従わせるための専門的な役割である。プロジェクト管理計画に従うにあたってのガイダンスは、資金提供者から開発者に至るまでの全員に必要だが、最も手強いのはプロジェクトに資金を投資している人々である。
各利害関係者には変更管理のプロセスについて了解を得たうえで管理計画に従ってもらう。彼らを管理計画に従わせることができれば、高品質な成果物を予定通りに納品するという目標が現実味を帯びてくる。もしそれができなければ、プロジェクトマネージャとしての責任を否応なく追求されるだろう。
Zel Nadal氏はPMP（Project Management Professional）資格を持ち、オハイオ州ヒリアードにあるHilliard City SchoolsのITプロジェクトマネージャを務めている。1994年からAmerican Express、GTE、Microsoft、Gateway、Eckerdといった企業向けアプリケーションの開発に従事、1998年以降はGeico、BASF、オハイオ州衛生局（Ohio Department of Health）といった組織におけるITテクノロジのプロジェクト管理を経験。