책임 프로젝트 관리 예제의 매트릭스. 프로젝트 역할 정의. 환경 요인

프로젝트 책임 매트릭스

프로젝트 책임에 대한 계층 구조를 반영하고 프로젝트 팀에 포함 된 각 그룹의 책임을 나타내려면 프로젝트 설명 문서에 포함시키는 것이 좋습니다 책임 매트릭스, 가장 일반적인 변종은 RACI- 매트릭스로 알려져 있습니다. 이 도구의 사용은 설계가   다양한 법인의 대표로 구성됩니다 (예 : typical   KIS 구현 프로젝트에는 고객, 일반 계약자 및 하청 계약자의 직원이 포함됨). 책임 매트릭스   조직 간 또는 그룹 간 상호 작용   결과적으로 특정 쟁점에 관해 연락해야하는 불확실성과 결정해야 할 사람과 채택 된 결의안을 직접 구현하는 사람이 있기 때문에 부서와 조직 간의 프로젝트에서 때로는 오해를 피하는 것이 좋습니다.

무료 30 일 평가판에 등록하십시오. 더 많은 프로젝트 관리 팁과 모범 사례가 필요하십니까? 최신 기사, 템플릿 등을 확인하십시오. 행렬의 각 작업 또는 최종 결과에 대해 책임 수준이 각 그룹 또는 문자에 지정됩니다. 여러 사람이 역할을 수행 할 수 있거나 한 사람이 여러 역할을 수행 할 수 있으므로 작업은 특정 사람 대신 역할에 할당됩니다. 그러나 동일한 역할을 수행하는 사람이 여러 명 있지만이 사람에게 할당 된 작업이 많이 겹쳐서는 안되기 때문에 역할 대신 실제 이름을 사용하는 것이 좋습니다.

가능한 한 빨리 모든 정식의 한계를 정하는 것이 중요합니다. 권위권리와 의무, 안녕   이 프로젝트는 아직 활발한 활동을 시작하지 않았습니다. 그렇지 않으면 직원들이 자신의 공연   프로젝트에서 그들의 위치에 관해서,이 쟁점들에 대한 견해의 차이는 오래 갈등으로 발전 할 수 있으며, 일정프로젝트 성과.

특히 사람들이 어떤 역할을 충원 할 것인지 혼란스러워 할 때 특히 그렇습니다. 책임 행렬의 구조에는 몇 가지 옵션이 있습니다. 책임 책임의 "책임"수준이 부여 된 사람들은이 일을 성취하기위한 작업을 수행합니다. 각 작업 또는 그 구현을 위해서는이 책임 수준에서 적어도 하나의 역할이 있어야합니다. 그러나 필요한 업무를 돕기 위해 다른 역할을 위임 할 수 있습니다.

일의 조직

그들은 또한 "책임있는"사람들에게 일을 위임 할 수 있습니다. 각 작업 또는 구현을 위해서는이 책임 수준이있는 역할이 하나만 있어야합니다. 우리는 책임있는 책임 수준이 부여 된 사람, 작업 또는 성과를 달성하기 위해 작업 과정에서 요구되는 사람 또는 필요한 목표에 따라 구현을 보장하기 위해 작업 결과를 분석하는 사람들과상의했습니다. 일반적으로 주제 전문가 또는 작업의 직접적인 영향을받을 수있는 사람들입니다. 이들과의 양방향 통신은 일반적으로 전체 워크 플로우에서 유지됩니다.

책임 매트릭스 구축

    프로젝트의 주요 작업을 나열하십시오.

수직적으로, 매트릭스는 프로젝트의 주요 작업만을 반영합니다 (레벨 2-3 이상 ISR), 그러나 이러한 작업을 수행하는 데 필요한 서로 다른 역할을 지정할 수있는 능력을 보장 할 수있는 충분한 정도의 세부 사항이 있어야합니다. 대규모 프로젝트 및 프로그램에 관해서는 여러 가지를 개발해야 할 수도 있습니다. 책임 매트릭스   다양한 정도의 디테일.

정보에 근거한 "책임감있는"수준의 책임자는 필요한 일   작업 또는 최종 결과를 지원하지만, 원칙적으로 작업 과정에서 지속적으로 업데이트됩니다. 또는 작업 또는 배송 완료 후에 만 ​​알림을받을 수 있습니다.

책임 (Responsible) 이것은 업무를 성공적으로 완수하거나 결과를 달성하는 책임있는 역할입니다. 각 작업마다 하나의 책임감있는 역할 만 있어야합니다. 도움이 역할은 책임감있는 역할이 작업을 완료하는 데 도움이됩니다. 책임 (Responsible) 승인자의 지시에 따라 업무 수행을 보장 할 책임이있다.

    프로젝트 팀 내의 그룹 / 역할을 나열하십시오.

매트릭스에 수평 적으로 프로젝트 팀 내의 그룹 / 역할이 나열됩니다. 에서 책임 매트릭스 그룹 / 역할, 개별 팀 구성원의 성과 이름이 아님. 개인화 디자인 작업   개발 단계의 후반부에 제작 프로젝트 일정.

