ambiente para gerenciar multiplos projetos de ti

Um modelo para o gerenciamento de mltiplos

projetos de software aderente ao CMMI TRABALHO DE GRADUAO

Universidade Federal de Pernambuco Graduao em Cincia da Computao

Centro de Informtica

Aluno: Bruno Celso Cunha de Freitas ([email protected]) Orientador: Hermano Perrelli de Moura ([email protected])

janeiro de 2005

Um Modelo para o Gerenciamento de Mltiplos Projetos de Software Aderente ao CMMI 6/3/2005

Trabalho de Graduao

2

ASSINATURAS

Este Trabalho de Graduao resultado dos esforos do aluno Bruno Celso Cunha de Freitas, sob

a orientao do professor Hermano Perrelli de Moura, na participao do projeto Um modelo para

o gerenciamento de mltiplos projetos de software aderente ao CMMI, conduzido pelo Centro de

Informtica da Universidade Federal de Pernambuco. Todos abaixo esto de acordo com o

contedo deste documento e os resultados deste Trabalho de Graduao.

Bruno Celso Cunha de Freitas

Hermano Perrelli de Moura


Trabalho de Graduao

3

RESUMO

A importncia da utilizao de mtodos, tcnicas e ferramentas na gerncia de projetos

cada dia mais reconhecida em todas as reas da atividade humana. A relevncia da atividade de

gerenciamento de projetos reconhecida por organizaes, comunidade e pessoas; tanto no setor

pblico quanto no setor privado. Na rea de software e tecnologia da informao (TI), o assunto

assume a cada dia uma importncia maior. Isto se deve, em parte, pelo entendimento de que parte

significativa do insucesso em projetos de software est relacionada com uma m gerncia de

projetos ou, algumas vezes, por uma ausncia completa de gerenciamento.

Muito tem sido feito e estudado em busca de uma rea e disciplina de gerncia de projetos

consolidada e bem entendida. Uma iniciativa importante na rea o Project Management Body of

Knowledge (PMBOK) do Project Management Institute PMI. Na rea de software e TI, vrias

metodologias e processos de software trazem mtodos, tcnicas, ferramentas e atividades

relacionadas com gerncia de projetos. Uma dessas metodologias o Capability Maturity Model

Integration (CMMI), modelo de maturidade no desenvolvimento de software elaborado pelo

Software Engineering Institute (SEI), que possui nfase na rea de processo de Planejamento e

Acompanhamento de Projetos, entre outras. O CMMI est em franca ascenso principalmente

entre as empresas de software que tem investido bastante na melhoria dos seus processos

visando aumentar sua participao em projetos de grande porte e na exportao de produtos

atravs da obteno deste certificado.

Apesar de verificarmos uma evoluo visvel de casos de sucesso de projetos de TI,

ocasionada pela especializao dos profissionais desse ramo e pela adoo de modelos como o

CMMI, a quantidade de projetos que extrapolam o planejamento inicial ou so cancelados ainda

expressiva. Isso se deve principalmente por TI ser uma rea muito mais dinmica e mais abstrata

do que a maioria das demais reas de conhecimento que trabalham basicamente atravs da

adoo de projetos. Alm dos problemas inerentes a um nico projeto, a indstria de TI

predominantemente um ambiente multiprojetos. Isso acarreta problemas ainda maiores, prprios

deste tipo de ambiente, e que no podem ser desprezados pelos gerentes de projetos.

Dentro deste contexto, o presente projeto foca na definio de um modelo que possibilite a

gerncia de vrios projetos de software gerenciamento de multiprojetos, atravs da definio de

uma arquitetura, entidades e informaes relacionadas com as atividades necessrias para o

gerenciamento de vrios projetos em execuo concorrente e aderente ao modelo CMMI.


Trabalho de Graduao

4

ABSTRACT

The importance of the use of methods, techniques and tools in the project management is

each more recognized in all the areas of the human activity. The relevance of the activity of project

management is recognized for organizations, community and people; as much in the public sector

as in the private sector. In the area of software and information technology (IT), the subject

assumes a bigger importance day by day. This is caused, in part, by the agreement of that a

significant part of failure in software projects is related with a bad project management or, some

times, by a complete absence of management.

Much has been made and studied in search of an area and disciplines of project

management consolidated and well understood. An important initiative in the area is the Project

Management Body of Knowledge (PMBOK) of the Project Management Institute - PMI. In the area

of software and IT, some methodologies and processes of software bring methods, techniques,

tools and activities related with project management. One of these methodologies is the Capbility

Maturity Modelo Integration (CMMI), a software development maturity model developed by Software

Engineering Institute (SEI), which enphasizes the project planning and monitoring, among others.

CMMI is in free ascension mainly between software companies that have invested sufficiently in the

improvement of its processes aiming at to increase its participation in big projects and in the

exportation of products through the attainment of this certificate.

Although to verify a visible evolution of cases of success of IT projects, caused for the specialization of the professionals of this branch and for the adoption of models as the CMMI, the

amount of projects that surpass the initial planning or are cancelled still is expressive. This is

caused mainly because IT is a much more dynamic and more abstract area than the majority of the

other areas of knowledge that work basically through the adoption of projects. Beyond the inherent

problems to a single project, the IT industry is predominantly a multiproject environment. This

causes bigger problems inherent of this type of environment and that they cannot be unconsidered

by the project manager.

Inside of this context, the focus of the present project is in the definition of a model that

makes possible the management of many projects of software - multiproject management, through

the definition of an architecture, entities and information related with the necessary activities for the

management of many projects in simultaneous execution and adherent to CMMI model.


Trabalho de Graduao

5

AGRADECIMENTOS

Acima de tudo agradeo a Deus, que sempre esteve presente na minha vida sendo,

conjuntamente com meus pais, Orman e Lcia, e minha namorada, Ismnia, fonte de inspirao e

fortaleza.

Agradeo ao professor Hermano Perrelli que como um orientador, sempre incentivou meu

trabalho e mostrou-me os melhores caminhos a serem seguidos mesmo diante das suas inmeras

ocupaes. Estendo este agradecimento tambm a todos os professores do Centro de Informtica

que contriburam com o meu aprendizado ao longo desses quatro anos de curso. Muitos destes

no sero apenas lembrados como professores, mas tambm como exemplos de profissionais

dedicados, competentes e amigos, em particular os professores Edna Barros, Manoel Eusbio e

Fernando Fonseca.

Agradeo tambm aos amigos que fiz neste curso que me proporcionaram vrios

momentos de descontrao, que vivenciaram junto comigo os momentos de tenso e alvio que

tivemos durante nossa estadia no Centro de Informtica e que no cito seus nomes aqui para no

ser injusto se por acaso esquecer algum deles.

Por fim, agradeo Inteligncia Informtica, na pessoa de Joaquim Costa e Arlindo Viana,

pela oportunidade de me ajudar a desenvolver e aplicar este trabalho em seus projetos, pela

presteza das informaes que me foram passadas e pela disponibilidade que sempre me foi

oferecida. Sem a ajuda e a pacincia destas pessoas, este trabalho no teria a qualidade na qual

est apresentado em suas prximas pginas.

A todos vocs, o meu muito obrigado!


Trabalho de Graduao

6

SUMRIO

1. INTRODUO..................................................................................... 11

1.1. A DEFINIO DE PROJETO ............................................................................................. 13 1.2. O CICLO DE VIDA DO PROJETO........................................................................................... 15 1.3. PROBLEMAS COMUNS ATIVIDADE DE GERENCIAMENTO DE PROJETOS DE SOFTWARE ..... 16

2. AMBIENTES MULTIPROJETOS......................................................... 19

2.1. PORTFLIO DE PROJETOS X GERNCIA DE MULTIPROJETOS.............................................. 19 2.2. TIPOLOGIAS DE AMBIENTES MULTIPROJETOS ................................................................... 21 2.3. AMBIENTES MULTIPROJETOS DE SOFTWARE..................................................................... 23

3. MODELOS DE QUALIDADE EM GESTO DE PROJETOS .............. 24

3.1. PROJECT MANAGEMENT BODY OF KNOWLEDGE (PMBOK) ............................................. 24

3.2. CAPABILITY MATURITY MODEL INTEGRATION (CMMI) .................................................. 30

3.3. RATIONAL UNIFIED PROCESS (RUP)................................................................................. 43

3.4. OUTROS MODELOS DE QUALIDADE .................................................................................. 46

4. TCNICAS PARA ALOCAO DE RECURSOS E CONTROLE DE ORAMENTOS DE PROJETOS........................................................ 48

4.1. CORRENTE CRTICA .......................................................................................................... 48

4.1.1 O Mtodo da Corrente Crtica ................................................................................... 50 4.2. ANLISE DE VALOR AGREGADO ....................................................................................... 54

4.2.1. Anlise de Valor Agregado em Ambientes Multiprojetos........................................... 58

5. UM MODELO PARA O GERENCIAMENTO DE MLTIPLOS PROJETOS DE SOFTWARE ............................................................. 59

5.1. PLANEJAMENTO DE PROJETOS........................................................................................... 59

5.1.1 Objetivos .................................................................................................................... 59 5.1.2 Papis e Responsabilidades ....................................................................................... 59 5.1.3 Medies .................................................................................................................... 60 5.1.4 Verificao ................................................................................................................. 60 5.1.5 Treinamento ............................................................................................................... 60 5.1.6 Ferramentas ............................................................................................................... 61 5.1.7 Descrio do Processo............................................................................................... 61

5.2. MONITORAMENTO E CONTROLE DE PROJETOS.................................................................. 74


