'B-Project/Project Management'에 해당되는 글 38건

  1. 2011.11.26 IT프로젝트 관리자의 리더십 역량: 팀 사회적 자본 관점에서
  2. 2009.11.06 The Politics of Projects
  3. 2009.11.06 Projects & Politics: Evil or Just Inevitable?
  4. 2009.11.06 프로젝트 목표 설정
  5. 2009.11.03 Project Manager's Competence 관련 논문들..
  6. 2009.01.23 프로젝트 목표 설정 기법
  7. 2009.01.23 조지 도란(George T. Doran)의 SMART 방법론
  8. 2009.01.23 프로젝트 업체 선정 (4)
  9. 2009.01.23 프로젝트 이해관계자
  10. 2009.01.23 이해관계자 네트워크
  11. 2009.01.23 프로젝트관리자의 체크리스트
  12. 2009.01.23 A Simple 6-Step Project Stakeholder Management Framework
  13. 2009.01.19 Conducting Successful Interviews With Project Stakeholders
  14. 2009.01.19 도움 안되는 네트워크 관리자 유형 7가지
  15. 2009.01.19 관리자의 리더쉽 유형도
  16. 2009.01.16 인재 킬러형 관리자의 7가지 유형
  17. 2009.01.16 프로젝트 매니저와 프로젝트 팀 (1)
  18. 2009.01.16 프로젝트 팀 구성 프로세스
  19. 2009.01.16 프로젝트 팀의 초기활동
  20. 2009.01.06 프로젝트 조직구성
  21. 2009.01.06 SWOT Team: Building Community With Wikis and Weblogs and Other Forums
  22. 2009.01.06 프로젝트 관리자에게 요구되는 기량
  23. 2009.01.04 프로젝트 관리자의 소양
  24. 2009.01.04 프로젝트 관리자의 역할
  25. 2008.12.12 프로젝트 관리자의 100가지 룰
  26. 2008.12.12 최상의 프로젝트 관리자에 대한 고찰
  27. 2008.12.12 프로젝트 조직이란
  28. 2008.12.12 팀조직, 네트워크조직, 가상조직
  29. 2008.11.06 Power politics and the IT project
  30. 2008.11.06 The politics of project management

IT프로젝트 관리자의 리더십 역량팀 사회적 자본 관점에서
 

이혜정, 박준기, 이정우
 

  This study explores the applicability of social capital theory in IT project management. Specifically, an empirical model is developed using different types of leadership competencies (emotional, cognitive, and social) as independent constructs impacting IT project performance. Social capital shared among team members are measured and placed as a mediating construct between leadership competencies and performance. Using PLS analysis of 120 data points collected through a survey of IT project participants in two large electronic manufacturers, direct and indirect impacts of leadership competencies are explicated. Research results reveal that emotional leadership competency seems to directly influence the project performance but not through team social capital, while social leadership competency seems to indirectly influence the project performance through team social captial but not directly onto the project performance. Cognitive leadership competency is the only leadership competency that maintains direct and indirect influence on project performance. Total effect of cognitive competency on project performance is almost two times larger than the total effect of emotional leadership competency and six times larger than the total effect of social leadership competency. Implications of findings are discussed at the end, and further studies are suggested.

Posted by 노터니

The Politics of Projects

Geoff Choo

January 13, 2003

Politics: A strife of interests masquerading as a contest of principles.--Ambrose Bierce


For better or for worse, office politics is the art of getting things done: It's what makes most organizations run. Without it, most businesses will just grind to a halt as personal agendas don't get fulfilled, interests don't get satisfied and people don't get what they want. If you want to play successfully in the high-stakes project management game, you have to understand that politics isn't just about playing dirty. You can play clean and still win.


Do you have what it takes to play the political game the right way?


Do you know what matters most to your organization?
The successful project politico understands what really matters to your organization. You may be smart and have loads of good ideas, but it's not what you bring to the game that counts--it's what you do with what you bring. If you want to influence how things work in your company, your personal agenda has to be aligned with the overall mission and values of the company.


This isn't a case of idealistic thinking; it's just a matter of good business sense. It will be easier to "sell" your radical ideas if people can see that what you want to do will add to the company's bottom line, and will eventually benefit everyone in terms of a bigger year-end bonus, or something along those lines.


So, you have to ask yourself if you know why your organization is in business, how does it do it's business and what really matters to the company--do profits matter more than market share or top-of-mind? Or are eyeballs more important than what the customer thinks? Whatever it is, do you fully understand what part you play in the success of your company?


Do you know how your organization really works?
Working successfully within the organization requires organization savvy--knowing how the company really works and whom to trust and whom not. There are two kinds of org charts in any organization: the official one based on title and rank, and the real one with the people who really count--the ones with the real influence and power to do things, or stop things from getting done.


John may be the director of the department, but if you want to get things done, you have to get the blessing of Margaret the executive secretary, Mario the mail office boss and Janet, who runs the company's websites. You need friends in high places to support your initiatives, but more importantly, you also need the ones in the low places, the ones who operate where the rubber meets the road, because that is where the work gets done, and where people will either embrace or reject what you're trying to accomplish.


Here's how to develop organizational savvy, starting right from today: Become a student of the organization and try to understand why things get done the way they get done. Keep your eyes open as you go about your daily routine. Don't take things for granted, but pay attention to the dynamics of how things work or don't. Find out who you need to please to make things happen and who you need to squeeze. Learn to see things from their points of view. Learn what approaches work and what doesn't when dealing with the players in your organization.


Do you work your network?
Software development is getting harder than ever before. Technology is changing too quickly and getting too complex for you to have all the knowledge to get your job done. Smart project managers know how to turn to others for help, because networking may be the only way that you can get your work done. But networking isn't just a matter of saying "hi" at the coffee machine. You need to cultivate a deeper relationship by being easy to work with and understanding that the economics of networking means you have to give more than you take. Here's how to master the networking game.


Begin by figuring out what you don't know but need to know. Then figure out who can supply that knowledge and what you can give them back in exchange. But don't just think only about yourself. You also have to actively find out who needs help and what you can do for these people. You may not have the knowledge to help these people out directly, but you can make the effort to point them in the right direction of someone who can. If you keep building up your network one person at a time and one day at a time, you'll have something solid in no time at all.


Don't call on someone you need help from and simply demand his or her assistance. The law of reciprocity in networking states that everyone expects to get before they give. If you want people to trade with you, you have to show them that you have something worth trading for, like expertise and precious resources. If you want your developer to burn three weekends in a row to deliver your project on time, then you must match her sacrifice with something much bigger or better, like a more powerful workstation or more interesting work.


But don't expect to make a fair trade right away. Networking takes time and patience to build up your "credits," and you have to be ready to give out a lot of favors before asking for anything in return.


Do you know how to show and tell?
Politics is like marketing--or some would say that it is marketing: You need to use the right message with the right audience at the right time. But how you say the message is also as important as the message itself. What's the point of having a good message if no one hears it, or worst, hears the wrong message because you screwed it up? Here's how you can excel at show and tell.


Figure out the message that moves the people you're speaking to. This means understanding the audience and finding out what they will listen to and what will inspire them. The secret is to take a hopelessly complicated set of problems and reduce it to simple metaphors that anyone can understand. The message also has to make sense to your audience. For one person, it might be more money, for another, it might be less overtime. You need to deliver the message in a way that works for that audience, be it bullet points and a slide show, an e-mail memo or just a quick recap in the elevator.


Learn to use the grapevine to spread your message. If real information moved through the company as fast as gossip did, we'd all be much better off. You can't affect what people do unless you influence what they listen to. And the most powerful communication channel you can use is the unofficial one.


But don't overdo it. You don't want to bore people to death by over-communicating your messages. When people hear the same thing over and over again, the first instinct is to tune it out. You need to be able to time your message properly and deliver them only when you'll get the maximum effect.


Can you lead without leading?
You may have the formal authority to  lead, but if don't have the moral authority to lead--if people don't respect your moral right to lead--you still won't be able to accomplish much. Project politicos know that real leadership isn't about big visions, big ambitions and big egos. It's the small stuff that counts, like knowing what you're talking about, knowing how to take the team forward by building momentum--and keeping the energy high, especially during the difficult times.


The most important thing is taking care of everyone who's involved in the project. You may not have the power to give out bonuses, promotions or raises, but what you have is the ability to organize people and coordinate efforts to get things done. And you have this because you lead without leading.


The non-leader understands that what really counts is making your people realize their objectives and fulfill their ambitions. Begin by understanding the people who are following you: Why are they following you, what do they have to gain and how can you help them on their journey.


Then focus on the small things to kick start and keep the momentum going in the organization, like making sure that meeting rooms have been booked, coffee and pastries have been prepared, people have all the software tools they need and things don't fall through the cracks. Leaders need to have a big vision, but having the ability to get things done is more important.


Remember, politics isn't about winning at all costs. It's about building relationships to reconcile the push and pull of conflicting interests and getting results at the same time.


Geoff Choo is an independent technology consultant and a freelance business and technology writer. People call him when they need someone to fuss over all the small details and turn vague ideas into finished products. In a previous life, he worked for IconMedialab in Milan. You can get in touch with Geoff at geoff@netstatistica.com.

Copyright © 2008 gantthead.com All rights reserved.
The URL for this article is:
http://www.gantthead.com/article.cfm?ID=157963
Posted by 노터니

Projects & Politics: Evil or Just Inevitable?

Mark Mullaly, PMP

October 27, 2004

Sooner or later, all of us must face the inevitable. No matter what we do, where we go or how much we hope otherwise, politics eventually emerge as a force to be reckoned with. Politics are seemingly inevitable, whether it's participating in a volunteer organization, serving on a board of directors, attending a meeting or--more often than not--managing a project. The fact is that politics are ever-present. It's just that some situations stick in our minds as being more politically charged than others.

In their most benign sense, politics are the dynamic forces that define the practice of organizational governance. As a nice, neat analytic theory, that's all well and good. The politics that most of us are more typically referring to are more overt, and more negative. They are the activities of individuals and interest groups who try to gain advantage for themselves at the expense of someone--or, in the case of our projects, something--else.

For many of us, we confront and deal with politics daily. Some of us are the instigators, and many more of us are the recipients. We deal with political interference from sponsors, executives, colleagues, managers and even team members. For certain project managers, I would hazard a cautionary estimate that upwards of 75 to 85 percent of their role and day-to-day activities are defined by politics, rather than dealing with the more rational and objective aspects of project management.

Many of ask the question of whether politics are a necessary evil, or are simply part of the project role. The most common perception, based upon feedback from many clients and training course participants, is that people simply wish that dealing with politics was not a part of their role, all the time recognizing that on some level it is. I've observed a range of responses, from the active to the passive, in how project managers respond to politics:

The Player
This project manager doesn't just accept politics, they thrive on them. Politics is a sport to be played and played well. Not only will this project manager actively engage in politics, but in many instances is the instigator behind them. The project simply becomes a vehicle to engage in the pursuit of personal interest. The danger of this approach is that the purpose of the project runs a strong risk of playing second-fiddle to the political goals of the person running it. Just like the debater that goes looking for an argument or the troubleshooter that will create problems just so they can be solved, there is a very real risk that the quest for politics here trumps all else, including an efficient and successful outcome of the project.

The Manager
This project manager views politics as a necessary evil, to be dealt with when required. While not inherently political themselves, those that respond to this type know how to play the game when pushed, and will jump in the fray as needed when others begin to work in conflict with the objectives of their project. To an extent, this profile takes a similar approach to that of risk management--expect the worst, allow for it and engage your contingency plan should it in fact occur. The only caution in this approach is that there are situations where the point of realization of political problems is well beyond the point at which a proactive--or even constructive--resolution is possible.

The Passive-Aggressive
This project manager uses politics as a shield, deflecting problems onto others in order to prevent having to deal with situations themselves. For the passive-aggressive project manager, their project would be fine if it weren't for everyone and everything else. The consequences of this dynamic are readily obvious--deflection of accountability for problems, even to the point of identifying imaginary problems elsewhere to deflect attention and focus from the project and the project manager. While the implications of this approach are painful, this behavior can persevere for a significant amount of time before it surfaces, at which point problems in the project may be well beyond the point of fixing easily.

The Avoider
This project manager doesn't like politics, and doesn't want to know about them. Not only will they not engage in politics, but they will deny their existence even in the face of objective evidence to the contrary. Those that respond to this type believe that hard work and objective fact will eventually prove out, and are constantly astonished when this doesn't occur. While the view may be perceived as naïve, the reality is that it is a perspective that many project managers hold, and that many more wish they could, if only as an ideal. Unfortunately, wishing politics away won't make them disappear, and refusing to deal with them cuts off our ability to effectively control the fate of our projects--and sometimes our careers.

Many of us will see ourselves in one or more of these types. Still others will prefer not to. Regardless of the motives behind each type, however, what emerges is the fact that politics are an inevitable part of the job, but also a potentially dangerous and not necessarily constructive part. Equally important is the recognition that politics comes in many different styles and flavors. It isn't just the Players that we need to watch out for, even if they are the most overt.

Our ability to choose how we respond to the presence of politics first depends upon acknowledging their existence. Without a doubt, there are approaches that are going to be more or less effective in different circumstances--whether these differences are due to the sponsor, customer, team or organizational culture. To be successful, it is important that we know ourselves and our attitude toward politics, and have sufficient perception to recognize when we need to engage in political action and which approach will be most effective. The way we deal with the Passive-Aggressive will not work for the Manager or the Avoider.

Lastly, it's important to keep politics in perspective. While we have to deal with them, our first priority should--wherever possible--be the project, not the politics. It is incredibly easy to get sucked into political turmoil that consumes our every waking thought, only to emerge out the other end and wonder where our perspective was. To paraphrase Henry Kissinger's comments on universities, "[The] politics are vicious precisely because the stakes are so small."

Mark Mullaly is president of Interthink Consulting Incorporated, an organizational development and change firm specializing in the creation of effective organizational project management solutions. Since 1990, it has worked with companies throughoutNorth America to develop, enhance and implement effective project management tools, processes, structures and capabilities. Mark is also the author of Interthink's Project Management Process Model (PM2), a maturity model that has been used to assess over 550 companies worldwide.

Copyright © 2008 gantthead.com All rights reserved.
The URL for this article is:
http://www.gantthead.com/article.cfm?ID=220158

Posted by 노터니
고객의 요구사항이 파악되고 대략적인 프로젝트의 최종산출물에 대한 윤곽이 잡히면 프로젝트 팀원들은 프로젝트의 각 진행 단계별로 산출물에 대한 개념을 공유하여야 한다. 이는 동일한 프로젝트의 목표를 추구하고 프로젝트 완료까지 일관된 수행을 해나가는데 많은 도움이 되기 때문이다. 프로젝트의 최종 목표를 완료하고 달성하기 위해서는 프로젝트 팀의 모든 개인과 관련부서 그리고 고객과 완벽하게 프로젝트의 목표를 공유하고 개개인의 목표와 모든 기능 지원 팀의 목표가 명료하게 설정되어야 한다.

프로젝트의 목표를 설정할 때에는 무엇을(범위), 언제까지(일정) 수행하는 데 얼마나 많은 자원(비용)이 드는 지가 포함되어야 한다. 일반적으로 S.M.A.R.T 기준에 의해 목표를 설정한다.

• Specific : 구체적이어야 한다. 달성하고자 하는 것은 구체적으로 무엇인가?
• Measurable : 측정 가능해야 한다. 목표 달성 여부를 어떻게 측정할 수 있는가?
• Attainable : 달성 가능해야 한다. 이 목표는 달성 가능한 목표인가?
• Result-oriented : 주어진 예산, 시간, 자원의 범위에서 이루어질 수 있는 현실적인 것이어야 한다.
                              목표가 결과물 중심으로 표현되어 있는가?
• Time-based : 수행 기간이 명확하게 표현되어야 한다. 언제 그 목표가 달성될 수 있는가?

예를 들어, 목표를 “2007년 6월 1일까지 사업부 소속직원 6명이 100만원의 예산으로 현재 종이 사용량의 30%를 줄일 수 있는 문서관리 프로세스를 설계한다.”와 같이 설정했을 때, 일정은 2007년 6월 1일 까지, 자원은 직원 6명이 100만원의 예산으로, 범위는 현재 종이 사용량의 30%를 줄일 수 있는 Process 임을 알 수 있다. 그래서 이 목표는 S.M.A.R.T 하게 잘 작성 되었다고 할 수 있다.

프로젝트의 목표 설정 프로세스에는 다음과 같은 사항이 포함되어 순차적으로 진행되는 것이 좋다.

1. 프로젝트 산출물 명세서(POS: Project Outcome Statement) 개발
2. 지원 기능 팀의 목표 수립
3. 목표에 대해 고객과 합의

프로젝트 산출물 명세서는 “프로젝트의 목표 고객에게 무엇을 제공할 것인가?” 에 대한 간략하면서도 정확한 문장이다. 그러므로 우선적으로 프로젝트 팀원들과 전체적인 프로젝트의 목표에 대한 토의를 거쳐 개발하고 결과를 문서화하여 공유하는 과정을 거쳐야 한다. 

다음으로, 프로젝트 팀과 프로젝트 매니저가 지원 기능팀(부서, 부문)의 목표를 함께 정의하는 것이다. 이런 목표는 각각의 지원 기능팀(부서, 부문)이 프로젝트의 목표 달성을 위해서 책임져야 하는 업무에 대한 진술문 형식으로 작성하는 것이다. 지원 기능팀의 목표를 수립하기 위해서는 목표에 대한 합의를 위해 지속적으로 의사소통 하는 것이 중요하다. 결과를 문서화하고 목표 수립과정을 공유하며, 명확히 해야 하거나 협상이 필요한 이슈를 확인할 필요가 있다.

마지막으로, 설정된 목표가 고객의 요구와 일치하는지 확인하기 위한 검토가 필요하다. 이를 위해서 정기적인 또는 비정기적인 회의가 이루어질 수 있는데, 이때 발생하는 목표에 대한 서로의 차이점은 다시 재조정하는 단계를 거쳐야 한다. 제안된 계약 내용 및 프로젝트 관련 문서를 검토하고 고객의 요구사항에 대해서 이해한 후, 고객과 만나서 요구사항을 확인하여야 한다. 고객과의 차이점은 조정하여 프로젝트 목표에 대해서 합의하고, 추가 사항은 무엇인지 확인하여야 한다. 만약, 새로이 변경된 사항이 있다면 이에 대해 프로젝트 팀원과 재 공유 한 후 다시 고객과 합의를 하는 이러한 절차로 진행이 되어야 한다. 

프로젝트의 목표를 S.M.A.R.T 하게 설정하고, 프로젝트 팀, 고객, 이해관계자들과 목표를 공유하는 것은 프로젝트의 성공을 위한 약속이다.


* 프로젝트 매니지먼트 전문가(PMP), 프로젝트 매니지먼트 코치(PMC) - 허정재(hur@psi.co.kr) 
Posted by 노터니

김기영, 한동균, 이선로, “프로젝트 관리자의 리더쉽과 참여자의 임파워먼트가 다중 정보시스템 개발 프로젝트의 성과에 미치는 영향”, 정보화정책, 16, 2, 2009, pp 103-122.

김은홍, 김화영 “SI 프로젝트에 있어서 프로젝트 관리자의 역량과 리더십 유형이 프로젝트 성과와 고객만족에 미치는 영향”, 한국정보관리학회, 31권 제4, 2006.12

김화영, 강소라, “IT프로젝트 관리자의 리더수비 유형별 역량이 프로젝트 성과에 미치는 영향”, 한국IT서비스학회지, 7, 2, 2008, pp 95-111. 

문용은, “IS 개발 프로젝트 관리자의 지식과 기술 그리고 경력개발경로”, 「Information Systems Review」, 한국경영정보학회, 제4권, 제2 호(2002), pp.343-360.

Mumford, M. D., S. J. Zaccaro, F. D. Harding, T. O. Jacobs, and E. A. Fleishman, “Leadership Skills for a Changing World:Solving Complex Social Problems”, Leadership Quarterly, Vol.11, No.1(2000), pp.11-35

Jurison, J., “Software Project Management:The Manager’s View,” Communications of the Association for Information Systems, Vol.2, Article 17(1999), pp.1-56.

Bassellier, G., B.H. Reich, and I. Benbasat, “Information Technology Competence of Business Managers:A Definition and Research Model,” Journal of Management Information Systems, Vol.17, No.4(2001), pp.159-182.

The roles of R&D team leaders in Korea: a contingent approach By: Youngbae Kim; Byungwook Min. R&D Management, Apr99, Vol. 29 Issue 2, p153, 13p, 7 charts; (AN 1828541)

Investigating project managers' work values by repertory grids interviews Author(s): Shi-Rui Song, Andrew Gale
Journal: Journal of Management Development Year: 2008  Volume: 27 Issue: 6 Page: 541 - 553

Collaborative competence in new product development and its performance effects  Journal of operations management ,v.27 no.4 ,2009 ,pp.324-338 

Matching the project manager's leadership style to project type  Muller, R. ; Turner, J.R.  ( International journal of project management : the journal of the International Project Management Association ,v.25 no.1 ,2007 ,pp.21-32  )

Senior management perceptions of project management competence  / Crawford, L.  ( International journal of project management : the journal of the International Project Management Association ,v.23 no.1 ,2005 ,pp.7-16  )

The Research of Project Managers' Competence  / Liu, M.-l. ; Zhang, Z.-g.  ( International conference on management science & engineering ,2004 ,2004 ,pp.2674-2678  )

A competency-based performance model for construction project managers  / Dainty, Andrew R.J. ; Cheng, Mei-I ; Moore, David R.  ( Construction management and economics ,v.22 no.8 ,2004 ,pp.877-886  )

Which skills do care managers need? A research project on skills, competency and continuing professional development  / Gorman, Helen  ( Social work education ,v.22 no.3 ,2003 ,pp.245-259  )

Managerial Competences for ERP Journeys  / Kræmmergaard, Pernille ; Rose, Jeremy  ( Information systems frontiers ,v.4 no.2 ,2002 ,pp.199-211  )

The project manager and the project-network  / Blackburn, S.  ( International journal of project management : the journal of the International Project Management Association ,v.20 no.3 ,2002 ,pp.199-204  )

