프로젝트 관리의 진화: 신생 기업 대 기업

스타트업은 포커를 하고, 대기업은 체스를 합니다.

Google의 Developer Advocate인 Don Dodge의 이 인용문은 스타트업에서 프로젝트 관리자가 되는 것과 기업에서 프로젝트 관리자가 되는 것의 차이점을 요약합니다.

스타트업은 확률 게임을 하고 있습니다. 포커 플레이어와 마찬가지로 최고의 플레이어가 지속적으로 이기지만 때때로 아마추어에게 집니다. 스타트업 프로젝트 관리에서는 뛰어난 실행력이 필요하지만 사실은 최고의 기업가라도 실패할 수 있다는 것입니다. 체스와 마찬가지로 엔터프라이즈 프로젝트 관리 시스템은 훨씬 더 전략적이고 두 단계 앞서 계획하고 위험을 덜 감수해야 합니다.

흑백이 전부는 아니다

이 주제를 다루기 전에 주의해야 할 점은 모든 종류의 회사가 있다는 것입니다. 직원 100명의 회사를 더 이상 스타트업이라고 부를 수 있습니까? 직원이 200명에서 300명으로 늘어난다면? 때때로 Uber는 여전히 미디어에서 스타트업이라고 불리지만 현재 Uber는 12,000명의 직원을 두고 있습니다. 또 다른 차이점은 학부생이 시작한 스타트업은 20년 이상의 전문 경험을 가진 연쇄 창업가가 시작한 스타트업과 매우 다르다는 것입니다.

따라서 5명이 함께하는 공동 창업부터 전 세계에 지사를 둔 다국적 기업까지 다양한 사례가 있습니다. 이 기사는 주로 두 가지 극단에 초점을 맞출 것이지만, 모든 것을 약간의 소금으로 받아들이고 테이크아웃이 귀하의 특정 상황에 적용되는지 여부에 대해 비판적으로 생각하십시오.

스타트업 대 기업

이 경고를 무시하고 두 가지 극단을 정의하여 논의의 근거를 마련해 보겠습니다. 이 기사의 목적에 따라 스타트업 의 특성은 다음과 같습니다.

• 일반적으로 모든 동료의 이름을 알고 있는 공동 배치 팀(최대 1-50명의 직원).
• 역할은 느슨하게 정의됩니다.
• 공동 창립자는 대부분의 결정을 내리는 데 매우 적극적입니다.
• 회사는 손실을 보고 있고 남은 활주로도 얼마 남지 않았습니다. 생존이 주요 문제입니다.

스펙트럼의 다른 쪽 끝에서 기업 은 다음과 같이 보일 것입니다.

• 여러 부서 및 위치.
• 당신은 직속 동료에 대해서만 잘 알고 있으며 다른 부서의 소수의 사람들과 교류합니다.
• 모든 사람에게는 명확한 책임과 계층이 있습니다.
• 회사는 공개될 수 있습니다.
• 수익성과 단기 생존은 문제가 되지 않습니다.

시작 프로젝트 관리

프로젝트 매니저 ≈ 제품 매니저

이론적으로 프로젝트 관리자는 제품 관리자와 실질적으로 다른 책임을 집니다. 그러나 시작 설정에서 두 역할은 일반적으로 얽혀 있습니다. 당신이 스타트업의 프로젝트 매니저라면 기업에서 전통적으로 하던 일 외에 더 많은 업무를 맡게 될 것입니다.

스타트업 프로젝트 관리자를 위한 기회

빠른 결정과 큰 영향

스타트업 프로젝트 관리에서는 프로세스, 다른 팀, 클라이언트 등의 의존도가 많지 않기 때문에 중요한 결정을 내리기가 매우 쉽습니다. 새로운 동료를 고용하거나, 홈페이지를 변경하거나, 새로운 기능을 추가하거나, 기한을 연장하는 것은 회의나 Slack과의 대화가 될 수 있습니다. 이는 프로젝트 관리자에게 권한을 부여하고 자율성을 생성합니다.