Trabalho de Graduao

7

5.2.1 Objetivos .................................................................................................................... 74 5.2.2 Papis e Responsabilidades ....................................................................................... 74 5.2.3 Medies .................................................................................................................... 75 5.2.4 Verificao ................................................................................................................. 76 5.2.5 Treinamento ............................................................................................................... 76 5.2.6 Ferramentas ............................................................................................................... 76 5.2.7 Descrio do Processo............................................................................................... 77

6. CONCLUSO...................................................................................... 89

7. REFERNCIAS BIBLIOGRFICAS.................................................... 91


Trabalho de Graduao

8

NDICE DE FIGURAS Figura 1. Tempo de vida de um sistema no mercado desde o momento de sua concepo. ......... 11

Figura 2. Desempenho, custo, prazo e metas do projeto. ................................................................ 13

Figura 3. Crescimento do nmero de associados ao PMI. ............................................................... 14

Figura 4. Os stakeholders de um projeto. ......................................................................................... 15

Figura 5. O ciclo de vida do projeto. ................................................................................................. 16

Figura 7. Estrutura Organizacional.................................................................................................... 20

Figura 8. Ambiente Multiprojetos Convergentes ............................................................................... 21

Figura 9. Ambiente Multiprojetos Divergentes .................................................................................. 22

Figura 10. Ambiente Multiprojetos Paralelo ...................................................................................... 22

Figura 11. Grupos de Processos do PMBOK 2000 .......................................................................... 24

Figura 12. Sobreposio dos grupos de processos do PMBOK 2000.............................................. 25

Figura 13. reas de Conhecimento do PMBOK 2000 ...................................................................... 26

Figura 14. Processos de Planejamento do PMBOK 2000 ................................................................ 27

Figura 15. Processos de Planejamento do PMBOK 2000. ............................................................... 29

Figura 16. Processos de Controle do PMBOK 2000......................................................................... 30

Figura 17. Processos de Encerramento do PMBOK 2000. .............................................................. 30

Figura 18. Representaes do CMMI ............................................................................................... 31

Figura 19. Nveis de maturidade da representao por estgios do CMMI. .................................... 33

Figura 20. Estrutura do Modelo do CMMI na representao por estgios. ...................................... 34

Figura 21. Relacionamentos entre as metas especficas, os principais resultados, os

stakeholders e a rea de processo de Acompanhamento e Controle de Projetos. ................. 37

Figura 22. Relacionamentos entre as prticas especficas da meta Estabelecer Estimativas......... 37

Figura 23. Relacionamentos entre as prticas especficas da meta Desenvolver o Plano do

Projeto....................................................................................................................................... 38

Figura 24. Relacionamentos entre as prticas especficas da meta Obter Comprometimento ao

Plano......................................................................................................................................... 40

Figura 25. Relacionamentos entre as prticas especficas da meta Monitorar o Projeto de

Acordo com o Plano. ................................................................................................................ 41

Figura 26. Relacionamentos entre as prticas especficas da meta Gerenciar Aes Corretivas

at o Fechamento..................................................................................................................... 43

Figura 27. Grfico das Baleias do RUP. ........................................................................................... 44

Figura 28. Fluxograma para o Gerenciamento de Projetos, segundo o RUP. ................................. 45

Figura 29. Exemplo de multitarefa em um ambiente multiprojetos................................................... 49

Figura 30. Exemplo execuo de projetos aps priorizao em um ambiente multiprojetos........... 49


Trabalho de Graduao

9

Figura 31. Status da utilizao dos recursos dentre vrios projetos de uma organizao

multiprojetos. ............................................................................................................................ 51

Figura 32. Status da utilizao dos recursos dentre vrios projetos de uma organizao

multiprojetos aps a insero dos buffers na Corrente Crtica. ............................................... 52

Figura 33. Regies de gerenciamento dos buffers da Corrente Crtica............................................ 53

Figura 34. Multiprojetos disputando o recurso Desenvolvedor......................................................... 54

Figura 35. Multiprojetos sincronizados em torno do recurso Desenvolvedor. .................................. 54

Figura 36. Exemplo grfico do BCWS, BCWP e ACWP ao longo do tempo para um

determinado projeto.................................................................................................................. 55

Figura 37. Exemplo grfico do BCWS, BCWP e ACWP ao longo do tempo para um

determinado projeto.................................................................................................................. 56

Figura 38. Exemplo grfico contendo todos os ndices de EAV. ...................................................... 57

Figura 39. Sub-processos do processo de Planejamento do Projeto............................................... 61

Figura 40. Fluxo de Atividades do Sub-processo Iniciar Projeto.................................................... 62

Figura 41. Fluxo de Atividades do Sub-processo Elaborar Estimativas......................................... 63

Figura 42. Fluxo de Atividades do Sub-processo Identificar Riscos. ............................................. 64

Figura 43. Fluxo de Atividades do Sub-processo Planejar Capacitao. ...................................... 65

Figura 44. Fluxo de Atividades do Sub-processo Elaborar Cronograma e Oramento. ................ 67

Figura 45. Fluxo de Atividades do Sub-processo Planejar Envolvimento dos Stakeholders

Relevantes............................................................................................................................... 72

Figura 46. Fluxo de Atividades do Sub-processo Consolidar Planos............................................. 73

Figura 47. Fluxo de Atividades do Sub-processo Obter Comprometimento dos Envolvidos......... 74

Figura 48. Sub-Processos de Gerenciamento e Controle de Projetos. ............................................ 77

Figura 49. Fluxo de Atividades do Sub-processo Acompanhar Progresso do Projeto. ................. 78

Figura 50. Fluxo de Atividades do Sub-processo Realizar Revises do Projeto. .......................... 87

Figura 51. Fluxo de Atividades do Sub-processo Gerencia Aes Corretivas............................... 88


Trabalho de Graduao

10

NDICE DE TABELAS Tabela 1. Fatores de Sucesso de Projetos. ...................................................................................... 16

Tabela 2. Fatores de Risco em Projetos........................................................................................... 17

Tabela 3. Fatores de Fracasso em Projetos. .................................................................................... 17

Tabela 4. Taxas de Evoluo no Gerenciamento de Projetos de TI. ............................................... 17

Tabela 5. Comparao de alto nvel entre gerenciamento de portflio de projetos e gerncia de

mltiplos projetos...................................................................................................................... 20

Tabela 6. Grupos de processos do PMBOK e suas principais atividades........................................ 24

Tabela 7. Descrio das reas de conhecimento do PMBOK.......................................................... 26

Tabela 8. Vantagens de cada uma das representaes do CMMI................................................... 31

Tabela 9. reas de processo por nveis de maturidade da representao por estgios do

CMMI. ....................................................................................................................................... 33

Tabela 10. Metas e prticas especficas da rea de processo de Planejamento de Projetos. ........ 36

Tabela 11. Prticas especficas da meta Estabelecer Estimativas................................................... 38

Tabela 12. Prticas especficas da meta Desenvolver o Plano do Projeto. ..................................... 39

Tabela 13. Prticas especficas da meta Obter Comprometimento ao Plano. ................................. 40

Tabela 14. Metas e prticas especficas da rea de processo de Acompanhamento e Controle

de Projetos................................................................................................................................ 41

Tabela 15. Prticas especficas da meta Monitorar o Projeto de Acordo com o Plano.................... 42

Tabela 16. Prticas especficas da meta Gerenciar Aes Corretivas at o Fechamento. ............. 43

Tabela 17. Oramento Projetado. ..................................................................................................... 55

Tabela 18. Papis e Responsabilidades Envolvidos no Planejamento do Projeto........................... 59

Tabela 19. Obrigatoriedade de treinamento para os papis inerentes ao planejamento do

projeto....................................................................................................................................... 60

Tabela 20. Ferramentas de Suporte ao Planejamento de Projeto.................................................... 61

Tabela 21. Papis e Responsabilidades envolvidos no gerenciamento e controle de projetos....... 75

Tabela 22. Treinamentos requeridos para cada um dos papis....................................................... 76

Tabela 23. Ferramentas de Suporte ao Gerenciamento e Controle de Projetos. ............................ 76


Trabalho de Graduao

11

1. INTRODUO

No ambiente de negcios, o tempo de lanamento de um produto ou servio a partir do

momento da concepo da sua idia um dos fatores fundamentais para a aceitao e, conseqentemente, o sucesso desse produto. Na rea de administrao, esse intervalo de tempo no qual o produto concebido, modelado, desenvolvido e lanado chamado de time-to-market [Boswell 1998].

A partir do momento em que o produto est no mercado, haver uma ascenso do seu

consumo baseado na necessidade do mercado consumidor atingindo um pice de consumo que trar uma lucratividade tima para o seu fabricante. A partir do momento em que produtos concorrentes so lanados e a tecnologia na qual o produto est baseado vai ficando defasada, h uma queda no consumo desse produto at um ponto no qual o mercado no o consumir mais.

Desta maneira, fica claro que o atraso no lanamento de um produto no mercado implica

que outros produtos similares surjam antes. Neste caso, a aceitao do mercado acontece de maneira mais lenta e a lucratividade obtida menor por conta da concorrncia. Entretanto, a queda de consumo desse produto ir ocorrer em uma proporo similar quela que aconteceria se o mesmo tivesse sido pioneiro devido aos mesmos fatores citados anteriormente.

A Figura 1 resume o tempo de vida de um produto a partir do momento da sua concepo

[DeBardelaben 1998]:

Figura 1. Tempo de vida de um sistema no mercado desde o momento de sua concepo. Considerando a concorrncia acirrada gerada pela globalizao, a crescente exigncia do

