Curso de Pós-Graduação MBA Executivo Gerência de Projetos André Baptista Barcaui Princípios de Gerência de Projetos e Gerência de Integração

Transcrição

1 Curso de Pós-Graduação MBA Executivo Gerência de Projetos Professor: Disciplina: André Baptista Barcaui Princípios de Gerência de Projetos e Gerência de Integração

2 Curso de Pós-Graduação MBA Executivo Gerência de Projetos Princípios de Gerência de Projetos e Gerência de Integração Prof. André Baptista Barcaui

3 Sobre o Material Didático Todos os direitos em relação ao design deste material didático são reservados à Fundação Getulio Vargas. Todos os direitos quanto ao conteúdo deste material didático são reservados ao(s) autor(es). Diretores das Escolas EBAPE/FGV Prof. Bianor Scelza Cavalcanti EPGE/FGV Prof. Renato Fragelli Cardoso Diretor do IDE Prof. Clovis de Faro Diretores Executivos FGV Management Prof. Ricardo Spinelli de Carvalho FGV Online Prof. Carlos Longo FGV PDE Prof. José Guilherme Heráclito Lima Núcleo FGV - Brasília Profª. Maria do Socorro V. de Carvalho ISAE Amazônia Profª. Rosa Oliveira de Pontes ISAE Paraná Prof. Norman de Paula Arruda Filho ILG Alphaville (Barueri-SP) Prof. Marilson Gonçalves Superintendentes Regionais Prof. Paulo Mattos de Lemos Prof. Silvio Roberto Badenes de Gouvêa Prof. Djalma Rodrigues Teixeira Filho A sua opinião é muito importante para nós Fale Conosco! ouvidoria@fgv.br i

4 1 Sumário 1. PROGRAMA DA DISCIPLINA EMENTA CARGA HORÁRIA TOTAL OBJETIVOS CONTEÚDO PROGRAMÁTICO M ETODOLOGIA CRITÉRIOS DE AVALIAÇÃO B IBLIOGRAFIA RECOMENDADA CURRICULUM RESUMIDO DO PROFESSOR TEXTOS PARA ESTUDO PORQUE GERENCIAR PROJETOS? THE HISTORY OF PROJECT MANAGEMENT CREATING A PROJECT PLAN FATORES CRÍTICOS DE SUCESSO EM GP GERENCIANDO OBJETIVAMENTE SEU PROJETO MATERIAL COMPLEMENTAR... 25

5 2 1. Programa da disciplina 1.1 Ementa Histórico e conceituação de projeto, programa e gerência de projeto. Ciclo de vida e processos de um projeto. Áreas de conhecimento segundo o PMI (Project Management Institute). Estudos de caso, gerência da Integração. Confecção do plano de projeto. Estruturas organizacionais para gerenciamento de projetos. Características do Gerente de Projetos. 1.2 Carga horária total 36 horas/aula 1.3 Objetivos Definir o que é um projeto e os aspectos essenciais inerentes ao seu ciclo de vida; Identificar os fatores que podem levar ao sucesso ou ao fracasso de um projeto; Identificar os principais stakeholders de um projeto e os diferentes papéis que desempenham; Relacionar as áreas de conhecimento em Gerência de Projetos e suas características; Analisar os processos envolvidos na gerência de projetos e seu impacto na condução do mesmo; Descrever os principais itens a serem abordados em um plano de projeto; Estabelecer um paralelo entre a teoria de projetos e a realidade cotidiana na empresa.

6 3 1.4 Conteúdo programático Características de um projeto Histórico da Gerência de Projetos Ciclo de vida e processos de um projeto Áreas de conhecimento em gerência de projetos Confecção do plano de projeto Estruturas Organizacionais para gerenciamento de projetos Análise de Cases voltados para prática e com base na teoria estudada. Conceito e definição de um projeto. Projeto x Programa. O que é gerenciamento de projetos. A evolução da carreira. Stakeholders e sua importância. Fatores que determinam o sucesso de um projeto Posicionamento histórico do surgimento e desenvolvimento da disciplina.. Iniciação. Planejamento. Controle. Execução. Finalização. Overlap das fases. Introdução as áreas de: escopo, tempo, custo, qualidade, recursos humanos, comunicação, risco, e aquisições. Sub-processos envolvidos em cada área. A importância do plano de projeto. O que abordar. Controle do plano ao longo do projeto. Gerência de Mudanças. Funcional x Projetizada. Estruturas matriciais e suas diferenças. Influência do tipo da estrutura na condução dos projetos Sessão de discussão sobre o tema, trabalho em sala de aula procurando explorar casos reais de projetos. 1.5 Metodologia Apresentação do conteúdo programático com uso de datashow, estudo de casos com apoio de vídeos, vivências e debates.

