Versão inicial recebida em 15/11/2011. Versão final publicada em 10/1/2012.

Transcrição

1 RELATÓRIOS DE PESQUISA EM ENGENHARIA DE PRODUÇÃO v.12 n. 2, p FATORES CRÍTICOS DE SUCESSO PARA MONITORAMENTO E CONTROLE DE PROJETOS DE SOFTWARE COM EARNED VALUE MANAGEMENT Heitor Luiz Murat de Meirelles Quintella UFF - Universidade Federal Fluminense hquintel@uninet.com.br Isac Mendes Lacerda UFF - Universidade Federal Fluminense isac.mendes@gmail.com Resumo As atividades relacionadas a monitoramento e controle mantêm importante papel para o sucesso de um projeto. Prova desse reconhecimento é a significativa parcela dedicada ao assunto entre as principais abordagens de gerência de projetos. Levando isso em consideração, este estudo se propôs a identificar Fatores Críticos de Sucesso (FCS) no uso de Earned Value Management (EVM), como técnica de monitoramento e controle, para projetos de software. Deste modo, foram utilizados os seguintes referenciais teóricos: o método de FCS de Rockart (1979); os prognósticos do Ciclo de Vida do Produto (CVP) de Porter (1986); a técnica EVM; e modelos de processos de software (prescritivos e ágeis). A base metodológica utilizada foi o método hipotético-dedutivo de Popper (1975). Para a realização da pesquisa, foram coletados dados em três empresas multinacionais brasileiras que produzem software e usam conceitos de gerência de projetos. Os dados coletados foram tratados pelos métodos de Kolmogorov-Smirnov e Lógica Paraconsistente. A aplicação dos métodos permitiu a validação de seis FCS para uso de EVM em projetos de software, de sete fatores deduzidos dos prognósticos da fase de introdução do CVP de Porter (1986). Palavras chave: Earned Value Management; Fatores Críticos de Sucesso; Projetos de Software; Monitoramento e Controle. Abstract The activities related to monitoring and control play important role for projects success. Evidence of this is the significant portion dedicated to the subject among the main approaches of project management. Taking this into consideration, this study aimed to identify Critical Success Factors (CSF) in the use of Earned Value Management (EVM), as a technique of monitoring and control for software projects. Thus, the following theoretical references were used: the CSF method by Rockart (1979); the prognoses of Product Life Cycle (PLC) by Porter (1986); the EVM technique; and software process models (prescriptive and agile). The methodological basis used was the hypothetical-deductive method of Popper (1975). For the research development, data were collected in three Brazilian multinational companies that produce software and that use concepts of project management. The collected data were treated by the Kolmogorov- Smirnov and the Paraconsistent Logic methods. The application of the methods allowed for validation of six CSF for the use of EVM in software projects, from seven factors derived from the prognoses of the PLC introduction phase by Porter (1986). Key words: Earned Value Management; Critical Success Factors; Software Projects; Monitoring and Control. Versão inicial recebida em 15/11/2011. Versão final publicada em 10/1/2012.

2 1. Introdução É notável a relevância do software como recurso tecnológico e estratégico para as organizações atualmente. Os números da indústria de software, no Brasil e no mundo, confirmam a importância e a intensidade da produção desse recurso. Dados da consultoria International Data Corporation (IDC) em parceria com a Associação Brasileira das Empresas de Software (ABES) destacam que a produção de software e os serviços relacionados movimentaram U$ 884,5 bilhões de dólares em todo o mundo em 2010 (ABES, 2011). Dessa quantia, 40,6% foi resultado das atividades dos Estados Unidos, o líder mundial no setor. Enquanto isso, a participação do Brasil foi de 1,95%, ou seja, U$ 17,03 bilhões de dólares. A parcela brasileira, além de ter conferido ao país a décima primeira posição no ranking mundial, representou cerca de 1,00% do Produto Interno Bruto (PIB) no ano de Os especialistas reforçam a relevância, atribuindo grande valor ao software como recurso tecnológico. Pressman (2006) afirma que o software de computadores é uma das tecnologias mais importantes no palco mundial. Para CHOW e CAO (2008), o software é fundamental para todas as facetas do mundo moderno e, por isso, influencia de forma significativa toda a economia. Essa importância ecoa como um mar de oportunidades aos que desejam fazer negócios. No entanto, junto às oportunidades estão as dificuldades. Booch (2003) afirma que a expansão dos softwares (em tamanho, complexidade, distribuição e importância) pressiona o que os técnicos sabem fazer. Por consequência, a especialização requerida para os profissionais realizarem os trabalhos não acompanha a demanda. Com o intuito de superar as dificuldades e atender à demanda, construindo software de qualidade e em tempo hábil, os produtores têm experimentado diversos instrumentos durante as atividades de construção. A gerência de projetos tem sido apontada como um desses instrumentos. Kerzner (2006) afirma que atualmente a gerência de projetos é reconhecida por organizações em todo o mundo como arma competitiva que pode promover níveis crescentes de qualidade e valor aos interesses dos clientes. Segundo Srivannaboon (2006), os projetos e suas práticas são ferramentas que materializam os planos e metas estratégicas das organizações. Ao avaliar as principais abordagens de gerência de projetos, nota-se que boa parte de suas composições trata de monitoramento e controle. O PMBOK (2008), Project Management Body of Knowledge, apresenta 10 processos de monitoramento e controle de um total de 42 processos propostos. O APMBOK (2000), Association of Project Management Body of Knowledge, insere planejamento, medição, monitoramento e ações corretivas em um grande ciclo de controle. Levando em consideração que muitos dos problemas em projetos, de software ou não, referem-se a monitoramento e controle, é fácil entender a razão das significantes parcelas dedicadas a monitoramento e controle das abordagens de gerência de projetos. Carpes Jones (2006) destaca que entre as principais causas de problemas em projetos de software estão: estimativas inadequadas; relato de status inadequado; ausência de dados históricos de projetos similares; e processos de controle de qualidade inadequados. Miranda e Bourque (2010) afirmam que o monitoramento é função básica na execução de qualquer projeto, pois serve para alertar possíveis problemas antes que eles se tornem irreversíveis. Para Rozenes et al. (2006), o controle é uma questão importante durante todo o ciclo de vida do projeto, pois a execução de acordo com o planejado depende de uma metodologia de controle. Segundo Avison et al. (2001), o desempenho de um projeto pode ser significativamente melhorado se mais atenção for dada a monitoramento e controle. Entre as opções para monitoramento e controle de um projeto está a técnica Earned Value Management (EVM), que é bastante utilizada nos Estados Unidos, mas pouco no Brasil (VARGAS, 2002). EVM além de ser apontada como uma ferramenta poderosa que suporta o gerenciamento integrado do escopo, prazo e custo, também é apontada como técnica capaz de permitir avaliação de tendências que contribuem para a tomada de decisão quando ainda é possível corrigir desvios (ANBARI, 2003). Segundo Fleming e Koppelman (2006), EVM 10

