설계 관리에 있어 공통적 문제들

설계 프로젝트는 제한된 정보로 시작되며 설계 제안서에서 승인된 정보만으로 프로젝트의 설계 단계를 관리하는 것은 어렵습니다. 범위가 잘 정의되어 있지 않거나, 예산이 범위에 묶여 있지 않을 수 있습니다. 그리고 일정은 시작일과 종료일만으로 구성되며, 중간 마일스톤 날짜가 몇 개 있을 수 있습니다. 그리고 일정은 시작일과 종료일만으로 구성되며, 중간 마일스톤 날짜가 몇 개 있을 수 있습니다. 이러한 모든 쟁점은 설계 담당 프로젝트 관리자에게 문제를 초래하게 합니다. 설계 프로젝트관리자의 공통적인 불만 사항에는 다음이 포함됩니다. 프로젝트 범위가 잘 정의되어 있지 않은 것. 프로젝트의 시작부터 끝까지 너무 많은 확장. 프로젝트 예산이 범위와 연동되지 않음. 작업량의 불일치, 너무 바쁘거나 할 일이 없을 수도 있음. 너무 많은 프로젝트를 동시에 처리하려고 시도함. 한 프로젝트에서 다른 프로젝트로 우선순위 이동. 부족한 의사소통, 오해, 너무 많은 재작업. 기업이 프로젝트를 처리할 수 있도록 조직되어 있지 않음. 프로젝트를 처리할 시스템이 없음. 전체적이고 이해할 수 있는 작업 계획이 없음 등입니다. 계약 문서의 작성 시 여러 가지 설계를 평가하고 계약 문서를 작성하기 위한 컴퓨터의 도입은 과거의 전통적인 수작업으로는 불가능했던 수많은 설계 대안을 평가할 기회를 제공합니다. 하지만 컴퓨터를 과도하게 사용하면 과잉 설계, 중복 작성 및 과잉 도면작성이 발생할 수 있습니다. 예를 들어 하나 이상의 시뮬레이션을 실행하려는 프로세스 엔지니어 또는 유압 엔지니어, 다른 부하 검사를 위해 하나 이상의 컴퓨터를 실행하려는 구조 엔지니어가 있을 수 있습니다. 또 하나의 예는 다른 변경이 있을 경우 도면이 어떻게 보이는지 확인하고자 하는 CADD 운영자 또는 시방서 작성자가 계약 문서에 새 섹션을 잘라내어 붙여넣기를 계속하는 것을 포함합니다. 때로는 과도한 시뮬레이션, 과잉 설계 또는 중복 작성 작업으로 인해 계약 문서에 오류가 발생할 수 있습니다. 리드 설계자는 과도한 청구 시간 없이 작업이 진행되도록 설계 성과를 모니터링하는 시스템을 개발해야 하지만 시공자가 시공 중에 작업을 수행할 수 있도록 적절하게 정의된 계획과 시방서를 작성하여야 합니다. 이것은 오류로 가득 차 있고 시공성이 부족한 미적가치 중심의 도면에 시공자의 불만을 줄일 수 있습니다. 설계 중의 범위 증가 부분입니다. 일부 설계자는 변경 사항이 프로젝트의 비용 및 일정에 미치는 영향과 상관없이 고객을 만족시키기 위해 설계 중에 변경하는 경향이 있습니다. 변경 사항은 프로젝트 개발 또는 범위 확장으로 목록화 할 수 있습니다. 프로젝트 개발은 현재 정의된 범위를 수용하는데 요구되는 변경사항과 관련됩니다. 범위 확장은 프로젝트의 원래 범위, 즉 설계 프로세스를 시작하기 전에 승인된 범위를 변경하는 수정과 관련이 있습니다. 모든 설계 성과를 위해서는 범위 확장을 통제/관리하는 프로세스가 있어야 합니다. 발주자와 엔지니어는 모두 범위와 변경 통제/관리를 위해 최선을 다해야 합니다. 발주자는 개념 설계 단계 이후에 프로젝트 범위 고정에 대해 심각하게 생각해야 합니다. 제안된 모든 변경 사항은 비용 및 일정에 대한 영향과 다른 활동에 대한 결과적인 영향을 고려한 공식 검토 및 승인 프로세스를 거쳐야 합니다. 설계 중 변경 사항을 승인하는 권한은 제한되어야 합니다. 발주자와 설계자는 변경 관리 철학 및 계획에 동의해야 합니다. 예를 들어, 어떤 조건에서 변경 사항을 고려해야 합니까? 효과가 없다면? 법적으로 영향을 미치는 경우? 환경적 영향이 있는 경우? 변경 사항의 제안이 있을 때 다음과 같은 질문에 대한 답변해야 합니다. 변화는 가치를 더하는가? 그리고 변화는 필요한가? 고정 범위에 대한 "늦어도 언제까지"라는 날짜는 발주자와 엔지니어가 합의해야 합니다. 개념 설계 단계 이후에 프로젝트 범위를 확정하는 것이 성공적인 프로젝트 관리를 위한 최선의 방법이지만, 일부 프로젝트에서는 발주자는 매우 경쟁적인 시작에서 목적물을 생산해야 한다는 점을 인식해야 합니다. 경쟁이 치열한 시장 환경에서 발주자는 완성된 프로젝트의 기능에 가장 적합하도록 설계 기간 및 시공 과정에서도 프로젝트 범위를 수정할 수 있는 유연성을 원할 수 있습니다. 이러한 유형의 상황에서 설계 팀의 작업은 더 복잡하며, 범위 변경의 모든 영향을 발주자에게 알리기 위해 특별한 노력을 기울여야 합니다. 범위 변경을 위한 엔지니어링 및 공사비는 완료된 시설의 수익, 운영 및 유지보수를 포함하여 발주자의 향후 재정적 이익에 대해 평가해야 합니다. 프로젝트 예산에는 범위 변경에 대한 예비비와 범위 확장에 대한 관리 준비금이 포함되어야 합니다. 제안된 변경 사항은 이에 영향을 받을 수 있는 모든 전문 분야 관리자 또는 기타 관련자에게 전달되어야 합니다. 그런 다음 관련된 관리자는 변경사항이 실행되는 경우 비용 및 일정의 영향을 결정하고 보고해야 합니다. 위의 영향이 발주자의 대표, 엔지니어링 관리자 및 프로젝트관리자에 의해 검토되고 승인될 때까지 작업을 계속해서는 안 됩니다. 일단 변경이 승인되면 변경의 이유를 변경 사항에 영향을 받는 사람들에게 전달하는 것이 중요합니다. 소규모 프로젝트의 프로젝트관리자는 여러 프로젝트에 대하여 동시 책임을 갖는 것이 일반적입니다. 문제는 어느 한 프로젝트의 관리가 아닙니다. 문제는 프로젝트관리자가 각 프로젝트에 요구되는 주의를 기울일 수 있는 능력인데, 이는 일정과 자원 통제/관리를 복잡하게 만듭니다. 소규모 프로젝트의 경우 최소한의 조직 구성원을 사용할 수 있으므로 프로젝트관리자는 다른 프로젝트관리자와 자원을 공유해야 합니다. 즉, 프로젝트에 할당된 소수의 설계 팀 구성원들이 여러 기능에 대한 책임을 져야 합니다.