7 4 1.6 Critérios de avaliação A nota dos alunos estará baseada em dois patamares: Prova sobre o conteúdo da disciplina (60%); Desenvolvimento e apresentação de um trabalho em grupo realizado em sala de aula com base em tópicos relativos a disciplina (40%). 1.7 Bibliografia recomendada A bibliografia recomendada para esta disciplina e que pode servir de apoio e fonte de consulta para os alunos encontra-se listada abaixo: 1. CLELAND, David I. & IRELAND, David. Project Manager s Portable Handbook. New York: McGraw-Hill Inc., CLELAND, David I. Project Management: Strategic Design and Implementation. New York: McGraw-Hill, COHEN, Dennis; GRAHAM, Robert. The Project Manager s MBA: how to translate project decisions into business success. San Francisco: The Jossey-Bass Inc., GOLDRATT, Eliyahu. Critical Chain. Great Barrington: The North River Press, IBBS, William & REGINATO, Justin. Quantifying the Value of Project Management. Newton Square: Project Management Institute, KERZNER, Harold. Project Management: a systems approach to planning, scheduling, and controlling. 8a edição. New York: John Willey & Sons., LEACH, Lawrence. Critical Chain Project Management. Norwood: Artech House, MEREDITH, Jack R. & MANTEL, Samuel J. Project Management: a managerial approach. New York: John Willey & Sons Inc, PROJECT MANAGEMENT INSTITUTE. Project Management Body of Knowledge (PMBOK). Newton Square: Project Management Institute, TAYLOR, James. A Survival Guide for Project Managers. New York: American Management Association (AMACOM), WIND, Jerry Y.; MAIN, Jeremy. Driving Change. New York: The Free Press, 1998.

8 5 1.8 Curriculum resumido do professor André B. Barcaui é Doutorando em Engenharia pela COPPE/UFRJ, Mestre em Sistemas de Gestão pela UFF-RJ e formado em Informática pela PUC-RJ. Possui mais de 12 anos atuando na área de gerência de projetos. Foi Project Office Manager da HP Consulting responsável pela região Latino-Americana e Gerente de Programa e Serviços na IBM, tendo gerenciado vários projetos em diferentes áreas como outsourcing, telecomunicações e gerência de ambiente de IT. É membro-fundador do PMI Chapter Rio, onde concluiu sua certificação PMP em É professor também de MBA s da FGV/RJ, da FIA/USP em Gerência de Projetos e Consultor na área de gerência de projetos e montagem de PMOs. Representa também a empresa ESI International, líder mundial em treinamento em gerência de projetos no Brasil.

