요금 코드에 따라 사전 요금 부과

이 문서는 "트렌치에서" 컬렉션의 일부입니다. 프로젝트 관리 시스템 또는 작업표 시스템에 대한 organization 요금 코드 구조를 정의하는 모범 사례를 설명합니다.

이 문서의 Word 버전을 다운로드하려면 충전 코드에서 미리 충전을 참조하세요.

더 많은 문서를 보려면 "참호에서" 백서를 참조하세요.

요금 코드에 따라 사전 요금 부과

조직에서 프로젝트 관리 시스템 또는 작업표 시스템에 대한 요금 코드 구조를 정의할 수 있도록 도와달라는 요청을 자주 받습니다. 모든 organization 다르고 요구 사항이 다르면 다양한 유형의 요금이 부과되는 것은 사실이지만, 지난 몇 년 동안 보편적인 몇 가지 일반적인 관행이 있습니다.

더 적은 질문, 더 이상

아무도 관료를 좋아하지 않으므로 청구 코드 구조가 복잡할수록 사람들이 정확한 보고서를 작성할 가능성이 줄어듭니다. 예를 들어, 선택할 수 있는 긴 플랫 목록에 10,000개의 요금 코드 목록을 만든다고 상상해 보십시오. 이 특정 작업표 또는 프로젝트 업데이트에 대한 올바른 선택을 찾기 전에 드롭다운 목록에서 가능한 각 항목을 검사하여 한 시간 동안 스크롤해야 할 수 있습니다. 그런 다음 목록의 나머지 부분을 스크롤하여 좀 더 정확하지 않은 항목을 찾지 못했는지 확인해야 합니다.

바보가 되지 맙시다. 아무도 그렇게하지 않습니다. 그들은 합리적으로 가까운 것 같다 첫 번째 항목을 가지고 그것을 선택합니다. 실패하면 모든 시간이 결국 "999:기타"를 담당하게 됩니다.

따라서 목록을 간단하게 만듭니다. 이상적으로는 스크롤이 전혀 필요하지 않지만 단일 화면 또는 한 번 더 클릭으로 볼 수 있어야 합니다. 즉, 최대 20~30가지 옵션 중에서만 선택할 수 있습니다. 이 경우 는 더 적습니다.

관리가 훨씬 더 세부적인 정보를 얻기로 결정한 경우 더 많은 세부 사항과 적은 정확도보다 더 정확하고 세부적인 정보를 얻는 것이 더 낫다는 것을 상기시켜 줍니다.

이미 알고 있는 내용을 묻지 마세요.

각 부서 또는 각 프로젝트에 대해 동일한 요금 코드가 있는 많은 요금 코드 구조를 살펴보았습니다. 그러나 사람들이 이미 프로젝트를 선택하라는 요청을 받고 있고 예를 들어 모임에 참가하는 경우 품목이 "이 프로젝트의 모임"이어야 한다는 것을 알고 있기 때문에 요금 목록을 여러 모임 항목으로 오염시키는 이유는 무엇인가요? 부서와 동일한 논리가 유지됩니다. 각 부서에 속한 직원 목록이 있는 경우 해당 부서가 어떤 부서에 속해 있는지 이미 알고 있습니다. "영업 부서 회의", "기술 부서 회의" 및 "마케팅 부서 회의"로 요금 목록을 오염시키는 이유 "모임"이라는 항목을 하나 만드면 직원의 부서와 모임의 대상에 대한 프로젝트를 추론할 수 있습니다.

더 나은 해결을 위해 해결

프로젝트 및 작업표에 적절한 수준의 해상도를 선택하는 것은 일반적인 과제입니다. 이러한 조건으로 작업을 관리하려는 수준에 대해 생각해 보세요. 1) 데이터를 수집하는 시간보다 데이터에 더 많은 가치가 있어야 하므로 하루 종일 보고하는 경우 실제로 어떤 작업을 수행할 수 있을까요? 2) 결정을 내릴 준비가 된 수준에서 작업합니다. 3) 입력하는 것이 복잡할수록 정확한 데이터를 얻을 가능성이 줄어듭니다. 4) 가능하면 모든 사용자가 동일한 수준의 해상도로 작업하여 10분 길이의 작업에서 하나의 그룹을 관리하지 않고 3일 길이의 작업에서 다른 그룹을 관리하지 않도록 합니다. 많은 사람들에게 주어진 날에 대해 3-5 줄의 세부 사항을 보고 할 수 있다는 것은 많은 세부 사항입니다.

데이터 조건 지정