mercado pela qualidade dos produtos e a complexidade das necessidades do mercado consumidor, o time-to-market cada vez menor e a complexidade no desenvolvimento de solues que atendam s demandas do mercado cada vez maior. Desta maneira, h uma necessidade natural de que o processo de lanamento de um produto a partir da sua concepo seja cada vez mais organizado, cada vez mais sistematizado, para que o objetivo final possa ser alcanado dentro das restries de custo, prazo e qualidade existentes.


Trabalho de Graduao

12

Esse tipo de organizao se d atravs da adoo de projetos [Meredith 2003] de desenvolvimento dos produtos. O projeto distribudo na forma de atividades inter-relacionadas e coordenado por uma gerncia de projetos capaz de conduzi-lo visando sempre atingir o objetivo final. O gerenciamento de projetos dota as organizaes de poderosas ferramentas que aperfeioam suas habilidades em planejar, implementar e controlar suas atividades bem como a maneira como elas utilizam seu pessoal e os recursos. Quase todas as empresas do comrcio de software para computadores desenvolvem rotineiramente seu produto em forma de projeto ou grupos de projetos.

O gerenciamento de projetos se tornou emergente por causa das caractersticas da nossa

sociedade de virada do sculo procura do desenvolvimento de novos mtodos de gesto. Das muitas foras envolvidas, trs so soberanas:

1. a expanso exponencial do conhecimento humano; 2. a demanda crescente por uma faixa ampla de bens e servios complexos, sofisticados e

sob medida; 3. a evoluo dos mercados globais competitivos para a produo e consumo de bens e

servios. Todas essas foras se unem para determinar o uso de equipes para resolver os problemas

que normalmente so resolvidos individualmente, aumentando grandemente a complexidade dos bens e servios produzidos alm da complexidade dos processos utilizados para produzi-los. Isso leva necessidade de sistemas mais sofisticados para controlar o resultado e o processo. A expanso do conhecimento permite o uso de um crescente nmero de disciplinas acadmicas para solucionar problemas associados com o desenvolvimento, a produo e a distribuio de bens e servios. A satisfao da continuada demanda por produtos e servios mais complexos e personalizados depende da habilidade em tornar o projeto do produto uma parte integrada e inerente do sistema de fabricao e distribuio. Por fim, os mercados mundiais nos foram a incluir as diferenas culturais e ambientais nas nossas decises administrativas a respeito do qu, onde, quando e como produzir e distribuir o produto. O requerido conhecimento no reside no fator individual, mas em equipes utilizadas para tomar decises e agir. Isso clama por um alto nvel de coordenao e cooperao entre os grupos de pessoas no utilizadas particularmente nesta interao. Outra importante fora societria a intensa competio entre instituies, com ou sem fins lucrativos, incentivada pelo nosso sistema econmico. Isso exerce uma extrema presso nas organizaes para tornar seus produtos complexos e personalizados disponveis o mais rpido possvel.

Em geral, os projetos possuem os mesmos objetivos gerais: atingir metas de desempenho,

prazo e custo. Existe uma tendncia a pensar em um projeto somente em termos do seu resultado, ou seja, no seu desempenho. O prazo no qual o resultado estar disponvel por si s parte do resultado, como tambm o seu custo vinculado obteno do resultado. A concluso do produto pontualmente e dentro do oramento um resultado bem diferente da concluso do mesmo produto um ano depois ou com 20 por cento a mais no oramento, ou ambos. A Figura 2 ilustra os principais objetivos de um projeto.


Trabalho de Graduao

13

Figura 2. Desempenho, custo, prazo e metas do projeto. De fato, mesmo o conceito de desempenho pode ser mais complexo do que aparenta.

Muito tem sido escrito nos ltimos anos provando que, alm do prazo, custo e especificaes, h uma quarta dimenso a ser considerada: a expectativa do cliente. Essa expectativa tende a aumentar medida que o projeto progride, conhecido como alargamento do escopo. Separar os desejos do cliente das especificaes do projeto cria conflitos porque raramente cliente e equipe agem de comum acordo. O cliente especifica o resultado desejado e a equipe do projeto esboa e implementa o projeto. O cliente v o resultado das idias da equipe do projeto e, dada a essncia da criatividade do ser humano, existe a pequena chance das especificaes permanecerem inalteradas durante o processo. O gerente do projeto jamais vence quando tal conflito aparece. Essa volatilidade dos requisitos do projeto uma das principais causas de fracasso como veremos na Seo 1.3.

1.1. A definio de Projeto

Ainda segundo Meredith, a complexidade dos problemas encarados pelo gerente de

projeto (GP), somados ao rpido crescimento do nmero de organizaes orientadas por projetos, contribuiu para a profissionalizao da administrao de projetos. O Project Management Institute (PMI), fundado em 1969, uma associao sem fins lucrativos, cujo principal objetivo difundir a gesto de projetos no mundo, de forma a promover tica e profissionalismo no exerccio desta atividade. De acordo com o site oficial do PMI em So Paulo (PMI-SP1), empresas como a Nasa, IBM, AT&T, Siemens, Chiyoda Corporation, PricewaterhouseCoopers, Sociedade Computacional de Singapura e o Governo Estadual de Oregon (EUA) lanam mo de tcnicas e metodologias de Gerenciamento de Projetos para obter os resultados esperados em seus projetos. Na rea de software e tecnologia da informao (TI) este assunto assume a cada dia uma importncia maior. Isto se deve, em parte, pelo entendimento de que parte significativa do insucesso em projetos de

1 http://www.pmisp.org.br/home.asp

Desempenho requerido

Data limite

Desempenho

Prazo (previsto)

Limite do Oramento

Custo

Meta

Desempenho requerido

Data limite

Desempenho

Prazo (previsto)

Limite do Oramento

Custo

Meta


Trabalho de Graduao

14

software est relacionada com uma m gerncia de projetos ou, algumas vezes, por uma ausncia completa de gerenciamento. No caso do setor pblico, a necessidade de boa gerncia de projetos ainda mais acentuada, uma vez que os recursos so escassos e devem ser utilizados de forma a criar sistemas de informao capazes de responder s questes de gerenciamento de forma eficaz, no que se refere iniciao, planejamento, execuo, controle e finalizao de projetos. A importncia da gerncia de projetos nos vrios setores da sociedade pode ser vista pela evoluo do nmero de associados ao PMI, conforme apresentado na Figura 3.

Figura 3. Crescimento do nmero de associados ao PMI.

Nitidamente, o rpido crescimento no nmero de gerentes de projeto e o PMI foi o

resultado, e no a causa, do tremendo crescimento do nmero de projetos sendo executados. A indstria de software sozinha foi responsvel por um significativo percentual do crescimento.

O PMI definiu o projeto da seguinte forma:

Nas discusses de gerenciamento de projetos, algumas vezes til distinguir termos como

projeto, programa, tarefas e pacotes de trabalho. Os militares, fonte da maioria desses termos, geralmente utilizam o termo programa para se referirem a um objetivo excepcionalmente grande, de longo alcance, que fragmentado para um conjunto de projetos. Esses projetos so divididos em tarefas, que so, por sua vez, divididas em pacotes de trabalho, os quais so compostos por unidades de trabalho. Mas so abundantes as excees a essas nomenclaturas hierrquicas.

No sentido mais amplo, um projeto uma tarefa especfica, limitada, a ser realizada. Se

em grande ou em pequena escala ou de curso longo ou curto no particularmente relevante. O que relevante que o projeto seja visto como uma unidade. Existem, contudo, alguns atributos que caracterizam os projetos:

a) Propsito

Um projeto normalmente uma atividade peridica com um conjunto bem definido de almejados resultados finais. Ele pode ser dividido em subtarefas que precisam ser realizadas a fim de atingir as metas do projeto. O projeto suficientemente complexo, j que as subtarefas requerem cuidadosa coordenao em termos de cronometragem, precedncia, custo e desempenho. Muitas vezes o projeto em si precisa ser coordenado com outros projetos que estejam sendo executados por uma mesma organizao afiliada.

19911993 1995

1997 19992002

5.00010.00015.00020.00025.00030.00035.00040.00045.00050.00055.00060.00065.00070.00075.000

Um esforo temporrio incumbido de criar um nico produto ou servio.


Trabalho de Graduao

15

b) Ciclo de Vida Identicamente s entidades orgnicas, os projetos possuem ciclos de vida. Desde o lento

comeo do seu progresso at o desenvolvimento do tamanho, o auge, o incio do declnio e, finalmente, at a concluso.

c) Interdependncias

Os projetos freqentemente interagem com outros projetos que esto sendo executados simultaneamente pelas suas organizaes ligadas; mas os projetos sempre interagem com as operaes rotineiras em execuo nas organizaes ligadas. Embora os departamentos funcionais de uma organizao interajam entre si de forma regular e padronizada, os padres de interao entre os projetos e esses departamentos tendem a ser variveis. O setor de marketing pode ser envolvido no incio e no fim do projeto, mas no no meio. A fabricao pode ter um maior envolvimento no transcurso. O setor financeiro freqentemente envolvido no incio e a contabilidade no fim, bem como nos relatrios peridicos. O gerente de projeto precisa tornar claras todas essas interaes e manter o inter-relacionamento apropriado com todos os grupos externos.

d) Singularidade

Cada projeto possui alguns elementos que so nicos. Alm da presena de risco, essa caracterstica significa que o projeto, por sua natureza, no pode ser completamente reduzido rotina. Dois projetos bastante semelhantes sempre tero fatores distintos.

