복잡한 소프트웨어 없이 여러 프로젝트를 관리하는 방법

내려야 할 결정에서부터 시작하기

형식을 선택하기 전에 개요가 답을 주어야 하는 질문들을 적어보세요. 예를 들면 다음과 같습니다: 다음 마일스톤을 향해 순조롭게 진행 중인 프로젝트는 무엇인가? 이번 주에 주의가 필요한 프로젝트는 무엇인가? 한 프로젝트가 다른 프로젝트를 기다리고 있는가? 내가 내려야 할 결정은 무엇인가?

이러한 질문들은 개요의 초점을 명확하게 유지해 줍니다. 모든 작업, 메모, 대화 내용까지 전부 추가하면 프로젝트 전체를 아우르는 그림이 묻혀버립니다. 세부적인 작업 목록은 실제 업무가 일어나는 곳에 두고, 개요는 여러 프로젝트를 조율하는 데 도움이 되는 몇 가지 핵심 사실을 보여주는 용도로만 사용하세요.

이러한 구분은 프로젝트 관리에 관한 엄격한 규칙이 아니라 실용적인 방법입니다. Atlassian의 프로젝트 상태 보고서 가이드에서는 진행 상황, 향후 작업, 해결 과제 또는 장애 요인을 보고할 것을 권장합니다. 여러 프로젝트를 다룰 때 유용한 확장 방식은 이러한 필드들을 나란히 놓고 한눈에 훑어볼 수 있을 만큼 일관되게 만드는 것입니다.

한 페이지 프로젝트 개요 구축하기

프로젝트당 하나의 행이나 카드를 만듭니다. 시작점으로 다음 필드들을 활용해 보세요:

프로젝트명과 목표 결과, 다음으로 관찰 가능한 마일스톤과 목표 날짜, 현재 상태, 변경 사항을 증명하는 내용, 다음 조치와 담당자, 장애 요인 또는 종속성, 그리고 해당 행이 마지막으로 확인된 날짜를 기록합니다. 모든 프로젝트에서 필드 순서를 동일하게 유지하세요.

마일스톤은 "검토자에게 초안 공유 완료" 또는 "행사 장소 확정"처럼 다른 사람도 완료되었음을 명확히 알아볼 수 있는 것이어야 합니다. "진행 상황 진척"은 체크포인트가 될 수 없습니다. 프로젝트의 다음 결정이나 전달에 중요한 마일스톤을 선택하세요. 사소한 작업이 길게 나열되면 개요를 읽기가 더 어려워집니다.

Kanban University의 칸반 기법 가이드에서는 작업과 작업 흐름의 이동을 시각화하는 것이 눈에 보이지 않던 업무를 더 쉽게 이해할 수 있게 만드는 방법이라고 설명합니다. 간단한 개요는 이러한 아이디어를 프로젝트 수준에 적용한 것으로, 현재 상태와 작업이 지연되고 있는 지점을 보여줍니다. 전체 칸반 시스템을 도입할 필요는 없습니다.

누구나 일관되게 적용할 수 있는 상태 라벨 사용하기

색상 라벨은 팀원들이 그 의미를 명확히 이해할 때만 유용합니다. 개요 옆에 간단한 정의를 적어두고, 전체 프로젝트에 대한 막연한 느낌이 아닌 '다음 마일스톤'을 기준으로 적용하세요. 예를 들면 다음과 같습니다:

정상 진행(On track): 다음 마일스톤이 목표 날짜까지 달성될 것으로 예상되며, 현재 이를 위협하는 미해결 문제가 없음.

주의 필요(Watch): 마일스톤에 영향을 미칠 수 있는 구체적인 우려 사항이 있으나, 다음 대응 단계가 확인됨.

진행 차단(Blocked): 명시된 문제, 결정 또는 종속성이 해결될 때까지 진행을 계속할 수 없음.

이 라벨들은 제안된 업무 규칙일 뿐 공식적인 표준은 아닙니다. 개요를 업데이트하거나 사용할 사람들과 함께 라벨의 의미를 합의하세요. 프로젝트가 "주의 필요"로 표시된 경우 그 이유와 "정상 진행"으로 되돌리기 위한 조치를 포함해야 합니다. "진행 차단"인 경우 필요한 지원과 후속 조치를 취할 담당자를 지정하십시오. 설명 없는 라벨은 심각한 문제를 단순한 불확실성처럼 보이게 만들 수 있습니다.

