최고의 프로젝트 관리자의 5가지 필수 자질

이 기사의 오디오 버전을 들어보세요

최고 PM이 된다는 것은 당신을 돋보이게 하고 당신이 최고 PM으로 인정된다면 당신은 수요가 많을 것입니다. 이해 관계자는 당신을 더 신뢰하고, 당신과 함께 일하기를 원할 것이며, 당신의 조언에 더 귀를 기울일 것입니다. 구축하는 데 도움이 되는 것이 무엇이든, 최고의 PM은 전 세계 조직에서 항상 수요가 있습니다. 이것은 최고 프로젝트 관리자의 몇 가지 핵심 자질 목록입니다. 바라건대, 그들은 당신이 하나가되거나 이미 이러한 습관이 있는지 확인하는 데 도움이 될 것입니다.

1. 팀 내 신뢰 구축

신뢰는 모든 팀의 중요한 측면입니다. 그것은 자주 이야기되고 쓰여지지만 프로젝트를 실행할 때 실제로 실행되는 경우는 거의 없습니다. 프로젝트 관리 프로세스에서 신뢰의 중요성은 다양한 프로젝트 관리 조직에서도 인식하고 있습니다.

국제 프로젝트 관리 협회(International Project Management Association)는 프로젝트, 프로그램 및 포트폴리오 관리의 개별 역량에 대한 글로벌 표준인 ICB4 인증에 대한 신뢰에 관한 섹션을 포함했습니다.

유사하게, Scrum의 경험주의의 세 가지 기둥은 신뢰가 경험적 프로젝트 제어를 유지하는 세 가지 가장 중요한 요소 중 하나라는 아이디어에 오랫동안 기반을 두고 있습니다. 신뢰를 구축하는 동일한 경향이 LEAN 및 기타 전통적인 프로젝트 관리 방법론에 있습니다. 이것이 오랫동안 시급한 주제였다면 PM이 팀 내에서 진정한 신뢰를 구축하는 데 방해가 되는 주요 방해 요소는 무엇입니까?

이 질문에 대한 가장 반복되는 대답 중 하나는 "문화를 비난하는 것"입니다. 신뢰 문화를 달성하는 열쇠는 이러한 문화에서 벗어나 모든 실수를 학습 기회로 바꾸는 것입니다.

이를 현실로 만들기 위해 PM은 팀 내에서 투명성과 편안함의 올바른 환경을 촉진해야 합니다. 대부분의 사람들은 팀 구성원이 자신을 표현하고 실수를 할 수 있는 환경에서 훨씬 더 잘 수행하기 때문입니다.

최고 PM은 그들과 함께 생활하고 실수를 공유하도록 격려하고 학습을 위한 모범으로 전환함으로써 모범을 통해 이러한 원칙을 팀에 가르칩니다. 최고 PM은 겸손과 취약성을 보여주는 것이 강점의 표시라는 것을 알고 있습니다. 특히 자신의 실수를 인정할 때 사람들이 방어적이 되거나 책임을 전가하는 경향이 있는 경우가 많습니다. 당신이 실수를 했고 왜 당신을 취약하게 만들 수 있다고 설명하지만 이러한 실수를 공개적으로 인정하고 분석한다면 이 습관은 다른 사람들이 미래에 그것을 피하는 데 도움이 될 것이며 모든 사람이 신뢰를 구축하고 실수에 대해 마음을 여는 데 도움이 될 것입니다. . 예를 들어, 주요 이해 관계자에게 가능한 한 빨리 이정표를 완료하도록 지나치게 약속했다면 해당 주제에 대한 기술적 깊이가 부족하기 때문에 팀에 실수를 인정하고 잘못 평가한 것을 비난하는 대신 팀에 알리는 것이 좋습니다. 원하는 만큼 빨리 기술을 제공하지 않았기 때문입니다. 이것은 다른 사람들이 당신과 팀원들과 더 강한 관계를 시작하고 구축하도록 영감을 줄 수 있습니다.

팀원의 능력, 두려움, 좌절감, 그들이 좋아하는 것과 싫어하는 것, 다른 사람들과 상호 작용하는 방식을 이해하십시오. 팀원들이 자신이 가치 있다고 느낄 때 가치를 더 쉽게 전달할 수 있습니다. 팀을 목표를 향해 억지로 밀어붙이는 대신 당면한 과제로 팀에 동기를 부여할 수 있는 방법을 찾으십시오. 그렇게 하려면 프로젝트 및 프로젝트 팀의 역할과 책임에 대한 성공이 어떤 것인지 명확하게 설명하되, 해당 분야의 전문가가 되도록 하십시오. 팀원들이 해야 할 일을 말해주기를 기대하십시오. 그들의 말에 귀를 기울이고 의사 결정을 분산하여 팀에 권한을 부여하되 필요할 때 어려운 결정을 내릴 준비를 하십시오.