e) Conflitos

Os projetos competem com os departamentos funcionais quanto a recursos e pessoal. Mais srio, com a crescente proliferao de projetos, o conflito projeto x projeto por recursos dentro de organizaes multiprojetos. Os membros da equipe do projeto esto em conflito quase constante pelos recursos do projeto e pelo papel de liderana na soluo dos problemas do projeto. As quatro partes de interesses ou os stakeholders em qualquer projeto constantemente definem o sucesso e as falhas de formas diferentes. Os stakeholders de um projeto so apresentados na Figura 4.

Figura 4. Os stakeholders de um projeto.

O cliente quer vantagens e as organizaes ligadas querem lucros, os quais podem ser reduzidos se mudanas so feitas. Indivduos que trabalham nos projetos so freqentemente subordinados a duas chefias ao mesmo tempo e essas chefias possuem diferentes prioridades e objetivos. O pblico, por sua vez, espera que o projeto resulte em produtos e servios que atendam s suas necessidades dentro do menor tempo e com o custo mais acessvel possvel.

1.2. O ciclo de vida do projeto

A maioria dos projetos passa atravs de estgios similares no caminho entre a origem e a

concluso. Esses estgios so chamados de ciclo de vida do projeto e so mostrados na Figura 5.

Clientes

OrganizaesFiliadas

Equipedo

ProjetoPblico

Clientes

OrganizaesFiliadas

Equipedo

ProjetoPblico


Trabalho de Graduao

16

Figura 5. O ciclo de vida do projeto.

O projeto nasce (sua fase de incio) e o gerente escolhido, a equipe de projeto e os recursos iniciais so alocados e o programa de trabalho organizado. Em seguida, o trabalho passa por um momento de rpida construo da sua forma. O progresso feito e isso continua at que o fim seja visvel. A concluso da meta final parece tomar uma quantidade irregular de tempo, parcialmente porque freqentemente existe um nmero de partes que devem vir juntas e parcialmente porque os membros de projetos tendem a diminuir seu ritmo de trabalho por vrias razes e evitam as etapas finais.

1.3. Problemas comuns atividade de gerenciamento de projetos de

software O time-to-market crtico. As respostas devem vir mais depressa, as decises precisam

ser tomadas mais cedo e os resultados devem ser mais velozes. A informao e o conhecimento crescem explosivamente, mas o prazo permissvel para localizar e utilizar o conhecimento adequado est diminuindo. Ainda que o conhecimento tcnico para o desenvolvimento do produto seja muito importante, h diversas outras variveis que comprometem o andamento do projeto e que sero responsveis pelo sucesso ou fracasso do mesmo. As Tabelas 1, 2 e 3 so resultados de uma pesquisa realizada pelo Standish Group chamada de The Chaos Report [Standish Group 1994 ]. Nesta pesquisa foram ouvidas as opinies de diversos gerentes executivos de TI.

Tabela 1. Fatores de Sucesso de Projetos.

Fatores de Sucesso dos Projetos

Percentual de

Respostas 1. Envolvimento do usurio 15.9%2. Suporte da alta administrao 13.9%3. Clara definio dos requisitos 13.0%4. Planejamento apropriado 9.6%5. Expectativas realsticas 8.2%6. Pontos de verificao do projeto menores 7.7%7. Competncia da equipe 7.2%8. Propriedade 5.3%


Trabalho de Graduao

17

9. Clara Viso e Objetivos 2.9%10. Trabalho intenso 2.4%11. Outros 13.9%

Tabela 2. Fatores de Risco em Projetos.

Fatores de Risco em Projetos

Percentual de

Respostas 1. Falta de participao dos usurios 12.8%2. Requisitos e especificaes incompletos 12.3%3. Volatilidade de requisitos e especificaes 11.8%4. Ausncia de suporte da alta administrao 7.5%5. Limitao da tecnologia 7.0%6. Falta de recursos 6.4%7. Expectativas irreais 5.9%8. Objetivos no claramente definidos 5.3%9. Cronograma irreal 4.3%10. Nova tecnologia 3.7%11. Outros 23.0%

Tabela 3. Fatores de Fracasso em Projetos.

Fatores de Fracasso em Projetos

Percentual de

Respostas 1. Requisitos e especificaes incompletos 13.1%2. Falta de participao dos usurios 12.4%3. Falta de recursos 10.6%4. Expectativas irreais 9.9%5. Ausncia de suporte da alta administrao 9.3%6. Volatilidade de requisitos e especificaes 8.7%7. Falta de planejamento 8.1%8. Obsolescncia do projeto 7.5%9. Ausncia de gerenciamento de TI 6.2%10. Problemas com a tecnologia empregada 4.3%11. Outros 9.9%

Dessa maneira, o ambiente de desenvolvimento de produtos baseado na adoo de

projetos bem mais desafiador para a sua gerncia do que considerando apenas a complexidade tcnica da necessidade do mercado. Um estudo chamado Extreme CHAOS 2001 [Johnson 2001], publicado pelo Standish Group em 2001 mostra uma evoluo dos projetos finalizados com sucesso em relao aos dados do The Chaos Report mencionados anteriormente. A Tabela 4 sumariza os dados desse estudo.

Tabela 4. Taxas de Evoluo no Gerenciamento de Projetos de TI.

1994 1996 1998 2000Projetos concludos e operacionais, com oramento e prazo respeitados e com todas as funcionalidades implementa-das.

16% 27% 26% 28%

Projetos concludos e operacionais, porm com oramento e prazo estourados e

31% 40% 28% 49%


Trabalho de Graduao

18

com menos funcionalidades do que especificado inicialmente. Projetos cancelados em algum ponto do ciclo de desenvolvi-mento.

53% 33% 46% 23%

Os dados mostrados nesta Seo demonstram uma evoluo da gerncia de projetos de

TI. Entretanto, ainda percebemos que cerca de 72% dos projetos no terminam conforme planejado ou so cancelados, segundo os dados do ano 2000 apresentados na Tabela 4. Isso demonstra que a indstria de software ainda tem muito a evoluir nesse aspecto. A necessidade de um modelo de gerenciamento de projetos de software que diminua cada vez mais esse percentual ntida.

O captulo 2 deste trabalho examina o ambiente multiprojetos, uma caracterizao

moderna do ambiente organizacional voltado ao desenvolvimento de projetos e amplamente difundido nas empresas de software. Os modelos de qualidade em gerncia de projetos desenvolvidos ao longo dos anos por especialistas de diversas reas de conhecimento e que visam tornar o ambiente de projetos mais produtivos so discutidos no captulo 3. No captulo 4, abordaremos algumas tcnicas para o gerenciamento de projetos cuja utilizao bastante recomendada em ambientes multiprojetos. O captulo 5 descreve uma instanciao dos modelos propostos no captulo anterior para a realidade das empresas de software. Por fim, o captulo 6 aborda as consideraes finais acerca do que foi tratado ao longo de todo o trabalho.


Trabalho de Graduao

19

2. AMBIENTES MULTIPROJETOS Dentro do cenrio que retratamos na Seo anterior, ainda h uma nova tendncia a se

considerar. Uma organizao dificilmente consegue sobreviver atravs de um nico projeto, ela precisa conduzir diversos projetos, simultaneamente, a fim de levantar fundos que cubram seus custos, principalmente quando os projetos no caminham conforme planejado.

A grande maioria das organizaes, principalmente as fbricas de software, no tem

condies de manter uma equipe dedicada a cada um dos seus projetos, os seus funcionrios vo sendo deslocados entre os projetos de acordo com a necessidade de cada um deles. Outra caracterstica importante e bastante comum nestas organizaes que o oramento mensal de cada projeto fique totalmente comprometido ou estoure devido a imprevistos. Neste caso, a soluo realocar recursos financeiros de outros projetos que no estejam to comprometidos. Este ambiente dinmico no qual a alocao de recursos pea-chave conhecido como ambiente multiprojetos [Danilovic 2001][Rautiainen 2000]. Pouco mais do que 90% de todos os projetos so conduzidos neste tipo de ambiente [Danilovic 2001].

Segundo Barcaui [Barcaui 2004], em um ambiente multiprojetos, o portflio de projetos

[Dye 2000] da organizao depende diretamente do seu conjunto de recursos, sejam estes internos ou externos. O problema que este nmero finito. Nestes casos, a competncia e a capacidade destes recursos podem ser interpretadas como principal fator restritivo e estes critrios acabam por levar estes recursos a serem mais utilizados do que outros, degradando a performance do sistema. Ainda segundo Barcaui, os processos e polticas da empresa em relao a alocao de seus recursos so de fundamental importncia no contexto da restrio. Em um ambiente multiprojetos, a combinao de diversas tarefas no sincronizadas, a chamada multitarefa, limita a performance destes recursos. Nestes casos, a verdadeira restrio no so os recursos da organizao, mas as prprias prticas organizacionais que no estabelecem mecanismos de priorizao de recursos e tampouco se preocupam com a capacidade do sistema.

Portanto, alm das complexas variveis que cercam um nico projeto existem outras

