파일럿이 탑승했나요?

"기내에 조종사가 있다면 전화 버튼을 울리시겠습니까?" 승객이 듣고 싶어하지 않는 것입니다. 저는 2013년 12월에 일어난 것과 같은 참된 사건에서 놀라운 뉴스 기사를 다시 읽었습니다. 아이오와 주 데스 모인스에서 비행기를 타고 출발한 후, 부조종사들은 비상 사태를 겪었고, 부조종사들은 기내 조종사들에게 요청을 했습니다. 미 공군의 B1 폭격기 조종사인 마크 곤골 대령이 침입에 나섰습니다. 비행기, 승객, 승무원은 모두 안전하게 착륙했습니다.

그것은 좋은 이야기이지만 최근에 다시 읽으려고 돌아가는 것은 매우 다른 무언가에 의해 트리거되었습니다. 우리의 잠재 클라이언트는 최근에 전화를 걸어 엔터프라이즈 프로젝트 작업표 소프트웨어를 "파일럿"할 수 있는지 물었습니다. 이러한 종류의 전화는 항상 나를 일시 중지합니다. 항공기에 타고 있는 누군가가 "조종사"라고 말하는 경우, 우리는 모두 의미에 대해 매우 명확하지만 소프트웨어 옵션을 평가하는 사람이 "파일럿"이라고 말하면 잘 모르겠습니다.

소프트웨어 세계에서 "파일럿"이라는 용어는 종종 "개념 증명"과 같은 다른 도전적인 평가 방법과 혼합됩니다. 이러한 용어의 의미와 자체 엔터프라이즈 평가 프로세스에서 해당 용어를 가장 잘 사용할 수 있는 방법을 살펴보겠습니다.

개념 증명

이 용어는 수년 전으로 거슬러 올라가며 전기 공학 분야에서 인기가 있습니다. "브레드 보딩"은 회로가 가능한지 확인하기 위해 수행되었으며 생산을 위해 회로를 만들기 시작하지 않았습니다. 개념 증명으로, 프로덕션 회로를 만드는 것보다 랩 벤치에서 더 많은 시간을 보낼 수 있지만, 앞에서 작업 중인 회로 기판에 대한 유일한 손상은 있을 수 있습니다. 전기 회로가 원하는 결과를 제공할 수 있음을 증명하는 저렴하고 위험이 낮은 방법이었습니다.

소프트웨어 측면에서 개념 증명은 무언가를 증명하도록 설계되어야 합니다. 잠재 고객이 엔터프라이즈 프로젝트 관리 또는 엔터프라이즈 작업표 소프트웨어에 대한 개념 증명을 제공할 수 있는지 묻기 위해 를 호출할 때 항상 "어떤 개념을 증명하시겠습니까?"

이는 일반적으로 침묵과 혼란스러운 표현으로 충족됩니다.

개념 증명을 수행하려고 하고 증명하려는 내용에 대한 개념이 없다면 성공 또는 실패인지 어떻게 알 수 있습니까? 물론 전혀 방법이 없습니다.

왜, 당신은 물어, 누군가가 심지어 개념 증명을하고 싶어? 가장 일반적인 대답은 요청자가 조사 중인 소프트웨어를 구현하기 위해 관리에서 필요한 바이인을 가지고 있지 않을 것이며, 단지 그들 앞에서 실행되는 경우 아이디어와 사랑에 빠지고 배포해야한다는 데 동의하기를 바랍니다. 이 경우 "증명"은 관리에 있으며 "개념"은 엔터프라이즈 소프트웨어의 전체 아이디어입니다.

엔터프라이즈 프로젝트와 작업표 소프트웨어가 그들에게 적합하다는 것을 경영진에게 쉽게 설득할 수 있다면, 우리는 훨씬 더 많은 것을 배포할 것입니다.