결국, 당신의 팀은 당신이 참여하기 위해 존재합니다. 너무 많은 PM이 직접 작업을 작성하고 그 책임을 너무 많이 떠맡는 실수를 합니다. 이것은 때때로 해당 팀 내의 신뢰와 이해 부족으로 인해 발생합니다. 팀의 신뢰가 있을 때 팀이 작업 범위를 지정하고 사용자 스토리를 작성하고 일반적으로 중요하다고 생각하는 문제에 대한 조언을 제공하는 데 참여하도록 하십시오.

최고 PM은 팀이 최고의 자산임을 깨닫고 기회가 있을 때마다 그들과 강력한 관계를 구축할 것입니다. 협상가이자 촉진자가 되십시오. 그러나 무엇보다 먼저 팀과 하나가 되십시오. 그들은 당신이 위의 누군가가 아니라 그들과 함께 일하는 것처럼 느껴야 합니다. 이것은 이 기사에 있는 보다 기술적인 몇 가지 팁의 전조입니다. 이러한 신뢰가 없으면 프로젝트가 일련의 문제에 부딪힐 가능성이 높기 때문입니다.

핵심 요점: “모든 사람이 실수를 한다는 것을 보여주는 것은 괜찮습니다. 실수를 했을 때 공유하고, 팀에 자신의 편이라는 것을 보여주고, 팀 내 신뢰를 우선순위에 두십시오.”

2. 이해관계자들이 진정으로 필요한 것을 얻을 수 있도록 참여시키기

PM은 많은 소프트웨어 프로젝트가 이해 관계자가 원하거나 필요로 하는 것과 다른 것을 제공한다는 사실을 잘 알고 있을 것입니다. 이 문제는 다양한 요인으로 인해 발생하며 이 문제를 해결하기 위한 새로운 방법론이 탄생했습니다.

하지만 애자일 개발 시대에도 우리는 여전히 잘못된 것을 구축하는 함정에 빠지곤 합니다. 이해 관계자 분석은 필수적이지만 종종 잘못된 질문에서 시작됩니다. "왜 우리가 이것을 하고 있는가?"라는 질문을 하지 않고 많은 프로젝트가 시작되고 잘못 정의되어 실제 비즈니스 요구를 해결하지 못한 솔루션을 구축하는 함정에 빠지게 됩니다.

"왜"와 함께 최고 PM은 "누구에게?"라는 후속 질문을 해야 합니다. 솔루션을 제공하기 위해 어떤 이해 관계자가 "왜?"를 다루도록 지원하고 있습니다.

여기에서 최고 PM이 중요한 차이점을 인식합니다. 솔루션은 결과물 또는 결과물로 정의할 수 있지만 최고 PM은 솔루션 자체가 원래 비즈니스 요구 사항을 반드시 충족하지는 않는다는 것을 이해합니다. 예를 들어 이해 관계자가 비즈니스 요구 사항이 ERP 시스템을 구현하는 것이라고 생각하는 경우 PM은 ERP와 같은 솔루션을 사용하는 이면의 실제 비즈니스 요구 사항을 밝힐 수 있도록 도와야 합니다. ERP 자체는 비즈니스 요구 사항이 아니라 솔루션입니다.

진정한 비즈니스 요구를 인식하려면 맥락과 이해 관계자, 그들의 태도, 권력 또는 영향력 수준, 관심 수준, 프로젝트에 대한 영향, 프로젝트가 그들에게 미치는 영향, 관심사, 그리고 물론 그들이 무엇으로 받아들일 것인지에 대한 깊은 이해가 필요합니다. 프로젝트의 성공.

따라서 프로젝트가 목적을 보다 성공적으로 달성할 수 있도록 비즈니스 목표에 영향을 주는 솔루션 생성 프로젝트 관리자의 책임은 솔루션 생성 자체를 넘어 솔루션이 실행되는 곳으로 확장되어 실제로 생성된 가치가 예상 목표와 일치하는지 명확하게 측정합니다. 목표 정의에서.

PM은 전체 프로세스에 걸쳐 프로젝트를 제공함으로써 얻을 수 있는 진정한 이점이 실제 비즈니스 요구, 목표 및 목표에 맞춰져야 한다는 점을 항상 염두에 두어야 합니다.