어떤 사람들은 최종 사용자가 같은 질문에 반복해서 대답하게 할 것입니다. 예를 들어 "R&D"에 대한 열이 있는 시스템은 이 요금이 R&D 세금 공제에 적합한 요금이거나 그렇지 않다는 것을 의미합니다. 그러나 각 사용자의 작업표 줄이 아닌 작업 자체에 자격을 연결할 수 있어야 합니다. 또한 일부 사용자가 적격하다고 생각하고 일부 사용자가 적합하지 않다고 생각하면 어떻게 해야 하나요? 이 시나리오는 "R&D에 대한 디자인 적격" 및 "R&D에 적합하지 않은 디자인"과 같은 예제에서도 수행됩니다. 이렇게 하면 반환 값이 없는 충전 코드 수가 두 배로 늘어나게 됩니다. R&D에 있는 누군가가 각 드롭다운 값을 적격 여부로 플래그 지정하고 최종 사용자에게 매주 알아내도록 계속 요청할 필요가 없습니다.

계층적

더 나은 프로젝트 및 작업표 시스템을 사용하면 데이터를 계층적으로 표시할 수 있습니다. 가능한 선택 사항이 많을 수밖에 없는 경우 계층 구조를 구축하면 많은 데이터를 더 쉽게 삼킬 수 있습니다. 각 수준에서 선택할 최대 5-10개 항목을 생각해 보세요. 그리고 수십 개의 레벨을 만들고 싶은 유혹을 받지 마십시오. 3-4 수준 계층 구조를 만드는 것은 대부분의 옵션을 처리할 수 있어야 합니다. 결국 4단계 시스템의 수준당 10개 항목은 10,000개 가능한 요금입니다. 프로젝트가 그보다 더 복잡합니까?

덜 표시

사용자에게 줄 질문과 선택 항목이 적을수록 더 나은 선택이 될 수 있습니다. 백그라운드에서 답변할 수 있는 항목이 있는 경우 작업표에서 사용자에게 묻지 않도록 시도합니다. 목표는 가능한 한 많은 데이터를 수집하는 것이 아니라 가능한 한 정확한 그림을 수집하는 것이며, 최종 사용자를 데이터, 질문 및 옵션으로부터 격리하는 경우 더 잘 할 수 있습니다.

해당 데이터로 무엇을 하시겠습니까?

나는 종종 그들이 내가 제안하는 것보다 "훨씬 더 세부 사항"이 필요하다고 말하고 내 응답은 항상 동일합니다 : "당신은 그것으로 무엇을 할 것인가?" 작업 기반 작업표 데이터를 수집하는 목적은 더 나은 비즈니스 의사 결정을 내리는 것이므로, 저는 종종 중간 관리자에게 더 많은 세부 사항이 있는 경우 더 잘 할 수 있다고 생각하기 때문에 지금 내릴 수 없는 비즈니스 결정을 물어봅니다. 그런 식으로 정보를 살펴보기 시작하면 더 적은 정보가 필요할 수 있습니다. 모임이나 전송 중 또는 오버헤드 작업에서 소요된 총 시간만 파악하는 것만으로도 해당 작업의 모든 작업을 파악하는 것보다 충분할 수 있습니다.

드릴 심층... 하지만 반드시 필요한 경우에만

작업표 분석을 시작하여 모든 시간이 어디로 가는지 파악하기 시작하면 불균형한 결과를 찾을 수 있습니다. 기대치를 무시하는 비정상적으로 높은 시간 비율을 발견한 경우 조금 더 깊이 드릴합니다. 그러나 너무 깊지 않습니다. 해당 요금에 대한 세부 정보 계층을 한 번 더 추가하고 몇 주 후에 어떤 데이터를 가져오는지 확인합니다. "모임"과 같은 단일 요금 코드를 발생할 수 있는 모든 유형의 모임이 있는 50개의 새로운 요금 코드로 확장하려는 유혹이 있습니다. 이 유혹에 저항하고 대신 1 충전 코드를 5 또는 6으로 변경하십시오. 세부 정보를 얻지 못하거나 여전히 불균형한 결과가 있는 경우 좀 더 깊이 파고들어 보세요.

클린 집 보관

요금 목록은 크기가 증가하는 경향이 있지만 결코 감소하지 않습니다. 정기적으로 검토하고 bloat을 제거하는 것이 좋습니다. 이렇게 하면 더 정확한 정보를 계속 얻고 시간을 잃고 있는 영역을 식별할 가능성이 더 높습니다.

결론

프로젝트 일정 또는 작업표 시스템에 대한 요금 코드 관리는 데이터를 계산할 수 있는 효율적인 시스템 또는 정의가 너무 많고 정확도가 부족한 시스템 간에 차이를 만들 수 있습니다. 충전 코드 구조를 디자인할 때는 더 적은 것부터 시작하는 것이 좋습니다. 더 많은 세부 정보를 실행 취소하고 과부하가 많은 사용자를 위해 더 간단하게 만드는 것보다 필요한 경우 나중에 더 많은 세부 정보를 추가하는 것이 훨씬 쉽습니다.

작성자 정보

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 관련 문서를 읽으려면 HMS의 EPM 지침 사이트(https://www.epmguidance.com/?page_id=39)를 참조하세요.