3 promove a integração da tripla restrição (escopo, prazo e custo) e pode ser empregada em projetos e indústrias de qualquer tipo e tamanho. A capacidade de integrar três elementos de naturezas distintas é a atração central de EVM, pois tal característica dinamiza a análise de desempenho de um projeto (LACERDA, 2009; QUINTELLA e LACERDA, 2011). Desta maneira, este artigo apresenta um estudo de FCS no uso de EVM para projetos de software, feito em grandes empresas brasileiras. A seguinte estrutura foi assumida, para organizar o artigo: a seção 2 destaca os referenciais teóricos utilizados; a seção 3 destaca a metodologia de pesquisa; a seção 4 apresenta a análise e discussão dos resultados obtidos; por último, a seção 5 apresenta as conclusões e recomendações do trabalho. 2. Referenciais Teóricos Os referenciais teóricos utilizados foram: o método de FCS de Rockart (1979); o CVP de Porter (1986); a técnica EVM para monitoramento e controle de projetos; e modelos de processos de software (duas abordagens prescritivas e duas ágeis). Dos quais, os dois primeiros foram utilizados para estruturação do problema e da solução provisória, o terceiro como objeto de estudo e o quarto como fundo conceitual, destacando o tipo de influência que os projetos de software têm sofrido Referencial 1 - Fatores Críticos de Sucesso (FCS) Em 1979, John F. Rockart, na ocasião pesquisador do Massachusetts Institute of Technology (MIT), apresentou um método para determinar as informações necessárias para gestores corporativos. O método foi descrito no artigo Chief Executives Define Their Own Data Needs, publicado na Harvard Business Review (ROCKART, 1979). A abordagem de Rockart foi denominada como o método dos FCS. Essa publicação popularizou e estendeu o conceito de fatores críticos que já havia sido discutido por Ronald Daniel em 1961 no artigo Management Information Crisis, também publicado na Harvard Business Review (DANIEL, 1961). Entretanto, foi a partir do artigo de Rockart que uma série de publicações sobre FCS foi desencadeada e um número crescente de organizações passou a adotar o método (ROCHA, 2005). FCS podem ser definidos como um número limitado de áreas que, se tiverem resultados satisfatórios, irão assegurar desempenho competitivo e de sucesso para a organização (ROCKART, 1979). Em outras palavras, FCS são poucas áreas-chave do negócio de uma empresa onde as coisas precisam dar certo para que o negócio prospere. Como consequência, os FCS exigem uma atenção permanente e cuidadosa dos gestores. De forma simplificada, a identificação dos FCS sugerida por Rockart pode ser realizada em pelo menos duas sessões separadas de entrevistas junto aos gestores de uma organização: Na 1ª sessão, os objetivos da organização e os FCS (para cada um dos objetivos) são registrados e discutidos. Na 2ª sessão, os resultados da primeira são revisados e se necessário atualizados, buscando sempre o consenso entre os gestores. Para Rockart (1979), o método dos FCS pode ser aplicado com três principais objetivos: Ajudar os gestores corporativos na definição das informações relevantes em seus processos de tomada de decisão; Contribuir para o processo de planejamento estratégico da empresa; Contribuir no processo de construção de sistemas de informação mais adequados. Rockart (1979) destaca também que bons gestores têm implicitamente os FCS identificados. Entretanto, o método dos FCS é útil, pois torna explícito os pontos que requerem maior atenção. Deste modo, mesmo os bons gestores não correm o risco de esquecer onde devem concentrar os esforços. 11

4 Desta maneira, esta pesquisa assume como verdadeira a validade da abordagem de Rockart para a identificação de FCS no uso de EVM em projetos de software Referencial 2 - Ciclo de Vida do Produto (CVP) Porter (1986) apresenta uma técnica chamada de Ciclo de Vida do Produto (CVP) como forma de avaliar a evolução tanto de um produto específico como de uma indústria. Esse conceito assume que um produto atravessa quatro fases ao longo de sua existência: Introdução; Crescimento; Maturidade; e Declínio. A fase de Introdução é caracterizada pela dificuldade de superar a inércia do comprador para experimentar o produto lançado. A fase de Crescimento é caracterizada pela precipitação dos compradores quando descobrem que o produto provou seu sucesso. A fase de Maturidade é caracterizada pela penetração dos compradores em potencial do produto, diminuindo o crescimento e com tendência mais estável dos compradores. A fase de Declínio é caracterizada pela aparição de novos produtos que diminuem as chances de aquisição do produto original. Para cada uma das fases, a partir de aspectos significativos para as indústrias, Porter (1986) apresenta um conjunto de prognósticos genéricos. O quadro 1 destaca os aspectos e prognósticos da fase de Introdução, que foram utilizados como fonte de FCS neste trabalho e compõem a hipótese da pesquisa, conforme trata a seção da metodologia. Aspectos 1) Compradores e comportamento do comprador 2) Produtos e mudança no produto Prognósticos da Introdução - Comprador de alta renda; - Inércia do comprador; - Compradores devem ser convencidos a testar o produto. - Qualidade inferior; - Projeto do produto é chave para o desenvolvimento; - Muitas variações diferentes do produto (sem padronização); - Freqüentes mudanças no projeto. - Freqüentes mudanças do produto. 3) Marketing - Publicidade/Vendas muito altas; - Melhor estratégia de preços; - Altos custos de marketing. 4) Fabricação e distribuição - Supercapacidade; - Tandas de produção curtas; - Alto conteúdo de mão-de-obra especializada; - Altos custos de produção; - Canais especializados. 5) Pesquisa e desenvolvimento - Técnicas de produção mutáveis. (P&D) 6) Comércio exterior - Algumas exportações. 7) Estratégia global - Melhor período para aumentar parcela de mercado; - P&D e engenharia são funções básicas. 8) Concorrência - Poucas companhias. 9) Risco - Alto risco. 10) Margens e lucros - Margens e preços altos; - Lucros baixos; - Elasticidade-preços para vendedor individual não é tão grande como na maturidade Quadro 1 Prognósticos do CVP 12

5 2.3. Referencial 3 - Earned Value Management (EVM) O terceiro referencial teórico é a técnica de monitoramento e controle EVM. Esse conceito surgiu a mais de 100 anos entre engenheiros norte americanos, com o propósito de confrontar padrões planejados de trabalho, padrões realizados de trabalho e custos realizados. Mas foi a partir da década de 60 que EVM ganhou sua primeira publicação formal, conduzida por uma experiência bem sucedida em um projeto da força aérea norte-americana. Da década de 60 à década de 90 o uso de EVM praticamente se limitou a projetos do governo dos Estados Unidos. Nesse período, as empresas privadas apresentaram pouco interesse pelo uso de EVM, atribuindo excesso de burocracia a esta abordagem. No entanto, ainda na década de 90, foi publicado um padrão sobre o assunto na American National Standard Institute/Electronic Industry Association (ANSI/EIA) sob o código ANSI/EIA Essa publicação, por trazer simplificações na terminologia e critérios de aplicação, foi bem recebida pela iniciativa privada que desde então tem adotado e reconhecido os benefícios de sua utilização (FLEMING; KOPPELMAN, 1998 e KIM et al., 2003). Para Warburton (2011), o ponto chave de EVM é a conversão de unidades físicas mensuráveis do projeto (ex. marcos/entregas principais) em unidades financeiras. Vargas (2004a) define EVM como a avaliação entre o que foi obtido em relação ao que foi realmente gasto e ao que se planejava gastar, onde se propõe que o valor a ser agregado inicialmente para uma atividade é o valor orçado para ela. Em outras palavras, ao completar um pacote de atividades, o valor orçado para esse pacote passa a ser valor agregado ou Earned Value (EV) no projeto (LACERDA, 2009). Anbari (2003) afirma que por essas características EVM suporta uma gestão integrada do escopo, prazo e custo dos projetos. Os componentes básicos de EVM são Planned Value (PV), Earned Value (EV), Actual Cost (AC) e Budget At Complete (BAC), indicados no quadro 2. Componente Planned Value (PV) Earned Value (EV) Actual Cost (AC) Budget At Complete (BAC) Descrição É o custo orçado para o trabalho planejado até uma data de medição do projeto É o valor orçado atribuído ao trabalho concluído de uma atividade até uma data de medição do projeto. EV também pode ser denominado como o valor monetário atribuído ao trabalho pronto. É o custo real das atividades até uma data de medição do projeto. Representa o orçamento total e também o último ponto da linha de base de custos. Quadro 2 Componentes Básicos EVM A partir dos componentes básicos de EVM, é possível avaliar variações e índices de desempenho de prazo e custo, indicados nos quadros 3 e 4 respectivamente. Variação Cost Variance (CV) Scheduled Variance (SV) Time Variance (TV) Descrição É definida pela diferença entre Earned Value (EV) e Actual Cost (AC) em uma data de medição do projeto. Assim: CV = EV AC. É definida pela diferença entre Earned Value (EV) e Planned Value (PV) em uma data de medição do projeto. SV é uma forma de se referir ao atraso ou à antecipação do projeto em uma linguagem monetária. Assim: SV = EV PV. É definida pela diferença de tempo entre o momento em que Earned Value (EV) foi medido e o momento em que deveria ter sido alcançado quando comparado ao Planned Value (PV). Quadro 3 Variações EVM 13