스타트업은 아이디어를 시도하고 전문적으로 성장할 수 있는 좋은 장소입니다. 친구가 회사에서 사용한다고 말한 새로운 프로젝트 관리 도구를 사용해 볼 수 있습니다. Scrum에서 Kanban으로 이동하는 것은 어떻습니까? 무엇이든 더 빠르게 제공할 수 있도록 CEO가 답합니다. Google Analytics를 자연어로 쿼리할 수 있는 새로운 챗봇을 구현하는 것에 대해 어떻게 생각하십니까? 이를 위해 개발자가 필요하지 않습니다. 점심 시간에 CTO가 설명합니다. 기업에서는 이 모든 것이 전담 프로젝트 관리자가 관리하는 별도의 크고 긴 이니셔티브가 될 것입니다.

빨리 끝내다

스타트업의 개발 수명 주기는 기업보다 훨씬 짧습니다. 오늘 아이디어를 내고 다음 주에 무언가를 생산할 수 있습니다. 레거시 코드가 많지 않기 때문에 개발자들은 코드베이스를 리팩토링해야 하고 결과를 빠르게 전달할 수 있어야 한다고 불평하지 않습니다. 이를 통해 고객과 지속적으로 피드백을 주고받고 진정으로 민첩해질 수 있습니다.

적응 또는 피벗 용이

동일한 제공 속도와 종속성 부족으로 인해 스타트업 팀은 빠르게 진로를 변경할 수 있습니다. 유명한 예가 PayPal입니다. "휴대전화용 암호화" 솔루션으로 시작된 이후 처음 15개월 동안 Paypal은 5번의 회전을 했습니다. 지불 시장은 빠르게 변화하고 있었고 PayPal은 Billpoint라는 자체 지불 솔루션을 개발하고 있던 eBay를 능가할 수 있었습니다. PayPal의 민첩성은 eBay 구매자와 판매자에게 더 나은 관심을 끌 수 있게 해 주었고 결국 eBay는 Paypal을 인수하게 되었습니다.

유체 공정

일반적으로 스타트업 내 사람들의 운영 방식에 대한 엄격한 프로세스와 절차는 많지 않습니다. 많은 부분이 상식과 내부 협상에 맡겨져 있습니다. 이것은 위에서 언급한 요점이 실제로 작동하는 주요 이유 중 하나입니다. 즉, 더 빠르게 결정을 내릴 수 있고 수많은 승인이 필요하지 않습니다. 물론, 이것은 필연적으로 절충안이며, 이 기사의 뒷부분에서 보게 될 다른 문제를 야기합니다. 그러나 제품 시장 적합성을 찾고 자금이 더 많고 더 큰 경쟁자들을 압도하려는 스타트업에게는 합리적인 절충안이 있습니다.

스타트업 프로젝트 관리자의 과제

책임이 완전히 정의되지 않음

유동적인 프로세스는 빠르고 직관적인 결정을 가능하게 합니다. 이것은 일이 잘 될 때 순조롭게 진행되지만, 반대로 실수와 혼란스러운 환경을 초래합니다. 세분화하면 프로세스는 본질적으로 체크리스트입니다. 결과를 달성하기 위해 취해야 하는 단계는 무엇입니까? 프로세스는 일반적으로 동료들이 무언가를 돌보지 않은 것에 대해 서로를 비난하기 시작하고 회사가 의사 결정을 명확하게 정의된 단계로 간소화하여 이러한 문제가 발생할 위험을 줄이기 위한 프로세스 생성을 시작할 때 일부 실패의 결과로 발생합니다. 미래.