이 방법의 문제는 이 개념 증명 instance 배포하기 위해 수행할 수 있는 작업은 엔터프라이즈 시스템의 프로덕션 배포에 대해 얻을 수 있는 것과 동일한 지원을 받을 가능성이 매우 낮다는 것입니다. organization 작업표 또는 프로젝트 관리 시스템과 같은 엔터프라이즈 시스템을 배포하는 경우 성공을 위해 필요한 여러 가지 사항이 있습니다. 첫째, 배포에 연루된 organization 모든 측면에 대한 관리 및 라인 담당자의 입력이 필요합니다. 다음으로, 구성 시간, 다른 엔터프라이즈 시스템에 연결하기 위한 기술 서비스의 지원, 관리 후원, 교육 시간 및 예, 돈이 필요합니다.

이러한 항목이 없다면 개념 증명에서 완료할 수 있는 시스템은 무엇인가요? 그것은 당신이 최선을 원하는 무엇의 그림자가 될 것입니다. 오늘날의 클라우드 내 시대에는 서버 및 소프트웨어 구입에 대해 걱정할 필요가 없도록 완전히 호스트된 시스템에 액세스할 수 있지만 시스템을 설치하는 것만으로도 개념 증명 시스템의 기본 배포를 만드는 데 필요한 작업의 일부일 수 있습니다.

organization 전체 organization 영향을 미칠 수있는 무언가의 구현을 위해 많은 돈과 자원을 바치는 것을 주저하는 이유를 쉽게 이해할 수 있습니다. 그것은 고위험 운동입니다. 엔터프라이즈 프로젝트 관리 소프트웨어의 이점에 대해서만 이야기하는 경향이 있지만 동일한 프로젝트가 잘못되었다는 것은 똑같이 부정적인 영향을 미칠 수 있다고 상상하기 쉽습니다. 따라서 위험을 완화하는 것은 명백한 관심사입니다. 그러나 실제 과제가 시스템의 이점 관리를 설득하는 것이라면, 분명히 이 작업을 수행하는 더 나은 방법이 있습니다. HMS Software에서는 다음 기술 중 몇 가지에 집중했습니다.

  1. 실제 기존 클라이언트와 통신합니다.

    우리는 매우 만족에 의해 큰 몇 가지 훌륭한 고객을 가지고 여기에 축복입니다. 새 잠재 클라이언트가 무엇을 얻고 있는지에 대한 우려가 있는 경우 기존 클라이언트와 함께 해당 organization 가져옵니다. 대부분의 경우 기존 클라이언트는 직접 모임을 개최할 수 있을 만큼 충분히 관대했습니다. 다른 경우, 그들은 우리가 의도적으로 일부가되지 않는 서로 통화를합니다. 기존 클라이언트가 좋은 소식과 과제를 모두 공유하는 것이 좋습니다.

  2. 우리가 그것을 증명하자.

    실제로 증명이 필요한 개념이 있다면 증명해 주세요. 일부 구현의 일부 측면을 먼저 입증해야 하는 정당한 이유가 있습니다. 아마도 배포에는 매우 많은 양의 특정 종류의 데이터가 있을 것입니다. 예를 들어, 특히 큰 프로젝트 로드로 작동하는 솔루션을 보여 달라는 요청을 받았습니다. 특정 브라우저 또는 특정 데이터베이스에서 작업하거나 특정 외부 시스템의 특정 버전에 연결하는 소프트웨어를 보여 달라는 요청을 받았습니다. 그것이 평가를 차단하는 개념의 종류라면, 그 도전을 극복 할 수있는 가장 좋은 사람들은 주제 전문가입니다.

  3. 당신은 그것으로 몇 가지 교육을 할 수 있습니다.

    잠재 클라이언트가 직원이 사용하는 데이터로 작동하는 시스템을 절대적으로 보여줘야 하는 경우, Microsoft는 호스트된 시스템에 데이터를 로드한 다음, 최소한 클라이언트가 원하는 대로 시스템을 구성하고 참여할 사람들을 교육하는 데 도움을 드립니다. 우리는 데모 자체를 돕기 위해 회사로 데려오는 것을 매우 선호하지만, 불가능한 경우 관련 사람들이 사용할 스크립트 또는 데모를 검토하고 조정하거나 사람들을 교육하여 배달하도록 요청합니다.

파일럿이 필요할 때 파일럿은 어디에 있나요?