9 6 2. Textos para Estudo 2.1 Porque Gerenciar Projetos? André B. Barcaui, MSc, PMP Muitos executivos hoje se perguntam sobre o real valor e aplicabilidade dessa tal gerência de projetos em suas empresas. Se você já ouviu falar sobre isso em alguma palestra ou se você já não aguenta mais aquele seu velho amigo e entusiasta da idéia comentando sobre o assunto, já deve também ter se perguntado a mesma coisa: até onde vale a pena investir tempo e dinheiro para garantir um bom gerenciamento de projetos? Essa mesma pergunta já foi feita e repetida muitas vezes por várias pessoas envolvidas em empreendimentos das mais diferentes complexidades. Da preparação de uma nova campanha de marketing a construção de uma hidroelétrica, de um novo sistema de fluxo de caixa ao envio do homem a lua. Mas onde começou tudo isso? Porque essa febre avassaladora chamada gerência de projetos está sendo ouvida e pregada em toda parte nos dias de hoje? Para entender melhor onde tudo começou é preciso voltar um pouco no tempo. Desde a época das pirâmides, problemas e conceitos relativos a gestão de projetos, já eram sentidos. O termo trabalho foi cientificamente definido por Frederick Taylor ( ), sendo o primeiro a considerar um tipo de desenho de processos. Mas só no pós-guerra é que técnicas de gerenciamento de projetos foram definidas e agrupadas de forma a serem consideradas uma disciplina. O grande catalisador deste acontecimento foi o Departamento de Defesa Americano, que através de iniciativas como o programa Polaris ( ), alavancou ferramentas de diagramação de rede como PERT (Program Evaluation and Review Technique) e tantos outros termos hoje usados, como a famosa sala de acompanhamento de projetos, nossa war room. Depois dos militares, os setores de construção, automotivo, cinematográfico e aeroespacial também foram grandes patrocinadores do crescimento da disciplina, percebendo rapidamente o quanto poderiam estar se beneficiando através dessa abordagem. Gerenciamento de times multi-disciplinares e atingimento de objetivos únicos dentro de períodos finitos de tempo e com limitações de recursos parecia mais factível.

10 E a cada dia surgem novos estudos e técnicas que apoiam as áreas de conhecimento envolvidas no gerenciamento de projetos. Conceitos como os de empresas projetizadas, PMO (Project Management Office), softwares de planejamento e controle poderosíssimos, e metodologias de gerenciamento estão cada vez mais presentes no nosso cotidiano. Como tudo na vida, esse movimento não aconteceu por acaso. É preciso observar o contexto do mundo em que se vive hoje, para compreender o sentido de tamanha revolução. Nada mais seguro de ser afirmar, do que afirmar que nada mais é seguro. As empresas e seus profissionais passam hoje por processos de mudança contínua para evoluírem de acordo com os rumos que o mundo aponta. Por maiores que sejam as diferenças de opinião, não podem ser ignorados os efeitos da globalização, da tecnologia que nos envolve, dos anseios da sociedade que fazemos parte, e principalmente do cada vez mais impaciente, intolerante, e exigente cliente que somos nós mesmos. Os pensamentos relativos à qualidade vêm evoluindo muito desde Deming, Crosby e Juran. A tendência é que vire até mesmo commodity, em um mundo onde cada vez mais a experiência proporcionada por produtos e serviços se tornou a chave para satisfação. Mas essa evolução não é trivial. É necessário poder de adaptação, é necessário muitas vezes mudar literalmente o modus operandi e a forma de pensar para poder evoluir. Cada novo passo, uma mudança, e a cada mudança, um novo projeto. Chegamos ao cerne da questão. Se o desenvolvimento de seu departamento, divisão ou empresa depende de projetos, nada mais justo e razoável do que realizá-los com excelência. Na verdade não se gerencia projetos por gerenciar. O que realmente se espera é uma melhoria de performance. Diretores e clientes não gostam de surpresas. Em função disso, talvez uma outra forma de definir gerência de projetos seja como uma apólice de seguros. Planejamento e controle são partes integrantes do jogo e, por definição, reduzem os fatores de risco envolvidos nesse ambiente de constante mudança. Agora tome o nosso querido Brasil como exemplo. Se partirmos da premissa que todo o risco carrega consigo uma oportunidade associada, que país melhor do que o nosso para se transformar restrições e dificuldades em resultados positivos? É esse o objetivo de se ter projetos bem gerenciados! Diminuir incertezas, atingir a satisfação de seu cliente seja ele interno ou externo, e sair ileso ao fim do projeto. E sair ileso não significa somente entregar dentro do prazo, do orçamento previsto e com qualidade. Existe mais por trás dessa definição de sucesso. Um projeto antes de qualquer coisa é constituído por pessoas. Fazer com que essas pessoas se sintam bem e cresçam ao longo do projeto em torno de um objetivo comum também é um indicativo de sucesso. E todos somos conscientes das dores e delícias embutidas em gerenciar pessoas. Multiplique isso por um ambiente de característica passageira como de um projeto, e veremos a importância do conhecimento e da experiência que se faz necessária a um gerente de projetos. Outro indicativo é o aprendizado armazenado para projetos futuros. As chamadas lições aprendidas. Porque não faz sentido errar duas vezes. 7