예를 들어, 새 릴리스가 클라이언트의 웹사이트에 충돌을 일으켰습니다. 회사의 모든 사람들은 다가오는 릴리스에 대해 알고 있었지만 아무도 고객에게 알리지 않았습니다. 프로젝트 관리자 또는 주요 계정 관리자가 고객의 개발 팀에 연락해야 합니까? CTO가 좀 더 적극적이어야 했을까요? 열띤 토론 끝에 관련자들은 다음 번에 특정 직원이 석방되기 전에 특정 조치에 대해 책임을 지도록 하여 이러한 일이 다시는 발생하지 않도록 하는 데 동의했습니다.

이 예는 스타트업이 기업으로 진화하는 방법의 축소판입니다. 스타트업의 복잡성이 날로 증가함에 따라 그러한 결정이 내려지고 일상적인 운영에서 모호성이 제거됩니다. 그러나 그 상태에 도달할 때까지는 대개 고통스러운 실수를 많이 합니다.

약한 교섭력

스타트업의 프로젝트 관리자는 외부 협상에 참여할 가능성이 더 큽니다. 공동 설립자는 피치의 기술 또는 제품 측면을 대표하기 위해 후반 단계의 고객 회의에 귀하를 데려갈 수 있습니다. 회의 중에 많은 질문과 새로운 요구 사항이 발생할 수 있으며 프로젝트 관리자는 너무 빨리 결과물에 동의하지 않도록 해야 합니다. 공동 설립자는 새로운 백로그 항목의 비용을 완전히 깨닫지 못한 채 회의 중에도 잠재 고객을 확보하고 조건에 동의하기를 열망할 수 있습니다. 클라이언트는 당신의 스타트업이 오랜 실적을 갖고 있지 않다는 사실을 이용하여 당신이 합리적으로 제공할 수 있는 것보다 더 많은 것을 약속할 수 있습니다.

프로젝트 관리자는 뒤로 미루고 개발 팀과 함께 새로운 요구 사항을 평가할 시간을 더 요청할 수 있어야 합니다. 팀으로부터 최소한 대략적인 견적을 얻은 후에는 이를 공동 창립자에게 제시하고 거래의 새로운 조건에 동의하는 것이 여전히 타당한지 논의하십시오.

바로 가기는 레거시 문제를 만듭니다.

스타트업에서는 일정한 MVP 모드에 있는 것이 매우 쉽습니다. 프로젝트 관리자로서 개발팀이 더 촉박한 기한에 동의하고 로드맵 항목에 대한 지름길을 택하도록 압력을 가하는 것은 매우 유혹적입니다. 공동 창립자들이 끊임없이 당신의 등 뒤에 있기 때문에 거의 필요한 것 같습니다. 그러나 큰 힘에는 큰 책임이 따른다는 속담처럼. 이 권한을 남용하면 결국 팀은 레거시 문제에 직면하게 됩니다. 그리고 이것은 미래의 언젠가를 의미하지 않습니다. 여전히 시작 모드에 있는 동안 이러한 문제가 발생할 수 있습니다.

예를 들어 회사에서 제품 목록 페이지를 만들기로 결정했다고 가정해 보겠습니다. 결과를 좁히려면 여러 필터가 있어야 합니다. 또한 다양한 속성을 기반으로 한 정렬 옵션이 있어야 합니다. 초기 추정치가 너무 커서 필요한 필터 및 정렬 옵션의 범위를 좁히려고 합니다. 결국, 추정치의 대부분은 전체 시스템인 것으로 밝혀졌습니다. 결과를 검색하고 반환하는 것입니다. 더 간단한 버전을 더 빨리 전달할 수 있는 방법이 있는지 묻습니다. 한 개발자는 월간 구독으로 타사 솔루션을 사용할 것을 제안합니다. 다른 개발자들은 종속성 문제와 레거시 문제에 대해 이야기합니다. MVP를 더 빨리 받고 나중에 프로젝트를 폐기하기로 결정하면 구독이 취소될 수 있기 때문에 완벽하게 들립니다. 스크럼 마스터는 프로젝트가 폐기되지 않은 경우 코드를 다시 작성할 기회가 있는 경우에만 타사 솔루션을 사용하는 데 동의합니다.

