(1)監査の実施者の権限、開発主体への影響力に限界は無いか
進捗の改善は、コストがかかる。コストの分担は、委託者、受託者伴に大きな問題となる。（通常、委託者の方が強い）
(2)システムの内容にかかわらなくて適切な勧告が可能か
平均的なシステム開発リーダーであれば、納期遅れの対策はほぼ理解している。しかし、開発コストオーバーにつながるため、とれる対策が限られている。
上記の状況で、建前論を展開しても実質的な改善は進まない。本当の対策は、コストの増加、分担の詳細まで立ち入って具体的アクションを決める必要がある。
(3)今までの進捗管理手法で進捗管理ができるか
ウォーターフォールモデルで利用してきた管理方法がオブジェクト指向、プロトタイピング手法の開発に適用できない。
新しい手法での開発は、ほとんどが「仕掛かり」状態であり、ある日突然に大量の完成が発生する。このような開発手法での進捗把握は何を指標として実施ずるべきか。

２．システム開発を納期通り、見積もり予算内で完了可能か

(1)システムの進捗遅れは取り戻せない（遅れを増大させないことは可能）
進捗遅れは、原因があり原因を取り除くだけでは本来の進捗に復帰するのみで遅れは取り戻せない。遅れを本当に取り戻すには、予定の工数の倍から３倍の投下が必要で、実際にはコスト的に困難である。
(2)見積もり時に適正な余裕を組み込めれば可能
見積もり時に経験的な余裕を反映した内容でユーザーが納得すれば、うまくプロジェクトをコントロールできた場合は、予算ないで完了することができる。
しかし、適正な余裕を算定する妥当な手段が無い。（開発者の能力不足と言われればそれでおしまい）

３．システムの品質を監査できるか

(1)品質とコスト、納期の見合いを誰が調整可能か
システムの品質は、テストの内容とテストの実績からほぼ予測することは可能である。 但し、性能に関する品質向上は、通常、きわめて工数が必要となるケースが多い。この場合の、コスト負担を解決しないと対応は難しい。

４．開発局面のシステム監査をビジネスとするには

(1)権限と責任
プロジェクトの改善にはコストが必要となるため、コストを提供する権限が必要。しかし、その場合は、プロジェクト完遂責任が発生するのが一般的と考える。（改善勧告のみで済むか？ビジネスのリスクは？）
(2)マーケットは
開発委託者（ユーザ）の一般的な感覚、建前は、「システム開発はうまくいってあたりまえ」である。「失敗するのがあたりまえ」という感覚になってくればニーズがでてくるかもしれない。