개발 및 요구 사항 변경 중에 비즈니스 목표를 잊어버리는 경우가 너무 많습니다. 종종 프로젝트는 처음에 제품 개발을 촉발한 실제 비즈니스 요구 사항 중 일부를 해결하는 기능적 제품을 제공하게 됩니다. 이해 관계자가 올바르게 관리되고 제품 반복이 자주 제공되면 이를 방지할 수 있습니다.

최고 PM은 또한 프로젝트를 이끄는 자신의 역할을 인식하므로 이해 관계자가 프로젝트 초기에 모든 요구 사항을 전달하기를 기대하지 않습니다. 그들은 일부 이해 관계자가 항상 자신의 요구 사항을 설명하는 방법을 알지 못하며, 요구 사항 도출에서 프로젝트 제공에 이르기까지 이해 관계자가 자신의 요구 사항을 명확하게 설명하도록 돕는 것이 그들의 역할임을 이해합니다. 요구 사항 도출 프로세스 동안 이해 관계자의 요구 사항뿐만 아니라 그들의 관심사도 이끌어 내야 함을 기억하는 것도 중요합니다.

예를 들어, 덜 성숙한 조직에서 흥미로운 역설은 종종 새 프로젝트의 시작 부분에서 발생합니다. 프로젝트 초기화 단계에서 개발 팀은 이해 관계자가 개발할 솔루션에 대한 모든 요구 사항과 요구 사항을 명확하게 식별할 것으로 기대합니다. 동시에 이해 관계자는 전달 팀이 시간과 비용 측면에서 정확한 견적을 제공할 것으로 기대합니다.

그러나 프로젝트 범위 지정 초기에는 이러한 추정치를 확정하기에는 너무 많은 불확실성이 있으며 그렇게 하면 비현실적인 추정치를 생성할 위험이 있습니다. 때때로 이해 관계자는 현재 덜 가시적인 솔루션의 불확실성을 수용하기 위해 가능한 한 많은 요구 사항을 포함합니다. 한편, 배송 팀은 미지의 것에 대한 대략적인 추정치를 제공합니다.

그 결과 이해 관계자가 활용하는 전체 요구 사항의 20%만 얻는 솔루션이 될 가능성이 큽니다. 나머지는 프로젝트를 예산 초과 및 일정 초과로 만드는 명확한 목표 없이 개발될 것입니다.

운 좋게도 최고 PM은 이해 관계자를 참여시키고 프로젝트의 VUCA(변동성, 불확실성, 복잡성 및 모호성) 세계의 각 단계를 안내하는 방법을 정확히 알고 있습니다. 프로젝트 관리자는 프로젝트를 보다 실질적인 증분으로 나누고 이해 관계자를 참여시키는 동시에 학습 내용을 적극적으로 만들고 검토할 수 있습니다.

여기서 핵심 내용은 다음과 같습니다. “솔루션은 비즈니스 요구 사항을 해결하기 위해 구축되었으며 PM은 프로젝트가 생성될 때 이 목표를 놓치지 않도록 해야 합니다. 이해 관계자가 핵심 요구 사항과 우려 사항을 해결하기 위해 참여함으로써 올바른 것을 구축하고 싶어하는지 확인하십시오.”

3. 프로젝트 위험 관리를 유기적으로 실행

대부분의 프로젝트에는 프로젝트 초기화 초기에 발생하는 일련의 일반적인 위험이 있습니다.

거의 모든 프로젝트는 변화에 대한 사용자의 저항, 자원 부족, 미성숙한 기술 등을 포함하여 이러한 일반적인 위험으로 시작됩니다. 최고 PM은 팀을 참여시켜 일반적인 위험뿐만 아니라 가장 시급하고 고유한 위험을 식별하여 위험 식별이 프로젝트 초기의 사소한 작업이 아니라 프로젝트 수명 주기 전반에 걸쳐 반영되도록 합니다.

위험을 인식할 때 최고 PM은 요구 사항 및 우려 사항에서 위험을 명시적 또는 암시적으로 정의하는 경우가 많은 주요 이해 관계자와의 협업도 고려합니다. 훌륭한 PM은 이 프로세스가 요구 사항 도출 단계에서 전체 프로젝트 수명 주기에 걸쳐 발생한다는 것을 이해하고 이를 프로세스 전반에 걸쳐 위험을 정의하는 자산으로 간주합니다.