그러나 현실은 스크럼 마스터가 나중에 스프린트에서 실제로 기술 부채 작업을 수행하고 때가 되면 이를 방어하지 않는 한 이 합의는 거의 이행되지 않는다는 것입니다. 목록 페이지에 대한 초기 피드백이 긍정적인 경우 MVP는 테스트일 뿐이므로 프로젝트 관리자의 자연스러운 반응은 추가 기능을 개발하는 것입니다. 6개월 후, 새로운 기능을 추가하는 데 비용이 많이 들지만 리팩토링에는 훨씬 더 많은 비용이 들며 더 중요해지고 초기 의도를 흐리게 하는 다른 우선 순위가 있는 시점에 도달합니다.

거짓 긍정

IT 프로젝트 관리의 경우 거짓 긍정은 팀에서 MVP를 개발하고 초기 긍정적 피드백을 제품 시장 적합성의 증거로 받아들이는 경우입니다. 이해 관계자가 "나는 우리 업계에서 가장 큰 고객에게 우리 솔루션을 제안했고 그들은 분명히 우리에게서 그것을 구매할 것이라고 말했습니다." 당신이 그것을 개발하면 그들은 실제로 당신에게서 그것을 사지 않습니다.

가양성(False positive)은 큰 문제이지만 이를 완화할 수 있는 방법이 있습니다. Validately의 설립자인 Steve Cohn은 솔루션에 대한 수요를 검증해야 한다고 제안합니다. 다음 세 가지 신호가 도움이 될 수 있습니다.

1. 전체 솔루션을 제공하기 전에도 고객이 비용을 지출하거나 약정할 의향이 있습니까? 솔루션을 제공하기 전에 계약을 체결하는 것이 가장 좋은 검증일 것입니다.
2. 고객이 솔루션 개발에 시간을 할애할 의향이 있습니까? 시간은 돈이고 모든 사람에게는 끝없는 작업 백로그가 있습니다. 클라이언트가 요구 사항을 파악하는 데 적극적으로 참여하고, 다른 동료를 토론에 참여시키고, MVP를 철저히 테스트하고, 충분한 피드백을 제공할수록 올바른 길을 가고 있을 가능성이 커집니다.
3. 고객이 평판을 사용하여 귀하를 홍보할 의향이 있습니까? 소셜 미디어에서든, 전문적인 행사에서든, 다른 형태로든 고객이 당신을 홍보할 때 그들은 당신에게 그들의 진정한 관심을 확인시켜주는 평판을 빌려주고 있습니다.

이해관계자 관리

스타트업에서 프로젝트 관리자의 가장 중요한 이해 관계자는 일반적으로 공동 창립자입니다. 기회 부분에서 보았듯이 공동 창립자는 상식에 따라 빠른 의사 결정을 내릴 수 있습니다. 그러나 문제는 많은 공동 창업자들이 의사 결정을 본능에 의존하는 경우가 많다는 것입니다. 특정 산업에서 해당 분야의 전문가로 일해 왔으며 이제 자신의 업무에서 직면한 문제를 해결하기 위해 IT 솔루션을 만들기로 결정한 공동 설립자의 경우 특히 그렇습니다.

깊은 시장 지식은 모든 스타트업에 매우 유용하지만 로드맵을 작성할 때에만 의존할 수는 없습니다. 대부분의 신생 기업의 열망은 국제적으로 확장되는 솔루션을 만드는 것입니다. 같은 시장에 여러 회사가 있다고 해도 반드시 같은 방식으로 문제를 해결하는 것은 아닙니다. 공동 설립자는 이전 회사가 어떻게 일했는지에 대해 친밀한 지식을 가지고 있을 수 있지만 다른 회사, 특히 다른 국가에서 동일한 문제를 해결한 방법에 대한 지식으로 해석되지는 않습니다.

