PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU EM
GESTÃO DO CONHECIMENTO E DA TECNOLOGIA DA
INFORMAÇÃO
MESTRADO
G
ERENCIAMENTO DEP
ROJETOS DES
OFTWAREB
ASEADO NOV
ALOR PARA ON
EGÓCIOAutor: Anderson Luis Cambraia Itaborahy
Orientadores:
Profª Drª Káthia Marçal de Oliveira
Anderson Luis Cambraia Itaborahy
Gerenciamento de Projetos de Software Baseado no
Valor para o Negócio
Dissertação apresentada ao Programa de Pós-Graduação “Strictu Sensu” em Gestão do Conhecimento e da Tecnologia da Informação, da Universidade Católica de Brasília, como requisito parcial para obtenção do Título de Mestre em Gestão do Conhecimento e da Tecnologia da Informação.
Orientadora: Profa. Dra. Káthia Marçal de Oliveira
Co-orientador: Prof. Dr. Rildo Ribeiro dos Santos
Brasília
I88g Itaborahy, Anderson Luis Cambraia.
Gerenciamento de projetos de software baseado no valor para o negócio / Anderson Luis Cambraia Itaborahy. – 2007.
218f. : il. ; 30 cm
Dissertação (mestrado) – Universidade Católica de Brasília, 2007. Orientação: Káthia Marçal de Oliveira
Co-orientador: Rildo Ribeiro dos Santos
1. Software. 2. Tecnologia da informação. 3. Negócios. 4.
Gerenciamento de configurações de software. I. Oliveira, Káthia Marçal, orient. II Santos, Rildo Ribeiro, co-orient. III. Título
CDU 004.4
Ficha elaborada pela Coordenação de Processamento do Acervo do SIBI – UCB.
A
GRADECIMENTOS− À Flávia, minha esposa, pelo apoio incondicional, pelo carinho infinito
e por nunca me deixar desanimar.
− Ao Lucas e à Bia, por entenderem e perdoarem minhas ausências.
− À Profa. Káthia, minha orientadora, pelo apoio e comprometimento
especiais, ao Prof. Rildo, meu co-orientador, pelo incentivo, e a ambos, pela competência e pela força nas horas difíceis.
− Aos meus pais, pelo exemplo e pelos valores que me legaram.
− Aos amigos que dividiram comigo essa caminhada, por me
suportarem ao longo dela e, em especial, ao André e ao Nick, pelas conversas sobre a Academia, a vida e o inglês.
− Aos professores e colegas do MGCTI, pelo tanto que me ensinaram.
− Aos colegas do trabalho, pela rica troca de idéias e o incentivo
constante.
“É quase um dever pensar que o que já se tenha realizado é sempre pouco em comparação com o que resta para fazer.”
(autor desconhecido)
“Há uma satisfação esportiva em dar caça a um texto que não se encontra, há uma satisfação de charadista em encontrar, após muito refletir, a solução de um problema que parecia insolúvel.”
S
UMÁRIO
Sumário...i
Lista de Quadros ... v
Lista de Figuras...viii
Lista de Figuras...viii
Resumo... xi
Abstract ... xii
1. Introdução ...1
1.1. Motivação e Contexto ...1
1.2. Objetivos...4
1.3. Metodologia ...4
1.3.1. Classificação da Pesquisa ...4
1.4. Organização do Trabalho ...5
2. Gerenciamento de Projetos de Software...6
2.1. Introdução...6
2.2. Definições ...8
2.3. Modelos de Processo de Gerenciamento de Projetos...10
2.3.1. O PMBOK ...10
2.3.2. Gerenciamento de Projetos no CMMI ...13
2.3.3. Comparação Entre os Modelos...19
2.4. Projetos e Estratégia Organizacional...21
2.5. Escritório de Gerenciamento de Projetos ...24
2.6. Considerações Finais do Capítulo ...27
3. Valor para o Negócio em Projetos de Software...29
3.1. Introdução...29
3.2. Abordagens de Valor em Projetos ...30
3.2.1. Valor em Termos Financeiros ...30
3.2.2. Valor na Transformação dos Processos de Negócio ...34
3.2.3. Cadeia de Resultados ...39
3.3. Valor na Engenharia de Software ...45
3.3.1. Engenharia de Software Baseada em Valor ...45
3.3.2. MBASE...46
3.3.3. Decisão Baseada em Valor...49
3.3.4. Monitoramento e Controle Baseado em Valor ...50
3.4. Estratégia de Negócios...51
3.5. Considerações Finais do Capítulo ...55
4. Gerenciamento de Projetos Baseado em Valor ...57
4.1. Introdução...57
4.2. Fundamentação da Abordagem ...59
4.3. Fatores Determinantes do Valor do Projeto...64
4.3.1. Objetivos Estratégicos...66
4.3.2. Processo de Negócio ...67
4.3.3. Transformação no Negócio ...68
4.3.4. Benefício ...69
4.3.5. Processo de Conversão ...70
4.3.6. Processo de Integração ...71
4.3.7. Processo de Competição ...73
4.3.8. Tempo ...74
4.3.9. Custo...75
4.3.10. Riscos ...76
4.3.11. Comentários sobre os Fatores Determinantes do Valor do Projeto ...78
4.4. Domínios e Representação dos Fatores de Valor do Projeto...79
4.4.1. Domínio para Objetivos Estratégicos de Negócio ...81
4.4.2. Domínio para Processos de Negócio...84
4.4.3. Domínio para Transformação dos Negócios ...86
4.4.4. Domínio para Riscos aos Benefícios...90
4.4.5. Representação do Cenário de Projeto de Software ...94
4.4.6. Representação das Iniciativas Complementares ...98
4.4.7. Representação do Cenário de Mercado...98
4.5. Artefatos de Registro do Valor do Projeto...99
4.5.1. Modelo de Valor ...101
4.5.2. Cenário do Projeto ...103
4.5.4. Cenário de Mercado...106
4.6. Monitoração do Valor do Projeto ...108
4.6.1. Artefato de Monitoração do Valor do Projeto ...110
4.6.2. Apresentação dos Resultados da Avaliação ...114
4.7. Processo de Gerenciamento do Valor do Projeto...115
4.7.1. Definir os Pontos de Monitoração e Avaliação...117
4.7.2. Definir o Modelo de Valor do Projeto...117
4.7.3. Registrar o Cenário do Projeto...118
4.7.4. Monitorar as Iniciativas Complementares ...119
4.7.5. Monitorar o Cenário de Mercado...119
4.7.6. Monitorar o Valor do Projeto ...120
4.7.7. Registrar e Divulgar o Valor do Projeto ...120
4.7.8. Identificar e encaminhar decisões...121
4.8. Considerações Finais do Capítulo ...121
5. Aplicação Prática da Abordagem Proposta...124
5.1. Introdução...124
5.2. Projeto A – Criação de Novo Produto...125
5.2.1. Momento 1 – Início do Projeto ...126
5.2.2. Momento 2 – Projeto em Execução ...133
5.2.3. Momento 3 – Próximo ao Final do Projeto ...140
5.3. Projeto B – Cumprimento de Determinação Legal...147
5.3.1. Momento 1 – Início do Projeto ...147
5.3.2. Momento 2 – Projeto em Execução ...150
5.3.3. Momento 3 – Próximo ao Final do Projeto ...154
5.4. Projeto C – Ampliação de Produto Existente ...157
5.4.1. Momento 1 – Início do Projeto ...158
5.4.2. Momento 2 – Cenário 1...160
5.4.3. Momento 2 – Cenário 2...163
5.5. Considerações Finais do Capítulo ...165
6. Conclusão ...168
6.1. Contribuições...170
6.2. Limitações...171
6.3. Trabalhos Futuros...172
Apêndice A – Consolidação dos Objetivos Estratégicos de Negócio ...178
Apêndice B – Consolidação dos Tipos de Transformação do Negócio por um Projeto de Software ...181
Apêndice C – Artefatos de Registro dos Fatores Determinantes do Valor para o Projeto B...184
L
ISTA DE
Q
UADROS
Quadro 1 – Grupo de processos de gerenciamento de projetos (PMBOK, 2004)...10
Quadro 2 – Áreas de conhecimento em gerenciamento de projetos (PMBOK, 2004). ...11
Quadro 3 – Processos de Monitoramento e Controle de Projetos (PMBOK, 2004). .12 Quadro 4 – Informações de projeto monitoradas segundo o PMBOK (2004) ...13
Quadro 5 – Áreas de processo fundamentais de gerência de projetos (CMMI, 2001). ...15
Quadro 6 – CMMI/PMC – Monitorar Projeto Conforme o Plano – Práticas Específicas (CMMI, 2001). ...16
Quadro 7– CMMI/PMC – Gerenciar Ações Corretivas até a Conclusão – Práticas Específicas (CMMI, 2001). ...17
Quadro 8 – Informações do projeto monitoradas, segundo o CMMI (2001)...17
Quadro 9 – CMMI/PPQA – Avaliar Objetivamente Processo e Artefatos – Práticas Específicas (CMMI, 2001). ...18
Quadro 10 – CMMI/PPQA – Fornecer Entendimento Objetivo – Práticas Específicas (CMMI, 2001). ...18
Quadro 11 – Informações monitoradas em um projeto de software...19
Quadro 12 – Principais questões nos processos da cadeia de valor (adaptado de Soh e Markus,1995; Marshall, McKay e Prananto, 2004) ...37
Quadro 13 – Questões-chave para tomada de decisão em projetos (Thorp, 1999)..42
Quadro 14 – Forças competitivas em uma indústria (Porter, 1979) ...52
Quadro 15 – Níveis de turbulência (adaptado de Ansoff e McDonnel, 1993)...54
Quadro 16 – Fatores determinantes do valor em um projeto de software...66
Quadro 17 – Informações do Cenário do Projeto de Software...71
Quadro 18 – Informações do Cenário de Mercado ...74
Quadro 20 – Objetivos estratégicos de negócio (Porter, 1996)...81
Quadro 21 – Dimensões do uso estratégico da TI (adaptado de Kraemer et al, 1994) ...82
Quadro 22 – Objetivos estratégicos de negócio (Harris e Cosonato, 2002)...83
Quadro 23 – Objetivos estratégicos de negócio (PMI, 2006a) ...83
Quadro 24 – Relação consolidada de objetivos estratégicos de negócio ...84
Quadro 25 – Categoria de processos operacionais na PCF (APQC, 2006)...85
Quadro 26 – Categoria de processos de gerenciamento e suporte na PCF (APQC, 2006) ...86
Quadro 27 – Transformações de negócio habilitadas por TI (Venkatraman, 1994) ..87
Quadro 28 – Transformação do negócio pela TI (Mooney, Gurbaxani e Kraemer, 1997) ...87
Quadro 29 – Capacidades criadas ou ampliadas por um projeto de software (Apfel e Smith, 2003)...88
Quadro 30 – Efeito da TI sobre os negócios (Ross e Beath, 2003) ...89
Quadro 31 – Transformação nos negócios a partir de projetos de software ...90
Quadro 32 – Fatores de risco de obtenção de benefícios (ITGI, 2006b)...91
Quadro 33 – Fatores de risco à obtenção de benefícios...93
Quadro 34 – Elementos do Cenário de Projeto...97
Quadro 35 – Representação do Cenário de Mercado...99
Quadro 36 – Artefatos de registro dos fatores de valor em um projeto ...100
Quadro 37 – Informações no Cenário de Projeto...104
Quadro 38 – Informações do Cenário de Mercado ...107
Quadro 39 – Relacionamento entre questões-chave (Thorp, 1995) e processos na cadeia de valor (Marshall, McKay e Prananto, 2004)...111
Quadro 40 – Aspectos a observer na monitoração do valor do projeto...111
Quadro 42 – Objetivos e práticas de gerenciamento do valor do projeto...116
Quadro 43 – Artefatos produzidos na monitoração do valor do Projeto A...126
Quadro 44 – Consolidação dos objetivos estratégicos de negócios ...178
L
ISTA DE
F
IGURAS
Figura 1 – Componentes de uma área de processo – PA – no CMMI ...14
Figura 2 – Criação de valor pela TI (SOH e MARKUS, 1995)...34
Figura 3 – Processo modificado de geração de valor pela TI (MARSHALL, McKAY e PRANANTO, 2004) ...36
Figura 4 – Transformações de negócio habilitadas por TI (Venkatraman, 1994)...38
Figura 5 – Cadeia de Resultados (adaptado de Thorp,1999) ...40
Figura 6 – Framework de integração de modelos MBASE (adaptado de BOEHM e PORT, 1999) ...47
Figura 7 – Monitoramento e controle do valor gerado no projeto (BOEHM, 2006c)..51
Figura 8 – Cadeia de processos de geração de valor por um projeto de software....62
Figura 9 – Gerenciamento de Projetos de Software baseado em seu valor para o negócio...63
Figura 10 – Classificação de investimentos em TI (Ross e Beath, 2003) ...89
Figura 11 – Matriz de intensidade de risco (adaptado de PMBOK, 2004)...94
Figura 12 – Exemplo de Modelo de Valor ...102
Figura 13 – Exemplo de Cenário de Projeto...105
Figura 14 – Exemplo de Iniciativas Complementares ...106
Figura 15 – Exemplo de Cenário de Mercado...107
Figura 16 – Artefato de monitoração do valor do projeto ...113
Figura 17 – Gráfico de evolução do valor do projeto...114
Figura 18 – Linha de tempo de monitoração do valor do Projeto A...126
Figura 19 – Projeto A – Modelo de Valor no Momento 1...127
Figura 20 – Projeto A – Iniciativas Complementares no Momento 1...129
Figura 21 – Projeto A – Cenário de Mercado no Momento 1 ...129
Figura 23 – Projeto A – Monitoração do Valor do Projeto – Linha de Base ...132
Figura 24 – Projeto A – Modelo de Valor no Momento 2...133
Figura 25 – Projeto A – Cenário de Projeto no Momento 2...135
Figura 26 – Projeto A – Iniciativas Complementares no Momento 2...136
Figura 27 – Projeto A – Cenário de Mercado no Momento 2 ...136
Figura 28 – Projeto A – Monitoração do Valor do Projeto no Momento 2 ...137
Figura 29 – Projeto A – Monitoração do Valor do Projeto – Momento 2 ...139
Figura 30 – Projeto A – Modelo de Valor no Momento 3...141
Figura 31 – Projeto A – Cenário de Projeto no Momento 3...142
Figura 32 – Projeto A – Iniciativas Complementares no Momento 3...143
Figura 33 – Projeto A – Cenário de Mercado no Momento 3 ...144
Figura 34 – Projeto A – Monitoração do Valor do Projeto no Momento 3 ...145
Figura 35 – Projeto A – Monitoração do Valor do Projeto no Momento 3 ...146
Figura 36 – Linha de tempo de monitoração do valor do Projeto B...147
Figura 37 – Projeto B – Monitoração do Valor – Linha de Base...149
Figura 38 – Projeto B – Linha de base do valor ...150
Figura 39 – Projeto B – Monitoração do Valor no Momento 2...151
Figura 40 – Projeto B – Registro do Valor do Projeto – Momento 2...153
Figura 41– Projeto B – Monitoração do Valor no Momento 3...155
Figura 42 – Projeto B – Registro do valor do projeto no Momento 3...156
Figura 43 – Linha de tempo de monitoração de valor do Projeto C ...158
Figura 44 – Projeto C – Monitoração do valor no Momento 1 ...159
Figura 45 – Projeto C – Monitoração do Valor – Linha de Base...160
Figura 46 – Projeto C – Monitoração de valor no Momento 2 com cenário 1...161
Figura 47 – Projeto C - Registro do valor no Momento 2 com cenário 1...162
Figura 49 – Projeto C – Registro do valor no Momento 2 com cenário 2 ...164
Figura 50 – Projeto B – Modelo de Valor no Momento 1...185
Figura 51 – Projeto B – Iniciativas Complementares no Momento 1...185
Figura 52 – Projeto B – Cenário de Mercado no Momento 1 ...186
Figura 53 – Projeto B – Modelo de Valor no Momento 2...186
Figura 54 – Projeto B – Cenário de Projeto no Momento 2...187
Figura 55 – Projeto B – Iniciativas Complementares no Momento 2...188
Figura 56 – Projeto B –Cenário de Mercado no Momento 2 ...188
Figura 57 – Projeto B –Modelo de Valor no Momento 3...189
Figura 58 – Projeto B –Cenário de Projeto no Momento 3...190
Figura 59 – Projeto B –Iniciativas Complementares no Momento 3...191
Figura 60 – Projeto B – Cenário de Mercado no Momento 3 ...191
Figura 61 – Projeto C – Modelo de Valor no Momento 1 ...193
Figura 62 – Projeto C – Iniciativas Complementares no Momento 1...193
Figura 63 – Projeto C – Cenário de Mercado no Momento 1 ...194
Figura 64 – Projeto C – Modelo de Valor no Momento 2 com Cenário 1 ...194
Figura 65 – Projeto C – Cenário de Projeto no Momento 2 com cenário 1 ...195
Figura 66 – Projeto C – Iniciativas Complementares no Momento 2 com cenário 1196 Figura 67 – Projeto C – Cenário de Mercado no Momento 2 com cenário 1...196
Figura 68 – Projeto C – Cenário de Projeto no Momento 2 com cenário 2 ...197
Figura 69 – Projeto C – Modelo de Valor no Momento 2 com cenário 2 ...198
R
ESUMO
Projetos são veículos de criação de valor nas organizações modernas e, dada a importância da tecnologia da informação em geral e do software em particular, os projetos de software são muito relevantes nesse contexto. Quando uma organização decide levar adiante um projeto de software, alocando a ele parte importante de seus recursos humanos e materiais em geral escassos, espera obter uma contrapartida de valor. O gerenciamento dos projetos de software, portanto, deve basear suas decisões nesse valor, buscando compreender e influenciar os fatores que o determinam. Entretanto, apesar da evolução da engenharia de software e do gerenciamento de projetos nas últimas décadas, sua atuação em geral ainda se dá em um “contexto neutro quanto ao valor”, voltado principalmente para a correção técnica e a aderência aos planos elaborados. Embora indiscutivelmente necessário, isso não é suficiente para assegurar o valor do projeto. Este trabalho pretende contribuir para uma visão do gerenciamento de projetos que seja baseada em seu valor para os negócios. Para tanto, a partir de pesquisa na literatura, foram identificados fatores que determinam o valor em um projeto de software e propostos instrumentos para registrá-los e monitorá-los. Esta é a base para uma abordagem de gerenciamento em que as decisões se baseiam no potencial de valor do projeto para a organização e não apenas na sua correção técnica. Essa abordagem foi descrita e utilizada em três aplicações práticas, onde se avaliou sua aplicabilidade e utilidade na fundamentação das decisões de projeto. Os resultados da pesquisa, embora não permitam concluir que esta seja a melhor forma de considerar o valor do projeto, indicam que a abordagem é viável e pode ser um instrumento útil nas decisões de gerenciamento.
Palavras-chave: Gerenciamento de Projetos, Engenharia de Software
A
BSTRACT
Projects are vehicles for value creation in modern organizations and, giving the importance of information technology (especially software), software projects are very relevant in this context. When an organization decides to carry out a project it invests a significant amount of scarce human and material resources and expects to get some value in return. Thus, decisions in software project management should be based on this expected value by trying to understand and influence its driver factors. However, despite the significant progress project management and software engineering have experienced in recent decades, both disciplines still work in a ‘value neutral context’, by which is meant focusing on technical correctness and adherence to plans. Although attention to these items is important, it’s not enough to ensure project value. This work intends to contribute to a view of project management based on business value. To do so, a brief literature review was done in order do identify value driver factors, and instruments for recording and monitoring these factors will be proposed. These are the foundations for a management approach that bases its decisions on the projects potential business value, rather than exclusively on technical correctness. This approach will be described as it was used in three practical applications during the research period, in order to evaluate its applicability and usefulness. Although research results were not enough to conclude the approach here is the best way to consider project value, they nevertheless indicate that it is both viable and useful for management decision-making.
Key-words: Project Management, Value-based Software Engineering, IT
1. I
NTRODUÇÃO
1.1. Motivação e Contexto
Venkatraman (1994), ao considerar a forma como a tecnologia da informação afeta os negócios, afirma que esta “não é apenas um recurso útil tal como a eletricidade ou o telefone, mas uma fonte fundamental de transformação nas organizações”.
Com o ambiente onde atuam em constante mudança, as organizações dependem cada vez mais da tecnologia da informação – ou TI – para garantir tanto eficiência operacional quanto vantagem competitiva. Isso faz com que a parcela dos investimentos direcionados à TI chegue a representar 50% do total, segundo Weill e Ross (2006).
Segundo Kerzner (2002) os projetos são os principais vetores de transformação e inovação nas organizações. Os projetos de desenvolvimento de software – um caso especial de projetos de TI – são elementos de grande importância, representando uma fonte relevante de valor para o negócio.
Corroborando esse raciocínio, Boehm e Sullivan (1999) afirmam que a indústria de software existe porque produz valor, logo a expectativa desse valor deve ser levada em consideração em todos os aspectos do projeto.
Segundo aqueles mesmos autores, entretanto, a engenharia de software é, em geral, neutra quanto ao valor, ou seja, não o leva em consideração em suas decisões, concentrando-se nos aspectos técnicos do projeto. A responsabilidade do engenheiro de software frequentemente é vista como limitada a transformar requisitos de software em código verificável (BOEHM, 2006b), ignorando se o projeto está ou não gerando valor para a organização.
desenvolvimento de software deve buscar a vantagem competitiva sustentável, portanto um objetivo central desse gerenciamento deve ser compreender que fatores criam valor para a organização e como podem ser influenciados (WHOLIN e AURUM, 2006).
Diversos autores como, por exemplo, Hlupic e Qureshi (2003), Tockey (2005), Rönkkö e Pöyry (2006) e Sikka (2004), discutem os mecanismos de geração de valor a partir de projetos de software, contemplando instrumentos de análise financeira de investimentos, capital intelectual, características de mercado e outras.
A questão do alinhamento e da integração entre os projetos de software e as estratégias de negócio é também uma importante frente de pesquisa, envolvendo autores como Soh e Markus (1995), Thorp (1999), Mooney, Gurbaxani e Kraemer (1997), Marshall, McKay e Prananto (2004) e Luftman (2004).
Outros autores tratam da importância que o valor deve ter nas decisões de projeto e discutem como considerá-lo. Simmons (1996) e Favaro (1996) questionam uma visão excessivamente focada em qualidade no desenvolvimento de software, em detrimento dos seus efeitos sobre os objetivos de negócio e o valor gerado, Boehm e Sullivan (1999) apresentam o termo “Economia de Software” para descrever uma abordagem alinhada aos objetivos de negócio para as decisões em projetos de software e Biffl et al (2006) propõem uma Engenharia de Software Baseada em Valor (Value-Based Software Engineering – VBSE).
Boehm (2006a) investiga as tendências da indústria de software até 2025, destacando a significativa evolução que devem experimentar os processos de software em resposta à crescente demanda, com ênfase nos usuários e no valor final. Citando Fuggetta (2000, apud Boehm, 2006a), aponta como uma das tendências futuras para engenharia de software “a necessidade de processos e métricas de software e estudos empíricos serem orientados a valor”.
Os projetos de software compartilham as principais características dos demais projetos em uma organização, mas acrescentam a elas a complexidade intrínseca da tecnologia da informação, afirmam Johnstone, Huff e Hope (2006). Esses projetos devem, portanto, ser tratados de forma abrangente, incluindo aspectos técnicos, de governança e de gestão de negócios. Segundo aqueles autores, “muitos estudos observam diferentes aspectos de um projeto de TI, mas ainda falta uma visão integral, holística”.
Os autores citados nesta seção convergem na idéia de que quando uma organização decide levar adiante um projeto de software, o faz porque pretende obter algum valor. Parece inquestionável, portanto, que esse valor deva ser considerado em todas as decisões do projeto.
Permanece, entretanto, um problema, traduzido nas seguintes questões:
− como gerenciar um projeto de software de forma a assegurar seu valor
para a organização?
− como os fatores que determinam esse valor podem ser registrados e
monitorados para fundamentar as decisões?
Apesar das importantes contribuições, não se encontra nos autores citados uma clara proposta para essas questões, principalmente quando se considera que o próprio conceito de valor é, em si, bastante complexo, reunindo características subjetivas e intangíveis.
Este trabalho pretende contribuir para a redução dessa lacuna propondo uma abordagem de gerenciamento de projetos de software baseada no seu valor para os negócios. Para isso irá procurar compreender os fatores que criam valor nos projetos e como esses fatores podem ser registrados e monitorados para fundamentar decisões que assegurem a sobrevivência e a vantagem competitiva da organização.
1.2. Objetivos
O objetivo geral deste trabalho é estabelecer uma abordagem de gerenciamento de projetos de software onde as decisões se baseiem na expectativa de geração de valor para a organização.
Os objetivos específicos são:
i. Investigar como se dá a geração de valor num projeto de software;
ii. Propor uma forma de registrar os fatores que determinam o valor do projeto;
iii. Investigar como o valor pode ser monitorado ao longo do projeto;
O contexto em que será conduzida a pesquisa e o ponto de vista a ser adotado nas discussões será aquele de organizações que utilizam software em seus negócios e conduzem projetos de software, mas para as quais esse não é o negócio principal, ou seja, não comercializam software ou serviços correlatos.
Organizações que comercializam produtos ou projetos de software adotam uma abordagem de mercadoria para definir seu valor. As organizações descritas acima, por outro lado, vêem os projetos de software como um investimento que ampliará o valor de seu negócio.
1.3. Metodologia
1.3.1. Classificação da Pesquisa
Segundo Moresi (2004) as formas tradicionais de classificação de uma pesquisa a consideram quanto a sua natureza, abordagem, fins e meios.
Com base nas classificações apresentadas por aquele autor, a pesquisa desenvolvida neste trabalho é de natureza aplicada, uma vez que busca gerar conhecimento para aplicação prática – o gerenciamento de projetos de software – e a abordagem utilizada é qualitativa.
Quanto aos fins, a pesquisa é, principalmente, metodológica por propor um instrumento de captação e manipulação da realidade.
investigação documental, analisando a base de dados de projetos de uma organização para avaliação da aplicabilidade dos instrumentos propostos.
Desta forma, este trabalho se baseia no seguinte conjunto de suposições, que serão consideradas nos capítulos subseqüentes:
i. O valor do projeto para os negócios da organização é determinado por um conjunto de fatores a partir dos quais pode ser explicitado;
ii. Esses fatores podem ser identificados e monitorados ao longo do projeto;
iii. O resultado da monitoração dos fatores que determinam o valor do projeto é um subsídio importante para as decisões e contribuem para assegurar a geração de valor para os negócios da organização.
1.4. Organização do Trabalho
O trabalho está dividido em seis capítulos, incluindo esta introdução.
O segundo capítulo irá apresentar um conjunto de conceitos fundamentais sobre o gerenciamento de projetos, oferecendo uma visão dessa disciplina a partir de dois modelos relevantes: o PMBOK (2004) e o CMMI (2001), com maior foco nas práticas de monitoramento.
O terceiro capítulo discutirá as propostas de diversos autores sobre como se dá a geração de valor em projetos de software, buscando destacar os aspectos essenciais de cada uma delas, de forma a revelar os elementos que definem as várias facetas desse valor.
A partir da base teórica apresentada nos Capítulos 2 e 3, no Capítulo 4 será desenvolvida e apresentada uma abordagem de gerenciamento de projetos de software baseada em seu valor para o negócio, que buscará alcançar os objetivos apresentados na Seção 1.2.
No Capítulo 5 serão descritas três aplicações práticas realizados sobre projetos reais de uma mesma empresa, onde foram utilizadas as propostas desenvolvidas no Capítulo 4, com a finalidade de verificar sua aplicabilidade.
2. G
ERENCIAMENTO DE
P
ROJETOS DE
S
OFTWARE
2.1. Introdução
O gerenciamento de projetos é uma disciplina antiga, mas alcançou maior destaque nas últimas décadas em função do crescimento da complexidade e da incerteza presentes no ambiente a partir da segunda metade do século XX, juntamente com a rápida evolução tecnológica que levou o conhecimento ao status de ativo mais importante nas organizações (VALERIANO, 2005).
Iniciativas como a criação do Project Management Institute – PMI – nos Estados Unidos e da International Project Management Association – IPMA – na Europa, ambas no final da década de 1960, levaram à estruturação da disciplina e de seus princípios.
Esse período de consolidação da visão moderna do gerenciamento de projetos coincidiu, em grande parte, com a evolução da tecnologia da informação e da indústria de software. As organizações, cada vez mais dependentes de sistemas de informação para condução de seus negócios, não podiam conviver com um ambiente de imprevisibilidade no desenvolvimento de software.
A engenharia de software surgiu no contexto do que se convencionou chamar “crise do software” como uma resposta para as dificuldades em lidar com a crescente complexidade e criticidade dos sistemas a desenvolver (GHEZZI, JAZAYERI e MANDRIOLI, 1991).
O sistema de software passava a ser visto como um produto complexo, resultado de uma atividade de engenharia que requer gerenciamento, organização, teorias, técnicas, ferramentas e metodologias (GHEZZI, JAZAYERI e MANDRIOLI, 1991).
Uma importante parte da engenharia de software está relacionada com atividades de gerenciamento de projetos, envolvendo questões técnicas como estimativas, planejamento, distribuição de atividades e acompanhamento de sua execução e, também, questões de pessoal, como seleção, treinamento e motivação da equipe.
O objetivo deste capítulo é apresentar a base conceitual do gerenciamento de projetos de software, na forma como é comumente aceita atualmente. Essa base forma o que será referenciado como gerenciamento de projetos tradicional, como forma de distingui-la da abordagem com maior ênfase no valor para negócio com a qual este trabalho se alinha.
Da base tradicional, posteriormente, será buscada parte dos elementos que constituirão os fatores de geração de valor nos projetos de software.
Nas próximas seções serão apresentados os principais conceitos do gerenciamento de projetos dentro de um contexto do desenvolvimento de software. Dois dos principais modelos que descrevem os processos de gerenciamento de projetos – o PMBOK e o CMMI – serão apresentados, discutidos e comparados.
A partir desses modelos, será abordado o tema do gerenciamento de projetos como instrumento de implementação da estratégia organizacional, incluindo nessa discussão o papel o escritório de gerenciamento de projetos.
2.2. Definições
Um projeto é um sistema temporário de recursos e atividades coordenados com a finalidade de gerar um produto único sob restrições de tempo, custo e qualidade.
Esta definição de projeto é largamente aceita e adotada por diversas fontes de referência (PMBOK, 2004; CMMI, 2001; MAXIMIANO, 2002; VALERIANO, 2005; KERZNER, 2000) que, com pequenas variações, destacam algumas características fundamentais, presentes em qualquer projeto:
− Um projeto é um empreendimento temporário: o projeto terá início e fim
identificáveis, embora possa ser de longa duração;
− Um projeto é um sistema coordenado de atividades e recursos: o
projeto irá consumir recursos ao executar atividades planejadas de forma a alcançar seus objetivos;
− Um projeto tem a finalidade de gerar um produto único: o projeto irá
gerar um resultado singular de alguma forma, algo que ainda não foi feito antes;
− Um projeto atua sob restrições de tempo, custo e qualidade: em todo
projeto o tempo e os recursos disponíveis são limitados e a qualidade do produto final deve atender a definições prévias.
Maximiano (2002) destaca o componente de incerteza presente em todos os projetos, definindo essa característica como uma escala que representa o grau de desconhecimento com relação ao resultado ou ao caminho para alcançá-lo. Quanto maior o desconhecimento, maior a incerteza e a dificuldade de fazer previsões.
Outra característica destacada pelo mesmo autor é a complexidade inerente aos projetos de forma geral que, assim como a incerteza, também é uma escala. A complexidade de um projeto corresponde ao número de variáveis a serem administradas e é afetada por fatores como a multidisciplinaridade, o número de pessoas ou organizações envolvidas, a dispersão da equipe e a diversidade e volume das informações a serem manipuladas, dentre outros.
vez, reunirá atividades que nunca foram realizadas exatamente daquela forma e que, talvez, jamais venham a sê-lo novamente no futuro.
No contexto atual dos negócios, o controle dos meios físicos de produção já não representa a garantia de sucesso, as mudanças são cada vez mais freqüentes e inesperadas e a dependência da TI é cada vez maior. As empresas precisam utilizar tecnologia de vanguarda para potencializar os conhecimentos que possuem e gerar vantagem competitiva.
Projetos reúnem e entregam conhecimento e são a principal fonte de criação de novo valor ao alavancar os ativos – tangíveis e intangíveis – da organização e produzir novos ativos, de valor maior (STEWART, 1997, apud KERZNER, 2002).
Os projetos relacionados ao uso de alta tecnologia – caso dos projetos de TI em geral e dos projetos de desenvolvimento de software em particular – trazem dificuldades significativamente maiores que projetos de outras áreas de conhecimento e enfrentam condições extremamente críticas (KENDRICK, 2003).
Quando comparados com os projetos conduzidos no passado, projetos envolvendo TI são frequentemente mais restritivos em termos de tempo e recursos e apresentam maiores desafios do ponto de vista técnico (KENDRICK, 2003).
Gerenciamento de projetos é o processo de tomar decisões relacionadas ao uso de recursos (MAXIMIANO, 2002), envolvendo planejamento, programação e controle do conjunto de atividades de forma integrada para atingir seus objetivos em benefício dos participantes do projeto (KERZNER, 2002).
A crescente complexidade dos projetos e sua importância para as organizações no mundo atual, levaram à necessidade de se sistematizar os procedimentos envolvidos no seu gerenciamento, convertendo o gerenciamento de projetos em uma disciplina, um corpo organizado de conhecimentos.
2.3. Modelos de Processo de Gerenciamento de Projetos
2.3.1. O PMBOK
O Project Management Institute (PMI), a partir da década de 1980, consolidou um movimento para identificar as áreas de conhecimento que concentram os conceitos e técnicas mais importantes para o gerenciamento de projetos.
Esse movimento produziu o Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (PMBOK, do inglês Project Management Body of Knowledge), atualmente em sua terceira edição (PMBOK, 2004). O PMBOK reúne os conhecimentos em gerenciamento de projetos amplamente aceitos como boas práticas pela comunidade internacional e constitui-se em um padrão de facto na área.
O PMBOK (2004) organiza os conhecimentos em gerenciamento de projetos como um conjunto de processos agregados em cinco grupos em função da integração entre eles e de seus objetivos. O Quadro 1 relaciona os grupos de processo e respectivos objetivos.
Quadro 1 – Grupo de processos de gerenciamento de projetos (PMBOK, 2004).
!
" #
$
Os mesmos processos estão agrupados também em nove disciplinas, conforme a natureza do conhecimento que os caracteriza. Cada uma das disciplinas reúne processos voltados a gerenciar um aspecto específico do projeto.
Quadro 2 – Áreas de conhecimento em gerenciamento de projetos (PMBOK, 2004).
!
%
!
& % & % !
' ! (
)
% %
% ! *
+ !
!
, - ! !
)
. % %
!
, !
/!
!
! %
Ao descrever esses processos, o PMBOK (2004) indica quais devem ser suas entradas e saídas, sugere também um conjunto de conhecimentos, técnicas e ferramentas que podem ser utilizados na sua execução.
Essa definição, entretanto, não é impositiva, ou seja, nem todas as saídas devem ser geradas obrigatoriamente, nem todas as técnicas precisam ser aplicadas. Para que o projeto seja bem sucedido, devem ser selecionados os processos necessários para atender seus objetivos dentro dos grupos de processo de gerenciamento de projetos.
No contexto da discussão principal deste trabalho, um aspecto fundamental do gerenciamento de projetos é o acompanhamento de sua evolução. No PMBOK (2004) essa questão é tratada dentro do grupo de processos de Monitoramento e Controle do Projeto.
envolve o monitoramento de suas atividades com relação ao plano estabelecido e o controle dos fatores que podem afetar seu desempenho.
Esse acompanhamento deve ser realizado continuamente, ao longo de todo o projeto, para que se tenha uma visão clara de sua evolução e seja possível identificar as ações corretivas necessárias.
O Quadro 3 relaciona os doze processos que compõem o grupo de Monitoramento e Controle do projeto, acompanhados de uma breve descrição e da indicação da área de conhecimento à qual pertencem.
Quadro 3 – Processos de Monitoramento e Controle de Projetos (PMBOK, 2004).
! " # $
" "
" %
& ' $
(
&
(
) '
* ' +
%
) ,
& &
' &
-& .
' )
/
As informações monitoradas por esse grupo contemplam todos os aspectos do projeto e representam os elementos que descrevem o estado do projeto em um determinado momento, segundo o PMBOK (2004).
Dos doze processos desse grupo, nove tratam informações específicas. Os três remanescentes tratam todas as informações de forma geral. São eles os dois processos de integração (Monitorar e Controlar o Trabalho do Projeto e Controle Integrado de Mudanças) que atuam sobre o conjunto dos elementos de gerenciamento de projetos e o processo de comunicação Relatório de Desempenho, que é voltado à formatação e publicação das informações de monitoração.
O Quadro 4 relaciona o conjunto de informações do projeto submetidas aos processos de monitoramento, segundo o PMBOK (2004).
Quadro 4 – Informações de projeto monitoradas segundo o PMBOK (2004)
" !
"
( (
" ) " " & & )
'
2.3.2. Gerenciamento de Projetos no CMMI
A engenharia de software evoluiu significativamente desde seu surgimento, havendo atualmente abordagens consagradas e provadas para grande parte dos problemas técnicos relativos ao desenvolvimento de software.
O CMM descreve os princípios e práticas que devem constituir um processo de software efetivo e aponta um caminho para conduzir as organizações no aperfeiçoamento desse processo de um estado caótico para outro maduro, disciplinado e previsível.
A partir do sucesso do CMM para software (SW-CMM) diversos outros CMMs foram desenvolvidos, abrangendo aspectos de gestão de pessoas, aquisições, engenharia de sistemas e desenvolvimento integrado de produtos e processos.
Em 2001 o SEI publicou o CMMI – Capability Maturity Model Integration, ou Integração dos Modelos de Maturidade da Capacidade (CMMI, 2001), que combinava vários dos modelos de maturidade então existentes.
O CMMI define um modelo de referência para avaliação dos processos de uma organização a partir de um conjunto de áreas de processo (Process Areas – PA). Uma PA corresponde a um grupo de práticas relacionadas a uma determinada área que, quando executadas de forma coletiva, satisfazem objetivos considerados importantes para produzir melhoria significativa naquela área.
A Figura 1 ilustra a estrutura de uma PA.
Figura 1 – Componentes de uma área de processo – PA – no CMMI
Cada PA tem objetivos específicos que devem ser atingidos para que seja considerada executada. Além disso, um conjunto de objetivos genéricos, aplicável a todas as PA, indica o grau de institucionalização da área de processo. Os objetivos são alcançados através da realização de práticas específicas e genéricas.
O CMMI oferece duas representações para seu conteúdo: uma por estágios, que avalia a maturidade da organização em cinco níveis progressivos, e outra
0
1 * 1 2 (
contínua, que identifica níveis de capacitação para cada PA, apontando seu grau de institucionalização.
As PAs na representação contínua são agrupadas em quatro categorias, baseadas no fluxo de artefatos entre os processos: Gerenciamento de Processos, Gerenciamento de Projetos, Engenharia e Suporte.
Dentro de cada uma dessas categorias são apontadas PAs fundamentais, voltadas a estabelecer os objetivos básicos do processo, e PAs progressivas, que representam avanços na capacitação da organização.
A categoria Gerenciamento de Projetos é composta por sete áreas de processo, sendo três delas fundamentais e quatro progressivas. O Quadro 5 mostra as áreas de processo fundamentais que compõem a categoria Gerenciamento de Projetos, indicando seus objetivos específicos.
Quadro 5 – Áreas de processo fundamentais de gerência de projetos (CMMI, 2001).
!
" & % & &
"
&
0 &
& ) & / "
1
) )
As siglas utilizadas para identificação das áreas de processo correspondem aos termos originais em inglês, conforme utilizados no modelo: PP para Project Planning, PMC para Project Monitoring and Control e SAM para Supplier Agreement Management.
O planejamento do projeto (PP) começa com requisitos que apontam o que será construído, definindo, a partir deles, as várias atividades de engenharia e de gerenciamento que irão compor o projeto.
A área de processo de monitoramento e controle (PMC) obterá dos planos do projeto os níveis apropriados de monitoramento e, quando percebido algum desvio, indicará e gerenciará as ações corretivas necessárias.
Requisitos do projeto que impliquem em aquisições externas serão tratados pela área de processo Gerenciamento de Acordo com Fornecedores (SAM). O plano de projeto representa o conjunto de artefatos que consolida e coordena as áreas de processo na categoria gerenciamento de projetos.
Para os objetivos deste trabalho, conforme já comentado na Seção 2.3.1, é de especial interesse o acompanhamento da evolução do projeto. No CMMI, este acompanhamento é implementado pela PA Monitoramento e Controle de Projetos – PMC.
A área de processo PMC tem dois objetivos específicos, conforme consta do Quadro 5: Monitorar o Projeto Conforme o Plano e Gerenciar Ações Corretivas até a Conclusão. O Quadro 6 relaciona as práticas associadas ao primeiro desses objetivos e o Quadro 7 aquelas associadas ao segundo deles.
Quadro 6 – CMMI/PMC – Monitorar Projeto Conforme o Plano – Práticas Específicas (CMMI, 2001).
"
2
! & 2 3
4
' &. -.4
'
& & )
%
&
& & & " & & & &
5 & $ & ' &.
& $ ' & ' &.
Quadro 7– CMMI/PMC – Gerenciar Ações Corretivas até a Conclusão – Práticas Específicas (CMMI, 2001).
" #
( & &
5
& "- & & )
& & /
O propósito desta área de processo é prover compreensão sobre o andamento do projeto com relação ao que foi planejado, fundamentando a definição de medidas corretivas, se necessário, e acompanhando sua execução. O conjunto de informações acompanhadas descreve, na visão do CMMI (2001), o estado do projeto em um determinado momento.
Das práticas relacionadas no Quadro 6, as cinco primeiras indicam aspectos específicos que são monitorados, enquanto as duas últimas descrevem procedimentos de revisão, quando se aplicarão as práticas anteriores. As práticas relacionadas no Quadro 7 não se referem a informações específicas, mas sim a procedimentos de correção dos desvios identificados no projeto.
O Quadro 8 relaciona, a partir das considerações acima, as informações de projetos monitoradas segundo o CMMI (2001).
Quadro 8 – Informações do projeto monitoradas, segundo o CMMI (2001).
' "
2
-% ) %
" & & & &
' '
Comparando as informações relacionadas no Quadro 8 com os processos de Monitoramento e Controle de Projetos do PMBOK relacionados no Quadro 4, percebe-se que há uma grande convergência entre elas.
controle de qualidade é tratada dentro da categoria de processos de Suporte, na área de processo de Garantia da Qualidade de Produtos e Processos (PPQA – do inglês Process and Project Quality Assurance).
O propósito da PPQA é avaliar objetivamente o processo executado, os artefatos e serviços, avaliando-os com relação a descrições de processo, padrões e procedimentos (CMMI, 2001). Assim como as demais áreas na categoria de Suporte, a PPQA define processos que serão utilizados no contexto da execução de outros processos.
A PPQA tem dois objetivos específicos:
− Avaliar objetivamente processo e artefatos: Avalia objetivamente a
aderência dos processos e serviços e artefatos relacionados a padrões aplicáveis;
− Fornecer entendimento objetivo: Rastreia e comunica problemas de
qualidade e não-conformidades e assegura sua resolução.
O Quadro 9 e o Quadro 10 relacionam objetivos e práticas específicos da área de processo PPQA, na mesma estrutura utilizada para apresentar os componentes do PMC.
Quadro 9 – CMMI/PPQA – Avaliar Objetivamente Processo e Artefatos – Práticas Específicas (CMMI, 2001).
" #
& & & . , 5&
& & &
& . &
Quadro 10 – CMMI/PPQA – Fornecer Entendimento Objetivo – Práticas Específicas (CMMI, 2001).
" #
4 4
" " / &
ao objetivo “Fornecer Entendimento Objetivo” voltam-se aos procedimentos de registro e disponibilização das informações, enquanto o objetivo “Avaliar Objetivamente Processos e Artefatos” volta-se a apurar a qualidade dos processos executados e dos artefatos produzidos. Desta forma, incluindo-se a área de processo PPQA juntamente com a PMC como fonte de informações de monitoração, deve-se incluir a informação “qualidade” juntamente com aquelas descritas no Quadro 8.
2.3.3. Comparação Entre os Modelos
Tanto os processos no grupo de Monitoramento e Controle do PMBOK (2004) quanto as práticas associadas a cada um dos objetivos específicos nas áreas de processo PMC e PPQA do CMMI (2001) representam práticas consagradas no gerenciamento de projetos. As informações apuradas e divulgadas a partir dessas práticas cobrem os aspectos relevantes na descrição do estado de um projeto.
Comparando-se o Quadro 4 e o Quadro 8 (acrescida da informação de qualidade), obtém-se uma relação de informações que descrevem o estado de um projeto de software. O Quadro 11 relaciona essas informações e apresenta uma breve descrição de seu significado.
Quadro 11 – Informações monitoradas em um projeto de software
#
"
" "
& %
( )
" .
' %
%
" & & 67& & &
2 &
' $
− Entregas: O PMBOK define explicitamente um processo voltado à
aceitação formal das entregas do projeto, enquanto o CMMI engloba essa informação, de forma implícita, dentro do processo de Monitoramento dos Parâmetros do Projeto;
− Escopo: O PMBOK define um processo específico para o controle das
alterações de escopo do projeto, com objetivo principal de manter sua estabilidade. O CMMI considera o escopo como um dos parâmetros monitorados do projeto.
− Cronograma: Da mesma forma que nas informações anteriores, o
PMBOK define um processo específico enquanto o CMMI inclui o cronograma no conjunto de parâmetros monitorados do projeto.
− Custos: O PMBOK define um processo específico para acompanhamento
dos custos e o CMMI o inclui – com destaque – dentre os parâmetros de projeto para monitoração.
− Qualidade: O PMBOK trata a questão de qualidade em um processo cujo
objetivo volta-se para a conformidade com padrões estabelecidos. O CMMI trata da questão de qualidade e de conformidade com padrões com muito mais detalhes em uma área de processo específica – PPQA – que pode ser acionada pelos processos de qualquer uma das demais áreas.
− Equipe: A atenção à equipe é destacada em um processo específico do
PMBOK e no CMMI/PMC é tratada como um dos parâmetros do projeto a serem monitorados.
− Recursos: O PMBOK não trata explicitamente de recursos nos processo
de Monitoramento e Controle de Projetos. O CMMI, por outro lado, considera este um dos parâmetros que devem ser monitorados do projeto.
− Compromissos: O PMBOK explicita apenas uma classe de
− Documentação: O grupo de processos de Monitoramento e Controle no
PMBOK não faz referência específica ao tratamento da documentação do projeto. O CMMI/PMC, por outro lado, define um processo de Monitoração do Gerenciamento dos Dados do projeto. Gerenciamento de Dados, no CMMI, refere-se à documentação que será produzida para registrar os dados do projeto.
− Envolvimento: Tanto PMBOK quanto o CMMI/PMC definem um processo
para monitorar o envolvimento dos stakeholders em cada fase do projeto a partir do que foi definido como necessário no planejamento.
− Riscos: Ambos os modelos dão grande importância ao registro e
monitoramento dos riscos do projeto como elemento fundamental do seu gerenciamento.
As informações relacionadas acima constituem o conjunto de elementos que as melhores práticas, segundo o PMBOK (2004) e o CMMI (2001), indicam que devem ser monitorados em um projeto de software. Esses são os elementos que descrevem o estado do projeto e fundamentam as avaliações a seu respeito.
2.4. Projetos e Estratégia Organizacional
Um projeto de software não está isolado. Ele é pensado, proposto e desenvolvido dentro de uma organização e – tenha esta ou não fins lucrativos – o projeto existe para gerar algum benefício, para criar valor para a organização.
A preocupação com a inserção dos projetos dentro de uma estratégia de negócios está presente tanto no CMMI quanto no PMBOK, com enfoques distintos, entretanto.
O PMBOK (2004) destaca, em sua introdução, que “os projetos são frequentemente utilizados como um meio de atingir o plano estratégico de uma organização”. O guia ressalta, também, a importância de o gerente e a equipe do projeto compreenderem o ambiente em que este está inserido, seja no aspecto cultural e social, nas questões políticas ou físicas.
em andamento na organização, tomando como insumo os fatores ambientais da empresa.
Embora o PMBOK (2004) defina que o termo de abertura deve descrever o relacionamento do projeto com o plano estratégico e suas responsabilidades dentro da organização, o guia não contém processos que sejam voltados a compreender ou monitorar o contexto de negócios em que o projeto se insere. De forma geral os processo do PMBOK (2004) referem-se ao ambiente interno do projeto, tendo como principal finalidade produzir um planejamento que leve aos resultados definidos e monitorar sua evolução.
O CMMI (2001), por sua vez, define uma categoria de áreas de processo voltada ao gerenciamento de processos. Essa categoria reúne os processos relativos a atividades de definição, planejamento, implementação e administração em geral dos processos que transcendem um único projeto. O foco dessa categoria é a criação de um conjunto de processos organizacionais, sua institucionalização e controle quantitativo.
Na categoria de processos de suporte, o CMMI (2001) define o processo “Ambiente Organizacional para Integração” (OEI – do inglês de Organizational Environment for Integration) que tem como objetivo estabelecer a abordagem e o ambiente para implementação do desenvolvimento integrado de produtos e projetos.
Esse ambiente será estabelecido com o desenvolvimento de processos que facilitem a integração das equipes envolvidas e a comunicação e colaboração das diversas partes interessadas no projeto. Se bem sucedido, esse processo levará a integração entre funções técnicas e de negócio na execução do projeto.
Apesar da preocupação com a institucionalização dos processos e o amadurecimento da organização, o CMMI (2001) também tem seu foco no ambiente interno.
levar em consideração seu contexto, acreditando que, uma vez criado o software, os benefícios automaticamente virão para a organização.
Se o gerenciamento do projeto de software o vê apenas como um conjunto de atividades voltadas a gerar um determinado produto, dentro de um cronograma e custos acordados, a possibilidade de que esse produto venha a gerar de fato os benefícios esperados pela organização é deixada em segundo plano, com grande risco de que não venha a ser cumprida (Thorp, 1999).
A visão tradicional do gerenciamento de projetos tem essa limitação: considera o projeto isoladamente, sem explorar suas interconexões com o ambiente de negócios, e presume que o produto de software a ser gerado representa, por si só, o benefício para a organização.
A partir da crítica a essa visão, vêm ganhando destaque as abordagens de gerenciamento de programas e de portfólios, onde um conjunto de projetos é gerido de forma coordenada para implementar os objetivos estratégicos da organização e otimizar a alocação de seus recursos.
Thorp (1999) defende essas abordagens, considerando o gerenciamento de projetos insuficiente para as organizações modernas. Mais recentemente, o PMI lançou dois novos padrões, voltados ao gerenciamento de portfólios (PMI, 2006a) e de programas (PMI, 2006b).
As visões de Thorp (1999) e do PMI (2006a, 2006b) são bastante próximas e ressaltam a preocupação com o gerenciamento dos projetos de forma coordenada como um meio para garantir os benefícios para a organização. Programas e portfólios são conceituados da seguinte forma:
− Programa: um grupo de projetos relacionados, gerenciados de forma
coordenada para obter benefícios e controle que não seriam alcançáveis se gerenciados individualmente;
− Portfólio: coleção de projetos, programas e outros tipos de trabalho
agrupados para facilitar seu efetivo gerenciamento para alcançar objetivos estratégicos de negócio.
preocupando-se apenas em gerar o produto previsto e atender às restrições de tempo e custo, embora seja condição necessária para gerar benefício para a organização, certamente não é o suficiente.
O projeto deve ser considerado sempre dentro de seu contexto, ponderados o ambiente da organização, seus objetivos estratégicos e os demais projetos que o complementem, tendo sempre em mente o valor que a organização espera receber como retorno pelos recursos que investiu.
A integração efetiva dos projetos à estratégia de negócios da organização implica em, necessariamente, considerar o valor do projeto para os negócios em todas as decisões. Essa vem a ser a questão essencial no gerenciamento de projetos baseado em valor.
2.5. Escritório de Gerenciamento de Projetos
Um Escritório de Gerenciamento de Projetos – EGP – é uma unidade organizacional que centraliza e coordena o gerenciamento de projetos em uma organização (PMBOK, 2004).
Kerzner (2000) associa a evolução dos escritórios de gerenciamento de projetos à ampliação do uso de abordagens de gerenciamento de projetos pelas organizações e, também, aos novos recursos oferecidos para essa atividade pela tecnologia da informação.
Nas décadas de 50 e 60 esses escritórios surgiram associados com grandes projetos de construção, com foco em manter atualizados os cronogramas e documentos do projeto, normalmente voltados a um projeto ou cliente específicos.
A partir da década de 70, com o advento de softwares de gerenciamento de projetos de uso centralizado e processamento baseado em mainframes, os EGP passaram a servir ao conjunto de projetos de uma organização, tornando-se o centro de informações da empresa com relação a seus projetos. Nessa época os EGP passaram a responder pela padronização dos instrumentos e processos de gerenciamento de projetos e pela disseminação de práticas na organização.
Valeriano (2005) destaca que, a partir dessa época, multiplicaram-se os projetos de menor porte nas organizações, num movimento associado à expansão do uso da abordagem de gerenciamento de projetos em novas áreas, inclusive no desenvolvimento de software. Além disso, os projetos passaram a receber atribuições mais amplas que as atividades operacionais que tradicionalmente desempenhavam.
Essa nova situação levou à necessidade de disseminação e homogeneização dos procedimentos aplicáveis aos projetos em uma organização. Os escritórios de gerenciamento de projetos passaram, então, a receber um novo conjunto de atribuições que incluem, conforme registrado no PMBOK (2004), o planejamento, priorização e execução coordenada dos projetos, assim como o suporte aos gerentes e equipes, na forma de treinamento, disponibilização de softwares, definição de políticas e procedimentos, etc.
Dentre os benefícios que a existência de um escritório de gerenciamento de projetos pode trazer para uma organização, Valeriano (2005) destaca:
− Maior alinhamento entre os projetos e os objetivos estratégicos;
− Maior profissionalismo e produtividade na condução dos projetos;
− Melhor distribuição dos recursos da organização;
− Uniformidade no tratamento aos clientes e partes interessadas nos
projetos;
− Melhor qualidade nas informações disponibilizadas à organização.
Atualmente a inclusão de um EGP como componente chave da metodologia de gerenciamento de projetos é um conceito largamente adotado pelas organizações, conforme atesta o Gartner Group (LIGHT et al, 2005), tendo ampliado sua aceitação a partir do ano 2000, mas existe grande variação nas formas de implementação dessas estruturas.
a) Numa abordagem leve, o EGP serve como repositório para informações sobre metodologias e padrões na organização. Essa forma é comum em empresas onde os projetos são descentralizados, sob controle das áreas de negócio, que os patrocinam e financiam. Os projetos se reportam diretamente a seus patrocinadores e o EGP não provê visibilidade sobre seu desempenho para a organização como um todo.
b) Num estágio ainda inicial de evolução, o EGP presta serviços de controle de prazos e custos dos projetos, produzindo relatórios multiprojetos e multidepartamentais. Além disso, envolve-se na capacitação dos gerentes de projeto e atua como ligação entre estes, os gerentes departamentais e os gestores de recursos.
c) Num estágio intermediário, o EGP mantém a base de dados com informações de projetos, é responsável pelas definições de métodos e padrões, administra os processos de gerenciamento de projetos na organização e atua como consultoria interna, apoiando a avaliação e revisão dos projetos.
d) Numa abordagem corporativa, o EGP participa da análise e aprovação de propostas de projetos, gerencia a distribuição dos recursos, identifica conflitos e apresenta recomendações para sua solução, provê revisão crítica e avaliação de desempenho dos projetos e atua externamente, junto a clientes e patrocinadores. Nesse estágio o EGP concentra o gerenciamento de projetos, podendo chegar a prover o gerenciamento direto dos principais projetos ou, ao menos, sua supervisão.
A evolução dos EGP nas organizações, especialmente em organizações de desenvolvimento de software, passa a incluí-lo como parte integrante das estruturas de Governança de TI e de gestão dos portfólios de projetos.
A maioria das iniciativas de negócio resulta em diversos projetos, muitos com uma participação substancial de TI. Segundo, ainda, o Gartner Group (LIGHT et al, 2005), deixar as decisões de governança desses projetos no âmbito exclusivo das áreas de TI tem se mostrado um equívoco, comprometendo seu valor para a organização e prejudicando a percepção geral da própria área de TI.
O mesmo Gartner Group (LIGHT et al, 2005) prevê, com uma probabilidade de 70%, que ao longo do ano de 2008, 75% dos projetos bem sucedidos de custo superior a US$ 500.000 (quinhentos mil dólares) serão planejados e acompanhados com a participação de um escritório de gerenciamento de projetos, enquanto 75% daqueles que fracassarem não terão essa participação.
Outra tendência identificada, também para o ano de 2008, é a de que a maioria das organizações de TI irá avançar para formas mais sofisticadas de EGP, justamente buscando maior efetividade dos seus resultados.
Desta forma, o escritório de gerenciamento de projetos passa a estar diretamente relacionado com alguns dos itens mais importantes da agenda dos gestores de TI (CIOs), segundo o Gartner Group (LIGHT et al, 2005):
a) Entrega de projetos que garantam crescimento dos negócios;
b) Ligação entre os negócios e as estratégias e planos de TI;
c) Melhoria da governança de TI.
O EGP tem se mostrado uma peça fundamental para o sucesso do gerenciamento de projetos moderno. Seu papel cresce em importância nas organizações, evoluindo de um simples repositório de padrões ou consolidador de informações, para um valioso instrumento de governança, com participação fundamental no alinhamento entre os projetos e os objetivos estratégicos de negócio.
2.6. Considerações Finais do Capítulo
princípios, métodos e instrumentos de gerenciamento de projetos fazem parte do repertório da engenharia de software, sendo o desenvolvimento de software um tipo particular de projeto.
Neste capítulo os conceitos do gerenciamento de projetos foram tratados dentro do contexto do desenvolvimento de software, tendo sido apresentados dois dos principais modelos que descrevem seus processos: o PMBOK (2004) e o CMMI (2001), sendo que neste se tratou particularmente do grupo de processos de gerenciamento de projetos, um subconjunto do modelo.
Da comparação entre os dois modelos foi extraído o conjunto de elementos que as melhores práticas, ali consolidadas, indicam que devem ser monitorados em um projeto de software. Esses são, portanto, os elementos que descrevem como o projeto evolui e que são utilizados para fundamentar as decisões do gerente de projetos e dos demais interessados e participantes.
Os dois modelos, entretanto, apresentam um foco interno ao projeto, não havendo neles processos ou práticas que, explicitamente, se voltem a identificar fatores do ambiente externo ao projeto que possam afetar o valor que virá a ser gerado para a organização.
Esse foco, conforme aumenta a complexidade dos projetos e a dependência das organizações com relação ao software, já não é suficiente. Na Seção 2.4 discutiu-se a evolução do gerenciamento de projetos, que passa a considerar programas e portfólios como forma de assegurar um melhor alinhamento entre os diversos projetos numa organização e destes com a estratégia de negócios.
Nesse mesmo sentido, a Seção 2.5 tratou do escritório de gerenciamento de projetos – EGP – como um instrumento para essa evolução, observando-se que, conforme cresce a preocupação com o efeito dos projetos sobre os negócios, evolui o papel dos EGP nos processos de governança.
O gerenciamento de projetos com base em seu valor para o negócio enfatiza e complementa essa evolução, trazendo os efeitos do projeto sobre os negócios para o centro das decisões.
3. V
ALOR PARA O
N
EGÓCIO EM
P
ROJETOS DE
S
OFTWARE
3.1. Introdução
Thorp (1999), ao analisar o problema da seleção de projetos nas organizações, destaca que atualmente existem múltiplas maneiras de se aplicar a tecnologia da informação em iniciativas de negócio e, como conseqüência, praticamente toda iniciativa de negócio envolve TI de alguma forma.
Enquanto toda iniciativa potencial oferece a possibilidade de algum benefício para a organização, lembra Thorp (1999), existem limites tanto nos recursos disponíveis para implementar os projetos quanto na capacidade da organização absorver as mudanças. As iniciativas envolvendo TI nas organizações hoje, em geral, superam largamente esses limites. Surge, então, um problema de decisão.
Além disso, ainda segundo Thorp (1999), dada a intensa competição e os grandes volumes investidos em projetos de TI, essa decisão pode envolver a própria sobrevivência da organização. Se forem propostos mais projetos do que se pode levar adiante, qual deve ser o critério de escolha?
O autor aponta um erro comum nas organizações ao tratar essa questão quando assumem que basta o projeto entregar o produto definido para que os benefícios surjam. Nos primeiros dias da TI, quando o foco estava na automação de processos manuais, os benefícios eram claros e facilmente mensuráveis, mas atualmente, com a evolução do uso da TI e sua fundamental importância em inúmeros aspectos de negócio, definir o valor de um projeto já não é simples.
