programming/Project Management

이것만 알면 프로젝트 성공률 UP! 필수 관리 노하우

jamie91 2025. 2. 23. 18:09

1. 프로젝트 관리

  1. 프로젝트 정의 : 유니크한 제품, 서비스, 결과 등을 만들기 위하여 한시적으로 수행되는 작업.
    • 한정된 기간과 비용 내에서 정해진 자원을 활용하여 완수하고자 하는 과제.
      1. 계약상의 목표
      2. 일정
      3. 비용
      4. 자원 활용
    • 제한사항을 지키지 못한다면 신뢰도 하락, 수익절감 (지연보상금) 등..
  2. 업종별 프로젝트 현황 (IT, 건설, 토목, 조선, 제조 , R&D 등.의 수주업)
    • 수주업의 개념 : 고겍이 발주한 사업을 타 회사들과의 경쟁을 통해 획득하고 이를 수행하는 business 를 영위하는 업종
    • 고객의 사업기획 및 발주 → 제안 → 계약 및 협상 → 프로젝트 수행
    • EX) 중국의 저가 수주 ?? → 이익보다는 시장점령이 우선. 이익을 못보더라도 수주를 하겠다는 마인드
  1. 사업 발주 및 제안 프로세스
    • 프로젝트 타당성 검토 → 사업계획 및 예산 확보 → 프로젝트 발주 ⇒ 제안요청서 및 제안서 → 제안서 평가 → 사업자 선정 → 협상 → 계약
    • 사전 영업, 사업계획 지원 / RFI 제공 (Pre-Sales) - RFP 지원 → 입찰 참여 → 제안서 작성 → 협상 → 계약
  2. 제안 평가 (경쟁입찰 방식)
    • 평가주체 : 사업을 발주한 고객, 제안서를 객관적으로 평가할 수 있는 외부 전문가 등 평가위원(공공)
      • 공공기관에서 외부 전문가 등 평가위원을 쓰는 이유 ? 김영란법과 같은 맥락.
      • 대학 교수? 실무적 업계 내용을 모름 → 제안서의 과장,과대를 믿는 경우가 있음. ( 능력평가가 힘들다 , 공공 프로젝트의 퀄리티가 무너진다.)
    • 평가대상 :
      • 기술 평가 : 제시된 실행안 → 제안서, 요약서, 발표 자료
      • 가격 평가 : 제안 가격 → 제안가(입찰가)
    • 평가요소 :
      • 공식 요소 : 제시된 수행방안(기술)의 적합성 및 차별성, 가격의 적합성
      • 비공식 요소 : 고객/평가위원의 사업자에 대한 호감도, 친밀도, 관계 등
  3. 사업참여 의사결정
    • 사업 수행 가능 여부, 매출 규모와 이익률, 고객과의 전략적 관계 등을 고려하여 결정
    • < 주요 검토 사항 > 
      1. 현실적인 수주 확도는 어느 정도인가?
      2. 성공적인 수행이 가능한가? ( 기술, 관리, 위험 검토 )
      3. 매출 규모와 이익율은 어느 정도인가?
      4. EX ) IT 업계의 프로젝트 수행 시 평균 이익율 ? 5% 이내.
      5. 고객과의 관계유지를 위해 전략적으로 필요한가?

 

2. IT 프로젝트

  • IT 프로젝트 유형은 크게 컨설팅, 시스템 구축, 운영 및 유지보수로 구분됨.
  • ISP, PI : IT 컨설팅, 중장기 IT 사업기획 수립 ( ~5년 )

 

내부 기획부서 vs 외부 전문 컨설팅 업체?

  • 컨설팅 업체를 활용하는 이유
    ( AS -is —> TO - Be )
    1. 객관성
    2. 전문성
    3. 정치적 이유

 

2. 1 IT 프로젝트 규모

차세대 시스템? → 업무 시스템을 갈아 엎는다. 기반 인프라를 엎는다. → 규모가 크다. 성공률이 낮다.

  • 소형 프로젝트
    • 10명 이내 수행인원, 수행기간 6개월 이내 (최대 10억규모)
  • 중형 프로젝트
    • 10명 이상 수행인원, 수행기간 12개월 이내 프로젝트
  • 대형 프로젝트
    • 100명 이상 수행인원, 수행기간 2년 이상 프로젝트 (1000억이상 규모)
      💡 프로젝트 규모가 `작을수록` 성공확률은 `높아지며`
           프로젝트 규모가 커질수록 성공확률이 현저하게 낮아진다.

 

2.2. IT 프로젝트 현실

전세계 IT 프로젝트의 28% 는 중도하차, 26% 만이 예산과 기한 내에 완료된다.

 

