프로젝트 비즈니스 환경 영역은 프로젝트가 운영되는 환경과 통합 관리와 관련되어 있습니다. 개발 접근 방법과 프로젝트 생애주기, 프로젝트 조정도 일부 비즈니스 환경 영역과 관련되어 있습니다. 프로젝트는 프로젝트를 둘러 싸고 있는 외부의 환경에 영향을 받게 됩니다. 영향을 주는 외부 환경에 의해 프로젝트는 변경도 될 수 있고 취소도 될 수 있으며 중단도 될 수 있습니다.
이에 따라 각 역할자들과 회사는 어떻게 대응 하는지에 대해서 잘 알고 있어야 합니다. 적응형 접근 방식인 애자일 개발 방법이 굉장한 관심을 받고 있습니다. 그래서 많은 회사들이 애자일 방법론을 도입하고 싶어 합니다. 하지만 이러한 도입은 쉽지 않습니다. 애자일 접근 방식을 도입하기 위해서 회사는 어떤 준비를 해야 하고 어떤 것을 먼저 해야 하며 도입하였을 때 어떤 장점이 있는지를 파악하는 것이 중요합니다. 프로젝트에 대한 타당성 검토와 준비가 되어 프로젝트가 승인 받고 프로젝트가 착수 되었을 때 비즈니스 케이스, 프로젝트 헌장, 프로세스 조정은 중요해집니다. 그럼 이어서 매우 중요한 비즈니스 환경 영역과 프로젝트에 대해서 좀 더 자세히 알아보도록 하겠습니다.
프로젝트 비즈니스 환경 영역 이해
프로젝트 비즈니스 환경 영역에는 프로젝트 규정 준수 계획과 관리, 프로젝트 장점과 가치 평가, 프로젝트 인도, 프로젝트 범위에 미치는 외부 비즈니스와 환경 변화의 영향을 평가하고 대응하는 방법, 조직의 변화 지원으로 구성되어 있습니다. 보안, 건강과 안전 수칙, 규정 준수와 같은 프로젝트 규정 준수 요구 사항을 확인하며 규정 준수 범주를 분류하고 규정 준수에 대한 잠재적 위협을 결정합니다. 규정 준수 지원 방법을 활용하고 규정 위반의 결과를 분석합니다. 규정 준수 요구 사항을 충족하기 위해 필요한 접근 방식과 조치를 결정합니다.
프로젝트가 어느 정도 규정을 준수하고 있는지를 측정합니다. 프로젝트 장점과 가치 평가, 그리고 인도에 대해서는 프로젝트 장점이 파악 되었는지를 조사해야 합니다. 지속적인 이점을 실현하기 위해서 프로젝트를 통해서 얻는 결과물에 대한 소유권에 대해서도 문서화해야 합니다. 프로젝트 이점 추적을 위해서 측정 시스템이 실행 중인지를 검증합니다. 가치 증명을 위한 인도 옵션을 평가할 수 있습니다. 가치 획득 프로세스의 이해 관계자를 평가합니다. 외부 비즈니스 환경에 대한 변경 사항을 조사할 수 있습니다. 예를 들어 규정, 기술, 지정학적 요인, 시장 등이 있습니다.
외부 비즈니스 환경의 변화를 기반으로 프로젝트 범위, 백로그에 대한 영향 평가와 우선순위를 지정할 수 있습니다. 범위와 백로그 변경 사항에 대한 옵션을 권유하고 일정과 비용 변경이 발생할 수 있습니다. 프로젝트 범위 백로그에 대한 영향을 주는 외부 비즈니스 환경을 지속적으로 검토합니다. 조직의 문화를 평가하고 조직의 변화가 프로젝트에 주는 영향을 평가하며 필요한 조치를 결정할 수 있습니다. 프로젝트가 회사에 주는 영향을 평가하고 필요한 조치를 결정합니다. 애자일 방법론을 도입하는 것은 애자일에서 사용되는 관행을 도입하는 것이 아니라 애자일의 가치와 원칙을 도입하는 것입니다. 따라서 애자일의 가치와 원칙을 이해하는 것이 애자일 사용으로 전환할 때 가장 먼저 해야 할 일입니다.
비즈니스 환경 영역과 프로젝트
프토폴리오는 전략적 사업 목표를 달성하기 위해서 작업을 효율적으로 관리해야 하는 프로젝트 단위나 프로그램 단위, 그리고 관련된 작업들의 모음을 의미합니다. 포트폴리오에 속해 있는 프로젝트나 프로그램들은 상호 의존적이거나 직접 연관될 필요는 없습니다. 포트폴리오는 일반적으로 프로그램의 상위 개념이기 때문에 프로그램의 범위 보다 큽니다. 프로젝트 매니저(PM)는 원가 절감을 위해서 원격지에 떨어진 팀으로 구성되어 있는 프로젝트를 관리할 때 이는 프로젝트 제약 사항에 해당합니다. 프로젝트 성과에 영향을 주는 프로젝트 내부나 프로젝트 외부의 제한, 그리고 한계를 프로젝트 제약 사항이라고 부릅니다. 가장 대표적은 예는 완료일을 고정된 일자로 받는 일정 제약이 있습니다.
프로젝트 업무의 4분의 1은 반드시 원격지에서 수행되어야 하는 조직의 가이드라인이 있을 겨우 이는 프로젝트의 제약 사항의 예입니다. 프로잭트 매니저는 프로젝트 이해 관계자들과 협의하여 프로젝트 방법론을 결정할 수 있습니다. 이를 통해 프로젝트 방법론이 정해지면 프로젝트 매니저는 프로젝트 관리 계획서 문서에 기록해야 합니다. 프로젝트 방법론은 작업자가 사용해야 할 실무 사례, 기법, 절차, 규칙 등에 대한 체계입니다. 이러한 방법론은 프로젝트 관리 계획서에 작성됩니다. 리스크 관리 방법론이 리스크 관리 계획서에 포함되는 것과 비슷한 맥락입니다. 이 이외에도 프로젝트 계획서에는 프로젝트 생애 주기와 개발 방식도 포함됩니다. 프로젝트 관리 계획서에는 보조 관리 계획서, 범위, 일정, 원가와 관련된 기준선, 변경 관리 계획서, 형상 관리 계획서, 성과 측정 기준선, 프로젝트 생애주기, 개발 방식이 포함됩니다. 프로젝트 매니저는 기획 단계에서 프로젝트 헌장을 만들거나 변경하게 됩니다.
프로젝트 헌장의 변경에 대해서 승인할 수 있는 사람은 프로젝트 스폰서입니다. 스폰서는 임원 레벨에서 맡게 됩니다. 프로젝트 헌장에 대한 승인은 스폰서가 하는 것입니다. 따라서 프로젝트 헌장에 대한 변경에 대한 승인도 스폰서가 할 수 있는 것입니다. 프로젝트 헌장 변경에 대한 승인은 변경 통제 위원회에서 하는 것이 아닙니다. 변경 통제 위원회는 변경 요청서가 있을 때 변경에 대한 승인이나 기각 여부를 결정하는 역할을 담당하는 것이기 때문에 프로젝트 헌장과는 관련이 없습니다. 변경 통제 위원회는 프로젝트의 기준선에 대한 변경을 하는 역할입니다. 프로젝트 유형 중에는 글로벌 프로젝트도 있습니다. 만약 글로벌 프로젝트에서 프로젝트 매니저나 더 상위의 프로그램 단위의 프로그램 매니저일 경우 여러 개의 로컬 프로젝트 매니저들과 프로젝트를 준비할 수 있습니다.
글로벌 그룹에서 이러한 형태의 프로젝트를 진행할 수 있습니다. 예를 들어 독일의 알리안츠 그룹에서 한국, 중국, 일본 등 각 국에 디지털 프로젝트를 프로그램 단위로 진행할 수 있는 것입니다. 이러한 경우 프로젝트 매니저들은 프로젝트 공식 승인과 함께 서포팅 할 수 있는 임원을 요청하고 배정 받아야 합니다. 프로그램 관리는 프로그램 관리의 효율성을 위해서 여러 개의 프로젝트를 하나로 묶어서 관리하는 것입니다. 프로그램의 일환으로 프로젝트를 하는 것이라도 가장 먼저 해야 할 것은 프로젝트를 공식화하는 것입니다. 나머지는 전부나 그 이후에 해야 할 일들입니다. 프로젝트의 시작은 항상 프로젝트 헌장에 대한 승인으로부터 출발합니다. 프로젝트 중간에 투입된 프로젝트 매니저가 프로젝트를 하는 이유에 대해서 알고 싶다면 비즈니스 케이스를 보면 됩니다.
비즈니스 케이스는 비즈니스 관점에서 프로젝트에 투자할 가치가 있는지 여부를 판별하는데 필요한 정보를 포함하고 있는 문서입니다. 일반적으로 프로젝트 타당성 확인 자료와 프로젝트 범위 설정에 필요한 비즈니스 요구 사항, 그리고 비용과 편익 분석 자료가 포함되어 있습니다. 프로젝트 매니저가 프로젝트 헌장을 만들려고 할 때 프로젝트 범위 설정에 필요한 근거와 프로젝트 타당성 확인 자료가 필요할 때 프로젝트 매니저는 비즈니스 케이스 문서를 확인하는 것이 중요합니다. 범위 설정의 근거와 타당성 확인 자료가 있는 문서는 비즈니스 케이스입니다.
프로젝트 개발 방법론과 생애주기를 전통적인 워터폴 방식의 프로젝트에서 애자일 방식으로 전환할 경우 성공하기 위한 핵심 요소는 통제되는 사고 방식에서 촉진되는 사고 방식으로 전환하는 것입니다. 애자일 프로젝트 매니저는 프로젝트를 통제하는 방식에서 촉진하는 방식으로 관리 스타일을 전환하는 것이지 절대로 방임하거나 포기하는 것은 아닙니다. 애자일 접근 방식으로 이해 관계자들이 얻을 수 있는 이점은 소프트웨어 등의 인도물을 조기에 지속적으로 인도하여 가시성을 높이고 더 자주 조정할 수 있는 기회를 제공 받을 수 있게 됩니다. 비즈니스 환경과 프로젝트는 밀접한 관련성이 있는 것입니다.
프로젝트 비즈니스 환경 영역 추가 설명
프로젝트 변경에 대해서 관리를 할 때 프로젝트 매니저는 불필요한 변경을 예방하는 것이 중요합니다. 프로젝트 변경은 가급적 피하면 좋은 것이지만 프로젝트를 진행하다 보면 변경이 발생하지 않을 수 없습니다. 따라서 프로젝트 변경을 효과적으로 관리하는 것이 중요합니다. 특히 불필요한 변경을 예방하는 일이 가장 중요하다고 볼 수 있습니다. 불필요한 변경은 프로젝트 팀원들의 사기를 떨어뜨리고 일정과 예산을 불필요하게 증가시키게 됩니다. 프로젝트 초반에 발생하는 변경은 프로젝트에 좋지 않은 영향을 주게 되지만 프로젝트 후반에 발생하는 변경은 변경 비용이 많이 발생하게 되고 제품의 품질을 떨어뜨릴 수도 있습니다. 프로젝트에 대한 검수 방법과 승인 조건은 일반적으로 계약서에 명시되어 있습니다. 따라서 계약서의 검수 방법과 승인 조건에 외부 감사를 받아야 하는지 여부에 대해서도 기재되어 있을 수 있습니다.
계약서에 외부 감사가 검수 방법이나 승인 조건으로 명시되어 있다면 프로젝트 팀원에서는 감사 준비를 하고 이에 대응해야 합니다. 외부 감사는 일반적으로 프로젝트 규모가 크고 금액이 높은 프로젝트를 대상으로 하게 됩니다. 이러한 기준은 회사에서 회사 프로젝트 관리 세칙과 같은 내부 사규로도 규정하고 있습니다. 따라서 대상에 대해서는 회사마다 다르게 운영할 수 있지만 일반적으로 규모가 큰 프로젝트는 반드시 외부 감사를 받도록 되어 있습니다. 외부 감사를 받게 되면 프로젝트 중간에 외부 감사가 요구하는 자료를 제출해야 합니다. 프로젝트를 외부 수주사에 맡겨서 진행하는 개발 프로젝트 형태가 많습니다. 이러한 경우 프로젝트 착수 보고, 중간 보고, 종료 보고 순서로 진행되며 프로젝트 보고 단계가 끝날 때 마다 착수금, 중도금, 잔금을 지급하도록 되어 있습니다.
프로젝트 종료 단계에서는 잔금을 지급하게 되는데 산출물에 문제가 있으면 대금이 지급되지 않을 수 있습니다. 따라서 프로젝트 산출물은 매우 중요합니다. 프로젝트 마지막 단계에서 변경 요청이 있을 경우 이러한 변경이 작다면 문제가 되지 않지만 프로젝트의 일정 지연이 예상되는 변경 요청 사항이라면 프로젝트 매니저는 통합 변경 통제 수행 프로세스를 시작해야 합니다. 발주사 쪽에서 변경 요청을 하여도 반드시 해야 하는 것은 아닙니다. 요청된 변경 요청에 대해서 변경 통제 위원회를 열어서 승인인지, 기각인지를 먼저 판단하고 승인이 나면 그 때 가서 일정과 원가를 어떻게 할 것인지를 회의를 통해서 결정할 수 있습니다. 변경 요청에 대한 승인과 기각 결정이 나지도 않았는데 활동을 생략하거나 일정을 단축하거나 원가를 늘리는 방법은 올바른 방법이 아닙니다.
변경이 발생하면 항상 원칙대로 처리하는 것이 중요합니다. 만약 프로젝트가 모두 종료되었는데 이후 발주사에서 중요한 내용이 누락되었다고 문제를 제기할 경우 프로젝트 매니저는 계약이 종료되었기 때문에 새로운 사항에 대해서 추가 협의를 진행할 수 있습니다. 프로젝트가 정상적으로 종료되었다는 것은 고객이 종료 확인을 했고 승인을 했다는 의미입니다. 그래서 산출물까지 인도되었다는 것은 계약이 정상적으로 종료된 것입니다. 만약 해당 문제가 하자일 경우에는 이야기가 다릅니다. 하자일 경우에는 계약서를 근거로 하자 보증을 해줘야 합니다. 하지만 만약 하자가 아니라 중요한 사항이 누락 되었다거나 다른 요청 사항일 경우 새로운 협의를 통해서 대응하는 것이 좋습니다. 만약 소송을 준비하는 것을 생각하였다면 그것은 너무 앞서 나가는 이야기입니다.
미래 목표 달성을 위한 변화에 대한 고찰
미래 목표 달성을 위한 변화는 프로젝트를 진행함에 있어 매우 중요한 영역입니다. 프로젝트를 통해서 회사가 의도하고 원하는 목표가 있습니다. 회사가 이러한 목표를 달성하고 비즈니스의 중요한 가치들을 만들어 내기 위해서는 현재의 상태를 변화 시켜야만 할 수 있는 내용들이 많습니다. 하지만 변화에는 부작용이나 반발이 발생할 수 있습니다. 따라서 회사는 이러한 변화에 대한 부작용을 최소화 시키는 방향으로 진행하는 것이 매우 중요합니다.
회사는 변화에 의해서 기존과 다른 새로운 변화를 경험하고 이에 대해 영향을 받는 사람들을 배려할 수 있는 방안과 프로세스들도 함께 필요합니다. 프로젝트를 통해 회사가 변화하기 위해서는 미래 상태로의 효과적인 전환이 필요하며 이를 위해서 회사와 조직 전반에 걸쳐서 변화 관리가 반드시 필요합니다. 프로젝트 매니저(PM)는 이해 관계자들을 참여 시키고 동기부여 접근 방식을 통해서 사람들이 변화를 채택하는데 도움을 줄 수 있습니다.
미래 목표 달성을 위한 변화에 대한 이해
변화는 내부 영향이나 외부 요인에 의해서 발생할 수 있습니다. 프로젝트에서는 이해 관계자들의 편익을 위해서 무엇을 제공해야 하는지를 평가하고 이에 따라 신속하게 대응해야 합니다. 프로젝트는 새로운 것을 만들어 내는 것입니다. 프로젝트는 새로운 것을 만들어 내는 것이기 때문에 반드시 변화가 필요합니다. 프로젝트는 새로운 것을 만들어 내는 변화의 동인으로 작용하는 것입니다.
따라서 프로젝트를 진행하는 프로젝트 매니저는 회사와 조직이 변화에 대비하도록 철저하게 준비하는 것이 좋습니다. 프로젝트를 통해서 발생 시키는 변화에 대해서 회사와 조직이 쉽게 받아들이고 변화를 진행하는 것이 문제가 없게 끔 자연스러운 이어짐을 만들어 낼 필요가 있는 것입니다. 변화 관리와 변경 관리는 다른 개념입니다. 조직의 변화 관리는 개인과 그룹, 그리고 조직을 현재 상태에서 미래 상태로 전환하기 위한 포괄적이고 체계적인 접근 방식입니다. 변화 관리와 변경 관리는 확실하게 구분해야 합니다.
프로젝트 변경 통제에 대한 내용 이해
프로젝트 변경 통제는 프로젝트를 통해 만들어야 하는 인도, 계획, 기준선에 대한 수정 요구 사항이 발생하면 이에 대해 승인하거나 거부를 진행하는 체계적인 프로세스를 의미합니다. 모든 이해 관계자들은 변화를 수용하지 않습니다. 이해 관계자들 중에서 일부는 변화를 수용하지만 일부는 수용하지 못하는 경우가 대부분입니다. 따라서 변화 관리는 상당히 어려운 주제이자 과제입니다. 그래서 조직 변화를 관리하기 위해서 반드시 고려해야 하는 사항들이 있습니다.
변화에 대한 동의를 얻기 위해서 초기에 변화와 관련된 비전과 목표를 전달해야 합니다. 효과적인 변화 관리를 위해서 강제적인 전략이 아닌 동기 부여 전략을 사용해야 합니다. 프로젝트 팀은 이해 관계자들과 협업 하여 변화와 관련된 저항, 변화 수용과 관련된 문제들을 해결하고 조직의 변화 수용 가능성을 높이며 임직원들이 변화에 성공적으로 적응할 수 있도록 진행해야 합니다. 변화는 사람들의 불만을 만들어 낼 수 있습니다. 또한 짧은 시간에 너무 많은 변화를 진행하는 경우 엄청난 저항이 발생할 수 밖에 없습니다. 따라서 변화는 속도 조절도 중요합니다. 단기적인 변화 관리와 장기적인 관점에서의 변화 관리가 필요합니다.
미래 목표 달성을 위한 변화에 대한 설명
프로젝트는 더 나은 가치와 더 나은 미래 목표 달성을 위해서 변화를 진행하게 됩니다. 하지만 변화는 언제나 환영 받지 못합니다. 모든 이해 관계자들이 변화를 수용하는 것이 아닙니다. 따라서 변화 관리는 매우 어려운 것입니다. 프로젝트는 변화를 만들어 내는 하나의 수단입니다. 정도의 차이는 분명하게 있겠지만 프로젝트가 만들어 내는 변화를 싫어하는 개인이나 그룹이 존재할 수 밖에 없습니다. 특히 회사 안에서 직원들이 사용하는 정보 시스템을 구축하는 프로젝트일 경우 기존에 사용하던 업무 프로세스에 대한 변화가 반드시 발생할 수 밖에 없습니다.
이에 따라 직원들이 변화된 프로세스에 적응하고 변화된 내용에 대해 학습하는 시간과 노력이 일정 기간 필요하게 됩니다. 이는 기존에 익숙한 프로세스를 버리고 새로운 프로세스에 적응해야 하는 상황인 것입니다. 이에 따라 개인이나 그룹은 불편함을 경험하고 어려움을 겪을 수 밖에 없습니다. 아무리 더 나은 훌륭한 정보 시스템이 만들어 졌다고 하더라도 초반에는 시스템 오류로 인해서 불편함이 더 가중될 수도 있습니다. 장기적인 관점에서 보면 프로젝트를 통해 구축한 정보 시스템은 더 나은 가치를 만들어 내고 더 좋은 가치와 성과를 만들어 낼 수 있게 됩니다. 하지만 단기적인 관점에서는 다양하고 많은 불편함을 초래하기 때문에 많은 주체들로부터 불만과 부정적인 피드백들이 프로젝트 팀에 전달됩니다.
프로세스 개선 결과와 효과에 대한 설명
프로세스를 개선한 결과로 업무량이 줄어드는 개인과 그룹도 있겠지만 상황에 따라서는 반대로 프로세스를 개선한 결과가 자신의 업무량을 증가 시키고 가중 시키는 개인이나 그룹이 있을 수 있습니다. 이러한 경우는 해당 개인과 그룹은 불편함을 넘어서 업무와 관련된 피해를 볼 수 있는 것입니다. 변화의 정도가 많은 프로젝트일수록 변화 관리에 실패하면 프로젝트는 성공하지 못하고 실패한 프로젝트로 결론이 날 수도 있습니다. 개인과 그룹은 기존에 하던 것에 대한 익숙함과 적응했던 부분들이 있습니다.
그래서 변화를 당연하게 받아들이지 못하는 상황이라면 이것은 엄청난 불만과 부정적인 피드백으로 다가올 수 있습니다. 프로젝트는 변화를 수반하게 되며 이 때 변화를 좋아하지 않는 사람들이 많을 수 있습니다. 이에 따라 변화에 대한 체계적인 접근 방식이 반드시 필요합니다. 또한 개인들의 동기 부여를 확인하고 장기간에 걸쳐 변화를 진행할 경우 직원들의 피로감을 유발 시킨다는 것을 염두 해두어야 합니다. 프로젝트에서는 변화로 인한 부작용 모니터링은 반드시 진행해야 합니다. 변화에 대해서는 파일럿 방식으로 진행해서 점진적인 변화를 진행하는 것도 또 하나의 좋은 방법입니다. 파일럿을 통해 시스템에 대한 만족도를 확인할 수 있습니다.
변화에 대한 공감대의 필요성
변화에 대한 체계적인 접근 방식이 필요합니다. 회사 내의 개인과 그룹, 그리고 조직이 현재 상태에서 미래 지향적인 상태로 전환하는 것이 필요하다는 것을 구성원들 모두가 인지하고 받아들일 수 있는 상태가 되어야 합니다. 변화를 만들어 내는 상황 변화는 회사와 조직 내부에서 발생할 수도 있고 회사 밖에서 발생할 수도 있습니다. 심지어 대고객 서비스와 대고객 시스템에 대한 변화라면 고객이 이러한 변화에 적응해야 하는 경우도 있습니다. 대고객 서비스를 제공하는 시스템의 프로세스가 바뀌면 해당 서비스를 잘 이용하던 고객은 새로운 프로세스를 익히면서 사용해야 하는 것입니다.
상황 변화에 대응하는 변화의 동기는 회사와 조직의 생존과도 직결될 수 있습니다. 회사는 더 나은 기회를 얻기 위해서 과감한 변화를 시도할 수도 있는 것입니다. 회사는 시장의 변화에 대응해야 하고 회사도 이러한 시장 변화에 따라 함께 변화할 수 있어야 치열한 경쟁 상황 속에서 살아 남을 수 있습니다. 이러한 사실은 이제 누구나 아는 너무 나도 당연한 내용이 되었습니다. 회사에서는 더 좋은 방향으로 변화하는 것이 반드시 필요합니다. 어떤 유형과 형태의 변화이든지 간에 변화에 영향을 받는 이해 관계자들의 공감은 프로젝트의 목표를 달성하기 위한 필요 조건입니다. 분명한 것은 너무 짧은 시간 안에 너무 많은 변화를 진행하고 시도하게 되면 변화에 대한 불편함과 피로감이 사람들의 강력한 저항으로 이어질 수 있다는 것입니다. 그래서 변화에 대한 공감대가 반드시 필요합니다.
강력한 저항의 부정적 영향 이해하기
강력한 저항은 프로젝트 팀을 힘들게 만들 수 있습니다. 변화를 추진하는 경우, 회사는 회사의 임직원들의 변화에 대한 태도, 변화에 들어가는 비용, 변화의 필요성 등을 종합적으로 고려해서 변화를 진행하고 변화에 대한 속도를 함께 조절해가면서 진행해야 합니다. 너무 짧은 시간 안에 임원들과 경영진이 직원들을 찍어 누르듯이 밀어 붙여서 변화를 추진 시키면 회사 내 직원들의 변화에 대한 강한 불만과 저항으로 이어질 수 있습니다.
변화에 대해서는 임직원들 모두가 이해하고 공감하고 그 필요성을 함께 인지해야 합니다. 그리고 변화의 방향이 회사에서 추가하고 더 나은 미래 상태로 변화 시킬 수 있는 올바른 방향임을 모두 공감할 수 있어야 합니다. 사실 변화 자체도 성공할 수도 있고 실패할 수도 있는 개념입니다. 따라서 변화 자체의 방향성과 진행 방식은 사전에 치밀하게 준비되어야 하며 이러한 변화에 대한 추진을 위해서는 최고 경영자와 경영진의 적극적인 지원 아래에서 진행되어야만 힘을 얻고 진행될 수 있습니다. 회사나 조직이 지금 상태에서 더 이상 변화하지 않고 가만히 있는다면 치열한 경쟁 상황 속에서 살아 남지 못할 것이라는 강한 공감대가 있는 것도 매우 중요한 요소라고 할 수 있습니다.