공동 창립자는 자신의 신념을 고수하고 자신의 견해에 균형을 맞추기 위해 독립적인 프로젝트 관리자가 필요한 경우가 많습니다. 제품 발견의 초기 단계에서 데이터 기반 의사 결정과 민첩한 개발의 중요성에 대해 공동 창립자를 교육하는 것은 프로젝트 관리자의 임무입니다.

기업의 프로젝트 관리

프로젝트 매니저 ≠ 제품 매니저

스타트업이 성숙하고 대기업이 되면서 업무가 구체화되면서 다양한 직책의 역할이 점점 더 명확해집니다. 기업에서도 프로젝트 관리자와 제품 관리자가 겹치는 경우가 있습니다. 그러나 프로젝트 관리자는 프로젝트의 운영 측면에 더 집중하는 경향이 있는 반면 제품 관리자는 실행을 담당합니다.

프로젝트 관리 사무소(PMO)

회사가 성장함에 따라 프로젝트 포트폴리오도 함께 커집니다. 새로운 프로젝트 관리자가 합류하여 새로운 프로젝트 관리 도구와 방법론을 가져옵니다. 처음에는 상황이 약간 혼란스러워지고 프로젝트 관리 사무실(PMO)이 필요하게 됩니다. PMO는 프로젝트 관리 수명 주기와 관련이 있으며 회사 전체에 모범 사례를 전파하거나 시행할 수 있습니다.

기업의 프로젝트 관리자는 PMO와 인터페이스해야 합니다. 각 PMO는 다르지만 직면할 수 있는 사항은 다음과 같습니다.

• 프로젝트 시작 및 종료를 위한 다양한 양식 작성.
• 검토를 위해 예산을 제출합니다.
• 정기적인 진행 상황 업데이트를 제공합니다.
• 이정표 또는 다양한 프로세스 단계에 대한 승인 받기.

이미 많은 계획과 추적을 수행하고 있는 프로젝트 관리자에게 많은 PMO 요구 사항은 특히 프로젝트 속도가 느려지기 시작하는 경우 불필요한 관료주의처럼 보일 수 있습니다. 이러한 관료주의가 좌절의 원인이 될 수 있지만 사전 예방적 프로젝트 관리자는 오버헤드를 최소화하고 PMO에서 프로젝트의 가치를 추출할 수도 있습니다.

• 보고 요구 사항을 파악하기 위해 초기에 PMO와 협력하십시오. 그런 다음 시간을 절약하기 위해 프로젝트 실행 중에 생성된 재료와 일치시킬 수 있습니다.
• 프로세스 챔피언이 되십시오. 프로젝트 관리자의 삶을 더 쉽게 만들기 위해 프로세스를 변경할 수 있는 방법에 대해 PMO에 피드백을 제공합니다. PMO의 주요 목표 중 하나는 제품 관리자가 효과적이도록 돕는 것입니다.
• 프로젝트에 문제가 발생할 때 PMO를 활용하여 도움을 받으세요. PMO는 모든 프로젝트에 대한 전사적 관점을 가지고 있으며 프로젝트 수행 중에 발생하는 다양한 문제 또는 위험을 처리한 경험이 있습니다. 그들의 지식을 당신에게 유리하게 활용하십시오.

엔터프라이즈 프로젝트 관리자를 위한 기회

믿을 수 있음

기업의 안정성과 장기 계획은 고객과 파트너에게 신뢰를 줍니다. 당신의 회사와 협력하기를 원하는 사람들은 당신이 약속을 이행할 수 있고 당신의 전문 분야에서 많은 경험을 가지고 있는 좋은 실적을 찾고 있습니다. 이것이 기업이 스타트업에 비해 가지는 가장 큰 장점 중 하나입니다. 새로운 고객과 파트너를 쉽게 찾을 수 있습니다.