12. Capabilities and Competency: 12.3 Project Manager Competence Model.Full Text Available By: Bolles, Dennis L.; Hubbard, Darrel G.. Power of Enterprise-Wide Project Management, 2006, p142-144, 3p; (AN 32721053

IT project managers' construction of successful project management practice: a repertory grid investigation.Citation Only Available By: Napier, Nannette P.; Keil, Mark; Tan, Felix B.. Information Systems Journal, May2009, Vol. 19 Issue 3, p255-282, 28p; DOI: 10.1111/j.1365-2575.2007.00264.x; (AN 37307722)

Posted by 노터니

프로젝트에서 목표(목적), 요구사항, 인도물 등의 단어들이 간혹 홍용, 교체되어 사용된다. 그러나 약간의 차이점은 있다.

목표(Goals)와 목적(objectives)은 프로젝트를 착수하기위한 취지이며, 프로젝트 최종 결과를 기술한 것이다.

프로젝트의 목적은 어떤 것을 할지, 어떤 것을 성취할 것인지에 대한 것이며, 그것이 목표이다.


1. 프로젝트 목표(Project Goals)

 목표는 수행하려는, 성취하려는, 제작하려는 것에 대해 기술한 것으로 목표와 목적은 현실적인 용어로 표현되어야 한다.

 목표가 달성되었을때 프로젝트가 완료된다. 목표와 목적은 결합될 수있고, 간단히 목표라고 부른다. 중요한것은 프로젝트의 최종 목적이 무엇인지, 그리고 그것이 성취되었을 때 어떻게 확인하는지에 대해 이해하는 것이다.


목표는 SMART규칙에 따라 정해진다.


S- Specific : 목표는 확실해야하며, 명확하고, 간결하고, 이해할 수 있는 용어로 표현되어야 한다.프로젝트 설립인가서와 범위 기술서에 문서화되어야 한다.


M-Measurable :목표는 측정될 수 있어야 한다. 프로젝트 또는 프로젝트 단계의 인도물은 검증 가능한 성과 또는 결과로서 측정 가능한 것이다.


A-Accurate : 목표는 적절해야하며, 무엇이 요구되는 지에 대해 정확히 기술된다. 요구사항 및 인도물의 검증과 측정은, 정확성을 결정하기 위해 또 프로젝트 계획에 따라 잘 진행되는지 확인하기위해 사용된다.

                   

R-Realisitic and tangible : 달성하기 불가능한 목표는 현실적이지 않으며 도달할 수 없다. 프로젝트는 유일하며, 현실적인 제품 또는 서비스를 생산한다. 모든 프로젝트의 3대 제약(시간, 돈, 품질)은 프로젝트에 주어진 제약의 한계에 기반하여 현실적인 목표, 현실적인 요구사항의 정의를 돕는다.


T-Time bound : 목표는 할당된 종료 날짜를 가진 시간 프레임을 갖는다. 프로젝트는 명확한 개시일과 종료일을 갖는 특정 시간프레임 내에서 수행된다.



2. 프로젝트 요구사항(Project Requirements)

요구사항은 목표 및 목적과 같은 것이 아니며, 목표 또는 인도물의 명세서이다.


3. 프로젝트 인도물(Project Deliverables)

인도물이란 프로젝트 또는 프로젝트 단계의 완료를 결정하기 위해 생산되어야 하는 측정 가능한 성과물, 또는 결과물, 또는 특정 품목이다.

인도물은 목표와 같이 확실하며, 검증가능해야 한다.


프로젝트 기술을 얼마나 잘 저용하든지 상관없이, 잘못된 인도물이나 프로젝트가 잘못된 목표로 관리된다면, 프로젝트는 결국 실패하게 된다.


4. 이해관계자(Stakeholders)

PMOK가이드에 따르면 이해관계자는 기획 프로세스에서 공식적으로 그 신원이 확인된다. 그러나 핵심 이해관계자의 경우 프로젝트 개요, 목표, 인도물을 위한 그들의 투입물을 얻기 위하여 좀더 일찍 접촉하게 된다.

이해관계자는 프로젝트 후원자, 고객(프로젝트 후원자와 동일할 수 있다.), 프로젝트 관리자, 프로젝트 팀원, 경영인원, 게약자, 공급자 등이 포함된다. 이해 관계자는 조직의 내부 또는 외부에 존재할 수 있다.


이해 관계자들과의 의사소통

프로젝트의 확실한 목표를 결정하기 위해, 핵심 이해관계자들과 만나 프로젝트의 목표에 대한 그들의 아이디어를 문서화해햐한다.

프로젝트에 관한 그들의 필요성과 관심에 대해 이해하라.

프로젝트가 왜 필요한지에 대해 물어라

프로젝트가 어떤 비즈니스 프로세스를 변경하고 강화하는지 또 대치하는지 물어라.

이 프로젝트를 위한 중대한 비즈니스적 필요성이 있는지 또는 그저 가지면 좋을 정도인지 확인하라.

이 프로젝트의 결과는 무엇인가? 고객 서비스가 향산되는가? 판매가 증진되는가?

프로젝트가 달성될 때, 그들이 바라는 결과물을 얻는 것에 방해 요인이 있다면 그것을 발견하라.

인도물 및 그들이 어떻게 검증하고 측정할 것인지 확인하라.

프로젝트가 성공적으로 완료되었는지 어떻게 알 수있는지 이해관계자에게 확인하라.


성공적인 프로젝트의 정의는 이해관계자들의 기대를 충족시키는 것임을 기억하라. 그들의 기대를 이해하고 문서화 하라.


프로젝트 목표를 확인하는 한 가지 방법은 프로젝트에 무엇이 포함되지 않는가에 대해 살펴보는 것이다.


5. 프로젝트 개요 문서

프로젝트 개요 문서는 프로젝트 목표와 인도물에 대한 고수준의 내용을 제공한다.

프로젝트 및 인도물에대한 계획된 성과를 파악하는 목적인 된다.

프로젝트의 간략한 배경 및 회사에서 이용하려는 비즈니스 기회에 대한 내용을 제공한다.

프로젝트가 달성해야 할 비즈니스 목적에 대해 기술한다.

개요는 인도물과 프로젝트의 기대에 대해, 미래의 합의를 위한 기초를 제공한다.


일부 조직은 이 시점에 타당성 조사(feasibility study)를 요구 할 수 있다.

타당성 조사는 프로젝트가 실행 가능한지를 결정하기위해, 성공가능성을 확인하기 위해, 프로젝트 제품의 현실성을 검토하는데 이용된다.

프로젝트와 관련 있는 기술적인 이슈에 대한 것이나, 제안된 기술이 타당하고 신뢰할 수 있고 조직의 기존 기술 구조에 쉽게 동화 할 수 있는지를 결정하는 것에 이용된다.


타당성 조사를 실시하는 사람들은 프로젝트에서 일하는 사람들과 동일해선 안된다. 프로젝트 팀원은 프로젝트에 친화적일 수 있고, 그것은 타당성 조사의 결론에 영향을 줄 수 있기 때문이다.


-------------------------

출처 : 정보문화사의 "Project Management Professinal"(킴 헬멘 저/류한석 역)


Posted by 노터니
프로젝트의 목표를 정의하고 실천하기 위해 위한 기준을 다음과 같이 SMART의 이니셜로 설명한 것이 도란의 SMART 방법론입니다.
프로젝트 실무를 여러분은 얼마나 SMART한지 확인해 보기 바랍니다.
 
1) Specific: 목표 정의가 명쾌해야 합니다.프로젝트 관리가 성공하기 위해서는 무엇보다도
목표가 분명해야 합니다. 목표가 분명하다는 것은 프로젝트의 생성에서부터 타당성 검토가 이루어져야 하고, 고객 및 이해 관계자의 요구 사항을
정의하는 것에서부터 출발합니다. 프로젝트 관리 방법론에서는 작업 목록을 WBS(work break-down structure)라고 부릅니다.
프로젝트의 목표는 WBS로 구현되므로, WBS의 원리와 구성 방법론을 체계적으로 이해해야 합니다. WBS에는 산출물과 단계가 분명하게 반영되어야
하며, 관리 가능한 범위 내에서 합리적으로 구현해야 합니다.
 
2) Measurable: 측정 가능한 진행 상황 관리 기준을 수립해야 합니다.
피터 드러커도 “측정할 수 없으면, 관리할 수 없다”라고 지적하였듯이, 프로젝트 계획이 구체적인 수치로 정량화되지 않으면, 관리 기준을
분명히 적용할 수 없습니다. 단순히 측정 가능해서는 부족하며, 측정 값을 시각적인 차트와 그래픽 표시기로 제시하여 직관적이고 정확한 분석을 할
수 있어야 합니다.
측정 가능한 프로젝트 계획을 수립하기 위해서 작업은 어떻게 분해해야 하는지, 진행율은 어떻게 측정할 것인지 계획 단계에서부터 고려해야
합니다. 작업에 대한 여유 시간은 얼마나 되는지, 가용 자원으로 수행 가능한지 측정할 수 있어야 합니다. 계획 대비 실적의 차이는 얼마나
되는지, 상황 보고 시점에서 프로젝트의 범위, 일정, 작업량, 예산은 어떠한지 측정할 수 있어야 합니다. 프로젝트의 착수 시점부터 완료 시점까지
모든 업무를 측정 가능하게 계획하고 실행하는 방법을 이해해야 합니다.
 
3) Assignable: 목표 완수를 위한 한 명의 책임자를 지정합니다.프로젝트의 수행도를 높이기
위한 최소한의 기본 지침은 업무의 책임을 분명히 하는 것입니다. 자원을 배정하는 기준은 업무 수행 능력 뿐만 아니라 책임성이 함께 있어야
합니다. 프로젝트를 수행하는 주체는 결국 프로젝트 팀원이며, 팀원들은 프로젝트의 가장 중요한 자원인 시간과 돈을 쓰는 존재이기 때문입니다.
프로젝트의 수행도를 높이고 책임 있는 업무 수행을 위해서는 프로젝트 관리자의 역할론을 이해하고 효율적인 의사 소통 방법을 이해할 필요가
있습니다. 조지 도란이 제시한 SMART 의 A가 잘못 제시되는 경우가 많습니다. 예를 들면, acceptable, agreed-on,
action-oriented, attainable, achievable, appointable, aligned, accountable 등
다양하게 해석하고 있습니다. 그러나 분명한 것은 프로젝트 관리에서 자원의 책임성을 강조한 자원 배정 적합성이 매우 중요하다는 것입니다.
 
4) Realistic: 현실적인 제약 조건을 조정할 수 있어야 합니다.프로젝트의 계획은 현실성이
있어야 합니다. 현실적인 원칙이란 제한된 시간, 예산 및 자원의 체계적인 운영을 의미합니다. 프로젝트의 현실적인 운영을 위해 필요한 고려 사항은
범위, 시간, 예산, 품질, 작업량이 있으며 이들 제약 조건들은 상호 영향 관계에 있습니다.
 
5) Time-related: 작업은 분명한 기간을 가져야 합니다.프로젝트 관리자에게 가장 중요한
사고는 시간 개념입니다. 모든 작업은 기간과 작업량을 가집니다. 뿐만 아니라 프로젝트의 모든 관리 기준 구성 요소들은 시간 요소를 갖습니다.
정보의 가치는 시간 선상에서 의미를 가지며, 정보 공유 시점이 지난 모든 프로젝트 정보는 가치를 상실하기 때문입니다.
Posted by 노터니
Robert L. Bogue ( TechRepublic )

프로젝트를 수행하는 데 있어 제대로 된 시스템 구축 업체를 선정하려면 상당한 시간을 투자해야 한다. 이 과정에서 맞닥뜨릴 수 있는 문제와 대처 방법에 대해 알아보도록 하자.

기업이 성장세에 있다면 그 기업의 IT 부서 또한 힘을 키워갈 수 있다. 기업의 투자비를 자기네 회사로 돌리려 애쓰는 업체들이 즐비한 현실에서 실제적인 도움을 얻어내는 방법을 아는 것은 필수 사항이다. 이 부분을 정확히 파악하려면 무엇이 문제이고 무엇이 중요하며 어떤 것이 중요하지 않은지 분류해내는 것이 핵심이다. 지금부터 하나씩 알아보도록 하자.

제대로 된 업체 선정, 어떤 이득을 주나
정확한 업체 선정 과정은 상당히 시간을 잡아먹는 일이다. 조직이 성장하는 과정에서 협력사 역할을 하게 될, 제대로 된 업체를 찾는다는 것은 어찌보면 시간이 해결해주는 문제이긴 하다. 그러나 이들이 부여된 임무를 제대로 해결하지 못할 경우 신속하게 다른 업체를 선정해 바꾼다 하더라도 문제는 산적해 있다.

첫번째 문제는 바로 업무의 연속성이 끊긴다는 점이다. 이 말은 방향이 자주 바뀐다는 뜻이기도 하다. 일이 조금 바뀌는 것뿐이라고 하찮게 여길지 모르겠지만 낙숫물이 바위를 뚫는다는 격언이 있다. 처음엔 IBM 웹스피어/자바 개발 전략을 미는 업체와 일하다가 1년 뒤 윈도우/ASP.NET 전략에 끌려다닐지도 모른다.

여기에 협력사가 계속 갈팡질팡한다는 건 조직 내 환경을 확실히 인지하도록 재교육해야 한다는 것을 뜻한다. 업체들에겐 재교육이 기껏해야 몇 시간 정도겠지만 몇차례 누적된다면 얘기가 달라진다.

두 번째 문제는 가능성 있는 업체를 너무 부려먹을 때 일어난다. 기업들은 종종 연락이 닿는 모든 컨설팅 업체를 “쥐어짜내며” 한번이라도 함께 일한 컨설팅 회사는 불쾌한 경험만 잔뜩 얻게 된다. 결국 해당 기업은 필요할 때 지원을 받기 어렵게 되거나 아예 지원 요구조차 불가능해지게 된다. 이제 컨설팅 회사들은 이 기업과 일하길 거부하거나 웃돈을 요구한다.

세 번째 문제는 시스템에서 작업하는 사람 중 신원이 확실하지 않은 사람들이 너무 많아져 위험도가 증가하는 경우다. 이들은 보안 취약점을 만들거나, 서버를 망가뜨리거나, 기업 데이터를 도둑질하거나, 데이터를 파괴할 확률이 상당히 높다.

용역 직원을 고용할 때 발생하는 위험이야 어쩔 수 없이 당연한 것일 수 있지만 그렇다고 그냥 넘어갈 순 없는 부분이다. 업체를 변경하면서 이런 위험만 심화될 수도 있다.

처음에 제대로 된 업체를 선정하는 데 도움이 될만한 몇 가지 팁을 소개한다.

1. 임계 질량을 찾아라
업체 선정시 해당 분야에서 충분한 능력을 보유한, 물리학적 용어로 “임계질량”을 보유한 업체를 찾아라. 임계 질량이란 충분히 자족할 수 있는 포인트를 뜻한다. 즉 셰어포인트(SharePoint) 컨설턴트 한 명을 고용할 경우 그 자가 유일한 쉐어포인트 컨설턴트가 아니란 점을 인지해야 한다.

기업들은 자사 고유의 방식으로 시장에서 승부를 보려하는 경우가 많다. 자신들에게 이 시장이 맞는지 알아보겠다는 차원에서 업체들은 시장을 점유하려 안간힘을 쓴다. 처음에 저렴하게 구축할 수 있을지는 몰라도 만약 이 업체가 시장에서 철수해버린다면 어떻게 할 것인가?

고유한 방식으로 승부하는 업체와 일했을 때 얻을 수 있는, 얼마 안되는 비용 절감은 구축 업체를 새로 바꿀 때 드는 비용, 그리고 제대로 된 업체를 물색하는 데 드는 비용과 비교할 때 턱없이 작을 경우가 많다.

2. 원하는 것을 선택하라, 그리고 비용을 지불하라
기대한 업체를 찾아냈는데도 곤란한 상황에 놓이는 경우는 두가지가 있을 수 있다. 먼저 업체가 제안서에 명기했던 인력이 다른 사람으로 바뀌는 경우다. 계약 단계가 완료되기도 전에 업체가 제안한 사람이 다른 일 때문에 사라져 버린다.

그래도 이런 건 애교로 봐줄 수 있는 문제다. 어떤 경우엔 프로젝트에 절대 어울리지 않는 사람, 즉 완전히 다른 프로젝트에서 일하고 있는 사람들이 면전에 등장하기도 한다. 구축 업체들은 발주 프로젝트에 적합한 인력을 보유하고 있다는 점을 전면에 내세우기 위해 이런 행동을 하기도 한다.

물론 이들이 정말로 제대로 된 인력을 보유하고 있을 수도 있다. 하지만 문제는 실제 프로젝트에서 일할 수 있는 제대로 된 인력을 얻을 수 있느냐 없느냐에 있다.

프로젝트에 제대로 된 인력을 얻으려면 협상 단계를 거친 이후 계약 단계에서도 인력에 대한 동의를 얻어야 한다고 고집해야 한다. 이처럼 단계를 마련해놓으면 애초 약속된 인력들이 예기치 않게 다른 프로젝트로 사라져버릴 경우 업체가 바꾼 인력으로 계속할지 여부를 승인할 수 있는 권리를 갖게 된다.

인력 수급 계획이 갑자기 바뀌는 문제 뿐 아니라 비공식적으로 주변을 확인하는 것도 상당히 중요하다. 프로젝트에 관련된 사람이 아닌, 이미 회사가 알고 있던 다른 인력들에게 조언을 구할 때 문제가 없어야 한다. 이들은 다른 업체들이 추천한 사람일수록 좋으며 보통 모르는 사람보다 예전에 함께 일했으며 계속 관계를 유지해온 사람이 좋다.

이들은 조직의 능력과 약점에 대해 균형감있게 이야기해 줄 수 있을 것이다. 나아가 어떤 경우에는 이들과 프로젝트를 진행하게 될 수도 있다. 이럴 경우 기대하는 바를 명확히 이해시킬 수 있게 되며 프로젝트에서 기대치가 뭘 의미하는지 심사숙고할 수 있을 것이다.

3. 전략을 선정하라
장기 프로젝트에서는 제대로 된 업체를 선정하고 잠재 비용을 산출해 내는 것이 매우 중요하며 오판의 위험 또한 산재해 있기 때문에 장기간을 두고 검토하는 게 필수적이다. 선정한 업체는 조직의 성장과 함께 계속 진행하게 될 일에 충분한 관심을 갖고 있어야 한다. 이 말은 구축 업체들이 조직 자체를 하나의 고객으로 여겨야 한다는 것이다.

만약 몇 개 업체와 함께 프로젝트의 범위를 넓힐 때 각 업체별로 규정된 작업 패턴을 고수하지 않는다면 이들은 진정한 파트너가 되지 않을 것이다. 가장 먼저 구축 업체의 목적에 부합해주지 못하고 있기 때문이다.

반대로 업체의 소득을 너무 많이, 즉 50% 이상 보장해주는 것도 위험하다. 이렇게 하면 어쨌든 구축업체가 향후에도 프로젝트가 계속될 것이라는 생각을 가짐으로써 프로젝트 지연에 속수무책이 될 수도 있다.

누구나 구축 업체를 파트너라고 지칭하며 이야기한다. 하지만 그것이 뭘 의미하는지는 서로 다른 경우가 많다. IT 업체와 파트너 관계를 가지려면 기업 고객과 업체 양쪽 모두에 이득이 되는 상황을 만들어내기 위해 함께 노력해야 한다.

그러나 많은 업체들이 말하는 협력 관계는 업체들에게 돈을 줄 준비가 돼 있으며 업체는 돈을 수중에 넣게 된다는 것만을 의미하는 경우도 종종 있다. 또한 많은 기업 조직들은 컨설팅 회사와 파트너 관계를 원한다고 이야기할 때 컨설팅 회사가 그다지 많은 비용을 청구하지 않으며 조직들이 단시간 내에 혜택을 볼 수 있도록 해달라는 취지로 말하기도 한다.

협력업체를 물색하는 것은 당사자들끼리 마음을 트고, 마음을 열 수 있는 업체를 찾는 것이다. 기업 고객들은 정직하게 필요한 것을 얘기하며 구축 업체드은 필요한 걸 충족시키기 위해 최상의 해결책을 찾도록 노력하는 것이다.

자, 지금 당신 앞에서 제안서를 들고 있는 시스템 구축업체가 협력관계로 발전하고 있는지 알고 싶은가? 그렇다면 지금 내가 이들에게 뭘 감추고 있는지 자문하면 된다. 현 예산에서 얼마나 많이 감추고 있는가? 업체가 해주지 못할 것이라고 미리 결정내린 다음 말하지 않는 것은 무엇인가? 여기에 한개라도 “그렇다”라는 답이 나온다면 구축업체와 끈끈한 협력관계에 있지 않다는 증거일 것이다. @
Posted by 노터니
사용자 삽입 이미지

프로젝트의 실행에 있어서 참여하거나 이해관계가 얽혀 있는 사람들은 상당히 많다. 이렇게 프로젝트에 얽혀 있거나 이해관계가 있는 사람들을 통틀어 "이해관계자"라고 한다. 영어로는 stakeholders라고 한다.

PMBOK에서 이야기하는 이해관계자의 정의와 역할은 다음과 같다.

프로젝트 이해관계자란 프로젝트에 적극적으로 참여하거나 프로젝트의 실행이나 완료결과에 따라 이해 관계에 영향을 받을 수 있는 개인이나 조직을 가리킨다.

프로젝트 이해관계자들은 프로젝트의 목표와 결과물에도 영향력을 행사할 수 있다. 프로젝트 관리팀은 프로젝트를 성공으로 이끌기 위해 이해관계자가 누구인지 식별하고 그들의 요구사항과 기대치를 파악하고, 나아가 그러한 요구사항에 대한 이해관계자의 영향력을 가능한 수준으로 관리해야 한다.


일반적으로 프로젝트 이해관계자로 꼽는 사람 또는 조직은 다음과 같은 것들이 있다.
  • 프로젝트 관리자
  • 고객/사용자
  • 수행조직
  • 프로젝트 팀원
  • 프로젝트 관리팀
  • 스폰서
  • 영향력 행사자
  • 프로젝트 관리 오피스(PMO)
사용자 삽입 이미지