지원 누가 지시 된대로 업무를 완수 할 수 있도록 책임감있는 역할이 할당되었는지. 서명국 그러나 고객 대표, 감사관, 준법 감시인 또는 이와 유사한 역할로도 채울 수 있습니다. 이 구성표는 추가 역할을 추가합니다.

이것은 과제에 참여할 수있는 사람에 대한 혼란이나 논쟁이있을 때 특히 유용 할 수 있습니다. 드라이버 프로젝트에는 드라이버 역할이 하나만있을 수 있습니다. 대부분의 경우, 이것은 프로젝트 후원자이며 모든 프로젝트의 궁극적 인 솔루션 개발자 인 역할입니다.

    코드 작성 책임 매트릭스.

프로젝트의 작업과 함께 역할과 행이있는 해당 열의 교차점에있는 셀의 코드를 사용하여 참여 정도, 형식 권위   그리고 각 작업의 이행을위한 책임 할당. 공식의 다른 수준의 명확한 표시 권위   프로젝트 팀의 많은 구성원이 프로젝트에 특별한 요구를하기를 원하는 상황에서 특히 유용합니다.

승인 승인자의 역할은 설계 작업의 대부분을 승인 할 책임이 있으며 성공적인 작업을 보장하는 역할을합니다. 그들은 또한 실패의 책임이있는 정당이기도합니다. 대부분의 프로젝트에서 이들은 핵심 프로젝트 그룹을 구성하는 프로젝트 관리자 및 이해 관계자입니다.

정보를 제공받은 역할은 프로젝트의 영향을받는 사람들로 구성됩니다. 그들은 정기적 인 상태 업데이트를받으며 승인자와 운전자의 역할에 대한 결정에 대해 통보 받지만 의사 결정이나 실행에 적극적으로 참여하지 않습니다. 대부분의 프로젝트에서 이러한 프로젝트는 비 핵심 프로젝트 이해 관계자가됩니다. 책임 매트릭스에는 비즈니스 분석가가 알아야 할 숫자 용도가 있으며 다음과 같은 방법으로 사용할 수 있습니다.

표 6.1. 전설 책임 매트릭스   (RACI)

지정

암호 해독

설명

출연자 (책임자)

작업의 즉각적인 실행을 담당합니다. 각 작업에 적어도 한 명의 출연자가 지정되어야합니다.

책임 매트릭스의 가장 일반적인 사용은 다음과 같은 이점을 제공하는 프로젝트 관리에 있습니다. 특정 프로젝트 또는 작업을 달성함에있어 모든 역할에 대해 합의 된 책임을 정의합니다. 역할과 책임을 정의하여 모든 사람이 관련 그룹의 참여를 보장하는 데 도움이되는 일을해야한다는 것을 알도록 보장합니다.

  • 노력의 중복을 제거하는 데 도움이됩니다.
  • 오해의 위험을 줄입니다.
  • 모든 작업에 대한 결정을 내리는 책임을 정의합니다.
책임 매트릭스는 프로세스 일치에 대한 추가 정보를 작업에 추가하는 좋은 방법입니다.

책임

고위 경영진의 최종 결과에 대한 책임. 각 작업에는 반드시 하나의 책임을 지어야합니다.

컨설팅

의사 결정 조정, 양측 간의 상호 작용

위의 "있는 그대로"의 프로세스 책임 매트릭스부터 비즈니스 분석가는 이제 프로세스를 재 설계하는 데 도움이되는 많은 정보를 보유하고 있습니다. 매트릭스는 프로세스의 잠재적 인 병목 현상을 식별하는 데 도움이 될 수 있으며 새로운 프로세스를 개발할 때 새로운 수준의 책임을 나타내는 새로운 매트릭스를 작성할 수 있습니다. 그런 다음 이전 및 새로운 매트릭스를 비교하여 작업, 단계 또는 이해 관계자가 새로운 프로세스에서 제외되지 않도록 할 수 있습니다.

결정 결정 및 분석

위의 프로세스 매핑을 사용하는 것처럼 조직 분석에서 책임 매트릭스를 작성하면 비즈니스 분석가가 누가 무엇을 수행하고 어떤 책임을 지는지를 더 잘 이해할 수 있습니다. 행렬에는 응용 프로그램을 소유 한 사람, 응용 프로그램을 지원하는 사용자, 새 응용 프로그램이 종속되어 있거나 새로운 응용 프로그램에 종속되어있는 시스템을 소유하고있는 응용 프로그램 또는 응용 프로그램의 상태 변경에 대해 알고 자하는 사용자가 표시되어야합니다.

옵서버 (정보 제공)

그는 이미 취해진 결정에 대해 통보받으며, 그와의 상호 작용은 일방적이다.

표 6.2. 프로젝트 관리팀의 기능 책임 분배

기능적 책임