6 Índice Schedule Performance Index (SPI) Cost Performance Index (CPI) Descrição Índice que sinaliza o percentual de realização do projeto comparado ao que estava previsto em uma data de medição. O SPI é determinado pela divisão do Earned Value (EV) pelo Planned Value (PV). Assim: SPI = EV / PV. Índice que sinaliza o percentual de eficiência dos gastos do projeto em uma data de medição. O CPI é a divisão de Earned Value (EV) pelo Actual Cost (AC). Assim: CPI = EV / AC. Quadro 4 Índices EVM A figura 1 apresenta a situação de um projeto hipotético de três meses de duração, indicando os componentes básicos (EV, PV, AC e BAC) e as variações de prazo e custo (SV, CV e TV). Neste exemplo, é possível verificar que o projeto está atrasado e com ineficiência de gastos, ao final do primeiro mês. Essa conclusão pode ser obtida calculando SV e CV ou SPI e CPI, de acordo com os quadros 3 e Referencial 4 - Processos de software Figura 1 Exemplo EVM De forma geral, processo pode ser definido como um conjunto de passos necessários com propósitos específicos que ao serem executados permitirão alcançar um objetivo. No contexto de software, Pressman (2006) define processo como um arcabouço de tarefas que são necessárias para construir software de qualidade. Em outras palavras, um roteiro que ajuda a criar a tempo um resultado de qualidade. Pressman destaca também que processos de software formam a base para o controle gerencial de projetos de software e servem para estabelecer o contexto no qual os métodos técnicos são aplicados, os produtos de trabalho são produzidos, os marcos são estabelecidos, a qualidade é assegurada e as modificações gerenciadas. Deste modo, processos têm grande influência sobre a maneira de gerenciar os projetos de software. Atualmente, os processos de software têm sido classificados como prescritivos ou ágeis. Os processos prescritivos são conhecidos pela disciplina e padronização de um conjunto de elementos como atividades, ações de engenharia de software, modelos, mecanismos de garantia de qualidade e controle de modificações (PRESSMAN, 2006). Enquanto isso, os processos ágeis são conhecidos por ideias que valorizam mais indivíduos e interações do que processos e ferramentas, assim como software funcionando mais do que documentação abrangente, colaboração ativa do cliente mais do que rigidez contratual e respostas rápidas às modificações mais do que um plano engessado (AGILE ALLIANCE, 2010). 14

7 Entre os processos prescritivos de software mais conhecidos está o Processo Unificado (PU), criado por Ivar Jacobson, Grady Booch e James Rumbaugh (JACOBSON et al., 1999). Os criadores do PU afirmam que o processo é sustentado por três princípios: é dirigido por casos de uso; é centrado na arquitetura; e é iterativo e incremental. Além disso, sua organização inclui fases, marcos e papéis definidos. Outro processo prescritivo é o Processo para Aplicativos extensíveis InterativoS (PRAXIS), criado pelo professor Wilson de Pádua Paula Filho (PAULA FILHO, 2005). O PRAXIS é muito semelhante ao PU, no entanto, o autor afirma que não há concorrência entre o dois processos. Em sua avaliação, o PRAXIS pode ser utilizado como base de aprendizado para o PU, podendo ser aplicado em projetos de seis meses a um ano de duração (individualmente ou por pequenas equipes) e ou com fins didáticos em disciplinas de engenharia de software. O PRAXIS propõe fases e marcos muito semelhantes aos do PU, no entanto, trabalha com um número menor de disciplinas e sugere um número definido de iterações para algumas de suas fases. Além disso, algumas iterações têm propósitos definidos, tornando o processo mais prescritivo que o PU nesse aspecto. Entre os processos ágeis mais conhecidos estão o extreme Programming (XP) e o SCRUM. O XP é um processo ágil que teve sua primeira publicação em 1999, embora suas ideias existam desde os anos 80 (BECK, 1999). Entre as principais práticas do XP, destacam-se: a denominação dos requisitos de software de estórias de usuário; atribuição de valor relativo de importância para cada estória de usuário; decomposição das estórias de usuário de modo que a estimativa de cada uma não supere três semanas de trabalho; limitação do esforço sempre ao escopo das estórias de usuário; aplicação da abordagem orientada a objetos através de cartões CRCs (class responsability colaborator); testes unitários antes da implementação, baseados nas estórias de usuário; programação em pares; e flexibilidade na aceitação de novas estórias de usuário, alterando assim planos de versões remanescentes. Já o SCRUM foi desenvolvido por Jeff Sutherland nos anos 90 e expandido em 2001 por Ken Schwaber e Mike Beedle (SCHWABER e BEEDLE, 2002). Embora, esteja se difundindo muito em projetos de software, o SCRUM é um processo aplicável para o desenvolvimento de qualquer produto (ADM, 2010). Entre as principais práticas no SCRUM, destacam-se: a criação de uma lista de requisitos, denominada de product backlog; definição de intervalos de tempo, normalmente de 15 a 30 dias, denominados de SPRINTs, com objetivo de entregar incrementos de software; reuniões diárias de 15 minutos, pautadas no que foi feito desde a última reunião, o que está planejado para fazer até a próxima reunião e quais os impedimentos momentâneos; e reuniões de demonstração e avaliação ao final de cada SPRINT. Esses quatro processos, brevemente descritos, apresentam uma pequena amostra das influências que os projetos de software têm experimentado. Isso demonstra que a escolha de um processo tem grande relação com a maneira de gerenciar os projetos, incluindo os esforços de monitoramento e controle. Exatamente por isso, o tema processos de software cumpriu o papel de fundo conceitual, sendo um dos referenciais teóricos do trabalho. 3. Metodologia 3.1. Método de abordagem Neste trabalho foi utilizado o método hipotético-dedutivo de Popper (1975). Com o método, entende-se que toda discussão científica começa a partir de um problema de pesquisa, definido como uma lacuna em teorias ou em conhecimentos prévios. Deste modo, dado um problema, uma teoria tentativa deve ser formulada como solução provisória, comumente chamada de hipótese. Por sua vez, a hipótese deve ser submetida a testes, podendo ser refutada ou corroborada. Com isso, Popper (1975) afirma que esse processo tem o poder de renovar a si mesmo que acaba originando novos problemas que promovem novas oportunidades de pesquisa. A partir dessa abordagem, a situação-problema e a hipótese da pesquisa foram formuladas, conforme descrevem as seções seguintes. 15