성격이 크게 다른 여러 프로젝트에 걸쳐 진행률(%)을 주요 지표로 삼는 것은 피하세요. "80% 완료"는 디자인, 이벤트, 연구 과제에서 완전히 다른 의미를 가질 수 있습니다. 날짜가 명시된 체크포인트와 눈으로 확인할 수 있는 증거가 독자에게 훨씬 구체적인 판단 기준을 제공합니다. 이는 백분율이 결코 유용하지 않다는 뜻이 아니라 실용적인 비교를 위한 선택입니다. 작업량을 일관되게 측정할 수 있는 단일 프로젝트 내에서는 진행률이 도움이 될 수도 있습니다.

가벼운 업데이트 루틴 수립하기

개요는 정보가 최신 상태인지 확인할 수 있을 때만 제 역할을 합니다. 프로젝트가 변하는 속도에 맞춰 업데이트 주기를 정하세요. 많은 소규모 그룹의 경우 주간 점검이 합리적인 시작점이지만, 진행이 느린 작업은 덜 자주 업데이트해도 되고, 빠르게 변하는 프로젝트는 더 자주 점검해야 할 수도 있습니다. Atlassian 역시 상태 보고서 가이드에서 프로젝트의 복잡성과 이해관계자의 요구에 맞게 상태 보고 빈도를 선택할 것을 권장합니다.

매 업데이트마다 각 프로젝트 담당자에게 다음 네 가지를 확인하도록 요청하세요:

1. 다음 마일스톤, 목표 날짜 또는 담당자가 변경되었는가?

2. 지난 점검 이후 눈에 띄게 완료된 작업은 무엇인가?

3. 장애 요인, 새로운 종속성 또는 필요한 의사결정이 있는가?

4. 다음 조치는 무엇이며 언제 다시 점검할 것인가?

업데이트 날짜를 기록하세요. 한 행이 최근에 점검되지 않았다면 "미업데이트"로 표시하거나 담당자에게 먼저 확인한 후 상태를 최신으로 간주하십시오. 이렇게 하면 오래된 "정상 진행" 라벨이 마치 최신 평가인 것처럼 오인되는 것을 방지할 수 있습니다. 날짜가 변경될 때는 날짜를 바꾸게 된 이유나 결정을 짧은 메모로 남기세요. 그렇지 않으면 반복되는 일정 변경의 맥락을 파악하기 어려워집니다.

업데이트 회의를 진행한다면 예외 사항과 조율에 초점을 맞추세요. 미리 행들을 읽어본 후, 차단된 작업, 마일스톤 리스크, 종속성, 여러 프로젝트에 영향을 미치는 선택 사항에 대한 논의에 시간을 할애하십시오. 일상적인 진행 상황은 모든 작업을 일일이 설명하지 않고도 기록할 수 있습니다. 이는 개요의 목적에 맞춘 효율성 제안일 뿐, 특정 회의 시간이 모든 팀에 들어맞는다는 보장은 아닙니다.

프로젝트 간 종속성 파악하기

프로젝트들은 개별적으로는 건강해 보일 수 있지만, 동일한 인력, 결정, 회의실, 장비 또는 검토 시간을 두고 경쟁할 수 있습니다. 한 프로젝트가 다른 프로젝트의 무언가를 필요로 할 때 종속성을 추가하세요. 중요한 날짜나 조건과 함께 제공자와 수령자를 모두 기록하십시오. 예를 들면: "웹사이트 출시는 5월 12일까지 이벤트 프로젝트로부터 최종 이벤트 세부 정보를 받아야 함."

그런 다음 개요에서 공유 인력과 일정을 살펴보세요. 같은 사람이 마감일이 겹치는 여러 다음 작업의 담당자이거나, 한 프로젝트의 결정 지연이 다른 프로젝트의 마일스톤을 지연시키는 경우 갈등 요소를 시각화하고 우선순위나 수정된 계획에 합의하세요. 이 지점에서 단일 개요가 개별 프로젝트 업데이트보다 훨씬 유용해집니다. 약속과 종속성을 한곳에서 비교할 수 있기 때문입니다. Project Management Institute(PMI)의 포트폴리오 프로세스 역시 다중 프로젝트 인벤토리를 모든 세부 작업으로 채우는 대신 상위 수준의 마일스톤, 상태 및 프로젝트 간 상호 종속성을 기록하도록 권장합니다. 여기서 제시하는 컴팩트한 버전은 소규모 그룹에 맞게 편집된 방식입니다.

단지 담당자가 지정되어 있다고 해서 종속성이 해결되었다고 가정하지 마세요. 예상되는 인계 시점을 기록하고 실제로 이루어졌을 때 확인하십시오. 순서나 날짜가 불확실하다면 그렇다고 명시하세요. 드러난 불확실성이 암묵적인 약속보다 논의하기 훨씬 쉽습니다.