기존 시스템의 변경을 고려할 때이 시스템의 책임 매트릭스는 모든 이해 관계자가 토론 및 결정에 참여하도록 보장 할 수 있습니다. 현재 프로세스, 사업 단위 또는 조직에 대한 "있는 그대로"의 책임 매트릭스는 신입 사원이 그들이 수행하는 새로운 역할에 대한 책임과이 역할이 전반적인 비즈니스 프로세스에 어떻게 적용되는지 이해하는 데 도움이되는 귀중한 도구가 될 수 있습니다. "미래"매트릭스와 결합하여 기존 직원이 새로운 프로세스 또는 시스템 배포의 일부로 어떤 변화가 일어나는지 이해할 수 있도록 교육하는 데 특히 유용합니다.

프로젝트 큐레이터 (스폰서)

프로젝트 관리자

시스템 설계자

프로젝트 관리자

계획

계획의 개발 및 정기적 갱신

책임 매트릭스를 작성하는 것은 다음 단계를 따르는 비교적 간단한 프로세스입니다. 달성해야 할 결과를 위해 완료되어야하는 업무 또는 결과를 결정하십시오. 당신이 가지고있는 경우에, 그 때 일을위한 고장 구조를 창조하는 것이 중요하다. 행렬의 왼쪽 수직축에 그것들을 나열하십시오; 바람직하게는 이들이 수행되는 순서로 수행된다.

프로젝트 역할 정의

역할 또는 실제 지정된 개인에 대한 책임을 할당할지 여부를 결정하십시오. 그런 다음 역할 또는 이름을 행당 하나씩 매트릭스 상단에 나열하십시오. 필요에 가장 적합한 책임 매트릭스 체계를 선택하십시오. 그런 다음 매트릭스를 거치면서 차례대로 각 작업을 검토하십시오. 각 과제에 대해 과제 수행에있어서 그 역할의 책임 수준을 나타내는 대문자를 입력하여 각 역할의 책임 수준을 나타냅니다. 생략 된 책임 수준을 포함하는 계획을 사용하지 않으면 모든 역할에 책임 수준이 할당되지 않아야합니다.

계획 승인

프로젝트 팀 관리

프로젝트 관리자의 역할에 직원 할당

다음 단계는 종종 가장 어렵습니다. 이것은 다이어그램을 검토하는 것뿐만 아니라 프로젝트 또는 노력에 참여한 모든 당사자가 자신이 할당 된 책임 수준을 이해하고이 과제에 동의하는지 확인하는 것입니다. 역할을 수행하는 사람, 특히 상담하거나 정보를 얻은 사람이 너무 많은 기술이나 업무 경험을 가지고 있습니까? 책임 수준이 너무 많은 관심과 시간을 감당하고 역할을 위임 할 수 있습니까? 그렇지 않다면,이 역할이 정말로 이것과 관련되어야합니까?

  • 나이가 많은 사람이이 역할에 배정되어야합니까?
  • 각 역할은 생략 된 것 이외에도 최소한 어느 정도의 책임이 있습니까?
프로젝트 리소스가 변경되거나 작업에 대한 지식이 변경 될 수 있습니다.

프로젝트 팀 구성

자격 요건 결정 및 IP 기능 전문가 그룹 구성

프로젝트를 수행하는 데 필요한 자원의 할당 보장

이 모든 것은 책임 매트릭스를 업데이트해야 할 수도 있습니다. 책임 매트릭스가 완성되면 다음 결과를 얻었어야합니다. 관련된 모든 사람들은 이러한 노력을 수행하기 위해 배정 된 역할과 책임을 이해하고 수용해야합니다. 책임 매트릭스는 이해 관계자 관리 노력을위한 매우 중요한 도구입니다. 모든 이해 관계자가 프로젝트에 대해 갖는 책임에 대해 알고 있고 동의하도록합니다. 지원은 프로젝트가 뒤집히는 경우 새로운 리소스가 책임을 인식하거나 나가는 리소스의 책임을 재 할당하는 것을 도와줍니다. 이들은 비교적 간단하게 생성 할 수 있으며 다양한 비 프로젝트 시나리오에서 사용할 수 있습니다. 합의 된 책임 매트릭스로의 전환은 그들이 맡은 역할이나 책임에 따라 관계 당사자가 자신의 역할이나 책임으로 간주하는 것에 대해 의견이 분분 할 경우 격동이 될 수 있습니다. 프로젝트가 시작되기 전에 모든 가능한 작업을 식별하는 데 어려움을 겪는 것은 쉽습니다. 이것은 관심있는 당사자들의 추가적인 논의 일뿐 아니라 부수적 인 프로젝트 일 수 있습니다. 매트릭스의 셀에 대한 색상 코딩을 고려하여 책임 수준에 따라 한눈에 이해할 수 있도록 할 수 있습니다.

  • 노력에 필요한 모든 작업을 식별해야합니다.
  • 작업을 완료하는 데 필요한 모든 역할을 정의해야합니다.
  • 이로 인해 행렬이 이와 같이 나타날 수 있습니다.
기사 관리 프로젝트 Karen Davey-Winter.

프로젝트 팀의 직접 관리

프로젝트 팀을 자극하기위한 제안서 작성

인센티브 프로젝트 팀 제공