이 외에도 내/외부 관계자, 고용주, 투자자, 판매자, 발주자, 팀원들의 가족, 정부기관, 언론, 일반시민, 로비단체, 지역사회 등이 넓은 의미의 이해관계자라고 할 수도 있다.

그런데 위의 도식에서 보면 일반적인 프로젝트의 이해관계자를 표시하지 않고, 내가 나름대로 중요하다고 생각되는 사람/조직을 중심으로 수정해 표시하였다. 특히 "학습자"라는 이해관계자를 붉은색으로 표시를 해 놓았다. 이유는 이러닝 프로젝트, 이러닝 콘텐츠와 관련된 프로젝트에서는 "학습자"가 중심이 되어야하기 때문이다. 학습자는 고객임과 동시에 사용자이다. 이러닝은 학습자 중심으로 구성되어야 하며, 학습의 방식 자체도 자기주도적인 학습으로 진행되기 때문에 "학습자"는 가장 중요하면서도 핵심 이해관계자라고 할 수 있다.

Posted by 노터니
요구사항을 정리하는데 난항이 있다. 고객쪽 수행팀장과 실무자 사이에 견해가 다른 것이다. 실무자 중에서도 수행팀에 속한 TFT 직원과 아닌 사람 사이에도 이견이 있었다. 부서 책임자의 결정으로 미뤄지자 그야말로 사안은 장기 계류(繫留)가 되었다. 복잡한 머리를 식히러 잠시 서점에 들러 본 책에 눈에 띄는 그림이 있었다.

사용자 삽입 이미지
이미지: Managing Agile Projects (Robert C. Martin Series)에서 발췌

안과장은 프로젝트에 당위성을 부여한 부서장과 면담하는 시간을 가질 수 있었다. 부서장의 이야기는 명쾌했다. 그리고, 그는 확고한 비전을 가진 사람이었고, 이 프로젝트는 그의 비전이 그대로 투영된 산물이었다. 신념을 가진 사람과 함께 있으면 동화되기 마련이다. 안과장은 마음으로 고객이기도 그를 최대한 도와야겠다고 마음 먹었다. 부서장 면담이 있고 얼마후 실무자들과 협의를 하는데 자신이 자꾸만 부서장 입장을 변호하는 듯한 위치에 서게 된 느낌이었다. 퍼뜩 놀라 잠시 말을 거두었다.

머릿속으로 부서장 입장에서 시스템이 만들어지고 난 이후를 떠올려보았다. 그리고, 시스템을 실제로 활용할 실무자 입장에도 서봤다. 그리고 시스템의 당위성을 사내에 알릴 테스크포스의 역할까지... 그럴수록 상황이 점점 더 명확해졌다. 몇 주가 지난 지금 안과장은 이해관계자를 유형화 해서 바라보는 것이 상황을 얼마나 명쾌하게 해주는지 알 수 있었다. 사실 그러한 깨달음은 별다른 것도 아니다. 학창 시절 배웠던 포터의 5 forces가 그러하고, 아키텍처를 논할 때 항상 언급하는 4+1뷰도 동일한 원리의 다른 표현일 뿐이다.

Diagram of Porter's 5 Forces
이미지 출처: http://www.usdoj.gov/atr/public/hearings/single_firm/docs/219395.htm

전략적 목표를 가지고 조직의 포석을 결정할 사람의 이해와 당장 업무 편의성이 필요한 실무자의 입장이 다른 것은 자연스러운 일이다. 또한, 책임소재를 가진 사람 즉, 프로젝트를 만드는데 일조한 부서와 책임은 없이 향후 시스템 사용자가 되는 부서의 입장은 확연하게 다르다.
Posted by 노터니
쓸만한 체크리스트...가 있다면 짧은 시간에 무언가 점검할 수 있다. 우연히 발견한 글에서 소개한 10가지 체크리스트를 가지고 현장에서 경험을 덧붙여본다.

1) 범위에 따른 착수와 종료 시점의 설정이 불분명

범위라는 것은 합의 혹은 협약에 기반한 것이다. 일정 규모 이상의 프로젝트는 다자간의 계약이기 때문에 협약이 만만치 않다. 어느 정도 신뢰 관계 형성이 가능한 경우라면, 프로젝트 목적에 대한 공유가 잘 될수록 프로젝트 성공 확율이 높다. 만일 신뢰 관계 형성이 어렵고, 어떤 이유로든 직접적인 의사소통이 어려운 경우라면 철저한 계약이 뒤따라야 한다. 프로젝트가 길어지면, 주고 받는 정보의 양이 방대해지고, 관리해야 할 산출물은 늘어나기 마련이다. 필연적으로 범위의 경계가 모호해지고, 범위에 걸친 것으로 보이는 요구사항들이 속출한다. 범위를 기준으로 작업 내역이 지속적으로 관리 테두리안에 담을 수 있게 종종 숨고르기를 해야 한다.1 필요하다면 관리 대상을 추려내거나 혹은 추상화 하고 적절히 위임하지 않으면 언젠가 손댈 수 없게 될지도 모른다.

착수종료 시점에 대해 특히 말하고 싶은 점은 인위적으로 나눈 날짜에 연연하지 말자는 것이다. 날짜를 맞추느라 정해진 기간(단계, 반복) 탓에 일하다 말고 잠시 이것 저것 부산하게 정리하느라 힘을 빼면 곤란하지 않은가? 한참 페이스가 올랐는데 보고서 쓰느라 진 빼다가 다시 재가열을 하는 소모적인 날들을 보내서는 곤란하지 않는가? 역시 팀원 및 다양한 계약 주체 사이의 합의 혹은 목적의식 공유에 입각한 시작과 종료가 중요하다.

2) 개별 작업의 일정 변경이 프로젝트 전체에 주는 영향도를 이해하지 못함

과학적인 접근 방식을 고려하자면 요주의 경로(Critical Path) 같은 것이 있지만, 마일스톤(Milestone)에 입각한 접근을 혼용하라고 하고 싶다. 분할된 작업 사이의 연관성을 파악해서 미세하게 관리하는 것도 방법이겠지만, 프로젝트 범위진척에 미치는 영향이 큰 작업을 기준으로 삼는 것도 좋다. 미세하게 쪼개진 작업을 기준으로 할 때보다 오히려 목적 공유에 유리하다. 하지만 마일스톤을 제대로 뽑아내려면 프로젝트 범위를 이루는 항목에 대한 우선순위가 분명해야 한다.

3) 프로젝트 추진 계획 대비 실적을 정확히 알고 있지 못함

무엇을 관리하든 계획 대비 실적은 핵심적인 지표다. 진척 산정에 있어 가장 관심이 가는 내용은 말단의 진척율을 무엇은 기준으로 산정하는가다. 단순히 기간 내에 작업을 완수했거나 산출물을 만들어낸 것으로 충분할까? 검증, 확인, 테스트 등이 실적 산정의 기준이 되어야 한다.

4) 현재 시점에서 우선적으로 처리해야 되는 일이 무엇인지 모름

잘 만들어진 방법론은 작업지시서를 통해 특정 시점에서 역할에 따른 지침을 제공한다. 하지만, PM이라고 한다면 1,2,3번을 통해 4번에 대한 센서는 늘 켜져 있어야 한다.

5) 문제점 발생 시 또는 최종 결과물의 잘못에 대한 책임 한계가 불분명(업무 범위와 책임 관계 설정이 어렵다)

1번의 범위 문제와 같은 맥락에서 볼 수 있다. 프로젝트 범위는 결국 분할하면 개인의 역할과 책임으로 연이어 진다.

6) 텍스트 중심으로 기술한 직관적이지 못한 보고서

정보의 양에 따라 다르다. 대개 취급해야 하는 정보가 많은 경우복합적인 경우 텍스트 문서는 효용성이 떨어진다. 표, 차트, 모형 등이 빛을 발한다.

7) 보고서 만드는데 들이는 엄청나고 아까운 시간, 시간, 시간

취합하여 만드는 보고서와 다단계 보고는 비효율의 궁극이다. 인터넷 비즈니스의 파괴력은 중개인(intermediary)이 없어진데서 비롯한다. 프로젝트에서도 중개인이 사라지고 infomediary가 자리를 차지할 날이 올 것이다.

8) 문제와 리스크는 터지고 나면 대처하기 위해 전력을 다함 (Reactive)

잠재위험에 대한 사전 대응은 매우 중요하다. 그러기 위해서는 다양한 정보에 민감해야 한다.

9) 다수 계약자 및 부서 별 연관된 업무 특성으로 통합 관리 역량 미흡

갈등을 피하지 말고, 적시에 R&R 분장을 이끌어내라. 무지막지하게 중요하지만, 달성하기가 그리 녹록하지 않다.

10) 일관된 사업관리 체계 부재 및 프로젝트 관리 기술 부족

PM으로써는 기본기나 조직력이다. 기본기가 없거나 조직력이 없는데 월드컵 본선에 나가겠다는 것인가?


Posted by 노터니

Project Stakeholder Management focuses on the human dynamics of a project environment: managing relationships and communications. This essential process can help to ensure that your projects succeed where others fail.

We will present here a simple step-by-step process to help Project Managers cope with the demands of managing all the varied project stakeholders, named the ‘ice-cube’ model (because we have 6 steps like the 6 sides of a cube, and we name the steps I-C-E, I-C-E).

ICE-CUBE

Here are the steps:

1. IDENTIFY the project stakeholders, by asking yourself:

  • Who will be affected by the project or its deliverable?
  • Who will get the responsibility of supporting the product once the project is over?
  • Any external contractors or suppliers?
  • Any government or regulatory requirements?

2. CLASSIFY and group the stakeholders by Interest and Influence

3. Gain an understanding, and manage, their EXPECTATIONS

4. INFLUENCE the stakeholders, by educating them about the benefits of your project

5. COMMUNICATE and get everyone involved as soon as possible

6. EVALUATE to check that your strategy is working, and also check for any changes in stakeholder groups

The process is discussed fully in the Article, available in the download section of this website.


Posted by 노터니

Conducting Successful Interviews With Project Stakeholders

By Steve Baty

Published: September 10, 2007

A simple, semi-structured, one-on-one interview can provide a very rich source of insights.

If you’ve read some of my previous columns on UXmatters, you could be forgiven for thinking my entire working life is spent largely surrounded in a sea of quantitative data. This is, rather surprisingly even to me, not nearly close to the truth. Looking back over recent months, by far the most common form of research I’ve carried out is that stalwart of qualitative studies—the interview.

A simple, semi-structured, one-on-one interview can provide a very rich source of insights. Interviews work very well for gaining insights from both internal and external stakeholders, as well as from actual users of a system under consideration. Though, in this column, I’ll focus on stakeholder interviews rather than user interviews. (And I’ll come back to that word, insights, a little later on, because it’s important.)

Ten Guidelines for Stakeholder Interviews

Here are ten general guidelines I follow when conducting stakeholder interviews:

1. Set aside at least 45 minutes for each interview.

I often find I don’t need all of this time. However, occasionally, I do need all of it and am glad I allowed plenty of time. I’ve been lucky, on a few occasions, to interview people who not only understood the topic under study, but were also able to clearly articulate their thoughts. Such interviews are golden—for both the quality of insights they can generate and because of their rarity.

Suffice it to say, as you conduct more and more interviews, you’ll come to appreciate these golden moments and appreciate having the luxury of some extra time to interview such insightful stakeholders.

Conversely, I don’t feel compelled to stretch out an interview just to fill up a time slot. There are times when the person I’m interviewing doesn’t have a lot to contribute. In such cases, don’t waste their time or your’s. (I don’t mean to sound arrogant here. It’s quite frequently the case that I don’t get to nominate everyone on the interview list. Sometimes clients suggest that I interview certain people they think will be good sources of information about such-and-such, but they don’t necessarily understand what I need.)

2. Leave at least 30 minutes between interviews.

I use this time between interviews for two things:

  • making any additional notes I wasn’t able to capture during the interview itself
  • clearing my mind before the next interview

I can’t stress enough how important this time is—especially if I’m conducting more than four or five interviews in one day.

3. Limit an interview to just three or four major topics.

These might be topics like the following:

  • What are the brand values?
  • What sets your organization apart from competitors?
  • What is the next big challenge?
  • What does success look like?

I might ask three or four questions about each topic, depending on the length and quality of the answers I receive.

4. Talk about culture, challenges, and goals, not features.

“I don’t want them to talk about features, functionality, content, search engine optimization, or anything else that deals with a solution.”

I’ll usually let business stakeholders talk about just about anything within the scope of the topics for an interview—with one exception: I don’t want them to talk about features, functionality, content, search engine optimization, or anything else that deals with a solution.

Sometimes, though, it can be almost impossible to get an interviewee to let go of making the case for some pet feature they’ve decided a Web site, application, or widget absolutely needs. If this happens, I try to move the interview back on topic with a simple question: “What issue does this feature address? Let’s talk about that for a moment.”

5. Be prepared for your interviews.

Preparation includes obvious things like making sure you have a pen that works. Before conducting any interviews with internal stakeholders, I always try to get my hands on the following materials:

  • a copy of the company’s most recent annual report
  • any recent research the company has undertaken on anything related to the business—strategy, positioning, product range, brand awareness—going as far back as their last major business planning or strategy document
  • a copy of their last major business planning or strategy document
  • copies of print advertisements currently in circulation
  • vision and mission statements, if they exist
  • the company’s organization chart

There are several reasons for doing this:

  • I don’t like to waste either my or the interviewee’s time, asking a question that’s already been answered, unless I want specifically to verify that what they say matches what appears in those documents.
  • I find it works well if I can ask questions that are based on the company’s own internal documentation and plans.
  • Interviewees appreciate the effort I’ve made to read and familiarize myself with this material before speaking with them.
  • Finally, this preparation allows me to better spot inconsistencies between operational policy and strategy.

6. Let interviewees know in advance what you’ll ask them.

It’s easy to forget that it might be the first time interviewees have ever been asked to participate in something like this.”

Whenever possible, I let interviewees know in advance what I’ll be asking—or at least the three or four main topics I’ve planned to discuss.

Once in a while, I get an interviewee who’s nervous, which is so unexpected. And yet, it finally made sense to me when an interviewee said, “I don’t know why I’m here! I don’t know anything about the Web.”

“That’s okay,” I said, “we’re not going to talk about the Web,” which led to a mixture of relief and confusion.

Such problems generally arise in cases where I can’t communicate directly with interviewees beforehand. I ran into this problem recently when conducting stakeholder research for a government project. I had to coordinate all interviews through a designated project contact, who chose not to disseminate the interview topics. This meant that none of the interviewees showed up with any clear idea of why they were there. One interviewee brought along a marked-up screen shot of a single page from the current Web site, which wasn’t even the project under discussion.

Since I work on such research projects every day—and have done for a few years, now—it’s easy to forget that it might be the first time interviewees have ever been asked to participate in something like this—especially in a research project related to the Internet—and they’re concerned about doing it properly.

So, let interviewees know the topics of discussion ahead of time, because

  • they’ll feel more comfortable
  • they’ll be better prepared
  • you’ll get more directed responses

7. Don’t be afraid to ask one interviewee to comment on something another interviewee said.

“Interview as many people as you feel is necessary for you to build up a clear picture of an organization with respect to the project at hand.”

Each interview adds to your overall picture of an organization, so whenever possible, I try to get interviewees to comment on or respond to things others have said. I’ve had cases where the head of one business unit has blamed the organization’s poor performance or capability on another business unit or some deficiency elsewhere. It’s entirely unlikely that Business Unit Head A is confiding some deep secret to you, so I feel quite comfortable putting that comment to Business Unit Head B and asking for his or her take on the issue.

The idea here is not to foment discord, but to take the opportunity the first comment presents to gain a deeper understanding of the issue. Don’t shy away from such internal tensions!

8. There is no correct number of interviews.

Interview as many people as you feel is necessary for you to build up a clear picture of an organization with respect to the project at hand. Sometimes this can be as few as three or four interviewees, and I’ve had projects where I’ve conducted twelve or more interviews.

9. If necessary, ask an interviewee to wait while you make a note.

I find interviewees are more than happy to hold off talking, so you can make note about something they’ve said. This is particularly important if you want to record a direct quotation before continuing with your next question.

A note about taking notes: I always take my own notes—whether I’m conducting an interview over the phone or face to face. If I have another person with me on the interview, I still take my own notes. I also have one rule: The other person doesn’t ask any questions. This might seem strange to you, but I’ve found from experience that having two people asking questions ruins the flow of the interview.

10. Decide for yourself whether you’ll record interviews.

“I still have all the notes I’ve taken during interviews, and I still refer to them on occasion.”

I never record interviews. Well, I did once. I went to a great deal of effort getting permission to record from each interviewee, recording each interview, creating a transcript of each interview, and storing both the audio and the transcripts. Nobody has ever listened to the recordings or read the transcripts. So, five years on, I still have all the notes I’ve taken during interviews, and I still refer to them on occasion.

The archaeologist in me knows this is probably not the best approach, since I’m missing my one and only chance to make a recording of an interview. However, it doesn’t feel natural for me, and I know it affects the way I go about the interview when I do record, so I don’t do it. You should try this out for yourself though, and make up your own mind.

The Benefit of Keeping Your Interviews Informal

It’s important to remember that you’re doing informal, semi-structured interviews, not taking testimony. Why informal and semi-structured?

Interviews are an excellent way of drawing out people’s perceptions and thinking.

Given the opportunity, I’d like to ask a company’s CEO or COO different questions from those I’d ask, say, the customer service manager or the logistics manager. Working at very different levels of an organization, with narrower or more broadly defined areas of influence, stakeholders’ perceptions and thinking on each topic will be quite different.

Recall that I earlier mentioned I use interviews to gain insights. I find interviews are an excellent way of drawing out people’s perceptions and thinking. They do this much more effectively than a survey or questionnaire could ever do. The reason for this is the ability of an interviewer to ask follow-up, probing questions to clarify or expand on an idea.

Documenting the Outcomes of Stakeholder Interviews

“The most useful deliverable from a set of stakeholder interviews is a summary document that provides a general overview of the picture you’ve built up through the interview process.”

The most useful deliverable from a set of stakeholder interviews is a summary document that provides a general overview of the picture you’ve built up through the interview process. My summary documents usually combine information I’ve gleaned from the literature I read before beginning the interviews and the responses interviewees have given to my questions. Where relevant, I use direct quotations to highlight or illustrate a particularly important point.

I also try to highlight cases where interviewees’ responses to questions indicate attitudes or operational policies that do not support the documented strategy or brand values. Such cases often show critical areas for realignment prior to the commencement of a project’s design phase. If a project involves work on an existing system, I also try to highlight areas of that system that aren’t aligned with the documented or de facto strategy.

In Summary

Interviews with project stakeholders offer a rich source of insights into the collective mind of an organization. They can help you uncover areas of misalignment between a company’s documented strategy and the attitudes and day-to-day decision-making of stakeholders. They can also highlight issues that deserve special consideration due to their strategic importance to a business. Best of all, interviews are one of the easiest and lowest-tech forms of UX research you can conduct.

Posted by 노터니
대부분의 네트워크 관리자들은 힘들고 어려운 상황에서도 맡은 바 업무를 잘 해내고 있지만, 간혹 그렇지 못한 경우도 있다. 다음 목록은 가장 위험한 네트워크 관리자의 7가지 유형이다. 필자가 오랜 기간 이 분야에서 동료들의 특성을 관찰해 그 결과를 정리한 것이다.

보통 네트워크 관리자들은 아래에 서술된 특성 중 몇 가지에 해당하겠지만 이 글은 어디까지나 '정도가 지나친 경우'에 대한 것임을 유념하고 가볍게 읽어주길 바란다.

1. 보안 강박증형
이 유형의 관리자는 자신이 관리하는 네트워크에 "눈곱만큼의 '나쁜 것'도 허용하지 않는다"는 지상 과제를 갖고 있다. 네트워크 케이블, 패치 패널, 라우터, UPS 등 모든 것이 책상서랍 속의 마우스볼처럼 그의 소유라는 점에 유의하자.

보안 강박증형이 문제를 예방하는 방법은 시스템을 아주 단단히 잠궈 그 무엇도, 그 누구도 변화를 줄 수 없도록 하는 것이다. 사용자가 할 수 있는 일이라곤 로그인, 그리고 패스워드 변경(어차피 사용할 때마다 새로운 것으로 갱신하도록 설정돼 있다) 정도에 불과한 경우도 있다. 인가되지 않은 실행 파일을 수행하는 것은 사용자에게 허용하기엔 너무 위험한 일이다. 이메일 서버는 파일 첨부가 안되도록 설정돼 있다.

이 보안 강박증형 관리자가 네트워크 운영을 맡은 지난 7년간 단 한차례의 바이러스 감염도 없었다. 앞으로도 마찬가지일 것이다. 안전을 위해 자신이 사용하는 컴퓨터 본체의 USB 소켓은 바이오스에서 비활성화 시켜뒀고 바이오스에는 암호를 걸어놨다. 게다가 USB 소켓 자체를 접착제로 막아버렸기 때문에 누군가 USB 메모리 스틱을 가져와 그의 컴퓨터에서 정보를 빼간다는 것은 불가능하다.

관리자의 컴퓨터는 책상에 단단히 고정돼 있는데다 네트워크 케이블을 꼽지 않으면 부팅도 안되기 때문에 뜯어간다 해도 별 소용 없다. 시스템 커버를 제거하려는 불순한(?) 시도가 있을 경우 소형 폭발물이 터질지도 모르겠다.

2. 어떻게 하다보니형
어떻게 하다보니형은 다른 직종의 직원이 우연한 계기로 네트워크 관리자가 돼 요령을 익혀 나간 케이스다. 회사가 10년 전 서류업무를 줄이기 위해 PC를 구매했는데, 가장 늦게 퇴근하는 어느 한 직원이 자연스럽게 비공식 'PC 담당'이 된 것이다. 이후 5명이던 직원이 80명으로 늘어났으며 네트워크도 확장됐다.

현재 이 회사에는 임시 서버에 10여 대의 시스템이 아무렇게나 연결돼 있다. 이 서버는 이메일 게이트웨이, 파일 서버, 인터넷 프록시 서버 역할을 전담하고 있다. 네트워크에 대한 모든 잡다한 지식은 관리자의 머릿속에 있기 때문에 관리 문서 따위는 없다. 특별히 위험한 상황만 발생하지 않는다면 네트워크는 그럭저럭 굴러가긴 한다.

