Project Management 란?

업무

Project Management 란?

로지컬엔지니어 2025. 1. 24. 22:54

최근에 Project Management 관련하여 짧은 코스로 교육을 받은 적이 있었다. 개괄적인 내용을 다루고 있었지만, Remind 차원에서 곱씹어보기 좋은 내용들이 있어 기록 및 공유 차 작성을 마음먹었다.

프로젝트의 성격 및 Project Director (PD), Project Manger (PM) 등의 생각에 따라 조금씩 다를 수는 있겠지만, 대체적으로 아래의 내용에 큰 이견은 없을 것이라고 생각한다.

Project 란?

- A temporary endeavor with a start and finish, undertaken to create a unique product, service, or result.

즉, 어떠한 결과물을 만들어 내기 위하여 일정 기간 동안 특정 업무를 수행하는 것으로 볼 수 있는데, 이 기간에는 시작과 끝이 존재한다.

따라서 무엇이든 될 수 있다. 가령, 개인의 결혼준비를 Project라 할 수 있을 것이고, 차량 구매 또한 Project라 할 수 있을 것이다. 회사에서 크게 준비하는 특정 업무만이 Project가 아니라는 의미이다.

- 일반적으로 프로젝트는 약 65% 정도가 결국 실패한다고 한다. 심지어 아래의 글에서는 약 70%가 실패한다고 한다.

https://pm360consulting.ie/project-management-statistics-trends-and-common-mistakes-in-2023/

Project Management Statistics: Trends and Common Mistakes in 2023 - PM 360 Consulting

Project management doesn’t come cheap—it takes up to 20% of the overall project budget. Running a project without solid management, or bad project management, however, will do more harm than good. That’s why we’ve put together the most important

pm360consulting.ie

Project Success Factors

- Project의 성공을 위해서는 크게 Value, People, Process 이렇게 세 가지의 요소가 중요하다. 각 항목별로 조금 더 자세히 보도록 하자. (참고로 나는 요즘 Process가 가장 중요하다고 생각한다.)

Value: Why does this project matter?

프로젝트는 본인의 Team, Organization 또는 Customer에게 어떤 Value를 줄 수 있는지 확실한 목표가 있어야 한다. 예를 들어, 내가 사우디 아람코의 프로젝트를 진행한다고 했을 때 'A 지역의 부동산을 매입하여 렌트를 주겠다' 라는 목표로 프로젝트를 기획한다고 하면, 물론 제대로 추진되기도 힘들 뿐더러 애초에 공감을 살 수도 없을 것이다. 그러나, 사우디 아람코의 Vision에 맞는, 예를 들어 'Heavy Oil Upgrading을 통한 Sustainability 향상 및 수익성 향상' 이라는 프로젝트를 기획한다면 어떨까? Team, Organization 및 Customer에게 모두 Value를 창출할 수 있는 프로젝트라고 볼 수 있을 것이다.

People: How do I help people want to play on my team and win?

모든 일에는 사람이 가장 중요하다. 프로젝트 또한 누가 참여하느냐에 따라 성패가 갈린다고 봐도 무방하다. 안타깝게도 프로젝트에 참여하는 사람들이 모두 에이스일 수는 없다. 따라서 우리는 프로젝트에 참여하는 팀원들이 최대한 Credible Individual이 될 수 있도록 힘써야 하고, 나아가서 그들이 각 Part의 Credible Leader이 되도록 이끌어 주어야 한다. 그렇다면 Credible Individual 및 Credible Leader는 어떤 사람들일까?

내 경우 과거의 경험을 생각해 보았을 때, 일하기 좋은 사람들이라 한다면 1. 의사 소통이 쉬워야 하고, 2. 아는 것이 많아야 하고, 3. 성실한 사람들이 대부분 떠올랐다. 반대로, 피하고 싶은 사람들이라면 1. 말이 안 통하고, 2. 게으르고, 3. 아는 것이 없는 사람들이다. 사람들마다 모두 생각하는 바가 조금씩 다를 것이나, 아래와 같이 Credible Individual/Leader가 프로젝트를 참여하게 된다면 그 프로젝트는 원만하게 진행될 가능성이 높다.