많은 종류의 명령이 있습니다. 기능 팀은 재무, 영업, 마케팅 등과 같이 조직의 특정 부분에 대한 운영 활동을 수행하기 위해 만들어진 영구 팀입니다. 기능 팀의 경우 비즈니스 유지에 필요한 시간 제한이 없습니다. 프로젝트 팀은 특정 목표를 달성하기 위해 이산 기간 동안 함께 참여합니다. 프로젝트가 끝나면 팀이 해체됩니다.

프로젝트 팀은 프로젝트 목표를 달성하기 위해 각기 다른 기능 그룹의 구성원이 인원이되는 특유의 성격을 지니고 있습니다. 프로젝트 매니저가 높은 신뢰도를 가졌을 때, 그는 강한 매트릭스로 알려져 있습니다. 기능 관리자가 더 강력한 권한을 가지고있을 때 이것을 약한 매트릭스라고합니다.

일의 조직

고객과의 상호 작용 및 다른 프로젝트 참가자와 필요한 모든 커뮤니케이션 링크 제공 조직

전체 조직의 준비, 조정 및 승인 조직 기술 문서프로젝트에서 IP를 생성하는 데 필요합니다.

개발 된 IC를 고객에게 양도하는 절차를 수행하고 문서화하는 조직

프로젝트의 조직 및 시행에 필요한 규제 문서의 검토 및 승인

조직, 행정 및보고 문서 작성. 프로젝트 팀 목록을 최신 상태로 유지

프로젝트 팀에게 필요한 정보 자료 제공

프로젝트 팀의 재료 및 기술 지원

프로젝트 진행 상황 모니터링

프로젝트 진행 상황을 논의하기위한 회의 조직 및 개최

큐레이터에게 프로젝트 진행 보고서 준비 및 제출

프로젝트 구현에 대한 통합보고의 접수 및 분석

IP 개발을위한 TOR의 프로젝트 결과 준수 제어

프로젝트 수행 중 전문가의 실제 인건비 조정

에서 사용 된 코드 책임 매트릭스제한이 없지만 가장 널리 사용되는 방법은 해당 코드를 설명하는 RACI (Responsible (R), Accountable (A), Consulted (C), Informed (I))입니다.

    매트릭스 사용을 시작하고 사용 절차를 포함하십시오. 책임 매트릭스   문서 " 프로젝트 관리 계획".

승인 후 책임 매트릭스   모든 변경 사항은 원본 버전 작성자의 참여로 통합 변경 관리 절차를 거쳐야합니다.

구조화 된 접근법을 사용하여 변경하는 것의 이점 책임 매트릭스   프로젝트 관리자가 배포와 관련하여 분쟁 상황이 발생할 경우 참조 할 수있는 최신 문서를 받는다는 사실에 있습니다 권위   프로젝트에서

특히 책임 매트릭스   핵심 기능 책임을 할당하는 데 사용할 수 있습니다. 그래서 탭을 클릭하십시오. 6.2   왼쪽 열에는 프로젝트 작업에 해당하는 기능적 책임과 사용 된 방법 및 축적 된 프로젝트 경험을 기반으로 한 목록이 나열되어 있으며 표의 오른쪽에는 해당 기능에 대한 프로젝트 관리 팀원의 책임 및 참여 수준이 표시되어 있습니다.

프로젝트의 기능 및 권한 확보

프로젝트 헌장의 구성에 관한 섹션에서 앞서 프로젝트 관리 팀 구성원의 역할과 기본 직무 설명의 성격에 대해 간략하게 설명했습니다. 이 섹션에서는이 부분을 자세히 검토하고 좀더 자세하게 설명합니다. 목록   기능 및 권위   아래 나열된 각 역할에 대해

프로젝트 큐레이터 (스폰서)- 프로젝트 역할   프로젝트의 전략적 관리를 담당하는 관리. 큐레이터는 프로젝트의 전략적 문제를 결정하고 범위의 주요 변경 사항을 승인합니다. 작품들, 용어, 단계, 프로젝트 관리자의 능력을 넘어서는 프로젝트 예산. 원칙적으로 프로젝트 큐레이터 (스폰서)는 매니저   조직의 최고 경영자.

주요 특징 :

    프로젝트 구현의 일반적인 관리;

    프로젝트를 수행하는 데 필요한 자원을 할당하고, 작업 자금을 제공한다.

    프로젝트의 조직 및 시행에 필요한 규제 문서의 검토 및 승인

    프로젝트 진행 상황에 대한 통합보고를 얻고 분석하는 것;

    프로젝트의 기본 매개 변수 변경 관리 및 프로젝트 관리자의 역량을 뛰어 넘는 문제 해결

메인 권위:

    프로젝트 목표 승인;

    프로젝트 관리자의 임명 승인;

    프로젝트의 전반적인 계획 및 예산 승인;

    실행의 진행 상황에 대한 요약 보고서를 프로젝트 관리자로부터받는 것;

    프로젝트 결과의 시간, 비용 및 품질에 영향을 미치는 중요한 변경이 발생할 때 근본적인 결정을 내립니다.

프로젝트 리더- 프로젝트 역할 프로젝트 관리 책임자.프로젝트 리더 계획된 프로젝트 시행 기한 및 주어진 수준의 품질에 따라 할당 된 예산 내에서 프로젝트 목표 달성에 직접적인 책임이있다.