회사는 네트워크를 전담할 IT 전문가를 고용할 정도가 되지 않아 결국 한 직원만 혹사시키고 있는 것이다. 이 관리자는 원래 속한 팀에서도 자기 일을 모두 해야 한다.

이 경우 유일한 희망은 회사가 더 확장돼서 IT 전문가를 고용할 수 밖에 없게 되는 것, 그래서 어떻게 하다보니형 관리자가 시스템 관리 일에서 영원히 손을 떼는 것이다.

잦은 시스템 다운, 바이러스 감염, 불안정한 전원 문제 정도는 별로 상관하지 않는다면 이런 형태로 운영이 불가능한건 아니다. 모든 직원의 패스워드가 동일하고, 모든 직원에게 네트워크 폴더 접근 권한이 있다 해도 "직원들의 인간성이 좋은데다 신뢰할 수 있다"고 말한다면 역시 문제될 것 없다.

3. 원격 지배형
애플리케이션의 원격 설치 및 업그레이드 기술을 완전히 마스터한 한 관리자가 있다. 그에게 사용자가 원하느냐, 원하지 않느냐 따위는 문제가 아니다.

업무 후 컴퓨터를 끄고 퇴근한다 해도 이 원격 지배자의 손길을 벗어날 수는 없다. 이미 네트워크 상의 모든 컴퓨터를 WOL(Wake-On-LAN) 상태로 설정해뒀기 때문이다.

자신의 컴퓨터를 지키고 싶다면 네트워크 케이블을 뽑고 퇴근해야 한다. 그렇지 않을 경우 다음날 아침 생소한 PC를 대면하게 될 수도 있다. 어제 사용하던 것들 중 어느 하나도 찾을 수 없는, 완전히 새로운 PC를!

4. 고지식형
사용자가 통상적인 것에서 조금만 벗어난 것을 요구해도 "제 업무 범위를 벗어난 일입니다"라고 대답하는 유형으로, 관공서 공무원을 연상시킨다.

자신이 실수를 저질렀다면 (아무리 작은 것이라 해도) 스스로에게 징계처분을 내릴 유형이기도 하다. 만일 이 관리자가 업무와 별 관련 없는 이메일이 네트워크를 통해 오간 것을 발견한다면, 해당 직원들은 각오해야 할 것이다.

5. 실험가형
실험정신으로 무장한 이 관리자는 항상 새로운 패치, 업그레이드를 시도한다. 지각있는 대부분의 관리자들은 실제 시스템에 적용하기 전에 소규모 시험용 네트워크에서 돌려보지만 이 유형은 그런 절차 없이 바로 실제 시스템에 적용해본다.

원격지배형과 비슷한 점도 있지만, 그래도 원격지배형은 최소한 사전 확인 작업을 통해 실제 네트워크에 끼칠 영향을 점검한다.

6. 네트워크 사유재산화형
명칭이 의미하듯 회사 네트워크는 이 관리자의 개인 소유다. 누군가 네트워크의 원활한 운영에 조금이라도 영향을 미치는 행동을 할라 치면 크게 분노한다.

그정도는 좋은 현상이라고 생각할 수도 있다. 하지만 위의 다른 유형들과 마찬가지로 정도가 너무 심한 경우가 문제다. 네트워크 성능이 100%로 나오는 로그에 유별나게 집착한다. 이 '100% 로그'를 위해 일반적 용도로는 네트워크 자원을 거의 할당하지 않는다.

7. 게임광형
위험한 네트워크 관리자 유형 중 가장 친숙한 타입이다. 주로 대학교에서 많이 발견된다. 소수 학생들의 졸업논문 작성이나 연구에 이용되는 대학 네트워크에는 남는 자원이 풍부하다. 이 자원은 곧 네트워크 관리팀의 게임 플랫폼으로 활용된다.

대학 네트워크 관리자들이 수많은 온라인 게임에서 상대방의 가상 존재를 없애는 일에 네트워크 자원을 사용하고 있는 셈이다. 힘든 하루를 보낸 후 가상 공간에서 몇 시간 동안 즐기는 것이야말로 이들에게는 더할 나위 없이 좋은 휴식이다. @
Posted by 노터니

리더쉽 유형도

           

(P)

좋은사람형

 

 

 

 

 

 

 

팀관리자형

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

컨트리클럽형

 

 

 

 

팀      형

 

 

 

 

 

 

 

 

 

 

중  간  형

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

무 기 력 형 

 

 

 

과  업  형 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

행정관료형

 

 

 

 

 

 

 

 

친 절 한

독재자형

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

과업지향적 행동(T)

                      ( ● : 자기평가 , ★ : 피고과자 평균 , ◆ : 피고과자평가 )

 

※리더쉽 유형별 특징


1.무기력형 :

구성원과 업무수행 모두에 무관심한 유형이다. 이 유형의 리더는 가급적 어려운 일을 피

하고, 자기 주변만을 깨끗하게 유지하는 데 신경을 쓰면서 정년만 기다린다. 맹목적으로

규칙적인 목표만을 처리해 나간다. 이 유형의 리더쉽은 건설적인 개혁이나 발전을 위한

창의성은 거의 유발될 수 없다. 리더의 무사안일한 태도로 인하여 성원들의 성실한 참여

가 유발되기 힘들다. 무난한 것을 좋아하고 어려운 일은 회피한다.


2.행정관료형 : 무기력형이 심화된 상태


3.컨트리클럽형 :

업무에는 무관심한 반면 성원들에 대해서는 높은 관심을 보인다. 이 유형의 리더는 성원

들의 욕구, 소망 및 동기 등을 해결해 주면 그들이 맡은 바 임무를 자발적으로 수행한다고

생각하기 때문에, 성원의 사기를 중시하며 성원과의 인간관계를 개선하고 좋은 작업조건

을 조성하여 주며 성원들의 보수인상을 위해 노력해 준다. 그러나 성원들을 돌보아 주는

것이 그들로 하여금 업무에서 이탈하지 않도록 하는 기능으로는 충분하나 리더가 업무수

행에 깊은 관심을 보이지 않기 때문에 성원들의 성실성이 유발되기는 어렵다. 경쟁이나

갈등상황에 직면하면 불안을 느끼고 가급적 원만히 해결코자 하여 통상 양보와 망각의

방법을 적용하게 된다.


4.좋은사람형 : 컨트리 클럽형이 심화된 상태


5.중간형 :

중간형태의 리더로서 향상 성원의 복지와 업무수행의 두 가지 내용을 같이 고려하여 집

단을 유지하기 위해 노력한다. 즉, 어느 정도까지는 업무수행을 위해서 성원들을 강력한

지시로 이끌어 가지만 반면에 성원들을 이해해 주려고 노력하고 사기앙양에 관심을 기울

인다. 이 유형의 리더쉽은 목표달성을 위해 권위로 누르거나 명령에 대한 복종을 강요하

지 않고 성원들의 자발적 동기유발 혹은 의사교환과 설득의 방법을 이용한다. 이 유형의

리더는 성원들의 창의성을 자극하지만 그것을 업무와 연관시켜 활용하지 않는다. 무리한

도전이나 모험심이 없는 안정주의자이다.


6.과업형 :

이 유형의 리더는 업무수행에 온갖 관심을 기울이지만 성원들을 목표달성에 필요한 하나

의 도구로 보고 성원들의 요구나 소망은 목표달성을 위해 무시한다. 모든 결심을 독단적

으로 하고 그에 따른 책임을 진다. 이 유형의 리더는 주로 위급한 상황이나 전투시 또는

단기적으로 목표를 달성해야 하는 경우에 매우 유용하다. 이러한 유형의 리더쉽은 성원

들로 하여금 자발적인 성실성보다는 강제에 의한 수동적인 성실성을 유발시킨다. 아울러

성원들의 창의적 의견이 차단되기 쉽다.


7.친절한 독재자형 : 과업형이 심화된 상태


8.팀형 :

이 유형의 리더는 성원들의 참여의식을 조성하고 그들의 의견을 존중하여 집단목표를 성

취하려 한다. 개인들의 업무를 통합함으로써 목표를 달성하는 것이 아니라 집단의 공동

작업 및 단체행동을 중시한다. 다른 유형의 리더와는 달리 성원들의 참여의식을 고취시

키기 위하여 인간의 동기를 이용한다. 이 유형의 리더 아래에서 지휘받는 성원들의 창의

성은 대단히 높다. 이 유형의 리더는 실험적 태도를 가지고 있어 하나의 방법을 검토하고

장단점을 명확히 함으로써 보다 발전된 방법을 부단히 개발해 나간다. 강한 인간관계를

조직의 기조로 하여, 성원간의 상호존경, 신뢰 및 이해의 풍토를 조성하고 공동목표를 갖

도록 한다. 이런 점에서 가장 높이 평가받는 리더쉽 유형이다.


9.팀관리자형 : 팀형이 심화된 상태

Posted by 노터니
인적 자원 역량을 극대화하기 위해서는 구성원들의 실력을 키워주고, 열정을 고무시킬 수 있어야 한다. 그 중심 축이 바로 관리자들이다. 강한 인재를 길러내는 관리자가 있는가 하면, 반대로 인재를 망치는 인재 킬러형 관리자도 많다. 이에 대해 살펴본다. 

기업들의 인재 유치 노력이 그 어느 때 보다 강도 높게 전개되고 있다. 치열한 시장 점유 경쟁을 하듯 기업들의 인재 유치 활동이 공격적으로 전개되는 양상이다. ‘Talent War’라 해도 과언이 아니다. 이러한 인재 확보 노력은 일류 기업으로 향하는 출발점인 만큼 최우선해야할 경영의 핵심 과제이다. 그런데 여기서 한가지 유의해야 할 점이 있다. 기업이 인재를 확보하고 효과적으로 활용하기 위해서는 외부에서 좋은 사람을 유치하는 것만으로 끝나는 것이 아니라는 사실이다. 인재 유치는 시작일 뿐이다. 진정 중요한 것은 내부에서 지속적으로 능력을 키워주고, 동기부여시킬 수 있어야 한다. 이와 관련된 결정적인 핵심 동인이 바로 관리자들이다. 관리자들 중에는 부하의 능력을 잘 키우고 열의를 복돋아 주어 최고의 인재로 만들어 내는 사람이 있는가 하면, 반대로 어렵게 유치한 인재를 망치는 인재 킬러형 관리자들도 있다. 그 몇 가지 대표적인 유형과 특징들을 보자. 


독선적 권위형

인재를 약화시키는 대표적인 관리자의 모습으로는 우선 독선적 권위주의형을 꼽을 수 있다. 이 경우 대개가 귀족 의식이 매우 강하고, 자신의 뜻대로 일이 안되면 부하들에게 쉽게 화를 내거나 지위적 권위로 억압하는 특징을 갖는다. 이런 관리자 밑에서는 직원들이 상사를 무서워 하고 주눅이 들어, 창의성이나 일에 대한 열정이 발휘될 없다. 단지 상사가 시키는 대로 수동적으로 일할 뿐이다. 

권위의식이 강한 관리자의 더 큰 문제는 아랫 사람들과 열린 마음으로 대화하지 못한다는 점이다. 특히, 자신의 의견에 대한 부하들의 반론이나 비판을 진지하게 듣고 수용하는 면이 매우 부족하다. 이런 상황에서는 부하 직원들이 상사에게 좋은 것만 이야기 하고 나쁜 정보는 감추게 되는 커뮤니케이션 왜곡 현상이 발생한다. 관리자의 열린 커뮤니케이션 행동은 직원들의 아이디어나 잠재력을 이끌어 내는 중요한 동기부여 요인이다. 개인이 하고 싶은 말이나 의견을 자유롭게 발산할 수 있도록 하는 것은 금전적 보상에 버금가는 동기부여 효과가 있기 때문이다. 따라서 관리자들의 독선적이고 권위적인 행동은 종업원들의 사기를 저하시키고 결과적으로 인재들을 떠나게 만드는 커다란 인재 파괴 요인일 수 있다. 

고대 중국 제왕들의 성패 사례가 좋은 교훈을 준다. 초대 당나라의 부흥에 결정적인 역할을 한 태종은 신하들이 범접하기가 어려운 매우 위엄이 있는 인상의 소유자였다고 한다. 제위 초기에 신하들이 감히 말을 하지 못하였고, 이로 인해 상하간의 의사소통이 제대로 이루어지지 않았다. 이를 깨달은 태종은 항상 온화한 표정을 지으며 신하들과 자주 얼굴을 맞대고 만나는 노력을 했다. 또한 누구라도 하고 싶은 말을 자유롭게 할 수 있는 열린 분위기를 만들고, 좋은 간언(諫言)을 하는 사람에게는 후한 상을 내려 용기를 복돋아 주었다. 이렇게 함으로써 훌륭한 인재들이 주변에 많이 모여 등용될 수 있었다. 반면, 대표적인 폭군으로 평가되는 수나라의 양제는 매우 독선적이고 신하의 간언을 싫어하는 성격이었다고 한다. 그 때문에 신하들은 모두가 왕을 두려워하고 충언하는 사람이 한 사람도 없었다. 그 결과 인재들은 모두 떠나고, 패망으로 치달을 수 밖에 없었던 것이다(참고: ‘중국 고사에서 배우는 제왕학’). 

일류 기업들의 중요한 특징중 하나는, 관리자들이 직원들과 열린 의사소통을 통해 그들의 잠재력이나 아이디어를 이끌어내는 개방적 커뮤니케이션 문화가 강하다는 점에 유념할 필요가 있다. 예를 들어, 메모리 분야에서 비메모리 반도체의 강자로 변신하여 성공한 인텔의 근본적인 강점도 바로 열린 커뮤니케이션 문화에 있었다. 비메모리 분야로 사업 방향의 변화가 필요하다는 전략적 의견은 먼저 밑으로부터 강하게 제기 되었고, 이러한 주장이 임직원들간의 열띤 토론을 거쳐 최고경영자에게 수렴되어 전략 변화로 연결된 것이다. 구성원들이 서로가 좋은 관계를 유지하면서도 건설적인 논쟁이나 대화를 나누고, 이로부터 해법을 찾는 건강한 커뮤니케이션 문화가 눈에 보이지 않은 핵심 역량이었다. 월마트의 창업자인 샘 월턴은 자사의 성공 비결에 대해 이렇게 말한 적이 있다. “우리가 가진 가장 큰 강점은 직원들과의 효율적인 의사소통에 있다. 우리는 가능한 모든 수단을 활용하여 직원들의 목소리에 귀를 기울인다.” 그 만큼 경영자를 비롯한 관리자들이 열린 마음으로 대화하는 커뮤니케이션 문화가 중요하다는 이야기이다. 


무임 승차형

어떤 개인이 가장 크게 동기부여 되는 경우는, 회사나 조직으로부터 인정 받고 있다는 느낌을 받을 때이다. 이를 위해서는 관리자들이 부하의 헌신과 공을 제대로 인정해 주고 그에 상응하는 적절한 보상을 해주어야 한다. 부하의 공을 인정하고 배려하지 못하는 상사는 관리자로서 기본 책무를 유기하는 것이나 마찬가지다. 그 전형적인 경우가 바로 자신은 별다른 노력이 없이 부하들의 헌신과 희생 덕에 직장 생활을 하는 무임승차형 관리자이다. 이런 관리자들의 두드러진 특징으로는 부하의 공을 가로채는 행위를 꼽을 수 있다. 예컨대 부하들이 고생해서 만들어낸 아이디어나 성과물을 자신이 직접 한 것처럼 하여 윗사람에 보고 한다든지 자신의 공으로 돌리는 경우도 있다. 마치 ‘재주는 곰이 넘고 돈은 되놈이 받는다’는 식과 같은 모습이다. 이는 부하들의 일할 의욕과 사기를 꺾고 상하관계를 어렵게 만드는 치명적인 독소가 될 수 있다. 

말만 앞서고 솔선수범하지 못한다는 점도 무임승차형 관리자가 갖는 특징이다. 부하들과 같이 고민하고 현장에 몰입하기 보다는 지시만하고, 본인은 슬쩍 뒤로 빠져 관망하는 경우가 많다. 이런 관리자에게는 부하 직원들을 불필요하게 통제하고 감시하는 경향이 있다. 예컨대, 정규 근무 시간 외에 특정한 목적이 없이 불쑥 전화를 하여 부하 직원이 야근하고 있는지, 주말이나 휴일에 나와서 근무를 하고 있는지를 체크 하는 행위를 하기도 한다. 관리자의 이러한 행위들도 부하 직원들의 스트레스를 가중시키고 사기 저하를 가져오는 주된 요인이다. 


감성 결핍형

감성 지능(emotional intelligence)이 떨어지는 관리자도 큰 문제다. 감성 지능이 낮은 관리자들의 전형적인 특징은 부하의 감정이나 기분 등 내적인 심리 상태를 배려하지 못한다는 점이다. 이런 관리자들 중에는 오직 일 밖에 모르는 일 벌레형 관리자들이 많을 수 있다. 구성원들이 잠시의 여유를 갖는 모습을 보면 불안해 하고, 사원들이 항상 바쁘게 움직이는 것처럼 보여야 마음을 놓는 경향이 있다. 상사가 지나치게 일 중심으로 움직이고, 부하의 개인적 고충이나 스트레스 등 인간의 정서적인 측면에 대해 무감각하게 되면 조직적 탈진(burn-out) 현상을 유발할 수 있다. 이는 구성원들의 일하는 재미, 의욕을 꺾고, 인재들이 회사를 떠나게 되는 부작용을 낳게 된다. 

Daniel Goleman이라는 학자의 연구 결과에 의하면, 지속적으로 높은 성과를 내는 일류 리더들은 공통적으로 감성 지능이 높다고 한다. 지능이나 지적 능력, 기술적 능력은 훌륭한 리더가 되기 위한 필요 조건이기는 하나, 충분 조건은 아니다. 감성 지능이 낮은 사람은 날카로운 분석적 사고와 명쾌한 아이디어는 제시할 수 있는 능력은 뛰어날지 몰라도 탁월한 리더가 될 수 없다고 한다. 감성 지능이 높은 관리자들은 자신의 말이나 행동이 부하에게 미치는 영향을 인식하는 자기 인지력, 다른 사람의 감정을 헤아리고 그에 적절히 대응 조치할 수 있는 감정 이입력, 부정적인 충동이나 기분, 행동을 조절하는 자기 통제력 등을 갖추고 있다고 한다. 
GE의 웰치 전회장은 재임 시절 대대적인 구조조정으로 사원들로부터 중성자탄이라는 별명을 얻을 정도로 냉혹한 평가를 받기도 했지만, 반면에 사원들의 정서나 감정을 배려하는 인간적인 섬세한 면도 갖추고 있었던 것으로 보인다. 예컨대, 어느 사업부의 한 중견 사원이 웰치 회장 앞에서 직접 보고를 하게 되었는데, 그로 인해 해당 직원은 굉장한 심적 부담을 받았다고 한다. 이를 알게 된 웰치 회장은 해당 직원에게 과다한 스트레스를 받게 해서 미안하다는 내용의 편지와 함께 작은 선물을 보냈다는 일화가 있다. 웰치는 결단력 있는 카리스마와 함께 부하에 대한 인간적인 배려도 잊지 않은 섬세한 감성도 지니고 있었던 경영자가 아닌가 싶다.


해바라기형

위계적 관료 문화가 강한 조직에서 흔히 있는 현상의 하나가, 정치적이고 강자에게 절대 복종하는 해바라기형 관리자들이 많다는 것이다. 이런 타입의 관리자는 윗사람에게 약한 대신, 아랫 사람들에게는 군림하려는 특성이 있다. 또한 자신보다 파워가 있는 사람들 앞에 나서기 좋아하고 잘 보이려는 Show-up 기질이 강하다. 그 때문에, 부하의 공을 가로채거나 자기 보다 뛰어난 부하 직원들에 대해서는 경계하는 모습도 보이게 된다. 이런 관리자 밑에서는 부하들의 사기 저하는 물론 제 2인자가 키워지기 어렵다. 

‘빈 수레가 요란’하듯이 해바라기형 관리자는 뒤에서 조용히 일하는 도덕적 겸양이 부족한 면이 있다. ‘Good to Great’라는 책의 저자로 유명한 Jim Collins에 따르면, 위대한 기업을 만든 일류 리더(Level 5 리더)들은 뛰어난 업무 능력 만이 아니라, 밖으로 드러나지 않게 제 역할을 묵묵히 수행하는 겸손함도 같이 갖추고 있다고 한다. 일찍이 노자는 도덕경에서 가장 훌륭한 지도자는 백성이 그 존재가 있는지 조차 모르는 지도자(‘太上 不知有之’)라고 하였는데, 그 요지도 이와 같은 맥락이 아닐까 한다.


자린고비형

인재를 키우고, 지속적으로 동기부여하기 위해서는 사람에 대한 투자가 기본이다. 이런 투자 마인드가 약한 사람이 자린고비형 관리자이다. 이 같은 관리자는 당장 눈앞의 작은 이익을 위해 인재라는 큰 자산을 놓치는 소탐대실의 모습을 보이기 십상이다. 사람에 대한 투자는 반드시 많은 자원을 요구하는 것만이 아니다. 예컨대, 교육훈련이나 복리후생 측면에서 보면, 큰 돈을 들이지 않고도 종업원들을 만족시킬 수 있는 요인들이 많이 있다. 관리자가 이런 부분에 드는 비용을 아까워 한다면 부하 직원들의 스트레스나 불만이 가중될 수밖에 없다. 사람에 대한 투자는 금전적인 요인만을 의미하지 않는다. 시간적인 투자도 중요하다. 관리자가 자신의 업무 시간을 쪼개어 육성 활동에 투자하는 데 인색해서는 부하 직원들의 실력이 늘지 않는다. GE의 잭 웰치, 인텔의 앤디 그로브, 펩시의 로저 엔리코 등 일류 경영자들은 자신의 업무 시간의 상당 부분을 사원 교육 등 인재 육성 활동에 쏟았다는 점에 주목해야 한다.

