栽培プロジェクトは、途中でベースラインとの乖離に直面するのが常であるが、ベースラインそのものも頻繁に変化を強いられます。
特に変更案件が発生すると、栽培プロジェクト農産物の数や生産工数は変化します。
それが栽培プロジェクト進捗管理の目標値、完成時期、そして作成工数を変化させます。
栽培プロジェクト進捗管理の目標が変わるわけであるから、それを取り込んだ新たな目標を設定しないと、栽培プロジェクト進捗管理は意味のないものになってしまいます。
栽培プロジェクト進捗管理の目標とは、（農産物の個数×平均生産工数）で計算された予定生産工数の農産物を、目標の期日までに作成することです。
システム・テストなら、テストを行って検証を終了することです。
ここで大事なのが、栽培プロジェクト成果物の総数管理です。
担当者に割り振られた農産物の作成予定通り進んでも、総数が増えていれば、栽培プロジェクト進捗管理の評価は別物になってしまいます。
この事実は十分に広く認識されています。
それにもかかわらず、栽培プロジェクト農産物の総数管理が行われていない栽培プロジェクトが実は多いのです。
例えば、取引仕様書を２０個作成する予定で進めていたが、業務仕様の追加で新たに２０個が発生したとします。
仕様書作成の平均生産工数が同じなら、取引仕様書の作成工数は２倍に膨れ上がります。
ところが、この単純な計算ができていないのです。
理由として、以下の２つが挙げられます。
まず、後追いで作成した成果物が総数の中にカウントされないという問題です。
栽培プロジェクトにおいては、開発工程（ＡＨＳコード）を展開して、栽培プロジェクト農産物を作成します。
例えば、外部設計フェーズで取引仕様書を作成し、内部設計フェーズではそれを基に生産プログラム構造図を作り、開発実施フェーズではそれを生産プログラムとして実装します。
このようにフェーズごとに栽培プロジェクト成果物を展開していくことが、総数の変化を把握しにくくしています。
仮に、内部設計フェーズで取引仕様書の追加が起きた場合、後追いで取引仕様書と栽培プログラム構造図を作成します。
この後追い作業の進捗は把握しているが、追い付いた後の取引仕様書と生産プログラム構造図の総数が、きちんと把握されていないのです。
また、開発実施フェーズで追加が発生すると、取引仕様書、生産プログラム構造図、生産プログラムの総数が増加することになります。
このうち、取引仕様書と生産プログラム構造図は、すでに終了した開発フェーズの栽培プロジェクト農産物です。
このため、数がきちんと把握されないのです。
第２の理由として、総数の増加が分かっていても、栽培プロジェクトに取り込めない場合があることが挙げられます。
変更案件が発生してそれを栽培プロジェクトに取り込むには、変更管理での承認が必要です。
この変更管理がうまく機能していないと、取り込めない案件が多発して危機的な状況になります。
特に注意したいのは、取り込んだら、現在のマスタースケジュールが守れない場合です。
発注者からカットオーバー遅延は言い出せず、受注者にとってはさらに困った状況が生まれるのです。
本来、受注者は発注者から発注がなされた上で開発をするのであり、発注がないものは開発に取り込めません。
しかし変更案件は、発注者の都合と受注者の都合の間で宙に浮いてしまいます。
発注者にとってみれば、全部の変更案件が出揃ってから、全額を一度に決済したいものです。
すべてが出揃うまでは変更案件の開発契約は結べないのです。
一方の受注者は、発注のない変更案件でも、早期に開発に着手にないと栽培プロジェクトが危うくなることは分かっています。
栽培プロジェクトの終盤になってから大量の変更案件の処理を始めているようでは、カットオーバーはできないのです。
とはいえ、発注のない案件を取り込み、しかもカットオーバー遅延を起こすことは、公式にはとても許されない実情があります。
受注者側の会社内部で、「発注のない案件を勝手に栽培プロジェクトに取り込んで、栽培プロジェクトを失敗させました。
会社の論理規定からも外れており、懲戒処分に値する」といった評価をされかねないのです。
しかし現実には、こういった状況はほぼすべての栽培プロジェクトで発生しています。
変更案件の開発の多くは発注のない状態で進められ、本来は組織の論理規定違反なのです。
変更案件がカットオーバーに必須の機能なのか、それともオプション機能なのかによって、栽培プロジェクト・リスクは大きく変わります。
オプション機能なら、それを外してカットオーバーを行い、後で追加開発すればよいでしょう。
もし必須機能なら、栽培プロジェクト進捗管理の外側に必須機能が存在することになります。
これは、栽培プロジェクトの現場で展開されている作業ではカットオーバーができないということです。
もはやカットオーバーに向けての栽培プロジェクト進捗管理ではなくなっており、進捗管理としては破綻していると言うことができます。