주요 특징 :

    프로젝트 팀 및 프로젝트 관리 팀 구성;

    프로젝트의 목적을 달성하기위한 작업의 이행을 계획, 조직 및 모니터링하며, 요구되는 품질, 비용 및 특정 기간을 달성한다.

    프로젝트 자원의 배분 및 구현 과정에서 프로젝트 팀의 상호 작용 조직;

    고객과의 상호 작용 조직 및 다른 프로젝트 참여자와의 모든 필요한 의사 소통 링크 제공;

    프로젝트 실행을위한 자원의 실제 경비 계산;

    큐레이터에게 프로젝트 보고서를 생성하고 제출하는 것.

메인 권위:

    프로젝트 팀 (개별 회원)에 작업을 할당하고 구현을 모니터링합니다.

    그들의 역할 기능을 수행하기위한 프로젝트 팀의 요구 사항

    프로젝트 집행자의 실제 비용에 관한 보고서의 확인 또는 거부;

    근거 및 요구 프로젝트 큐레이터   프로젝트에 추가 자원을 할당한다.

    필요한 경우 큐레이터에게 지원을 요청하십시오.

시스템 설계자- 프로젝트 역할   프로젝트 주제 분야 책임자. 건축가   시스템 관리자는 프로젝트 관리자에게 직접보고합니다.

건축가   이 시스템은 계획된 프로젝트 기한과 주어진 수준의 품질에 따라 정보 시스템의 개발을 직접 담당합니다.

구현되는 정보 시스템에서 가장 유능한 전문가는 시스템 아키텍트의 역할에 배정됩니다. 건축가   시스템은 설계 및 IP 생성, 기술 문서 개발 및 실행 분야에서 IP, 표준 및 규정 문서를 작성하는 방법론 및 기술을 알아야합니다.

주요 특징 :

    정보 시스템의 개발 및 구현에 관한 작업의 구성, 기간 및 기술 결정;

    프로젝트 조건에 명시된 프레임 워크 내에서 IP의 개발 및 구현에 필요한 자원의 식별

    자격 요건의 정의 및 활동 분야의 전문가 작업반 구성, 업무에 따른 분배, 업무 조직 및 프로젝트 구현 과정에서의 결과 검증.

    구현되고있는 정보 시스템의 기능적 아키텍처의 무결성 보장

    프로젝트의 틀에서 지적 재산권 창출에 필요한 모든 기술 문서의 준비, 조정 및 승인의 조직

    프로젝트 수행에 대한 전문가의 실제 노동 비용 계획 및 조정;

    프로젝트 매니저에게 필요한보고의 생성 및 제공;

    iP 생성의 구현 및 중간 결과 분석

    고객 IC가 개발 한 이전 절차의 조직, 실행 및 문서화.

메인 권위:

    iP 창출에 관한 작업 스케줄링에 참여;

    프로젝트 팀에 작업 할당 및 구현 모니터링

    임명 된 임무의 양질의 성과와 새롭게 제기 된 이슈에 대한시기 적절한 정보의 집행자로부터의 요구 사항;

    필요성을 정당화하고 프로젝트 관리자에게 프로젝트에 추가 자원을 할당하도록 요청합니다.

프로젝트 관리자- 프로젝트 역할   프로젝트 관리자에게 정보를 제공하고, 프로젝트 문서 흐름을 조직하고 유지 관리하는 책임자. 관리자프로젝트는 기능적으로 특정 프로젝트에 지정되고 프로젝트 관리자에게 직접보고됩니다.

주요 특징 :

    프로젝트 관리자에게 프로젝트, 계획, 자원 및 우선 순위를 제어 할 수있는 구조화 된 정보를 제공합니다.

    회의록;

    프로젝트 문서의 적시 준비, 이동 및 보관을 보장합니다.

    메인 권위:

    프로젝트 참여자로부터 프로젝트 문서의 전송 및 수령;

    설정된 워크 플로우 시스템으로 프로젝트 참가자의 준수 모니터링

    운영 정보 프로젝트의 특정 구현 자 요구 사항 및 프로젝트 진행 상황 보고서

프로젝트의 기능과 책임을 통합하기 위해 프로젝트 역할. 역할 지침에서는 다음을 정의해야합니다.

    역할에 배정 된 사람의 목표는 무엇입니까?

    누구에게이 역할 또는 그 역할에 배정 된 직원이 제출 하는가?

    그 기능, 책임, 권위.

많은 전문가들이 지적한 중요한 점은 정의   프로젝트의 역할과 책임은 기업의 환경 요인을 고려하여 이루어져야한다. 있음 탭을 클릭하십시오. 6.3   예를 들면 조직적, 기술적, 대인 관계, 정치적 및 기타 요인이 계획 과정   프로젝트 팀.

표 6.3. 계획 팀 프로젝트에 환경 요인이 미치는 영향

환경 요인

팀 역할 및 책임의 정의에 대한 영향

조직적