8 3.2. Formulação da situação-problema e questão da pesquisa A competitividade dos negócios que envolvem software pressiona as organizações para o uso cada vez mais eficiente dos recursos. Considerando que para fazer uso eficiente dos recursos em projetos de software é necessário possuir mecanismos adequados de monitoramento e controle, viu-se a necessidade de estudar a técnica EVM como opção para esse tipo de projeto. Vale destacar que na ocasião da realização da revisão bibliográfica deste trabalho não foram encontrados estudos específicos de FCS para o uso de EVM em projetos de software, embora tenham sido encontrados vários trabalhos sugerindo a aplicação de EVM para projetos de software (HANNA, 2009; RUSK, 2009; LI et al., 2008; LIPKE, 2008; CABRI e GRIFFITHS, 2006; SULAIMAN et al., 2006; TUMA e DAVID, 2005; PRACCHIA, 2004; LIPKE, 2002; SOLOMON, 2002; STALEY et al., 2002; SOLOMON, 2001; LIPKE e JENNINGS, 2000; FLEMING e KOPPELMAN, 1998; CHRISTENSEN e FERENS, 1995). Tais abordagens, no entanto, não sistematizam a identificação e validação de FCS no uso de EVM para o contexto de produção de software brasileiro, o que reforçou a necessidade do presente estudo. Com isso, o problema da pesquisa foi definido através da seguinte pergunta: Quais são os Fatores Críticos de Sucesso (FCS) no uso de EVM em projetos de software? 3.3. Premissas A pesquisa assumiu as seguintes premissas, para efeito de planejamento e execução: O conceito de FCS apresentado por Rockart (1979) é um instrumento empírico válido para identificação de pontos mais importantes no planejamento empresarial; O modelo de Ciclo de Vida do Produto (CVP) de Porter (1986) e seus prognósticos são aplicáveis ao universo brasileiro de produção de software e serve como fonte de FCS no uso de EVM Hipótese e questões da pesquisa Como resposta provisória ao problema da pesquisa, foi elaborada a seguinte hipótese: Os Fatores Críticos de Sucesso (FCS) no uso de EVM, para projetos de software, extraídos dos prognósticos da fase de introdução do Ciclo de Vida do Produto (CVP), apresentados por Porter, são válidos para a amostra da pesquisa. Os aspectos e prognósticos do CVP de Porter foram utilizados como ponto de partida para a identificação de FCS, pois representam um importante instrumento de gestão para avaliar genericamente a entrada de um produto em operação. Nesse sentido, os aspectos e prognósticos foram utilizados para deduzir os FCS no uso de EVM (que representa o produto a entrar em operação no contexto organizacional de produção de software). Assim, embora Porter apresente dez aspectos e vinte e cinco prognósticos para a fase de Introdução, conforme quadro 5, foram considerados aplicáveis aos projetos de software apenas os prognósticos de cinco aspectos dessa fase: (1) Compradores e comportamento do comprador (compradores devem ser convencidos a testar o produto); (2) Produtos e mudança no produto (sem padronização); (3) Marketing (publicidade/vendas); (4) Fabricação e Distribuição (canal especializado); e (9) Riscos (alto risco). O Quadro 5 apresenta os prognósticos utilizados, os FCS deduzidos (apresentados como questões-chave) e as considerações de dedução aplicadas. 16

9 Prognóstico Questão-Chave Consideração de Dedução Compradores Questão 1: É um FCS ter patrocínio gerencial no devem ser processo de implementação de EVM convencidos a (Abordagem TOP DOWN)? testar o produto comprometimento. Sem padronização Publicidade / Vendas Canal especializado Canal especializado Alto Risco Alto Risco Questão 2: É um FCS definir uma metodologia de uso de EVM que considere a natureza intangível e a dificuldade de definição prematura de escopo em proj. de software? Questão 3: É um FCS definir um programa de comunicação que esclareça o propósito e as utilidades do uso de EVM? Questão 4: É um FCS treinar toda a força de trabalho envolvida com o uso de EVM? Questão 5: É um FCS manter uma estrutura de suporte (como Escritório de Projetos - EP) aos usuários no uso de EVM? Questão 6: É um FCS não usar EVM como instrumento de punições ou demissões? Questão 7: É um FCS que os Gerentes de Projetos (GPs) sejam encorajados a relatar o desempenho verdadeiro e só o verdadeiro? Quadro 5 Questões-Chave Com patrocínio gerencial os recursos serão mais facilmente disponibilizados. Além disso, estando os usuários de EVM conscientes de que sua utilização faz parte de objetivos gerenciais, haverá maior Definir o roteiro de uso da técnica, quais informações usar, templates, softwares e processos, considerando as características de projetos de software, servirá de amparo para os usuários. Tornar conhecido o objetivo de uso da técnica e seus benefícios gerará comprometimento entre os usuários. Contribuir para que os usuários tomem posse e dominem os instrumentos/conceitos de trabalho aumentará a chance de uso correto. Manter uma estrutura com profissionais experientes para apoiar os usuários iniciantes minimizará equívocos no uso da técnica. Caso os usuários interpretem o uso da técnica como instrumento de punições, a confiabilidade das informações poderá ser comprometida. Se os GPs forem estimulados a relatar informações corretas, a organização entrará em um ciclo virtuoso de aprendizado e aprimoramento Universo e amostra O universo da pesquisa foi descrito como: empresas de grande porte instaladas no Brasil (multinacionais de origem brasileira), que desenvolvem software e utilizam gerência de projetos como instrumento para atingir seus objetivos de negócio. A amostra, por sua vez, está caracterizada como não-probabilística, pois seus elementos foram selecionados pela facilidade de acesso e julgamento dos pesquisadores. Deste modo, a amostra foi composta por dados coletados em três empresas multinacionais que mantinham atividades no estado do Rio de Janeiro, no sudeste brasileiro. Vale destacar que duas das empresas são do segmento de tecnologia da informação (TI) e uma do segmento de energia. As duas empresas do segmento de TI (na ocasião da pesquisa) tinham juntas cerca de empregados, o que representava aproximadamente 11% de todos os profissionais das 820 empresas da Associação Brasileira das Empresas de Software (ABES, 2010). Quanto ao faturamento, as duas empresas de TI somaram 12% de todo o faturamento da ABES, considerando o dólar a taxa de R$ 2,00 (ABES, 2010). A terceira empresa, mesmo não sendo do segmento de TI, mantinha uma relevante contribuição na economia do Brasil e uma área de TI significativa, com mais de profissionais só nesse departamento Coleta de dados A coleta dos dados foi feita através de um questionário de campo, composto por quatro questões. A primeira dessas questões foi elaborada com a finalidade de desenvolver percepção de importância entre os sete FCS extraídos dos prognósticos de Porter. A segunda questão foi elaborada com a finalidade de identificar rejeições entre os FCS sugeridos. Deste modo, considerou-se como não-crítico o fator rejeitado 30% ou mais pelos respondentes, faixa utilizada em outros estudos de validação de FCS (QUINTELLA e ROCHA, 2005; TOLEDO, 2000; SIQUARA, 2003). A terceira questão foi elaborada com a finalidade de identificar fatores complementares aos FCS extraídos dos prognósticos de Porter, minimizando influências das 17