그렇다면 파일럿 프로젝트는 어떨까요? 그건 더 나은, 오른쪽? 그것은 될 수 있습니다. 엔터프라이즈 작업표 또는 엔터프라이즈 프로젝트 관리 시스템의 파일럿 배포를 설정하라는 요청을 받은 경우 먼저 목표를 결정해야 합니다. 개념 증명에 대한 목표가 전부라면 파일럿 프로그램에 전혀 포함되지 않습니다.

파일럿 프로젝트는 실제 프로덕션 내 라이브 배포입니다. 일반적으로 평가되는 시스템에 대해 고려되는 총 사용자 기반의 하위 집합이 포함되므로 파일럿 프로그램에 다소 시간이 걸릴 수 있습니다. 전체 대상 사용자 기반의 요구 사항은 처음부터 고려되지만 파일럿 프로그램은 파일럿 사용자를 위한 실제 구현을 수행하는 데 중점을 둡니다. 실제로 프로젝트를 관리하거나 실제로 작업표를 새 시스템으로 채웁니다.

데이터의 볼륨 또는 복잡성을 제외하고 전체 프로덕션 배포가 직면하게 될 것과 동일한 과제도 파일럿 구현에 의해 직면됩니다. 내가 본 파일럿 프로젝트의 가장 일반적인 과제는 후원의 부족, 부족한 예산, 시간과 자원, 그리고 아마도 최악의, 파일럿 프로젝트가 성공했는지 여부를 결정하는 방법을 알고 명확한 목표의 부족을 포함한다.

이것은 파일럿 프로젝트가 나쁘다는 것을 말하는 것이 아닙니다. 파일럿을 수행하는 것은 매우 합리적일 수 있으며 불완전하거나 잘못 구성된 배포로 전체 organization 영향을 미칠 위험을 완화하는 역할을 할 수 있습니다. 그러나 파일럿 프로젝트를 성공적으로 만드는 데는 몇 가지 생각이 필요합니다.

최근에는 공공 부문 organization 대한 상당한 규모의 배포 작업을 시작했습니다. 연습에 대해 만족하는 것은 organization 이미 평가를 완료해야 하는 모든 시간을 보냈다는 것입니다. 그들은 엔터프라이즈 시스템을 선택했습니다. 다행히도, 그것은 우리의 것입니다. 지난 1년 동안 평가 팀과 협력하여 기술적인 질문에 대한 답변을 확인했지만, 이제는 이 organization 사람들의 일상 프로세스에 미치는 영향에 초점을 맞추고 있습니다.

그들은 우리가 상당한 동안, 여전히 전체 그룹의 약 10 %인 그룹과 함께 6 개월 동안 일할 것을 제안했다. 적절한 예산이 있고, 파일럿은 최고 수준의 관리를 지원하며, 이와 같은 배포에서 일반적으로 수행하는 모든 작업을 지원할 수 있는 충분한 시간을 확보할 수 있습니다. 이 프로젝트 추적 및 작업표 환경에 배치될 그룹은 당분간 프로덕션 환경에서 작업하므로 테스트가 아닙니다. 이는 "사용해 보기" 연습이 아니라 배포의 첫 번째 단계와 비슷합니다. 이러한 모든 요소를 갖춘 우리는 올해 말 성공적인 결과에 대한 모든 기대를 가지고 있습니다.

래핑업

파일럿 및 개념 증명 프로젝트는 엔터프라이즈 소프트웨어의 실제 생활이지만, 미래에 프로젝트가 있는 경우 관련된 모든 사람에게 몇 가지 주요 성공 요인을 지적하는 데 도움이 될 수 있습니다.

  1. 먼저 목표가 명확하게 명시되어 있는지 확인합니다.

  2. 다음으로, 경영진이 필요한 것을 이해하고 이러한 목표를 달성하기 위해 돈, 자원 및 시간 측면에서 지원하도록 합니다.

  3. 마지막으로 프로젝트 계획을 만들고 포트폴리오의 다른 프로젝트와 마찬가지로 관리해야 합니다.

만든 이 정보

Chris Vandersluis는 캐나다에 본사를 둔 HMS Software인 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 관련 문서를 읽으려면 그의 EPM 지침 블로그(https://www.epmguidance.com/?page_id=39)를 참조하세요.