전문가 PM은 또한 팀을 신뢰하고 전문가 지식을 위험 완화의 원천으로 인식합니다. 팀 구성원이 위험을 사전에 발견할 수 있도록 PM은 팀이 프로젝트를 주도하고 위험 식별 및 관리에 적극적으로 참여할 수 있도록 권한을 부여합니다.

실용적인 측면에서, 일일 스탠드업 중 세 번째 질문은 "무엇이 방해가 됩니까?"입니다. 팀이 프로젝트의 성공에 기여할 수 있는 권한이 부여됨에 따라 보다 신중한 응답을 반영합니다. 물론 일부 차단기는 일시적이거나 스크럼 직후에 제거될 수 있지만 일부는 잠재적인 후보가 되어 상당한 위험이 될 수 있습니다. 팀 구성원은 이러한 잠재적 위험을 식별하도록 격려해야 하며 프로젝트 수명 주기가 끝날 때라도 무시하지 말고 포함된 것을 축하해야 합니다.

위험 인식은 위험을 명시하고 앞으로 나아가는 것만큼 간단하지 않습니다. 위험 인식은 확률, 심각도 및 때때로 잊혀지는 지표인 근접성 측면에서 정기적으로 평가되어야 합니다. 후자의 메트릭을 통해 팀은 "다음 위험 인식 단계까지 아무것도 하지 않음"이든, 위험이 더 근접한 경우 더 가시적인 것이든 올바른 조치 항목을 정의할 수 있습니다. 여기에서 인식하는 것이 중요한 것은 최고 PM이 위험을 실행 가능하게 만드는 방법을 이해하고 있다는 것입니다. 위험은 관리되지 않으면 도움이 되지 않기 때문입니다. 또한 조치 항목 목록은 사후적일 뿐만 아니라 본질적으로 사전 예방적이어야 하며 궁극적으로 위험 조정 제품 백로그를 알려야 합니다.

요컨대, 최고 PM은 경험이나 권한에 관계없이 위험 인식 및 관리를 위한 단일 소스가 아니며 그렇게 되어서도 안 된다는 것을 인식합니다. 이해 관계자, 팀 및 기타 중요한 프로젝트 기여자는 초기 단계뿐만 아니라 프로젝트 수명 주기 전반에 걸쳐 정기적으로 위험 인식 및 관리에 참여해야 합니다. 이것은 프로젝트 초기에 식별되었지만 그 이후로 관리되지 않은 위험을 거의 사용하지 않기 때문에 중요합니다.

여기서 핵심 내용은 다음과 같습니다. “성공적인 프로젝트 관리를 달성하려면 전체 팀이 위험 식별을 책임져야 합니다. 위험 발견은 프로젝트의 전체 수명 동안 발생하는 지속적인 프로세스여야 합니다.”

4. 환경에 대한 이해

최고 PM은 중국 상점의 황소처럼 프로젝트를 시작해서는 안됩니다. 방법론이나 프로젝트 접근 방식을 강요하는 대신 프로젝트 관리자는 환경, 공식 구조, 비공식 구조, 문화, 습관, 도구, 기능 및 조직 자산에 대한 심층 분석을 수행해야 합니다. 그래야만 변화의 여정을 시작할 수 있습니다.

모든 PM은 자신이 수행하는 프로젝트가 조직에 영향을 미칠 것이라는 점을 이해하고 있지만, 최고 PM은 조직이 마찬가지로 자신의 프로젝트에 영향을 미친다는 것을 알고 있습니다.

결함이 있는 획일적인 사고 방식 대신 최고 PM은 환경을 이해하여 접근 방식을 조정합니다. 그렇게 함으로써 가장 시급한 비즈니스 요구 사항, 조직이 솔루션을 채택하거나 수용하는 방법, 채택, 목표 달성에 올바른 적합성을 달성하기 위해 솔루션에 적용할 변경 사항을 더 잘 인식할 수 있습니다.

효과적인 프로젝트 관리 접근 방식을 조정하는 동안 최고 PM은 다양한 PM 접근 방식뿐 아니라 비즈니스 분석 방법론, 변경 관리 프레임워크, 엔터프라이즈 아키텍처 프레임워크 및 기타 유용한 분석 방법에 대해 깊이 이해해야 합니다. 이를 통해 PM은 현재 진행 중인 프로젝트를 수행하는 데 있어 회사에 가장 적합한 솔루션을 찾을 수 있습니다.