이 신뢰를 통해 클라이언트와 더 많이 통합할 수 있습니다. 기술 공급업체로서 고객을 지원하고 있으며 고객은 가능한 한 빨리 새로운 기능을 제공할 수 있도록 자체 로드맵을 귀하의 로드맵에 맞게 조정할 수 있습니다. 이러한 관계는 스타트업이 매우 불안정하고 신뢰하기 어렵기 때문에 스타트업이 달성하기 매우 어려울 것입니다.

요구 사항을 더 쉽게 수집

기업은 스타트업에 비해 시장에서 훨씬 더 큰 존재감을 가지고 있습니다. 회사가 성장하고 업무가 점점 더 구체적이 되면서 점점 더 많은 전문 인력을 고용하고 있습니다. 동시에, 비전을 유지하기 위해 점점 더 많은 노련한 최고 경영진이 회사에 합류합니다. 이 모든 사람들은 엄청난 시장 통찰력을 가져오며, 이는 프로젝트 관리자가 사용자 요구 사항을 수집하는 데 매우 쉽게 액세스하고 활용할 수 있습니다.

이것은 PM의 개인 개발에도 큰 이점이 될 수 있습니다. 많은 수의 연락처를 보유하면 기업 내 다른 이해 관계자에게 영향을 미치거나 프로젝트가 회사의 상위 계층에서 충분한 관심을 받을 수 있도록 해야 할 때마다 연락할 수 있습니다.

사용자 요구 사항에 도움을 줄 수 있는 또 다른 동료 그룹은 영업, 계정 관리 또는 고객 지원 팀에서 찾을 수 있습니다. 그곳에서 일하는 사람들은 매일 클라이언트를 접하고 사용자 요구 사항과 불만 사항에 대해 많은 피드백을 제공할 수 있습니다. 그러나 이 피드백이 나오는 맥락을 항상 염두에 두십시오. 예를 들어 고객 지원 팀은 제품을 사용하는 사람들을 상대하고 영업 사원과 계정 관리자는 구매 결정을 내리지만 실제로 소프트웨어를 사용하지 않는 고위 경영진을 상대할 수 있습니다.

구축 또는 구매

스타트업에게 없는 기회는 인수합병(M&A)을 통한 성장이다. 2018년에는 이미 전 세계적으로 기록적인 M&A 거래가 있었습니다. 이러한 추세의 큰 부분은 최근 AT&T가 Time Warner를 850억 달러에 인수한 것과 같은 초대형 거래입니다. 그러나 하버드 비즈니스 리뷰(Harvard Business Review)의 연구에 따르면 거래의 일부는 가치 평가 측면에서 작으며 더 나은 수익을 창출합니다. 단일 지점 솔루션을 갖춘 소규모 신생 기업이 많이 있으며 기업의 프로젝트 관리자는 솔루션을 복사하는 대신 구매하는 것이 합리적일 수 있다는 점을 명심해야 합니다. 프로젝트 관리자는 그러한 시나리오에 대한 의사 결정자가 아닐 수도 있지만 이 옵션을 테이블로 가져오는 사람은 될 수 있습니다.

엔터프라이즈 프로젝트 관리자의 과제

승인 시간이 더 오래 걸립니다.

회사가 성장함에 따라 보고 계층도 함께 커집니다. 여러 부서, 프로세스 및 절차가 있습니다. 브랜드 가이드라인이 만들어집니다. 때때로 신생 기업에서 간과되는 법적 위험을 고려해야 합니다. 새로운 파트너와의 공동 보도 자료 견적은 필요한 모든 승인을 수집하는 데 몇 주가 걸릴 수 있습니다.

