하향식 또는 상향식
이 문서는 "트렌치에서" 컬렉션의 일부입니다. 프로젝트 관리, 포트폴리오 관리 및 작업 관리에 대해 설명하고 이와 관련된 하향식 및 상향식 관리 사례를 비교합니다.
이 문서의 Word 버전을 다운로드하려면 하향식 또는 상향식: 백서(Project Server 2010)를 참조하세요 .
더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.
하향식 또는 상향식?
"프로젝트 관리가 필요합니다... 음, 나는 포트폴리오 관리를 의미 ... 음, 난 정말 작업 관리를 의미 ... 아, 우리 모두 필요해." 내가 자주 듣는 전투의 외침이다. 혼동을 일으키는 이 세 가지 개념에 대한 정의가 부족한 것이 아니라 유사성입니다.
수년 동안 IT 분야에서 일해온 사람들은 기술적 관점에서 사물을 보는 경향이 있으며 때로는 우리에게 도움이 되지 않습니다. 포트폴리오 관리, 프로젝트 관리 및 작업 관리의 데이터를 살펴보면 매우 유사할 수 있습니다. 세 가지 모두에 ID 필드, 설명 필드 및 시작 및 종료 날짜가 있습니다. 이 세 가지를 모두 연결하는 것은 자연스러운 일입니다.
아마도 그렇지 않을 것입니다.
이 세 가지 개념을 한 번에 하나씩 살펴보겠습니다. 그들의 유사성을 쉽게 볼 수 있지만 세 가지 관점에서 근본적인 차이가 있습니다.
포트폴리오 관리 - 하향식 접근 방식
사람 "포트폴리오 관리"에 의해 많은 다른 것을 의미 할 수 있지만, 가장 일반적인 의미는 아마 프로젝트 선택 및 우선 순위입니다. 원칙은 궁극적으로 조직의 모든 사람에게 영향을 미치지만 이 과정은 고위 경영진에게 큰 관심사입니다. 경영진은 사용 가능한 총 예산과 "이 금액으로 무엇을 할 수 있고 어떻게 해야 할까요?"라는 질문에 답해야 하는 등의 특정 제약 조건으로 시작됩니다. 포트폴리오 관리 프로세스가 충분히 성숙한 경우 이 분석에는 새로운 아이디어뿐만 아니라 기존 프로젝트도 포함될 수 있습니다.
포트폴리오 선택 및 우선 순위 지정 프로세스를 만들려면 경영진은 회사를 이끄는 비즈니스 기준에 직면하고 신규 및 기존 프로젝트를 살펴볼 때 고려할 메트릭에 미리 동의해야 합니다. 투자 수익률이 핵심 메트릭이어야 하나요? 아마도 우리는 고객 만족도 또는 직원 보존 또는 전략적 목표와의 일치에 미치는 영향을 고려해야 할 것입니다. 주요 메트릭이 무엇이든 간에 경영진은 각 프로젝트 이니셔티브를 해당 프로젝트가 이러한 목표를 어떻게 발전시킬 수 있는지, 그리고 각 프로젝트가 비용을 지출할 수 있는 대체 이니셔티브와 어떻게 비교되는지를 파악해야 합니다.
이는 머리 속에서 수행되더라도 매우 분석적인 프로세스입니다. 프로젝트 포트폴리오 관리 소프트웨어를 사용할 때 매우 분석이 좋습니다. 소프트웨어의 분석이 보고서 또는 보기에 도달하더라도 우선 순위에 대한 최종 결정이 내려지는 거의 항상 일부 관리 수준 감독이 있습니다. 이 작업이 완료되면 각 프로젝트의 프로젝트 관리를 수행할 사용자에게 최종 결과를 전송해야 합니다. 이러한 결정의 효과는 일부 프로젝트에 자금을 지원하고 다른 프로젝트에 자금을 지원하지 않고, 일부 프로젝트에 더 높은 우선 순위로 사용 가능한 리소스를 만들고, 일부 프로젝트의 일정을 진행하고 다른 프로젝트에는 지연시키는 것입니다.
프로젝트 관리 - 하향식 및 상향식
프로젝트가 승인되면 완전히 다른 영역으로 이동합니다. 이제 프로젝트 일정에 대한 클래식 보기가 집중됩니다. 이제 승인되기 전에 비즈니스 정당성에 설명된 것을 실제로 빌드해야 합니다.
프로젝트 관리자는 프로젝트 범위 및 결과물 측면에서 생각하기 시작합니다. 프로젝트 관리자는 소프트웨어 조각이든, 점유할 준비가 된 건물이든 관계없이 만들어야 하는 최종 제품을 알고 있습니다. 해당 프로젝트의 주요 단계를 생각하고 작업 분석 구조를 만들 수 있습니다.
프로젝트를 완료하는 데 필요한 논리적 단계의 중요한 경로가 설계됩니다. 또한 프로젝트 관리자는 자신이 제작되는 일정을 고려하여 프로젝트의 다양한 주제 전문가와 상담할 수 있다는 것을 알고 있습니다. 프로젝트 관리자는 작업별로 작업을 살펴보고 해당 작업을 프로젝트 단계까지, 그리고 최종적으로 프로젝트 자체에 요약하여 프로젝트의 상향식 보기를 만듭니다. 이때 프로젝트 관리자는 기술, 부서 또는 이름별로 리소스를 할당하기 시작할 수도 있습니다. 이러한 리소스에는 관련 비용이 있을 수 있습니다. 작업 기간, 필요한 리소스 및 해당 속도를 계산한 결과 프로젝트의 상향식 추정치가 제공됩니다.
지금까지는 좋았어요.
그러나 프로젝트 포트폴리오 선택 프로세스의 하향식 접근 방식을 살펴보면 비용도 있었습니다. 실제로 프로젝트의 예상 비용은 경영진이 프로젝트를 승인할 때 고려한 비즈니스 근거의 일부였습니다. 우리가 지금 주제 전문가의 결합 된 전문 지식에서 프로젝트의 상향식 추정을 얻고 있다면, 그들은 이그제큐티브 제품군에서 프로젝트 선택에 무엇을 사용했습니까?
그것은 좋은 질문입니다. 일부 조직에서는 프로젝트에 대한 비즈니스 근거를 만들기 위해 프로젝트 부서에서 대략적인 추정치를 받게 됩니다. 다른 조직에서는 포트폴리오 프로세스에서 프로젝트를 고려하기 전에 전체 상향식 추정치가 생성됩니다. 이러한 두 가지 방법의 문제는 노력을 기울인다는 것입니다. 완전한 추정은 많은 노력이 필요할 수 있지만 프로젝트는 아직 자금 조달에 대한 승인을 받지 못했습니다. 따라서 많은 조직에서 경영진이 이 프로젝트의 비용을 추측하기만 하면 됩니다.
따라서 프로세스가 모두 통합된 것처럼 보이지만 여기에 catch-22가 있을 수 있습니다. 먼저 프로젝트에 시간을 할애하기 위해 예상 또는 프로젝트 선택에 소요된 작업은 무엇입니까?
또한 상향식 추정치가 포트폴리오 선택 프로세스의 추정치와 일치하지 않으면 어떻게 되나요? 추정치가 적으면 문제가 없을 수 있지만 포트폴리오 선택 인력이 예상한 시간이나 예산에서 작업을 완료할 수 없는 경우 충돌이 발생합니다.
고위 경영진을 다시 소집하고 문제를 논의하는 것이 자연스러운 일이라고 생각할 수도 있지만, 그렇게 쉽지 않은 상황이 많이 있습니다.
우선 포트폴리오 선정 위원회는 프로젝트 관리 담당자가 거의 없습니다. 고위 프로젝트 관리 직원은 거의 항상 포트폴리오 선택 위원회에 포함되지만 그룹 자체는 일반적으로 모두 함께 할 시간을 구성하는 것이 어렵다는 것을 알게되는 매우 고위 임원입니다. 둘째, 선발위원회는 불규칙하게 만날 수 있으므로 한 프로젝트에 대한 일치하지 않는 비용의 모든 파급 효과와 예상 비용을 논의하기 위해 다시 모이는 것은 큰 도전이 될 수 있습니다. 마지막으로, 이 프로젝트에 대한 적절한 일정과 예산이 무엇인지에 대한 추측이 완전히 잘못되었다는 소식을 고위 경영진에게 전달해야 하는 경력 발전이 아닌 기업 문화가 있습니다.
작업 관리 - 상향식 접근 방식
작업 관리를 생각할 때 매우 운영적으로 생각하는 경향이 있으며, 대부분의 경우 일상적인 의제와 Outlook과 같은 제품으로 연결됩니다.
이제 개인 또는 소규모 팀 구성원 수준에서 작업하고 있습니다. 컨텍스트에서 작업이 표시되지 않습니다. 우리는 우리가 헌신한 것들 또는 팀 구성원에게 커밋하도록 요청한 것들을 볼 수 있습니다. 분석 보기가 아닙니다. 해야 할 일이 있으며 개인은 그렇게 하겠다고 약속했습니다.
그 핵심은 작업 관리가 매우 간단합니다. 작업을 수행하고 완료되면 작업을 수행한 사람에게 작업이 완료되도록 지시합니다. 이에 대한 모든 기능은 이미 Outlook에 있습니다.
유사한 데이터의 장난
"오리처럼 보이고 오리처럼 보이면 오리여야 합니다." 그것은 오리에 대 한 사실, 하지만 그것은 항상 작업 기반 데이터에 대 한 사실.
다음 세 가지 수준의 프로젝트 지향 데이터를 살펴보겠습니다.
포트폴리오 수준에서 프로젝트와 해당 프로젝트 아래 단계가 있습니다. 단계 정보에는 코드 번호, 설명, 기간, 시작 날짜 및 종료 날짜가 있을 수 있습니다.
프로젝트 수준에서 프로젝트 아래에 프로젝트 및 태스크가 있습니다. 작업 정보에는 코드 번호, 설명, 기간, 시작 날짜 및 종료 날짜가 있을 수 있습니다.
해당 작업 관리 수준에는 태스크가 있으며 작업 정보에는 코드 번호, 설명, 기간, 시작 날짜 및 종료 날짜가 있을 수 있습니다.
그들은 확실히 동일하게 보이지만, 사실, 데이터의 관점은 이러한 다소 일반적인 기록의 각각은 매우 다른 목적을 제공합니다.
"포트폴리오 보기에서 프로젝트 보기로 데이터를 Outlook으로 다시 이동할 수 있나요?"라는 메시지가 자주 표시됩니다.
그 질문에 대한 짧은 대답은 "예"입니다.
그러나 우리 회사에는 기술적인 조언을 할 때 "어떻게 해야 할지 말하지 말고, 왜 해야 하는지 말해줘"라는 진언이 있습니다.
요점을 만들려면 이 예제를 상상해 보십시오. 우리는 완전히 통합된 환경을 만듭니다. 규모의 맨 위에는 포트폴리오별로 구성된 프로젝트 목록이 있습니다. 이러한 프로젝트를 선택할 뿐만 아니라 EPM 시스템에서 라이브 프로젝트로 활성화된 후 이를 따라 더욱 통합됩니다. 이를 위해 이미 사용할 수 있는 기능을 사용하여 통합 시스템의 포트폴리오 쪽에서 시스템의 프로젝트 쪽으로 프로젝트 및 단계 정의를 이동합니다. 데이터는 동일하게 보입니다.
이제 엔터프라이즈 프로젝트 관리 시스템에서 위에서 아래로 푸시된 포트폴리오 정의의 원래 단계를 사용하여 보다 자세한 정의를 만듭니다. 이렇게 하면 프로젝트를 업데이트할 때 포트폴리오 시스템에서 해당 요약을 업데이트할 수 있습니다. 많은 작업을 수행하고 많은 리소스를 할당합니다. 이제 리소스 수준 분석을 수행하여 여러 프로젝트에서 용량을 확인합니다.
리소스 할당을 사용하여 각 사용자에게 작업 및 할당 데이터를 Outlook 작업 또는 일정 이벤트로 푸시합니다. 사용자는 더 이상 "프로젝트 관리 시스템"으로 이동하지 않아도 됩니다. 이제 그들은 자신의 일일 의제에서 자신의 데이터를 볼 수 있습니다. 데이터는 프로젝트 목록에서처럼 보이며 포트폴리오 뷰에 더 업스트림으로 연결됩니다.
이러한 작업의 진행 상황 및 Outlook의 가용성은 이 작업이 완료될 시기에 대한 예상과 함께 개별 작업에서 프로젝트 관리 시스템으로 다시 이동됩니다. 데이터는 다른 두 시스템에서와 마찬가지로 표시되므로 데이터를 이동하는 것이 비교적 쉽습니다.
이러한 시스템을 만드는 것은 기술적으로 매우 간단하다 구성 및 개발의 비트와 함께 오늘날 우리에게 사용할 수있는 도구를 사용하여. 그리고 그것은 아름답게 보여 줄 것입니다.
우리는 정기적으로 구조의 정확히이 유형을 요구받을. 그러나, 우리가 그것을 할 수 있지만, 우리는해야합니까?
작업 수준에서 개인이 응급 치과 방문을 위해 아침을 쉬고 오늘 아침에 사용할 수 없다는 Outlook을 업데이트한다고 상상해보십시오. 그것은 그에게 나쁜 소식이지만 프로젝트에 대한 파급 효과는 거대 할 수 있습니다. 이제 프로젝트 시스템은 오늘 아침에 수행될 예정이었던 작업이 오늘 완료되지 않을 것이라고 계산합니다. 내일 한낮에만 완료됩니다. 중요한 경로와 모든 태스크를 이 경로에서 다운스트림으로 보고 4시간씩 앞으로 밀어붙입니다. 아마도 수백 개의 작업이 영향을 받았습니다. 그 결과 프로젝트의 종료 날짜가 반나절 후에 푸시될 수 있습니다. 이 프로젝트에서 작업하는 다른 사람들이 이제 작업을 다시 정렬해야 하고 포트폴리오 뷰 자체가 몇 픽셀 앞으로 미끄러지기 때문에 다른 프로젝트도 영향을 받습니다.
우리가 실시간으로 이것을 상상한다면, 문제는 확대됩니다. 하루 종일 수백 또는 수천 명의 사람들이 변경하고 있으며 EPM 보기, 리소스 평준화 보기 및 포트폴리오 보기는 효과와 함께 앞뒤로 애니메이션 효과를 줍니다.
실제로는 이런 일이 일어나지 않습니다. 우선, 불운한 치과 환자는 정오에 그녀의 게시물에 돌아올 것이고 이 중요한 경로가 잡히고 모든 것이 아침에 궤도에 돌아올 수 있도록 오늘 밤 몇 시간 후에 일할 수 있습니다.
또한 데이터가 동일하게 보이지만 정확히 이러한 효과 때문에 이러한 방식으로 통합되지는 않습니다.
데이터 컨텍스트 - 관점이 중요합니다.
데이터를 볼 때 데이터의 컨텍스트는 매우 중요합니다. 레코드-레코드 스키마에서 동일하게 보일 수 있는 데이터는 애플리케이션의 관점에 따라 매우 다른 용도로 사용됩니다.
하향식 포트폴리오 뷰에서 우리는 투자 수익을 극대화하기 위해 자원을 어디에 배치할 지에 대한 전략적 결정을 내리고 있습니다. 프로젝트 관리자가 선택하지 않을 수 있습니다. 우리 조직에서는 기존 기술 집합을 완전히 벗어난 프로젝트를 선택하기도 했는데, 이러한 기술을 향상시키고 싶었기 때문에 이를 달성하는 데는 매우 비효율적이라는 것을 알고 있습니다. 투자 수익률은 효과적인 설치가 아니었으며, 학습된 설치 관리자였습니다. 분석 보기입니다.
전술적 프로젝트 관점에서 우리는 인력의 최상의 처리량을 얻고 프로젝트를 가능한 한 빠르고 효율적으로 완료할 수 있는 위치에 대한 운영 결정을 내리고 있습니다. 프로젝트 관리자의 눈은 항상 미래입니다. 과거에 일어난 일은 미래에 대한 자신의 견해를 향상시키는 한 프로젝트 관리자에게만 관심이 있습니다. 이는 매우 분석적인 보기이기도 합니다.
안건과 같은 작업 관리 보기에서는 분석이 아닙니다. 의제는 약속 시스템입니다. 우리는 우리 자신 또는 다른 사람들에게 특정 시간에 특정 한 일을 할 것이라고 약속합니다. 분석 보기에 적합할 수 있습니다. 그리고 그것은 하지 않을 수 있습니다.
영향을 이해하지 않고 이러한 관점과 컨텍스트를 혼합하면 혼란이 발생할 수 있습니다.
하향식 또는 상향식?
평소와 같이 정답이 없습니다. 프로젝트 관리 시스템의 일부 측면은 실제로 상향식에서 비롯되어야 합니다. 결국, 프로젝트에 대해 무엇이든 빌드할 개인입니다. 그러나 일부 결정은 맨 위에서 내려져야하며 필요에 따라 하향식입니다.
프로젝트 관리 패러다임의 각 수준을 구분하는 경우 이러한 시스템 중 일부가 실제로 통합되어야 하는지 여부를 확인하는 것이 더 명확해집니다. 한 레벨의 프로세스와 생각이 다른 수준에서 완전히 통합되어 직접적인 이점이 없다면 통합은 최상의 플레이가 아닙니다. 이러한 통합이 실제 컨텍스트에서 작동하는 방식과 한 수준의 빈도와 세부 정보가 다른 수준에게 값을 제공하는지 여부를 안내하는 것이 중요합니다.
예를 들어, 운영 위원회가 한 분기에 한 번만 만나 앞으로 나아갈 프로젝트와 그렇지 않은 프로젝트에 대해 큰 결정을 내린다면 매일, 매주 또는 매달 자신의 견해를 업데이트하는 이점은 무엇입니까?
엔터프라이즈 프로젝트 관리 리소스 평준화 알고리즘은 실제로 개인의 치과 약속을 확인해야 합니까, 아니면 해당 개인의 대략적인 가용성을 알기에 충분합니까?
그럼에도 불구하고 개인의 안건이나 작업표 화면에 직접 과제를 보낼 수 있다면 매일 같은 데이터를 보기 위해 다른 시스템과 인터페이스로 이동해야 하는 몇 분을 절약할 수 있을까요?
따라서 하향식은 어떤 상황에서는 옳고 상향식은 다른 상황에서는 맞습니다. 이러한 도구와 개념을 통합하면 적절한 배당금을 묶기 전에 상환할 수 있는 위치를 확인하기 위해 자신의 상황을 살펴봐야 합니다.
작성자 정보
Chris Vandersluis는 캐나다에 본사를 둔 HMS 소프트웨어인 Microsoft Certified Partner인 몬트리올의 사장 겸 설립자입니다. 그는 맥길 대학교에서 경제학 학위를 취득했으며 프로젝트 제어 시스템의 자동화 분야에서 30년 이상의 경험을 보유하고 있습니다. 그는 PMI(프로젝트 관리 연구소)의 오랜 회원이며 MPUG(Microsoft Project Users Group)의 몬트리올, 토론토 및 퀘벡 지부를 설립하는 데 도움을 주었습니다. Chris가 저술한 출판물에는 포춘, 헤비건설 뉴스, 컴퓨팅 캐나다 잡지, PMI의 PMNetwork 등이 있으며, 프로젝트 타임즈의 정기 칼럼니스트입니다. 그는 McGill 대학에서 고급 프로젝트 관리를 가르치고 종종 북아메리카 및 전 세계의 프로젝트 관리 협회 기능에서 연설합니다. HMS Software는 TimeControl 프로젝트 지향 시간 유지 시스템의 게시자이며 1995년부터 Microsoft 프로젝트 솔루션 파트너로 활동해 왔습니다.
Chris Vandersluis는 다음에서 전자 메일로 연락할 수 있습니다. chris.vandersluis@hms.ca
Chris Vandersluis에서 더 많은 EPM 관련 문서를 읽으려면 HMS의 EPM 지침 사이트(https://www.epmguidance.com/?page_id=39)를 참조하세요.