大きさが重要

プロジェクトの大きさ、チームの大きさ、成果物の大きさ、チェックリストの大きさ。プロジェクトのあらゆるものが、その大きさに依存しています。大きさによって、ゲームをどうプレイするかのルールが変わってきます。

プロジェクトが（その大きさや複雑さにおいて）大きくなればなるほど、プロジェクト・マネジャーがプロジェクトを管理可能なモジュールに分割し、これらモジュールの納品責任を有能なメンバーと共有することが重要になってきます。これによって、プロジェクト・マネジャーを含むプロジェクトのキーメンバーは、些細なことにとらわれることなく、プロジェクトの健康状態を調べて、その「全体像」を把握できるようになります。

分散したプロジェクトは通常のプロジェクトと比べても大きくなりがちです。プロジェクト・マネジャーがその大きさを管理するためにどんな方針をとるかが、実際にプロジェクトの最終結果に大きな影響を及ぼします。「大きい」という言葉からは、さまざまなイメージが頭に浮かびます。8人で12か月かけてやる仕事（小さなベンダー）から、何百人もかけて年間メンテナンス契約を締結してやる仕事（クライアント向けの巨大なITパートナー）まで、あらゆるものを意味します。

プロジェクトを適切な大きさに分割した小さなパーツが、どのようにプロジェクト全体の成功を左右するのか、全員が確実に理解するための方法を以下に提案します。

• プロジェクトを、独立しながらも管理可能なワークストリームにできるだけたくさん分割すること。
• 各ワークストリームに納品責任を持つ重要な窓口を少なくとも一名配置すること。
• できれば、複数のワークストリームに役割を持つキーメンバーを配置すること。こうすることで「全体像」をチーム間でシェアすることができます。
• 各ワークストリームの進捗を（何らかのツールを使って）個別に追跡すること。そして、プロジェクト全体の鼓動が感じられるよう、定期的に評価指標と関連付けること。
• リスク、課題、前提、各ワークストリームの依存関係をそれぞれ文書化して共有すること。
• チームの定例ミーティングを開催して、すべてのワークストリームの状況を共有すること。
• プロジェクト全体のロードマップを公表すること。これには個々のワークストリームのリリース計画も含まれます。
• オンラインツールを積極的に利用して、ユーザー要求、マイルストーンの更新、バグレポート、レポートスケジュール、リスクを共有すること。

例えば、バージョンが3つ（北米、アジア太平洋、中東）あるWebサイトの構築を任されたとしましょう。あなたは3つの異なるワークストリームを作って、それぞれ独立した納品窓口を置くのがよいと判断できます。これら3つのサイトはみな、基本的には同じサイトの別バージョンなので（中程度のカスタマイズ）、何名かのキーメンバーを3つのワークストリームにまたがるよう配置しましょう。そうしておけば、彼らはサイト全体の整合性を確保しつつ、どのように実装詳細を再利用すればよいか提案できます。

また、ひとつのプロジェクトに複数のシステムインテグレータがかかわる場合もあるでしょう。各インテグレーションポイント（あるいは関連するものをいくつかまとめたもの）を個別のワークストリームに分割するのが理想的でしょう。こうしておけば、複数の作業を同時に進めることができ、納品期間を短縮できるかもしれません。全体の品質を調整するために、さまざまなチームを毎日のミーティングに参加させましょう。