色々準備を行いやっとプロジェクトが立ち上がり運用が軌道にのってからも、いろいろ問題が発生します。なかでも、製造・開発関連のプロジェクトの根幹に関する問題として、開発物の機能変更があります。
ここではまた、システム開発を例に考えてみます。要求仕様をとりまとめ、システム仕様を決め、プログラム設計を行い、コーディングを行い、テストを行い、運用にはいるわけですが、機能変更が出るのは大概、コーディングがほぼ終了し、α版、β版としてテストモードに入ったときに、仕様確認として出されたものに対してです。
この段階でだされる機能変更は原則として
の４つのパターンになります、ようは、各段階でのチェック機能が働いていないために起こるいわゆるミスです（大概、設計ミスと一言で終了してしまいます） 本来ソフトが動いてみてわかるというのでは要求仕様やシステム仕様、プログラムの設計をやる意味がないようにも思えますが、ここが実は重要なところで、誰が機能変更を決めるのか そもそもなぜ機能変更を行うのか という点を明確にしておく必要があります。
結局、要求仕様やシステム仕様、プログラムの設計を行い、その段階でチェックできるスキル・そして時間を持った人間はそれほどおおくありません、しかし、システム開発は数千〜数億単位となりことが多く、限られた人間が独断ですべてをきめてしまうにはリスクが高くなってしまいます。
そこで、α版、β版の段階で出来るだけ多くの利用者に一度使ってもらい、問題点を洗い出し、機能変更を行うことにより、運用時のリスク低減を図ることは、運用コスト低減につながります。
とはいえ、α版、β版段階での機能変更は、特にスケジュールと品質への影響がおおくなります、具体的にはどうしてもスケジュールが伸び、品質が下がることになります。
そこで、あらかじめ設計段階である程度機能変更を見越した設計を行うことが必要ですが、あまり機能変更の自由度をあげてしまえば、コスト（開発期間と品質）がかかりすぎてしまいます。
結局、最後はバランスの問題になってしまいます。このバランスを維持することが、プロジェクトマネージャとしてもっとも難しい点かもしれません。