프로젝트와 관련된 조직 또는 부서의 관계, 프로젝트 간 상호 작용의 메커니즘

기술적 인

프로젝트에 요구되는 기술 및 전문 분야, 언어 간의 조정 필요성 소프트웨어생애주기의 한 단계에서 다른 단계로의 전환에서의 특별한 어려움의 존재

대인 관계

프로젝트 팀의 잠재적 인 구성원들, 그들의 의무들 사이의 형식적이고 비공식적 인 관계. 업무 관계에 영향을 줄 수있는 팀 구성원 간의 문화적 또는 언어 적 차이.

정치적

잠재적 인 프로젝트 팀 구성원, 프로젝트에 대한 중요 영역에서 비공식적 인 영향을 미치는 사람들 (또는 사람들의 집단), 잠재적 인 프로젝트 참여자 간의 비공식적 인 연결의 존재 여부

각 역할에 대한 계획 단계에서 결정되어야합니다. 목록   프로젝트 팀원이 필요로하는 기술 목록의 개발을 위해 사용하는 것이 좋습니다 기술 레지스트리 - 목록프로젝트 구현 팀의 특정 클래스에 대한 카테고리 및 기술 구성 요소 ( 탭을 클릭하십시오. 6.4).

기술 세트 분석을 제공하기 위해 구성 요소는 기술 스킬, 관리, 대인 관계 스킬, 전략 스킬의 네 가지 범주로 분류됩니다. 표시된 각 스킬에 대해 등급   중요성과 등급   능력 [ 12 ]. 평가 목적으로, 4 점 척도를 사용하는 것이 일반적입니다 ( 탭을 클릭하십시오. 6.5).

표 6.4. 기술 레지스트리   프로젝트 팀을 위해

기술 능력

    프로젝트 및 기술 관리 능력

    프로젝트 문제 해결 지원

    기술 직원과의 상호 작용

    타협

    트렌드 이해하기

    마케팅의 주요 목표 이해

    시스템 분석 기술 보유

대인 관계 및 지도력 기술

    문제 해결 지원

    다기능 팀 구축

    목표 정의

    최고 경영진 지원 받기

    팀원 동기

    충돌 관리

관리 기술

    독특한 전문가의 매력

    효과적인 의사 소통 기술

    위임하는 능력 권위

    자원 제공을위한 협상

    스케줄링

    정책 및 업무 절차에 대한 이해

    다른 프로젝트 팀과의 협업

전략 기술

    전략적 계획

    전략적 의사 결정

    위험에서 일할 수있는 능력

    리드 능력

기술 등록

기술 등록 프로젝트 관리자, 시스템 설계자, 품질 전문가와 같은 인력 클래스별로 컴파일해야합니다. 프로젝트 관리자를위한 기술의 중요성은 주로 프로젝트의 규모와 프로젝트의 조직 구조에 의해 결정됩니다. 가장 위대한 권력   부여받은 프로젝트 매니저   따라서 프로젝트 조직 구조에서 가장 높은 요구 사항을 배치해야합니다. 목록   기술은 정보 기술의 전문 표준을 기반으로 결정될 수 있습니다. 기술의 분배는 행정 책임의 수준에 달려 있습니다. 등급   비판은 "기술적 인 것"에서 "행정적인 것"으로 이동 한 다음 행정 책임이 커짐에 따라 "대인 관계 커뮤니케이션"과 "전략적 기술"로 이동합니다. 대인 관계 기술의 중요성이 강조되어야합니다.   이 프로젝트는 프로젝트 팀원들의 분위기를 이해하고, 자신의 행동을 예상하며,주의 깊게 듣고, 자신의 의견을 인정하고, 문제를 해결할 경우 발생하는 문제의 수를 줄이고 직원 상호 작용을 증가시킬 수 있습니다. 프로젝트 팀을 관리하고 프로젝트에서 일하기 위해 공감 능력, 영향력, 창의적인 접근 방식 및 그룹 작업을 용이하게하는 능력과 같은 기술 의미   소중한 자산. 레지스트리가 형성되면 새로운 프로젝트 상황을 최소한으로 미세 조정하여 사용할 수 있습니다.

개발 예제등록 기술

아래 ( 탭을 클릭하십시오. 6.5, 탭을 클릭하십시오. 6.6) 컨설턴트 및 프로젝트 관리자를위한 기술 범주 : 기술, 행정, ​​대인 관계 기술, 전략 기술을 강조했습니다. 각 컨설턴트 (직업을 신청할 때와 프로젝트 팀에 등록 할 때 모두)는 1-4의 척도 ( "나쁜", "만족스러운", "좋은", "우수한")로 기술 평가를 수행해야합니다.

회사 컨설턴트의 기술적 역량을 평가하는 방법에 대해 자세히 설명하는 것은 가치가 있습니다. 프로젝트 직원을 계획 할 때 고려해야 할 가장 중요한 기술입니다.

Nalbandyan G.G., Kushnirenko E.B.    러시아 연방 정부의 재정 대학 경영학 석사, "경영 컨설팅"
   과학 고문 - 박사, 부교수, 부교수 "전략 및 위기 관리"N.V.Linder