1. IT 프로젝트의 특징

  • 프로젝트의 진행상황을 가시적으로 정확히 판단하기 어려움
  • 투입 인력(개발자) 의존도가 높은 속성을 갖음.
    개발인력의 능력에 따라 퀄리티와 개발시간이 달라진다.
  • 초기에 사용자 요구사항을 명확히 정의하기 어려움.
    요구사항이 감성적(Simple , Comfort ? .. ) 이다. ( 구체적이지 못하고 추상적인 말이 많다. )
    사용자의 IT에 대한 이해도가 낮으면  개발단계에서 진단을 받을 수 가 없다.
💡 개발 단계에서의 예시 

분석(사용자의 요구사항 분석. 매우 Rough ) 
→ 설계(사용자에게 진단을 받을 수 없음) 
→ 개발(사용자에게 진단을 받을 수 없음) 
→ 테스트(이 과정에서야 진단이 가능.)  ←  여기서 사용자가 변경이나 추가할 내용을 말한다. ?? 반영이 어렵다. 
→ 안정화

 

  • 대부분 일괄계약 형태로 진행하여 초기 정확한 규모 산정이 어려움.

2. IT 프로젝트 주요 실패 요인

  • 국내 프로젝트 주요 실패 요인
    1. 고객의 잦은 요구 변경 (21%)
    2. 기술, 경험 부족 (20%)
    3. 부정확한 기간, 비용 예측 (20%)
    4. 고객, 현업의 참여 부족 (12%)
    5. 영업 부서의 과욕 (9%)
    6. 고객 , 현업과의 인간관계 부실 (7%)
    7. 스케쥴 관리 미흡 (4%)
    8. 개발 방법론 부재 (3%)
    9. 개발 환경 미흡 (3%)
    10. 품질관리 부족 (2%)
💡 Crunch Mode
프로젝트의 마감일을 앞두고 일정을 맞추기 위해 팀원들이 수면,영양,사회 생활, 위생 문제를 포기한 채
고강도 근무체제를 유지하는 방식을 의미하는 용어
게임 업계를 통해 알려졌지만 과거 IT 업계 전체에 만연해 있던 프로젝트 수행방식으로 현재 이를 개선하기 위한
사회적 분위기 조성과 노력이 지속되고 있음. ( EX. 주 52시간 근무제도 )

 

 

3. 동양 서양의 프로젝트 차이

서양은 계약 중심의 프로젝트를, 동양은 계약+관계 중심의 프로젝트를 수행한다.

  • 서양의 문화는 사업 목표라는 객체 중심으로 프로젝트를 인식하여 계약을 체결하고 프로젝트 수행 중
    발생하는 계약 범위 밖의 요구사항은 쉽게 거절할 수 있기 때문에 수행 및 관리가 비교적 용이함.
  • 동양의 문화는 초기에 설정한 계약상의 프로젝트 목표도 중요하지만, 고객과의 관계 유지가 더 중요하기 때문에
    고객의 요구에 따라 목표와 범위가 수시로 변동되어 프로젝트의 수행 및 관리가 매우 어려움.

4. 프로젝트 관리 필요성

  • 점점 복잡해지고 많은 이슈를 내재하고 있는 프로젝트의 성공적인 수행을 위해서는 체계적인 프로젝트 관리가 필수 사항
    • 프로젝트 과업 범위를 보다 명확하게 정의하고 정해진 일정 내에서 가용한 자원을 효율적으로 활용하여 목표 달성
    • 프로젝트 팀원과의 협업, 이해관계자간의 효과적인 의사소통 수행이 중요

5. 프로젝트 관리 영역

  • 프로젝트 관리영역은 총 10개의 영역
    <PM 관리 업무>

 

 

  • 프로젝트 관리 핵심 요소
    • 과제 : COST 생각 없이 Scope 와 Time 에 맞추어 과제를 수행한다.

 