dificuldades que surgem quando passam a existir diversos projetos acontecendo simultaneamente. comum que os projetos sejam lanados com falta de recursos e de uma programao bem definida. Isto acarreta a re-priorizao entre os projetos, sub-projetos e tarefas, ou seja, no momento em que o prazo de algum dos projetos esteja vencendo ele passa a ser o foco das atenes. Em um momento posterior ele pode ser relegado a segundo plano em detrimento de outro que esteja na mesma situao. A alocao de recursos ento deve ser feita no momento em que os projetos precisam e no atravs de um planejamento prvio. O resultado pode ser a ausncia do recurso no momento em que o mesmo necessrio, recorrendo a solues paliativas drsticas que comprometem o oramento, a qualidade e o cronograma do projeto. Um caso tpico acontece durante a manuteno de um produto. s vezes um problema simples de ser resolvido pode ser postergado por vrios dias devido indisponibilidade de uma pessoa capacitada para resolv-lo no momento em que ele surge. Considerando ento a natureza mutvel dos recursos entre os projetos, o problema da comunicao toma propores ainda maiores. Isso gera conflitos, sentimento de insegurana, estresse e desconforto entre a equipe de desenvolvimento, pois a mobilidade das pessoas entre os projetos por muitas vezes no permite que elas tenham um conhecimento mais aprofundado do que esto desenvolvendo.

2.1. Portflio de Projetos x Gerncia de Multiprojetos

Por portflio de projetos entende-se a atividade de atribuir critrios para selecionar e

priorizar projetos dentro de um conjunto de propostas que estejam alinhados com as estratgias organizacionais. A gerncia de multiprojetos preocupa-se em como distribuir e controlar os recursos para os projetos uma vez que estes tenham sido selecionados. No geral, no h um entendimento claro entre portflio de projetos e gerenciamento de multiprojetos. A Tabela 5 aborda


Trabalho de Graduao

20

de maneira bastante sinttica as sutis diferenas inerentes entre estes dois conceitos, segundo Dye [Dye 2000].

Tabela 5. Comparao de alto nvel entre gerenciamento de portflio de projetos e gerncia de mltiplos

projetos.

Gerenciamento de Portflio de Projetos Gerenciamento de Mltiplos

Projetos Propsito Seleo e priorizao de projetos Alocao de recursos Foco Estratgico Ttico nfase do planejamento Mdio e longo prazo Curto prazo (dirio) Responsabilidade Gerenciamento executivo/snior Gerentes de projetos/recursos

As organizaes esto estruturadas primariamente em trs nveis: estratgico, ttico e

operacional [Mussak 2003]. O nvel estratgico composto pela alta administrao executiva da organizao e responsvel pela definio das metas de mdio e longo prazo que estejam alinhadas s estratgias da organizao. no nvel estratgico que ocorre a seleo e priorizao dos projetos, tambm conhecido como portflio de projetos. O nvel ttico se preocupa em definir as tarefas a serem realizadas para que os projetos de longo e mdio prazo definidos no nvel estratgico aconteam. Este nvel composto pelos gerentes de projeto e o foco do trabalho no gerenciamento dirio das atividades planejadas e na alocao dos recursos necessrios para o andamento das atividades. O gerenciamento multiprojetos consiste no acompanhamento contnuo dos diversos projetos de um ambiente multiprojetos pela gerncia, manifestando-se primordialmente neste nvel. O nvel operacional composto pelos demais membros do projeto, os encarregados de executarem as atividades definidas pelo nvel ttico. A estrutura organizacional demonstrada na Figura 7.

Figura 7. Estrutura Organizacional.

Entrada Sada

Nvel Ttico

Portflio de Projetos

Tarefas a Realizar

Formaodos

Projetos

Decises de Negcio

Nvel Estratgico

Portflio de Negcios

Projeto A

Tarefa 1Tarefa 2

Tarefa 3Tarefa N

Projeto B

Tarefa 1Tarefa 2

Tarefa 3Tarefa N

Cliente 1

Nvel EstratgicoCliente 2

Nvel Operacional

Projeto dos Pacotes de Trabalho


Projeto daEstrutura

Analtica do Projeto(WBS)

Projeto daEstrutura


Entrada Sada

Nvel Ttico

Portflio de Projetos

Tarefas a Realizar

Formaodos

Projetos

Decises de Negcio

Nvel Estratgico

Portflio de Negcios

Projeto A

Tarefa 1Tarefa 2

Tarefa 3Tarefa N

Projeto A

Tarefa 1Tarefa 2

Tarefa 3Tarefa N

Projeto B

Tarefa 1Tarefa 2

Tarefa 3Tarefa N

Projeto B

Tarefa 1Tarefa 2

Tarefa 3Tarefa N

Cliente 1

Nvel EstratgicoCliente 2

Nvel Operacional



Projeto daEstrutura


Projeto daEstrutura



Trabalho de Graduao

21

Durante a fase de seleo e priorizao de projetos, especialmente quando a alocao de recursos em um ambiente multiprojetos um problema, importante considerar o seguinte:

(a) Os projetos deveriam ser similares em tamanho e nvel de complexidade; (b) Os projetos deveriam ter relativamente a mesma durao e requererem poucos

recursos nicos; (c) Os projetos deveriam ser de prioridades similares para permitir balancear requisitos

sem completamente omitir alguns projetos na atribuio de recursos; (d) Os projetos deveriam ser similares nas disciplinas e tecnologias abordadas. Todos os projetos, independentes ou inter-relacionados, tipicamente tm um nico e

completo ciclo de vida com diferentes datas de incio e trmino. Isto ocasiona que projetos individuais dentro do portflio estejam em diferentes fases para o gerente de projetos planejar e executar ao mesmo tempo. Um gerente de projetos pode experimentar alguma dificuldade para manter um balano entre os projetos por conta disso. Esta situao composta por projetos de diferentes prioridades. Projetos de maior prioridade recebem uma maior ateno para a atribuio inicial e subseqente de recursos. O problema que a maioria das organizaes no adota um modelo formal para priorizar os projetos que conduziro, a princpio todos eles tm prioridade mxima. No entanto, ao longo do desenvolvimento do projeto, essa prioridade vai sendo modificada de acordo com o nvel de urgncia do projeto. No geral, esse nvel definido pelo nvel de risco, complexidade ou fora relativa do stakeholder do projeto. Isto faz com que os recursos no tenham sido alocados previamente da maneira que deveriam ser, a alocao ento se torna dinmica e ocasiona conflitos de toda natureza. Se estes conflitos no so resolvidos de maneira sistemtica, visvel uma drstica reduo na performance do projeto e da organizao como um todo.

2.2. Tipologias de Ambientes Multiprojetos

Em relao classificao dos ambientes multiprojetos, Danilovic [Danilovic 2001] aborda

a existncia de trs tipos:

a) Ambiente Multiprojetos Convergentes

Figura 8. Ambiente Multiprojetos Convergentes

Uma caracterstica do ambiente multiprojetos convergente (Figura 8) que o que em um caso pode tratar-se de um subprojeto em outro caso pode ser um projeto independente ou um


Trabalho de Graduao

22

projeto maior contendo outros subprojetos. As indstrias de manufatura de carros e aeronaves podem ser usadas como exemplos de organizaes multiprojetos convergentes.

b) Ambiente Multiprojetos Divergentes

Figura 9. Ambiente Multiprojetos Divergentes

Uma caracterstica do ambiente multiprojetos divergentes (Figura 9) que vrios projetos diferentes compartilham a mesma plataforma, tecnologia e deciso de produto ou negcio. Um exemplo da configurao divergente a indstria automobilstica, na qual diferentes modelos compartilham a mesma plataforma, motor ou chassi. A sada do processo divergente uma variedade de modelos de carros, adaptaes do mercado, etc. O principal problema de tal ambiente coordenar atividades de acordo com as relaes identificadas.

c) Ambiente Multiprojetos Paralelos

Figura 10. Ambiente Multiprojetos Paralelo No ambiente multiprojetos paralelos (Figura 10), diferentes projetos podem ser vistos como

independentes uns dos outros, ainda que compartilhem recursos como pessoas, base de


Trabalho de Graduao

23

conhecimento, etc. O foco aqui no est na sada do processo mas nos recursos utilizados para conduzir os projetos e tarefas, enquanto a sada dos tipos de ambientes citados anteriormente a base para o entendimentos das caractersticas do ambiente multiprojetos.

2.3. Ambientes Multiprojetos de Software

A grande maioria das organizaes de software trabalha orientada a projetos e com mais

de um projeto sendo executados simultaneamente. O principal problema identificado nestas organizaes a ausncia de uma base histrica que permita aos gerentes de projetos fazer planejamentos com estimativas mais acuradas. De maneira geral, os gerentes tentam repetir o que foi bem sucedido em projetos anteriores e evitar o que no deu certo baseado em sua experincia pessoal ou, no mximo, baseado tambm na troca de experincias com colegas da empresa. Isso nem sempre d certo novamente devido a prpria singularidade dos projetos. Alm disso, este procedimento altamente subjetivo e no institucionalizado, se o gerente sai da empresa, aquele conhecimento adquirido vai embora com ele. Desta forma, os erros tendem a ocorrer novamente em diversos projetos conduzidos pela mesma organizao.

O portflio de projetos tambm no algo fortemente implantado nas organizaes de

software. No geral, a seleo necessria quando se h um nmero de projetos que exceda a capacidade de desenvolvimento da organizao, entretanto esta no a realidade das empresas de software. A realidade destas empresas a captao do mximo de projetos possveis e que consigam cobrir os custos fixos mensais das mesmas. Desta maneira, o alinhamento estratgico dos projetos com a organizao e as tcnicas de seleo e priorizao dos projetos deixada de lado. Isto reflete fortemente na gerncia dos mltiplos projetos, pois acarreta uma priorizao dinmica dos projetos, baseada nos seus deadlines, no seu valor ou na fora dos seus stakeholders. Dentro deste contexto, os prprios gerentes de projetos acabam se tornando super alocados para os diversos projetos e, conseqentemente, o resto da equipe de desenvolvimento da empresa. O que se sucede ento uma negligncia no gerenciamento muitas vezes devido escassez de tempo dos gerentes e no sua falta de habilidade ou de conhecimento tcnico.

