プロジェクトの複雑さを予測する際は、プロジェクトには「ビジネス」と「技術」という2つの次元があると考えるといい。そして、この2つの次元はそれぞれ、独自の属性セットを備える（属性の総数はプロジェクトによって異なる）。各属性がもたらす複雑さがそれぞれ1から4までのスコアで評価され、2つの次元それぞれの集成値が決定する。その値を2次元のチャートに表示すれば、そのプロジェクトの「ビジネス面の複雑さ」と「技術面の複雑さ」が描かれることになる。

ビジネス面の複雑さ

　プロジェクトのビジネス面の複雑さは、例えば、競合他社の存在、部門間協力の必要性、現行のビジネスプロセス、顧客の関与、資金的損害の可能性、地理的要因、規制による制約など、さまざまな要素によって決まってくる。こうした属性の複雑さをそれぞれ4段階で評価する。例えば、ビジネスルールが明確に定義され、静的であるなら、複雑さは低レベルとなり（スコアは1）、ビジネスルールがまだ定義されていなかったり、動的であるなら、複雑さは高レベルとなる（スコアは4）。同様に、既に事情を熟知している既存市場に製品を投入するということならば、複雑さは低レベルとなる。逆に、新規市場に製品を投入するということならば、複雑さは高レベルとなる。

技術面の複雑さ

　プロジェクトの技術面の複雑さは、例えば、セキュリティのニーズ、ハードウェア／ソフトウェアの安定性、取引の規模、プロジェクトチームの経験、技術統合のレベルなど、ざまざまな要素によって決まってくる。例えば、既に使い慣れた技術を幾つか統合するだけならば、複雑さは低レベルだろうが（スコアは2）、多様なベンダーの異種技術を多数統合するとなれば、複雑さも高レベルとなるだろう（スコアは4）。

　複雑さの査定プロセスは動的であり、プロジェクトの複雑さは何か大きな変更がある度に（例えば、プロジェクトの規模、リソース、技術、企業戦略などが大幅に変更された場合）、再検討し、更新すべきだ。プロジェクトのビジネス面の複雑さと技術面の複雑さを理解すれば、適切なスポンサー、プロジェクトマネジャー、チームを結集し、内在的なリスクを整理するのにも役立つ。プロジェクトを実行するか否かの判断には、プロジェクト全体の複雑さを把握することが不可欠だ。そこで、わたしからプロジェクトマネジャーへのアドバイスは次のようなものだ。「チームの能力を上回るほど複雑なプロジェクトは、それがプロトタイプであったり、その唯一の目標がそこから何かを学ぶことでもない限り、引き受けないことだ」

本稿筆者のゴパル・K・カプール氏はカリフォルニア州サンラモンのプロジェクト管理センターの代表で、著書に「Project Management for Information, Technology, Business and Certification」がある。