Credible Individual	Credible Leader
Honest & Trustworthy Inspiring Expertise & Capable	왼쪽의 항목 + Forward Looking

Credible Leader가 되기 위해서는 '앞을 보는 능력'이 추가가 되어야 하고, 이 부분이 프로젝트에서는 특히 중요하다 볼 수 있다. 프로젝트를 진행하다 보면 예상치 못한 변수들이 계속해서 생기기 때문에, 개인적인 경험에 비추었을 때 지나치게 낙관적인 생각으로 프로젝트를 진행하다 보면 간혹 크게 낭패를 볼 수 있다.

위와 같은 팀원들이 되도록 하려면 의사 소통 시, ' Informal Authority Behaviors'를 염두에 두면 좋다.

* Informal Authority Behaviors: The ability, without a formal position of power, to inspire people to willingly follow your direction.

쉽게 말하면, 사람들이 본인을 따를 수 있게 하는 행동 지침이라고 생각하면 되는데, 대략 아래의 요소를 토대로 의사 소통을 하면 되다.

. Demonstrate Respect (늘 존중하는 자세로 대하자)

. Listen First (상대방의 말을 먼저 경청하도록 하자)

. Clarify Expectations (본인이 원하는 바가 무엇인지 명확히 전달하자)

. Extend Trust (상대방을 신뢰하자)

. Practice Accountability (책임감을 갖자)

개인적으로는 'Clarify Expectations' 항목이 참 중요하다고 생각하는데, 그 이유는 보통 사람마다 특정 항목에 대해 생각하는 바가 다를 때가 많고, 높은 직책에 있는 사람들일수록 High level로 얘기하는 경우가 대부분이기 때문이다. 마치, 위에서 '이 문서 좀 잘 정리해봐' 라고 했을 때, "잘"의 의미가 명확하게 전달되지 않으면 실무자가 생각하는 기준에서 결과물이 나올 수밖에 없기 때문이다. (Process Engineer는 Process 관점에서, Piping Engineer는 Piping 관점, Controller는 Schedule 또는 Cost 등등)

Process: The Framework that would align the project team.

모든 업무는 정해진 틀에 따라 진행되게 된다. 프로젝트 또한 마찬가진데, 크게 아래의 구성이 전체 Process를 이루고 있고, 각 항목이 유기적으로 엮여 있다.

1. Scope - 프로젝트의 초기 단계에 매우 중요

2. Plan - Scope 기준으로 설정이 되며, 3번 (Engage)와 Feedback 관계임

3. Engage - Plan에 따라 프로젝트를 진행하며, 팀원들의 Accountability를 챙기는 것

4. Track & Adapt - 프로젝트 Status 관리, Change Management

5. Close - Lesson Learned 작성 및 종료

Scope

→

Plan ↔ Engage

(Track & Adapt)

→

Close

Scope 단계에서는 Key Stakeholder와 Align을 잘 맞추어 구체적인 업무 범위와 목표를 설정하는 것이 중요하다. 어떻게 보면 단추를 처음 끼는 단계라 볼 수 있기 때문에 가장 중요한 단계라고 보아도 과언이 아니다. Key Stakeholder는 프로젝트의 성공과 실패를 결정지을 수 있는 사람이며, 아래와 같이 'DANCE'로 나타낼 수 있다.

* Key stakeholder: Any person who determines the success or failure of the project. Key Stakeholder’s attributes can be explained as DANCE.

. Decisions: They control or influence the project budget

. Authority: They provide permission to proceed

. Need: They directly benefit from or are impacted by the project

. Connections: They remove roadblocks or exert influence when needed to ensure project success

. Energy: Their positive or negative energy could affect project success

예를 들어, 신규 공정을 새로 짓는다고 한다면 Key Stakeholder는 대략 공장장, 재무팀장(or 상무) 등이 될 수 있을 것이다. 하지만, EPC 과정에서 접촉하는 정부기관(for 인허가)은 단순 Stakeholder일 뿐이다.

Key Stakeholder와 프로젝트 Scope을 정하기 위해 대화를 할 때에는 아래와 같은 순서로 Interview 한다고 생각하면 된다.

1. Open Question - 일반적인 정보 취득