이것은 프로젝트 관리자가 훨씬 더 미리 계획하고 더 부지런해야 한다는 것을 의미합니다. 그러나 가능한 한 빨리 모든 승인을 받아야 하는 임시 및 예상치 못한 상황이 항상 있습니다. 이러한 상황에서 다른 부서와 좋은 관계를 유지하는 것은 큰 가치가 있습니다. 도움이 필요한 다른 사람들을 도울 수 있는 프로젝트 관리자는 그 대가로 동료들로부터 호의를 더 많이 받을 것입니다.

잘못된 의사소통

"아무것도 가정하지 않는다"는 프로젝트 관리자의 모토가 되어야 합니다. 회사 내에서 복잡성이 증가함에 따라 프로젝트 팀 내부 및 외부에서 효과적인 의사 소통을 유지하는 측면에서 프로젝트 관리자의 작업이 더 어려워집니다. 예제 시나리오를 살펴보겠습니다.

팀은 작업 중인 새 기능에 대한 몇 가지 새 아이콘이 필요합니다. 점심 시간에 우연히 디자인 팀 리더를 만나 아이콘에 대해 이야기합니다. 그녀는 실제로 지금 비슷한 아이콘을 작업 중이며 곧 준비할 것이라고 말했습니다. 다음 날 스탠드업 동안 정보를 팀에 전달하고 아이콘이 필요할 때 디자인 팀에 연락하도록 지시합니다. 문제의 기능은 4주 안에 출시될 예정이므로 모든 사람들은 그 시기에 아이콘이 준비될 것이라고 가정합니다. 개발자는 아이콘에 자리 표시자를 배치하고 QA 중에만 누군가가 아이콘을 교체하는 것을 잊었다는 것을 알아차렸습니다. 그들은 다른 긴급한 작업으로 인해 해당 아이콘 생성을 실제로 연기한 디자인 팀에 연락하기 위해 분주합니다. 팀에서 아무도 그들에게 연락하지 않았으며 디자인 팀 리더는 더 이상 아이콘이 필요하지 않을 것이라고 가정했습니다. 브랜드 가이드라인은 임의의 아이콘을 사용하여 프로덕션에 가는 것을 허용하지 않으며 팀은 배포할 수 없는 완성된 기능으로 그곳에 앉아 있습니다.

기업에서 프로젝트 관리자라는 직업은 오해의 소지가 있는 그런 순간들로 가득 차 있습니다. 여기에서 사용할 수 있는 두 가지 전략이 있습니다.

• 회고전을 사용하여 새로운 프로세스가 미래에 그러한 실수를 방지하는 데 도움이 될 수 있는지 팀과 함께 알아내십시오. 주간 검토 및 후속 조치를 통해 다른 팀의 모든 종속성 목록을 유지하는 것이 이 시나리오의 답이 될 수 있습니다.
• 의사 소통이 과도합니다. 일반적으로 프로젝트 관리자가 필요하다고 생각하는 것보다 더 많이 의사 소통하는 것은 좋은 전략입니다. 엘리베이터를 기다리거나 차를 타러 가는 동안 사람들과 체크인을 하고, 그 짧은 순간에 빠른 업데이트를 요청하는 습관을 들이십시오. 균열을 통해 미끄러지는 것을 줄이는 좋은 방법입니다.

천천히 움직이고 아무것도 부수지 마십시오

코드베이스가 오래될수록 새로운 기능을 개발하기가 더 어려워집니다. 프로젝트 관리자는 소규모 신생 기업이 새로운 혁신을 통해 시장에 더 빨리 출시하고 경쟁에서 앞서고 있다는 사실을 알아차리기 시작할 수 있습니다.

소규모 신생 기업의 도전에 맞서는 동시에 기업은 비슷한 규모의 경쟁자도 경계해야 합니다. 신생 기업이 성숙해짐에 따라 단일 지점 솔루션은 다양한 기능과 사용 사례를 가진 본격적인 플랫폼이 됩니다. 다른 거대 경쟁 기업과의 기능 동등성이 문제가 됩니다.