예를 들어, 승인 수준이 매우 다양하고 매우 엄격한 계층적 조직에서 프로젝트를 시작하는 경우 가장 좋은 접근 방식은 혼합 또는 하이브리드 프로젝트 관리 접근 방식일 수 있습니다. 사전에 요구 사항 승인을 수행한 다음 공식적인 단계 게이트가 있는 단계로 프로젝트를 분할하여 구조화된 요구 사항 도출 단계를 수행할 수 있습니다. 이와 동시에 PM은 개발 팀 내에서 애자일과 유사한 반복 실행을 설정하여 보다 전통적인 프로젝트를 실행함에도 불구하고 반복 개발의 모범 사례를 캡처할 수 있습니다.

요약하면, 최고 PM은 회사 문화를 존중하는 동시에 프로젝트 관리 관행을 개선하기 위해 새로운 접근 방식과 코칭 조직을 정중하게 제안합니다. 그들은 많은 조직이 변화에 대한 성숙도와 준비 상태가 서로 다르다는 점을 인식하고 이를 위협이 아니라 기회로 여기며 각 회사의 프로젝트 관리 모범 사례 구현 능력에 긍정적인 영향을 미칩니다.

여기서 핵심 내용은 다음과 같습니다. "프로젝트 관리자는 자신의 의제를 맹목적으로 밀어붙여서는 안 되며, 조직의 작업 방식에 적응해야 하며 필요한 경우 변경 사항을 천천히 전달해야 합니다."

5. LEAN 원칙 적용

최고 PM은 여정이 목표만큼 중요하다는 것을 알고 있습니다. 때때로 프로젝트 여정은 작업 수행 방법을 정의하는 프로세스로 인해 특히 번거롭습니다. 이는 불필요하게 무거운 템플릿, 무의미한 회의 또는 여행을 방해하는 산만한 주변 장치에서 나타날 수 있지만 이러한 방해 요소가 팀에 최대한 영향을 미치지 않도록 하는 것은 PM의 책임입니다.

최고 PM은 LEAN 방법론에 잘 정의된 민첩한 프로젝트 관리 원칙을 바탕으로 팀을 위한 보다 효율적이고 효과적인 프로세스를 식별해야 합니다.

널리 알려진 오해는 LEAN이 제조에만 적합하다는 것이며 이는 사실이 아닙니다. LEAN 프로젝트 관리 방법은 모든 프로젝트와 모든 프로세스를 향상시킬 수 있습니다. 단순한 비용 절감 프로그램이 아니라 팀을 위한 사고 방식과 행동 방식입니다.

LEAN 원칙 적용의 이점은 Toyota의 CEO인 Katsuaki Watanabe의 인용문에 잘 요약되어 있습니다. “훌륭한 프로세스 관리는 우리의 전략입니다. 우리는 뛰어난 프로세스를 관리하는 평범한 사람들로부터 뛰어난 결과를 얻습니다. 우리는 경쟁자 들이 깨진 프로세스를 관리하는 뛰어난 사람들로부터 평균(또는 더 나쁜) 결과를 얻는 경우가 많다는 것을 관찰했습니다.”

불필요한 프로젝트 소음과 작업을 제거하는 편향을 가진 최고 PM은 자연스럽게 프로세스를 LEAN 원칙으로 이끌 것입니다. 최고 PM은 제품 소유자, 해당 팀 및 관련 이해 관계자와 긴밀하게 협력하여 요구 사항을 간소화하고 이러한 요구 사항에 대한 응답으로 예상 가치를 지정할 수 있도록 해야 합니다.

프로젝트에 대한 모범 PM 사례를 차용하기 위해 LEAN 너머를 살펴보는 것도 유용합니다. 예를 들어, PRINCE2 방법론만 이 프로젝트의 시작 단계에서 배운 교훈을 캡처하는 의무적인 작업을 가지고 있습니다. 이것은 새 프로젝트를 시작할 때 다른 사람들이 거의 사용하지 않을 문서를 프로젝트 마지막에 작성하는 대신 이전 프로젝트에서 배운 모든 교훈을 포착합니다. 불필요한 단계를 제거하고 실제 가치를 추가하는 단계에 집중하기 위해 프로세스를 변경하는 것을 두려워하지 않는 것이 중요합니다.

이것은 프로세스를 돕고 재구성하거나 팀이 처음부터 올바른 프로세스를 선택하는 데 도움이 되는 좋은 기회입니다. 이러한 명확한 성과 지표는 프로젝트 성공의 명확한 지침을 정의하기 위해 관련된 모든 사람과 투명하게 공유되어야 합니다.

여기서 핵심 내용은 "올바른 솔루션을 찾는 것은 해당 솔루션을 제공하기 위한 정확하고 간소화된 프로세스를 갖는 것만큼 중요합니다."입니다.