설계 작업 계획과 공통적 문제들

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