10 questões fechadas. A quarta questão foi elaborada com a finalidade de identificar o grau de concordância do respondente quanto à importância do FCS e revelar eventuais incoerências com as respostas dadas à primeira questão. Foi preparada uma versão web do questionário de campo e enviado um aos respondentes com a explicação do propósito, o caráter acadêmico da pesquisa e o link para o preenchimento Tratamento e análise dos dados Os dados das questões 1 e 4 foram tratados através do método de Kolmogorov-Smirnov, recomendado quando a informação coletada é de natureza ordinal, condição dos dados dessas questões (MATTAR, 1996). Além disso, Mattar (1996) afirma que o método de Kolmogorov- Smirnov tem aplicação simplificada e seus resultados são estatisticamente significativos, não requerendo frequências mínimas. Considerando o formato da questão 4, onde foi avaliado o grau de concordância sobre os FCS, seus dados foram tratados também através da Lógica Paraconsistente, método utilizado para manipular conceitos de incerteza e inconsistência logicamente (AGUIAR, 2006; BISPO e CAZARINI, 2006) Limitações dos métodos Algumas limitações dos métodos incluem a possibilidade de distorções nos dados por influência do grau de motivação do respondente, falta de conhecimento sobre o assunto e eventual inadequação do questionário. Além disso, existe a possibilidade dos respondentes terem aumentado a pontuação das questões de forma a não terem transmitido avaliação ruim dos processos de gerência de projetos de suas empresas, mesmo sabendo que a pesquisa não tinha propósito de selecionar empresas ou pessoas. 4. Análise e discussão dos resultados 4.1. Tabulação dos dados A tabulação dos dados envolveu os seguintes passos: Contagem de frequência de cada FCS selecionado em cada par de vinte e uma combinações da primeira questão (sete fatores combinados em pares); Contagem de frequência de rejeição de cada FCS da segunda questão; Consolidação dos novos fatores apontados pelos respondentes como críticos da terceira questão, não incluídos entre os sete FCS extraídos dos prognósticos; Contagem de frequência da pontuação atribuída a cada FCS usando a escala de 1 discordo totalmente até 5 concordo totalmente da quarta questão. Na primeira questão, de modo a desenvolver percepção de ordem, os sete FCS foram combinados em vinte e um pares, onde o respondente pôde escolher (em cada par) o de maior importância, de acordo com seu entendimento. A tabela 1 indica a quantidade e percentual de respostas obtidas por FCS (total e por empresa componente da amostra). A última linha da tabela indica a pontuação máxima que cada FCS poderia ter alcançado. Na Empresa AB, por exemplo, cada FCS poderia atingir no máximo 60 pontos, pois o limite foi o número de respondentes (dez pessoas) multiplicado pelo número de pares possíveis para cada FCS. 18

11 Empresa AB (respondentes 10) CD (respondentes 10) EF (respondentes 34) Total (respondentes 54) FCS Pontos % Pontos % Pontos % Pontos % 7. Encorajar os GPs a relatar o 35 58, , , ,81 desempenho verdadeiro 5. Manter uma estrutura de 38 63, , , ,63 suporte como EP 2. Definir metod. de EVM p/ 28 46, , , ,40 projetos de software 4. Treinar a força envolvida 29 48, , , ,69 3. Definir prog. comunicação 35 58, , , ,37 6. Não usar EVM para punições 23 38, , , ,52 1. Ter patrocínio gerencial 22 36, , , ,58 Pontuação máxima % % % % Fonte: Elaboração Própria Tabela 1: Tabulação Questão 1 Na segunda questão, com o propósito de identificar rejeições, os sete FCS extraídos dos prognósticos de Porter, foram listados e os respondentes puderam indicar quais deles não deveriam ser considerados críticos. A tabela 2 indica as quantidades e os percentuais de rejeição de cada fator. A pontuação máxima foi o número de respondentes. Empresa AB (respondentes 10) CD (respondentes 10) EF (respondentes 34) Total (respondentes 54) FCS Pontos % Pontos % Pontos % Pontos % 1. Ter patrocínio gerencial 0 0, ,00 1 2,94 2 3,70 2. Definir metod. de EVM p/ 1 10,00 0 0,00 1 2,94 2 3,70 projetos de software 3. Definir prog.comunicação 0 0, ,00 2 5,88 3 5,56 4. Treinar a força envolvida 1 10, ,00 0 0,00 3 5,56 5. Manter uma estrutura de 0 0,00 0 0,00 2 5,88 2 3,70 suporte como EP 6. Não usar EVM para punições 2 20, , , ,78 7. Encorajar os GPs a relatar o 2 20, ,00 2 5,88 5 9,26 desempenho verdadeiro Pontuação máxima % % % % Fonte: Elaboração Própria Tabela 2: Tabulação Questão 2 Na terceira questão, a tabulação dos dados indicou dezesseis sugestões de novos FCS. No entanto, treze deles apresentaram apenas diferenças na redação ou já estavam implícitos nos sete FCS extraídos dos prognósticos de Porter. Deste modo, as sugestões das empresas se limitaram a três fatores: Implantação gradual de EVM; Uma avaliação para identificar se após algum tempo de uso, EVM está trazendo benefício claro e auxiliando no gerenciamento dos projetos de software; Ter pessoas competentes, motivadas e comprometidas (só treinamento não basta). Na quarta questão, com o propósito de avaliar o grau de concordância, foram feitas afirmações sobre os sete FCS e os respondentes puderam informar o quanto concordavam, através de uma escala variando de discordo totalmente (contabilizando 1 ponto) até concordo totalmente (contabilizando 5 pontos). A tabela 3 indica os resultados obtidos para cada uma das empresas da amostra. A pontuação máxima que cada FCS poderia obter foi a multiplicação entre 5, última opção da escala de respostas, pelo o número total de respondentes. 19

