この短い記事では、設計プロセスの7つの段階の最初の段階である、設計プロセスのビジネスケース段階に関する16のヒントの概要を説明します。設計管理の役割は、社内またはコンサルタントの所有者または開発者側の設計マネージャーのコンテキストで考慮され、完全に文書化された設計および構築のみの契約に基づいています。

設計管理は、主に設計プロセスの強化に焦点を当てたプロジェクト管理手法の確立を目指しています。建築プロジェクトの場合、プロジェクトライフサイクル全体を通じて設計管理を正常に実装することで、建築プロジェクトの成功と失敗の違いを表すことができます。

所有者と開発者は、要件がプロジェクトに完全に組み込まれ、プロセスが品質、タイミング、コスト、および価値の観点から必要な結果をもたらすようにプロジェクトが効果的に管理されることを保証できれば、建築プロジェクトの優れた成果を達成できます。

設計管理への従来のアプローチは、プロジェクト管理プロセスを介して行われ、設計管理は単にプロジェクト管理プロセスのコンポーネントと見なされ、設計プロジェクトはプログラムスケジュールとコストプランへの配信という観点から管理されます。設計自体の管理は、通常、設計者に任され、主任コンサルタント、通常は建築家が調整プロセスを管理します。

実際、建物の設計はプロジェクト管理プロセス全体の非常に重要なコンポーネントであるため、所有者と開発者にとって最良の結果を達成するには、専用の管理が必要です。この設計管理は、プロジェクトのライフサイクルの開始から、その後すべての重要な段階を通じて実装する必要があります。

設計管理の全体的な責任は、設計チーム自体ではなく、所有者または開発者のプロジェクト管理チーム内にある必要があります。設計チームは、技術的な観点から独自の社内設計を管理し、必要に応じて調整を行う必要がありますが、すべて所有者または開発者の設計マネージャーの注意深い監督の下で行われます。

ビジネスケースステージ-デザインレポート

設計マネージャーによるプロジェクトライフサイクルへの早期の関与は重要です。ビジネスケースステージのデザインマネージャーからの出力は、所有者または開発者のプロジェクト全体のビジネスケースに直接フィードされるデザインレポートになります。

以下は、設計プロセスのビジネスケース段階における所有者または開発者向けの16のヒントです。

ヒント1：所有者または開発者のデザインマネージャーを指名します。デザインマネージャーは、所有者または開発者の要件を満たし、望ましい結果を達成するデザインを提供する責任があります。

ヒント2：クライアントブリーフ、概念図、調査、計画条件など、プロジェクトで利用可能なすべてのデータを照合します。これは、プロジェクトの設計要件を開発するための設計関連情報を特定するのに役立ちます。

ヒント3：設計の観点からプロジェクトの実行可能性を判断するための基準を確立します。これを、関連するすべての利害関係者が関与する共同作業にします。

ヒント4：プロジェクトの機能要件を決定して定義します。これにより、プロジェクトに含める所有者または開発者の要件を可能な限り特定します。

ヒント5：利用可能なすべての設計情報を評価して、重大なギャップを特定します。次に、ビジネスケースにさらに情報を提供するために、設計に関連する調査とデータ収集をさらに行うことができます。

ヒント＃6：提案されたサイトにアクセスして、検討中のサイトに精通します。これは、プロジェクトが既存の環境内にどのように位置するかについての現実世界の視点と、周囲の影響に関するコンテキストを提供します。

ヒント7：ビジネスケースを開発する際に設計の観点から検討する実行可能なオプションを特定します。所有者または開発者は、プロジェクトのタイミング、サイトの場所、コスト、価値、および持続可能性の観点からオプションを確認できます。

ヒント＃8：設計レポートを作成する際に必要な技術的およびプロジェクトの入力について、必要に応じて設計コンサルタントを雇います。このような入力は、より技術的な詳細または評価が必要な場合にビジネスケースを強化します。

ヒント＃9：設計リスクを決定し、これらのリスクの評価を提供します。これは、ビジネスケースに情報を提供し、設計の観点から懸念事項を特定するのに役立ちます。

ヒント＃10：プロジェクト設計を提供するために必要な最も適切なコンサルタントを選択します。コストと設計チームを関与させるタイミングを評価します。これを行うと、ビジネスケースで予想される設計コストが通知され、提案を求める可能性のあるコンサルタントのリストが特定されます。

ヒント＃11：コンサルタント契約を準備します。調整、プログラム、成果物、および契約条件に関するサービスの範囲と設計の役割を含めます。これにより、すべての設計コンサルタントが一貫性のある明確な要件に対応できるようになります。

ヒント＃12：設計チームのプロジェクト組織図を作成します。これは、設計チーム自体の間でさまざまな設計コンサルタントの責任を定義し、プロジェクトのレポートとコミュニケーションの構造を特定します。

ヒント＃13：構築可能性、持続可能性、プログラミング、環境、およびその他の利害関係者の要件を検討します。この段階でのこの高レベルの評価は、ビジネスケースにさらに情報を提供します。

ヒント＃14：所有者または開発者とレビューするビジネスケース設計レポートのドラフトを準備します。これは、これまでに検討されたすべての設計関連の問題を確認する機会を提供し、レポートを完成させる前にコメントを組み込みます。

ヒント＃15：ビジネスケースの最終的なデザインレポートコンポーネントを整理して、所有者または開発者に提示します。これで、ビジネスケース全体の一部として、ビジネスケースへの設計入力が完了しました。

ヒント＃16：所有者または開発者からビジネスケースの正式な承認を取得します。承認は、アウトラインデザインを開発するための基礎です。

これらのヒントは、設計管理における32年以上の経験の結果です。構造エンジニア、建築工学（A＆E）プラクティスの所有者としての確かな技術的バックグラウンドを持ち、オーストラリア、アジア、中東で小規模から「メガ」までの幅広いプロジェクトに携わってきたPaul Sancandiは、現在シニアデザインです。オーストラリアのマネージャーコンサルティング。

If you liked this posting and you would like to obtain more information concerning MFA kindly check out our web site.