でよくある間違い。.. 設計開発プロセス

設計開発は、資産の仕様または高レベル設計が建設を進めることを可能にする詳細設計に変換されるプロセスであり、主要な建設プロ 設計および造りの基礎で手に入れられるプロジェクトのために顧客は設計および造りの建築業者によって開発される設計が彼らの条件を満た このため、主要プロジェクトの建設契約には、通常、詳細な設計開発手順が含まれます。

契約の基礎となる商業ドライバーと一致する明確で考慮された手順は、両当事者を保護するでしょう。 また、特にPFIプロジェクトの場合、資金提供者の要件である可能性があります。 一方、不明確な手順は、契約上の責任を曖昧にし、混乱につながる可能性があります。

ここでは、設計開発プロセスの文脈でいくつかのdosといけないことがあります。

設計開発と設計承認を混同しないでください設計開発プロセスでは、設計はプログラムに従ってクライアントに提出され、クライアントは指定された期間内に応答する必要があります。 この手順は、進行中の設計の可視性をクライアントに提供することを目的としています。 これは「承認」プロセスではなく、設計と構築の契約の下で請負業者と座る設計リスクの配分を変更するべきではありません。

特定のプロジェクトで承認として動作する”コメント”があれば、設計開発手順に限定された承認メカニズムを含める必要があるかもしれません。 請負業者は、設計が基本的な機能要件（例えば、手術室の場所）を満たしていることを確認する必要があります。 クライアントはそのような事項（”隣接関係”と呼ばれる）を確認するのが最善であるため、それらにサインオフすることが適切です。

承認された要素への後の変更はバリエーションとして扱われ、請負業者は追加の時間とコストを請求する権利があります。

設計開発は、契約上の変動メカニズムとは概念的かつ実質的に異なる。 これを理解していないと、プロセスが誤用される可能性があります

デザインに対するコメント/拒否の理由を明確にするプロセスが効果的に機能するためには、クライアントが提出されたデザインに対するコメント(または拒否)の理由は、具体的かつ十分に客観的でなければなりません。 コメントまたは拒否の許容される根拠は、通常、次のとおりです:

• 設計が契約仕様に準拠していない
• 設計が法定要件に準拠していない
• 請負業者は、クライアントが設計をレビューできるように十分な支援情報を提

設計開発とバリエーションを混同しないでください設計開発は、概念的かつ実質的に契約上のバリエーションメカニズムとは異なります。 これを理解できないと、プロセスが悪用される可能性があります。 クライアントが契約に記載されていない理由でデザインにコメントまたは拒否しようとする場合、請負業者はクライアントのコメントに挑戦し、正当な場合は、クライアントが実装されていることを主張する場合はバリエーションを請求する権利があります。

バリエーションを持つインターフェイスの周りに他の問題があります。 正当なコメントがデザインの別の側面を変更する必要がある場合はどうなりますか？ 一部の契約では、そのような変更がバリエーションとしての資格を得るかどうかを明示的に記載しています。

応答に失敗しないクライアントは、常に指定された期間内に提出されたデザインに応答する必要があります。 プロジェクトへの遅延を回避するために、契約は、多くの場合、クライアントが応答に失敗した場合、それはコメントを持っていないとみなされるこ クライアントが後で設計を変更または拒否したい場合は、バリエーションを指示する以外に選択肢がない可能性があり、時間とコストの結果が伴う可

適切な紛争解決手続きを提供する設計開発の問題に関連して紛争が発生した場合、それは迅速かつ好ましくは決定的に解決されるべきである。 このため、専門家の決定が最も適切なフォーラムである可能性があります。 しかし、英国のほとんどの建設契約は建設法の対象となるため、いずれかの当事者はいつでも裁定に紛争を参照する権利があります。

Iain SuttieはBerwin Leighton Paisnerのアソシエイトです