12 Empresa AB (respondentes 10) CD (respondentes 10) EF (respondentes 34) Total (respondentes 54) FCS Pontos % Pontos % Pontos % Pontos % 1. Ter patrocínio gerencial 49 98, , , ,59 2. Definir metod. de EVM p/ 46 92, , , ,48 projetos de software 3. Definir um programa de , , , ,26 comunicação 0 4. Treinar a força envolvida 46 92, , , ,30 5. Manter uma estrutura de , , , ,04 suporte como EP 0 6. Não usar EVM para punições 47 94, , , ,33 7. Encorajar os GPs a relatar o 47 94, , , ,48 desempenho verdadeiro Pontuação máxima % % % % Fonte: Elaboração Própria Tabela 3: Tabulação Questão Métodos de análise Os dados tabulados da primeira e da quarta questão foram submetidos ao teste de Kolmogorov- Smirnov, que permitiu a ordenação dos FCS e também a avaliação de significância das diferenças entre as pontuações obtidas. As tabelas 4 e 5 indicam respectivamente os resultados da primeira e da quarta questão de forma global (as três empresas da amostra juntas). As células destacadas em cinza são as maiores diferenças entre pontuação real e teórica (D=0,065, tabela 4 e D=0,011, tabela 5). Nos dois casos, as diferenças não superaram os respectivos valores tabulados pelo método, considerando o grau de significância (α=0,20) e a amostra de 54 elementos. Deste modo, atribui-se que as diferenças são estatisticamente não-significativas e ao acaso. Vale destacar que o método de Kolmogorov-Smirnov foi aplicado aos resultados das três empresas da amostra separadamente, no entanto, as diferenças em todos os casos também foram não-significativas. FCS Pontuação Absoluta Pontuação Relativa Pontuação Relativa Acumulada (real) Pontuação Relativa Teórica Pontuação Relativa Acumulada (teórica) Diferença (D) entre pontuação real e teórica 7. Encorajar os GPs a relatar 210 0,185 0,185 0,143 0,143 0,042 o desempenho verdadeiro 5. Manter uma estrutura de 177 0,156 0,341 0,143 0,286 0,056 suporte como EP 2. Definir metod. de EVM p/ 173 0,153 0,494 0,143 0,429 0,065 projetos de software 4. Treinar a força envolvida 161 0,142 0,636 0,143 0,571 0, Definir prog ,130 0,765 0,143 0,714 0,051 comunicação 6. Não usar EVM p/ 141 0,124 0,890 0,143 0,857 0,033 punições 1. Ter patrocínio gerencial 125 0,110 1,000 0,143 1,000 0,000 Total de Pontos ,000-1, Fonte: Elaboração Própria Tabela 4 Kolmogorov-Smirnov (Questão 1) 20

13 FCS Pontuação Absoluta Pontuação Relativa Pontuação Relativa Acumulada (real) Pontuação Relativa Teórica Pontuação Relativa Acumulada (teórica) Diferença (D) entre pontuação real e teórica 1. Ter patrocínio gerencial 250 0,149 0,149 0,143 0,143 0, Definir metod. de EVM 247 0,147 0,296 0,143 0,286 0,010 p/ projetos de software 7. Encorajar os GPs a relatar o desempenho verdadeiro 247 0,147 1,000 0,143 1,000 0, Definir prog ,144 0,440 0,143 0,429 0,011 comunicação 5. Manter uma estrutura de 235 0,140 0,719 0,143 0,714 0,004 suporte como EP 4. Treinar a força envolvida 233 0,139 0,579 0,143 0,571 0, Não usar EVM p/ 225 0,134 0,853 0,143 0,857-0,004 punições Total de Pontos ,000-1, Fonte: Elaboração Própria Tabela 5 Kolmogorov-Smirnov (Questão 4) Os dados da quarta questão, além do método de Kolmogorov-Smirnov, também foram tratados com a Lógica Paraconsistente. Nessa questão, para viabilizar a plotagem dos FCS no quadro unitário do plano cartesiano da Lógica Paraconsistente, foram atribuídos os pontos indicados para crença e descrença (quadro 6), a cada opção de escala selecionada. Considerando essa regra de pontuação, a tabela 6 consolida os dados por empresa e por FCS, apresentando os pontos obtidos, os pontos perdidos, o grau de crença (divisão do número de pontos obtidos pelo número de pontos possíveis) e o grau de descrença (divisão do número de pontos perdidos pelo número de pontos possíveis). Opções da Escala Questão Grau de Crença Grau de Descrença 4 1 Discordo Totalmente 0,00 1,00 2 Discordo Parcialmente 0,25 0,75 3 Não Discordo Nem 0,50 0,50 Concordo 4 Concordo Parcialmente 0,75 0,25 5 Concordo Totalmente 1,00 0,00 Quadro 6 Critério Crença x Descrença (Questão 4) 21

14 Empresa AB Empresa CD Empresa EF Resultado Global FCS Grau Grau Grau Grau Pontos Grau Grau Pontos Pontos Grau Pontos Pontos Pontos Pontos Grau Pontos de de Descre de Perdidos de Descrença Obtidos Perdidos Descrença Obtidos Perdidos Obtidos Perdidos Descrença Obtidos Crença Crença nça Crença Crença 1. Ter patrocínio 0, 9,75 0,25 0,98 0,02 8,75 1,25 0,88 0,12 30,50 3,50 0,90 0,10 49,00 5,00 0,09 gerencial (F1) Definir uma metodologia de 0, EVM particular 9,00 1,00 0,90 0,10 8,75 1,25 0,88 0,12 30,50 3,50 0,90 0,10 48,25 5,75 0,11 89 p/ projetos de software (F2) 3. Definir um programa de 0, 10,00 0,00 1,00 0,00 8,75 1,25 0,88 0,12 28,00 6,00 0,82 0,18 46,75 7,25 0,13 comunicação 87 (F3) 4. Treinar toda a 0, força envolvida 9,00 1,00 0,90 0,10 6,75 3,25 0,68 0,32 29,00 5,00 0,85 0,15 44,75 9,25 0,17 83 (F4) 5. Manter uma estrutura de suporte como EP (F5) 6. Não usar EVM para punições (F6) 7. Encorajar os GPs a relatar o desempenho verdadeiro (F7) Pontos Possíveis 10,00 0,00 1,00 0,00 7,75 2,25 0,78 0,22 27,50 6,50 0,81 0,19 45,25 8,75 9,25 0,75 0,93 0,07 5,25 4,75 0,53 0,47 28,25 5,75 0,83 0,17 42,75 9,25 0,75 0,93 0,07 8,50 1,50 0,85 0,15 30,50 3,50 0,90 0,10 48,25 5, , 0 1 1,0 10 1,0 1, ,0 1, ,00 1,0 0 Tabela 6 Questão 4, Lógica Paraconsistente 11,2 5 0, 84 0, 79 0, 89 0,16 0,21 0,11 Os graus de crença e descrença do resultado global de cada um dos FCS (tabela 6) foram plotados no plano cartesiano da Lógica Paraconsistente na figura 2. O grau de crença é representado pelo eixo X e o grau de descrença é representado pelo eixo Y. Com a aplicação da técnica, todos os FCS foram plotados na região do gráfico definida como zona de verdade, triângulo da extremidade inferior direita na figura 2. Em outras palavras, todos os FCS foram considerados verdadeiros, através da Lógica Paraconsistente. 22

15 4.3. Análise dos resultados Figura 2 Questão 4, Lógica Paraconsistente Na primeira questão, a aplicação do teste de Kolmogorov-Smirnov indicou não haver diferença estatisticamente significativa entre os FCS, mesmo quando avaliados separadamente (por empresa). Embora seja possível ordenar os fatores, atribui-se às diferenças de pontuação entre eles ao acaso, de acordo com o método. Na segunda questão, a tabulação dos dados indicou que, de forma global (em todas as empresas juntas), nenhum dos FCS foi rejeitado acima do ponto de corte estabelecido de 30%. Entretanto, ao analisar os dados separadamente foi possível notar que 40% dos respondentes da empresa CD rejeitaram o FCS 4.Não usar EVM para punições (tabela 2). Nas empresas AB e EF o FCS mais rejeitado também foi 4.Não usar EVM para punições, no entanto, com índices menores que 30% (tabela 2). Na terceira questão, como indicado na seção anterior, de dezesseis sugestões de FCS, apenas três foram consideradas novas sugestões. Na quarta questão, a aplicação do teste de Kolmogorov-Smirnov não apontou diferença estatisticamente significativa entre os FCS, o que reforçou os resultados encontrados na primeira questão. Na quarta questão, a Lógica Paraconsistente também foi utilizada e apontou todos os FCS extraídos de Porter como verdadeiros, o que também serviu para reforçar os resultados das questões 1 e 4 com o teste de Kolmogorov-Smirnov. 23