6. 프로젝트 수행 방법론

  • 방법론 개념
    • Methodology = Method + Knowlege
    • 방법론이랑 지식을 기반으로 일을 수행하는 절차, 방법, 원칙 등을 정의한 것.

 

  1. Waterfall 모델
    • 모든 개발 단계를 미리 예측하고 계획 한 후
    • 요구분석 → 설계 → 코딩 → 테스트 등의 순차적 개발 진행. (80% 가 차지하는 방식)
      시스템이 구현되어 시각적으로 확인되기 전까지 고객은 자신들의 요구사항의 실체를 알기 어렵다.
  2. 애자일 방법론
    • 일정한 반복주기를 가지고 끊임없이 프로토타입을 만들어 내며 필요할 때마다 요구사항을 더하고 수정하여 커다란 소프트웨어를 개발해 나가는 방식
    • 이 과정 각각에 이해관계자를 참여시켜 요구사항 수집과 결과 검증을 모두 거쳐갈 수 있는 장점이 있음.
      → 고객 (사용자) 중심의 개발 방식이다.
      → WorkSmart 한 방식이다.
    • Agile 방식
      Scrum ( IT )
      • Sprint : 기능개발 반복주기 (2주~4주 이내로 고정) → 다음 스프린트까지 고정된 기간에 스프린트 실시.
        • 절대로 스프린트 기간을 지연해서는 안된다
        • 각 스프린트는 (분석 - 설계 - 개발 - 테스트 - 검증 ) Plan - Design - Build - Test - Review - Launch 를 반복한다.
        • 고객의 변경 및 추가 요구사항이 생기면 ??
        • 다음 스프린트로 넘겨서 실행한다. → 다음 스프린트 계획안에 추가 되면 ? 실행하지 못하는 계획이 생기기 마련이고, 고객과 원래 해야할 기능과의 우선 순위를 조정한다.
      •  
실제로 현업에서 애자일 방법은 ?

고객 입장 : 불편, 참여요구

개발자 입장 : 적응력이 떨어진다. ( 고정 기간 내에 조그만 프로젝트를 계속해서 시작하고 끝내는 업무 방식 ) 

보고체계가  복잡하다. ( 스프린트의 기간이 짧은데, 의사소통이 너무 오래 걸린다.)
문화 : ( 팀원 → PL → PM → 고객 ) —> 이상적인 체계 : ( 팀원 → 고객 )

 

 

3. 프로젝트 착수 단계에서는 ?

  1. Project Leader 를 선임하고 팀원별 명확한 역할과 책임을 정립.
  2. 팀 내 협의 하에 프로젝트 (Ground Rule - 기본규칙 ) 을 정립.

    EX ) 회의 규칙
    • PL 에게 오늘은 무엇을 했고, 어떤 문제가 있었으며, 내일은 무엇을 할 것이다. 라 메일을 보내면, PL 은 그걸 수집해서
      회의를 주관하고 정리하여 다시 팀원들에게 보내준다. ( 일일 결산 회의 느낌 )
  3. 요구사항 (SPEC) 을 분석하여 최대한 명확화하도록 노력
    • 산출물
      1. 요구사항 정의서 (명세서)
      2. Use Case 명세서
      3. 요구사항 추적표
        • 요구사항 대비 단계별 산출물이 일관성을 가지는지를 프로젝트 전반에 걸쳐 추적하고 관리
        • 프로젝트 수행 과정에서 요구사항이 추가 혹은 변경될 경우 영향력 평가에도 활용
  1. WBS ( Work Breakdown Structure) 로 일정 관리 ( 프로젝트 수행 계획서 )
    • 프로젝트 일정을 관리하기 위해 단계별 활동내역을 정의한 후 작업과 활동을 정리, MileStone, 기간과 담당자, Network Diagram 등을 사용
    • Excel 또는 MS Project 를 사용하여 만들어보자 .

 

4. 프로젝트 일정계획 수립 시 고려해야 될 사항

  1. 개발 내역에 대한 기술적인 난이도를 사전에 평가해야 하고,
  2. 업무를 담당하는 팀원 각각의 능력을 고려하되,
  3. 개발과정에서 예상치 못한 이슈가 발생하는 경우가 많기 때문에,
  4. 이슈를 해결할 버퍼를 고려해서 일정을 계획하는 것이 바람직함.
    1. EX) 도전적인 목표를 가지고 프로젝트 계획의 마지막 1주~10일 정도를 비워놓는다.

 

5. 개발 전 목표단계에서의 설계

  • IT 프로젝트에서 설계가 중요한 이유는 ?
    1. 기능, 데이터, UI, 아키텍처 요구사항 등을 고려한 체계적인 설계
    2. 불필요한 코드를 줄이고 테스트와 재작업이 쉬운 코드를 만들고
    3. 개발과정에서 무한 수정/변경 등의 삽질..을 방지할 수 있을 뿐 아니라
    4. 향후 수정 및 유지보수가 용이하여 운영 생산성이 향상될 수 있음.

 

6. 형상관리 Tool 사용 ( GitHub )

  • 이슈 관리 - 버전 관리 - 배포 관리 - 릴리즈 관리 - 빌드 관리
  • 형상관리를 통해 버전(변경이력) 관리, 소스코드 재사용 및 이전 버전의 롤백이 가능.. 등
728x90
반응형