사원들의 작은 실패나 실수를 용납하지 않는 것도 인색한 관리자의 특징이다. 실패 경험을 통한 학습의 효과 보다는 그에 따른 비용을 더 중시하기 때문이다. 관리자가 작은 실수나 실패조차 용인하지 않으면, 직원들이 보수적으로 흐르게 되어 창의성이나 도전적인 행동이 나올 수 없다. 노키아, 3M 등 혁신 지향적인 기업에서는 R&D 프로젝트 등 중요한 과제를 추진하다가 실패하더라도 책임을 탓하기 보다는 재도전하도록 고무하는 소위 ‘Blame-free’ 문화가 강한데, 그 배경도 여기에 있다 하겠다.


자유방임형

인재를 키우지 못하는 관리자의 또 하나의 문제점은 부하에 대한 건설적인 질책이나 피드백 활동이 미약하다는 것이다. 특히 인간적인 관계가 깊어짐에 따라, 냉정한 입장을 유지하지 못하고 일의 완결성을 높이기 위한 세심한 점검과 피드백을 전혀 하지 않는 우를 범한다. 부하를 배려한다는 명목으로 칭찬이나 좋은 말만 하거나 인기에 연연하는 모습도 보인다. 이는 관리자의 기본 책무를 저버리는 자유 방임 행위이다. 이런 상황에서는 부하 직원들의 몸과 마음이 편할지는 모르나 일에 대한 몰입도나 실력이 늘지 않는다. 또한 업무 자세의 해이를 불러 일으킬 수도 있다. 때로는 읍참마속의 심정으로 부하에게 따끔한 피드백과 충고를 가하는 단호한 모습을 보여 주어야 한다. 

한 조사에 따르면 부하들이 상사에게 바라는 가장 큰 바람의 하나가 바로 ‘피드백’이라는 사실도 있다. 이 점에서 한국 축구의 4강 신화를 창조한 히딩크는 좋은 모범이 된다. 일부 스타 의식이 젖어 있는 선수들을 주전에서 제외시키는 등 냉정한 피드백과 질책을 통해 팀을 강하게 만들 수 있었다.


이지메형

인재를 상실하는 관리자의 가장 극단적인 형태는 자신의 눈 밖에 난 직원은 홀대하고 지속적으로 스트레스를 주는 타입이다. 예컨대 사소한 일에도 꼬투리를 잡아 야단을 치거나, 다른 사원들 앞에서 공개적으로 망신을 주는 모습을 자주 보인다. 이는 일본의 사회 문제가 되고 있는 일종의 ‘이지메(いじめ)’에 가깝다. 마치 학교에서 특정 학생을 ‘왕따’시키는 것과 같은 행위로 특정의 부하 직원을 괴롭히고 소외시켜 버리는 현상이다. 이 같은 관리자의 행위는 당사자에게 심한 스트레스를 주어, 정신 건강을 파괴하고 직장 생활 자체를 어렵게 만든다. 또한, 다른 동료 직원들의 정서적 불안감이나 사기 저하를 유발하여 조직 전체의 생산성을 떨어뜨리는 부작용을 야기할 수 있다.

과로사가 많기로 유명한 일본의 경우, 10년 이상의 장기 불황으로 기업들이 어려워지면서 최근에는 직장내 이지메 현상이 부쩍 늘어나고 있다고 한다. 주로 상사가 부하에게 과도한 성과 압력이나 정신적 스트레스를 주는 행위로, 심한 경우 우울증이나 자살까지 불러 일으키는 원인이 되고 있다. 예컨대, 과거 일본의 한 생명보험 회사에서 사원이 자살한 사건이 있었는데, 그 주요 원인도 상사로부터 받은 심한 스트레스에 있었던 것으로 알려졌다(참고: 週刊 ダイヤモンド, 2002. 5. 18). 

구성원들의 능력을 키워주고, 잠재력을 이끌어내기 위해서는 시스템만으로 한계가 있다. 관리자의 리더십이 더 중요한 요인이다. 최근에 일본의 한 연구 기관이 실시한 조사를 보면, 직장내 스트레스의 가장 큰 요인이 ‘상사’라는 서베이 결과가 있다. 미국의 경우도 이런 연구 결과가 많다. 예컨대, 퀼컴사가 자사의 직원들을 대상으로 실시한 조사에서도 인재들이 이직하는 큰 요인으로 상사의 리더십 문제가 지적된 바 있다. 당 연구원이 국내 기업을 대상으로 실시한 조사 결과에서도 이와 비슷한 결과가 나타난다. 인재 관리에 있어 관리자의 역할이 그 만큼 중요함을 보여 주는 증거들이다. 어렵게 유치한 인재들을 떠나가게 한다든지, 보다 강한 인재로 만드는 능력이 떨어지는 기업들은 앞서 언급한 관리자들의 모습 때문이 아닌지 심도 있게 점검해 볼 필요가 있을 것이다.
Posted by 노터니
축구 경기에서 팀이 아닌 혼자서는 경기에서 이길 수 없다. 스포츠에서와 마찬가지로, 프로젝트에서도 프로젝트의 성공은 팀원에 크게 달려있다. 이상적인 프로젝트 수행 팀은 적기에, 예산 내에서, 적은 관리 노력으로 각자의 업무를 완수하는 것이다.

그러나, 서로 조화를 이루지 못하는 팀은 하루하루 지연되어 가는 각자의 업무를 관리하기 위해 상당한 노력이 요구될 것이다.

프로젝트 업무를 수행해 나가는 것은 다름아닌 바로 프로젝트 팀이다. 프로젝트 팀은 전문성과 스킬로 프로젝트 활동에 시간과 노력을 투입하는 모든 개인 또는 그룹이다. 여기에는 프로젝트의 협력업체, 공급업자, 고객도 포함된다. 누가 프로젝트에 참여할 것인가는 프로젝트 초기 착수 단계에서부터 계획단계에 걸쳐 진행되며, 프로젝트의 모든 팀 구성원들의 책임과 역할이 결정되어야 한다. 

프로젝트 초기에는 프로젝트 팀의 구성원은 프로젝트 매니저 혼자일 수도 있지만. 프로젝트 범위에 대한 분석이 끝나면, 프로젝트 매니저는 요구사항을 개발하고 프로젝트 팀에 필요한 스킬을 식별하기 위해 전문가(기능부문 관리자)들의 도움을 구할 필요가 있다. 프로젝트 매니저는 프로젝트 초기에 요구사항을 정의해 나갈 때, 간과하고 넘어가는 과업들은 없는지 파악하기 위하여 경험 많은 전문가들의 도움을 구하여 누가 프로젝트 팀에 참여하는지를 식별하여야 한다.

프로젝트 매니저는 프로젝트 팀이 구성되고 본격적으로 프로젝트를 수행해나가기 앞서 구성원들의 참여와 활기를 이끌어내고 서로의 관계를 우호적으로 만들기 위해서는 프로젝트의 방향을 제시하고 현재 모습과 미래 모습을 제공해주어야 한다. 고객의 요구가 파악되고 대략적인 프로젝트 최종산출물의 윤곽이 잡히면 팀원끼리 산출물에 대한 컨셉트를 공유하여 동일한 목표를 추구하고 프로젝트 완료까지 일관된 수행을 해나가도록 해야 한다. 

즉, 프로젝트가 앞으로 가야 할 방향과 구성원들의 바라는 모습, 미래의 기업 운명 또는 조직이나 프로젝트에 대한 분명한 상을 제시하는 것이다.

프로젝트 매니저로서의 임무는 먼저 프로젝트를 평가하고 프로젝트 수행 인원을 선정하여 팀을 구축하는 것이다. 프로젝트 팀은 프로젝트의 최종 결과를 만들어 내기 위해 실질적으로 일하는 사람들로 구성된다. 거의 모든 프로젝트에서, 팀은 서로 다른 개성, 스킬, 능력, 지식, 기질을 가진 사람들로 조직된다. 프로젝트 팀을 구축하고 유지해나가는 것은 어떤 프로젝트 매니저에게든 가장 어렵고 힘든 두 가지 업무이다. 

규모가 작거나 일과성의 프로젝트에서조차 성공적으로 업무를 완수하기 위한 적절한 사람을 선발한다는 것은 어렵고, 위험이 따르며 어쩌면 시간을 요하는 일이 될 수가 있다.

그러나 이러한 노력은 가치가 있는 것이다. 

왜냐하면 예산과 장비를 이용할 수 있다 하더라도 사람 없이는 아무 일도 일어나지 않기 때문이다. 그래서 아무리 작은 프로젝트라 할지라도 필요한 인원은 신중하게 고려하는 것이 중요하다. 

결국, 프로젝트를 성공적으로 완수하는 것은 사람이기 때문이다.




* 프로젝트 매니지먼트 전문가(PMP), 프로젝트 매니지먼트 코치(PMC) - 허정재(hur@psi.co.kr)
Posted by 노터니
팀을 구성하고 유지해나가는 것은 어떤 프로젝트 매니저에게나 가장 어려운 두 가지 업무이다. 

그렇다면, 어떻게 적절한 인원들을 선발하고, 인원들의 역할과 책임을 명확히 하여 프로젝트 팀을 구성할 수 있을까?

어떤 프로젝트건 다음 세 가지의 질문은 프로젝트의 일을 완수하기 위해 필요한 사람들로 팀을 구성하기 위해 고려해야 될 사항이다.

   • 프로젝트의 과업을 완수하기 위해 요구되는 스킬은 무엇인가?
   • 어디에서 과업을 완수할 사람들을 구할 것인가?
   • 사람들을 어떤 프로젝트 구조로 조직화 할 것인가?


프로젝트를 수행하기 위해 필요한 스킬이 무엇인지 확인한다. 초기 프로젝트 업무의 이해와 프로젝트 과업을 파악하는 것으로부터 프로젝트를 수행하기 위해 필요한 스킬이 무엇인지 확인할 수 있다. 이러한 필요 스킬은 업무분해구조도(WBS: Work Breakdown Structure)를 개발하는 동안 보다 더 구체적이고 분명해진다. WBS란 프로젝트의 전체 범위를 구성하는 프로젝트 요소를 산출물 중심으로 작게 분해하여 그룹화한 업무 분석 방법이다. 분해를 상세하게 하면 할수록 업무에 대해 필요한 스킬 및 책임과 역할을 확실하게 정의할 수 있다.

프로젝트 수행에 필요한 지식과 기술을 가진 사람을 모두 확보하는 것은 매우 힘든 일이다. 왜냐하면, 대부분 조직에서는 한정된 인적 자원을 가지고 여러 개의 프로젝트를 수행하기 때문이다. 프로젝트 매니저는 이미 구성된 인원을 가지고 프로젝트 요구사항을 파악하도록 노력해야 한다. 그러나, 이미 구성된 인원이 모든 필요한 스킬을 가지고 있지 못하다면, 요구되는 스킬을 가진 다른 인력 소스를 확인한 후 이 인원의 자발적인 참여의사를 구하고, 전반적인 프로젝트의 우선순위에 의거 해당 기능 부서장과 협상을 하여야 한다. 이때 프로젝트 매니저로서 필요한 자원을 얻을 수 있는 협상 스킬이 필요하다. 대부분의 경우, 프로젝트 매니저의 협상 스킬은 대인관계 스킬과 일반적인 영향력의 조합이다. 때로는 경영진의 특별한 지원과 의사결정을 필요로 한다.

팀원들의 자발적인 참여에 의하여 팀워크를 구축하고, 부족한 기술적인 스킬을 채우며, 개인간의 갈등이나 팀원들간의 불협화음을 피하기 위한 모든 예방책을 강구해야 한다. 프로젝트에 관련된 이해 관계에 있는 모든 조직의 참여를 이끌어 내는 것이 중요한데, 이 방법 중 하나는 해당 조직의 구성원을 프로젝트 팀에 지명하는 것이다. 왜냐하면, 이해 관계에 있는 조직들은 팀 구성원의 출처가 되며, 자원을 제공해 줄 수 있기 때문이다. 또한, 이해 관계에 있는 조직들에게는 프로젝트 진도에 관한 정보를 제공함으로써 의사소통하고, 검토와 의사 결정을 하는데 참여하도록 유도한다. 

프로젝트 매니저는 모든 팀원이 화합할 수 있도록 노력을 기울여야 하고, 혁신적인 결과를 만들어내도록 리드해야 한다. 팀원 선발 시 우선, 주요 대상 인원, 팀원 자격, 기간, 역할, 업무 난이도 등의 검토를 통해 필요한 역할을 확인한 다음, 조직 구조를 염두에 두고 예비 팀원을 선정한다. 팀원을 선정할 때는 프로젝트에 필요한 주요한 특수 분야가 있는지를 파악하며, 모든 주요한 이해관계자들이 팀 구성원에 포함될 수 있도록 노력하고, 프로젝트 상황이나 의사결정 회의 시 각 조직이 계획성 있고 조직적으로 참여하도록 유도해야 한다.

프로젝트 팀원으로서 적절한 사람을 선택하는 중요성은 아무리 강조해도 지나치지 않다. 이는 프로젝트의 성공을 위한 가장 기본적이고 절대적으로 필요한 것이기 때문이다.



* 프로젝트 매니지먼트 전문가(PMP), 프로젝트 매니지먼트 코치(PMC) - 허정재(hur@psi.co.kr)
Posted by 노터니
팀으로서 함께 일하기 위해서는 프로젝트를 시작하는 첫 회의에서 팀원들은 회의 운영, 팀으로서 프로젝트 수행, 갈등 해결을 위한 기본 원칙 또는 행동규범(ground rule)을 설정하고, 이에 동의할 필요가 있다. 또한, 팀은 즉각 해결을 할 수 없는 회의 동안에 언급되는 아이디어나 이슈들을 정리하고 해결하는 방법을 마련해 두는 것이 필요하다.

먼저, 각 팀원들이 어느 수준 정도로 프로젝트에 기여할 것인가를 팀 내에서 합의를 구하는 것이 중요하다. 다음의 프로젝트에 대한 서약 사항에 대하여 동의를 득한 후, 각 팀원이 서명을 한다. 

   • 할 수 있는 한 최선을 다해 작업에 전념한다.
   • 프로젝트 진도 보고는 솔직하고 사실적으로 한다.
   • 주도적으로 임한다.
   • 프로젝트의 계획 변경에 영향을 미칠 수 있는 사항에 대해 고객과 스폰서에게 알린다.
   • 팀에 대한 개인적인 기여를 충실히 행하며 책임질 수 있는 행동을 한다.
   • 팀의 성과에 영향을 미칠 수 있는 잠재적인 문제점에 대해 다른 팀원들과 정보를 공유한다.
   • 전체적으로 볼 때 프로젝트에 가장 최선이 되는 것에 초점을 둔다.
   • 프로젝트가 완료될 때까지의 전체 프로세스를 항상 염두에 둔다.
 

다음으로는 프로젝트를 수행하는 동안 팀원들이 지켜야 할 합의된 행동 기준으로 프로젝트와 팀을 위해서 팀원들 사이에 합의된 사항으로 팀 행동규범을 정한다. 

   • 팀 구성원들이 따라야 할 규칙에 대해 합의
   • 회의 진행, 의사결정, 갈등 해결 등을 위한 방법 결정
   • 문제가 발생했을 때 스트레스를 줄여주고 문제를 보다 빨리 해결하기 위한 방법 결정
   • 팀원들이 프로젝트에 대해 공식적인 위임사항과 주인의식을 가지고 프로젝트에 몰입할 수 있도록
     역할과 책임 결정
   • 프로젝트에 도움이 된다고 생각하는 기타 지침 사항


행동 규범을 설정할 때 팀원 모두는 앞에서 언급한 사항을 포함하여 기대하는 사항들을 자유롭게 브레인스토밍으로 팀원 각자의 의견을 충분히 제시한다. 제안된 아이디어를 평가하여 팀의 행동규범으로 선정하게 된다. 이렇게 작성한 행동규범은 반드시 팀원 모두가 자주 모이는 회의실 또는 팀원 모두가 볼 수 있는 장소에 게시해두고 항상 염두에 두도록 하는 것이 좋다.

마지막으로 팀은 즉각 해결을 할 수 없는 회의 동안에 언급되는 아이디어나 이슈들을 정리하고 해결하는 방법을 마련해 두는 것이 필요하다. 아이디어를 정리하는 방법으로는 “parking lot”과 조치 활동이 필요한 이슈를 정리하는 “이슈 리스트(Issues list)”이다. 
Parking lot은 회의시 중요하지만 현 상황에서 거론할 이슈는 아닌 것들을 따로 모아 두는 것을 말한다. Parking lot은 차를 모아 두는(주차) 장소인 주차장의 개념을 유사하게 인용하여, 아이디어의 모음(집합)을 말한다. 이슈 리스트는 프로젝트를 수행하는 동안 내/외부 팀들에게 발생할 수 있는 조치 사항(action items)의 해결 과정을 모니터/통제 하는데 활용할 수 있다. “Action Item List” 라고도 한다. 

프로젝트 수행을 위해 사람만 모였다고 효과적인 프로젝트 팀이 되는 것은 아니다. 효과적인 프로젝트 팀으로서 동고동락하면서 프로젝트를 수행하기 위해서는 팀원 각자가 어느 수준 정도로 프로젝트에 기여할 것인가를 팀 내에서 합의를 구하고, 프로젝트와 팀을 위해서 합의된 사항으로 팀 행동규범을 정하여 스스로 지키고자 하는 노력이 필요하다.


* 프로젝트 매니지먼트 전문가(PMP), 프로젝트 매니지먼트 코치(PMC) - 허정재(hur@psi.co.kr)
Posted by 노터니

3. 조직 구성
  (1) 조직 구성
     ① 목적 : 공통된 목표 달성을 위한 협력체계 확립
     ② 소프트웨어 개발 생산성에 큰 영향을 미침
     ③ 작업의 특성과 팀 구성원 사이의 의사교류에 영향을 미침
  (2) 프로젝트 팀의 구조
     ① 프로젝트별 조직 : 프로젝트의 시작에서 개발 완료까지를 한 팀이 전담
     ② 기능별 조직 : 계획 수립과 요구사항 분석팀, 설계 및 구현팀, 테스트 및 유지보수 팀
     ③ 매트릭스 조직 : 개발 요원들은 고유 관리 업무와 기능 조직에 동시 관련, 필요에 따라 요원을 차출하여 팀을 구성하고, 작업이 완료되면 원래의 소속으로 복귀
  (3) 의사 결정 방법에 따라 팀 구성
     ① 중앙 집중형 팀 구성
     ② 분산형 팀 구성
     ③ 혼합형 팀 구성

4. 중앙 집중형 팀 조직
  (1) 의사 결정권이 팀 리더에게 집중 (계층형 구조)
  (2) 책임 프로그래머 팀 (chief programmer team)
     ① 외과 수술 팀 구성과 유사
     ② 책임 프로그래머 : 요구사항 분석과 설계, 주요부분의 코딩, 코든 중요한 기술적 판단, 작업의 지시
     ③ 프로그램 사서(program librarian) : 프로그램 리스트 관리, 설계 문서 및 테스트 계획 등을 관리
     ④ 보조 프로그래머 : 책임 프로그래머를 보좌, 기술적인 문제의 자문, 사용자 및 품질보증 팀과의 섭외, 책임 프로그래머의 감독 하에 부분적인 분석, 설계, 구현 업무도 담당
     ⑤ 프로그래머 : 책임 프로그래머의 지시로 각 프로그램 모듈의 코딩
  (3) 특징
     ① 의사 결정이 신속함
     ② 소규모 프로젝트에 적합
     ③ 초보 프로그래머를 훈련시키는 기회로 적합
  (4) 단점
     ① 한 사람의 능력과 경험이 프로젝트의 성패를 좌우
     ② 개인의 창의성 발휘나 집단의 의견 수렴 기회 결여

5. 분산형 팀 조직
  (1) 민주주의식 의사 결정
     ① 링(ring)형 구조
     ② 서로 협동하여 작업을 수행하는 비이기적인 팀(Egoless)
     ③ 구성원이 동등한 책임과 권한 소유
  (2) 다양한 의사 교환 경로 소유
  (3) 특징
     ① 구성원의 작업 만족도가 높음
     ② 의사 교류의 활성화
     ③ 장기 프로젝트에 적합
  (4) 단점
     ① 대규모 문제 해결에 부적합
     ② 의사 결정의 지연
     ③ 책임 소재의 불명확

6. 혼합형 팀 조직
  (1) 중앙 집중형과 분산형의 단점을 보완한 혼합형 구조
  (2) 특징
     ① 초보자와 경험자를 구분 (중앙 집중형)
     ② 프로젝트 관리자와 고급 프로그래머에게 지휘 권한이 주어짐
     ③ 의사 교환은 초보 엔지니어나 중간 관리층으로 분산
     ④ 계층적인 소프트웨어 구조에 적합
     ⑤ 프로젝트 리더가 검토회에 참석, 작업 조정
  (3) 단점
     ① 기술 인력이 관리를 담당, 개발 경험의 사장
     ② 의사 전달 경로가 길다


Posted by 노터니

SWOT Team: Building Community With Wikis and Weblogs and Other Forums
by Meryl K. Evans and Hank Stroll
April 5, 2005


Online communities have been around for years, but we now have more tools for building them. The options include Weblogs (blogs), wikis, forums (bulletin boards), email discussions and online chats. Each has its strengths and weaknesses.

MarketingProfs readers also found these similar articles helpful

Shifting From Mass Marketing to Micro Marketing

SWOT Team: Inventing Brands

The Distinct Advantage of One-to-One Marketing

Strategic Approaches to Business Event Marketing

Book Reviews: Free Prizes, a Playbook, Touchpoints and Thinking Pink (Not!)