16 5. Considerações finais e recomendações 5.1. Solução do problema e verificação da hipótese O problema da pesquisa foi apresentado através da seguinte pergunta: Quais são os Fatores Críticos de Sucesso no uso de EVM em projetos de software? Enquanto isso, a resposta provisória dada ao problema foi a seguinte hipótese: Os Fatores Críticos de Sucesso no uso de EVM, para projetos de software, extraídos dos prognósticos da fase de introdução do Ciclo de Vida do Produto, apresentados por Porter, são válidos para a amostra da pesquisa. Deste modo, a hipótese foi submetida a testes de falseabilidade. Foram aplicados o teste de Kolmogorov-Smirnov e a Lógica Paraconsistente, que permitiram responder as questões-chave da hipótese. Dos sete FCS deduzidos dos prognósticos de Porter apenas seis foram validados. Um deles foi rejeitado pela empresa CD com índice de 40% (valor superior ao ponto de corte estabelecido de 30%). Afirma-se então que a hipótese da pesquisa é parcialmente verdadeira e as seguites respostas às suas questões são formuladas: Questões-chave da hipótese: Questão 1: É um FCS ter patrocínio gerencial no processo de implementação de EVM? Resposta: Sim, pois foi validado por todas as empresas da amostra. Questão 2: É um FCS definir uma metodologia de uso de EVM que considere a natureza intangível e a dificuldade de definição prematura de escopo em projetos de software? Resposta: Sim, pois foi validado por todas as empresas da amostra. Questão 3: É um FCS definir um programa de comunicação que esclareça o propósito e as utilidades do uso de EVM? Resposta: Sim, pois foi validado por todas as empresas da amostra. Questão 4: É um FCS treinar toda a força de trabalho envolvida com o uso de EVM? Resposta: Sim, pois foi validado por todas as empresas da amostra. Questão 5: É um FCS manter uma estrutura de suporte (como Escritório de Projetos - EP) aos usuários no uso de EVM? Resposta: Sim, pois foi validado por todas as empresas da amostra. Questão 6: É um FCS não usar EVM como instrumento de punições ou demissões? Resposta: Não, pois foi rejeitado por uma das empresas da amostra (empresa CD). Questão 7: É um FCS que os Gerentes de Projetos (GPs) sejam encorajados a relatar o desempenho verdadeiro e só o verdadeiro? Resposta: Sim, pois foi validado por todas as empresas da amostra. Vale destacar que além dos seis FCS validados, foram feitas três novas sugestões por duas empresas da amostra. No entanto, essas sugestões não puderam ser consideradas como FCS no trabalho, pois não foram citadas por todas as três empresas pesquisadas. Para serem validadas, deveriam ter sido submetidas à avaliação das três empresas da amostra e aceitas por todas, em um ciclo complementar de entrevistas. Entretanto, não houve tempo nem novo acesso aos respondentes para esse trabalho Conclusões Com a verificação da hipótese e das questões-chave, conclui-se que: Em projetos de software, na amostra pesquisada, seis FCS extraídos dos prognósticos de Porter para o uso de EVM foram validados (de um total de sete); O fator rejeitado pela empresa CD 4.Não usar EVM para punições, com 40%, também foi o fator com maior índice de rejeição nas empresas AB e EF, mas, com índices abaixo do ponto de corte de 30%. Isso indica uma percepção de menor importância do fator em 24

17 detrimento dos outros. No entanto, é possível que a sua relevância não tenha ficado clara o suficiente aos respondentes, visto que se identifica na literatura a recomendação de cautela ao vincular EVM a programas de valorização profissional, especialmente em períodos de implantação (STRATTON, 2006 e VARGAS, 2004b). Entre os argumentos de cautela, destaca-se a potencial inibição e manipulação das informações de desempenho dos projetos, causada por medo a punições. Por sua vez, a eventual manipulação das informações nos projetos pode desacreditar a principal função de EVM como instrumento de monitoramento e controle. E por último, os prognósticos apresentados por Porter (1986) para a fase de introdução do CVP serviram como fonte de FCS para o uso de EVM em projetos de software Sugestões para estudos futuros Este trabalho não esgota o assunto sobre FCS no uso de EVM em projetos de software. Sabe-se que outros aspectos sobre o tema podem ser investigados e aprofundados. Entre as possibilidades estão: Como EVM pode se tornar mais aderente aos projetos de software, já que deve considerar a natureza intangível e a dificuldade de definição prematura de escopo desses projetos? Devem existir diferenças de abordagem no emprego de EVM quando se usa os chamados processos de software prescritivos ou ágeis? Métricas como Pontos de Função e Pontos de Caso de Uso influenciam a implantação de EVM em projetos software? Quais são essas influências? Programas de valorização profissional baseados nos conceitos de EVM promovem quais impactos em empresas de base tecnológica, especialmente de software? Quais são os fatores críticos de sucesso de um programa dessa natureza? 6. Referências bibliográficas ABES - Associação Brasileira das Empresas de Software. Mercado Brasileiro de Software: Panorama e Tendências Disponível em: < Acesso em Abril, ABES - Associação Brasileira das Empresas de Software. Mercado Brasileiro de Software: Panorama e Tendências Disponível em: < Acesso em Abril, ADM - Advanced Development Methods. Controlled-Chaos: Living on the Edge. Disponível em: < Acesso em Janeiro, AGILE ALLIANCE. Manifesto for agile software development. Disponível em < Acesso em Abril, AGUIAR, Ezequiel P. Fatores Críticos de Sucesso em Venda de Combustíveis no Mercado de Aviação Civil Doméstico e a Qualidade Percebida pelo Cliente f. Dissertação (Mestrado em Engenharia de Produção). Universidade Federal Fluminense, Niterói, ANBARI, Frank T. (2003). Earned Value Project Management: Method and Extensions. Project Management Journal, 34, APMBOK. Project Management Body of Knowledge. Association for Project Management. UK, AVISON, David; BASKERVILLE, Richard; MYERS, Michael (2001). Controlling Research Projects. Information Technology and People, 14, n.1, BECK, Kent (1999). Embrace Change with Extreme Programming. IEEE Computer Magazine, [S.1], p , October. 25