2. Detailed Question - 프로젝트 Scope 확정을 위한 구체적인 질문

3. Closed - 내용 정리 후 Yes 또는 No 답변으로 Closed

예를 들어, 진행하려는 프로젝트의 예산을 정하고 싶다면, Key Stakeholder (재무팀장)에게 가서 '예산을 쓰려면 어떻게 해야 할까요? or 예산이 좀 남은 게 있을까요?' 등의 일반적인 질문으로 시작해서, '~~ 정도의 예산을 올해 승인 받을 수 있을까요? or ~~ 예산을 승인 받을 경우 Contingency 명목으로 추가로 받을 수 있는 금액 제한이 있나요?' 등으로 구체적인 정보를 받은 다음, 마지막으로 '올해 xx까지 진행이 될 경우 예산을 ~~정도 승인을 받을 수 있고, Flexibility는 ~~ 정도 된다는 말씀이시죠?' 하며 Yes/No 답변을 받는 식이다. 다만, 이러한 의사소통의 경우에는 추후 내용이 달라질 수도 있기 때문에, 꼭 회의록 (MOM, Minutes of Meeting) 등을 작성하여 공유하는 것이 필요할 것이다.

Plan의 경우 Risk Strategy와 Project Schedule이 가장 중요하다. Risk Management의 경우 프로젝트를 한 번이라도 해 보았다면 아래가 익숙할 수 있다.

Risk = Consequence X Likelihood (or Impact X Probability)

프로젝트에서 발생 가능한 다양한 Risk를 검토하고, 각 Risk들에 대한 대응 방안은 크게 TAME으로 정리될 수 있다.

. Transfer: Shift the risk to a third party

. Accept: Acknowledge the risk and deal with it, if it occurs

. Mitigate: Lessen the risk by reducing the probability or impact

. Eliminate: Remove the risk

Project Schedule은 크게 아래와 같은 단계로 작성하게 된다.

Develop the Work Breakdown Structure (WBS) - 가장 큰 구성 요소로, 규모가 작은 프로젝트의 경우 단일 WBS로 이뤄질 수도 있다.
Sequence activities - WBS를 다양한 Deliverable 또는 Component로 쪼개면, 각 단위를 업무의 순서대로 배열한다.
Identify and assign people resources - 이후 각 Activity를 담당자를 지정하여 배분한다.
Estimate duration - 각 업무에 얼마나 시간이 소요되는지, 필요한 시간이 얼마인지 정한다.
Identify the critical path - 가장 오래 걸리는 일, 가장 중요한 일, 꼭 지켜져야 하는 일정 등의 기준에 따라 정해진다.

예를 들어, 어떤 공정을 설계한다고 했을 때, 그 업무의 부분 중 하나를 'Licensor Technology Selection'으로 선정할 수 있을 것이다. 그러면, 해당 Component를 업무의 순서대로 배분했을 때 대략 다음과 같이 나눌 수 있을 것이다.

Number	Components / Activities	Predecessor	Work Hours	Duration (days)
1	Technology Selection
1.1	Design Data Gathering		8	5
1.2	Data Review	1.1	16	5
1.3	Transfer Data to Licensors	1.1	2	3
1.4	Have Responses from Licensors	1.3	4	14
1.5	Evaluate Responses	1.4	24	7
1.6	Licensors' Technologies Reference Check	1.3	4	3
1.7	Complete Evaluation	1.5	4	3
1.8	Report to Management	1.7	4	3

여기서 중요한 것은, 각 Activity의 Dependency를 확인하는 것인데, 예를 들어 1.6 항목 (Licensor Technology Reference Check)의 경우에는 굳이 이전 단계 (1.5 Evaluate Responses)를 끝내지 않더라도 별도로 Reference Check을 동시에 진행할 수 있다. 따라서 Schedule 작성 시에는, 각 Activity의 Dependency를 확인하고 수립하는 것이 중요하다. Dependency에는 아래와 같은 Sequence가 있다.