2014 년 사업 전략, №4

위임은 관리자의 역할 중 필수적인 부분이므로 프로젝트 초기에 역할과 책임을 정의하는 것이 매우 중요합니다. 관리자의 책임은 처음부터 프로젝트에 참여한 사람들의 기대를 결정하는 것입니다.

프로젝트는 많은 사람들의 참여를 필요로하지만, 특정 작업의 구현에서 사람들이 서로 싸우는 상황을 피하는 방법. 아무도 책임을지고 결정을 내리지 않는 상황도 마찬가지입니다. 사람들은 자신의 책임 수준을 어떻게 이해해야합니까? 질문이 있으면 누구에게 연락 할 수 있습니까? 작업 또는 프로세스를 수행 할 때 누가 정보를 받아야합니까? RACI 모델을 적용하면 이러한 모든 질문에 답할 수 있습니다.

RACI 매트릭스는 역할 및 책임을 정의하고 작업 또는 프로세스의 실행에 혼란을 피하는 데 사용되는 간단한 도구입니다. 프로젝트 관리 및 "현재 상태"및 "향후 상태"에서의 책임 표시에 사용됩니다.

이 기사의 주요 목적은 RACI 방법론과 관리 활동에서의 사용 방법을 연구하는 것입니다.

책임 매트릭스는 기능 영역, 핵심 활동, 모호한 부분이있는 관리 결정을 내리기위한 기준을 결정하기위한 특별한 방법입니다. 이 과정에서 발생하는 모든 불일치는 일반적인 논의를 위해 제기 될 수 있으며, 이후에 집단적 의사 결정을 통해 해결 될 수 있습니다.

이러한 접근 방식을 통해 관리자는 활동을 설명하는 체계적인 프로세스, 구현해야 할 의사 결정에 적극적으로 참여할 수 있으며 고용 및 경영 결정과 관련하여 각 참여자가 갖는 의무와 책임을 명확히 할 수 있습니다. 이러한 접근 방식을 통해 자연스러운 워크 플로를 홍보하고 그룹 내에서 역할과 책임을 조정할 수 있습니다. 책임 매트릭스를 사용함에 따른 주요 이점은 개인적으로나 팀으로서의 역할과 책임의 차이를 명확히하는 것입니다. 종종 오해, 명확한 전문성 부족, 자신의 힘에 대한 모호한 생각이 그룹 내에서 발생하기 때문에 팀 정신이 약화되고 결과적으로 생산성이 낮아집니다. 따라서 책임 영역과 권한 영역의 정의는 각 직원과 그룹의 성과를 평균적으로 향상시킵니다.

특히, 책임 분배 매트릭스는 팀에서 수행되는 기능의 중복을 피할 수있게합니다. 분쟁 발생시 프로세스 관리자는 불일치 또는 오류가 발생한 프로세스 체인을 담당하는 특정 담당자를 지칭 할 수 있습니다. 따라서 팀은 더 많이 설정됩니다. 개방 방법   의사 소통을 기반으로 의사 소통을하고 참가자들에게 프로세스를 알린다.

표 1.   요약 : 중요한 모델 문제

매트릭스 구성 지침

행렬을 만들기 위해 준비 할 때, 당신은 역할과 책임의 분배에있어서 새로운 회사의 "철학"을 알아야합니다. 팀워크를 장려하는 것이 성공적인 프로젝트 추진의 열쇠라고 할 수 있으며, 100 %의 정확성은 종종 요구되지 않습니다. 또한 중요한 점   "검증 가능하고 검증 가능한"체인에 대한 예외가있을 것이며, 이는 이중보고 시스템을 나타내므로 워크 플로의 혼동과 금지로 이어집니다. 프로세스는 승인자 (책임자)와 책임자가 기능적 및 지식 집약적 인 단위에 최대한 가깝도록 설계되어야합니다. 동시에 승인자는 각 부서별로 유일하게 유지되어야 함을 관찰 할 필요가 있습니다. 권한있는 당국과 승인자 간의 긴밀한 상호 작용은 그룹 내 지원의 좋은 예라고 간주됩니다. 그러나 컨설턴트 및 정보의 수를 최소한으로 유지해야합니다. 준비 과정이 끝나면 모든 역할과 권한이 관련 문서에 명시되고 지원되어야합니다.

표 2.   전설의 책임 매트릭스 - RACI

"R"아티스트 (책임자) 과제를 담당합니다. 각 작업에는 하나 이상의 계약자가 있어야합니다. 책임의 정도는 승인자가 분배합니다.
"A"승인자 (책임 소재) 그에게보고하기 전에 결과에 대한보고가 있었고, 제안을 수락하고 거절 할 수있는 권한이 있으며, 거부권을 행사했습니다. 각 프로젝트마다 하나 이상의 승인자가 할당됩니다.
"C"컨설턴트 (컨설팅) 의사 결정 및 조정. 유닛 간 양방향 통신으로 특징 지어 짐
"나는" 완료된 작업에 대한 최종 정보를받습니다. 단방향 통신으로 특징 지어 짐