11 8 Alguns autores dizem que gerenciar projetos é na verdade gerenciar problemas o tempo todo. Talvez estejam corretos. O fato é que não importando a área de atuação de sua empresa (podemos extrapolar esse pensamento até mesmo para projetos da vida pessoal), é necessário adaptar processos, treinar pessoas, disponibilizar ferramentas, e mover montanhas se preciso para aumentar as chances. E mesmo assim não é garantido. Tirando a ficção e a fantasia de lado, o sucesso em projetos não se dá num passe da mágica. Mas uma coisa é certa: muito pior é nunca tentar. 2.2 The History of Project Management Toney Sisk (Fonte: Project management, in its modern form, began to take root only a few decades ago. Starting in the early 1960s, businesses and other organizations began to see the benefit of organizing work around projects and to understand the critical need to communicate and integrate work across multiple departments and professions. The Early Years: Late 19 th Century We can travel back further, though, to the latter half of the 19 th century and to the rising complexities of the business world to see how project management evolved from management principles. Large-scale government projects were the impetus for making important decisions that became management decisions. In this country, the first large organization was the transcontinental railroad, which began construction in the early 1870s. Suddenly, business leaders found themselves faced with the daunting task of organizing the manual labor of thousands of workers and the manufacturing and assembly of unprecedented quantities of raw material. Early 20 th Century Efforts Near the turn of the century, Frederick Taylor ( ) began his detailed studies of work. He applied scientific reasoning to work by showing that labor can be analyzed and improved by focusing on its elementary parts. He applied his thinking to tasks found in steel mills, such as shoveling sand and lifting and moving parts. Before then, the only way to improve productivity was to demand harder and longer hours from workers. The inscription on Taylor's tomb in Philadelphia attests to his place in the history of management: "the father of scientific management."

12 9 Taylor's associate, Henry Gantt ( ), studied in great detail the order of operations in work. His studies of management focused on Navy ship construction during WWI. His Gantt charts, complete with task bars and milestone markers, outline the sequence and duration of all tasks in a process. Gantt chart diagrams proved to be such a powerful analytical tool for managers that they remained virtually unchanged for nearly a hundred years. It wasn't until the early 1990s that link lines were added to these task bars depicting more precise dependencies between tasks. Taylor, Gantt, and others helped evolve management into a distinct business function that requires study and discipline. In the decades leading up to WWII, marketing approaches, industrial psychology, and human relations began to take hold as integral parts of business management. Mid-20 th Century Efforts After WWII, the complexities of projects and a shrinking war-time labor supply demanded new organizational structures. Complex network diagrams called PERT charts and the critical path method were introduced, giving managers greater control over massively engineered and extremely complex projects (such as military weapon systems with their huge variety of tasks and numerous interactions at many points in time). Soon these techniques spread to all types of industries as business leaders sought new management strategies and tools to handle their growth in a quickly changing and competitive world. In the early 1960s, general system theories of science began to be applied to business interactions. Richard Johnson, Fremont Kast, and James Rosenzweig described in their book The Theory and Management of Systems how a modern business is like a human organism, with a skeletal system, a muscular system, circulatory system, nervous system, and so on. Today This view of business as a human organism implies that in order for a business to survive and prosper, all of its functional parts must work in concert toward specific goals, or projects. In the following decades, this approach toward project management began to take root in its modern forms. While various business models evolved during this period, they all shared a common underlying structure (especially for larger businesses): that the project is managed by a project manager, who puts together a team and ensures the integration and communication of the workflow horizontally across different departments.

13 Creating a Project Plan Joe Launi (Fonte: SD Magazine, Maio de 1999) A solid project plan is a blueprint or a game plan that charts the entire project s course. It should minimize the cost of rework by anticipating and addressing problems early in the project. There is nothing more frustrating for a CIO than approving a project plan only to find out months later that the recommended technology cannot be applied. To combat this, risk assessment is a mandatory step in effective project planning. The fundamental premise of good project management states that the project manager s greatest challenge is effectively balancing the components of time, cost, scope, quality, and expectations. Figure 1 shows the project diamond, which signifies this balance. Figure 1: Project Diamond The components of the project diamond have a symbiotic relationship. For example, when a user requests an additional report that wasn t agreed in the requirement specifications, the project s scope and quality change. This will change the other project components as well. As a result, the diamond s shape will be skewed, graphically depicting a project out of control. The challenge is managing change while keeping the diamond s shape intact. Project planning defines the diamond, while effective change and expectation management lets you manage it throughout the project s life cycle. In this article, I ll define a methodical approach to assembling project plans. This approach will help your team manage client and upper management expectations by accurately and effectively defining any project s scope, cost, time, and quality dimensions.

14 This process combines pre-project discovery methods with proven management science techniques, and consists of the following steps: Performing your factor analysis Developing your project agreement Creating your change control procedures Developing your work breakdown structure Estimating the tasks Creating the schedule Performing risk assessment 11 Performing Your Factor Analysis In the Seven Habits of Highly Effective People (Covey Leadership Center, 1998) author and management scientist Steve Covey writes, To be understood, you must seek to understand. Often, from the moment a project is initiated, developers make assumptions about the effort ahead and how to attack it. Too often, they leap to conclusions about projects to the point of preparing plans or estimates based largely on invalid or incomplete information and the project fails to meet its budget, objective, and schedule expectations. Sooner or later (usually later) in the development process, the conditions you should have discovered in the planning process, like choosing the right mix of human resources, become apparent, and the project efforts or deliverables suffer. How many times have you completed a documentation task only to realize that a technical writer would have performed it better than the programmer? Factor analysis is a disciplined technique for investigating, analyzing, and understanding a project before you make commitments. Similar to requirements analysis in a standard development methodology, factor analysis questions should not only focus on system requirements but also the environmental issues surrounding the project. These issues include: What is the project s scope? Are all client personnel committed to the project? What is the acceptance criteria? How will I communicate project status? Often, a good factor analysis will lead to the inclusion of a technical requirements analysis phase in the system development effort. This process consists of 10 key factors or elements of every project. Once you understand them, you and your team can explore each element s impact on the project and the appropriate project deliverables. Performing a factor analysis removes much of the mystery from planning and estimating future events. It is a structured, critical first step in confirming what you know and exposing what you don t know about a project.

15 Following are the 10 factors of every project. As you gather information about the specific factors, it s important to document expectations, constraints, and associated issues to consider during subsequent planning activities. Definition/Scope: The primary project s purpose, including major functions and deliverables, and the purpose of the project relative to the organizational whole Resources: The financial, technical, material, and human resources you need to support or perform the project Time: Elapsed time and actual work time required to complete the project Procedures: The various organizational requirements: policies and procedures, methodologies, quality program, work request initiation, financial review, and so on Environment: The project s entire cultural, political, geographical, physical, and technical context Change: New or different future conditions, requirements, events, or constraints discovered within or imposed on the project and the associated procedures for managing project change Communications: Meetings, status reports, presentations, and complexities that will affect communication Commitment: The degree of sponsor, user, and other stakeholder support Expectations: Business, productivity, operational, cultural, or any other performance changes you expect as a result of project implementation Risk: The potential jeopardies to project success and, conversely, the jeopardies associated with not doing the project or some aspect of the project. 12 Develop Your Project Agreement The project agreement is the contract or proposal that defines the work you need to do in terms of the project diamond. In addition, project agreements document the project schedule by depicting a work breakdown structure the foundation for accurate estimates, task dependencies, and eventually a critical project path. It is important to negotiate project agreements so that the client and the project manager agree on the work needed and the schedule to accomplish it. Stakeholders should understand their requirements, but they might not grasp the time frames and cost for development and implementation. The project manager must be comfortable debating all of the diamond s components. The ultimate goal should be a mutual understanding of the diamond s dimensions. This creates buy-in on both sides.

16 13 Creating Change Control Procedures A project can change at any time. For example, new requirements can be introduced. Change management is simply the process of analyzing and evaluating potential changes in the project s scope, schedule, quality, or cost for orderly integration into the project plan. The project manager s role is not just to implement customer requirements but also to assist and facilitate in the impact assessment of all change items. The project manager must work with the client to make good business decisions. The change process, which you must document in the project agreement, is the vehicle to advance this. A universal truth applies to any project: change will occur constantly, dynamically, and usually, without warning. Freezing requirements is a popular, though rarely feasible, approach to controlling the inevitable. A good project manager recognizes the inevitability of change and plans for effective change management. Effective project management anticipates change and the calculated reaction to it. Ineffective change management will blur the boundaries of when and what is to be delivered. If you don t plan for change, the ground will be well-tilled for poisonous project weeds and skewed expectations. Since my definition of quality is conformance to customer requirements, the process of evaluating and communicating the effects of change with the client is fundamental to a strong project management process. Developing Your Work Breakdown Structure Creating a work breakdown structure is integral to planning, estimating, scheduling, and managing a project. It is the process of decomposing a project into its detailed work tasks, and logically arranging these tasks to accomplish the project s objectives. This includes identifying the phases, deliverables, and activities you need to accomplish project objectives. The lowest level of a work breakdown structure provides the basis for estimating and cost-tracking. It s generally the most reliable level in which to estimate. More often than not, poor estimates reflect missing tasks, rather than poorly estimated, known tasks. Without a comprehensive work breakdown structure, you can t measure or predict project progress, costs, and accountability. Moving down the hierarchy represents an increasing amount of work detail. The lowest detail level tasks are called work packages. Work packages are the units you schedule the project work by. You use the higher- or summary-level tasks for project sizing and negotiation, cost accounting, and management and customer status reporting. You also define project milestones in the work breakdown structure. Milestones are major events or points in time that you ll measure your progress against.

17 Figure 2 depicts a work breakdown, or decomposition, diagram. It shows the typical work breakdown structure numbering convention. Figure 2: Typical Work Breakdown Diagram 14 Estimating the Tasks You must estimate the approximate time and costs you need to complete the project you described in the work breakdown structure, and in accordance with environmental constraints you identified during factor analysis. Preparing estimates of time and cost can be difficult for project managers. If you follow factor analysis and work breakdown structure principles properly, you ll develop estimates with greater confidence. Most estimate problems are caused by failing to identify all the necessary tasks, not from poor time estimation of the identified tasks. You cannot estimate time or costs for tasks that have not been identified. You can develop estimates at various levels of detail. You can develop planning approximations for budgetary purposes with higher-level work breakdown structures than contract estimates for billing. In general, estimates prepared at the lowest level of the work breakdown structure are more reliable and accurate than estimates prepared at the higher levels. Project managers often have problems because they don t compensate for a few basic estimating concepts. For example, it may take 40 hours to complete a programming task. This does not necessarily mean the task duration will last one week. If a programmer is in high demand and divided between two projects, this task could actually take two weeks. If a vacation week falls in those two weeks, it may take three weeks to complete this 40- hour task. The time you spend estimating a project may be a small percentage of the total project time. It is still important to document the estimate, because it not only lets you improve the standard (for future estimates), it also lets you teach the estimating process to someone else. Creating the Schedule Once you identify all the project tasks and establish their duration, you can assign staff resources, derive task dependencies, and then develop the subsequent schedule. Scheduling is the process of varying scope, time, resource, and risk constraints to select and document the optimum project time and staff schedule. The project schedule will be your primary tool for monitoring the project life cycle s progress. You must revise it periodically to reflect the inevitable changes I discussed earlier.

18 Scheduling, like estimating, occurs throughout the project life cycle. First, create the initial schedules to negotiate the project agreement. Then, each time the project changes, you complete the work breakdown structure and associated estimates and rework the schedule. This includes analyzing the tasks and resource requirements to determine their impact on the remaining project. Once you assemble the schedule, you should clearly understand the critical path. The project s critical path will determine the project completion date. The critical path has the least amount of float (or 0 float days) of all paths, and has the longest elapsed time of all paths. In summary, any task on the critical path that slips its completion date will make the project s end date slip as well. Thus, tracking the critical path will help you determine whether or not your project will end on time. Equally important, tasks on the critical path may not be the most project critical tasks. Critical path is a management science concept that only addresses the time dimension of the diamond. Contrary to popular belief, not all projects are time critical. The critical path may not be the place where you should spend the majority of your time. Critical path tasks, for example, might be documentation activities, while design and programming fall on paths with float. You may choose to spend the bulk of your time monitoring the design and programming activities while letting the documentation specialists inform you of any potential time delays. 15 Perform Risk Assessment Risk is an inherent component of project management. Whenever you undertake any project, you expose yourself to risk. Project risk is anything that will adversely affect project objectives. Risk is the possibility of incurring some harm and therefore is related to the potential occurrence of some events. When assessing risk, consider these three factors: The risk event itself The event s probability The effect s potential severity. Risk management is the process of identifying, analyzing, and responding to risk throughout the project s life cycle. This response should take the form of contingency plans additional tasks built into the work breakdown structure to mitigate a risk event, deflecting the risk items to another entity, and so on. For example, a project team is developing a system that calls for the implementation of new technology. The team has the resources necessary to develop the system but fears it lacks the resources to implement the new technology.

19 16 The risk scenario would look something like the following Table 1. Table 1: Risk Scenario Examples Risk Event: Risk Probability: Impact: Response: What if we don't have the resources to implement the new technology when it's needed late in the project? 75% chance the resources will not be available. 90% chance the resources, if available, will perform poorly. Project will not complete on time, quality of the final project will be compromised if the technology is not installed properly. Find a qualified subcontractor to assist or perform the new technology implementation. As you can see, the response in Table 1 will have a major impact on your project agreement. This adds greater complexity to the project and affects the cost by adding tasks to the work breakdown structure. In addition, it will affect the quality of the system you install. At a minimum, you should use this type of analysis for all risk events with a high probability of occurrence and a high degree of impact. Manage the Diamond by Managing Expectation Effective project planning is not conducted in a vacuum. It must be carried out in coordination and cooperation with all appropriate stakeholders. You must manage their expectations throughout the process. The project manager must constantly look for opportunities to create win-win relationships by negotiating the work that must be accomplished. A project manager who declares that this can t be done in the time frame allotted will meet with stiff resistance from client management. On the other hand, a project manager who can defend this statement with a solid understanding of the project s scope, backed by a logical work breakdown structure; thoughtful estimate; thoughtful estimate and project schedule; and concise risk analysis will be met with a response like, Maybe you re right. Help me understand what you understand. This is effective expectation management and proper development of winwin relationships. Once your project plan is in place, it s easy to simply manage your project diamond.

20 Fatores Críticos de Sucesso em GP Paulo Ferrúcio, MSc, PMP Gerente de Projetos Sênior Lucent Technologies A necessidade das organizações de maior eficiência e velocidade para atender as necessidades do mercado faz com que os projetos tenham que ser implantados dentro dos prazos requeridos, de acordo com o orçamento aprovado e conforme os requisitos definidos pelo cliente. Para que tudo isso dê certo, é necessário seguir uma metodologia de planejamento, execução e controle que seja consagrada pela comunidade. A metodologia que vamos descrever é aquela definida pelo PMI e que vem sendo adotada por várias empresas, com pequenas adaptações. Mesmo outras metodologias, como a PRINCE (Projects IN Controlled Environments) desenvolvida pelo Departamento de Comércio do Governo Britânico, tem forte inspiração na metodologia do PMI. A metodologia desenvolvida pelo PMI e que pode ser estudada no manual PMBOK (Project Management Body of Knowledge) abrange as seguintes áreas: Gerência da Integração - Desenvolvimento do Plano do Projeto - Execução do Plano do Projeto - Controle de Mudanças Gerência do Escopo - Início - Planejamento do Escopo - Definição do Escopo - Verificação do Escopo - Controle de Mudança do Escopo Gerência do Tempo - Definição das Atividades - Seqüência das atividades - Estimativa da Duração das Atividades - Desenvolvimento do Cronograma - Controle do Cronograma Gerência de Custos - Planejamento de Recursos - Estimativa de Custos - Orçamento de Custos - Controle de Custos