기업의 프로젝트 관리자는 혁신에 참여하고 고객을 위한 새로운 가치 제안을 생성할지 아니면 경쟁자와 동등한 기능을 달성하기 위해 노력할지 결정해야 합니다. 그러나 대부분의 경우 이러한 결정을 스스로 내릴 수 없으며 이러한 결정을 내리기 위해 여러 이해 관계자에게 영향을 미치도록 노력해야 합니다. 이는 특히 이해 관계자가 디지털에 익숙하지 않고 구축하도록 설득하려는 기능에 익숙하지 않은 경우 좌절감을 줄 수 있습니다.

결론

이 기사에서 우리는 스타트업과 기업의 기본 메커니즘이 프로젝트 관리자에게 기회와 도전을 어떻게 창출하는지 논의했습니다. 스타트업에서 프로젝트 관리자는 제품 관리자의 많은 기능을 수행할 가능성이 높지만 기업에서는 두 역할이 명확하게 구분됩니다. 각 회사는 고유하며 논의된 모든 주제가 모든 상황에 적용되는 것은 아니므로 미묘한 환경에서는 프로젝트 관리자가 다양한 프로젝트 관리 자질과 기술을 활용해야 합니다.

요약하자면, 스타트업은 유동적인 프로세스를 가지고 있고 프로젝트 관리자는 빠른 결정을 내릴 수 있고 전체 회사에 큰 영향을 미칠 수 있습니다. 개발 수명 주기가 훨씬 짧기 때문에 프로젝트 관리자가 민첩성을 유지하고 변화하는 시장 상황에 적응할 수 있습니다.

스타트업의 프로젝트 관리자도 상당한 어려움에 직면해 있습니다. 완전히 정의되지 않은 책임은 스타트업이 성장함에 따라 많은 문제를 일으킬 수 있습니다. 클라이언트와 공동 창립자는 팀이 합리적으로 제공할 수 있는 것보다 더 많은 것을 약속하도록 프로젝트 관리자를 압박할 수 있습니다. 그 후 로드맵에 다양한 지름길을 넣을 수 있으며, 이는 향후 레거시 문제로 이어집니다. 스타트업의 공동 창업자들은 로드맵을 정의하는 데 매우 적극적입니다. 그러나 그들의 확신은 오탐으로 이어질 수 있으며 프로젝트 관리자는 이러한 문제를 완화하기 위해 데이터 중심적이고 민첩해야 합니다.

기업 측면에서 프로젝트 관리자는 회사의 신뢰성과 실적을 활용하여 외부 당사자와 좋은 업무 관계를 구축할 수 있습니다. 정기적으로 고객과 소통하는 노련한 경영진과 동료로부터 요구 사항을 수집하는 것이 더 쉽습니다. 마지막으로 프로젝트 관리 사무실은 제한적이지만 프로젝트 실행 중에 발생하는 문제를 완화하고 위험을 관리하는 데 도움이 될 수 있습니다.

엔터프라이즈 프로젝트 관리의 과제는 불가피하게 회사 규모와 관련이 있습니다. 다양한 승인 및 승인은 프로젝트 관리자가 프로젝트 실행 속도를 늦추지 않도록 매우 부지런히 계획하고 PMO와 협력해야 함을 의미합니다. 점점 더 많은 사람과 부서가 관여함에 따라 잘못된 의사 소통이 발생할 가능성이 높으며 올바른 프로세스를 배치하여 이를 완화해야 합니다. 마지막으로 개발 수명 주기가 길어지고 프로젝트 관리자는 시장에서 스타트업 및 다른 기업과 경쟁해야 합니다.

이것이 프로젝트 관리자가 작업하는 두 환경 간의 핵심 차이점입니다. 이러한 문제를 이해함으로써 한 환경에서 다른 환경으로 이동하면서 직면할 수 있는 상황을 더 잘 예측할 수 있습니다.