18 BISPO, Carlos A. F.; CAZARINI, Edson W. (2006). Avaliação Qualitativa Paraconsistente do Processo de Implantação de um Sistema de Gestão Ambiental. Gestão & Produção, 13, n.1, BOOCH, Grady. Melhores Práticas do Desenvolvimento de Software. In: KRUCHTEN, Philippe. Introdução ao RUP Rational Unified Process. Addison-Weley/Ciência Moderna, p.3-13, CABRI, Anthony; GRIFFITHS, Mike. (2006). Earned Value and Agile Reporting. In: PROCEEDINGS OF THE CONFERENCE ON AGILE 2006, p.17-22, 23-28, July. CHOW, Tsun; CAO Dac-Buu (2008). A Survey Study of Critical Success Factors in Agile Software Projects. The Journal of Systems and Software, 81, CHRISTENSEN, David S.; FERENS, Daniel (1995). Using Earned Value on Software Development Projects. Acquisition Review Quarterly, 2, DANIEL, Ronald. Management Information Crisis (1961). Harvard Business Review, Watertown, 6, FLEMING, Quentin W.; KOPPELMAN, Joel M. (1998). Earned Value Management: A Powerful Tool for Software Projects. CrossTalk: The Journal of Defense Software Engineering, July. FLEMING, Quentin W.; KOPPELMAN, Joel M. (2006). Start With Simple Earned Value On All Your Projects. CrossTalk: The Journal of Defense Software Engineering, June. HANNA, Robert A. (2009). Earned Value Management Software Projects. In: 3 th IEEE INTERNATIONAL CONFERENCE ON SPACE MISSION CHALLENGES FOR INFORMATION TECHNOLOGY. JACOBSON, Ivar; RUMBAUCH, James; BOOCH, Grady (1999). The Unified Process. IEEE Computer, 16, JONES, Carpes (2006). Social and Technical Reasons Software Project Failures. CrossTalk: The Journal of Defense Software Engineering, June. KERZNER, Harold. Gestão de Projetos: as melhores práticas; tradução Lene Belon Ribeiro. 2.ed. Porto Alegre: Bookman, KIM, EunHong.; WELLS JR., William G.; DUFFEY, Michael R. (2003). A model for effective implementation of Earned Value Management methodology. International Journal of Project Management, 21, n.5, LACERDA, Isac M. Fatores Críticos de Sucesso no Uso de Earned Value Management em Projetos de Desenvolvimento de Software e a Relação com a Qualidade Percebida. 2009, 207f. Dissertação (Mestrado em Sistemas de Gestão). Universidade Federal Fluminense, Niterói, LI, Jinhua; MA, Zhibing; DONG, Huanzhen (2008). Monitoring Software Projects With Earned Value Analysis and Use Case Point. In: PROCEEDINGS OF THE 7 th IEEE/ACIS INTERNATIONAL CONFERENCE ON COMPUTER AND INFORMATION SCIENCE, p , 14-16, May. LIPKE, Walter H. (2002). Earned Value Management Our Story. CrossTalk: The Journal of Defense Software Engineering. LIPKE, Walter H. (2008). The Use and Impact of Earned Value Management on Software Projects. The Measurable News. LIPKE, Walter H.; JENNINGS M. (2000). Software Project Planning, Statistics, and Earned Value. CrossTalk: The Journal of Defense Software Engineering, 13, MATTAR, Fauze. Pesquisa de Marketing. 2 volumes. Atlas. São Paulo, MIRANDA, Eduardo; BOURQUE, Pierre (2010). Agile Monitoring Using the Line of Balance. The Journal of Systems and Software, 83, PAULA FILHO, Wilson de (2005). A Model-driven Software Process for Course Projects. In: PROCEEDINGS OF EDUCATORS' SYMPOSIUM OF THE ACM / IEEE 8TH INTERNATIONAL CONFERENCE ON MODEL DRIVEN ENGINEERING LANGUAGES AND SYSTEMS, Montego Bay, Jamaica, Out. 26

19 PMBOK. A Guide to the Project Management Body of Knowledge. 4 nd. Project Management Institute Newton Square, POPPER, Karl. A lógica da pesquisa científica. Editora Cultrix. São Paulo, PORTER, Michael E. Estratégia Competitiva Técnicas para Análise de Indústrias e da Concorrência. 16a. Edição. Rio de Janeiro: Campus, PRACCHIA, Lisa (2004). The AV-8B Team Learns Synergy of EVM and TSP Accelerates Software Process Improvement. CrossTalk: The Journal of Defense Software Engineering, 17, PRESSMAN, Roger S. Engenharia de Software. 6 nd. Mc Graw Hill São Paulo, QUINTELLA, Heitor L. M. de M.; LACERDA, Isac M. (2011). Earned Value Management em Projetos Ágeis de Software: Abordagens de Aplicação. Relatório de Pesquisa em Engenharia de Produção, v.11, n.9. QUINTELLA, Heitor L. M. de M.; ROCHA, Henrique M.; ALVES, Manuela F. (2005). Projetos de Veículos Automotores: Fatores Críticos de Sucesso no Lançamento. Produção, v.15, n.3. ROCHA, Henrique M. Fatores Críticos de Sucesso de START UP de Veículos e a Qualidade (CMMI) no Desenvolvimento de Produtos no Sul Fluminense. 2005, 353f. Dissertação (Mestrado em Sistemas de Gestão). Universidade Federal Fluminense, Niterói, ROCKART, John (1979). Chief Executives Define Their Own Data Needs. Harvard Business Review, v.57, ROZENES, Shai; VITNER, Gad; SPRAGGET, Stuart (2006). Project Control: Literature Review. Project Management Journal, v.37, n. 4, September. RUSK, John (2009). Earned Value for Agile Development. DoD Software Tech News (Journal of Software Technology), v.12, n.3, September. SCHWABER, Ken.; BEDLE, Mike. Agile software development with scrum. NJ: Pretence Hall, SIQUARA, Lúcia. Fatores Críticos de Sucesso no Lançamento de Solventes Industriais. 2003, 103f. Dissertação (Mestrado em Administração e Desenvolvimento Empresarial). Universidade Estácio de Sá, Rio de Janeiro, SOLOMON, Paul (2001). Practical Software Measurement, Performance-Based Earned Value. CrossTalk: The Journal of Defense Software Engineering, 14, SOLOMON, Paul (2002). Using CMMI to Improve Earned Value Management. Technical Note CMU/SEI-20020TN-016. Software Engineering Institute, Carnegie Mellon University. SRIVANNABOON, Sabin (2006). Linking Project Management With Business Strategy. Project Management Journal, v.37, n.5, 88-96, December. STALEY, Mary J.; OBERNDORF, Patricia; SLEDGE, Carol A. (2002). Using EVMS with COTS-Based Systems. Technical Report CMU/SEI-2002-TR-022. Software Engineering Institute, Carnegie Mellon University. STRATTON, Ray W. The Earned Value Management Maturity Model. Management Concepts, Inc Vienna, SULAIMAN, Tamara; BARTON, Brent; BLACKBURN, Thomas (2006). AgileEVM Earned Value Management in SCRUM Projects. In: PROCEEDINGS OF CONFERENCE ON AGILE 2006, p.7-16, July 23-28, Minnesota. TOLEDO, Ruben. Fatores Críticos de Sucesso no START UP de uma Franquia: o Caso BR Mania. 2000, 161f. Dissertação (Mestrado em Administração e Desenvolvimento Empresarial). Universidade Estácio de Sá, Rio de Janeiro, TUMA, David; WEBB, David R. (2005). Personal Earned Value: Why Projects Using the Team Software Process Consistently Meet Schedule Commitments. CrossTalk: The Journal of Defense Software Engineering, 18,

20 VARGAS, Ricardo. Estudo da Utilização da Análise de Valor Agregado em Projetos na Construção Civil Pesada Nacional. 2002, 173 f. Dissertação (Mestrado em Engenharia de Produção), Universidade Federal de Minas Gerais, Belo Horizonte, VARGAS, Ricardo (2004a). Using Earned Value Probabilistic Forecasting Using Monte Carlo Simulation. In: 48 th ANNUAL MEETING OF AACE INTERNATIONAL, Washington. VARGAS, Ricardo (2004b). Using Earned Value Management Indexes as a Team Development Factor and a Compensation Tool. In: PMI GLOBAL CONGRESS EUROPE, Praga. WARBURTON, Roger D. H. (2011). A Time-dependent Earned Value Model for Software Projects. International Journal of Project Management, v.29, n.08, p