Esta superalocao acrescida de outros fatores como volatilidade dos requisitos e a pouca

participao dos usurios representativos do sistema durante seu processo de desenvolvimento levam a uma alta taxa de projetos de software mal sucedidos ou cancelados se comparados com projetos de outras reas de conhecimento como a construo civil.


Trabalho de Graduao

24

3. MODELOS DE QUALIDADE EM GESTO DE PROJETOS

Melhorar a produtividade do gerenciamento de projetos no um problema atual. Pelo

contrrio, ele remete a uma necessidade existente h vrias dcadas. Diversos modelos de qualidade j foram propostos visando suprir estas lacunas. Este captulo aborda alguns dos modelos mais difundidos nesse segmento - entre eles o CMMI, foco do modelo que aqui propomos - bem como os modelos mais recentes que esto sendo cada vez mais adotados por diversas organizaes que trabalham com projetos e no exclusivamente empresas de software.

3.1. Project Management Body of Knowledge (PMBOK)

O Project Management Body of Knowledge (PMBOK) um guia elaborado pelo Project

Management Institute (PMI) que aborda as melhores prticas da gerncia de projetos, desenvolvido por profissionais e cientistas da rea. O PMBOK aborda todas as reas vitais de um bom planejamento e orienta os gerentes de projeto para conseguirem atingir os objetivos dos projetos que conduzem dentro do prazo, oramento e qualidade exigidos ou, pelo menos, com o mnimo de imprevistos possveis. A verso mais atual desta publicao foi lanada no ano 2004, porm a verso em que este trabalho est baseada a do ano 2000.

Segundo o PMBOK, a gerncia de projetos a aplicao de conhecimentos, habilidades e

tcnicas para projetar atividades que visem atingir requisitos definidos. O principal objetivo do PMBOK visualizar a gerncia de projetos como um conjunto de processos encadeados e integrados. Por processos entende-se uma srie de aes que provocam resultados. O PMBOK descreve 39 processos estruturados em cinco grupos, conforme mostrado na Figura 11.

Figura 11. Grupos de Processos do PMBOK 2000

As principais atividades atribudas a cada um destes grupos de processos podem ser vista na Tabela 6.

Tabela 6. Grupos de processos do PMBOK e suas principais atividades. Grupo de Processo Principais Atividades

Iniciao Definio e compromisso com o projeto

Planejamento Definio de um plano que garante que a execuo do projeto cumpre a sua misso

Execuo Coordenao de pessoas e recursos para realizar o plano

Controle Monitorao, controle e aes corretivas para garantir que os objetivos so atingidos

Finalizao Aceitao formalizada dos resultados do projeto e terminao coordenada.


Trabalho de Graduao

25

O projeto primeiramente passa por uma fase de iniciao na qual so definidos os objetivos e os produtos finais do projeto. Estes resultados so formalmente apresentados aos stakeholders do projeto visando uma compreenso e uma aceitao formal de ambas as partes acerca do projeto como um todo. Em seguida produzido um plano de projeto detalhando as atividades, o cronograma, os recursos envolvidos (humanos e financeiros) e outras informaes relevantes para que os objetivos do projeto possam ser atingidos. As atividades definidas no planejamento so ento executadas e monitoradas continuamente. Caso ocorram desvios em relao ao planejado, aes corretivas so tomadas de imediato. Freqentemente, o planejamento passa por atualizaes durante o transcorrer do projeto. O ciclo envolvendo o planejamento, a execuo e o controle se repete indefinidamente at que os objetivos do projeto sejam atingidos e seus produtos tenham sido elaborados. A partir desse momento ocorre a finalizao formal do projeto que passa pela aceitao formal dos resultados do projeto por parte dos stakeholders e o armazenamento das lies aprendidas durante o projeto em uma base histrica para uso posterior. Esta base histrica permitir ao gerente de projetos repetir os procedimentos que foram bem sucedidos em projetos anteriores, evitar os procedimentos mal sucedidos e fazer estimativas mais acuradas em projetos futuros semelhantes.

Apesar desta distino formal entre as atividades dos grupos de processos, na prtica

estas atividades se sobrepem e interagem ao longo de todo ciclo de vida do projeto como pode ser visto na Figura 12.

Figura 12. Sobreposio dos grupos de processos do PMBOK 2000

Estes grupos de processos ainda so subdivididos em nove reas de conhecimento, conforme mostrado na Figura 13. As reas de conhecimento da gerncia de projetos descrevem os conhecimentos e prticas em gerncia de projetos em termos dos processos que as compem.


Trabalho de Graduao

26

Figura 13. reas de Conhecimento do PMBOK 2000 A Tabela 7 apresenta as principais descries de cada uma dessas reas de

conhecimento e os processos que compem cada uma delas.

Tabela 7. Descrio das reas de conhecimento do PMBOK. rea de

Conhecimento Descrio Composio

Escopo

Descreve os processos necessrios para assegurar que o projeto contemple todo o trabalho requerido, e nada mais que isso, para completar o projeto com sucesso.

Iniciao Planejamento do Escopo Detalhamento do Escopo Verificao do Escopo Controle de Mudanas do Escopo

Custo Descreve os processos necessrios para assegurar que o projeto seja contemplado dentro do oramento previsto.

Planejamento dos Recursos Estimativa dos Custos Oramento dos Custos Controle dos Custos

Tempo

Descreve os processos necessrios para assegurar que o projeto termine dentro do prazo previsto.

Definio das atividades Seqenciamento das Atividades Estimativa da Durao das

Atividades Desenvolvimento do Cronograma Controle do Cronograma

Integrao Descreve os processos necessrios para assegurar que os diversos elementos do projeto sejam adequadamente coordenados.

Desenvolvimento do Plano do Projeto

Execuo do Plano do Projeto Controle Geral de Mudanas

Qualidade Descreve os processos necessrios para assegurar que as necessidades que originaram o desenvolvimento do projeto sero satisfeitas.

Planejamento da Qualidade Garantia da Qualidade Controle da Qualidade

Risco

Descreve os processos que dizem respeito identificao, anlise e resposta a riscos do projeto.

Identificao dos Riscos Quantificao dos Riscos Desenvolvimento das Respostas

aos Riscos Controle das Respostas aos

Riscos

Comunicao Descreve os processos necessrios para assegurar a gerao, captura, distribuio, armazenamento e pronta

Planejamento das Comunicaes Distribuio das Informaes Relato de Desempenho


Trabalho de Graduao

27

apresentao das informaes do projeto sejam feitas de forma adequada e no tempo certo.

Encerramento Administrativo

Recursos Humanos

Descreve os processos necessrios para proporcionar a melhor utilizao das pessoas envolvidas no projeto.

Planejamento Organizacional Montagem da Equipe Desenvolvimento da Equipe

Aquisies

Descreve os processos necessrios para aquisio de mercadorias e servios fora da organizao que desenvolve o projeto.

Planejamento das Aquisies Preparao das Aquisies Obteno de Propostas Seleo de Fornecedores Administrao dos Contratos Encerramento dos Contratos

Em um grupo de processos, os processos individuais so ligados por suas entradas e

sadas. Relacionando os 39 processos apresentados na Tabela 7 com os 5 grupos de processos apresentados na Figura 11, teramos:

(i) Processos de Iniciao

O nico processo deste grupo de processos o de Iniciao. O propsito deste processo obter o comprometimento da organizao para o incio da prxima fase do projeto.

(ii) Processos de Planejamento

O planejamento de fundamental importncia num projeto, porque executar um projeto

implica em realizar algo que no tinha sido feito antes. Como conseqncia, existem relativamente mais processos nessa seo. Entretanto, o nmero de processos no significa que a gerncia de projetos principalmente planejamento a quantidade de planejamento elaborada deve estar de acordo com o escopo do projeto e com a utilidade da informao desenvolvida. Planejamento um esforo contnuo atravs da vida do projeto.

Os relacionamentos entre os processos de planejamento so mostrados na Figura 14.

Estes processos esto sujeitos a freqentes interaes antes da complementao do plano.

Figura 14. Processos de Planejamento do PMBOK 2000


Trabalho de Graduao

28

Alguns dos processos de planejamento tm dependncias bem definidas, que fazem com que eles sejam executados essencialmente na mesma ordem, na maioria dos projetos. Estes processos essenciais de planejamento podem interagir vrias vezes durante qualquer fase de um projeto. Eles incluem:

a) Planejamento do Escopo desenvolver uma declarao escrita do escopo, como base para

futuras decises no projeto. b) Detalhamento do escopo subdividir os principais subprodutos do projeto em componentes

menores e mais manuseveis. c) Definio das Atividades identificar as atividades especficas que devem se realizadas

para produzir os diversos subprodutos do projeto. d) Seqenciamento das Atividades identificar e documentar as dependncias entre as

atividades. e) Estimativa da Durao das Atividades estimar o nmero de perodos de trabalho (prazos)

que sero necessrios para completar as atividades individuais. f) Desenvolvimento do Cronograma criar o cronograma do projeto a partir da anlise da

seqncia das atividades, suas duraes, e as necessidades de recursos. g) Planejamento da Gerncia de Risco decidir qual a abordagem e o planejamento para a

gerncia de risco em um projeto. h) Planejamento dos Recursos determinar que recursos (pessoas, equipamentos, materiais)