책임 매트릭스는 6 단계로 구성됩니다.

  1. 프로세스의 목표 및 요구 사항을 키 관리 담당자에게 알리기 위해 소개 회의를 진행합니다.
  2. 결정 지와 기능적 책임이 개발되고 분석되며 핵심 기능 목록으로 통합됩니다.
  3. 워크샵은 기능을 조화시키고 각 프로세스의 상대적인 역할뿐만 아니라 각 프로세스의 참여 유형을 설명 할 수있는 코드를 규정합니다. 결과는 책임 매트릭스의 구성입니다.
  4. 책임 매트릭스는 문서화되어 있으며 프로세스의 각 참여자와 상호 작용하는 조직에 전달되어야합니다.
  5. 새로운 역할에 대한 의사 소통 및 승인은 모든 관련 개인 및 부서의 참여로 회의를 통해 개발되고 승인되어야합니다.
  6. 후속 회의는 주기적으로 그들의 활동을 감시하고 격려하며 참가자들이 모든 확립 된 규칙을 준수하도록 조직됩니다.

RACI의 도움을 받아 결정을 내리는 주요 원칙은 다음과 같습니다.

  1. "회의 참석"과 같은 명백한 이벤트는 피하십시오.
  2. 모든 행동이나 결정은 좋은 행동 동사로 시작해야합니다. 예 : 작업, 승인, 준비, 개발, 테스트 등
  3. Verb의 조치가 솔루션을 의미 할 때 (예 : 평가하고 제어하기 위해) 우선 순위 결과를 나타내는 구를 추가해야합니다. 예 : 데이터를 분석하여 납품 지연 사유를 찾습니다.
  4. 행동과 결정은 특정 사람이 아닌 특정 역할이나 기능과 관련하여 간결하고 간결하며 설계되어야합니다.

수직적 분석 (기능적 역할 별)은 해당 문제를 나타냅니다 : 성공할 경우 :

  • 많은 R,이 경우 당신은 특정 사람이 그러한 많은 행동에 책임이 있는지 여부를 자문 할 필요가 있습니다.
  • 빈 셀이 없으면 사람들을 그런 수의 작업으로 끌어들이는 것이 필요합니까?
  • r 또는 A가 없음 -이 기능적 역할을 제거 할 수 있습니까?
  • 다량 - 책임은 정확하게 할당됩니까? 다른 사람들이 이러한 과정에서 책임을 질 수 있습니까?

수평 적 분석은 행동을 조사합니다.

  • 아무런 R도 없다면 아무도 그 과정에 책임이 없으며 실행되지 않을 것입니다.
  • 승인자가 행동을 어떻게 수행해야하는지에 대한 자신의 비전이 있기 때문에 많은 A가 혼란 스러울 것입니다.
  • 많은 C - 실제로 많은 다른 기능적 역할과상의 할 필요가 있는지를 이해할 필요가있다.
  • 많은 I - 역할이 정의되는 상황이있을 수 있습니다. RACI를 올바르게 사용하면 다음과 같은 목표를 달성하는 데 도움이됩니다.
    • 명확하게 구조화 된 계층 적 시스템을 통한 생산성 향상;
    • 결혼 생산과 같은 생산 오류의 감소, 필요한 것을 알아내는 것 기술적 특성;
    • 생산에서 중복 및 제거를 제거하여 생산성을 향상시킵니다.
    • 불필요한 기능 요소없이 현대화 된 조직 구조;
    • 의사 소통 라인 구축 (상담 및 정보 제공)으로 팀 구성원의 참여가 많아 기획 프로세스가 개선되었습니다.

요약하면, 책임 매트릭스의 분배는 성공적인 워크 플로우 계획의 중요한 요소라는 점은 주목할 가치가 있습니다. 유능한 사용 과정에서 승인자의 존재를 통해 달성 된 프로젝트의 성과를 향상시켜야합니다. 워크 플로우의 숙련 된 구성으로 의사 결정에 비표준 방식을 제공 할 수있는 유능하고 숙련 된 플레이어로 구성된 강력한 팀이 구성됩니다. 결과적으로 커뮤니케이션 인터페이스 (Consultant and Informed)의 개발을 통해 모든 참여자들 사이에보다 생산적인 커뮤니케이션 시스템을 구축 할 수있게 될 것입니다.

참고 문헌

1. Andersen B. 비즈니스 프로세스. 개선 도구. - M : RIA "표준 및 품질", 2014.

Deming V. Edwards. 위기에서. - 트 베리 : 2009 년 알바.

3. Drozhzhinov V. 회사 업무 프로세스의 리엔지니어링 // 귀하의 거래 은행. 이코노미스트. - 2012. № 2.

4. 드러커 P.F. 경영 관행 : Trans. 영어에서 - M : Izd. 윌리엄스 하우스, 2011.

5. Efremov V.S. 조직, 비즈니스 시스템 및 전략 계획 // 러시아 및 해외 관리. - 2013. - № 2.

6. Kalyanov G.N. 비즈니스 프로세스 재구성의 이론과 실습. 시리즈 "비즈니스 프로세스 리엔지니어링". - M : SINTEG, 2012.