지속적으로 활용 가능한 가장 단순한 형식 선택하기

정렬 가능한 행, 날짜, 필터 또는 여러 프로젝트에 걸친 컴팩트한 보기가 필요할 때는 스프레드시트를 사용하세요. 팀이 한 장소에서 함께 일하고 카드를 단계별로 옮기는 것이 효과적일 때는 화이트보드를 사용하세요. 업데이트 내용이 주로 짧은 서면 요약이고 프로젝트 수가 적을 때는 공유 문서를 사용하세요.

이는 형식 간의 장단점 비교일 뿐 특정 제품을 추천하는 것이 아닙니다. 여러분의 팀이 쉽게 접근하고 이해하며 업데이트할 수 있는 가장 단순한 옵션을 선택하세요. 소프트웨어를 도입하기 전에 실제로 무엇이 문제인지 질문해 보세요: 상태를 서로 비교하기 어려운가요? 업데이트가 늦어지나요? 종속성이 보이지 않나요? 새로운 도구가 협업이나 알림에는 도움이 될 수 있지만, 불명확한 마일스톤이나 명확하지 않은 담당 문제를 도구 스스로 해결해 주지는 못합니다.

프로젝트에 서로 다른 전문 세부 정보가 필요한 경우, 해당 정보는 기존 작업 기록에 두고 실용적인 수준에서 개요에서 링크를 걸거나 참조하도록 하세요. 다중 프로젝트 개요는 한눈에 훑어볼 수 있을 만큼 작게 유지되어야 합니다. 개요의 너비가 지나치게 넓어져야 한다면 일부 필드가 동일한 질문에 답하고 있지는 않은지, 혹은 프로젝트 수준의 메모에 들어가야 할 내용인지 점검해 보세요.

실제 적용 사례

한 코디네이터가 커뮤니티 이벤트, 웹사이트 리뉴얼, 월간 뉴스레터라는 세 가지 프로젝트를 관리하고 있다고 가정해 보겠습니다. 이들의 개요는 다음과 같이 표시될 수 있습니다:

예시: 커뮤니티 이벤트는 후보 장소 두 곳이 아직 예약되지 않아 '주의 필요' 상태입니다. 담당자는 5월 12일 장소 확정 마일스톤을 위해 5월 8일까지 대관 가능 여부를 비교할 예정입니다. 웹사이트 리뉴얼은 초안 페이지가 검토자들에게 전달되어 '정상 진행' 상태입니다. 5월 15일 검토를 위해 5월 10일까지 피드백이 마감됩니다. 월간 뉴스레터는 최종 원고에 확정된 이벤트 세부 정보가 필요하여 '진행 차단' 상태입니다. 담당자는 5월 9일 원고 마일스톤 이전에 5월 7일까지 세부 정보를 요청할 예정입니다.

이는 실제 보고 결과가 아닌 설명을 돕기 위한 예시 항목입니다. 이 개요는 뉴스레터가 이벤트 세부 정보에 종속되어 있다는 사실을 명확히 보여줍니다. 또한 이벤트 관련 결정이 뉴스레터 일정에 맞춰 제때 내려질 수 있는지 확인하거나 뉴스레터 계획을 조정하는 등의 유용한 다음 조치도 보여줍니다. 상태 색상 하나만으로는 우려의 원인도, 필요한 조율 사항도 파악할 수 없습니다.

더 구조화된 방식이 필요한 경우

동일한 업무를 업데이트하는 사람이 많아지거나, 프로젝트의 일정이나 예산이 복잡해지거나, 접근 권한 제어가 필요하거나, 의사결정 및 변경 이력 기록이 중요해지면 한 페이지 개요만으로는 부족할 수 있습니다. 여전히 간결한 다중 프로젝트 요약본을 유지할 수는 있지만, 세부 정보에는 보다 구조화된 시스템과 더 명확한 역할 책임이 필요할 수 있습니다.

소규모 포트폴리오의 경우 몇 가지 핵심 필드로 시작하고, 상태 정의에 합의하며, 동일한 마일스톤을 꾸준한 리듬으로 검토하세요. 개요가 주의가 필요한 부분을 파악하고 다음 조치를 조율하는 데 도움이 된다면 제 역할을 다하고 있는 것입니다. 개요가 사람들이 실제로 활용하지도 않으면서 형식적으로 작성하기만 하는 또 하나의 보고서로 전락한다면 내용을 단순화하거나 그 개요가 답하고자 하는 질문을 변경해 보세요.

이 주제 더 살펴보기