devem ser utilizados, e em que quantidades, para a realizao das atividades do projeto. i) Estimativa dos Custos desenvolver uma aproximao (estimativa) dos custos dos

recursos que so necessrios para completar as atividades do projeto. j) Oramento dos Custos alocar a estimativa dos custos globais ao pacote de trabalho

individuais. k) Desenvolvimento do Plano do Projeto agregar os resultados dos outros processos de

planejamento construindo um documento coerente e consistente.

As interaes entre os demais processos de planejamento so mais dependentes da natureza do projeto. Por exemplo, em alguns projetos pode haver sido identificado apenas um pequeno risco ou mesmo nenhum, at que a maioria do planejamento tenha sido concluda e a equipe reconhea que as metas de custo e prazo so por demais ousadas, envolvendo assim um risco considervel. Ainda que estes processos facilitadores sejam realizados intermitentemente, e medida que so necessrios, durante o planejamento do projeto, eles no so opcionais. Eles incluem:

a) Planejamento da Qualidade identificar os padres de qualidade relevantes para o projeto

e determinar como satisfaz-los. b) Planejamento Organizacional identificar, documentar, e atribuir papis, responsabilidades

e relaes hierrquicas no projeto. c) Montagem da Equipe conseguir que os recursos humanos necessrios sejam designados

e alocados ao projeto. d) Planejamento das Comunicaes determinar as necessidades das partes envolvidas

quanto informao e comunicao: quem necessita de qual informao, quando necessita e como a informao ser fornecida.

e) Identificao dos Riscos determinar os riscos provveis do projeto e documentar as caractersticas de cada um.

f) Anlise Qualitativa dos Riscos fazer uma anlise qualitativa dos riscos e suas condies, para priorizar seus efeitos nos objetivos do projeto.

g) Anlise Quantitativa dos Riscos fazer uma medio de probabilidade e de impacto de risco, assim como estimar suas implicaes nos objetivos do projeto.

h) Planejamento das Respostas aos Riscos desenvolver processos e tcnicas necessrias para o aproveitamento de oportunidades e reduzir s ameaas de risco para os objetivos do projeto.

i) Planejamento das Aquisies determinar o que, quanto custa e quando contratar.


Trabalho de Graduao

29

j) Preparao das Aquisies documentar os requisitos do produto/servio a ser adquirido e as fontes possveis de fornecimento.

(iii) Processos de Execuo

Os processos de execuo incluem os processos essenciais e os facilitadores. A Figura 15

ilustra como interagem estes processos.

Figura 15. Processos de Planejamento do PMBOK 2000.

a) Execuo do Plano do Projeto levar a cabo o plano do projeto atravs da realizao das atividades nele includas.

b) Garantia da Qualidade avaliar regularmente o desempenho geral do projeto, com o objetivo de prover confiana de que o projeto ir satisfazer os padres estabelecidos de qualidade.

c) Desenvolvimento da Equipe desenvolver habilidades e competncias das pessoas e da equipe, para melhorar o desempenho do projeto.

d) Distribuio das Informaes disponibilizar as informaes necessrias, e no momento adequado, s partes envolvidas.

e) Pedido de Propostas obter, conforme apropriado a cada caso (cotaes de preo, cartas-convite, licitaes, concorrncias), as propostas de fornecimento dos produtos e/ou servios pretendidos.

f) Seleo de Fornecedores escolher entre os possveis fornecedores. g) Administrao dos Contratos gerenciar os relacionamentos com os fornecedores. (iv) Processos de Controle

O desempenho do projeto deve ser monitorado e medido regularmente para identificar as

variaes do plano. Estes desvios so analisados, dentro dos processos de controle, nas diversas reas de conhecimento. Na medida em que so identificados desvios significativos (aqueles que colocam em risco os objetivos do projeto), realizam-se ajustes ao plano atravs da repetio dos processos de planejamento que sejam adequados quele caso. Controlar tambm inclui tomar aes corretivas, antecipando-se aos problemas.

Os grupos de processos de controle tambm apresentam processos essenciais e

facilitadores. A Figura 16 ilustra como os processos de controle essenciais e facilitadores interagem.


Trabalho de Graduao

30

Figura 16. Processos de Controle do PMBOK 2000.

a) Controle Integrado de Mudanas coordenar as mudanas atravs de todo o projeto. b) Verificao do Escopo aceitar formalmente os resultados (escopo) do projeto. c) Controle de Mudanas do Escopo controlar as mudanas no escopo do projeto. d) Controle do Cronograma controlar as mudanas no cronograma do projeto. e) Controle dos Custos controlar as mudanas no oramento do projeto. f) Controle da Qualidade monitorar resultados especficos do projeto para determinar se eles

atingem padres adequados de qualidade, e identificar aes para eliminar as causas de desempenhos insatisfatrios.

g) Relato de Desempenho coletar e divulgar informaes de desempenho. Isto inclui relatrios de status, medidas de progresso, e novas estimativas do projeto.

h) Controle e Monitoramento dos Riscos ficar atento na identificao de riscos, monitorando riscos existentes e identificando novos riscos, garantindo a execuo de um plano de resposta aos riscos e avaliando suas eficcia na reduo do risco.

(v) Processos de Encerramento

A Figura 17 ilustra como interagem os processos de encerramento.

Figura 17. Processos de Encerramento do PMBOK 2000.

a) Encerramento dos Contratos completar e liquidar o contrato, incluindo a resoluo de qualquer item pendente.

b) Encerramento Administrativo gerar, reunir e disseminar informaes para formalizar o trmino da fase ou projeto, incluindo avaliaes e lies aprendidas para usar em outras fases ou futuros projetos.

3.2. Capability Maturity Model Integration (CMMI)

A necessidade de se institucionalizar os procedimentos da organizao atravs da

definio de processos comuns no ciclo de desenvolvimento de software e, sobretudo, no gerenciamento destes projetos uma realidade visvel das organizaes. O Capability Maturity Model Integration (CMMI) [Chrissis 2003] um modelo de maturidade de desenvolvimento de produtos desenvolvido pelo Software Engineering Institute (SEI), que est cada vez mais sendo adotado nas empresas de software.

O CMMI o resultado da consolidao das diversas verses de seu antecessor, o

Capability Maturity Model (CMM) conjuntamente com algumas normas ISO e outros modelos de melhoria de processos. A proposta do CMMI a de um modelo integrado que pode ser utilizado em vrias disciplinas, com foco, sobretudo, em desenvolvimento integrado do produto e do


Trabalho de Graduao

31

processo (usado junto com prticas de produo de um produto especfico), desenvolvimento de sistemas (desenvolvimento de sistemas como um todo, incluindo software ou no), desenvolvimento de Software e subcontratao (aquisio de produtos de fornecedores), entre outros. Este modelo descreve orientaes para a definio de e implantao de processos, porm no descreve processo algum (o que x como) so orientaes definidas atravs de prticas especificadas.

Por sua vez, o CMMI apresenta dois tipos de representaes, a saber: Representao Contnua H um agrupamento das reas de processo por categorias

e essas reas de processo so avaliadas independentemente umas das outras segundo seus nveis de capacidade.

Representao por Estgios - H um agrupamento das reas de processo por nvel de maturidade e essas reas de processo so avaliadas conjuntamente em um processo de avaliao da maturidade da organizao como um todo.

A Figura 18 ilustra as representaes do CMMI.

Figura 18. Representaes do CMMI

Como vemos na Figura 18, na representao contnua, ilustrada esquerda, as reas de

processo podem desenvolver nveis de capacidade diferentes dependendo do objetivo estratgico da organizao. Por exemplo, a rea de processo de gerncia de requisitos poderia ser mais bem explorada e apresentar um nvel de capacidade maior do que a rea de processo de subcontratao se a organizao no utiliza muito este artifcio. J na representao por estgios, ilustrada direita, as reas de processo comuns so agrupadas em diferentes nveis de maturidade. O fato de a organizao estar no nvel de maturidade dois significa que todas as reas de processo obrigatrias para aquele nvel foram satisfeitas igualmente. Como dissemos, cada uma das representaes tem a sua aplicao selecionada baseado no modelo de negcio da organizao. Algumas das vantagens de cada uma destas representaes so apontadas na Tabela 8.

Tabela 8. Vantagens de cada uma das representaes do CMMI. Representao Contnua Representao por Estgios

Permite a seleo da ordem de melhoria dos processos que melhor se adeqa aos objetivos de negcio da organizao.

Prov uma seqncia de melhoria pr-definida em um conjunto determinado de reas de processo, onde cada nvel funciona como a fundao para o prximo nvel.

Permite a comparao de reas de processo entre diferentes organizaes ou atravs dos resultados apresentados de acordo com os estgios equivalentes.

Atribui uma nota de classificao do nvel de maturidade em que a organizao se encontra atravs dos resultados das avaliaes, permitindo dessa forma a comparao de forma

PA PA

Pro

cess

A

rea

Cap

ab

ilit

y

0

1 2

3

4

5

PAPA PA

Pro

cess

A

rea

Cap

ab

ilit

y

0

1 2

3

4

5

PA

Staged

ML 1ML2

ML3ML4

ML5

Staged

ML 1ML2

ML3ML4

ML5


Trabalho de Graduao

32

direta entre as organizaes. Estrutura compatvel com o padro ISO/IEC 15504.

Proporciona uma migrao simplificada do modelo SW-CMM para o CMMI.

Estrutura familiar para aqueles que esto migrando da comunidade de engenharia de sistemas.

Algumas organizaes que iniciaram os esforos de migrao para o CMMI relatam razes

pela escolha de cada uma delas: Representao Contnua