In forums, any registered user can start a new topic, with others responding. The content in wikis is open to the community for adding, editing and deleting as a collaborative effort. (See Wikipedia for a large and well-known example that's done well.)

With blogs, the bloggers control the conversation as they post the topic while customers or others respond through the comments or trackback feature. Only the authors have the ability to modify the original posting. For example, BzzAgent, through its Beelog blog, opens its doors and lets visitors see the inner workings of the company. Such topics have covered the process of hiring a new employee, with the employee introducing herself and writing about her first days with the company. And Marqui has not only its own blog but also a program that invites other bloggers to write about the company.

AbsoluteWrite and AWAI (American Writers & Artists Institute) use forums. Both cover writing-related discussions where writers help each other by giving advice, feedback on content and potential market information. Since AWAI's forums consist of students taking its courses, they often discuss assignments, post study-buddy requests and share drafts for input.

Every one of these communities has success stories, but how do you choose which tools to use in your business?

Have more pressing problems than building a village? The community of 200,000 "MarketingProfs Today" readers is ready to help provide you with new and creative answers to your challenges. Share a marketing challenge and receive a complimentary copy of our book, A Marketer's Guide to e-Newsletter Publishing.

This Week's Dilemma

Building a customer community

We are a new incarnation of a previous analytical instrument company. Our customers are a relatively limited group of chemists and other scientists. I like the idea of a Web-based medium for exchanging information and developing an ongoing relationship with customers and prospects. However, I'm not certain whether a blog, forum or wiki format makes better sense, given the small size of the community How do you determine which format to use for your community?

—Mike K., director of marketing and sales

Previous Dilemma

Mixing and matching marketing tools

I work in a high-tech company and lead a marcom team that produces marketing collateral for hundreds of products for businesses. Which marketing tools are the most effective in a sales cycle, especially when selling to other businesses? How does a company determine which collateral format works best for particular activities, or to target specific decision makers?

—Josie, product manager

Summary of Advice Received

Before determining which marketing vehicle is most appropriate, understand that successful B2B marketing starts with the premise that business people buy when they trust that the perceived value is applicable to them and comes from a stable company. Our responses mirror the four main points of this mantra:

  1. Earn trust.
  2. Show value.
  3. Establish relevancy.
  4. Demonstrate stability.

Once you understand this concept, determine how it will best fit within each of your activities. Doing so should help you decide which particular collateral format works best. Below, you’ll find a chart based on information from our readers that lists which particular marketing vehicle is best suited for specific situations. Josie, we hope this will make your selection process easier!

1. Earn trust

The following four steps contribute to building trust with your customers:

  • Know your customers.
  • Be a credible source.
  • Speak from integrity.
  • Build a community.

Knowing your customers provides you with information about the problems they need solving. When you help them close the gap, trust builds. Why should they believe what you say? That's where credibility comes in. Offering expertise from your company and industry experts shows you have your finger on the pulse of the industry.

"Thanks" to spam and phishing, marketing has a chink in its armor. But companies with integrity come through naturally through their words and actions. This column depends on the MarketingProfs community. If the answers to readers' problems come from just the two authors, the answers would be limited. Having the whole community involved allows you to get many perspectives.

2. Show value

Make sure that your marketing methods are about your customers, not you. Your customers don't care if your stock soars. They don't care if you hire a new person. They don't care if you land a big client. Only your stockholders want to know about such things.

Your customers have a problem that you can fix. When you repeatedly save them time and keep them informed, they eventually see the value in the services or products you offer.

3. Establish relevancy

The mantra continues: know thy customer. If you wear a blindfold while playing a game of darts, how do you think you'll do compared with not wearing one? You'll have a greater chance of scoring high when you know your targets and their interests.

If you have a coffee-related product, it may make sense to market tea. But you'll increase your chances of hitting the mark if you upsell with coffee grinders, mugs, coffee makers and perhaps even a book on the topic. Try marketing soda to the same crowd, and you'll be in trouble unless you've lucked out by having a coffee-'n-soda market.

The lesson: the marketing vehicle should be relevant to the users' wants and needs. Determine how you are going to solve their problems.

4. Demonstrate stability

After many Internet-related businesses crashed, and with companies continuing to merge, stability has become an issue. Who wants to buy a product from a manufacturer that's going out of business and won't be around to help with repairs? In the same way a company builds trust, it can prove its stability through its actions.

Implementing the Strategy

Now comes the hard part. How does a marketer implement this four-pronged strategy? By paying attention to the marketing vehicle most appropriate. Developing marketing materials that tie this mantra into the steps of a sales cycle makes for successful marketing.

The steps of a business-to-business sales cycle help a person move through a natural buying cycle, from prospect to client. The following table aligns the step in the sales cycle with an appropriate marketing activity. Each marketing activity must address one or more of the four points of our mantra.

Sales Cycle Step Definition Marketing Activity
Suspects Have a business problem Tradeshows, partnerships (other companies), alliances (associations), public speaking, articles, newsletters, purchasing lists
Prospects Express interest in solving this business problem Newsletters, seminars, Webinars, white papers, PR
Leads Express interest in having your company solve the business problem Response to a "call to action" within any of the above, or an ad
Qualified Leads Spend a considerable amount of time and/or share their specific business problem with your company to determine how you can help solve the business problem AND they have a budget Qualification questions, quiz, survey, consultative conversation, NDA
Client Signs contract with your company to solve their business problem Draft Proposal, final proposal, contract, NDA

Determining what tools work best in the sales cycle means looking at how you can make the four steps happen. What efforts allow you to earn trust, show value, establish relevancy and demonstrate stability? Answer those questions, and you’ll know which marketing vehicle to choose.

It takes a village to address many problems and a community of 200,000 MarketingProfs readers is right here to lend a hand.

MarketingProfs.com


Posted by 노터니

프로젝트 관리자는 그들의 능력 범위 내에서 많은 기술을 갖고 있는 제너럴리스트(Grneralist)이다.

그들은 분제를 해결하는 사람들이며, 실제 전문적인 기술을 소유하고 있을 수 있지만 반드시 필요한 조건은 아니다.


일반 경영에 대한 견실한 이해와, 좋은 프로젝트 관리기법을 이해하고 적용하는 것이 포부를 가진 모든 프로젝트 관리자에게 도움이 된다.


 프로젝트 관리자의 도구

 1 의사 소통(Communication)

 프로젝트 관리자의 가장 중요한 특성 중 하나는,뛰어난 의사소통 기량이다.

 프로젝트 의사소통(프로젝트 문서, 회의 정보, 상태 보고서 등)으로 정보가 숨김없이 명백하고

 완전하다는 것을 보증하는 것이 프로젝트 관리자의 의무이다.


 2 조직기술(Organizational skill)

  조직 및 기획기술은 프로젝트 관리자가 갖고 있어야 할 두번째로 중ㅇ요한 기술이다.

  조직은 많은 양식을 갖고 있다. 프로젝트 관리자로서 프로젝트 문서화, 요구사항 정보, 메모,

  프로젝트 보고서, 개인 기록, 판매자 견적서, 계약서 등 많은 것을 기록하여 보관해야 한다.

  또 회의를 주관하고 팀을 구성하고, 프로젝트에 대한 미디어 밢일정을 작성하고 관리해야 한다.


  시간관리 기술은 조직 기술과 밀접한 관련이 있다. 그것은 문제 및 중단에 우선순위를 정하는 것

  을 돕고, 일정에 우선순위를 부여하고, 시간을 관리하기위한 약간의 훌륭한 팁과 기법을 제공한

  다.


 3 예산편성(Budgeting)

  프로젝트 관리자는 예산을 수립하고 관리하며, 그러기위한 재무 지식 및 회계 운리에 대한 약간의

  지식을 필요로 한다.


 4 문제 해결(Problem solving)

  문제해결은 이중 프로세스이다.

  먼저 문제를 정의해야한다. 문제의 증상뿐만 아니라 문제의 본질을 기술해야 한다. 그러기 위해서

  는 "이것은 내부 문제인가", 이것은 기술적인 문제인가", "팀원간 대인 관계 문제인가", 그것은 관

  리 될 수있는가" 등의 질문은 문제의 핵심에 도달할 수있도록 도와준다.

  문제 정의 후 의사결정을 해야 한다.


 5 협상 및 영향력(Negotiation and Influencing)

  효과적인 문제 해결을 우히ㅐ 협상과 영향력이 요구된다.

  협상은 타인의 동의를 얻기 위한 행동이다. 프로젝트에 있어서 협상은 범위 정의, 예산편성, 계약,

  자원배정 등 거의 모든 영역에 필수적이다.

  영향력은 다른경우라면 그렇게 하지 않을 행동을 하도록 만드는 능력이다. 이러한 기술은 프로젝

  트 관리의 모든 영역에 이용된다.


 6 지도력(Leading)

  리더십 ≠ 관리 (동의어가 아님)

  리더는 비전을 제시하고, 전략적 목표에 대한 동의르르 얻어내고, 방향을 수립하고, 분발하게 하

  며 동기를 부여한다.

  관리자는 결과에 초점을 맞추고, 요구사항에 따라 업무를 수행할 수 있도록 한다.

  프로젝트 수행시 두가지 특성 모두를 갖추어야 한다. 리더십과 관리에 있어 전환할 때와 다시 돌

  아갈 때를 이해하는 것은, 잘 조율하여 사용할 필요가 있는 능력이다.


 7 팀 구축 및 인적 자원(Team building and human resources)

  프로젝트 관리자는 팀 구축 및 인적 자원 관리 기술에 상당히 의존한다.

  프로젝트 관리자는 직접적인 보고대상이 아닌 팀원을 동기부여 하는데 책임이있다.




-------------------------

출처 : 정보문화사의 "Project Management Professinal"(킴 헬멘 저/류한석 역)

Posted by 노터니
프로젝트 성과는 프로젝트 관리자의 커뮤니케이션 능력, 정보관리기술, 기획·분석력, 위험예측 및 대응능력의 4가지 필수소양 수준에 따라 크게 달라진다. 더욱이 이들은 기본적인 지식 위에 실전경험이 더해짐으로써 획득할 수 있는 능력이다.
 
 
(1) 기획·분석력
 
우수한 기획력의 바탕에는 여러 현상의 이면을 꽤 뚫어 최초의 핵심원인을 파악할 수 있는 빠른 통찰력이 있다. 현상에 대한 올바른 이해 없이 계획된 프로젝트는 ‘허상을 쫓는 모래성 쌓기’. 시간과 비용 낭비만을 초래한다.
 
- 원인해결의 대안은 현상을 직시하고 이를 논리적 사고로 분석할 경우에 발견될 수 있다.
- 강한 정보수집 능력은 최선의 대안을 좀더 신속히 찾게 될 가능성을 좀더 높여준다.

결국, 우수한 기획과 분석능력은 프로젝트 출범에 앞서 명확한 목표와 바람직한 방법을 확인하기 위해 필요한 것으로서, 프로젝트가 그릇된 이정표를 앞세우고 출발되는 것과 잘못된 항해지도를 가지고 먼 길을 돌아가는 것을 예방한다.
 
< 기획에 대한 다양한 정의 >
 
- 아이디어의 완성도를 높이는 작업.
- 희망과 꿈을 자기주도적 행동에 의해 현실로 바꾸어 가는 과정.
- 개인 혹은 집단의 문제의식을 해체하고 재결합시켜 조직의 과제로 현재화(顯在化)하는 작업.
- 특정상황에 적합한 구체적인 해결책을 창조하거나 재구성하는 목표 지향적 행동.
- 문제발견, 문제의 형상화, 행동화에 이르는 일련의 시스템을 만들어 가는 과정.
 
- 예정된 행동을 설명하는 일련의 유기적인 시스템으로 목적달성을 위한 제반 자원의 결합방식을
  결정하는 행위.
 
- 어떤 과제달성을 위해 해야 할 업무의 이미지를 묘사하고, 전체 또는 세부에 걸친 구상을 다듬고
  한데 모아서 제안  내용의 정리까지 마무리 짓는 모든 작업 과정.
 
 
(2) 커뮤니케이션 능력, 정보관리기술
 
분야를 막론하고 거의 모든 프로젝트가 다양한 사람들이 상호 공조하는 ‘협업(協業)’으로 이루어진다. 그리고 이들은 자신이 속한 조직이나 업무위치에 따라 일종의 프로젝트 환경이거나 할당 받은 자원으로 활동영역을 정의한다.
 
따라서 프로젝트 관리자가 이들을 얼마나 효과적으로 인솔하거나 조정할 수 있는가 하는 것은 프로젝트 성패에 매우 중요한 영향을 미치는 요소이며, 이때 우수한 프로젝트 관리자에게 필요한 것이 커뮤니케이션 능력과 정보관리기술이다.

< 우수한 팀워크, 이해집단과의 원활한 공조를 좌우하는 합리적 커뮤니케이션 능력 >
 
- 대체로 프로젝트 팀원은 다양한 인적자원으로 구성되는 경우가 많기 때문에
  관리자의 합리적인 커뮤니케이션 능력에 따라 팀워크는 크게 좌우된다.
 
- 또한 대부분의 프로젝트에서 원인해결의 대안은 내부에 존재하지 않아 외부 조력자와의 공조는
  필수적이게 된다.
 
- 프로젝트는 직,간접적으로 다수 이해관계자(또는 집단)의 영향을 받게 된다.
  유관 이해관계자와의 합리적인 이견조율과 협상은 프로젝트가 중도에 잘못된 길로 빠져들거나
  좌초되는 것을 막는 최고의 예방법이다.
 
 
< 프로젝트를 통해 수집된 대량정보의 분류, 문서화, 공유기술 >

 

- 프로젝트를 통해 수집되거나 프로젝트 수행과정에서 작성된 대량정보의 적절한 공유는

  내,외부적인 협력활동을 향상시킨다.

 

- 관계자의 쉬운 이해와 빠른 전달, 적재적시에 사용이 가능한 문서화 기술은 프로젝트 실행을

  원활히 하기 위한 기본 토대이다. 그러나 정보공유가 과도할 경우 정보유출의 문제가 발생하고,

  미흡할 경우 커뮤니케이션 오류의 문제가 발생된다.

- 따라서 체계적인 분류와 정보의 형태별 공유규정을 시스템화하는 것은 프로젝트 관리에서 매우

  중요한 일이다.



(3) 위험예측 및 대응능력


위험상황은 시장변수의 영향, 이해집단의 영향, 계획의 차질, 팀워크의 붕괴, 재무적 위험에서 비롯된다. 때문에 각각의 영역에 대한 폭넓은 이해을 쌓고 프로젝트 노선에서의 제약사항을 위험요소와 결부시켜 생각하는 습관을 들여야 한다.


Posted by 노터니

★ 다음 사항을 가정해서는 안된다.


1. 이 프로젝트가 수행되는 동안 팀 구성원의 변화는 없을 것이다.

2. 고객은 자신들이 무엇을 원하는지 안다.

3. 품질 보증을 위한 시험은 한 달이면 충분하다.

4. 6개월에 처리될 업무는 소프트웨어 엔지니어 3명이 2개월이면 할 수 있을 것이다.

5. 처음 출발이 옳으면 시스템 시험과 설치는 몇 일 안 걸릴 것이다.

6. 시스템은 다른 지역에서도 완벽히 운영되었으니, 한 명의 신입사원에 의해 3일이면 설치가 가능할 것이다.

7. 일정에서 빠진 것은 나중에 추가하면 된다.

8. 고객은 메뉴얼을 읽고 스스로 공부할 것이다.



★ 다음 사항은 피해야 한다.


1. 초기에 고객의 동의 및 서명을 받고 명확하고 상세하게 기술된 계획을 가지고 있지 않다.

2. 명세서를 작성하지 않거나, 고객이 서명한 명세서가 없다.

3. 확실하고 간결한 시험 계획이 없고, 시험 결과에 대해 고객의 서명을 받지 않았다.

4. 막연한 낙관론 또는 프로젝트가 곤경에 처해 있다는 것을 인정하지 않는다.

5. 프로젝트 납기일을 정하기 이전에 수행시기를 결정한다.

6. 내가 대하고 있는 사람이 결정권자 혹은 결정할 수 잇는 유일한 대상은 아니라는 생각을 한다.

7. 프로젝트의 범위 설정에 실패한다.

8. 프로젝트 구성원에게 모든 계획 변경 사항의 전달이 부족하다.

9. 통제를 충분히 하지 못한다.

10. 요구 사항 변경을 함에 있어서 상응하는 요원(직원) 변경이 없다.

11. 수행에 대한 계획이 부진하거나 고객측 위임 사항에 대한 계획이 부족하다.

12. 휴일, 휴가, 효율, 일반적인 소모 등을 감안하지 않은 개발 일정을 수립한다.




★ 다음 사항에 유의해야 한다.


1. 공식적인 시스템 개발 방법이 모두에게 인식되어야 하며 엄격하게 시행되어야 한다.

2. 테스트를 위해 충분한 시간을 할애한다.

3. 신입 사원 보충이 필요할 때는 그에 따른 교육 기간을 염두에 두어야 한다.

4. 효과적으로 의사 교환을 해야 한다.

5. 고객과 프로젝트팀으로부터 피드백을 요청한다.

6. 고객과 좋은 관계를 유지한다.

7. 업무 분기점을 부적절하게 나누면 일정상의 부족한 점을 간과하게 된다.

    업무 분기점은 구체적이어야 한다.



위 사항들은 S/W 프로젝트 관리자가 준수해야 일반적인 주의 사항 이라는 군요 ^^;


Posted by 노터니
프로젝트 관리자
1.      모든 관련 관리자를 방문한다.
2.      발주자의 중점 강조 부분을 알아야 한다.
3.      Tool은 변해도 관리의 원칙은 변치 않는다.
4.      공정한 대우를 한다.
5.      식은 열정, 미그적거림, 나약한 PM은 부적격하다.
6.      다음 과제를 기다리는 자가 되어야 한다.
7.      문제 해결은 자신이 해야 한다.
8.      장미의 향을 맡기 위해서는 머무름이 필요하다.
9.      HOW보다는 WHAT을 알아야 한다.
10.   성공한 모든 관리자는 유능하다고 할 수 없다.
11.   모든 사람을 귀중히 여기라.
12.   너무 완고한 고집을 하지 말라.
13.   자신이 직접 모든 것을 해서는 안된다.
14.   팀원의 기술과 실력에 의한 성공만이 있다.
 
초기작업
15.   문제의 씨앗은 항상 초기에 제거해야 한다.
 
의사소통
16.   모든 사안은 Partner와 미리 대화를 거쳐서 결정한다.
17.   적임자를 찾은 후 대화를 못하는 것은 죽은 것이다.
18.   국제 회의시 오해의 소지가 없게 대화를 배려한다.
19.   꾸준한 관리 교육 참여가 신 관리자를 만든다.
 
사람
20.   원하는 품질 유지토록 관리 해야 한다.
21.   적용전에 과거의 관리를 평가해 보고 사용한다.
22.   문서작성자, 검토자 보다도 실제 작업할 팀원이 중요하다.
23.   대부분의 문제는 사람에 있다.
24.   일에 중독자가 되지 않도록 팀원을 관리 한다.
25.   최하위 작업자의 지원을 받을 수 있도록 하라.
26.   부적절한 팀원이 있을시는 신중히 검토후 전배를 고려한다.
27.   불필요한 작업을 최소화 해준다.
28.   감시가 능사는 아니다. 함께 해결한다.
29.   보상이 동기 부여를 촉진 시킨다.
30.   작업 성과를 공개한다.
31.   난이도가 어려운 일은 생산성이 낮다.
32.   일의 목적 및 기대사항을 파악하는 것이 중요하다.
33.   추가 투입인원이 필요시 음식에 소금넣듯이 조금씩 추가적으로 투입하라.
 
검토와 보고
34.   검토와 검토자를 선정하고 절차를 수립한다.
35.   꼭 검토가 필요한 자료만을 대상으로 한다.
36.   숨김없이 사실에 입각한 검토를 받는다.
37.   외부 검토자와는 일정조정이 매우 어려우므로 급박한 일정에 대비 하도록 항상 준비한다.
38.   공개 석상에서 팀원을 공격하지 않는다.
39.   검토는 검토자를 위한게 아니고 제출자를 위함이다.
40.   작업 수행 회의는 6명 정도가 적당하다.
41.   검토대상 자료는 단순하고 명확해야 한다.
42.   서면 보고에만 의존하는 관리는 실패 가능이 높다.
43.   문서화된 자료가 현재를 모두 반영하고 있지는 않다.
44.   잘된 월간보고는 년간보고를 필요로 하지 않는다.
45.   상세한 내용의 설명이 필요시에는 한다.
46.   장래의 작업을 대폭 절감시켜줄 사안에 대해서만 철저한 주장을 경주 한다.
 
계약자와 계약절차
47.   프로젝트 관리자는 계약의 주된 주체이다.
48.   프로젝트 관리는 스코어로 관리되어서 보상한다.
49.   계약자와 관련한 인원의 도덕성이 중요하다.
50.   계약자와 우호적인 관계는 좋으나 계약자와의 지지자 관계는 업무 수행에 방해가 된다.
51.   모든 팀원은 비용에 관계한다. 계약자와의 1:1접촉은 유의한다.
52.   계약자는 프로젝트 관리자가 만만하게 보일 때 자격 미달자를 투입하는 경향이 있다.
53.   가능하면 합의된 계획을 바꾸지 않아야 한다.
54.   고객의 만족을 일정, 비용, 우수한 결과물에 있음을 숙지하고 있어야 한다.
 
기술자와 과학자
55.   기술자는 미로와 퍼즐을 좋아 하므로 특히 단순한 설계를 하도록 유의해서 리드한다.
56.   기술자는 낙천주의자 경향이 있으므로 문제를 조기에 느끼지 못하기에 일정과 비용 커브로써 징후를 파악해야 한다.
57.   문제를 해결할 수 있는 자원은 프로젝트 팀내에 있는 자원이 가장 적임자들이다.
58.   고객중에는 과학자도 있다는 것을 명심해서 보고시에 참조한다.
59.   대부분의 과학자는 신임을 갖을 때 합리적이다.
 
하드웨어
60.   사소한 변경도 운영환경을 변화 시킬수 있다.
61.   설계의 이해 부족이 구성 스펙의 이해 부족을 초래한다.
 
컴퓨터와 소프트웨어
62.   최신의 기법을 사용않는 것은 큰 실수이지만 컴퓨터가 생각을 대신해 주리라는 기대는 더 큰 실수이다.
63.   새로운 Version이 아무리 완벽해도 Old Version은 관리하고 있어야 한다.
64.   지식은 시뮬레이션과 테스팅을 통해서 향상된다. 그러나 컴퓨터 모델은 어떤 입력자료의 내용이 잘못된 것인지 감춘다.
65.   과거의 실경험에 의한 기술 습득 방법 대신 최근에는 컴퓨터가 확인만 해주지 말해 주지는 않는다.
 
Senior 관리자, 프로그램 사무실, 기타
66.   상위 관리자에게 궁금한 사항이 있으면 항상 문의하면 놀랄만한 것을 얻을 수 있다.
67.   자신의 관리 기법 특징을 알고 있어야 한다.
68.   경영진의 의견이 틀리고 나의 의견이 맞다고 생각 될때에는 주저말고 주장하고 그래도 경영진이 결정을 내리면 경영진의 의견을 따르고 성공 실현을 위해서 최선을 다하라.
69.   자신이 결정 할수 있는 것은 반드시 자신이 하지 경영층에 묻지 않는다.
70.   프로그램 관리자와는 한 팀웍으로써 일해야 한다.
71.   의사 결정을 하는 당사자와는 공식 비 공식적으로 항상 대화를 나눌 수 있는 길을 유지해야 한다.
 
프로그램 훈련, Budgeting, Estimating
72.   초창기 수립된 자금, 일정에 근거해서 예산, 리스크, 실패불용, 납기내의 사항들을 만족시키는 예술을 강요 당하고 있다.
73.   과거 실패 프로젝트는 실수에 있었던게 아니고 부실한 예측에 원인이 있었다.
74.   모든 문제를 적기에 해결 하려고 하면 일정상에 비상용 시간을 확보해 두어야 한다.
75.   Fixed Price계약 하에서는 엄격한 범위 관리가 필수적이다.
76.   동원 가능한 자원제공처를 가능한 많이 확보하고 있어야 한다.
77.   최소한의 내용만 비밀 사항으로 분류해야 팀원의 시야를 넓일 수 있다.
78.   자신의 팀이 가지고 있는 장점을 부각 시켜라.
79.   항상 내년에는 충분한 예산과 일정을 확보할 수 있을 것이라면 내년을 50년 후가 될수도 있다.
 
고객
80.   고객을 누구이고 그들의 목적은 무엇인지 항상 염두에 둔다.
81.   관리 지침이 현실과 맞지 않을 시에는 보완해서 향상 시킨다.
 
의사결정
82.   조기에 한 잘못된 결정은 쉽게 고칠수 있으나 늦게 결정한 옳은 결정을 바로 잡을 수 없다.
83.   그냥 기다리는것 자체가 해결책이 될때도 있다.
84.   실 상황에 근거해서 의사결정을 해야 한다.
 
Professional Ethics and Integrity
85.   자기의 부하가 자기를 믿을 때 나의 정직을 말해준다.
86.   자신의 경영자를 약하게 하는 것은 장기적으로 결국을 자신에게 이득이 되지 못한다.
 
프로젝트 관리와 팀웍
87.   모든팀은 보스 보다는 코치를 필요로 한다. 항상 코치는 선수를 부르고 있어야 한다.
88.   높은 스트레스를 받는 작업중에는 반드시 구체적인 작업 관리를 해야 한다.
89.   부족한 지원 보다는 행운을 믿는게 좋을수도 있다.
90.   팀원이 잘못된 정보로 인해서 틀린 결론에 도달한 것을 놀라지 않는다.
91.   관련 모든 고객을 기쁘게 할수있는 것이 관리자의 할 일 이다.
 
Treating과 실패 회피법
92.   실패한 경우의 예(a,b,c)
a)      알려진 모든것을 포함하고 있는 항목만으로 일정을 결정한다.
b)      아는 사실만을 기로하고 모든 이론을 Check한다.
c)      자백하기 전에는 자료를 비판하지 않는다.
d)      결론을 성급하게 내리지 않는다.
e)      멈춰야 할 시점을 안다.
93.   성공과 실패 교훈을 적극 활용 한다.
94.   리스크가 큰것은 대안과 비상계힉을 작성해야 한다. 실수는 용납가능 하지만 실패는 용인될 수 없다.
95.   완료된 모든 인증과 테스팅에도 불구하고 부분적인 문제는 있었다는 것을 이해한다. 대비하는 것은 단지 안전 장치에 불과하다.
96.   경험도 좋지만 실제 테스팅이 더욱 좋다.
97.   실패를 두려워 하면 성공 할 수 없다.
98.   팀의 가장 큰 힘 중의 하나는 잘못할 수도 있다는 사실을 모든 팀원이 알고 있는 것이다.
99.   여분의 하드웨어를 갖고 실패에 대비하는 것은 허구에 그칠 수 있다.
100. 고객에게 용서를 빌지 말고 앞으로 집행할 계획을 수립해서 제시하라.

