IT경영을 위한 다양한 방법 및 프레임워크가 개발되어 적용되고 있는데 공통으로 들어간 부분이자 가장 중요한 영역은 리스크 관리 입니다. 이번 영상에서는 리스크 관리 프레임워크, 적용사례, 리스크를 바라보는 관점과 대응방법 등을 정리했습니다.

모든 조직은 IT(Information Technology)를 활용하고 있다. 조직 목표를 달성하는데 IT경영이 핵심 수단이 되어 있다. IT경영을 위한 기법으로 다양한 방법론 및 프레임워크 등이 개발되어 적용되고 있다. 프로젝트 관리에는 PMBOK, SW개발은 CMM, IT서비스관리는 ITIL, SW 테스팅에는 TMMi, 시스템 관리의 BCP, 내부 통제에서는 COSO 프레임워크, 안정적인 IT서비스를 제공하기 위한 SLA 등이 있다.* PMBOK(Project Management Body of Knowledge), CMM(Cap

협상이라면 대부분 국가와 국가, 기업과 기업등의 세력 경쟁으로 생각할 수 있겠지만 의외로 우리 주변에서 많이 일어나고 있습니다.이번 영상에서는 현명하게 협상할 수 있는 7가지 방법들을 소개해 드리겠습니다.

공공부문 정보화는 ISP가 성패를 좌우한다 공공분야 정보화 사업 예산은 2013년 3조원에서, 2016년 4조원, 2020년 5조원을 넘어섰다(그림 1 참고). 2016년 이후 꾸준히 증가되고 있는 추세로 국가 예산의 중요한 부분으로 자리매김하고 있다. 디지털 경제로의 탈바꿈 및 디지털 뉴딜 정책 등에 따라 SW 부문 예산은 앞으로 꾸준하게 상승할 것으로 전망된다.2020년도 공공부문 ISP 예산은 192건에 454억원이 예산으로 수립되어 있다(그림 2 참고). 전체 SW사업 예산 규모는 증가하였지만, ISP는 건수가 늘었음에도 불

IT컨설팅을 수행하다 보면, 항상 고객사의 의사결정자 및 핵심고객으로부터 반드시 듣는 이야기가 있다. “이렇게나 비용이 많이 드나요?”라는 질문이다. 의사결정을 하는 입장에서보면, 시스템을 구축해야 할 필요성에는 공감하나, 너무 많은 비용이 소요된다는 것이다. 컨설팅 PM의 역량 평가 중 하나가 산출된 구축비용을 경영진에게 공감시키고 당초 비용안대로 통과시키는 것을 능력의 하나로 본다. 시스템 투자 필요에는 공감하더라도, 투자 규모는 부담스럽게 느낀다는 의미일 것이다. 그러나, 최근의 상황은 많이 달라지고 있다. 필자가 판교에 있는

통합테스트는 수행사보다 발주사의 역할이 더 중요하다소프트웨어 개발 단계별로 소요되는 기능점수(Function Point) 비중은 분석단계 19%, 설계단계 24%, 개발단계 32%, 테스트단계 25%이다(출처: S/W대가산정가이드, 한국소프트웨어산업협회, 2019). 테스트 단계는 개발 시스템의 성공 여부가 판가름나는 중요한 단계이다. 테스트를 얼마나, 어떻게 할 것인가는 구축 대상 시스템 특성에 따라 달라진다. 주로 고려할 요소는 목표 시스템에 요구되는 신뢰성과 사용성, 안전성 등의 품질기준이다. 대상 프로그램 물량, 테스트 참여

‘협상’이란 무엇일까? 내 이익을 위해 상대에게 양보를 바라는 논쟁일까?KOTRA가 2007년에 조사한 「16개국 비즈니스 협상스타일」에 따르면 우리나라 경영자들은 상대의 이익은 고려하지 않고 나의 이익만을 추구하는 이기심은 최고인 반면, 협상을 자신의 의도대로 이끌어 가는 협상주도력은 꼴찌였다. 이 조사를 주도했던 글로벌 협상전문가 진브렛(Jeanne Brett) 교수는 “협상 시 자신의 이익만큼 상대의 이익도 중요하다는 것을 인식해야만 양측의 기대치를 모두 충족시키는 원만한 결과를 도출할 수 있으며, 협상 결렬에 대비한 대안을

IT프로젝트의 성공을 좌우하는 것은 요구사항인데요애자일을 공부하다보면 다양한 요구사항 접근법이 있다는 사실을 알게 됩니다.이번 영상에서는 애자일에서 요구사항을 다루는 방법을 설명 드리겠습니다.

이해하기 쉽고 사용자의 의도에 적합한 보고서가 좋은 보고서라고 말할 수 있는데요,좋은 보고서를 만들기 위해선 계획과 함께 목적에 맞는 스토리 구성이 필요합니다.지난 1편에 이어 2편을 영상으로 만들었습니다~ #컨설팅 #보고서 #컨설턴트 #보고서작성방법

지난번 디지털 탈바꿈을 위한 프로세스 설계 [1부] 영상에 이어2부 서비스 기반 프로세스 설계 원칙을 영상에 담았습니다

디지털 탈바꿈의 대상은 기업 또는 기관이 수행하고 있는 프로세스인데디지털 탈바꿈의 성공을 위해서는 프로세스 모델링 원칙을 지키는 것이 중요합니다.이번 영상에서는 프로세스 모델링의 기본 원칙에 대해 설명 드리겠습니다.

PMO 서비스에 대한 몇몇 편견도 있지만 그만큼 도전적이면서 보람도 큰 서비스이기도 합니다.이번 영상에서는 PMO 프로젝트 수행을 통해 얻을 수 있는 장점, PMO 컨설팅을 잘 하는 방법들을 담았습니다.

비즈니스에서 협상은 돈 버는 기술이다1961년 존 F 케네디는 제35대 미국 대통령 취임연설에서 협상에 대한 자세를 이렇게 표현했다.“두려움 때문에 협상하는 일은 없도록 합시다. 그렇다고 협상을 두려워하지도 맙시다(Let us never negotiate out of fear, but let us never fear to negotiate).” 당시는 동서 냉전 시대였고, 민주 진영을 대표하는 미국은 공산 진영과 대결해야 하는 국면이었다. 흔히 협상이라고 하면 국가와 국가, 기업과 기업 등의 세력 경쟁으로 인식하는 경우가 많다. 트

프로젝트 수행 중 워크로드 관리보다 어려운 것이 자원관리 입니다.특히 장기간 수행되는 프로젝트일수록 자원관리가 어려워지는데요, 어떻게 하면 효율적으로 자원관리를 할 수 있을까요?

고객을 상대하는 IT컨설턴트에게 태도는 또 하나의 성공 비결입니다. 오늘 영상에서는 인상, 대화, 전화, 이메일, 문서, 약속 등 태도와 관련한 노하우를 전해드립니다.

애자일의 핵심은 요구사항을 다루는 방법에 있다 [그림 1] 많은 사람들이 가지고 있는 애자일에 대한 오해 / 출처: 딜버트 카툰[그림 1]과 같이 많은 사람들이 애자일은 포스트잇으로 설계를 대신하고 오로지 코딩을 통해 결과물을 만들어내는 방법론으로 오해하고 있다. 하지만 조금만 애자일을 학습해보면 오히려 폭포수 개발방법론에 비해 더욱 정교한 소프트웨어 공학적 접근을 하고 있다는 사실을 알게 된다. 요구사항 관점에서 애자일은 다음 두 가지 특징이 있다. ▶ 애자일은 요구사항을 가치창출 관점에서 바라본다프로젝트는 항상 비즈니스 기회에서

분할 후 정복하라, Divide and Conquer!소프트웨어 공학의 창시자들 중 한사람인 네덜란드의 에츠허르 데이크스트라(Edsger Wybe Dijkstra)는 1970년대에 이미 ‘분할 후 정복’을 주장했다. 전체 문제를 다룰 수 있는 범위로 먼저 나누고 그 다음에 각 단위 업무를 개발하여야 한다는 것이다.하지만 지금까지도 대상 업무를 나누기 보다는 동시에 개발하는 빅뱅 방식은 여전히 매력을 잃지 않고 있다. 빅뱅 방식이 주는 리스크보다도 효율성과 통합성이 더 중요하다고 생각하기 때문이다. 금융회사의 빅뱅 방식은 복잡도가 높

컨설턴트의 PMO 서비스에 대한 편견PMO 컨설팅은 다른 프로젝트에 비해서 기간이 길다. 최소한 1년 이상 길게는 3년도 더 소요되는 경우가 있다. 컨설턴트들은 PMO 컨설팅을 어떻게 생각할까? PMO 컨설팅을 알고 있는 여러 컨설턴트들에게 ‘PMO 서비스의 특징이 무엇인가?’라는 질문을 했다.‘프로젝트 수행 기간이 길다’, ‘프로젝트마다 별반 다르지 않다’, ‘프로젝트가 별로 배울게 없다’ 라는 대답들을 했다. 대부분 ‘수행 기능’, ‘수행 절차’, ‘수행 방법’에 있어서 PMO 서비스들이 유사하게 수행된다고 생각하고 있는듯 하다

PMO가 제대로 활동해야 프로젝트가 성공한다공공 부문의 정보화 프로젝트를 추진할 때 PMO도입은 의무사항은 아니다. 그 결과 PMO를 추진하기 위한 예산 확보에 어려움이 있다. 그럼에도 불구하고 최근 주요 공공 프로젝트에는 PMO사업을 별도로 추진하는 것이 일반화되고 있다.민간 부문에서는 대형 프로젝트의 경우 PMO사업을 별도로 발주하는 것이 금융권을 중심으로 정착되어가고 있다. 차세대 프로젝트처럼 전체 소요 예산 규모가 커서 비용 압박을 받을 수 밖에 없는 상황에서도 PMO사업 발주는 당연시되고 있다.공공과 민간 모두에서 PMO사

프로젝트거버넌스는 대부분의 프로젝트에서 주어지는 것으로 생각한다. 프로젝트가 실패했을 때 프로젝트거버넌스가 실패했다고 이야기하지 않는다. 주로 프로젝트 관리가 실패했다고 이야기한다. 그래서 실제로 프로젝트가 성공하지 못했을 경우 프로젝트 관리자가 상당부분의 책임을 떠안게 된다. 프로젝트거버넌스는 프로젝트 전체 관점에서 전략과 예산을 수립하고 의사결정을 수행하며, 프로젝트 관리는 프로젝트거버넌스에서 제시된 방향성을 기반으로 원활한 프로젝트 수행 환경이 조성될 수 있도록 지원한다. 프로젝트 실패의 원인을 관리의 실패로만 판단할 수 없다