o A habilidade de escolha da rea de processo que se deseja melhorar com base nos objetivos e prioridades da organizao;

o Quando a abordagem focada na melhoria contnua da capacidade do processo e no no atendimento de um nvel de maturidade;

o A liberdade de escolha das reas de processo impacta positivamente no programa de melhoria;

o Permite tambm um caminho para a abordagem por estgios, pois as organizaes ao longo de seu processo de melhoria podem selecionar as reas de processo exatamente iguais aos nveis de maturidade.

Representao por Estgios

o A gerncia snior das organizaes e os clientes compreendem com mais facilidade;

o Uma pesquisa entre os clientes potenciais das organizaes e at mesmo com os contratantes governamentais apresentou a abordagem por estgios como a mais indicada;

o Aparentemente, baseado em pesquisas informais, no existe um mercado atual para a abordagem contnua;

o A primeira vista, a abordagem por estgios a que mais se adequou s necessidades das organizaes.

Apesar dessas vantagens citadas, independente da abordagem usada e seja para a

melhoria de processos ou para avaliaes, o CMMI foi projetado para apresentar os resultados equivalentes. No existe um caminho mais fcil, independente da representao, para um mesmo objetivo. Alm disso, existe um mapeamento oficial que permite que avaliaes usando o modelo na representao contnua sejam traduzidas tambm em nveis de maturidade.

Por ser a representao mais adotada, o trabalho aqui proposto estar baseado na

representao por estgios. Como dissemos anteriormente, na representao por estgios as reas de processos comuns esto agrupadas em nveis de maturidade. Estes nveis so exibidos na Figura 19.


Trabalho de Graduao

33

Figura 19. Nveis de maturidade da representao por estgios do CMMI. As reas de processo de cada um dos nveis de maturidade da representao por estgios

do CMMI podem ser vistas na Tabela 9.

Tabela 9. reas de processo por nveis de maturidade da representao por estgios do CMMI. Nvel de Maturidade reas de Processo

Nvel 2

Gerenciamento de Requisitos Planejamento de Projetos Acompanhamento e Controle de Projetos Garantia da Qualidade do Processo e do Produto Gerncia de Subcontratao Gerncia de Configurao Medio e Anlise

Nvel 3

Desenvolvimento de Requisitos Soluo Tcnica Integrao de Produtos Verificao Validao Foco do Processo Organizacional Definio do Processo Organizacional Treinamento Organizacional Gerncia do Projeto Integrado Gerncia de Riscos Treinamento Integrado Anlise de Deciso e Resoluo Ambiente Organizacional para Integrao

Nvel 4 Performance do Processo Organizacional Gerncia de Projeto Quantitativa

Nvel 5 Inovao Organizacional e Implantao Anlise Causal e Revoluo * O nvel de maturidade 1 considerado o caos no qual a organizao no possui nenhum processo definido ou os processos ainda so insuficientes e instveis para gerar estimativas precisas e serem repetidos.

O segundo nvel de maturidade deste modelo foca justamente nos processos que

envolvem o gerenciamento de projetos. A nfase deste nvel na necessidade de se definir processos para a atividade de gerenciamento de projetos para os projetos mais representativos da

Processo imprevisvel, pouco controlado

Processo definido parao nvel de projetos e frequentemente reativo

Processo proativo e definido para a organizao

Processo medido e controlado

Foco na melhoria do processo

QuantitativamenteGerenciado

Executado

Gerenciado

Definido

1

2

3

4

5 Otimizado

Processo imprevisvel, pouco controlado

Processo definido parao nvel de projetos e frequentemente reativo

Processo proativo e definido para a organizao

Processo medido e controlado

Foco na melhoria do processo

QuantitativamenteGerenciado

Executado

Gerenciado

Definido

1

2

3

4

5 Otimizado


Trabalho de Graduao

34

organizao. O objetivo a criao principalmente de uma base histrica de informaes para a organizao, diminuindo a dependncia da organizao com seus colaboradores e disseminando o conhecimento adquirido para todos os demais colaboradores. Desta maneira nota-se que o primeiro passo para se obter qualidade no desenvolvimento de um produto melhorando a eficincia da sua gesto e disseminando as experincias boas e ruins com todos de modo a replicar as boas e diminuir a probabilidade de incidncia de erros conhecidos. Por esta razo limitaremos uma explanao mais detalhada apenas s reas de processo do nvel dois, mais especificamente apenas s duas reas de processo inerentes ao gerenciamento de projetos que mais sofrem a influncia dos impactos do ambiente multiprojetos - Planejamento de Projetos e Acompanhamento e Controle de Projetos.

Antes de passarmos a uma explorao detalhada destas duas reas de processo,

preciso obter uma viso geral da estrutura do modelo CMMI. Essa estruturao mostrada na Figura 20.

Figura 20. Estrutura do Modelo do CMMI na representao por estgios.

Cada componente desta estrutura tem o seu propsito, vejamos os principais: Metas Genricas O atendimento de uma meta genrica significa uma melhoria no

controle do planejamento e implementao dos processos associados rea de processo. As metas genricas constribuem para o grau de institucionalizao dos processos, ou seja, significa que o processo est sendo executado de forma mais slida, sistemtica e otimizada. So chamadas genricas porque so as mesmas para todas as reas de processo.

Metas Especficas As metas especficas so aplicadas a uma rea de processo e

endeream caractersticas que descrevem o que deve ser implementado para satisfazer a rea de processo. Todas as metas especficas de uma rea de processo devem ser atendidas para determinar a satisfao da rea de processo.

Prticas Genricas As prticas do CMMI refletem a essncia do modelo. no nvel

das prticas que se trabalha as atividades de melhoria de processos. As prticas genricas provm institucionalizao a fim de assegurar que os processos associados rea de processo sero efetivos, repetveis e duradouros. As prticas genricas

Maturity Level

Process Area Process Area Process Area

Generic Goals Specific Goals

Commitment to Perform

Ability to Perform

Directing Implementation Verification

Common Features

Generic Practices

Specific Practices

Maturity Level

Process Area Process Area Process Area

Generic Goals Specific Goals

Commitment to Perform

Ability to Perform

Directing Implementation Verification

Common Features

Generic Practices

Specific Practices


Trabalho de Graduao

35

contribuem para o atendimento das metas genricas quando aplicadas a uma determinada rea de processo.

Prticas Especficas Uma prtica especfica representa uma atividade considerada

importante no atendimento da meta especfica associada mesma.

Alm destes poderamos existem outros que no aparecem nesta estrutura, mas que so igualmente importantes, como:

Produtos de Trabalho Tpicos Fornecem exemplos de artefatos de sada das

prticas. O modelo do CMMI cita alguns de acordo com a prtica, mas existem outros que tambm so vlidos e no esto listados. A adoo destes depende da cultura da organizao.

Subprticas So descries detalhadas que fornecem informaes adicionais para

a interpretao das prticas genricas e especficas.

No caso especfico do nvel de maturidade 2, a meta genrica descrita no CMMI Institucionalize um Processo Gerenciado, ou seja, um processo realizado que planejado e executado de acordo com uma poltica, emprega pessoas habilitadas, possui os recursos necessrios, envolve stakeholders relevantes, monitorado e controlado e revisado quanto aderncia descrio do processo. Essa meta genrica representada por dez metas genricas:

Estabelecer uma poltica organizacional Estabelecer e manter uma poltica

organizacional para planejamento e realizao do processo Planejar o processo Estabelecer e manter o plano para realizao do processo

Prover recursos Prover os recursos adequados para a execuo do processo e

para o desenvolvimento dos produtos de trabalho e servios associados

Atribuir responsabilidades Atribuir responsabilidades e autoridade para a execuo do processo e para o desenvolvimento dos produtos de trabalho e servios associados

Treinar as pessoas Treinar as pessoas que executam e fornecem apoio ao

processo (no precisa ser treinamentos formais)

Gerenciar a configurao Colocar os produtos de trabalho designados sobre os nveis de controle apropriados de gerenciamento da configurao

Identificar e envolver os stakeholders relevantes Identificar e envolver os

stakeholders relevantes ao processo, conforme o planejado

Monitorar e controlar o processo Monitorar e controlar o processo com base no planejamento realizado para a execuo do mesmo e tomas as aes corretivas apropriadas

Avaliar aderncia objetivamente Avaliar objetivamente a aderncia ao processo

com base na descrio do processo, padres e procedimentos e enderear as no conformidades

Revisar o status com a gerncia snior Revisar as atividades, o status e os

resultados do processo com a gerncia snior e resolver as no conformidades


Trabalho de Graduao

36

Visando atender estas metas genricas, cada uma das reas de processo possui metas e prticas especficas que esto alinhadas com estas. A seguir exploramos com mais detalhes as reas de processo de Gerncia de Requisitos, Planejamento de Projetos e Acompanhamento e Controle de Projetos.

a) Planejamento de Projetos

Segundo o CMMI, o propsito do Planejamento de Projeto estabelecer e manter planos que definam as atividades do projeto. Esta rea de processo envolve:

Desenvolver o plano de projeto Interagir com os stakeholders apropriadamente Obter comprometimento com o plano Manter o plano O planejamento inicia com os requisitos que definem o produto e o projeto. O

Planejamento inclui estimar os atributos dos produtos de trabalho e das atividades, determinar os recursos necessrios, negociar os compromissos, produzir um cronograma e identificar e analisar os riscos do projeto. Iterar entre estas atividades pode ser necessrio para estabelecer o plano de projeto. O plano de

ambiente para gerenciar multiplos projetos de ti

Documents