출처 : Tong - 미니아빠님의 PM통

Posted by 노터니

최상의 프로젝트 관리자에 대한 고찰



글 _ Aaron Lazenby (Profit : The Business of Technology 특집 기사 편집장)



Center for Business Practices의 조사에 따르면, 모든 규모의 기업들은 비즈니스 혁신을 위해 복잡하면서도 비용이 많이 드는 프로젝트를 추진하고 있다고 한다. 프로젝트 관리자 및 기타 프로젝트 영향력자(비즈니스/사무 관리자 및 경영진)를 대 상으로 실시한 조사 결과, 전체 엔터프라이즈 프로젝트 중50% 이상이 복잡성 문제를 안고 있었으며, 40%는 100만달러이상 의 비용이 드는 것으로 나타났다. 많은 기업들이 직면하고 있는 프로젝트 관리 문제를 보다 자세하게 살펴보기 위해, 오라클 고객 및 전문가들을 한자리에 모아 프로젝트 및 기술, 그리고 이들 간의 교차점에 대해 논의하도록 했다.

*Oracle : 엔터프라이즈 소프트웨어와 마찬가지로 프로젝트가 점차 복잡해지고 있습니다. 관리를 목표로 설계된 프로젝트와 비슷한 속도로 기술도 진화하고 있습니까?


*Meg Lassarat(Mustang Engineering의 CFO) : 텍사스 주 휴스턴에 본사를 둔 Mustang Engineering은사람중심/프로젝트 중심을 모토로 하는 글로벌 프로젝트 관리 및 엔지니어링 업체입니다. 전 세계적으로 석유 및 가스 발굴 작업은 점차 복잡해지고 있습니다. 대상 고객들이 대규모의 다국적 석유 업체들을 비롯한 패브리케이터(fabricator)라는 점에서 복잡성 및 안전의 시급성 문제를 더욱 절감하고 있습니다. 석유 및 가스 업계의 경우 3~4년 마다 기술의 비약적인 발전이 이루어지고 있습니다. 이에 더 복잡한 지역에서 석유 및 가스를 발굴해 출시할 수 있도록 돕는 새로운 기술이 등장하고 있습니다. 가장 큰 문제는 바로 이들을 연결하는 것입니다. 우리는 건축 업체, 엔지니어링 업체, 석유 업체, 최종 사용자, 파이프라인 업체 등 관심사와 관점이 서로 다른 다양한 팀과 협력하고 있기 때문에 프로젝트 성공을 위해서는 이들을 하나로 연계할 수 있는 능력이 무엇보다 중요합니다.


*Amy Halverson(Fair Isaac의 비즈니스 애플리케이션 담당 디렉터) : 미네소타주 미니애폴리스에 위치한 의사 결정 관리 전문 업체로서, 첨단 분석 기능을 통해 고객의 의사 결정 전략을 향상시키는 Fair Isaac은 점차 전 세계로 사업을 확장하고 있습니다. 이제, 모든 사람들이 같은 사무실에 모여 앉아서 프로젝트를 수행하고 서로 의견을 교환하던 시대는 지났습니다. 또한, 보다 강화된 규제 관리 문제도 처리해야 합니다. 예를 들어, 사베인스-옥슬리(Sarbanes-Oxley)법은 우리에게 지대한 영향을 미치고 있습니다. 이 때문에 프로젝트 비용이 30%정도 상승할 수 있습니다. 원래의 프로젝트 요구사항은 물론, 이와 같은 모든 추가 외부 요구사항을 처리할 수 있는 능력을 갖춰야 하는 등 더욱 복잡해지는 양상을 띠고 있습니다. 우리는 컨퍼런스 콜, 화상 회의, 실시간 협업 등과 같은 새로운 기술을 활용해 이러한 문제를 해결하고 있습니다. 이제 더 이상 물리적 인 승인이 필요한 테스트 조건의 연결 고리가 없습니다. 이러한 환경은 감사가 어려운 것은 물론, 문서 관리 및 워크플로우에 더 많은 시간을 할애해야 합니다.


*Nari Kikkeri(InnerWireless의 전략 계획 담당 디렉터) : 텍사스주 리차드슨에 본사를 둔 InnerWireless는 무선 유틸리티 서비스 사업자이자, 기업 및 건물 소유자를 위한 구내(inbuilding) 무선 분배 시스템 설치 업체로서, 한 번에 최고 150건, 2,000만 달러 규모에 달하는 프로젝트를 진행하고 있습니다. 프로젝트가 진행되는 동안 고객, 벤더, 계약자 및 직원들이 참여하게 되며 비용 관리, 문서 관리, 예산 책정, 용량 계획 등 고려해야 할 범위를 늘리기 시작하면 프로젝트가 매우 복잡해집니다. 이로 인해 프로젝트 실행 과정이 매우 어려워질 수 있습니다. 따라서 우리는 프로젝트를 성공적으로 수행할 수 있도록 탄탄한 전략 계획과 통합 프로젝트 툴을 마련해야 합니다.



*Oracle : 연결성 문제가 모든 기업의 공통 현안인 것 같습니다. 그렇다면 기업들이 프로젝트 협업을 강화하고 프로젝트 관리에 있어 최상의 실행 방식을 적용하기 위한 툴 투자를 망설이게 만드는 요인으로는 무엇이 있습니까?



*Suhail Maqsood(Oracle Projects 제품 관리 담당 그룹 매니저) : 우리가 보기에 고객들은 까다로운 주요 프로젝트 관리 영역에 초점을 맞춰 솔루션을 설치하거나 실행하고 있습니다. 그러나 고객들은 지금까지와 달리 프로젝트 관리를 중심 으로 비즈니스 프로세스를 정의해야 할 필요성에 대해 점차 인식하기 시작했습니다.



*Lassarat : 실제로 지금까지는 제대로 연결되지 않았습니다. 기술 때문이 아니라, 프로젝트에서 직면하는 과제들을 실질적으로 해결하지 못했던 기업이나 관료적 보고 체계 내의 타성이 문제였습니다.



*Halverson : 우리 프로젝트는 다양한 영역에서 보다 빈번 하게 진행되고 있습니다. 따라서 규모와 상호 의존도가 점차 커지고 있습니다. 또한, 현재 상태를 고수하고 지식을 공유하지 않으려는 것이 인간의 자연적인 본성입니다.



*Jeffrey D. Ford(오하이오 주립 대학교 피셔 경영 대학의 경영 및 인적 자원 부교수) : MBA 과정의 관리자들을 통해 알게 된 것 가운데 하나는 그들이 일반적으로 다른 작업에 접근할 때와 거의 같은 방법으로 대규모 프로젝트에 접근하고 있다는 사실입니다. 관리자들은 동일한 습관과 실행 방식을 따르고 있지만, 복잡성이 심화되면 이러한 습관 및 실행 방식이 깨지기 시작합니다. 기술을 통해 소위 타성이라 불리는 습관이나 실행 방식의 붕괴를 극복할 수 있을까요? 실제 극복에 있어서는 어느 정도 한계가 있을까요?



*Lassarat : 저는 사람을 고치는 것보다는 기술을 고치는 것이 훨씬 쉽다고 생각합니다. 따라서 사람이 작업을 하도록 하는 대신 시스템이 작업을 수행하도록 하면 훨씬 높은 투자 효과를 거두는 것은 당연합니다. 일부 대규모 프로젝트에서 흔히 볼 수 있듯이, 엔지니어들은 사실 기술 보다는 행동 변화가 필요한 경우에도 기술 솔루션을 통해 문제를 해결하려는 경향이 있습니다.



*Halverson : 변경 관리에 드는 노력을 과소평가해서는 안됩니다. 이를 위해서는 당근과 채찍이라는 두 가지 접근 방식이 필요합니다. 프로젝트 관계 당사자들에게 프로젝트의 이점을 보여 주는 동시에 이들로부터“기업으로서 당연히 할 일을 하고 있다”고 말할 수 있는 올바른 스폰서를 확보하는 것이 중요합니다. 프로젝트 스폰서와 경영진은 프로젝트의 방향을 설정하고 프로젝트를 통해 실현할 비즈니스 가치를 정의해야 합니다.



*Ford : 복잡하면서도 횟수가 잦은 프로젝트에서도 대부분 크게 성공을 거두고 있습니다. 물론, 일정이나 예산이 초과된 프로젝트도 있고 시스템 전반에서 붕괴 현상이 나타나는 등 완전 실패로 돌아간 프로젝트도 있습니다. 그렇다면 이러한 일정 또는 예산 초과의 원인이 무엇이라고 생각하십니까?



*Lassarat : 첫째는 기대치를 분명하게 설정하지 않았기 때문이고, 둘째는 경영진이 프로젝트 변경에 적극 개입하지 않았기 때문입니다. 조선소에서 변경하는 것보다는 설계대에서 변경을 하는 것이 훨씬 쉽습니다. 또한, 변경 관리에 대한 신속한 의사 결정 여부도 세 번째 요인이 될 수 있습니다.



*Halverson : Fair Isaac은 훨씬 규모가 작을 뿐만 아니라 급격한 변화를 겪고 있는 기업입니다. 제가 가장 고전을 겪을때가 바로 프로젝트 중간에 비즈니스 우선순위가 바뀌는 경우 입니다. 예를 들어, 시장 출시 전략에 있어 중대한 변경을 수행 하는 동시에, SFA(Sales Force Automation)를 구현할 수 있습니다. 이 경우, 프로젝트 지연이 발생하게 됩니다. 하지만, 이와 같은 경우에는 시대의 흐름에 따라 문제를 해결하고 다시 계획을 세웠습니다. 이러한 문제로 인해 예산 및 일정이 초과하게 됩니다.



*Kikkeri : 우리는 구내 무선 유틸리티를 설치하고 있습니다. 또한, Time Warner 빌딩이나 Children’s Memorial Hospital 등과 같은 대규모 프로젝트를 진행하고 있습니다. 빌딩 용적이 백만 평방피트가 넘는 경우도 있습니다. 따라서 각 평방피트 마다 비용 및 수익을 추적할 수 있도록 탄탄한 프로젝트 수행 계획을 내놓아야 합니다. 상세 수준에서 비용을 추적한다는 것은 쉽지 않은 일이지만, 시스템 기능을 세부 조정함으로써 이를 완료했습니다. 가장 중요한 관건은 비즈니스 프로세스를 이행할 수 있도록 적절한 기능과 기술을 갖춘 유용한 툴을 확보하는 것입니다.



*Maqsood : 그동안의 경험에 따르면, 서로 다른 시스템을 구축하고 서로 다른 스프레드시트를 작성하는 경우, 프로젝트 관리자가 필요한 보고서를 준비하고 원래 계획을 기준으로 자체 평가하는 것이 더욱 힘들어 진다는 사실을 고객들이 잘 인식 하지 못하고 있습니다. 프로젝트를 중앙에서 정의할 경우 모든 이해 당사자들이 공통된 위치에서 프로젝트 비용을 추적할 수 있습니다. 따라서 프로젝트 관리자는 물론, 기타 로그온을 해서 정확한 현재 상태를 확인할 수 있는 권한을 가진 사람이면 누구나 프로젝트를 추적할 수 있습니다.



*Lassarat : Mustang의CFO로서 여기에 전적으로 동의합니다. 저는 여러분들이 엑셀 사용에 대해 이야기 하는 것을 듣고 깜짝 놀랐습니다. 이러한 단일 버전의 정보는 매우 중요합니다. 모든 사람들이 동일한 데이터 세트를 사용할 경우 데이터를 분석할 수 있는 능력도 마찬가지로 중요합니다. 프로젝트의 모든 구성원들이 서로 다른 요구를 가지고 있지만, 여러분 모두가 같은 데이터를 가지고 작업을 하고 있다면 올바른 데이터를 가진 사람이 누구인지를 두고 논쟁을 벌일 일은 없을 것입니다. 이러한 논쟁은 매우 소모적입니다. 또한, 사람들이 우리가 데이터를 제대로 이해하고 올바르게 해석할 수 있도록 돕기 보다는 누가 올바른 데이터를 가지고 있느냐를 두고 논쟁을 벌이는데 많은 시간을 소모하고 있을 때 좌절감을 느끼게 됩니다.



*Halverson : 예측 데이터와 실제 데이터를 함께 수집해서 단일 지점에서 확인할 수 있도록 단일 시스템을 갖추는 것이 가장 중요합니다. 프로젝트 관리자는 이러한 2가지 정보를 함께 수집하는 데 많은 시간을 들이고 있습니다.



*Lassarat : 그렇다면 올바른 정보를 가진 사람은 누구일까요? 여러분은CFO에게 어떤 정보를 전달했습니까? 그 정보는 프로젝트 디렉터에게 전달되었습니까? 그렇다면 고객은 어떻습니까? 정보를 받았습니까? 여러분은“알겠습니다. 상단 우측 코너에 며칠로 날짜가 표시되어 있습니까?”라고 말할 것입니다.



*Kikkeri : 누군가가 날짜나 시간을 잘못 이해해서 프로젝트가 조금 늦게 끝나게 되는 상황이 있습니다. 프로젝트 중간에 고객이 추가 자재를 요청할 수도 있습니다. 이 경우, 우리는 시스템에서 작업이 아직 진행 중인 것으로 표시되었기 때문에 자재를 선적해야 합니다. 1시간의 차이로 인해 프로세스 문제가 야기되거나 부서에 심각한 결과가 초래될 수 있습니다. 이것은 의사소통의 문제입니다. 오후 2시라고 말해도 다른 지역의 사람들은 이를 다르게 해석합니다.



*Maqsood : 또한, 프로젝트 팀이 시간대가 서로 다른 여러 국가로 분산되는 글로벌 프로젝트가 증가할 것으로 예상하고 있습니다. 기업들이 점차 글로벌화 되고 전 세계에 걸쳐 프로젝트가 수행되면서 프로젝트에서 해결해야 될 과제도 늘고 있습니다. 프로젝트 관리 실행에 어떤 툴이나 제품을 사용할 것인지 올바른 결정을 내려야 합니다. 왜냐하면 이러한 의사 결정은 프로젝트 중심의 기업에게는 핵심 부분이기 때문입니다. 올바른 툴을 갖추지 않으면 이기종 시스템으로 도태되고 사용자들은 다양한 소스에서 정보를 복제하고 진행 중인 프로젝트에 서의 현 위치를 총체적으로 파악할 수 없습니다.



*Ford : 여러분들이 어떤 경험을 통해 대규모 프로젝트를 프로젝트 참여자의 삶으로까지 연결해 이해할 수 있게 되었는지 궁금합니다. 저는 프로젝트 관리자와 많은 작업을 수행해 왔고, 이 과정에서 알게 된 사실 하나는 프로젝트 체계가 구축되어 있는 경우에도 프로젝트 참여자의 자체 일정에 따라 성공적인 프로젝트 수행에 필요한 작업은 끝나지 않았다는 것입니다. 이렇게 많은 사람들이 분주하게 움직였지만 놓친 부분이 있다는 것입니다. 이 경우 앞으로 돌아가 작업을 다시 수행해야 합니다. 그렇지 않으면 프로젝트의 일부가 과도하게 진행되고 이를 전체 진행 상황에 맞게 되돌리기 위해서 추가 자원을 투입해야 하는 상황이 발생합니다.



*Kikkeri : 현재 한층 향상된 기능을 갖춘 차세대 프로젝트 툴을 모색하고 있습니다. 이를 통해 프로젝트에 과도한 인력을 할당할 필요가 없을 것입니다. 하지만 중요 일정 계획을 수립한 상태에서 프로젝트를 시작하는 상황이 있습니다. 물론, 가장 좋은 방법은 프로젝트 팀으로 하여금 올바른 툴과 기술을 가지고 준수 일정에 따라 자신들의 능력과 자원을 최대한 활용하도 록 하는 것입니다. 프로젝트 팀이 여유 시간을 가지고 다른 프로젝트의 요구를 살펴볼 수 있다면 프로젝트에 적극 참여해 이러한 자원을 작업에 투입할 수 있을 것입니다. 우리의 프로젝트 자원 가운데 일부는 이러한 방식으로 배치되었습니다. 즉, 주요 멤버들은 몇 건의 프로젝트를 맡아서 이를 책임지고 성공적으로 수행하고 있습니다.



*Lassarat : 우리는 3,500명의 전문가를 보유하고 있으며, 대기업은 아닙니다. 그러나 프로젝트 관리자를 한 축으로, 부서 관리자를 다른 축으로 하는 매트릭스를 사용하고 있습니다. 따라서 프로젝트 관리자들은 개별 프로젝트에 초점을 맞추고 있지만 부서 관리자들은 프로젝트에서의 엔지니어 충원을 일부 책임지고 있습니다. 이들은 개별 엔지니어들이 자신의 업무와 프로젝트 내에서의 맡은 바 역할을 제대로 이해할 수 있도록 합니다. 엔지니어는 한 번에 10건의 프로젝트에 관여할 수 있습니다. 한편, 부서 관리자는 모든 프로젝트에서 우선순위를 설정할 수 있도록 돕는 것은 물론 개별 엔지니어가 자신이 수행하고 있는 업무를 이해할 수 있도록 도와야 합니다.



*Halverson : 우리도 비슷한 상황으로, 프로젝트 관리자 와 자원 관리자 모두에게 주 단위로 주요 보고서가 나가고 있습니다. 따라서 프로젝트 관리자들은 엔지니어들이 프로젝트에 얼마나 많은 시간을 할애하고 있는지 확인하고, 인력 배치 현황을 토대로 그들이 실제 기대하고 있는 것이 무엇인지 파악해야 합니다. 이를 통해 보다 효과적으로 커뮤니케이션하는 것은 물론, 주요 일정에 맞춰 보고할 수 있습니다. 또한, 적정 시기에 해당 프로젝트에 적절한 직무 능력을 갖춘 올바른 인재를 보유하는 등 올바른 자원 관리를 수행할 수 있습니다. 우리는 이제 막 전문 서비스 기업을 위한 자원 관리 모듈을 롤아웃 했으며 이를 통해 여러분은 매우 유연하게 스케줄링을 수행할 수 있습니다. 예를 들어, 내가 이러한 직무 능력이 필요로 할 수도 있고, 이러한 직무 능력을 통해 해당 사이트에서 누군가를 검색해 단기적 또는 장기적으로 특정 비율(%)로 자원을 스케줄링 할 수
있습니다. 올바른 프로젝트 관리는 매우 중요합니다. 그 날의작은 실수나 일정 위반으로도 기업은 수백만 달러의 비용 손실을 입을 수 있습니다.