Finish to Start: Activity1이 끝나야만 Activity2가 시작될 수 있는 경우 (e.g. 지붕 올리기는 벽 작업이 완료되어야 함)
Start to Start: Activity2이 시작하기 위해 Activity1이 시작되어야 하는 경우 (e.g. Concrete 붓기가 시작되어야 Leveling 진행이 가능함)
Finish to Finish: Activity2가 끝나기 위해선 Activity1이 끝나야만 하는 경우 (e.g. 가구 설치 완료 전 Painting이 완료되어야 함)
Start to Finish: Activity1이 끝나려면 Activity2가 반드시 시작되어야 하는 경우 / 흔치 않음 (e.g. 기존 컴퓨터 시스템이 작동되기 전에 신규 컴퓨터 시스템이 시작되어야 함)

Engage의 경우, 실질적으로 Success Factor 중 하나인 People 에서 다룬 내용이 그대로 적응된다고 보면 된다. 프로젝트는 대부분 일정 기간 동안 진행되며, 프로젝트의 시작부터 끝까지 모든 팀원들의 집중력이나 사기를 그대로 유지시키기 위해서는 많은 노력이 필요하다. 따라서 주기적으로 Accountability 에 대한 환기가 필요하고 Performance 모니터링, 또는 Feedback이 중요하다.

가장 중요하고, 또 일반적으로 대부분의 프로젝트에서 진행되는 Engage Activity는 정기적인 Meeting일 것이다. Meeting에서 지켜져야 할 사항들은 대체적으로 아래와 같다.

현재까지 진행된 주요 Activity 및 Updated Project Schedule
지난 Meeting 시 논의되었던 Action Item
다음 Meeting 까지 진행 예정인 Action Item

다만, 중요한 것은 Meeting 시에 늘 Informal Authority Behaviors에 따라 의사 소통하는 것을 유지하는 것이다.

Track & Adapt에서는 Project Status Report 및 Change Management가 주요 항목이다. 통상 Project Status의 경우 주요 Activity가 나열되게 된다. Report로 작성할 때에는 프로젝트가 전체적으로 어떤 상황인지, 즉, 예정대로 가고 있는지, 조금 문제가 있는지, 아니면 위험한 상황인지 함께 나타내주고, 이를 타개하기 위한 계획과 담당자 및 Due Date 등을 표기해야 한다. 프로젝트의 Status를 판단할 때에는 통상 Quality, Schedule, Budget 등을 토대로 보면 된다.

또한 프로젝트에서 Change가 발생했을, 또는 발생이 예상되는 경우에는 Change에 대한 사유와 함께 그로 인한 Impact 등이 명확히 명기되어 Key Stakeholder에게 승인을 받은 뒤에 적절하게 문서화 되어야 한다.

Close에서는 Lesson Learned 및 Hand over 가 중요하다. 대부분의 경우 프로젝트가 끝나면 단순히 프로젝트 조직이 해산되고 그만인 경우가 많으나 (특히 소규모 프로젝트일수록), Lesson Learned를 문서화 하는 것은 상당히 중요하며, 회사나 개인의 큰 자산이 될 수 있다. Lesson Learned 문서는 크게 다음과 같은 내용을 포함할 수 있도록 준비되면 된다.

What could be improved? / What will we do differently?
What worked well? - 이 부분의 경우, 해당 프로젝트에서 특별히 더 잘 되었던 부분들을 기록하는 용도로 쓰일 수 있다.

Hand over의 경우에는 프로젝트 이후 그 결과물이 다른 인원 또는 조직으로 넘어갈 때 특히 중요하다. 서로 충분히 의사 소통을 마무리하고 자료를 전달한 이후에는 Accountability가 완전히 Hand over되었다는 내용의 문서화를 해 두는 것이 추후 분쟁의 소지에서 자유로울 수 있다.

다양한 Project를 진행하며 공정 검토뿐 아니라 Project Management 업무도 병행하여 대부분의 내용을 알고는 있었으나, 이렇게 한 번 문서화를 하며 다시 한 번 내용을 복기해보니 머리속에 조금 더 구조화가 잘 되는 것 같다. 아마 프로젝트 업무를 많이 진행해 본 사람들의 경우 대부분 고개가 끄덕여지는 내용들일 것이며, 조금 더 상세하게 파고 들어가면 덧붙일 부분들이 많을 것이다.