원탁회의 참가자 - Jeffrey D. Ford(오하이오주 콜럼버스에 있는 오하이오 주립 대학교 피셔 경영 대학의 경영 및 인적 자원 부교수), Amy Halverson(미네소타주 미니애폴리스에 있는 Fair Isaac의 비즈니스 애플리케이션 담당 디렉터), Nari Kikkeri(텍사스주 리처드슨에 있는 InnerWireless의 전략 계획 담당 디렉터), Meg Lassarat(텍사스주 휴스턴에 있는 Mustang Engineering의 CFO), Suhail Maqsood(캘리포니아주 레드우드 쇼어에 있는 오라클의 Oracle Projects 제품 관리 담당 그룹 매니저)



프로젝트 관리는 모든 규모의 기업들에게 있어 매우 중요한 과제입니다. 최근 업계 조사에 따르면 일반 기업들이 진행하고 있는 전체 프로젝트의 50% 이상이 복잡성 문제를 안고 있으며, 40%는 100만 달러 이상의 비용이 소요되는 것으로 나타났습니다. 프로젝트 및 기술에 대한 원탁회의를 통해 오라클 고객 및 전문가들이 프로젝트 관리를 위해 얼마나 고군분투하고 있는지 알 수 있습니다.

글로벌 프로젝트 관리 및 엔지니어링 업체인 Mustang Engineering이 직면한 가장 큰 문제 가운데 하나는 바로 연결성입니다. 프로젝트의 성공 여부는 다양한 팀을 지속적으로 상호 연결할 수 있는 능력에 달려 있습니다. 의사 결정 관리 전문 업체 Fair Isaac역시 점차 세계적으로 사업을 확장하고 있지만, 프로젝트 비용 증가의 한 요인으로 규제 관리를 지목하고 있습니다. 이 업체의 경우 성공을 위해 실시간 협업, 화상 회의, 컨퍼런스 콜 등과 같은 새로운 기술을 도입하고 있습니다.

협업과 연결성은 가장 일반적인 과제이지만, 일부 업체들의 경우 프로젝트 협업을 강화하고 프로젝트 관리를 위한 최상의 실행 방식을 구축하기 위한 툴에 투자하는 것을 망설이고 있습니다. 이는 타성에 젖은 탓도 잇지만, 분산된 프로젝트 팀 간의 상호 연결성을 관리하는 문제 때문이라는 의견도 있습니다. 프로젝트가 성공을 거두지 못하는 데에는 여러 가지 이유가 있습니다. 명확한 기대치가 없이 복잡하기만 한 프로젝트가 있는가 하면, 프로젝트 중간에 우선순위가 변경되면서 제대로 추진되지 못하는 프로젝트도 있습니다. 프로젝트 관리자들은 모두 프로젝트 관리 성공을 보장하기 위해서는 올바른 툴 선택과 함께 효과적인 의사소통이 가장 중요하다는 데 의견을 같이하고 있습니다.



제공 : DB포탈사이트 DBguide.net


Posted by 노터니

1. 프로젝트조직이란

'특정한 목표를 달성하기 위하여 일시적으로 조직 내의 인적·물적 자원을 결합하는 조직형태'라고 정의하였음. 팀 구성원 상호간에는 평등한 입장에서 업무를 수행함으로써 창의와 자주성이 도입될 것이다. 목표달성이 되면 팀은 당연히 분산되고 전원이 종전 원래의 부서로 돌아간다. 예) 대통령 인수위원회, 건설교통부에서 행정도시 추진위원회

단점

1. 프로젝트의 성공은 프로젝트에서 주요한 기능을 수행하는 개인과 리더에 달려 있어 개인적 부담이 큼

2. 프로젝트 구성원의 원래 소속된 조직과 프로젝트 사이의 조정을 하여야 하며 이를 원만히 해결하지 못할 때는 갈등이 생기게 된다.(스트레스가 발생하기 쉽다.)

3. 시간, 비용, 기술의 제약 하에서 이용 가능한 자원을 이용하므로 자원이 중복이되기 쉽다.

장점 

1. 조직이 구성이 있는 동안 대량의 자원과 재능을 집중할 수 있다는 것이다.

2. 라인 조직이므로 프로젝트 관리자는 라인의 장이며, 그는 프로젝트를 실현하는 책임과 권한을 갖고 있음(책임과 평가의 명확성)

3. 프로젝트 목표달성, 이익목표달성을 프로제트 수행 중의 모든 의사결정을 하므로 , 결정시간이 단축된다.

2.  매트릭스조직

전통적 기능조직과 프로젝트조직이 결합된 구조의 조직으로 자율성 속에서 전문성을 도입할 수 있는 프로젝트팀의 장점을 입체적으로 살  가지며 이중의 명령체계에 속한다

단점

1. 매트릭스 조직은 두 사람의 상사에게 보고하고 통제를 받는 이중적구조 때문에, 때론 심각한 갈등을 유발하기도 합니다(명령계통간의 권력다톰이 발생하기쉽다) 

2. 원활한 의사소통을 위해 많은 시간이 필요합니다(조정을 위한 의사결정이 지연되기 쉽다.)

3. 조직 구성원들이 정보와 권한을 공유하지 못하면 제 기능을 발휘하기 어렵다는 것도 단점 가운데 하나이다.

4. 두사람의 상사에게 보고하고 통제하므로 책임과 권한이 애매하다는 단점있다.

장점

1. 조직내부의 자원을 각 사업부가 효율적으로 사용할 수 있고,

3. 사업역량과 자원을 효율적으로 이용하면서도 자율적이고 독립적으로 일할 수 있도록 매트릭스 조직의 효율을 극대화 시킬 수 있다.

4. 구성원 모두가 자율권을 가지고 창의적으로 일할 수 있어야 합니다. 

Posted by 노터니
Posted by 노터니

팀 조직이란?


유연성, 민첩성을 제고하기 위해 팀 조직을 지향하는 기업들이 늘고있다.
치열해지는 경쟁으로 인해 기업의 성과를 제고시키고자 하는 노력이 다양한데
그중 하나가 계층형 조직을 팀 조직으로 전환하는 방법입니다.
팀의 대표적인 형태는 스포츠 팀을 떠올릴수 있다. 팀의 승리가 최우선 과제가 되며,
이의 달성을 위해서 팀 구성원들이 상호 협력하면서 밀접하게 움직인다.
개개인의 성과도 중요하지만, 팀의 승리를 위할때만 정당화 된다.
상호보완적 능력을 가진 구성원들이 공동의 목표 달성을 위해서 공동으로
작업을 하며 그 결과에 대해 공동 책임을 지는 집단입니다.
팀이 되기 위해서는 그 집단의 목표가 구성원의 밀접한 공동 노력에 의해서
달성되어야 한다. 축구팀의 경우를 연상해 보자. 부분의 합 보다 전체가 크다는
시너지 효과를 생각해야 한다. 팀은 의사 결정을 스스로하는 자율권, 공동의
의미있는 목표, 그리고 결과에 대한 책임을 동시에 갖는다.
그리고 업무 수행의 유연성을 증진시키고, 여러가지 일들이 서로 잘 연결
되게 한다. 예를 들면 생산 공정에서의 생산은 부품 조달, 기계 정비, 수용 ㅖ측등
여러 가지 다른 업무들과 유기적으로 연결되어 수행되어야 의미가 있다.
구성원들의 노력 여하에 의해 달라 지는 업무 수행결과로 인해 각자의 존재 가치를
높일수있다.


네트워크 조직이란?


21세기는 인터넷을 중심으로 한 디지털 경제 시대이다. 인터넷 사용인구의 폭발적 증가,
정보통신 관련 주식 가격의 폭등 등 요즘 우리 주위에서는 디지털 시대가 펼쳐지고 있다.
정보통신 분야에서의 경이적인 기술 혁신의 속도가 빨라 지면서, 비즈니스 방식에
변화가 나타나기 시작했다. 이에 따라 조직 구조에 있어서도 변화가 일고 있다.
실체가 있는 다수의 기업, 각 분야의 사람들이 인터넷으로 연결 되면서 마치 하나의 기업처럼
프로젝트를 하는 것이 당연시 되고 있다. 또한, 동일 기업내의 별개조직이 인트라넷을 통하여
동시에 각분야의 스탭들을 집결,동원할수 있고, 완료시 다시 각각의 조직에 반환하는것이
당연시 되고 있다.
네트워크 조직은 경쟁 기업, 공급업체, 고객들과 사호 긴밀하게 연결 되어, 기업들이 마치
복잡한 거미줄을 치고 있는 것처럼 보이는 조직이다.
참여 기업들은 하나 혹은 일부 기능에 특화한다.
예를 들어 나이키를 보자. 나이키는 핵심기술인 'Air System'개발과 마케팅에 전념하고, 생산등의
다른 기능은 전세계적으로 두어, 장기 공급 계약이나 전략적 제휴를 함으로써 효율적인 운영을
하고있다. 나이키는 원재료 공급자와 매업자 등을 조직화, 조정하는 기능을 주로 담당한다.
또다른 예로는 소니를 들 수 있다. 가전 회사의 대명사인 소니는 더 이상 제품을 직접 생산하지 않는다.
본사에서는 최고의 디자이너와 엔지니어들만이 존재하며 생산 활동은 일본에 있는 제조 전담 자회사가 담당하고 있다.
또한 미국에 있는 현지 법인에서는 주로 일본 본사에서 핵심 역량을 가지고 있지 않은 사업에 주력하고 있다.
네트워크 조직은 정보의 공유를 통한 가치 창출이다. 기업내의 부서간ㆍ개인간의 정보 공유, 공급업체와의 정보 공유,  고객과의 정보 공유를 통하여 가치를 창출하는데 적합한 조직 형태이다.
대표적인 예로서 GE의 TPN(Trading Process Network)을 들 수 있다.
 TPN은 GEIS(GE Information Services)와 Thomas Publishing의 합작에 의해 만들어진 것으로서 생산자, 부품 공급자, 소비자가  한곳에서 거래가 가능하도록 하는 인터넷 기반의 시스템이다. 이것은 15만5천여사에 이르는 토마스사의 방대한 데이터베이스와 GE가 보유하고 있는 네트워크 조달 시스템의 노하우와 정보를 결합시킨 일종의 부품 조달 시스템이다.
GE는 TPN 시스템을 통해 구매 부문의 업무 효율화를 실현할 수 있었다. 또한 대량의 설계도면이나 사양서를 관리하는 등의 복잡한 부품 조달 과정을 전자화 또는 자동화시킴으로써 수발주 업무의 리드 타임을 크게 줄일 수 있었다. 이러한 내용은 모두 공급업체와의 정보 공유 및 지속적인 협조 체제를 통해 상호간의 윈윈 전략을 추구한 결과라고 할 수 있다.


가상조직이란?


가상조직(virtual organization)은 21세기에 고객의 요구가 매우 다양해지고 기술은 점점 더 복잡해져서 기술개발에 필요한 비용을 한 기업이 감당하기 힘든 상황에서 정보네트워크 기술의 발전을 이용한 새로운 기업간 협력을 통해 극복하려는 경쟁전략의 일환이다.
목표가 달성되면 해체한다.
즉,  가성조직은 다양한 업종의 기업이 각 개별 업체가 보유하는 경쟁력 있는 기술과 자원을 통합하여 우수한 제품 및 서비스를 고객에게  신속하게 제공할 수 있도록 특정기간 동안 일시적으로 제휴하는 것이다
가상조직을 쉽게 설명하면 야구나 농구경기의 올스타 팀에 비유될 수 있다.
즉 가상조직은 핵심 능력과 자원을 세계수준의 올스타 팀으로 통합하는 것이다. 가상조직은 한 제품이나 서비스를 기준으로 어떤 사업기회에  공동으로 참여하는 통상적인 네트워크조직보다 훨씬 효과적이다. 가상조직을 자원준거 관점에서 볼 때 상호의존적인 기업들의 핵심역량을 모아 놓은 것(pooling)으로 볼 수 있다.
 가상조직은 핵심역량의 연계를 통해 고객이 원하는 해법을 가장 효과적으로 또 가장 빠르게 달성할 수 있는 조직으로, 규모의 경제(economies of scale)와 범위의 경제(economies of scope) 외에  속도의 경제(economies of speed)도 이루는 조직형태이다. 이는 마치 미국 농구 올림픽 국가대표팀이었던 'DREAM TEAM'과 흡사하다. 가상조직은 세계에서 가장 우수한 핵심역량을 가진 기업들이 정보기술을 통해 시간과 장소적 한계를 뛰어 넘어 올스타 팀에서 만난 것으로 이해할 수 있다. 가상조직은 연구개발, 시제품생산, 제조, 마케팅, 유통, 서비스 등 광범하게 있는 세계적 핵심역량들을 가장 효과적이면서 효율적으로 하나로 묶을 수 있는 조직구조이다. 가상조직은 핵심적 역량들을 결합한다는 점에서 핵심적인 기능만 자신이 직접 수행하고 나머지 부수적인 기능은 다른 조직을 활용하는 네트워크조직과는 구분된다. 

Posted by 노터니
TAG 조직

Power politics and the IT project

Author:
Ron Condon
Posted:
17:05 14 Jan 2008

Who calls the shots when it comes to starting new IT projects in your organisation?

Does the IT department come up with all the good ideas and then get the company management to rubber-stamp them? Does the IT department just wait to hear what the company wants, and then meekly try to deliver it? Or is the IT department tightly integrated in the corporate decision-making process, consulted on difficult matters, and generally seen as a vital partner to the rest of the company?

If you can honestly answer that you fall into the last of the three categories, then read no further, because this article has nothing to teach you.

However, despite all the talk we hear about aligning IT with company strategy, it seems that in many companies IT still ends up as the dog's-body of the organisation. It is asked to perform miracles against impossible timescales, and then becomes a convenient scapegoat when things go wrong.

ADVERTISEMENT

One man who has studied the problem is Michael Gentle, a solutions architect with Compuware. He says the rot started to set in when IT departments became service departments whose function is merely to deliver what the company asks for, on time, on budget and to specification.

"The client/supplier relationship turns IT into an order-taker, so the emphasis is on doing the project right, not on doing the right project.

"That would not be bad if upstream there were a rational decision-making process. But this is not the case. Investment decisions are usually made on the basis of executive influence," he says.

And by executive influence he means it is decided by who shouts loudest (what he calls "decibel management") or is prompted by what the chief executive has read in a business magazine or newspaper.

"Far from being the rational and structured process we would like it to be, demand management is a nebulous combination of decibel management and organisational politics," he says.

Gentle says he has observed this in a variety of industries, and bears the "scars and stripes" of real experience to prove it.

The trouble with the IT department acting as a supplier to the business, is that it has little incentive to go beyond the specification that it is given.

The rapid pace of technological change also adds to the problem, because companies are tempted to try them out before they are mature.

Gentle is critical of the return on investment (ROI) exercises that take place to justify going ahead with IT projects. "The business case for IT is subjective, it is in the eye of the beholder. Every new project is new, so the benefits tend to be over-estimated, while costs are under-estimated," he says.

"There is no requirement to monitor the benefits over the lifecycle of the application.

The ROI is just used to launch the project. Once it is launched, then the business case is shelved."

The answer, he says, is for IT to become a strategic partner or trusted adviser of the business, not just an order-taker. Gentle says bringing about such a change to the business can be "a tall order".

But if IT can become a strategic partner, there can be instant consequences. Instead of just delivering to time, budget and specification, the IT department can share risk and rewards. The business can provide the IT department with an incentive to ensure the project continues to deliver after the system is launched.

"IT should not sit in its corner and wait for requests to come. It should engage with the business, using account managers, client managers, business-relationship managers - whatever you want to call them - to manage the relationship with the operational department," he says.

"So if you are in charge of sales and marketing systems, for instance, you do not just sit back and wait to be asked. You have regular meetings to understand what their business objectives are, challenge what they want IT to do, and propose alternatives. In short, arrive at a joint decision about which project requests are going to be funded. That is a trusted adviser status."

Decisions also need to be taken out of the CEO's hands, if that is possible. A proper investment committee, consisting of both IT and business managers, can properly assess each new proposal in a more rational way, and since risks are shared, both sides have an incentive to make it a success. Each project is scored by cost, benefit and risk.

Gentle also recommends a portfolio management approach to new projects. This means seeing individual projects not in isolation, but in context with other systems, and categorising them against different business goals - such as cost reduction, revenue generation, or regulatory compliance. That implies a far more rational advisory role for IT in helping to set priorities and ensure projects happen in the most logical way.

And finally, he says projects need to be subject to continuous performance monitoring. "At the moment, the business case is used to launch the project then it is forgotten," says Gentle. "But the business case shifts all the time - you have to monitor the benefits as well as the costs. If you find an application is not delivering benefits, you stop it and kick off something more promising."

If the IT department is in a client-supplier relationship with the rest of the business, and you decide to stop a project, he says, then it means someone made a mistake, and their head has to roll.

So how do companies match up to Gentle's vision? All companies have their own slant on IT and do things differently, and much depends on the style and type of organisation involved.

For instance, at Scottish law firm MacRoberts, IT director David Murphy has a fairly free hand to launch new projects as he sees fit. He supports around 270 desktops at two sites in Glasgow and Edinburgh, and has an IT department of eight people.

But, as he says, the sole concern of the fee-earners in the firm is to have their systems up and running and to be able to get at information when they need it.

He has introduced Blackberries to allow users to receive e-mail remotely and says this will be extended to let them access company files as well.

"Most of the ideas come from IT, but we also have a lot of smart lawyers too who talk to their peers. The trick for us is to stay ahead of the game, so that we can tell them what is good and bad about some of the ideas they bring to us."

The situation can be quite different in the public-sector. At Hampshire County Council head of IT Jos Creese and his team are required to help meet public demand for more interactive and joined-up services, but with static or shrinking budgets.

"In a typical year we will deliver over 200 projects, and we are increasingly looking closely at whether or not those projects individually are delivering the maximum possible value, not just meeting the typical project measures of 'time, quality and budget' targets.

"Benchmarking with the public and private sector, for example, has not shown any organisation with a lower cost base for basic desktop IT services than we are delivering. We are also adopting ITIL on the basis that a repeatable and consistent way of doing things will increase productivity and performance," says Creese.

IT and the business work together on assessing benefits and cost, he says.

"All projects should be considered in the first place as business projects with an appropriate assessment of costs and benefits - indirect and direct. Where judgments need to be made about the unquantifiable benefits, this should be done openly and transparently and judged on a business, not a technology basis. ROI more often than not needs to be harvested corporately not in individual service teams, requiring a considered approach to business change across the organisation."

That kind of close working requires skills that may not be in abundance in many IT departments. As Michael Gentle says, IT needs people to act as account managers who can work with the individual business departments and help to interpret and manage their demands.

And once a project is approved, a competent project manager needs to be found, which is not always easy, according to Ian Campbell, chairman of the Corporate IT Forum and head of IT at British Energy.

"People with those skills are few and far between," he says. "Project management can be complex and wide-ranging with lots of parallel work-streams going on. You need to know how to ask the right questions, make the right forecasts and get the plans right, in order to make the overall programme come together properly. That is why you see a lot of this going out to the consultancies because they are used to doing a lot of project-based work."

Campbell says the other big challenge for IT is managing the demands of the business, especially where a go-live deadline is set from the start.

"There is a disproportionate emphasis placed on launch dates. People set a date for a project, and that can take precedence over everything else, meaning that other things can be compromised. If you allow it to go live on the date but not when it is ready, then the project is tarnished," he says.

Again, this comes back to good project management, and skilled forecasting and continuous review during the course of the project, to ensure it stays on track.

As he says, "Boring is good in project management - it needs to be well organised. You do not want to have to call in the Red Adairs at the last minute to rescue you."


Posted by 노터니

The politics of project management


While there are plenty of how-to resources for project managers, the politics of project management is one topic they likely won't find in the industry literature, according to Bill Hagerup, a 30-year IT veteran and a consultant at Ouellette & Associates Consulting Inc.


To meet that need, the Bedford, N.H.-based firm is planning a new workshop, "The Politics of Project Management," which will complement its current IT project management and professional development offerings.


CW: What do you mean by the "politics of project management?"


Hagerup: Project managers have all the responsibility for getting the job done, but no direct authority to make it happen. The people on the project team report to somebody else who probably has a different agenda.


To make matters worse, project managers need resources—dollars, time and people—and there is never enough to go around in any organization. So project managers must compete for these scarce resources with other project managers in the same organization.


Given that competition, conflicts naturally arise. Project managers must use politics: the art of acquiring, developing and using power to influence others to do what you need them to.


CW: What about project managers who want to avoid politics?


Hagerup: They can't. Politics is out there. It's real. Project managers will surely encounter two kinds of political problems: some that others create and some that project managers create by their own blunders.


So those who ignore politics, or who think of it only as being unethical and nasty, are making a big mistake. And they often become scapegoats when projects fail.


CW: What do project managers need to know about politics?


Hagerup: Like the fable of Star Wars, politics has a dark side and a side of light and right. The dark side includes sharklike behaviors of scheming, arguing with customers and bullying.


Project managers and team members need to stick with the positive side of politics and navigate the political potholes in their organization. They need to build relationships and get to know people on the project team, as well as the customers, vendors and sponsors. Part of politics is motivating people by helping them to see what's in it for them when they cooperate with the project goals.


CW: Aren't most project managers too busy for politics?


Hagerup: Project managers are busy people. And many naively believe that if they keep their noses to the grindstone and work hard, everything will be OK. But there's more to the job than mastering project management software and generating reports.


While that approach may have worked on smaller jobs, it won't work on projects that are more complex, highly visible and have the potential to change the corporation. In the end, there's really no choice. If project managers fail to make time for the politics of their projects, including communicating, relationship building and facilitating agreement, ultimately, their projects will fail.

Posted by 노터니