BIBLIOTECA PARA O CURSO DE GERENCIAMENTO DE PROJETOS

Tamanho: px
Começar a partir da página:

Download "BIBLIOTECA PARA O CURSO DE GERENCIAMENTO DE PROJETOS"

Transcrição

1 BIBLIOTECA PARA O CURSO DE GERENCIAMENTO DE PROJETOS Selecionamos para você uma série de artigos, livros e endereços na Internet onde poderão ser realizadas consultas e encontradas as referências necessárias para a realização de seus trabalhos científicos, bem como, uma lista de sugestões de temas para futuras pesquisas na área. ossem Primeiramente, relacionamos sites de primeira ordem, como: SUGESTÕES DE TEM AS 1. FATORES CRÍTICOS DE SUCESSO NO GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE PRODUTO EM EMPRESAS DE BASE TECNOLÓGICA DE PEQUENO E MÉDIO PORTE 2. OS ESCRITÓRIOS DE PROJETOS COMO INDUTORES DE MATURIDADE EM GESTÃO DE PROJETOS 3. EMPRESAS EM COMPETITIVIDADE 4. ESTRATÉGIA 5. QUALIDADE 6. TEORIA DAS RESTRIÇÕES 7. REDES DE SUPRIMENTOS 8. OS AVANÇOS TECNOLÓGICOS E AS ALTERAÇÕES NO CENÁRIO ECONÔMICO. 9. COMO PERMANECER FOCADA EM OBJETIVOS ESTRATÉGICOS E, AO MESMO TEMPO, ADAPTAR-SE ÀS MUDANÇAS EXTERNAS? 10. ASPECTOS RELEVANTES DE DUAS ABORDAGENS COMPLEMENTARES 11. MATURIDADE E ESCRITÓRIO DE PROJETOS: REVISÃO TEÓRICA 12. MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS

2 13. O ENTENDIMENTO DA IMPORTÂNCIA DA MATURIDADE EM GERENCIAMENTO DE PROJETOS NAS ORGANIZAÇÕES 14. ESCRITÓRIOS DE PROJETOS: definições e modelos 15. MODELOS DE ESCRITÓRIOS DE PROJETOS ADOTADOS PELAS ORGANIZAÇÕES PESQUISADAS 16. A RELAÇÃO ENTRE MODELOS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS E MODELOS DE ESCRITÓRIO DE PROJETOS 17. ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS: um estudo de caso 18. IMPLEMENTAÇÃO DE ESCRITÓRIOS DE GERENCIAMENTO DE PROJETOS 19. CONDICIONANTES DE DESEMPENHO DOS PROJETOS DE SOFTWARE E A INFLUÊNCIA DA MATURIDADE EM GESTÃO DE PROJETOS 20. SISTEMA DE GESTÃO DE PROJETOS 21. PERFIL DOS ESCRITÓRIOS DE PROJETOS EM ORGANIZAÇÕES ATUANTES NO BRASIL. 22. GESTÃO DA INOVAÇÃO NO SETOR DE TELECOMUNICAÇÕES: inovação tecnológica e políticas públicas em telecomunicações no Brasil 23. GESTÃO DE PROJETOS: as melhores práticas 24. ESTRATÉGIA E MUDANÇA ORGANIZACIONAL: introdução do gerenciamento de projetos em uma organização não-projetizada 25. FATORES CRÍTICOS PARA IMPLEMENTAÇÃO DE GERENCIAMENTO POR PROJETOS: o caso de uma organização de pesquisa 26. O GERENTE DE PROJETOS NA EMPRESA 27. IMPLANTAÇÃO DE ESCRITÓRIOS DE GERENCIAMENTO DE PROJETOS: estudo de caso em uma empresa do setor de autopeças 28. UMA ABORDAGEM DE INTELIGÊNCIA ARTIFICIAL NA GESTÃO COLABORATIVA DE PROJETOS NA WEB 29. VALOR ESTRATÉGICO DOS PROJETOS DE TECNOLOGIA DE INFORMAÇÃO 30. UM MODELO DE PROCESSO DE GESTÃO DE RISCOS PARA AMBIENTES DE MÚLTIPLOS PROJETOS DE DESENVOLVIMENTO DE SOFTWARE 31. UM MODELO DE GERENCIAMENTO DE PROJETO PARA UM AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE 2

3 32. PROJECT MANAGEMENT KNOWLEDGE LEARNING ENVIRONMENT: ambiente inteligente de aprendizado para educação em gerenciamento de projetos 33. A CAPACIDADE DE REGULAÇÃO ESTATAL NA ARGENTINA 34. FERRAMENTA CASE PARA GERENCIAMENTO DE PROJETOS E MÉTRICAS DE SOFTWARE 35. GERÊNCIA DE PROJETOS O MODELO PMBOK 36. GERENCIAMENTO DE PROJETOS E SIMULAÇÃO DE PROCESSOS: UMA ABORDAGEM INTEGRADA 37. A GESTÃO DE PROJETOS COMO APRIMORAMENTO DA TERCEIRIZAÇÃO 38. CORRENTE CRÍTICA: um a alternativa à gerência de projetos tradicional 39. PERFIL DE ESCRITÓRIOS DE GERENCIAMENTO DE PROJETOS EM ORGANIZAÇÕES ATUANTES NO BRASIL 40. UMA FERRAMENTA EM BUSCA DO DEFEITO ZERO 41. U M ESTUDO EXPERIMENTAL SOBRE A UTILIZAÇÃO DE MODELAGEM E SIMULAÇÃO NO APOIO À GERÊNCIA DE PROJETOS DE SOFTWARE 42. GESTÃO DE ONGS: principais funções gerenciais 43. DEFINIÇÃO DE UM PROCESSO ÁGIL DE GESTÃO DE RISCOS EM AMBIENTES DE MÚLTIPLOS PROJETOS 44. ANÁLISE DE MATURIDADE NO GERENCIAMENTO DE PROJETOS DE TECNOLOGIA DE AUTOMAÇÃO 45. GERÊNCIA DE PROJETOS NA ENGENHARIA DE SOFTWARE EM RELAÇÃO ÀS PRÁTICAS DO PMBOK 46. GERÊNCIA DE PROJETOS: uma reflexão histórica 47. MATURIDADE EM GESTÃO DE PROJETOS: análise de um caso e proposição de um modelo 48. UM AMBIENTE DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE DISEN 49. GERENCIAMENTO DE PROJETOS EA APLICAÇÃO DA ANÁLISE DE VALOR AGREGADO EM GRANDES PROJETOS 50. ANÁLISE DE VALOR AGREGADO EM GRANDES PROJETOS: análise de valor agregado em grandes projetos 3

4 51. O AMBIENTE DE INOVAÇÃO EA GERÊNCIA DE PROJETOS 52. GERÊNCIA DE PROJETO DE SOFTWARE EM AMBIENTE FISICAMENTE DISTRIBUÍDO: um estudo de caso 53. CADEIA DE SUPRIMENTOS-PROJETO E GESTÃO 54. AS PEÇAS DO QUEBRA-CABEÇAS DO GERENCIAMENTO DO CONHECIMENTO 55. SISTEMÁTICA PROPOSTA PARA SELEÇÃO DE FORNECEDORES EM GESTÃO DE PROJETOS 56. UM MODELO ESTRUTURADO DE COMPETÊNCIAS E MATURIDADE EM GERENCIAMENTO DE PROJETOS 57. TEMPO DE IMPLANTAÇÃO DE SISTEMAS ERP: análise da influência de fatores e aplicação de técnicas de gerenciamento de projetos 58. ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS: um estudo de caso 59. GERÊNCIA DE PROJETOS DE TECNOLOGIA DA INFORMAÇÃO 60. IMPLANTAÇÃO E CONSOLIDAÇÃO DE ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS: um estudo de caso 61. WGPMS: um a abordagem de inteligência artificial na gestão colaborativa de projetos na web 62. IDENTIFICAÇÃO DE RISCOS EM PROJETOS DE TI 63. MÉTODO PARA GESTÃO DE RISCOS EM IMPLEMENTAÇÕES DE SISTEMAS ERP BASEADO EM FATORES CRÍTICOS DE SUCESSO 64. A IMPORTÂNCIA DA MODELAGEM DO PROCESSO DE PROJETO PARA O DESENVOLVIMENTO INTEGRADO DE EDIFICAÇÕES 65. GESTÃO DO PROCESSO DE PROJETO DE EDIFICAÇÕES 66. FATORES CRÍTICOS PARA IMPLEMENTAÇÃO DE GERENCIAMENTO POR PROJETOS: o caso de uma organização de pesquisa 67. METODOLOGIA SINGULAR DE GESTÃO DE PROJETOS: condição suficiente para a m aturidade em gestão de projetos 68. LIDERANÇA E INFLUÊNCIA NAS FASES DA GESTÃO DE PROJETOS 69. FATORES CRÍTICOS DE SUCESSO NO GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE PRODUTO EM EMPRESAS DE BASE TECNOLÓGICA DE PEQUENO E MÉDIO PORTE 4

5 70. OS ESCRITÓRIOS DE PROJETOS COMO INDUTORES DE MATURIDADE EM GESTÃO DE PROJETOS 71. ESTRUTURAS DE GERENCIAMENTO DE PROJETOS E COMPETÊNCIAS EM EQUIPES DE PROJETOS 72. ESTENDENDO O SCRUM SEGUNDO AS ÁREAS DE PROCESSO DE GERENCIAMENTO DE PROJETOS DO CMMI 73. ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS UM ESTUDO DE CASO 74. TEMPO DE IMPLANTAÇÃO DE SISTEMAS ERP: análise da influência de fatores e aplicação de técnicas de gerenciamento de projetos 5

6 ARTIGOS PARA LEITURA, ANÁLISE E UTILIZAÇÃO COMO FONTE OU REFERENCIA Gestão & Produção Print version ISSN X FATORES CRÍTICOS DE SUCESSO NO GERENCIAMENTO DE PROJETOS DE DESENVOLVIMENTO DE PRODUTO EM EMPRESAS DE BASE TECNOLÓGICA DE PEQUENO E MÉDIO PORTE TOLEDO, José Carlos de; Dr. Moacir Birro, 663 MENDES, Glauco Henrique Souza and JUGEND, Daniel. As empresas de base tecnológica (EBTs) estão associadas à inovação tecnológica, principalmente de produto, o que torna o desenvolvimento de produto um processo crítico para tais empresas. O desempenho deste processo pode ser avaliado em função dos resultados, em termos de sucesso ou não sucesso, do produto desenvolvido. E o grau deste sucesso depende de fatores de gestão praticados durante o desenvolvimento do projeto. Este artigo tem por objetivo identificar e analisar os fatores críticos de sucesso no gerenciamento de projetos de desenvolvimento de novos produtos em EBTs de pequeno e médio portes. Foram analisados projetos desenvolvidos por empresas dos setores de equipamentos médico-hospitalares (EMH) e de automação de controle de processos (EACP), localizadas no Estado de São Paulo. Com o método foi realizada uma pesquisa de levantamento (survey), aplicando-se um questionário estruturado em visitas realizadas às empresas. Foram levantados dados em 62 em presas, sendo 30 do setor de EMH e 32 do setor EACP. As unidades de análise foram projetos já concluídos por tais empresas. Os resultados demonstram que o gerenciamento de projetos de novos produtos de EBTs deve contemplar ações que valorizem mais as atividades de pré-desenvolvimento, tais como a avaliação do potencial de mercado do novo produto, a compreensão efetiva das necessidades do mercado e a sinergia do novo produto/projeto com outros produtos/projetos da empresa. Os resultados 6

7 também enfatizam a importância do aprimoramento de habilidades gerenciais e de relacionamento interpessoal dos gerentes (ou líderes) dos projetos. Normalmente cabe a esses gerentes (ou líderes) suprirem, durante o desenvolvimento, as deficiências gerenciais e organizacionais da empresa. Palvras-chave: Gestão do desenvolvimento de produto; Empr esa de base tecnológica; Gestão de projetos; Fatores críticos de sucesso. 7

8 OS ESCRITÓRIOS DE PROJETOS COMO INDUTORES DE MATURIDADE EM GESTÃO DE PROJETOS Ivete Rodrigues Roque Rabechini Júnior João Mário Csillag Empresas em Competitividade, Estratégia, Qualidade, Operações, Teoria das Restrições, Redes de Suprimentos muda com velocidade impressionante de acordo com os avanços tecnológicos e as alterações no cenário econômico. Uma pergunta que ecoa nas organizações é: como permanecer focada em objetivos estratégicos e, ao mesmo tempo, adaptar-se às mudanças externas? Muitas organizações têm encontrado na implementação de projetos o fator crítico para o enfrentamento dessa questão, uma vez que eles são fonte de novos produtos, novos serviços e novos processos que, potencialmente, podem aumentar vendas, reduzir custos, melhorar qualidade e outros benefícios decorrentes. Para isso, as empresas vêm investindo na melhoria de seus processos de gerenciamento de projetos como parte do planejamento estratégico par a melhorar a efetividade organizacional. Gerenciamento de projetos tem, nesse sentido, se apresentado como uma alternativa inovadora no atendimento dos objetivos dos empreendimentos associados às empresas, possibilitando-lhes maior competitividade. Com o decorrência da importância que os projetos vêm ganhando no seio das organizações, dois assuntos têm freqüentado a pauta das publicações especializadas em gerenciamento de projetos : um refere-se aos escritórios de projetos (Project Management Office PMO) e o outro aos modelos de maturidade organizacional em gestão de projetos. Certamente, o interesse que esses temas têm despertado diz respeito ao fato de que ambos estão relacionados à obtenção de melhores taxas de sucesso em gerenciamento de projetos, entendendo sucesso como a entrega de projetos no prazo, dentro do escopo e do orçamento previsto. O primeiro tema, escritório de projetos, mediante a implementação de uma estrutura formal, auxilia as organizações a melhor gerenciar seus projetos, sejam eles de desenvolvimento de novos produtos/serviços ou de implantação de novos processos, ajudando-as a minimizar os riscos associados, diminuir os conflitos 8

9 inerentes entre projetos e operações, prover metodologias adequadas etc. O segundo tema vem auxiliando as empresas a entender quão m aduras elas são em gerenciamento de projetos e a estabelecer estratégias em busca do aprimoram ento contínuo no que diz respeito a aquisição de conhecimento, capacidades, técnicas e ferramentas, visando atingir os objetivos da organização por meio de projetos. Portanto, ambos os assuntos são importantes, pois, direta ou indiretam ente, contribuem para elevar a competitividade das organizações intensivas em gerenciamento de projetos. Nessa direção, percebe-se a importância em estabelecer inter-relações entre os dois assuntos e discuti-las, contribuindo para que as empresas possam entender, melhor, suas questões gerenciais. Entretanto, ambos os assuntos vêm sendo tratados na literatura separadamente, havendo poucos estudos que investigam a relação entre eles. Há, portanto, uma lacuna a ser preenchida. Assim, no presente estudo, procurando preencher essa lacuna, apresentam-se os resultados de uma pesquisa que investigou o grau de maturidade das organizações e sua relação com os escritórios de escritórios de projetos. Buscou-se verificar se a existência de projetos é, ou não, um indutor da maturidade organizacional em gerenciamento de projetos. Um objetivo adicional foi entender como os escritórios de projetos estão funcionando hoje no Brasil. A metodologia adotada, para auxiliar no entendimento do problema, foi um estudo descritivo, com a utilização de variáveis quantitativas e qualitativas. Os dados foram obtidos por meio de um questionário, com questões fechadas, que foi aplicado em uma amostra não-aleatória, intencional, representada por profissionais de gerenciamento de projetos oriundos de empresas situadas no Brasil. O desenvolvimento e a aplicação do questionário foram antecedidos por uma revisão bibliográfica sobre os dois assuntos, o que ajudou a estabelecer as questões relevantes de estudo. Com o resultado, foi possível obter um quadro bastante rico em informações sobre dois assuntos que permeiam, atualmente, a realidade das organizações: um, que trata da existência de escritório de projetos e dos modelos adotados; outro, que enfatiza suas relações com a institucionalização ou a maturidade organizacional em gerenciamento de projetos. Com relação aos escritórios de projetos, foi possível verificar como eles ajudam as organizações a melhor gerenciar seus projetos. De 9

10 forma geral, observou-se que a implementação desse tipo de estrutura formal ajuda a minimizar os riscos associados, diminuir os conflitos inerentes entre projetos e operações, prover metodologias adequadas etc. Quanto à institucionalização, foi possível colocar em discussão como as práticas de gerenciamento de projetos podem auxiliar as empresas a entender quão maduras elas são. A partir daí, elas podem estabelecer estratégias de busca do aprimoramento contínuo no que diz respeito a aquisição de conhecimento, capacidades, técnicas e ferramentas, visando atingir os objetivos da organização por meio de projetos. Portanto, fica clara a importância de ambos os assuntos aqui tratados, à medida que eles podem contribuir para a discussão sobre competitividade, especialmente quando se referem às organizações intensivas em gerenciamento de projetos. A pesquisa ouviu 86 representantes de empresas (77% deles gerentes de projeto) de setores distintos, destacando-se a indústria (30%) e a tecnologia de informação (17%). Percebeu-se, nesse quadro, que há crescente interesse das empresas por gerenciamento de projetos, embora os escritórios de gerenciamento de projetos se encontrem estruturados com modelos considerados, pela literatura, ainda incipientes. 2. ASPECTOS RELEVANTES DE DUAS ABORDAGENS COMPLEMENTARES MATURIDADE E ESCRITÓRIO DE PROJETOS: REVISÃO TEÓRICA Dois temas têm preocupado os pesquisadores e estudiosos de gerenciamento de projetos atualmente: maturidade e escritórios de projetos. Ambos também têm sido objetos de atenção das empresas e organizações, preocupadas em melhorar o desempenho de seus resultados. Uma das evidências dessa preocupação tem sido a crescente busca por certificação de profissionais. Criada pelo Project Management Institute (PMI), a certificação Project Manager Professional (PMP) é reconhecida mundialmente como uma das mais altas qualificações de um profissional de gerenciamento de projetos. A existência de profissionais com essa certificação no seio das organizações está associada a uma maior m aturidade em gerenciamento de projetos. A importância dada à certificação PMP advém do fato de ela contar com o selo de qualidade ISO 9001 e o reconhecimento de outras instituições internacionais, como 10

11 o The Council for Accreditation. O PMI está hoje presente em 130 países e conta com mais de membros em todo o mundo, dos quais possuem a certificação PMP. Considerando que em 1990 o PMI tinha associados, passando para em 1995, houve crescimento sup erior a 200% em apenas cinco anos. De 1995 até hoje, ou seja, cerca de dez anos, esse crescimento foi superior a 900%. Os números revelam, de fato, um crescimento exponencial (PMI/SP, 2005). Dada a importância dos temas maturidade e escritório de projetos e como parte integrante da abordagem adotada neste trabalho, vale a pena explorá -los, ao menos brevemente, nos itens que se seguem Modelos de maturidade em gerenciamento de projetos O entendimento da importância da maturidade em gerenciamento de projetos nas organizações tem sido tratado por vários autores (FRAME, 1999; RABECHINI JR., 2003) ao sugerirem três tipos de competências associadas ao tema: as individuais, as de equipe e as da organização. Esses tipos podem ser vistos como se fossem três vetores conceituais. O primeiro refere-se às aptidões e habilidades dos indivíduos na solução de problemas. As competências da equipe, segundo vetor, relacionam-se com a capacidade de resolução de problemas complexos em contexto m ultidisciplinar. As competências da empresa formam o terceiro vetor, que lida com a capacidade de criação de um ambiente que possibilite o envolvimento tanto do indivíduo quanto das equipes para que possam tocar seus forma eficaz. A exploração dos modelos de maturidade em gerenciamento de seguido, geralmente, o conceito de crescimento evolutivo, hoje amplamente divulgado pelo Capability Maturity Model (CMM) desenvolvido pelo Software projetos de projetos tem Engineering Institute (PAULK et al., 1995). Um dos primeiros autores na área de gerenciamento de projetos a tratar do assunto foi Kerzner (1999), que propôs cinco níveis de desenvolvimento de competências para que as empresas alcancem a excelência. O primeiro nível linguagem comum é aquele em que a organização reconhece a impor tância do gerenciamento de metodologia útil para atingir sucesso em projetos como projetos. Nesse nível, em geral a 11

12 organização sente a necessidade de ter um bom entendimento e conhecimento básico na disciplina, com condições de, pelo menos, estabelecer uma terminologia. O segundo nível proposto processos comuns refere-se ao reconhecimento da organização sobre a necessidade de estabelecimento de processos comuns para projetos. Tais processos visam permitir a replicabilidade dos fatores de sucesso obtidos de um projeto para todos os outros na organização. O nível três metodologia singular m anifesta-se quando a organização reconhece a possibilidade de obter sinergia devido à combinação de várias metodologias dentro de uma única. Seu eixo central é o gerenciamento de projetos. O quarto nível benchmarking de gerenciamento de é formado por um processo contínuo de comparação das práticas projetos desenvolvido por uma organização com as concorrentes. O objetivo dessa fase é a obtenção de informações que ajudem organização a melhorar seu desempenho. Finalmente, no quinto e último nível melhoramento contínuo é aproveitada a informação aprendida advinda do nível anterior para implementar as mudanças necessárias visando ao melhoramento contínuo nos processos de de projetos. gerenciamento Além de Kerzner (1999), outros autores (ESI, 1999; BUNNIK e GARRETT, 2000; IBBS e KWAK, 2000; DINSMORE, 1999), incluindo experiências com empresas de consultoria, preocupam -se em entender o processo de maturidade nas organizações. Destaca-se, nesse sentido, o esforço do grupo de voluntários do PMI ao elaborar uma metodologia-padrão. A idéia de criar um modelo de maturidade em gerenciamento de projetos que fosse padrão do PMI ocorreu em maio de 1998 quando foi constituído o programa Organizational Project Management Maturity Model (OPM3 ) (PMI, 2003). Por intermédio de um Comitê de Padrões foram discutidas as principais capacitações inerentes a um gerenciamento de projetos organizacional (SCHLICHTER, 2001). Esse conjunto de capacidades deve ser desenvolvido tendo- se como premissa o entendimento das estratégias de negócios da organização. O OPM3 foi desenvolvido no sistema de voluntariado e constituído pela incorpora ão de resultados de diversas pesquisas sobre as melhores práticas, aderentes às necessidades de gerenciamento de projetos, identificadas em vários países. Três a 12

13 grandes dimensões foram consideradas em termos gerenciais: portfolio, programas e projetos. Para essas dimensões foram propostos níveis, considerando-se padroniza ão, medi es, controle e aprimoramento contínuo. O OPM3 composto pelos seguintes elementos: Best Practices (Melhores Práticas) é a melhor maneira, reconhecida pelo mercado, de atingir uma meta ou um objetivo. Capability (Capacidades) conjunto de competências específicas existentes na organização para executar processos em gerenciamento de projetos. Uma melhor prática é composta por uma ou mais competências específicas. Outcomes (Resultados) existência de uma capacidade. resultados tangíveis ou intangíveis que comprovam a KPI (Indicador de Desempenho) critério pelo qual uma organização pode determinar, qualitativa ou quantitativamente, a existência e o grau de um resultado associado a uma capacidade. A partir desses elementos, o OPM3 define que a maturidade organizacional em gerenciamento de projetos pode ser verificada por meio da existência de melhores práticas na organização. A existência delas é, por sua vez, verificada por m eio das capacidades e de resultados com provados Escritórios de projetos definições e modelos Em paralelo ao desenvolvimento do assunto de maturidade em gerenciamento de projetos, vários autores têm-se preocupado também com a questão da implementação de escritórios de projetos (PMO), entendidos como o locus dos projetos no âmbito organizacional. De acordo com Thorn (2003), um dos motivos para essa preocupação é que a gerência e os resultados dos projetos não têm sido, em geral, favoráveis. Dados indicam que nos últimos 20 anos as empresas têm tido a seguinte experiência com seus projetos : uma m dia de 25% dos projetos tem obtido sucesso em termos de sua conclusão dentro do escopo, do prazo, do custo e do desempenho requerido; outros 25% falharam, foram cancelados ou nunca completamente implementad os 50% restantes foram implementados, por m com mudan as (definitivas e caras) de escopo, prazo, custos e desempenho. os; 13

14 Para Thorn (2003), aumentar a probabilidade do sucesso é uma exigência básica no ambiente organizacional de hoje, sobre a qual todos concordam. Porém, o que é pouco reconhecido é a contribuição direta das atividades de gerenciamento e controle de projetos para a sobrevivência e o crescimento organizacionais. Isso se deve ao lapso de tempo existente entre o prazo requerido para planejar, projetar, controlar e executar um projeto e os resultados de transformações organizacionais de fato ocorridas. Na realidade, isso deveria ser visto como um investimento imperativo em tempo e recursos que conduzem a um resultado positivo. Em outras palavras, o retorno do investimento em atividades de planejam ento e controle de projetos pode parecer mínimo num primeiro momento, mas é crucial para sustentar o crescimento organizacional. Thorn (2003) baseia tais afirmações em estudo de caso em que o estabelecimento de um escritório de projetos levou cerca de cinco anos. Foi apenas nos últimos 18 meses da implementação que os resultados sobre o desempenho organizacional começaram a aparecer efetivamente. Quanto à definição do que é um escritório de projetos, não há ainda uma que seja aceita mundialmente. Muitos autores arriscam-se a explicitar esses conceitos e definem escritório de projetos como: mecanismo administrativo pelo qual um ponto focal atividades de gerenciamento de projetos na organização (RAD, 2001); disponibilizado para as local do gerenciamento de projetos na organização (DINSMORE, 1999); centro corporativo de controle da propriedade intelectual de gerenciamento de projetos (KERZNER, 2001); organiza ão centralizada, dedicada ao aperfei oa gerenciamento de projetos (KENDALL e ROLLINS, 2003). mento de práticas e resultados do A partir das várias definições propostas, conclui-se que os escritórios de representam uma unidade organizacional responsável pelos processos de gestão de projetos projetos, provendo internamente o respaldo necessário para que os profissionais possam gerenciar seus projetos dentro do prazo, do custo e da qualidade requeridos, por meio da utilização de métodos e processos de planejamento, acompanhamento e controle. Além disso, são os responsáveis por fazer a ligação entre o gerente de projeto e a alta administração, através de um sistema de feedbackque permite o aperfeiçoamento contínuo da disciplina no seio da organização. Esse conceito é defendido por Bernstein (2000) e também por Kendall 14

15 e Rollins (2003). Esses últim os consideram que prover um a metodologia padrão em gerenciamento de projetos para a organização é apenas uma pequena parte da responsabilidade de um escritório de projetos. Seu papel m ais relevante é influenciar a seleção dos projetos, focando nos investimentos, nos recursos, na avaliação e na definição dos objetivos estratégicos. O conceito de escritório de gerenciamento de projetos é decorrente do tipo escolhido para ser implementado ou desenvolvido numa organização. A tipologia é estabelecida dependendo do critério de atuação: suporte ou estratégico. De acordo com Rodrigues et al. (2002), há uma diversidade de modelos e funções que o PMO pode assumir, dependendo do estágio de evolução da disciplina na empresa, do tipo de estrutura organizacional (quão projetizada a em presa é), dentre outros fatores. Há desde escritórios que têm a função única de reportar o desempenho dos projetos (foco em suporte) até aqueles que participam da definição das estratégias empresariais e são responsáveis pelo corpo de profissionais da área (foco estratégico). Os escritórios de projetos podem ter foco apenas em processos internos (planejamento, gerenciamento de pessoas, execução, controle de mudanças etc.), mas também podem responsabilizar-se pelas interfaces externas (satisfação do cliente, comunicação com os stakeholders etc.). Os escritórios de projetos são reconhecidos nas empresas por distintas nomenclaturas, tais como Escritórios de Suporte a Projetos, PMO, Project Office, Centros de Excelência etc., mas o que os distingue são os diferentes graus de autoridade e responsabilidade. Casey e Peck (2001) partem do pressuposto de que não existe um único tipo de escritório de projetos que atenda a todas as necessidades e que se deve fugir de um modelo-padrão que pode acabar operando como qualquer outro departamento funcional. Diferentes tipos resolvem diferentes problem as. A escolha do modelo deve levar em conta o estágio de maturidade do gerenciamento de projetos na organização. Os autores descrevem três tipos de escritórios de figura abaixo, e os problemas que cada um deles pode solucionar. projetos, que podem ser vistos na Quando o problema da empresa é a confusão causada por diferentes tipos de relatórios elaborados por diferentes gerentes de projetos, com jargões variados, a solução que se apresenta é instituir um escritório de projetos chamado 15

16 Estação Metereológica. Esse tipo de escritório apenas reporta o andamento dos projetos, mas não tenta influenciá-los. O modelo Torre de Controle é sugerido quando a empresa tem: problemas de treinamento de pessoal, metodologias caras e pouco utilizadas; altos executivos com pouca compreensão ou visão equivocada sobre gerenciamento de projetos ; lições aprendidas não utilizadas em novos projetos ; uso e trocas constantes de quaisquer métodos e ferramentas. Nesse caso, o gerente do escritório dá a direção para os gerentes de projetos. Cada gerente pilota o avião e tem a responsabilidade pelo vôo, mas deve seguir as instruções da Torre de Controle, particularmente durante a decolagem e o pouso. Por fim, nas empresas cujo negócio é desenvolver projetos e que necessitam estar, permanentemente, atentas à capacitação de seu pessoal em gerenciamento de projetos, a solução proposta é o Pool de Recursos ou, na linguagem de Casey e Peck (2001), o Esquadrão de Comando. A participação do gerente desse tipo de escritório de projetos é bastante forte. Ele indica aos gerentes de projetos quando entrar no cockpit e quando decolar. Mesmo no ar, todos os pilotos devem estar em estrita consonância e voando na mesma direção. Alguns pilotos podem ser verdadeiros ases, outros nem tanto, mas o gerente do escritório de projetos é avaliado pelo desempenho do pool. A partir dos modelos propostos por vários autores (CASEY e PECK, 2001; DINSMORE, 1999; RAD, 2001), as diferentes contribuições foram sintetizadas aqui em, basicamente, três níveis de escritório de projeto, os quais foram os modelos adotados na pesquisa. Modelo Nível 1 Escritório de Apoio a Projetos Com foco emprojetos específicos, esse tipo é utilizado normalmente nas áreas funcionais e tem como objetivo básico dar suporte aos gerentes de projetos no gerenciamento de recursos. Modelo Nível 2 Escritório de Gerenciamento de Projetos Com foco em programas ou múltiplos projetos, esse tipo provê os diversos grupos de gerentes no estabelecimento de metodologias e no acompanhamento de desempenho, além de atuar como um centro disseminador das práticas de gerenciamento de projetos. 16

17 Modelo Nível 3 Diretoria de Projetos Com foco na gestão do portfolio de projetos, esse tipo serve toda a empresa focando as questões estratégicas em termos de gerenciamento de projetos. Orienta e aloca recursos e é responsável pelo sucesso dos projetos Escritórios de projetos e sua maturidade Assim como a literatura teórica apresenta os níveis de maturidade em gerenciamento de projetos para as empresas (KERZNER, 1999; IBBS e KWAK, 2000), Kendall e Rollins (2003) também definem níveis de competência contínua para os escritórios de projetos. Em outras palavras, tanto a organização como os escritórios de projetos podem ter seus níveis evolutivos de agregação de valor ao negócio conforme avançam suas competências. Para Kendall e Rollins (2003), em síntese, considera-se em estágio inicial o escritório de projetos que venha agregar capacidade de supervisão sobre um ou mais projetos, a fim de garantir profissionalismo e excelência na aplicação das práticas de gerenciamento de projetos. Nesse estágio, o foco de atenção do escritório de projetos é o projeto. Já, num segundo estágio, essa supervisão passaria a ser exercida em múltiplos projetos, buscando uma visão agregada do desempenho dos diversos gerentes de projetos. O foco seria, então, os programas. Num terceiro nível, há busca de alinhamento estratégico dos projetos às metas organizacionais e, nesse sentido, o foco está no portfólio de projetos. 3. METODOLOGIA DA PESQUISA No intuito de entender o problema apresentado inicialmente optou-se por realizar um survey informal ou enquete. Pesquisas do tipo informal survey são processos legítimos e científicos de coletar dados de um público específico. São adotadas quando o objetivo é obter opiniões e informações gerais a respeito de determinados assuntos, sem ter, contudo, a preocupação de gerar estatísticas válidas para uma população, caso dos recenseamentos nacionais, considerados surveys formais. Em surveys informais, pessoas que estão facilmente acessíveis podem constituir a amostra de pesquisa (FOWLER JR., 1991). Para tanto, foram definidos, de início, os conceitos a serem adotados, tanto para modelos de maturidade em gestão de projetos quanto para modelos de escritório de projetos. Definidos os conceitos, 17

18 elaborou-se a primeira versão do questionário que foi aplicado a cinco gerentes de projetos, estudantes do Curso de Formação em Gestão de Projetos oferecido pela Fundação Instituto de Administração (FIA). O questionário foi reelaborado com base no pré-teste e aplicado, em sala de aula, aos demais profissionais, em sua maioria gerentes de projetos, alunos do curso de Form ação em Gestão de Projetos, do curso de MBA em Administração de Projetos, também da FIA, e do Curso de Especialização em Gestão de Projetos, da Fundação Vanzolini, ligada à Escola Politécnica da Universidade de São Paulo. Ao todo, foram aplicados 86 questionários. A opção por aplicar os questionários a alunos desses programas deveu-se, em primeiro lugar, à facilidade de acesso dos pesquisadores e, em segundo lugar, ao fato de tratar-se, potencialmente, de um público qualificado no tema gerenciamento de projetos. A opção por aplicar os questionários em sala de aula deveu-se à necessidade de aumentar as chances de resposta (questionários enviados por correio tradicional ou correio eletrônico em geral têm baixo índice de retorno), bem como ao fato de maior interação entre os respondentes e os pesquisadores, principalmente no esclarecimento de dúvidas sobre questões levantadas no questionário. A coleta das informações qualitativas e quantitativas foi efetuada por meio de questões sobre as características da organização em três vertentes: maturidade organizacional, maturidade das equipes, maturidade dos indivíduos e dados sobre escritório de projetos que possibilitassem a identificação de um modelo adotado pela empresa. O questionário compreendeu um total de 66 questões, divididas em quatro partes: dados do entrevistado, dados da em presa, dados do gerenciamento de projetos (com o objetivo de identificar o nível de maturidade organizacional em gerenciamento de projetos ) e dados do PMO (com o objetivo de identificar o modelo de PMO adotado pela organização). Para a análise, foram feitas tabulações agregadas de todos os dados e tabulações específicas em função dos modelos de escritório de projetos adotados. Isso permitiu elaborar com parações entre aqueles que responderam sobre um determinado tipo de escritório (modelos 1, 2 ou 3) e o conjunto dos respondentes. 4. RESULTADOS OBTIDOS 18

19 Uma vez apresentados o problema e a metodologia de pesquisa, faz-se necessário apresentar os dados conseguidos e proceder à análise. Para isso serão considerados, inicialmente, os aspectos gerais das empresas estudadas, seguidos da apresentação de dados sobre maturidade, escritórios de projetos e, em seguida, as questões evidentes de inter-relações entre os dois temas Aspectos gerais das empresas estudadas A pesquisa aqui relatada contou com 86 respondentes que avaliaram 66 itens sobre maturidade em gerenciamento de projetos e sua relação com os escritórios de gerenciamento de projetos. Distribuída em sua maioria entre gerentes (77%) e técnicos (12%), a amostra revelou forte participação de indivíduos do sexo masculino (74%). Percebeu-se, também, que a maioria dos respondentes tem menos de 45 anos (90%), e que a maior concentração de respondentes (46%) aparece na faixa de menos de 35 anos. No que diz respeito à experiência em gerenciamento de projetos, a maioria (81%) tem mais de dez anos de experiência, o que parece reforçar a legitimidade dos dados encontrados na pesquisa. A pesquisa mostrou, ainda, que o universo das empresas envolvidas é composto, em sua maior parte (48,15%), por organizações que faturam acima de US$ 100 milhões anuais. Do restante, 25,93% faturam anualmente entre US$ 10 m ilhões e US$ 100 milhões, e os outros 25,93% faturam até US$ 10 milhões (gráfico 1). Quanto ao quadro de pessoal, a maioria (44%) das empresas pesquisadas tem entre 100 e funcionários. No entanto, percentual representativo (39%) refere-se às empresas com mais de funcionários, revelando tratar-se de organizações de médio e grande portes. Do restante, 15% têm de 50 a 100 funcionários e apenas 2% delas têm menos de 50. O setor industrial (30,23%), representado por empresas de manufatura, química, farmacêutica, alimentos, eletroeletrônica, aeronáutica, siderúrgica etc., foi o que mais contribuiu com a amostra (gráfico 2). Em segundo lugar aparece o setor que representa as empresas de tecnologia de informação (17,44%), que inclui integradoras, desenvolvedoras de sistemas, out-sourcing, entre outras. O setor bancário foi representado por 11,63% da amostra, enquanto os serviços de 19

20 consultoria representaram 8,14%. Outros setores (18,6%) com participações individuais m enores incluem comércio, mídia e publicidade etc. Gráfico 2: Setores Produtivos Um dos aspectos ressaltados pela pesquisa diz respeito à importância do gerenciamento de projetos para as empresas. Duas variáveis apresentam -se para desvendar esse aspecto. Uma refere-se aos investimentos atuais em gerenciamento de projetos garantidos e a outra, aos investimentos futuros. Por meio dessas variáveis é possível propor um quadro que mostra o interesse das empresas em gerenciamento de projetos composto por quatro clusters de interesses distintos. No primeiro, representado pelos poucos investimentos atuais e futur os, estão as empresas que utilizam pouco o gerenciamento de projetos ou que o utilizam, de forma não-estratégica, apenas de suporte. No segundo aparecem as empresas que estão aum entando seu interesse em gerenciamento de projetos, ou seja, investem pouco hoje, mas preparam-se para investir no futuro. Num terceiro cluster surgem as empresas que estão perdendo o interesse por gerenciamento de projetos, pois pretendem, no futuro, investir menos que hoje. Por fim, no quarto cluster existem as empresas que têm no gerenciamento de projetos sua opção estratégica para administrar empreendimentos, uma vez que investem nele e pretendem investir ainda mais. São as empresas para as quais o gerenciamento de projetos é considerado como uma competência organizacional. No que diz respeito aos investimentos em gerenciamento de projetos, outra informação relevante trazida pela pesquisa é que os respondentes, em geral, declararam não saber sobre os investimentos realizados por suas empresas em gerenciamento de projetos : 43% deles dizem que não sabem dos investimentos atuais e 61% desconhecem quantos recursos serão investidos no futuro próximo (daqui a um ano, como foi perguntado). Esse fato aponta para, no mínimo, três especulações possivelmente interligadas que merecem ser mencionadas. Uma, mais evidente, é sobre a falta de informação entre os respondentes que, em sua maioria, são gerentes de projetos (77%). Outra é decorrente e mostra o possível baixo nível de poder dos respondentes, uma vez que não têm acesso às 20

21 informações importantes, normalmente posse das camadas mais altas da administração corporativa. Nesse caso, percebe-se uma disfunção quando o cargo se refere ao do gerente de projetos. A terceira parece mostrar que a função gerenciamento de projetos não está conectada à estratégia de negócios, sendo, portanto, considerada uma atividade mais operacional do que estratégica. Embora a questão dos investimentos em gerenciamento de projetos não esteja explícita nos modelos de maturidade expostos na revisão conceitual, essa falta de informação parece denotar baixo nível de maturidade, uma vez que as equipes não estão, aparentemente, engajadas em processos decisórios. Em linhas gerais, foi possível perceber um crescim ento no percentual de empresas que pretendem investir em gerenciamento de projetos. Se hoje existem 27% delas que não investem, esse quadro é mais promissor no futuro, quando se constata que apenas 10% não farão investimentos nesse setor. Cresce, portanto, o número de empresas que devem optar por gerenciamento de projetos em suas alternativas de administração do conjunto de suas atividades nãorotineiras Aspectos da maturidade em gerenciamento de projetos Para avaliar a m aturidade das organizações, foram levantadas informações relativas ao gerenciamento de projetos em três dimensões: organização, equipes e indivíduos. A percepção das afirmações positivas foi feita considerando-se as declara es do tipo concorda ou concorda fortemente. J as negativas estão aderentes s declara es do tipo discorda ou discorda fortemente A dimensão organizacional As competências das empresas da amostra podem ser avaliadas segundo a proposta de Rabechini Jr. (2003), que consiste em traçar, de um lado, os aspectos estratégicos, ligados à gerência e aos relacionamentos organizacionais, e, de outro, os processuais, ligados ao tático e às tarefas. Do lado estratégico, foi possível investigar as questões referentes à implementação de estratégia de negócios, priorização de projetos, maturidade, apoio da alta administração e da gerência geral, e também de aspectos ligados ao portfolio de projetos. Do lado tático, as 21

22 questões enfatizaram principalmente o planejamento e o controle de projetos no que se refere ao gerenciamento de riscos, da comunicação e da qualidade. Foram também investigados os aspectos processuais e de acompanhamento de projetos. Assim, de acordo com os dados da pesquisa, foi possível perceber que, em geral, quando se trata das questões organizacionais, as empresas da amostra, em 66% dos casos, implementam estratégias por meio de projetos, e 71% de seus projetos apresentam -se alinhados às estratégias da empresa. Aqui parece repousar uma inconsistência entre as respostas encontradas e a literatura apresentada. A literatura aponta a existência de alinhamento entre estratégias de negócios e projetos como um índice de maturidade e coloca o escritório de projeto como o elo entre eles. Percebe-se que, embora 66% dos respondentes tenham dito que sua organização faz esse alinhamento estratégico, eles declararam a maturidade como sendo ainda incipiente (43%) e que, realmente, não foram diagnosticados avanços na implementação de processo de gerenciamento de projetos (46%). Do ponto de vista tático, destaca-se também o empenho no acompanhamento de projetos (48%), mas nota-se, por outro lado, a falta de cultura em gerenciamento de riscos (46%). Tais inconsistências nas respostas ficam mais sérias se considerar -se que se está falando de respondentes supostamente qualificados (a maioria é gerente de projetos e com conhecimento dos conceitos de maturidade e de escritório de projetos). Pode-se inferir que mesmo pessoas com alto grau de conhecimento e experiência em gestão de projetos não valorizam, ainda, práticas consideradas essenciais pela literatura. Gasta-se mais tempo com a execução do projeto do que com seu planejamento A dimensão das equipes de projetos Do ponto de vista das equipes de projetos foram adotados dois critérios para análise dos resultados, baseados na pesquisa de Thamhain (1993): os fatores mais voltados aos relacionamentos gerenciais e outros mais processuais, ligados às tarefas. Os fatores ligados às questões de relacionamentos constituem um quadro que considerou o envolvimento dos membros das equipes, a energia, a motivação, a administração dos conflitos, a confiança e o reconhecimento. Os outros fatores, 22

23 estes mais processuais, referem-se à busca do sucesso técnico, ao acompanhamento dos prazos e custos dos projetos, dos resultados, à qualidade e à visão de negócio entre projeto e empresa. Observou-se, seguindo essas características, que as equipes de projetos apresentam, em geral, grande envolvimento nos projetos (57%). Consistentemente com essa constatação foi possível notar, do lado mais processual, que as equipes se empenham em buscar sucesso técnico (72%) pelo esmero na qualidade daquilo que foi contratado (68%). Nesse ponto, embora a maioria dos respondentes afirme a existência de características que denotam certo grau de maturidade em gerenciamento de projetos, no geral a maturidade aparece como baixa A dimensão dos indivíduos Do ponto de vista dos indivíduos, os seguintes aspectos foram tratados: a carreira, as certificações profissionais, os programas de capacitação e desenvolvimento pessoal e a sua capacidade em resolução de problem as. Observou-se que as declarações sobre os indivíduos são as que apresentam maiores discordâncias e com desvios-padrões significativos. O ponto fraco foi, sem dúvida, com relação à certificação profissional em gerenciamento de projetos. Entre os respondentes, 72% das empresas não possuem estratégia definida para a certificação de seus profissionais de projetos. Destacam-se, também, a percepção quanto à falta de planejamento da carreira do gerente de projetos (em 54% dos casos), a falta de treinamento sempre que novas tecnologias e metodologias de gerenciamento de projetos são desenvolvidas (58%) e a ausência de programas de capacitação dos praticantes e gerentes de projetos (52%). No que diz respeito às certificações profissionais, números do PMI apontam uma tendência crescente. Os dados coletados na presente pesquisa parecem indicar, porém, que a busca pela certificação é uma atitude mais individual do que organizacional. Os profissionais, independentemente do apoio da organização, estão interessados nessa certificação como forma de valorização da sua carreira no mercado de trabalho. Isso mostra baixa maturidade organizacional, visto que um dos critérios de avaliação de maturidade em gerenciamento de projetos é a existência de um program a de certificação e de carreira para os gerentes de projetos. 23

24 Com parando as questões das dimensões organizações, equipes e indivíduos, talvez seja na dimensão individual na qual os respondentes parecem perceber falta de valorização da carreira do gerente de projetos que resida, na visão deles, o fato de as empresas serem pouco maduras em gerenciamento de projetos. Em outras palavras, as empresas podem ser mais maduras do ponto de vista de suas práticas organizacionais e de equipes, mas estão falhando no nível dos indivíduos e isso talvez esteja afetando a visão deles sobre o nível de maturidade organizacional Caracterização dos escritórios de projetos Visando à caracterização dos escritórios de projetos, parte-se de uma síntese própria, considerando os três modelos mais comumente relatados na literatura (foco em projeto, programa ou portfolio). Além dos modelos, questões relativas a nível organizacional, amplitude de suas responsabilidades, nível hierárquico do responsável pelo escritório e porte completaram a caracterização. Os respondentes foram ainda consultados sobre as funções exercidas pelo escritório de projetos e o impacto que esse tipo de estrutura traz para o sucesso no gerenciamento de projetos. Essas questões obtiveram a resposta de 78 participantes, pois, do total de 86 respondentes, oito (9%) afirmaram não haver em sua organização estrutura similar aos modelos apresentados. A maioria (47%) dos respondentes (gráfico 3) afirmou que sua organização opera com PMO similar ao modelo 1, ou seja, estruturas de suporte aos projetos na organização, com foco mais operacional do que tático ou estratégico. O modelo 2 foi escolhido em 30% das organizações, seguido do modelo 3 que obteve 14% das respostas. Gráfico 3: Modelos de Escritórios de Projetos Adotados pelas Organizações Pesquisadas Essas respostas são consistentes com o nível hierárquico ocupado pelos escritórios de projetos, pois 53% deles estão localizados em departamentos funcionais ou dedicados a um único time de projetos, e apenas 23% ocupam nível de divisão. Assumem nível corporativo 24% dos escritórios, o que indicaria, de acordo com a literatura, um modelo mais avançado, que se ocupa com o portfolio de projetos de 24

25 toda a empresa. O mesmo ocorre com relação ao cargo que melhor descreve a pessoa responsável pelo escritório de apenas 9% possuem nível sênior corporativo. projetos : 46% deles são gerentes, enquanto No que diz respeito ao percentual atual do total de projetos da organização que são gerenciados pelo escritório de projeto, 46% dos respondentes afirma ram que ele gerencia menos de 50% do total de projetos da organização. Para 25% dos respondentes, ele é responsável por uma faixa entre 50% e 75% dos projetos e, para 29% dos respondentes, por uma faixa entre 75% e 100% dos também é encontrada uma consistência com os modelos que mais freqüentemente foram mencionados, ou seja, não são escritórios corporativos. projetos. Aqui No que se refere às taxas de sucesso desses projetos (definidas como projetos completados no tempo, dentro do escopo e do orçamento), para a maioria (55%) elas permaneceram as mesmas. Houve uma percepção para 42% dos respondentes de que elas aumentaram e apenas para 3% elas dim inuíram. Esse aspecto ganha relevância se comparado a outro dado encontrado informando que, na maior parte dos casos (56%), o escritório de projetos não tem seu próprio orçamento, sendo financiado pelas unidades de negócio ou departamentos funcionais. Nesse caso, ele pode estar correndo o risco de ser entendido apenas como um centro de custo, sem retorno efetivo para o negócio, o que pode ameaçar sua própria existência. Ressalva importante deve ser feita em relação ao tempo decorrido desde a implementação do escritório de projetos, pois é sabido que os resultados demoram a aparecer. Uma inferência possível é que a percepção, na maioria dos casos, de que não houve mudança nas taxas de sucesso dos projetos esteja relacionada ao tempo de implem entação do escritório de projetos. Conforme verificado na literatura especializada sobre o tema, os investim entos em maior planejamento e controle dos projetos levam certo tem po para demonstrar resultados em termos de desempenho organizacional. Como essa interligação não foi estabelecida na pesquisa, é difícil avaliar se as respostas a essa questão teriam sido diferentes caso estivessem relacionadas ao tempo de implementação do escritório de projetos. Foram feitas 15 questões relativas às funções e ao papel do escritório de projetos, as quais são apresentadas na tabela a seguir. Assim como no item de maturidade organizacional em gestão de projetos, aqui também a percepção das afirmações 25

26 positivas foi feita considerando- se as declara es do tipo concorda ou concorda fortemente. J as negativas estão aderentes s declara es do tipo discorda ou discorda fortemente. Esse corte fo i feito porque, em quase todas as questões, um terço dos respondentes permaneceram na coluna central, com tendência à neutralidade das respostas. Algumas funções avaliadas referem-se a atividades com foco mais operacional e/ou tático, o que denotaria modelos de escritórios do tipo 1 e/ou 2, e outras com foco mais estratégico, o que denotaria modelos do tipo 3. No que diz respeito às funções tático-operacionais, houve concordância apenas nos aspectos relativos ao papel do escritório de assegurar que projetos similares executados com metodologia/processos consistentes sejam replicáveis (42%), garantir a conformidade dos projetos com as políticas e os processos corporativos de gestão de projetos (40%) e ter a responsabilidade pelos relatórios de progresso e realinhamento de projetos (44%). Chama a atenção o fato de que, embora a maioria dos respondentes tenha indicado a existência de modelos do tipo 1 e 2 (67%), houve maior discordância em relação às funções do escritório de projetos que caracterizariam melhor esses modelos: provimento de um padrão metodológico para gerenciar projetos (37%); condução do encerramento do projeto, comunicação e incorporação das lições aprendidas (55%); condução de processos para alocação de recursos e gestão da capacidade (42%); e a existência de mecanismos de suporte para times matriciais (44%). O oposto ocorre com as questões ligadas a um papel mais estratégico do escritório de projetos que, surpreendentemente já que a minoria indicou possuir modelos do tipo 3, apresentam índices elevados de concordância: a garantia de conformidade dos projetos com as políticas e os processos corporativos de gestão de projetos (40%); trabalhar somente com projetos relacionados aos objetivos estratégicos do negócio (50%); os projetos gerenciados pelo escritório de projetos têm relações diretas com as estratégias e os planos operacionais da organização (53%); e existência de suporte/patrocínio da alta administração (62%) A relação entre modelos de maturidade em gerenciamento de projetos e modelos de escritório de projetos 26

27 No que diz respeito à maturidade organizacional em gestão de projetos, como já dito anteriormente, as questões foram divididas em três dimensões: organização, equipes e indivíduos. O gráfico 4 mostra uma comparação entre as médias das notas obtidas dos modelos 1, 2 e 3 com as médias encontradas somando -se todos os respondentes. Para as questões relativas à organização, na m édia geral há poucos aspectos que apresentam baixa concordância e, conseqüentemente, baixo nível de maturidade. São eles: uso de técnicas de gerenciamento de riscos (2,74), existência de programa visando melhorar a maturidade em gerenciamento de PRojetos (2,80) e existência de um guia para ajudar os gerentes de projetos e praticantes no gerenciamento de projetos (2,77). Um dado importante é que, na maioria das questões, conforme aumenta a complexidade do escritório de projetos (de nível 1 até nível 3), aumenta o nível de concordância dos respondentes. Isso parece indicar uma relação positiva entre o nível de maturidade organizacional e os modelos, ou seja, modelos mais avançados de escritórios promovem elevação dos níveis de maturidade organizacional em gestão de projetos. Essa tendência só não se confirma nas questões relativas a: comunicação aberta em todos os níveis; existência de um guia para ajudar os gerentes deprojetos e praticantes no gerenciamento de projetos ; apoio adequado da gerência geral aos gerentes de projetos ; e existência de sistema de gerenciamento de porfolio de projetos, em que, inesperadamente, o modelo 1 apresenta m aior grau de concordância em relação ao modelo 2. Os escritórios de projetos configurados como modelo 3 apresentaram os maiores níveis de domínio, tanto de capacitação e competências organizacionais quanto de equipes e indivíduos. Ressalta-se, porém, que isso não deve indicar que todas as empresas devam adotar esse tipo de modelo. Dada sua sofisticação, a implementação é mais complexa e deve ser adotada por empresas nas quais os projetos sejam, de fato, um diferencial competitivo para o negócio. Analisando-se as questões de maturidade organizacional na dimensão das equipes (gráfico 5), percebe-se que, na maioria delas, há um bom índice de concordância em quase todos os aspectos (médias acima de 3,00). Embora importantes do ponto de 27

28 vista da maturidade organizacional em gestão de projetos, os itens relativos a cumprimento e controle de prazos e orçamentos planejados no projeto, bem como clareza quanto aos resultados de cada fase do projeto, apresentam índice de concordância relativam ente baixo (média de 2,85 e 2,95, respectivamente). Percebe-se que não há tendência clara de aumento na média de concordância, da mesma forma que se observou na tabela referente aos aspectos da organização. Por exemplo, na questão sobre busca do sucesso técnico na equipe como aspecto fundamental para seu desenvolvimento, o modelo 3 apresenta média de concordância discretamente menor (3,42) do que o modelo 2 (3,67). O mesmo ocorre com a questão que avalia se a equipe de projetos especifica e busca qualidade baseada no que foi especificado (média de 3,64 no modelo 2 e de 3,18 no modelo 3). Disparidades também ocorrem quando se comparam as médias apresentadas pelo modelo 2 com aquelas apresentadas pelo modelo 1. Em alguns casos, o modelo 1 apresenta médias superiores como, por exemplo, no que diz respeito à capacidade de a equipe seguir rigorosam ente os prazos e orçamentos planejados no projeto e fazer controle dos prazos e orçamentos (média de 2,82 no modelo 1 e de 2,77 no modelo 2). Outro aspecto dissonante é relativo ao fato de a equipe saber exatamente quais os resultados de cada fase do projeto (média de 3,70 para o modelo 1 contra média 3,00 para o modelo 2). O exame desses dados parece indicar que, pelo menos no que tange às equipes, não há uma relação clara entre graus de maturidade e modelos de escritórios de projetos. As questões relativas aos indivíduos que atuam em gerenciamento de projetos (gráfico 6) apresentam, na grande maioria, níveis baixos de concordância quando se analisam as médias obtidas no conjunto dos respondentes. Chama a atenção, particularmente, o fato de as empresas parecerem não ter ainda programas formais visando à certificação profissional de seus gerentes de projetos (média 1,98). Isso parece indicar que, no tocante à valorização dos indivíduos, as organizações são pouco maduras em gerenciamento de projetos. Porém, um fator positivo é que, na maioria dos casos, apesar de as médias encontradas permanecerem em níveis baixos de concordância, a simples existência de um escritório de projetos eleva-as, e elas aumentam, sensivelmente, no m odelo 3. Essa análise corrobora a literatura, pois indica que a existência de uma casa para os gerentes de projetos aumenta a visibilidade dessa disciplina no seio das organizações. 28

29 5. CONFRONTANDO OS DADOS COM OUTRAS PESQUISAS Estudos dessa natureza foram realizados recentemente, mostrando aspectos semelhantes e divergentes, mas todos são, o entanto, bastante interessantes, sobretudo quando se trata de perspectivas. Nessa direção, vale a pena construir um quadro com parativo entre as pesquisas. Para apresentar os primeiros elementos de análise, serão considerados os resultados da pesquisa de Block e Frame (2001) realizada com 74 respondentes em Esses autores concluíram que os escritórios de projetos irão continuar despertando o interesse das empresas, uma vez que os executivos enxergam a importância de gerar práticas repetitivas em termos de gerenciamento de projetos. A pesquisa aqui relatada revelou que os serviços oferecidos pelo escritório de projetos podem ajudar os gerentes a conseguir sucesso, inclusive de cunho estratégico, no âmbito das em presas. Analogamente, é possível notar que o setor de tecnologia de informação foi o mais incidente nas duas pesquisas; no trabalho de Block e Frame (2001), ele representou em torno de 27% e, nesta pesquisa, 17%. Isoladamente, tecnologia de informação foi o setor mais incidente em ambas as pesquisas. Faz-se necessário ressaltar que o setor industrial, que aparece com pesquisa, foi constituído pelo somatório de diversas indústrias. 30% nesta A pesquisa de Block e Fram e (2001) não fez distinção entre modelos de escritórios de projetos, mas ambas as pesquisas consideraram o apoio da alta administração como elemento crucial para obtenção de sucesso em seus empreendimentos. A maior distinção obtida diz respeito às necessidades percebidas. Na pesquisa de Block e Frame (2001), os serviços esperados dos escritórios de projetos referem-se a questões de caráter tático (suporte), como métodos e processos, consultoria, mentoring, treinamento e auxílio a projetos, enquanto a pesquisa apresentada neste trabalho revelou que os entrevistados estão mais preocupados com serviços de cunho estratégico, ou seja, apoio à alta administração, desenvolvimento da carteira de projetos (portfolio) e busca de alinhamento estratégico dos projetos. Observou-se ainda, que para Block e Frame (2001) o sucesso dos escritórios de projetos refere-se a pessoal competente, experiência da empresa e desempenho do projeto; no caso desta pesquisa, o sucesso está atrelado ao posicionamento do 29

30 escritório, ao suporte dado pelos gerentes funcionais e à realização do grande volume de trabalho esperado. Os dados do trabalho de Block e Frame (2001), quando confrontados com os desta pesquisa, mostraram que os escritórios de projetos fazem parte das preocupações das várias camadas organizacionais das empresas abordadas. Para aumentar a análise e fundamentar melhor as questões sobre os escritórios de projetos, vale a pena m encionar o trabalho desenvolvido no âmb ito do chapter do PMI Project Management Institute do Rio de Janeiro (PMI, 2004). A pesquisa, desenvolvida com o intuito de estabelecer um quadro das experiências em gerenciamento de projetos nas empresas brasileiras, tratou de oito aspectos relevantes, incluindo os escritórios de projetos. O setor de tecnologia de informação aparece também com maior incidência nesta pesquisa (33%, incluindo o setor de telecomunicações). Dentre as empresas pesquisadas, somente 11% declararam que a implementação de escritór ios de projetos não faz parte de seus planos; as demais, ou estão implementando ou estão prestes a implementar. Esse cenário pode ser comparado com os dados obtidos por esta pesquisa, na qual se constatou que apenas 10% não farão investimentos em implementação de escritório de projetos no próximo ano. Em ambos os estudos, foi possível notar o crescimento do número de empresas que devem optar por gerenciamento de projetos para conduzir suas atividades nãorotineiras. A pesquisa elaborada pelo PMI (2004) mostrou que as funções e os papéis mais comuns dos escritórios de projetos referem-se a estabelecimento de metodologia, padrões e ferramentas. O apoio à alta administração ocorre como a quinta função percebida pela pesquisa. Esses dados mostram que existem, portanto, visões distintas dos respondentes das duas pesquisas, uma vez que o apoio à alta administração aparece como elemento primordial percebido neste trabalho. 6. CONCLUSÃO Neste artigo, o objetivo principal foi investigar o grau de maturidade das organizações e a relação dele com a existência de escritório de projetos, os modelos de escritórios de projetos adotados, as funções que exercem etc. Como 30

31 objetivo secundário, buscou-se entender como os escritórios de funcionando hoje no Brasil. A pesquisa realizada com 86 profissionais da área de gerenciamento de projetos estão projetos de organizações de variados setores da economia indicou que as empresas possuem maturidade mais elevada no que diz respeito às questões organizacionais e das equipes, o mesmo não ocorrendo no tocante à valorização dos indivíduos. Confrontados diretamente com a questão a organiza ão tem um programa visando melhorar a sua maturidade em gerenciamento de projetos?, 43% dos respondentes declararam ser ela ainda incipiente e que, realmente, não foram diagnosticados avanços na implementação de processo de gerenciamento de projetos (46%). Essa percepção parece estar distorcida quando comparada aos resultados encontrados para os aspectos relativos à organização e às equipes, que foram claramente positivos. Pode-se inferir que a falta de cuidado das empresas com relação aos seus profissionais pode causar impacto negativo quanto à percepção deles a respeito da m aturidade de suas organizações em de projetos. Outro fator que pode ter causado essa distorção refere-se ao tempo de implementação do escritório de planejamento e controle dos gerenciamento projetos. Os resultados dos investimentos em maior projetos demoram, em geral, a aparecer e, quando aparecem, nem sempre estão relacionados à existência do escritório de projetos. Outra discrepância observada diz respeito à gestão dos riscos. Parece existir, nesse caso, um hiato entre a literatura e a prática das organizações. Embora vários autores apontem a adequada gestão dos riscos como um indicador de maturidade em gestão de esse aspecto. projetos, a pesquisa indicou um baixo índice de atenção das empresas a Ao se compararem os níveis de maturidade em gerenciamento com os modelos de escritórios de escritórios de projetos adotados, ficou evidente que os modelos mais avançados de projetos afetam positivam ente a maturidade organizacional em gestão de projetos. O mesmo não foi observado quando questões relativas às equipes foram estudadas. Nas questões referentes aos indivíduos, ainda que quase todas apresentassem níveis de concordância baixos, a existência de escritório de elevou o nível de concordância para patamares superiores. Portanto, parece que o projetos escritório de projetos pode ajudar as organizações a atingir maior maturidade em 31

32 gerenciamento de projetos, principalm ente aquelas em que o tema é visto como uma com petência organizacional. O estudo, no intuito de aprofundar algumas questões, buscou dados em pesquisas atuais, realizadas recentemente, confrontando seus dados. A maior evidência percebida foi com relação às perspectivas dos respondentes dos outros trabalhos: enquanto o nível de preocupação deste estudo foi caracterizado como mais estratégico, as preocupações dos demais ficaram no âmbito mais tático. O estudo evidenciou uma série de aspectos relativos à gestão de projetos nas organizações que podem ser úteis para as empresas e para estudos futuros. Contudo, obviamente, ele tem limitações, uma vez que o sistema de amostragem escolhido não permite generalizações para a população. Há, ainda, lim itações no que diz respeito à segmentação por setores. Talvez a realidade apresentada pudesse ser diferente caso os respondentes tivessem sido separados por setores. Por exemplo, teria a área de Telecomunicações um comportamento diferente do que foi aqui apresentado? Da mesma forma, uma outra variável que poderia interferir nos resultados e que poderia ter sido tratada de forma segmentada é o quanto os projetos interferem no faturamento das empresas. A pesquisa indicou alto grau de desconhecimento dos gerentes de projetos em relação a esse dado: 43% deles dizem que não sabem dos investimentos atuais e 61% desconhecem quantos recursos serão investidos no futuro próximo (daqui a um ano, como foi perguntado). Investigar os motivos desse desconhecimento pode ser tema de futuras pesquisas. 32

33 ESTENDENDO O SCRUM SEGUNDO AS ÁREAS DE PROCESSO DE GERENCIAMENTO DE PROJETOS DO CMMI Ana Sofia Cysneiros Marçal Universidade de Fortaleza, Mestrado em Informática Aplicada Fortaleza - CE, Brasil, C.E.S.A.R Centro de Estudos e Sistemas Avançados do Recife Recife - PE, Brasil, Bruno Celso Cunha de Freitas, Felipe Santana Furtado Soares, Teresa Maria Medeiros Maciel C.E.S.A.R Centro de Estudos e Sistemas Avançados do Recife Recife - PE, Brasil, {bruno.freitas, felipe.furtado, Arnaldo Dias Belchior Universidade de Fortaleza, Mestrado em Informática Aplicada Fortaleza - CE, Brazil, RESUMO No mercado de desenvolvimento de software há uma forte tendência para o desenvolvimento ágil de aplicações devido a um ritmo acelerado de mudanças. Este contexto tem causado crescentes frustrações nas organizações devido aos planos, especificações e documentações pesados, muitas vezes im postos por critérios de conformidade dos modelos de maturidade. Organizações de desenvolvimento de software que vinham adotando modelos de capacidade de maturidade com o o CMMI para a melhoria de seus processos estão cada vez mais interessadas na possibilidade de adoção de métodos ágeis. Este trabalho apresenta uma abordagem do método ágil Scrum com patível com áreas de Gerenciamento de Projetos do CMMI aplicada em uma organização de inovação e pesquisa no desenvolvimento de projetos de software. A extensão proposta para o Scrum pode contribuir de forma relevante para organizações que têm o propósito de adotar uma metodologia de gerenciamento de projetos ágil e que esteja compatível com práticas do CMMI. Palavras chave: Scrum, Medodologias Ágeis, CMMI, Gerenciamento Ágil de Projetos. 33

34 Introdução De acordo com Boehm [6], a partir de 2000 estamos vivendo uma tendência para o desenvolvimento ágil de aplicações devido a um ritmo acelerado de mudanças e inovações na tecnologia da informação, em organizações e no ambiente de negócios. Esse ritmo acelerado de mudanças tem causado frustrações crescentes com planos, especificações e docum entações pesados muitas vezes impostos por critérios de conform idade dos modelos de maturidade. Boehm [6] ainda cita que no final dos anos 90 acompanhamos o surgimento de vários métodos ágeis, entre eles: Adaptive Software Development, Crystal, Dynamic Systems Development, extreme Programming (XP), Feature Driven Development e Scrum. Todos esses métodos empregam princípios ágeis, tais como ciclos iterativos, entrega rápida de software funcionando e simplicidade, como definido no Manifesto para Desenvolvimento Ágil [7] publicado em A e ssência desse movimento é a definição de novo enfoque de desenvolvimento de software, calcado na agilidade, na flexibilidade, nas habilidades de comunicação e na capacidade de oferecer novos produtos e serviços de valor ao mercado, em curtos períodos de tempo [14]. Ao lado do manifesto ágil, surge também o APM (Agile Project Management) que representa um conjunto de valores, princípios e práticas, que auxiliam a equipe de projeto a entregar produtos ou serviços de valor em um ambiente desafiador [14]. Com o agilidade deve- se entender a habilidade de criar eresponder a mudanças, buscando a obten ão de lucro em um ambiente de negócio turbulento ; ou ainda, a capacidade de balancear a flexibilidade e a estabilidade [14]. Métodos, práticas e técnicas ágeis para desenvolvimento de software prometem incrementar a satisfação do cliente [5] produzindo software com maior qualidade e acelerando o tempo de desenvolvimento [3]. Assim sendo, organizações que empregaram um grande esforço na m elhoria dos seus processos baseadas no CMMI (Capability Maturity Model Integration) [19], agora tam bém acreditam que abordagens ágeis possam prover incrementos de melhorias [15]. Apesar da existência de características distintas entre os m étodos ágeis e o modelo CMMI, ambos possuem planos específicos para o desenvolvimento de software e buscam o melhor para que a organização produza software com qualidade [22]. 34

35 Davis [10] relata que, apesar de existir um a grande controvérsia entre a compatibilidade de ADM (Agile Development Methods) e o CMMI, eles não são mutuamente exclusivos. Complementa, explicando que há um lugar para ADM no CMMI e, o mais importante, aqueles que adotaram o CMMI, podem considerar a adição de ADM em seus processos. O caminho para alcançar mais agilidade com o CMMI é perceber que as práticas são primariamente consultivas ou indicativas e, que para corresponder a uma avaliação do CMMI, uma organização deve demonstrar que as metas de uma área de processo estão sendo alcançadas através de evidências de práticas [4]. Inserido neste contexto de controvérsias e compatibilidades entre CMMI e métodos ágeis, este trabalho apresenta uma extensão do Scrum segundo as áreas de Gerenciamento de Projetos do CMMI. Este estudo se inicia com um mapeamento entre o Scrum e o CMMI, avaliando-se o atendimento das práticas específicas do modelo restrito ao escopo de gestão de projetos. A partir desta avaliação, sugerese a adoção de práticas com plementares visando deixar o Scrum mais com patível com o CMMI, sem, no entanto, perder seus princípios ágeis. A extensão proposta para o Scrum pode contribuir de forma relevante para organizações que têm o propósito de adotar uma metodologia de gerenciamento de projetos ágil e que esteja compatível com práticas do CMMI. Este trabalho está organizado da seguinte maneira: a Seção 2 apresenta uma visão geral CMMI; na Seção 3, é provida uma visão geral do Scrum; a Seção 4 compreende a análise realizada entre o Scrum e as práticas de gerenciamento de projetos do CMMI; na Seção 5, propõem-se extensões para o Scrum visando um maior grau de atendimento às práticas do CMMI; na Seção 6, realiza -se uma aplicação prática dessa proposta em um ambiente real de desenvolvimento de software. Finalmente, a Seção 7 apresenta as conclusões deste trabalho. 2 Enfoques sobre o CMMI O CMMI-DEV [19] é uma abordagem de melhoria de processos que provê elementos essenciais para um processo efetivo. Reúne melhores práticas que endereçam atividades de desenvolvimento e manutenção, cobrindo todo o ciclo de vida de produto desde a sua concepção até a sua entrega e manutenção. É 35

36 apresentado em duas representações: em estágios ou contínua. Cada representação organiza diferentemente as áreas de processo. A representação contínua agrupa as áreas de processo por categorias de afinidade, com atribuição de níveis de capacidade para a melhoria de processos em cada área de processo. A representação em estágios, por sua vez, organiza as áreas de processo em 5 níveis de maturidade para suportar e guiar a melhoria dos processos. As áreas de processos podem ser agrupadas tam bém em quatro categorias: Gerenciamento de Processos, Gerenciamento de Projetos, Engenharia, e Suporte. Na categoria de Gerenciamento de Projetos, são englobadas atividades de gestão relacionadas com planejamento, monitoração e controle do projeto sendo composta pelas áreas de processo: nível 2 - Planejamento do Projeto (PP), Monitoramento e Controle do Projeto (PMC), Gerenciamento de Acordos com Fornecedores (SAM); nível 3 - Gerenciamento de Riscos (RSKM) e Gerenciamento Integrado do Projeto (IPM) + Desenvolvimento Integrado do Produto e do Processo (IPPD); nível 4 - Gerenciamento Quantitativo do Projeto (QPM). 3 Enfoques sobre o SCRUM O Scrum é um método que aceita que o desenvolvimento de software é imprevisível e formaliza a abstração, sendo aplicável a ambientes voláteis [1]. Ele se destaca dos demais métodos ágeis pela maior ênfase dada ao gerenciamento do projeto. Reúne atividades de monitoramento e feedback, em geral, reuniões rápidas e diárias com toda a equipe, visando à identificação e correção de quaisquer deficiências e/ou impedim entos no processo de desenvolvimento [21]. O Scrum assume a premissa de que o desenvolvimento de software é muito complexo e imprevisível para ser planejado totalmente inicialmente. Ao invés disso, deve-se usar controle do processo empírico para garantir a visibilidade, inspeção e adaptação [20]. O método baseia-se ainda, em princípios como: equipes pequenas de, no máximo, 7 pessoas; requisitos que são pouco estáveis ou desconhecidos; e itera ções curtas. Divide o desenvolvimento em intervalos de tem pos de no máximo 30 dias, também chamados de Sprints. 36

37 3.1 Papéis e Responsabilidades O Scrum implementa um esqueleto iterativo e incremental através de três papéis principais [20]: Product Owner: representa os interesses de todos no projeto; define os fundamentos do projeto criando requisitos iniciais e gerais (Product Backlog), retorno do investimento (ROI), objetivos e planos de entregas; prioriza o Product Backlog a cada Sprint, garantindo que as funcionalidades de maior valor sejam construídas prioritariamente. ScrumMaster: Gerencia o processo do Scrum, ensinando o Scrum a todos os envolvidos no projeto e implementando o Scrum de modo que esteja adequado a cultura da organização; deve garantir que todos sigam as regras e práticas do Scrum; é responsável por remover os impedimentos do projeto. Time: desenvolve as funcionalidades do produto; define como transformar o Product Backlog em incremento de funcionalidades numa iteração gerenciando seu próprio trabalho sendo responsáveis coletivamente pelo sucesso da iteração e conseqüentemente pelo projeto como um todo. 3.2 Fases do Scrum O Scrum possui um ciclo de vida composto por 4 fases [16] [2]: Planejamento: estabelecer a visão do projeto e expectativas garantindo recursos para a sua execução. Nesta fase são criadas as versões iniciais do Product Backlog e o plano de release, arquitetura de negócio e técnica em alto nível. Stagging: avaliar as várias dimensões do projeto criando itens adicionais ao Product Backlog relacionados com o tipo do sistema, time, ambiente de desenvolvimento, tipo de aplicação. Nesta fase os Times são formados e são construídos os mecanismos de comunicação e coordenação entre eles. Desenvolvimento: consiste de múltiplas Sprints para o desenvolvimento dos incrementos de funcionalidade do produto. Releasing: realizar a entrega do produto ao cliente. 3.3 Fluxo de Desen volvimento 37

38 No Scrum, um projeto se inicia com uma visão do produto que será desenvolvido [20]. A visão contém a lista das características do produto estabelecidas pelo cliente, além de algumas premissas e restrições. Em seguida, o Product Backlog é criado contendo a lista de todos os requisitos conhecidos. O Product Backlog é então priorizado e dividido em releases. O fluxo de desenvolvimento detalhado do Scrum é mostrado na Figura 1. Figura 1. Visão geral do processo do Scrum (adaptada de [12]) No Scrum, são realizadas iterações chamadas de Sprints. Schwaber [20] explica que cada Sprint inicia-se com uma reunião de planejamento (Sprint Planning Meeting), na qual o Product Owner e o Time decidem em conjunto o que deverá ser implementado (Selected Product Backlog). A reunião é dividida em duas partes. Na primeira parte (Sprint Planning 1), o Product Owner apresenta os requisitos de maior valor e prioriza aqueles que devem ser implementados. O Tim e então define colaborativamente o que poderá entrar no desenvolvimento da próxima Sprint, considerando sua capacidade de produção. Na segunda parte (Sprint Planning 2), o time planeja seu trabalho, definindo o Sprint Backlog, que são as tarefas necessárias para implementar as funcionalidades selecionadas no Product Backlog. Nas primeiras Sprints, é realizada a maioria dos trabalhos de arquitetura e de infra-estrutura. A lista de tarefas pode ser modificada ao longo da Sprint pelo Time e as tarefas podem variar entre 4 a 16 horas para a sua conclusão. Na execução das Sprints, diariamente o time faz uma reunião de 15 minutos para acompanhar o progresso do trabalho e agendar outras reuniões necessárias. Na reunião diária (Daily Scrum Meeting), cada membro do time responde a três perguntas básicas: O que eu fiz no projeto desde a última reunião? O que irei fazer até a próxim a reunião? Quais são os impedimentos? Ao final da Sprint, é realizada a reunião de revisão (Sprint Review Meeting) para que o Time apresente o resultado alcançado na iteração ao Product Owner. Neste m omento as funcionalidades são inspecionadas e adaptações do projeto podem ser realizadas. Em seguida o ScrumMaster conduz a reunião de retrospectiva (Sprint Retrospective Meeting), com o objetivo de melhorar o processo/time e/ou produto para a próxima Sprint. O monitoramento do progresso do projeto é realizado através de dois gráficos principais: Product Burndown e Sprint Burndown. Estes gráficos, mostram ao longo 38

39 do tempo a quantidade de trabalho que ainda resta ser feito, sendo um excelente mecanismo para visualizar a correlação entre a quantidade de trabalho que falta ser feita (em qualquer ponto) e o progresso do time do projeto em reduzir este trabalho. 4 Scrum versus Áreas de Gerenciamento de Projetos do CMMI Neste trabalho, a avaliação do Scrum nas práticas do modelo CMMI corresponde a: Planejamento do Projeto (PP), Monitoramento e Controle do Projeto (PMC), Gerenciamento Integrado do Projeto (IPM) + Desenvolvimento Integrado do Produto e do Processo (IPPD) e Gerenciamento de Riscos (RSKM). Estas áreas de processo compõem os níveis 2 e 3 de maturidade da representação por estágios do modelo, versão 1.2, na categoria de Gerenciamento de Projetos. Foram excluídas do escopo deste trabalho Gerenciamento de Acordos com Fornecedores (SAM) e Gerenciamento Quantitativo do Projeto (QPM), porque estas áreas de processo nem sempre são aplicadas a todas as organizações e têm uma importância m enor dentro do contexto de gestão de projetos ágeis. Para cada uma das Áreas de Processo do escopo foi realizada uma análise detalhada entre suas práticas específicas e as práticas gerenciais do Scrum classificando cada prática de acordo com os critérios definidos na Tabela 1. A prática está totalmente atendida no Scrum. Após a fase de classificação, foi calculado o percentual de satisfação de cada área de processo entre critérios definidos, tomando como base o número total de práticas específicas da área de processo. Em seguida, os resultados foram agrupados e foi gerada uma visão consolidada da cobertura do Scrum nas áreas de processo PP, PMC, RSKM e IPM + IPPD. Nas subseções seguintes são apresentados, para cada área de processo do escopo do trabalho, os resultados gerais da análise realizada enfatizando os pontos nos quais o Scrum atende ou não diretamente as práticas do CMMI. Uma análise detalhada por subprática pode ser encontrada em Marçal [17]. 4.1 Análise do Planejamento do Projeto 39

40 No Scrum, a definição do escopo inicial do projeto ocorre durante a fase de Planejamento onde todos os stakeholders podem contribuir com a criação do Product Backlog. Juntos, o documento de Visão e Product Backlog formam a base para a elaboração de um plano de projeto em alto nível compatível com a volatilidade de projetos ágeis. O comprom etimento do plano é realizado continuamente no início de cada iteração, durante a Sprint Planning Meeting. O Product Owner, ScrumMaster, e time em comum acordo, definem as prioridades do Product Backlog para cada Sprint e determinam que funcionalidades o time irá trabalhar na próxima Sprint. As estimativas são realizadas em 2 níveis: Product Backlog e Sprint Backlog. As estimativas do Product Backlog são pouco precisas, de alto nível, tendo como propósito oferecer uma visibilidade do esforço de cada requisito. Já as estimativas do Sprint Backlog são mais precisas. Entretanto, as estimativas de esforço realizadas no Scrum não necessariamente seguem um método formal, nem tampouco são derivadas de um tamanho ou complexidade como sugerido pelo modelo CMMI. Apesar de fazer menção ao uso de dados estimados em Sprints passadas, o Scrum não reforça a utilização de uma base histórica organizacional. O custo não é mencionado explicitamente no processo, mas somente o esforço, apesar de o custo ser necessário para o cálculo do orçamento do projeto e financiamento do mesmo pelo Product Owner. A partir do Product Backlog, é capturado o cronograma que é priorizado é subdividido em Sprints considerando a alocação do time de acordo com sua capacidade de produção. O cronograma é então automaticamente obtido após esta divisão, considerando o número total de Sprints do projeto, já que cada Sprint tem a duração de 30 dias. A reconciliação do trabalho é realizada durante da Sprint Planning, quando o time, define, em conjunto com o Product Owner e ScrumMaster o máximo de funcionalidades que poderá ser implementada na Sprint. A alocação do time e preparação da infra-estrutura do projeto são realizadas no início do projeto durante a fase de Stagging [2]. No Product Backlog são adicionados os recursos necessários ao desenvolvimento, tais como: máquinas, ferramentas e demais investim entos necessários para a configuração do ambiente de desenvolvimento. Além disso, o ScrumMaster é o responsável por prover os 40

41 recursos necessários ao longo do projeto de acordo com necessidades e impedim entos que são reportados nas reuniões diárias. O time, que é um grupo multifuncional, auto-gerenciado, deve na medida do possível ser configurado considerando as melhores pessoas, isto é, aquelas com maiores conhecim entos e habilidades (técnicos e de negócio) que são necessários para implementar o Sprint Backlog. Mas, se isso não é possível, necessidades de capacitação são incluídas no Product Backlog. Uma vez que no Scrum um risco é um possível im pedimento para o projeto, a identificação dos riscos é realizada de forma iterativa, durante as reuniões diárias do time sendo documentados em whiteboards, flipcharts e na lista de impedimentos (Impediment Backlog). Apesar de a identificação dos riscos ocorrer iterativamente, esta não ocorre, no entanto, de forma param etrizada e sistemática, utilizando, por exemplo, categorias e fontes de riscos como indicado no CMMI. Considerando-se o aspecto da comunicação, percebe-se que as práticas e regras definidas no Scrum contribuem para uma boa comunicação e colaboração entre o time e os stakeholders, bem como para a visibilidade da condução e progresso do projeto. Os dados gerados no projeto podem ser colocados em uma pasta pública acessível por todos [20]. Muitas das informações do projeto são comunicadas face-a-face nas reuniões e outras são comunicadas através de documentos, e outras através de relatórios de progresso gerados ao final de cada Sprint. Entretanto, não existe um plano de comunicações que formalize como serão realizadas as coletas, consolidação e divulgação das informações e dados do projeto. A privacidade dos dados também fica comprometida. A Tabela 2 mostra o resultado final da classificação de cada prática específica da área de processo PP. 4.2 Análise do Monitoramento e Controle do Projeto O monitoramento do projeto é feito efetivamente através dos gráficos de Burndown e das reuniões de acompanhamento mencionadas anteriormente. O Product BurnDown mostra a velocidade com que o time está entregando os itens do Product Backlog. É analisado a cada término de Sprint. Ajuda a monitorar o planejamento das entregas das funcionalidades dando visibilidade se conseguiremos entregar o 41

42 release ou se deveremos negociar a retirada de requisitos para conseguir entregar o release na data planejada. Já o Sprint Burndown mostra diariamente ao time a velocidade e progresso da evolução das suas tarefas em uma Sprint, dando visibilidade se o time irá concluir suas tarefas no final da Sprint. O Sprint Burndown provê uma ferramenta de apoio ao planejamento de ações corretivas que são tomadas no projeto. As reuniões de acompanhamento, sobretudo as reuniões diárias, permitem acompanhar o dia-a-dia de trabalho do time e perceber as dificuldades existentes para a realização das tarefas planejadas. Estas dificuldades devem ser rapidamente sanadas pelo ScrumMaster para que o time não perca seu foco e comprometa o objetivo da Sprint. Apesar disso, como as estimativas de custo, tamanho e esforço não são realizadas de maneira sistemática, não há um acompanhamento como solicitado no modelo CMMI. O envolvimento dos stakeholders é monitorado naturalmente durante as reuniões do projeto, através do ScrumMaster, que é o responsável pelo entendimento e respeito às regras e práticas definidas no processo Scrum devendo fazer com que todos os envolvidos no projeto entendam suas práticas e regras. Apesar de não haver registro de documentação do m onitoramento realizado. Os compromissos de cada Sprint são estabelecidos durante a Sprint Planning, monitorados durante a execução da Sprint através da Sprint Burndown e das reuniões diárias e revistos na Sprint Retrospective. Durante uma Sprint, o time não pode receber trabalho adicional dos stakeholders e/ou Product Owner. Apenas o time pode alterar o Sprint Backlog o qual deve manter foco initerrupto na realização das tarefas da Sprint. Assim, as reuniões diárias buscam levantar impedimentos (problem as, dependências, riscos, etc.). Logo há uma identificação e monitoramento dos impedim entos pelo ScrumMaster. Entendemos que no Scrum as ações corretivas para os impedimentos levantados são tomadas. Entretanto não há registro de planos de ações corretivas, nem de documentação relativa a isso, nem tampouco análise de resultados para determinar a eficácia das ações corretivas tom adas. 42

43 Não há procedimento e planejamento formal no Scrum para a gestão dos dados do projeto o que prejudica o comprometimento do monitoramento dos dados como solicitado no CMMI. A Tabela 3 mostra o resultado final da classificação de cada prática específica da área de processo PMC. 4.3 Análise do Gerenciamento Integrado do Projeto + IPPD Não é definido no Scrum um conjunto de processos padrões para a organização, apenas estabelece o conjunto de práticas e regras que devem ser usadas na execução do projeto, bem como atividades e caminhos que devem ser seguidos de acordo com o tipo do projeto. Também não há nenhuma menção a estabelecimento e manutenção de um processo definido para o projeto, uso de base histórica de projetos e ativos do processo organizacional para realização do planejamento e estimativa do projeto, integração entre planos bem medições e experiências para o processo organizacional. como contribuições com produtos de trabalho, Quando mais de um time trabalha simultaneamente no projeto, o projeto é chamado de projeto escalonado e os mecanism os usados para coordenar o trabalho desses times são chamados de mecanismos escalonados. Algumas práticas são críticas para o sucesso de projetos escalonados, dentre as quais [20]: Construa a infra -estrutura para o escalonamento antes de escalonar o projeto, que deve ser implementada por um único time inicial, em Sprints sucessivas até que a infra-estrutura esteja completa. Requisitos não funcionais para construir a infraestrutura do escalonamento devem ser adicionados ao Product Backlog e devem ser priorizados juntamente com outras funcionalidades de negócio na fase de Stagging do Scrum, que antecede a primeira Sprint; Sempre entregue valor de negócio nas itera es que estão sendo realizadas para a construção da infra-estrutura; Aperfei oe as capacidades do time inicial e depois forme os times adicionais. Os times adicionais devem possuir, no mínimo, 1 membro do time inicial, atuando como especialista da infra-estrutura e arquitetura. Estas práticas em conjunto, de certa forma estabelecem os requisitos necessários para o trabalho de times integrados do CMMI. A Tabela 4 mostra o resultado final da classificação de cada prática específica da Área de processo IPM + IPPD. 43

44 4.4 Análise do Gerenciamento de Riscos A identificação de riscos no Scrum é realizada como impedim entos durante as reuniões diárias, porém não existem práticas explícitas para definir fontes, parâmetros e categorias de riscos que devem ser usados para analisar, categorizar bem com o para controlar o esforço do gerenciamento dos riscos. Também não há uma estratégia para o gerenciamento dos riscos, nem mesmo um plano de mitigação para os riscos mais importantes e uso de bases históricas. Assim sendo, a avaliação, categorização e priorização dos riscos ficam comprometidas. Para essa área de processo, todas as práticas específicas foram consideradas Não Satisfeitas, à exceção da prática SP 2.1 Identificar Riscos que foi considerada como Parcialmente Satisfeita. 4.5 Resultados da Avaliação Na Figura 2, são apresentados os resultados gerais da avaliação realizada através de uma visão consolidada da cobertura do Scrum nas áreas de processo de PP, PMC, RSKM e IPM+IPPD da categoria de gerenciamento de projetos do CMMI. Figura 2. Cobertura do Scrum nas Áreas de Processo PP, PMC, RSKM e IPM+IPPD Considerando-se estes resultados, tem-se que 44,4% das práticas específicas encontram-se na categoria Satisfeito, 22,2% na categoria Parcialmente Satisfeito e 33,3% na categoria Não Satisfeito. Percebe-se também que este resultado deve-se principalmente a: Ausência de t cnicas ou pr ticas alternativas para a realiza ão das estimativas do projeto. Isto afeta diretamente práticas de PP (SP 1.2 e 1.4) e PMC (SP 1.1). Ausência de um melhor gerenciamento dos riscos, impactando práticas de RSKM (todas), PP (SP 2.2) e PMC (SP 1.3). Lacunas no gerenciamento de ações corretivas de problemas e dependências, afetando as práticas relacionadas com o objetivo SG 2 de PMC e práticas de IPM (SP 2.2. e SP 2.3). Lacunas no planejamento e gerenciamento do orçam ento do projeto, o que compromete práticas de PP(SP 2.1) e PMC (SP 1.1). Ausência de um planejam ento e monitoramento dos dados do projeto, impactando a aderência às práticas de PP (SP 2.3) e PMC (SP 1.4). 44

45 Lacunas no gerenciamento integrado do projeto devido à ausência de um processo integrado e definido que é adaptado a partir do conjunto de processos padrão da organização, conforme definido no objetivo SG1 de IPM + IPPD. Além disso, as descobertas da avaliação revelam que parte das lacunas encontradas está relacionada com a falta de documentação (evidências escritas) na execução das atividades. Isto se deve a um dos valores do manifesto ágil que enfatiza Software funcionando sobre documenta ão com preensiva, significando que o nível de documentação deve ser definido como o mais baixo possível. Entretanto, isso pode ser revisto, de forma que alguma documentação simples possa ser introduzida no Scrum, deixando-o assim mais em conformidade com o modelo CMMI. Práticas alternativas também podem ser analisadas e implementadas, o que aumentaria o grau de adequação do Scrum ao CMMI. Estas práticas, no entanto, precisam ser criticamente analisadas quanto ao seu atendimento ao modelo. 5 Estendendo o Scrum Neste trabalho, a proposta de extensão do Scrum não abrange todas as lacunas do Scrum em relação às práticas de gerenciamento de projetos do CMMI. Focamos inicialmente na resolução das fraquezas relacionadas com as práticas de estimativas, gerenciamento de riscos e gerenciamento de problemas e suas ações corretivas, pois acreditamos que este subconjunto contribui para uma grande variação no resultado de cobertura do Scrum no CMMI. Posteriormente, esta proposta deverá complementada, visando compatibilidade plena do Scrum com as áreas de processo PP, PMC, RSKM e IPM + IPPD do CMMI. 5.1 Práticas para Estimativas de Complexidade por Story Points A estimativa de complexidade por Story Points deve ser introduzida ao processo de estimativa e priorização dos itens do Product Backlog na Sprint Planning 1. A idéia por trás do método de estimativas por Story Points [9] é que o cliente e o time sejam parte fundamental das estimativas, na qual o primeiro considera o valor que cada item do Product Backlog agrega para o seu negócio, e o segundo dimensiona a complexidade de implementação de cada item baseado no contexto atual do projeto. 45

46 Uma vez que todo o Product Backlog sido valorado de acordo com o valor de negócio de cada item, a equipe do projeto estima a complexidade de cada um destes itens em Story Points. Para isto, podem utilizar a técnica Planning Poker, que segundo Cohn [9] é um método de atribuição de estimativas colaborativo, no qual cada integrante do time possui um conjunto de cartas identificadas com rótulos diferentes (por exemplo, com a seqüência de Fibonacci: 2, 3, 5, 8, 13, 21 e 34). Inicialmente, o time identifica o item de backlog mais simples (para este item é atribuído o valor 2) que passa a ser o item de referência na estimativa dos demais. Em seguida, para os próximos itens do Produxt Backlog, cada integrante do time apresenta uma carta com o rótulo que define a complexidade daquele item em relação à referência pré-definida. A estimativa do esforço necessária para desenvolver o projeto é derivada a partir do tamanho estimado em Story Points considerando-se a capacidade ou velocidade de produção do time (definida a partir de bases históricas e do resultado de Sprints passadas). Sim ilarmente, a duração em dias do projeto e quantidade de Sprints é obtida dividindo-se o esforço total do projeto pela quantidade de participantes do time. Um fluxo de atividades para realização de estimativas por Story Points no nível organizacional é proposto por Freitas [11] podendo o mesmo ser facilmente introduzido no Scrum. Observa-se ainda que a inclusão destas atividades no fluxo do Scrum contribui para que o mesmo passe a estar satisfeito com as práticas de PP (SP1.2 e 1.4), auxiliando também no monitoramento dos parâmetros do projeto conforme definido na prática de PMC (SP 1.1). 5.2 Práticas para o Gerenciamento de Riscos O gerenciamento ágil de processos tem práticas que visam atender a dois desafios [18]: o primeiro é que elas devem integrar as atividades de gerenciamento de riscos dentro das atividades de planejamento da iteração; o segundo é que elas devem adaptar as práticas de gerenciamento de riscos de forma que todo o time possa realizá-las rapidamente. Para que a práticas do RSKM sejam compatíveis com o Scrum, bem como as práticas de PP e PMC relacionadas com riscos, é necessário que sejam incluídas em seu fluxo atividades para identificação, análise, priorização e mitigação dos 46

47 riscos com a criação de planos de ação para tratar os riscos de maior prioridade. Essas atividades devem ser inseridas no contexto das reuniões do Scrum, conforme descritas a seguir: 1. Identificar Riscos: a identificação dos riscos deve acontecer: a) durante a Sprint Planning 1, com foco nos itens do Product Backlog com maior valor de negócio. A identificação dos riscos pode ser realizada através do método de Brainstorming [18]. Um checklist contendo fontes e categorias de riscos pode ser introduzido visando facilitar esta tarefa; b) durante as Daily Scrum, como possíveis impedimentos para o projeto. Riscos identificados devem ser adicionados ao Impediment Backlog. 2. Analisar Riscos: a análise de riscos deve ser realizada durante a Sprint Planning 1 e compreende etapas para determinar: (i) impacto (alto, médio e baixo); (ii) probabilidade (alta, média e baixa); e (iii) o fator de exposição do risco, obtido a partir do produto entre o seu impacto e a sua probabilidade. Alguns ajustes no fator de exposição do risco podem ser aplicados para tratar aspectos específicos do projeto e de qualidade como definidos por Chin [8]. A análise dos riscos nos ajuda a estabelecer uma importância relativa entre os mesmos e é útil na priorização dos riscos. 3. Priorizar os Riscos: seguindo um princípio ágil, Preston [18] sugere que os top 3-5 riscos sejam priorizados. Esses riscos são considerados os mais urgentes e por isso mesmo devem ser gerenciados e m itigados na próxima Sprint. Os demais riscos ficam guardados devendo ser reavaliados na próxim a reunião de Sprint Planning. A priorização dos riscos deve ocorrer na reunião de Sprint Planning 1, auxiliando na priorização e seleção dos itens de backlog que serão desenvolvidos na próxima Sprint. 4. Criar planos de ações: os planos de ação correspondem a todas as tarefas (ações) que devem ser executadas para mitigar os riscos, isto é, tarefas que devem ser executadas visando reduzir o fator de exposição do risco (probabilidade e/ou impacto). Este plano deve ser cr iado durante a Sprint Planning 2, em conjunto com identificação das tarefas que serão executadas para implementar os itens do Selected Product Backlog. Assim sendo, as ações entram no Sprint Backlog e devem ser realizadas e monitoradas continuamente pelo time durante as reuniões diárias do Scrum. Durante a execução da Sprint, riscos podem se transformar em problem as, e nestes casos, passam a ser tratados como impedimentos no Scrum. 47

48 Planos de ações de contingência, seguindo uma abordagem ágil, são elaborados (na Sprint Planning 2) apenas para os riscos priorizados e com fator de exposição alto e devem ser reavaliados à medida que os riscos transformam -se em problemas, sendo tratados pelo ScrumMaster que é o responsável pela resolução dos impedim entos. 5. Monitorar continuamente os riscos: os riscos são monitorados diariam ente, nas Daily Scrum Meetings, e também durante as Sprint Plannings, quando devem ser reavaliados em conjunto com os demais riscos identificados. É importante observar que para garantirmos a agilidade, apenas um subconjunto dos riscos está sendo monitorado a cada Sprint. Este subconjunto é representado pelos riscos que foram priorizados e que estão diretamente relacionados com os itens do Selected Product Backlog. 5.3 Práticas para o Gerenciamento de Ações Corretivas De acordo com Chin [8], identificar e monitorar sistematicamente os problemas do projeto, bem como suas ações corretivas facilita a resolução eficiente de problemas críticos e é necessário para um bom gerenciamento gerenciamento do projeto. Práticas para o de ações corretivas de problemas conforme sugeridas em PMC devem ser acrescidas às práticas já existentes no Scrum para a identificação e resolução dos impedim entos, conforme descritas a seguir: 1. Analisar Problemas: os problemas identificados durante as reuniões diárias devem ser devidamente registrados pelo ScrumMaster no Impediment Backlog, juntamente com uma análise dos mesmos a qual inclui informações sobre: (i) prioridade de resolução (alta, média e baixa); (ii) responsável pela resolução; (iii) data de identificação; (iv) data alvo para a resolução; (v) observações e (vi) estado do problem a (aberto, fechado, cancelado). A análise dos problemas determina ajuda na comparação entre os prblemas a na identificação da necessidade de tomada de ações corretivas para a sua resolução. 2. Tomar Ações Corretivas: seguindo o princípio ágil, ações corretivas devem ser identificadas pelo ScrumMaster, com a colaboração do time para os problem as/dependências mais prioritários. Uma lista das ações corretivas relacionadas com os problemas identificados deve ser documentada, incluindo informações que permitam o seu m onitoramento, tais como: (i) descrição do item de 48

49 ação; (ii) o responsável item de ação; (iii) a data de abertura; (iv) a data alvo para a resolução; (v) observações; (vi) estado da ação (aberta, fechada, cancelada). 3. Gerenciar Ações Corretivas: o gerenciamento das ações corretivas deve ser introduzido nos seguintes momentos: (i) durante as Daily Scrum Meetings, quando os responsáveis pela resolução de problemas devem relatar o que fizeram e o estado atual do problema. O registro do monitoramento deve ser documentado; (ii) durante as reuniões de retrospectiva (Sprint Retrospective Meeting), com o objetivo avaliar a eficácia das ações corretivas tomadas para os problemas identificados, melhorando assim, o gerenciamento de problemas para a próxima Sprint. 6 Uma Aplicação da Extensão do Scrum A proposta de extensão do Scrum está sendo inicialmente aplicada em dois projetos reais de desenvolvimento de software em um instituto de inovação e pesquisa no Brasil considerando apenas as práticas de estim ativas de complexidade por Story Points. Os dois projetos em estudo (que tiveram como requisito do cliente o uso método ágil Scrum para o seu gerenciamento ), são similares em termos de plataforma tecnológica (.NET), no tempo estimado para a sua execução (seis meses) bem como no tamanho da sua equipe (dez pessoas). Diferem, entretanto, nos seus objetivos. O Projeto A visa o desenvolvimento de uma aplicação de Customer Relationship Management (CRM). Já o Projeto B consiste na manutenção e desenvolvimento de novos requisitos para uma ferramenta case de apoio ao planejamento, projeto e execução de testes de software. Outro aspecto relevante sobre os respeito à falta de experiência das equipes com a metodologia ágil Scrum e com a tecnologia adotada. projetos diz Vários resultados práticos foram encontrados pelos times de desenvolvimento dos projetos com o uso desta extensão do Scrum com o uso de estimativas por Story Points, entre os quais se pode destarcar: Não uma referência necess ria tanta informa ão para com e ar a estimar. Precisamos apenas de o item de Backlog com menor complexidade, e a partir daí podemos realizar a estimativa dos demais itens através de comparações com este item. Maior comprometimento do time na hora da execução e cumprimento das tarefas estimadas já que as estimativas foram realizadas colaborativamente pelo próprio time. 49

50 Não preciso se preocupar com horas para a estimativa dos itens de Backlog. Isso facilita o processo de estimativa, uma vez que estamos apenas trabalhando com uma com plexidade, ou melhor, Story Points. O esfor o do projeto pode ser facilmente encontrado, por deriva ão, considerando - se a velocidade/capacidade de implementação de uma Story Point em um dia de trabalho pelo tim e. Desta forma, automaticamente derivamos a quantidade de Sprints que serão realizadas no projeto. A estimativa porstory Points ajuda a priorizar os itens do Product Backlog, e a selecionar os itens que devem compor o Selected Product Backlog. A comparação das estimativas entre projetos distintos foi uma das dificuldades encontradas na aplicação realizada. Isso se deve ao fato de que a estimativa por Story Points é baseada em uma referência para o projeto (o item de backlog m ais simples de ser desenvolvido), e que provavelmente não será a mesm a referência para um outro projeto. A precisão também foi outro fator de dificuldade percebido pelas equipes durante a realização das estimativas. Estimativas das primeiras Sprints foram pouco precisas ocasionando em horas adicionais de trabalho. Mas, à medida que o time foi se conhecendo melhor, se integrando e se sentindo mais confortável com o domínio da aplicação e com a tecnologia as estimativas tornaram -se mais precisas. 7 Conclusões O Scrum não cobre diretamente todas as práticas específicas de gerenciamento de projeto do CMMI. No entanto, pode ser um ótimo ponto de partida para empresas que não possuem processos definidos e têm times pequenos, pois consegue criar grande parte dos fundamentos necessários para que estas empresas institucionalizem as Áreas de Processo de Gestão de Projetos do nível 2 do CMMI, sem comprometer a agilidade de que necessitam. Por outro lado, para empresas que buscam níveis de maturidade maiores, o Scrum pode ser uma excelente largada, mas este necessita da adi ão de pr ticas complementares, como sugeridas neste trabalho. Com poucas adaptações, relacionadas ao gerenciamento ágil dos riscos, gerenciamento de ações corretivas e adição de um método de estimativas, o Scrum passa a ficar muito mais compatível ao CMMI, podendo o mesmo ainda ser as 50

51 estendido para atender as demais áreas de processo que não foram tratadas neste trabalho. No entanto, práticas alternativas podem ser identificadas, considerado as recomendações do Scrum, de acordo com a realidade de cada organização, o que minimiza o número de práticas não diretamente atendidas. REFERÊNCIAS [1] Advanced Development Methods ADM, Controlled chaos: living on the edge, (Dezembro 2006). [2] Advanced Development Methods ADM, Scrum Methodology Incremental, Iterative Software Development from Agile Processes, Revision 0.9, [3] Anderson, D. J. Agile Management for Software Engineering - Applying the Theory of Constraints for Business Results, Prentice Hall, [4] Anderson, D. J., Stretching Agile to fit CMMI Level 3, presented at Agile 2005 Conference, Dever, [5] Boehm, B. and Turner, R., Balancing Agility and Discipline: A Guide for the Perplexed, AddisonWesley, [6] Boehm, B., A View of 20th and 21st Century Software Engineering, ICSE [7] Beck, K. et al., Manifesto for Agile Software Development, agilemanifesto.org/, (Dezembro 2006). [8] Chin, G., Agile Project Management: How to Succeed in the Face of Changing Project Requirements. Amacon, [9] Cohn, M., Agile Estimating and Planning, Prentice Hall, 330 p, [10] Davis, C., Glover, M., Manzo, J. and Opperthauser D., An Agile Approach to Achieving CMMI, (Março 2007). [11] Freitas, B., Marçal, A., Soares, F., Tenório, L. e Maciel, T., Adaptando Story Points para Estimativas de Software no Nível Organizacional, [12] Gloger, B., The Zen of Scrum, (Março 2007). [13] Goldenson, D. and Ginbson, D., Demonstrating the Impact and Benefits of CMMI: An Update and Preliminary Results, CMU/SEI-2003-SR-009. SEI,

52 [14] Highsmith, J., Agile Project Management Creating Innovative Products, AddisonWesley, [15] McMahon, P. E., Extending Agile Methods: A Distributed Project and Organizational Improvement Perspective, CrossTalk, The Journal of Defense Software Engineering, vol. 18, issue 5, pp. 1619, [16] Larman C., Agile & Iterative Development, A Manager s Guide, Addison -Wesley, [17] Marçal, A., Freitas, B., Soares, F., Belchior, A., Mapping CMMI Project Management Process Areas to SCRUM Practices, 31st Annual Software Engineering Workshop, Loyola College, Baltimore, MD, USA, (6-8 March 2007). [18] Preston, S. and Pichler, R., Agile Risks, Agile Rewards, /dept/architect/ , (Janeiro 2007). [19] Software Engineering Institute - SEI, CMMI-DEV: CMMI for Development, V1.2 model, CMU/SEI-2006-TR-008, (Dezembro 2006). [20] Schwaber, K., Agile Project Managem ent With Scrum, Microsoft, [21] Schwaber, K. and Beedle, M., Agile Software Development With Scrum. NJ: Prentence Hall, [22] Turner, R., and Jain, A., Agile Meets CMMI: Culture Clash or Common Cause, In proceedings of the Second XP Universe and First Agile Universe Conference on Extreme Programming and Agile Methods XP/Agile Universe, pp ,

53 ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS: um estudo de caso Antonio Cesar Amaru Maximiano Jefferson Leandro Anselmo Antonio Cesar Amaru Maximiano é Professor Livre- Docente do Departamento de Administração da Faculdade de Ec onomia, Adminis tração e Contabilidade da Universidade de São Paulo (CEP São Paulo/SP, Brasil) e Supervisor de Projetos da Fundação Instituto de Administração. Endereço: Universidade de São Paulo FEA Departamento de Administração Avenida Professor Luciano Gualberto, 908 FEA1 Sala E São Paulo SP Jeffers on Leandro Anselmo é Doutorando, Mes tre e Bacharel em Administração pela Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo (CEP São Paulo/SP, Brasil) e Coordenador de Projetos da Promon. Recebido em 20/janeiro/2005 Aprovado em 09/agosto/2005 De acordo com Rad e Raghavan (2000), o gerenciamento de projetos é uma das disciplinas que mais crescem no mundo de hoje. Apesar do evidente aumento da utilização do gerenciamento de projetos por parte das empresas, ainda se observam altos índices de falhas em projetos (FORMAN apud RAD e RAGHAVAN, 2000). Crawford (2000b) justifica essa ineficácia pela falta de processos adequados e padronizados de gerenciamento. O Escritório de Gerenciamento de Projetos (EGP) emerge então como a unidade organizacional responsável pela correção desses problemas e, ad icionalmente, pela divulgação das práticas de gerenciamento de projetos para toda a organização, possibilitando a diminuição dos índices de falhas e garantindo que os projetos mais importantes para a organização sejam tratados de forma prioritária. Segundo alguns autores, o movimento pela instalação de EGPs nasceu no final da década de 1980 (ENGLUND, GRAHAM e DINSMORE, 2003), mas há outros que situam as origens em período mais remoto (KERZNER, 2003). 53

54 É possível que os EGPs não sejam solução viável para toda s as empresas (DINSMORE, 2002). A polêmica sobre as vantagens do EGP é um dos argumentos que tornam significativo um estudo do tem a. Neste trabalho apresenta-se o caso de uma empresa, precedido por um quadro de referências em que são descritas a implantação e a utilização de um EGP como instrumento de apoio ao gerenciamento de projetos e de implementação de estratégias organizacionais. 2. METODOLOGIA O estudo que produziu o caso (ao qual se refere como estudo de caso ) teve objetivo inicialmente exploratório, para permitir aos pesquisadores obter conhecim entos sobre o problema. Num estudo exploratório, o pesquisador parte de uma hipótese e aprofunda seu estudo nos limites de uma realidade específica, buscando antecedentes, maiores conhecimentos, para, em seguida, planejar uma pesquisa descritiva (YIN, 2001). O estudo exploratório é apropriado quando o conhecim ento disponível é insuficiente para estabelecer as relações de causa e efeito. Os estudos exploratórios não elaboram hipóteses a serem testadas, restringindo-se a buscar mais informações sobre o tema estudado, de acordo com os objetivos estabelecidos (CERVO e BERVIAN, 2003). Adicionalmente, o estudo teve objetivo descritivo, exigindo dos pesquisadores informa es sobre o que desejavam pesquisar. [...] O estudo descritivo pretende descrever =com exatidão os fatos e fenômenos de determinada realidade. Outros estudos descritivos denominam-se estudos de casos. Esses estudos têm por objetivo aprofundar a descri ão de determinada realidade (TRIVI OS, 1987). O método escolhido, o caso, caracterizaou poucos objetos, de maneira que permita o seu amplo conhecimento, tarefa se pelo estudo profundo e exaustivo de um praticamente impossível mediante outros delineamentos considerados (GIL, 2002). De acordo com Yin (2001), o estudo de caso é uma pesquisa empírica que investiga um fenômeno contemporâneo, dentro de um contexto de vida real, especialmente quando os limites entre o fenômeno e o contexto não estão claramente definidos. O caso escolhido é a implantação do EGP de uma empresa multinacional de grande porte do setor de telecomunicações. 54

55 Para a coleta de dados, foram utilizadas as técnicas de análise documental, observação direta e entrevista focalizada. A técnica da análise documental, como o nome sugere, refere-se ao estudo de documentos da empresa. Documento é toda e qualquer fonte ou base de conhecimentos acessível para consulta (PÁDUA, 1997). As fontes foram selecionadas de forma a garantir a pertinência aos objetivos da pesquisa. A observação direta consiste no contato pessoal e estreito do pesquisador com o objeto do estudo, permitindo-lhe utilizar seus conhecimentos e experiências como auxiliares no processo de compreensão e interpretação desse objeto. Com relação à entrevista, ela baseia-se em um roteiro predefinido, tendo o pesquisador liberdade para nele não abordar algumas questões e incluir outras (LAKATOS e MARCONI, 2005). A escolha do caso baseou-se nos seguintes critérios: empresa m ultinacional com subsidiária no Brasil; experiência pioneira na implantação de m etodologia e escritório de gerenciamento de projetos ; familiaridade dos pesquisadores com o caso e acesso a seus protagonistas. 3. ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS DEFINIÇÃO Algumas definições de EGP encontradas na literatura são as seguintes: a unidade organizacional que cuida de todos os projetos de uma organização (ARCHIBALD, 2003); unidade organizacional de nível corporativo que tem as fun es de defini ão e uniformização de processos e ferramentas (RAD e RAGHAVAN, 2000; DUGGALL, 2001); unidade organizacional de nível corporativo que atua como repositório ou provedor de serviços, profissionais, processos, métodos e ferramentas de auxílio (CRAWFORD, 2000a; CLELAND e IRELAND, 2000); unidade organizacional de nível corporativo que atua no auxílio ao gerenciamento de portfolio (MORNINGSTAR, 1999). O restante deste trabalho assume uma definição híbrida, ilustrada na figura 1, uma adaptação da definição de Gonsalez e Rodrigues (2002). O EGP é definido, portanto, como a unidade organizacional formalmente estabelecida que tem a responsabilidade de: definir, uniformizar e defender padrões, 55

56 processos, métricas e ferramentas; oferecer serviços de gerenciamento, treinamento e documentação; garantir o alinhamento das iniciativas à estratégia organizacional; confeccionar relatórios de progresso e acompanhamento e enviá-los para os patrocinadores Modelos, funções e composição interna Neste trabalho, as funções do EGP serão divididas em três modelos: Nível 1 Escritório de controle de projetos ; Nível 2 Escritório de suporte de projetos ; Nível 3 Escritório estratégico de projetos. Apesar dessa divisão, tipos diferentes de EGPs podem ser utilizados ao mesmo tempo em áreas distintas da organização ou mesm o dentro da mesma área ( CASEY e PECK, 2001). EGPs específicos podem ser usados para áreas funcionais, grupos de clientes ou para a empresa toda (KERZNER, 2003). Esses modelos podem também combinar-se, fazendo com que as fronteiras entre eles sejam muito tênues (KATE, 2000). De forma resumida, as funções do EGP variam de uma empresa para outra, mas há três que são encontradas em praticamente todas: desenvolvimento, apoio e controle (HALLOWS, 2002) Nível 1 Escritório de controle de projetos Um EGP de Nível 1 é utilizado para controle de projetos, sendo responsável pela emissão de relatórios e pelo acompanhamento de indicadores, sem influenciar a maneira como os projetos são conduzidos (GONSALEZ e RODRIGUES, 2002). As funções desse nível de EGP são: elaborar relatórios d e progresso, custos, orçamento, desempenho e riscos; manter uma base de dados de a es históricas e li es aprendidas; monitorar os resultados do projeto. Em geral, um escritório do Nível 1 controla as atividades do dia-a-dia dos projetos, para ajudar os gestores a assegurarem que o time do projeto alcance suas metas, resultados e orçamento estipulados (BRIDGES e CRAWFORD, 2001) Nível 2 Escritório de suporte de projetos 56

57 Um EGP de Nível 2, também chamado de escritório de suporte de projetos, é geralmente utilizado para controle de projetos grandes ou de quantidade um pouco maior de projetos pequenos e médios. É responsável, também, por (CASEY e PECK, 2001): todas as fun es de um EGP de Nível 1; fornecer treinamento em gerenciamento de projetos ; estabelecer e verificar o cum primento de padr es e m tricas; possibilitar o alinhamento dos projetos às estratégias do departamento; controlar e armazenar as li es aprendidas e os relatórios gerados; definir, implementar e controlar mecanism os de controle de mudanças; assum ir o papel de mentor para projetos com problem as. Assim, um EGP de Nível 2 difere de um de Nível 1 principalmente pelo poder de influir no andamento dos projetos por m eio de atuação como mentor e definição de metodologias, técnicas, métricas e ferramentas a serem utilizadas. Figura 1: Escritório de Gerenciamento de Projetos Conceito Fonte: Adaptada de Gonsalez e Rodrigues (2002) Nível 3 Escritório estratégico de projetos Um escritório estratégico de projetos opera no nível corporativo, coordenando e definindo políticas para todos os projetos dentro da organização, gerenciando o portfolio corporativo e prestando auxílio aos escritórios de Níveis 1 e 2, se existirem. No Nível 3, um EGP geralmente é considerado um centro de excelência em gerenciamento de projetos, guiando e ajudando os gerentes de projetos e demais membros dos times dos projetos a alcançarem seus resultados de maneira mais eficiente (BRIDGES e CRAWFORD, 2001). As funções principais desse nível de EGP incluem: todas as fun es do Nível 2; padroniza ão do gerenciamento de projetos ; identifica ão, prioriza ão e sele ão de projetos ; gerenciamento corporativo de recursos; implanta ão e manuten ão de um sistema de informa es; alinhamento dos projetos à estratégia corporativa; desenvolvimento profissional dos membros do EGP. 57

58 Segundo Bridges e Crawford (2001), a principal diferença entre os Níveis 2 e 3 dos EGPs é o caráter corporativo do Nível 3 em relação ao caráter departamental do Nível IMPLEMENTAÇÃO 4.1. Fatores motivadores Segundo Crawford (2001), grande parte da motivação para implantar um EGP reside no insucesso dos projetos ou dos objetivos organizacionais. Para Gonsalez e Rodrigues (2002), os projetos necessitam de controle elaborado para que fiquem alinhados com a estratégia organizacional. Essa necessidade de alinhamento somase à carência de competências específicas em gerenciamento de projetos, às crescentes complexidade e diversidade do portfolio das empresas e à necessidade de eficácia no gerenciamento de projetos e do portfolio, como fatores motivadores da implantação do EGP Aspectos culturais Ainda segundo Gonsalez e Rodrigues (2002), m uitos autores apontam o ceticismo que ocorre com freqüência na implementação de um EGP, visto como entidade meram ente burocrática. Os mesmos autores, citando Bernstein (2000), lamentam essa visão, pois, se corretamente implantado, o EGP representa alívio ao complicado processo de gerenciamento de projetos. A implantação de um EGP é também, portanto, um processo de gerenciamento de mudanças organizacionais (CRAWFORD, 2000a), associadas ao aumento da maturidade organizacional. A maturidade de uma organização para lidar com determinados conceitos é uma dim ensão de sua cultura. O nível de maturidade em gerenciamento de projetos mede o quanto a organização progrediu em relação à incorporação de gerenciamento de projetos como método de trabalho. Essa mensuração (que é qualitativa) indica a situação da organização em relação ao uso do gerenciamento de projetos e oferece os subsídios necessários para torná-lo mais eficaz. Os modelos para lidar com a idéia de maturidade do gerenciamento de projetos são baseados no Modelo de Maturidade da CarnegieMellon University (Capability Maturity Model CMM), idealizado para o desenvolvimento de software. Um 58

59 modelo desenvolvido em parceria com o Software Engeneering Institute, que contou com recursos iniciais do Departamento de Defesa americano, é de domínio público. O Organization Project Management Maturity Model (OPM3), criado pelo PMI (2003) e, possivelmente, o modelo mais conhecido de maturidade da gestão de projetos, tem o CMM como uma de suas fontes. Um trabalho precursor de avaliação da maturidade havia sido patrocinado antes do OPM3 pelo PMI (IBBS e KWAK, 2000). Há sólidas evidências da relação entre o nível de maturidade da organização e o desempenho dos projetos (MORAES, 2004) Fatores de sucesso e insucesso Uma descrição dos fatores de sucesso e insucesso na im plantação do EGP foi feita por Bridges e Crawford (2000). Os fatores de sucesso listados são: simplifica ão do processo; foco em valor; planejamento; patrocínio da alta administra ão; comunica ão eficaz. O insucesso está, por sua vez, relacionado a: tentativa de fazer tudo de uma só vez; procrastina ão; esquecimento das principais partes interessadas; atitude de exigir antes de prover; trabalho sem apoio dos interessados e da alta administra ão Fases da implementação Para a implementação do EGP, Bridges e Crawford (2000) adotam uma abordagem que visa gerar valor o mais rapidamente possível, ao mesmo tempo que considera soluções de longo prazo para aprimorar o gerenciamento de projetos. Os autores recomendam fazer um esforço consciente e planejar para gerar valor imediato e atender o mais rapidamente possível às necessidades da empresa. Eles propõem quatro fases, apontadas a seguir. 59

60 Fase I Preparar o terreno : são definidas as iniciativas de curto prazo e os objetivos de longo prazo. A fase termina quando as iniciativas foram levantadas e o plano de ação preparado e aprovado. Fase II Começar com iniciativas de curto prazo : a operação do EGP é iniciada com a alocação da equipe, o início das atividades de comunicação e a divulgação para a organização do EGP e de suas responsabilidades. A fase termina quando as iniciativas de curto prazo já deram resultado e estão consolidadas. Fase III Caminhar com soluções de longo prazo : o objetivo desta fase é gerar valor para a empresa por m eio da melhoria das práticas de gerenciamento de projetos e do desenvolvimento dos profissionais ligados a esse gerenciamento. Fase IV Manter e aprimorar : nesta fase, o EGP já está funcionando e a organização já reconheceu seu valor. Deve-se, portanto, conduzir as atividades diárias, refinando continuamente o sistema de gerenciamento de projetos e procurando sempre novas oportunidades de gerar valor para a empresa por meio de implementação mais rápida e com menor custo das estratégias organizacionais. 5. ESTUDO DE CASO ANÁLISE E INTERPRETAÇÃO 5.1. A empresa Líder mundial no mercado de telecomunicações, a empresa estudada está presente no Brasil desde No ano de 2001, antes da crise do setor de telecomunicações, o País era seu terceiro maior mercado, com faturamento de aproximadamente R$ 4 bilhões. Sua participação no mercado nacional girava em torno de 40% em telefonia móvel e 35% em telefonia fixa. Os negócios principais da empresa são o fornecimento de sistemas e infra -estrutura de redes de telecomunicações para as operadoras e a implantação de sistemas e infra-estrutura. As contas dos clientes são agrupadas em Key Account Managers (KAMs Gerentes de Contas-Chave), compostos por vários contratos. A receita da empresa está ligada diretam ente à venda dos projetos de implantação para os clientes, o que evidencia a im portância do gerenciamento de projetos para ela. A figura 2 ilustra a estrutura organizacional da empresa no Brasil. A empresa tem uma estrutura formal chamada Project Management Office, posicionada dentro da unidade Serviços Globais (Global Services), e que agrega os 60

61 gerentes de projeto, guarda a metodologia de gerenciamento, procura difundi-la e dá apoio para sua aplicação. Essa estrutura teve uma evolução relativamente rápida, desde que foi montada uma metodologia de gerenciamento de projetos (cerca de dois a três anos antes do levantamento deste caso). Essa metodologia foi apoiada por uma diretriz mundial de valorização da disciplina de gerenciamento de projetos na empresa Descrição, análise e interpretação do estudo do caso Aspectos organizacionais Estrutura organizacional No momento em que o caso foi pesquisado, no final de 2002, a empresa passava por uma transição. Ainda era departamentalizada, com estrutura de linha, mas já havia um movimento d e mudan a para uma organiza ão projetizada (PMI, 2004). A estrutura de poder estava nas linhas e a matriz para administrar tipo leve ou fraca (PMI, 2004). Essa estrutura da empresa não conseguiu sustentar a mudança de foco pretendida para a adm inistração por projetos era do projetos. Dentre os fatores impeditivos, coincidentes com os apresentados por Crawford (2001), podem ser enumerados: ausência de um respons vel nico pelo gerenciamento de cada projeto; estrutura de poder centrada nos departame ntos funcionais; EGP localizado três níveis hier rquicos abaixo da presidência, dificultando o acesso à alta administração e diminuindo o poder de ação estratégica. Relação do resultado da empresa com o resultado dos projetos A relação entre o resultado da empresa e o resultado dos projetos é intensa. A receita é gerada por meio de venda de soluções integradas de infra-estrutura e por meio da implantação dessas soluções para as operadoras. Mesmo numa venda de produtos, os serviços associados, geralmente projetos de implantação, fazem parte da oferta. Essa elevada relação entre o resultado da organização e o resultado dos ter tido certa influência sobre a decisão tomada pela alta administração de incentivar a administração por projetos pode projetos dentro da organização e pode também ser um fator motivador de mudanças na estrutura organizacional, de forma a facilitar que esse reposicionamento de foco seja efetivamente implementado. Utilização de gerenciamento por projetos 61

62 Com o exposto, a iniciativa de adotar o gerenciamento por projetos surgiu junto com o EGP e até recentemente esteve restrita a ele. Todas as demais áreas da empresa eram administradas e avaliadas de acordo com critérios funcionais. A própria estrutura organizacional da empresa favorece essa administração funcional. Isso pode evidenciar o relativo insucesso do EGP em demonstrar para a organização os problemas da administração funcional de uma empresa cuja receita é dependente de projetos. No entanto, o EGP pode assumir um papel de liderança na transformação do estilo de gerenciamento da empresa, devido ao recente apoio recebido da alta administração que planeja fazer a mudança para o gerenciamento por projetos. Porte e complexidade dos projetos Os projetos da empresa são de complexidade e porte variáveis, mas, de forma geral, orientados para implementação de equipamentos e soluções de redes de telecomunicações. Dessa forma, há projetos grandes, com o um turnkeyde R$ 50 milhões, ou um projeto de instalação, de apenas R$ 500 mil. O porte ou a complexidade do projeto não são, no entanto, fatores restritivos para a implantação do EGP, a qual habilitaria a empresa a administrar com eficiência projetos de natureza diversa no nível corporativo ou projetos de diferentes portes em programas específicos (GONSALEZ e RODRIGUES, 2002) Implantação do EGP Motivos para a implementação A necessidade de implantar o EGP surgiu em 1999 com a dem anda por uma metodologia padronizada de gerenciamento de projetos. Depois da criação dessa metodologia, a empresa percebeu que o desenvolvimento de competências em gerenciamento de projetos seria um fator com petitivo im portante. Esse também é um dos motivos identificados por Crawford (2001). Outros autores apresentam a existência e a maturidade dos processos de gerenciamento como condições necessárias para o sucesso do EGP, ou seja, a implantação e a consolida ão da metodologia deveriam vir antes da implementa ão do EGP: um indicador da maturidade de uma organização no campo do gerenciamento de 62

63 projetos é o reconhecim ento de que deve estabelecer um espaço para a função de gerenciamento de projetos (ARCHIBALD, 2003). A empresa começou a implementação da metodologia e, durante o andamento do processo, antes que essa metodologia estivesse totalmente absorvida, iniciou a implementação do EGP. Houve o entendimento de que a existência do escritório favoreceria o processo de disseminação da metodologia. Grau de envolvimento da alta adm inistração O apoio da alta administração foi relativamente alto em 1999, durante as fases iniciais do processo de implantação, porém caiu em 2000 e 2001, tendo sido retomado apenas no início de Essa variação no envolvimento da alta administração está relacionada, naturalmente, aos altos e baixos na implementação do EGP. Quando houve apoio da alta administração, o EGP conseguiu desenvolver - se e agregar valor; sem apoio, o desempenho do EGP ficou prejudicado. Isso confirma as indicações dos autores até aqui citados. Metodologia de implementação A implantação do EGP foi tratada como um projeto. Inicialmente, definiu-se o EGP e buscou-se o apoio dos interessados-chave. Em seguida, realizou-se todo o planejamento necessário para a implementação. Somente quando o escritório e seus objetivos estavam bem-definidos, as pessoas-chave doutrinadas e todo o planejamento feito, é que se iniciou a implementação do EGP. Apesar de a empresa ter feito, no início, o EGP exercer suas funções em apenas dois projetos, todas as funções do EGP foram executadas. Em outras palavras, a implantação buscou estabelecer a totalidade das funções do EGP logo no início, em vez de começar com funções de mais rápida implantação. Dificuldades encontradas As maiores dificuldades encontradas na implantação do EGP na empresa estão ligadas à cultura e à resistência com relação às mudanças organizacionais necessárias. Principalmente nos períodos em que o apoio da alta administração foi menos explícito, as pessoas apresentaram grandes resistências ao trabalho do EGP, deixando de observar os procedim entos recomendados e de colaborar com os 63

64 trabalhos de implantação da m etodologia e de desenvolvimento de com petências. Novamente, os fatos levam a uma confirmação do que a literatura (CRAWFORD, 2000b) afirma a respeito das dificuldades de implantação de um EGP: um dos maiores desafios é vencer a resistência das pessoas. Fatores críticos de sucesso identificados O principal fator crítico de sucesso identificado na implantação foi o apoio da alta administração. Novamente, esse fator não é o único descrito na literatura (BRIDGES e CRAWFORD, 2000), indicando que o processo de implantação do EGP na empresa poderia ter tido maior sucesso caso houvesse um estudo que buscasse identificar todos esses fatores Caracterização do EGP Filosofia de atuação O EGP da empresa atua como um provedor de serviços, metodologias e recursos, além de exercer funções de orientação. Não tem autoridade para modificar o andamento dos projetos a não ser por meio de negociações e persuasão do gerente de projeto e dos gerentes de linha associados. Com certeza essa falta de autoridade do escritório influi negativam ente em suas funções, impedindo-o de gerar m ais valor para a organização. Para que o EGP possa realizar suas funções de medição e de orientação, os gerentes de projetos enviam periodicamente relatórios de status com base nos quais o EGP realiza suas análises e recomendações e encaminha informações para a alta administração. Um dos problemas do escritório é a baixa qualidade desses relatórios. Essa filosofia de atuação (provedor de serviços e aconselhamento) é discutida pelos autores que fizeram parte do referencial bibliográfico (especialmente GONSALEZ e RODRIGUES, 2002), evidenciando que o EGP da empresa está posicionado entre o Nível 1 Escritório de Controle de Projetos e o Nível 2 Escritório de Suporte de Projetos, ou seja, exerce todas as funções de um escritório do Nível 1, mas apenas parte das funções de um escritório do Nível 2. O EGP poderia tornar-se rapidamente um escritório de suporte de projetos completo, caso o problema da falta de autoridade fosse resolvido. No entanto, a própria estrutura atual da empresa dificulta essa resolução, pois não permite fácil 64

65 acesso à alta administração. O escritório poderia atuar também de maneira mais precisa, caso as informações fornecidas pelos projetos fossem m ais com pletas. Porém, a forma de comunicação (envio de relatórios periodicamente, sem contato entre o EGP e os projetos ) dificulta a m inimização dessa falha. Esse é claramente um problema cultural e de percepção do EGP por parte dos projetos, já que os componentes dos projetos aparentemente não vêem valor nas funções do EGP. O problem a cultural, de acordo com a pesquisa bibliográfica, é um dos maiores entraves ao sucesso do EGP e os problemas observados vão ao encontro dessa constatação Estratégias organizacionais e EGP A relação entre as estratégias organizacionais da empresa e as funções do EGP é muito tênue. Apenas as ações estratégicas que envolvem gerenciamento de projetos incluem, de alguma forma, o EGP. Todas as demais ações são implementadas sem relação alguma com ele. Isso demonstra o caráter operacional do atual EGP, bem como o espaço para sua evolução Grau de autoridade do executivo principal do EGP O grau de autoridade do principal executivo do escritório de gerenciamento de projetos é reduzido, refletindo a estrutura organizacional da empresa e a própria falta de autoridade do EGP como um todo. Sua área de atuação restringe-se somente ao grupo que faz parte do escritório. Esse reduzido grau de autoridade do executivo do EGP também está claramente associado aos problemas no desempenho das funções do escritório Infra-estrutura Aproximadamente 70 pessoas estão ligadas ao EGP da empresa. Dessas, 63 são gerentes de projeto espalhados pela organização. As outras sete pessoas estão lotadas no EGP. Compõem esse grupo: o gerente do EGP, o responsável pela definição dos processos, um responsável pelos serviços de suporte, dois gerentes de projeto que auxiliam o gerente na execução das funções do EGP nos projetos, um assistente e um estagiário. 65

66 Segundo os autores citados, o escritório é maior quando o EGP tem a função de alocar recursos ao projeto e, conseqüentemente, os gerentes de projetos estão a ele vinculados, o que não é o caso na empresa pesquisada. Há uma gama de ferramentas disponíveis para o EGP, entre elas a Intranet corporativa, que contém ferramentas, textos de apoio e a descrição da metodologia de gerenciamento de projetos da empresa. Todas as ferramentas estão disponíveis para todos os membros do EGP, os quais utilizam a Intranet também para comunicação interna Atribuições e funções do EGP De maneira resumida, as atribuições e funções do EGP são: aloca ão dos gerentes de projetos : o EGP é responsável pela alocação dos gerentes nos projetos e por sua avaliação; guardião da metodologia, de processos e ferramentas; suporte para aplica ão da metodologia e estrutura ão do projeto; orienta ão com rela ão a t cnicas de gerenciamento de projetos ; padroniza ão da metodologia de gerenciamento de projetos Tamanho e duração dos projetos Há uma relação formal e documentada entre as funções/requisitos do EGP e o tamanho, a complexidade e a duração dos projetos. Isso demonstra a preocupação da empresa em adaptar o m odo de gerenciamento ao tamanho ou à com plexidade dos projetos. Em linhas gerais, projetos mais curtos e menos complexos demandam menos controle e projetos maiores ou mais complexos demandam mais controle. A preocupação é justificada, pois se não forem observadas essas especificidades relativas ao tamanho dos projetos, o EGP pode ser administrado de maneira ineficiente Resultados alcançados Em linhas gerais, o Escritório de Gerenciamento de Projetos da empresa estudada conseguiu alcançar seus objetivos iniciais que eram a unificação da metodologia de gerenciamento de projetos e a atuação como gestor de recursos ligados ao gerenciamento de projetos. 66

67 Essa uniformização de m etodologias efetivamente ocorreu e a alocação dos gerentes de projeto passou a ser feita pelo escritório. No entanto, havia a intenção inicial de expandir gradativamente as funções do EGP, de forma a possibilitar que suas atividades pudessem gerar maior valor para a empresa. Essa expansão de funções ocorreu de forma medíocre, pois até a conclusão do estudo do caso o escritório não havia conseguido apoio, visibilidade e percepção de valor suficientes para que essa intenção se concretizasse. Posteriormente, se houver a confirmação e a concretização da intenção da alta administração de tornar a administração por projetos um a prática comum na empresa, é possível que o EGP ganhe (ou já tenha ganho) novo fôlego e força política para expandir-se. Contudo, caso essa visão da cúpula da empresa não se concretize, dificilmente o escritório conseguirá avançar na expansão de suas atribuições. 6. CONSIDERAÇÕES FINAIS A disciplina do Gerenciamento de Projetos vem ganhando terreno no cenário empresarial, o que se comprova pelo crescimento exponencial dos associados ao Project Management Institute (PMI), bem como de suas atividades e do número de organizações que delas participam. Esse movimento pelo gerenciamento por projetos faz as empresas precisarem de maior capacidade de coordenar, gerenciar e controlar as atividades que têm natureza de projeto. Pode-se definir projeto como uma forma de planejamento, organização, execução e controle de ações visando à implementação de estratégias. Assim, quanto mais eficazmente os projetos forem administrados, mais cedo os benefícios esperados serão atingidos. Por outro lado, o fracasso ou a ineficiência sistemática nessa modalidade de administração pode levar a uma perda considerável da competitividade da empresa. O Escritório de Gerenciamento de Projetos é a unidade organizacional responsável por pensar todo o gerenciamento corporativo de projetos e por concretizar a obtenção desses benefícios. Este trabalho foi realizado de forma a analisar a implantação e a utilização de um EGP como instrumento de apoio ao gerenciamento de projetos e de implementação de estratégias organizacionais, identificando as principais dificuldades e fatores 67

68 críticos de sucesso da implantação e os principais pontos positivos e negativos da utilização. Para isso, realizou-se uma revisão bibliográfica sobre o tema e também sobre os conceitos mais gerais de gerenciamento de projetos, de forma a subsidiar de maneira mais completa o entendimento das funções e objetivos do escritório. Essa revisão foi seguida de um estudo de caso feito em uma grande empresa do setor de telecomunicações. A comparação do referencial bibliográfico com o estudo de caso possibilitou um melhor entendimento do EGP, permitindo avaliar de maneira mais completa os resultados obtidos pela em presa Questões e visão de futuro Algumas importantes questões surgiram no decorrer deste estudo, mas não foram aprofundadas por estarem fora de seu escopo. Uma das questões principais diz respeito à falta de uma metodologia viável de quantificação do valor de um EGP, para ajudar na justificativa de sua implementação. Apesar de a técnica do valor monetário esperado ser uma alter nativa, sua aplicação é ainda muito difícil e muitas vezes subjetiva. Além da importância da quantificação de valor, o EGP imprime maior transparência ao gerenciamento corporativo de projetos, fazendo com que possíveis acordos informais dentro da organização se revelem ou fiquem impossibilitados. Essa característica reforça o cuidado que se deve ter com a implantação do EGP, já que boa parte da dinâmica operacional da empresa pode estar baseada nesses acordos informais. Soma-se a essas e a outras possíveis questões uma visão de futuro para melhor explorar o potencial do EGP. Essa visão leva o EGP a assumir posição central nos temas de fronteira na Administração, como gerenciamento de portfolio, programas e projetos, mudanças organizacionais, conhecimento e implementação de estratégias. Essa posição levaria o EGP a atuar como catalisador da im plem entação de estratégias organizacionais. O futuro do EGP está mais relacionado com a coordenação de processos e com o fazer acontecer do que com a execução propriamente dita. Para poder exercer essa coordenação, o EGP deve ter competências multidisciplinares e conseguir 68

69 reconhecimento e legitimidade para atuar com o orquestrador dos processos de mudança organizacional. REFERÊNCIAS BIBLIOGRÁFICAS ARCHIBALD, Russell D. Managing high-technology programs and projects. 3rd ed. Hoboken, New Jersey: John Wiley, BERNSTEIN, Sally. Project offices in practice. Project Management Journal, [S.l.], v.30, n.4, p.4-7, Dec BRIDGES, D.N.; CRAWFORD, J.K. How to startup and rollout a project office. In: PROJECT MANAGEMENT INSTITUTE ANNUAL SEMINARS & SYMPOSIUM, 1., 2000, Houston. Proceedings... Houston: PMI, A project office where and what type. In: PROJECT MANAGEMENT INSTITUTE ANNUAL SEMINARS & SYMPOSIUM, 1., 2001, Nashville. Proceedings... Nashville: PMI, Nov CASEY, W.; PECK, W. Choosing the right PMO setup. PM Network, [S.l.], v.15, n.2, p.40-47, Feb CERVO, A.L.; BERVIAN, P. Metodologia científica.são Paulo: Prentice Hall, CLELAND, David L.; IRELAND, Lewis R. Project manager s portabler handbook. New York: McGraw-Hill, CRAWFORD, J.K. Making a place for success. Project Management Best Pratices Report, [S.l.; s.n.], p.93, June 2000a.. Improving organizational productivity with a project office. Contract Management, [S.l.], v.40, n.6, p.2-3, June 2000b.. The strategic project office: business case and implementation strategy Disponível em : <http://www.pmsolutions.com>. Acesso em: 14 abr DINSMORE, P.C. Sixteen reason not to implement a project office. PM Network, [S.l.], v.16, n.2, Feb DUGGAL, J.S. Building a next generation PMO. In: PROJECT MANAGEMENT INSTITUTE ANNUAL SEMINARS & SYMPOSIUM, n.1., 2001, Nashville. Proceedings... Nashville: PMI, Nov ENGLUND, Randall L.; GRAHAM, Robert J.; DINSMORE, Paul C. Creating the project office. San Francisco: Jossey-Bass, FRAME, J.D. Managing projects in organizations. San Francisco: Jossey-Bass,

70 GIL, A.C. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, GONSALEZ, F.; RODRIGUES, I. Implementação de escritórios de gerenciamento de projetos Monografia (MBA em Projetos ) Departamento de Administração da Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo, São Paulo, São Paulo, Brasil. HALLOWS, J.E. The project office toolkit. New York: AMACOM, IBBS, C.W.; KWAK, Y.H. Assessing project management maturity. Project Management Journal, v.31, p.32-43, Mar KATE, Belzer. The program office: a business results enabler Disponível em: <http://www.pmforum.org/library/papers/2001/programofficefinal.pdf>. Acesso em: 18 mar KERZNER, Harold. Strategic planning for a project office. Project Management Journal, v.34, n.2, p.13-25, LAKATOS, Eva Maria; MARCONI, Marina de Andrade. Fundamentos de metodologia científica. 6. ed. São Paulo: Atlas, MORAES, R.O. Condicionantes de desempenho dos projetos de software e a influência da maturidade em gestão de projetos Tese (Doutorado) Faculdade de Economia, Administração e Contabilidade da Universidade de São Paulo, São Paulo, São Paulo, Brasil. Disponível em: <http://www.teses.usp.br>. Acesso em: 21 mar MORNINGSTAR, D. The project office: a great idea whose time has come Disponível em: <http://www.systemcorp.com>. Acesso em: 28 fev again. PÁDUA, E.M.M. Metodologia de pesquisa: abordagem teórico-prática. Campinas: Papirus, PROJECT MANAGEMENT INSTITUTE (PMI). Organizational project management maturity model [OPM3]. Newtown, Pennsylvania, USA: Four Campus Boulevard, Project management body of knowledge [PMBOK]. Newtown, Pennsylvania, USA: Four Campus Boulevard, RAD, P.F.; RAGHAVAN, A. Establishing an organizational project office. AACE International Transactions, ABI/INFORM Global, p.p13a, TRIVIÑOS, A.N.S. Introdução à pesquisa em ciências sociais: a pesquisa qualitativa em educação. São Paulo: Atlas,

71 GERENCIAMENTO DE PROJETOS Resumo Desde o final da década de 1990, quando teve início o processo desregulamentação e privatização do setor de telecomunicações no Brasil, o crescimento desse setor tem sido significativo, com destaque especial nos serviços de telefonia celular. Dentre as estratégias de crescimento adotadas pelas quatro maiores empresas operadoras de telefonia celular no Brasil, está a utilização da aquisição de outras operadoras, que outrora operavam regionalmente, para chegar à posição de operação com cobertura nacional. Dos projetos de junção de empresas resulta como desafio a integração dos sistemas de TI, sendo que, para executá -los, as empresas têm buscado a utilização de técnicas modernas de gerenciamento de projetos, implantadas através dos Escritórios de Gerenciamento de Projetos (EGP). O presente trabalho apresenta as dificuldades encontradas no processo de implantação, consolidação e operação do EGP no contexto de junção de empresas operadoras de telefonia celular. Palavras-chave: Escritório de Gerenciamento de Projetos (EGP), implantação do gerenciamento de projetos, junção de empresas, setor de telecomunicações, Tecnologia da Informação (TI). INTRODUÇÃO Seguindo uma tendência m undial, o crescimento do setor de telecomunicações no Brasil tem sido significativo nos últimos anos, com destaque especial aos serviços de telefonia celular. Esse crescimento vem ocorrendo desde o final da década de 1990, quando teve início o processo de desregulamentação e privatização do setor. Entre 1994 e 2004, o número de terminais celulares passou de 755 mil para quase 68 milhões, conforme apontado na Figura 1. Em 2004, o mercado consumidor de telefonia celular estava distribuído por sete operadoras, com quatro delas detendo aproximadamente 92% do m ercado (TELECO, 2005). O crescimento da magnitude do setor de telecomunicações no Brasil só tem sido possível devido ao processo de inovação tecnológica e de políticas públicas adotadas no Brasil a partir de

72 (CAMPANÁRIO et al., 2004). O modelo de crescimento da telefonia celular tem entre seus pilares de sustentação a competição entre as empresas operadoras de telefonia. Para garantir o princípio de concorrência, o poder público, através da Agência Nacional de Telecomunicações (ANATEL), outorga licenças para mais de uma operadora em uma mesma área de cobertura geográfica. As operadoras de celular do Brasil, com exceção de alguns casos especiais, têm as suas áreas de prestação de serviço correspondentes às dez áreas definidas originalmente para o Serviço Móvel Celular (SMC) ou para as quatro regiões do Serviço Móvel Pessoal (SMP). Em conseqüência dessa política pública, algumas regiões no Brasil contam com até quatro operadoras deste serviço numa mesma área de concessão. Da situação original de composição de operadoras do modelo SMC para o atual SMP, houve uma redução no número de competidores regionais, através da consolidação de operadoras, para atender ao requisito de cobertura nacional. Dentre as estratégias de crescimento, as quatro maiores empresas utilizaram-se da aquisição de outras, que outrora operavam regionalmente, criadas no modelo SMC, para se chegar à posição de operação com cobertura nacional. Devido a esse processo, as empresas se depararam com a necessidade de integrar seus processos e sistemas herdados das operadoras originais. Dentre esses sistemas, estão os sistemas de Tecnologia de Informação (TI). Os sistemas de TI exercem um papel fundamental para a sobrevivência dos negócios das empresas. Tal qual em qualquer outro segmento de negócio com intensa utilização de sistemas de TI, um dos maiores desafios nos projetos de junção de empresas é a integração dos processos corporativos e de negócio, utilizando a integração dos sistemas com o principal ferramenta para operacionalizálos. Para vencer este desafio, as empresas têm tratado este processo de consolidação como um conjunto de projetos e programas (portfólio1) e, visando atingir o resultado esperado, têm buscado a utilização de técnicas modernas de gerenciamento de projetos. Como conseqüência da adoção dessas técnicas pelas equipes de desenvolvimento de projetos de TI, observa-se a implantação de empresa que pretende alcançar sucesso em gerenciamento de projetos deve desenvolver um processo de implantação bem sucedido. Escritórios de Gerenciamento de Projetos (EGP). 72

73 O EGP já é uma realidade em muitas empresas do setor de telecomunicações (BARCAUI, 2003), exercendo um papel subjacente no processo de crescimento das organizações, que é o de contribuir para a eficiência nos resultados dos seus projetos estratégicos. O foco deste artigo é o estudo de fatores que influenciam os processos de implantação e consolidação de um EGP, tendo como base o estudo de caso em uma operadora de telefonia celular do Brasil e outros casos análogos, na forma de artigos, que também foram pesquisados. O trabalho iniciou com a revisão da literatura sobre gerenciamento de projetos, maturidade em gerenciamento de projetos e EGP. Também foram coletadas informações sobre outros casos já publicados. Em seguida, através de entrevistas, foram levantados dados sobre o processo de implantação do EGP e os projetos de integração dos sistemas de TI no caso em estudo. Uma vez apresentados os resultados, procurou-se elaborar a argumentação da análise, considerando-se as teorias de gerenciamento de projetos. REVISÃO BIBLIOGRÁFICA Os itens a seguir resumem a pesquisa bibliográfica realizada no presente estudo. Inicialmente são apresentados, em caráter introdutório, o conceito de gerenciamento de projetos, um breve histórico de sua origem e a evolução de sua utilização, atingindo diferentes indústrias. Em seguida, como fundamento para o item subseqüente, discorre-se sobre o EGP, suas atribuições e classificações. Finalmente, apresentam-se as recomendações encontradas na literatura no que concerne à implantação do EGP, foco deste trabalho acadêm ico. Gerenciamento de Projetos Segundo o PMI - Project Management Institute, associação americana nãolucrativa de profissionais de gerenciamento de projetos, essa disciplina busca atender os requisitos dos projetos através da aplicação de conhecimentos, competências, ferramentas e técnicas de gerenciam ento de projetos (PROJECT MANAGEMENT INSTITUTE, 2000). 73

74 Embora gerenciar projetos seja uma prática muito antiga, o gerenciamento de projetos enquanto disciplina tem sua origem relacionada ao setor militar no período pós-segunda Guerra (WEBSTER2, apud CRAWFORD, 2002, p. 1). Desde então, tem sido cada vez m ais utilizado, estando sua implantação em foco a partir de meados da década de Segundo Kerzner (2002), atualmente a implantação do gerenciamento de projetos constitui a gestão avançada de projetos. A empresa que pretende alcançar sucesso em gerenciamento de projetos deve desenvolver um processo de implantação bem sucedido, sendo fatores de sucesso, dentre outros: ter como base a cultura da organização, realizar treinamentos extensivos e contar com o comprometimento dos executivos, que devem reconhecer o valor que o gerenciamento formal de projetos acrescenta à empresa (KERZNER, 2002). Assim, nos últimos anos, o foco do gerenciamento de projetos migrou da teoria para a sua implantação, outras organizações passaram a utilizá-lo e surgiu o conceito de maturidade em gerenciamento de projetos. De acordo com Kerzner (2002), a maturidade em gerenciamento de projetos é o desenvolvimento de processos e sistemas repetitivos, de modo a aumentar a probabilidade de sucesso dos projetos submetidos a estes processos e sistemas. Diversas são as razões pelas quais as organizações decidem pela implementação das práticas ou pela melhoria do nível de maturidade em gerenciamento de projetos. As forças que comumente motivam as em presas na busca pela maturidade em gestão de projetos são: os projetos estratégicos, as expectativas dos clientes, o entendimento da gestão de projetos com o diferencial competitivo, o maior comprometimento dos gerentes executivos, o desenvolvimento de novos produtos e a melhoria da eficiência e da eficácia, sendo que todas estas forças objetivam sobrevivência da empresa (KERZNER, 2002). Também podem ser considerados como fatores motivadores os benefícios associados ao uso do gerenciamento de projetos, dentre os quais destacam-se, entre os citados por Kerzner (2003), as melhorias em relação a: eficiência, lucratividade, controle de mudanças de escopo, relacionamento com clientes, identificação de riscos, qualidade, distribuição de informações e competitividade. Entre as indústrias que apresentam crescente utilização do gerenciamento de projetos, Crawford (2002) cita os segmentos de TI, de serviços de informação e de a 74

75 desenvolvimento de novos produtos, que buscam obter, através do gerenciamento, benefícios específicos, a saber: a redução de custos, a diminuição do ciclo de vida para lançamento de novos produtos e a melhoria na qualidade dos produtos entregues. Também progrediram nesta disciplina os setores bancário, farmacêutico, de telecomunicações, de petróleo e de gás. Segundo Kerzner (2002), essas indústrias progrediram nos últimos anos mais do que os outros setores em dez anos, sendo que três fatores acentuaram a busca da excelência em gestão de projetos nesses setores: fusões, aquisições e legislação, todos associados à competitividade e à necessidade de sobrevivência das empresas. Alguns estudos recentes apontam para o aumento do índice de sucesso dos projetos. Dentre as razões enumeadas pelo Standish Group International, Inc. (2001) e por Johson3, citado por Crawford (2002, p. 8), estão: Tendência utiliza ão de projetos menores e menos complexos, com conseqüente diminuição do custo médio; Desenvolvimento de ferramentas de controle de progresso dos projetos e aumento da utilização de processos de gerenciamento ; Capacita ão dos gerentes de projetos, resultando em um m elhor gerenciamento dos projetos ; Uso de estruturas como as constituídas atrav s dos EGPs. Assim, a implantação do EGP pode ser vista como um meio para obtenção de sucesso em projetos e está relacionada ao surgimento e propagação da disciplina. O EGP A origem do EGP está associada aos departamentos de projetos existentes no final da década de 1950 e início dos anos O departamento de projetos possuía atuação restrita aos grandes projetos e tinha como principais funções a atualização dos cronogramas e a preparação da documentação do cliente. Geralmente o departamento era associado ao espaço físico que ocupava e atendia a um único cliente (KERZNER, 2002); (KERZNER, 2003). Atualmente o EGP, também conhecido como Project Management Office (PMO), possui diversas definições, sendo que a maioria delas está associada ao fato de agregar as fontes das melhores práticas de gerenciamento de projetos. Desta forma, o EGP é tido como o responsável por implementar, manter e suprir as 75

76 necessidades da organização no que se refere a essa disciplina (CRAWFORD, 2002); (ENGLUND et al., 2003); (KERZNER, 2003). Igualmente diversas são as classificações ou níveis dos EGP. A classificação proposta por Crawford (2002) e Englund et al. (2003) divide os EGP em três níveis, que podem existir concomitantemente na organização: Nível 1 Escritório de Controle de Projetos O Escritório de Controle de Projetos possui como principais funções o desenvolvimento do planejamento do projeto e a emissão de relatórios de progresso. Apresenta foco em um único projeto, porém de grande porte e complexidade. (CRAWFORD, 2002). Nível 2 Escritório de Projetos da Unidade de Negócios O Escritório de Projetos Nível 2 oferece suporte aos projetos da área, de diferentes porte e com plexidade. Crawford (2002) destaca como principais funções do EGP a priorização entre os projetos e o gerenciamento de recursos. Entretanto, a integração destes projetos ocorre ao nível da Unidade de Negócios, não atingindo o nível corporativo. Nível 3 Escritório Estratégico de Projetos As principais atribuições do Escritório de Projetos Nível 3, segundo Crawford (2002), são: Selecionar, priorizar e garantir a integra ão dos projetos que estejam alinhados à estratégia da organização, inclusive no que se refere ao uso de recursos; Desenvolver, a tualizar e divulgar a metodologia de gerenciamento de projetos, bem com o divulgar o conhecimento em gerenciamento de projetos ; Tornar-se um centro de gestão do conhecimento, através do armazenamento de informações dos projetos na forma de lições aprendidas; Validar as estimativas de recursos feitas pelos projetos, baseado nas experiências de projetos anteriores. Im plantação do EGP 76

77 Apesar do conhecimento dos benefícios relacionados ao EGP, implantá-lo apresenta alguns desafios, principalmente por representar uma mudança cultural para a organização e envolver pessoas. Embora disseminar a cultura de gerenciamento de projetos exija tempo, Crawford (2002) sugere que a organização imprima certa velocidade à implantação do EGP, de modo a apresentar os primeiros resultados em seis meses. Outro fator a ser considerado no processo de implantação do EGP é o seu escopo de atuação, uma vez que a resistência apresenta diferentes níveis conforme novas responsabilidades são incorporadas. As atividades operacionais são facilmente aceitas pela organização, ou seja, apresentam baixo risco, pois implicam em uma pequena m udança de poder e não alteram a cultura organizacional. Como exemplos destas atividades, citam-se o desenvolvimento de metodologia e padrões, os treinamentos e o gerenciamento dos principais interessados. Por sua vez, existem outras atividades cuja implementação apresenta risco moderado, já que podem ocasionar alteração na estrutura de poder e autoridade da organização, como, por exemplo, o planejamento estratégico para o gerenciamento de projetos, a manutenção do histórico de lições aprendidas e os relatórios de desempenho. Por fim, as atividades de alto risco estão relacionadas à existência de grupos de resistência, uma vez que alteram a estrutura de poder e autoridade da organização. Com o exemplos destas atividades, podem ser citadas: a comparação das práticas da organização às práticas de outras empresas, a condução dos processos de priorização e aprovação dos projetos, bem como a auditoria interna de projetos. De forma a obter suporte para o estabelecimento do EGP, devem ser implantadas, primeiramente, as atividades de baixo risco (KERZNER, 2003). De acordo com Englund et al. (2003), a implantação do EGP deve ser feita em três etapas. Na primeira são criadas as condições para a mudança, e por isso a mesma é crítica para o sucesso do EGP. Englund et al. (2003) sugerem como passos dessa primeira etapa: 1) Evidenciar a importância da mudança e o senso de urgência junto aos membros da organização. Dentre as justificativas para a necessidade da mudança ocorrer nesse momento, podem ser utilizadas as taxas de insucesso em projetos e a comparação das práticas da organização às práticas de outras empresas. 77

78 2) Identificar possíveis grupos de resistência e apresentar a estes grupos os benefícios da mudança. 3) Buscar um patrocinador influente e desenvolver coalizões com membros da empresa. 4) Estabelecer quais as contribuições do EGP para atingir a visão do futuro da organização. 5) Elaborar o plano para im plantação do EGP e divulgá-lo à organização. Na segunda etapa, os agentes de mudança implementam a mudança, enquanto na terceira e última etapa é necessário motivar para que a situação pós-mudança seja a nova realidade, ou seja, procura- se recongelar a nova situa ão. De modo particular, no Brasil a produção científica a respeito do EGP ainda é pequena, principalmente por se tratar de um conceito recente. Alguns indícios do perfil dos EGPs brasileiros são apresentados no trabalho elaborado por Barcaui (2003). Dentre os resultados citados no estudo a respeito das empresas que possuem EGPs ou alguma estrutura similar instalada, e que, portanto, passaram pelo processo de im plantação, destacam-se: A maioria composta por empresas multinacionais de grande porte; Os principais ramos de atividade das empresas dos respondentes que possuem EGPs ou alguma estrutura sim ilar instalada são TI, Telecomunicações e Engenharia; A maioria possui estrutura organizacional predominantemente do tipo matricial; Segundo os respondentes, a maioria das empresas apresenta nível de maturidade médio, sendo que a pesquisa não definiu previamente um modelo de maturidade para análise; Os principais fatores motivadores para a implanta ão do EGP foram: a necessidade de alinhamento com as melhores práticas de gerenciamento de projetos do mercado, a ausência total ou parcial de controle do portfólio sentida pela gerência executiva e a ausência total ou parcial de metodologia, processos e padrões de gerenciamento ; Os EGPs geralmente foram implantado s acoplados a uma diretoria ou gerência específica, o que faz com que nem todos os projetos da empresa sejam administrados pelo EGP. Geralmente, são administrados os projetos de valor elevado, de alta complexidade ou de inovação; 78

79 A maioria das implanta es foi feita sem apoio de consultoria externa e fazendo uso de um projeto-piloto; Para a maioria dos respondentes, o grau de envolvimento da alta adm inistra ão na implementação foi alto; A maioria dos respondentes atribui implementa ão do EGP ganhos de desempenho dos projetos, dentre outros: melhorias relacionadas à lucratividade, ao cumprimento dos prazos, à adequação ao orçamento, à entrega do escopo previsto, ao grau de satisfação de clientes, da alta diretoria da empresa e das equipes de projeto, além do grau de m otivação dos gerentes de projeto. Ressalva-se, porém, que o estudo apresenta como limitação a abrangência da amostra, não permitindo a generalização das suas conclusões (BARCAUI, 2003). Outros indícios sobre a condução do processo de implantação do EGP em empresas brasileiras ou instaladas no Brasil são encontrados nos anais de encontros das comunidades de gerenciamento de projetos. Assim, foram identificados estudos de casos descrevendo o processo de implantação dos EGPs de diversas empresas que, embora pertençam a ramos de atuação distintos, apresentaram diversas similaridades, sendo algumas delas resumidas a seguir. Primeiramente, entre os fatores motivadores para a implantação do EGP nos casos em questão foram citados: A demanda por uma metodologia padronizada de gerenciamento de projetos (ANSELMO; MAXIMIANO, 2003); A existência de projetos estratégicos (SCHELP, 2003); O direcionamento da alta administra ão (MERKT, 2003); (SCHELP, 2003); A tentativa de assegurar a vantagem competi tiva (MERKT, 2003). Adicionalmente, o apoio da alta administração foi apontado como fator crítico de sucesso para a implantação do EGP por Anselmo; Maximiano (2003) e por Schelp (2003). Por sua vez, como dificuldades encontradas, destacaram -se a cultura organizacional e a resistência das pessoas no que tange às mudanças organizacionais necessárias (ANSELMO; MAXIMIANO, 2003); (SCHELP, 2003), além da falta de entendimento das atribuições do EGP (SCHELP, 2003). Finalmente, em alguns dos casos, a implantação do EGP ocorreu concomitantem ente à outra iniciativa visando à disseminação da cultura de 79

80 gerenciamento de projetos (SCHELP, 2003) ou ainda à aplicação de um modelo de maturidade em gerenciamento de projetos (MERKT, 2003). Também foram encontrados casos (SKROBOT; MAYER, 1996); (RABECHINI Jr. et al., 2002) descrevendo a implantação do gerenciamento de projetos sem menção da existência do EGP. Também nesses estudos foi reforçada a importância do papel da alta administração no processo. ABORDAGEM METODOLÓGICA A utilização do estudo de caso como método de pesquisa apresenta como vantagens a manutenção das características principais de eventos da vida real e a garantia da visão holística do problema estudado (YIN, 1994). De acordo com esta referência, três condições devem ser obedecidas para a escolha do estudo de caso como m todo de pesquisa: as quest es de pesquisa devem ser do tipo como ou por que, o pesquisador não deve exercer controle sobre os eventos a serem investigados e o foco da pesquisa deve ser um fenômeno contemporâneo inserido em um contexto da vida real. Para o presente artigo, estas condições foram satisfeitas e assim o estudo de caso foi utilizado como método de pesquisa. Os dados e informações foram levantados através de entrevistas, nas quais procurou-se identificar as principais dificuldades e os fatores de sucessos encontrados na implantação e consolidação do EGP, considerando o contexto de junção de empresas operadoras de telefonia celular. Uma vez apresentados os resultados, os m esmos foram analisados comparativamente com estudos de casos análogos na forma de artigo, considerando a bibliografia existente sobre gerenciamento de projetos. Assim, o presente estudo pretende responder à questão da pesquisa: fatores que influenciam o processo de consolidação do EGP? Quais são os Para essa questão, foram consideradas como hipóteses que os seguintes fatores influenciam o processo de consolidação do EGP: 1) O desenvolvimento das competências em gerenciamento de projetos, de forma aderente às características organizacionais da empresa. A adoção e o desenvolvim ento da metodologia de gerenciamento de carecem de transformações profundas na cultura organizacional (RABECHINI, 2003). Nas diversas camadas da estrutura da empresa, a saber, indivíduos, equipe e projetos 80

81 organização, o desenvolvimento de competências em gerenciamento de projetos, visando estabelecer uma cultura voltada para projetos, influencia positivamente no processo de consolidação do conceito de EGP, ao mesmo tempo em que precisa respeitar as características da cultura organizacional da empresa. 2) O modelo da estrutura organizacional deve ser capaz de absorver as transformações necessárias à condução de projetos estratégicos e complexos. A estrutura organizacional, em concordância com os modelos propostos pela literatura, a saber, projetizada, matricial e/ou funcional (RAD, 2000), deve ser capaz de absorver as transformações necessárias à condução de projetos estratégicos e complexos. 3) O entendimento do EGP como meio de geração de resultados. O entendimento do EGP como elemento importante na geração de resultados desejados aos negócios da organização, seja através do melhor desempenho dos projetos, seja pela sua função de suporte ao planejamento estratégico das organizações, influencia o processo de consolidação do EGP. 4) A influência do patrocinador No meio profissional é tida como necessária a presença de um forte patrocinador como parte do sucesso para a consolidação do conceito de EGP. Neste trabalho, busca-se ratificar a importância do patrocinador na m anutenção da vontade política do processo de consolidação do EGP, principalmente quando as atividades do EGP passam do nível operacional para o nível estratégico, com maior risco para a estrutura de poder da empresa. Helme et al. (2005) apresenta em seu estudo sobre a avaliação do papel do patrocinador no apoio de projetos com plexos as seguintes necessidades, dentre outras: habilidade e disposição para conectar os projetos à organização; compatibilidade pessoal com outras pessoas chaves da organização; apropriada senioridade e for as dentro da organiza ão. ESTUDO DE CASO Os itens a seguir apresentam o estudo de caso propriam ente dito. Inicialmente, em caráter informativo, são apresentadas as informações sobre a empresa e o contexto no qual ela está inserida. Em seguida, apresenta-se o projeto que executou a implantação, o contexto onde a implantação ocorreu e as principais características 81

82 do EGP. Finalmente apresenta-se como o EGP foi afetado pela junção entre empresas e como o mesmo consolidou-se após esse histórico, sendo o último item o foco deste trabalho acadêmico. A empresa A empresa estudada atua como Operadora de Telefonia Celular e tem abrangência em todo o território brasileiro. Está entre as m aiores do hemisfério sul, tendo resultado da junção de operadoras originalmente pertencentes a dois grupos estrangeiros. Os principais serviços oferecidos pela empresa estão relacionados à transmissão de voz e dados. Embora esteja em posição de liderança no mercado nacional, desde 2002 a empresa vem enfrentando desafios para manter essa posição. Para vencê -los, uma das estratégias adotadas foi a consolidação dos sistemas de informação, visando comprimir os ciclos para lançamento de novos produtos e serviços, possibilitar o lançamento de campanhas nacionais, melhorar os índices de atendimento ao cliente e reduzir os custos de manutenção e operação de sistemas. Esses objetivos coincidem com as exigências do mercado atual, que acabaram por fazer com que as organizações se voltassem para o gerenciamento de projetos, segundo Crawford (2002). Quanto à estrutura organizacional, pode-se dizer que, analisada globalmente, a empresa possui estrutura funcional, ou seja, a estrutura de poder está nas colunas. Entretanto, visando atender às exigências de mercado, a empresa vem esboçando ensaios de estruturas matriciais ou projetizadas em áreas específicas, para atender às necessidades de projetos estratégicos e complexos. Im plantação do EGP A necessidade de consolidação dos sistemas da empresa surgiu do processo de junção, associado ao cenário caracterizado pela escassez de recursos, pela dificuldade de priorização dos projetos e por falhas, em sua maioria relacionadas aos atrasos e aos produtos entregues sem atender às expectativas dos clientes internos. Assim, a estruturação de um programa de consolidação de TI foi o principal fator motivador para a implantação de um EGP, dando origem ao Projeto de Im plantação do EGP para o Programa de Consolidação de Sistemas. 82

83 Desde o início, o EGP foi entendido como elemento facilitador e condutor da mudança para a cultura de gerenciamento de projetos. Por isso, a empresa considerou que a implantação do EGP não seria possível sem o desenvolvimento de competências em gerenciamento de projetos e, como no caso apresentado em SCHELP (2003), estabeleceu o Projeto de Form ação de Profissionais em Gerenciamento de Projetos. Esse projeto se iniciou antes do Projeto de Implantação do EGP e teve como objetivo disseminar a cultura de gerenciamento de projetos nas áreas da empresa com maior envolvimento em projetos. Para tanto, foram realizados treinamentos formais e aconselhamento em projetos ( mentora ão ). Além disso, metade dos colaboradores participantes do programa foi certificada como profissionais de gerenciamento de projetos (PMP Project Management Professional 4). Ambos os projetos, Form ação de Profissionais em Gerenciamento de Projetos e Im plantação do EGP para o Programa de Consolidação de Sistemas, foram formalm ente vinculados à estratégia da empresa, garantindo assim o apoio formal da alta administração. Projeto de Implantação do EGP para o Program a de Consolidação de Sistemas A implantação do EGP foi tratada como um projeto, sendo então o primeiro a utilizar a metodologia proposta, ainda em elaboração. Inicialmente foram focadas pelo EGP as atividades operacionais, como forma de garantir a aceitação pela estrutura de poder da empresa, tornando o EGP um aliado ao cumprimento dos objetivos dos projetos conduzidos por essa estrutura. As principais dificuldades encontradas na implantação referem-se à mudança cultural que o EGP representava e à resistência das pessoas devido à alteração da estrutura de poder. Os principais riscos identificados pela empresa ao longo do projeto de im plantação e as respectivas estratégias de resposta foram: Amea a credibilidade do EGP: sendo o EGP respons vel por informar o status dos projetos sob a liderança das diretorias de TI, era imprescindível que estes diretores confiassem no EGP e o tivessem como aliado. Para tanto, foi inserido o papel do Facilitador, uma pessoa de confiança dos diretores, normalmente um gerente funcional, que participava dos projetos ao lado dos gerentes e dividindo o 83

84 papel de patrocinador com o Diretor de TI. O EGP tinha uma relação muito estreita com esses Facilitadores, informando-os, em primeira instância, sobre os eventuais problem as, para que tivessem tempo de agir, antes da publicação do status final. Dificuldade em encontrar no mercado profissionais com o perfil adequado ao EGP: como ainda era recente a explosão do gerenciamento de projetos, havia poucos profissionais disponíveis que conheciam as funções de um EGP e alguma metodologia em gerenciamento de projetos. A solução encontrada foi a contratação de um profissional certificado em gerenciamento de projetos e dos serviços de consultoria de terceiros com experiência anterior em EGPs. Assim, a equipe do EGP foi formada por esses profissionais, associados a outros com conhecim ento da empresa, porém menos experientes em gerenciamento de projetos. Visando eliminar a eventual dependência da consultoria na fase pósimplantação, durante a fase piloto pesquisaram-se em outras áreas colaboradores dispostos a integrar a equipe. Deste m odo, a participação da consultoria reduzia-se à medida que novos integrantes ingressavam na equipe do EGP. Dificuldade para formalizar a estrutura no organograma da empresa: tendo em vista a iminente unificação com outro grupo empresarial, não foi possível a formalização de uma nova estrutura, já que uma alteração muito maior iria acontecer. Sendo assim, buscou-se fortalecer as funções e responsabilidades do EGP, procurando-se evidenciar a importância dessas atividades para a obtenção de resultados nos principais projetos da empresa. Assim, ao mesmo tempo em que o EGP atuava diretamente comprometido com o sucesso dos atuação focada na organização e empenhava-se na aplicação da metodologia como ferramenta para direcionar a equipe rumo aos objetivos. Caracterização do EGP O EGP de TI entrou em operação ao término do seu projeto de implantação, com o portfólio restrito aos projetos do Plano de Consolidação de Sistemas. Entre as principais funções do EGP implantado citam -se: projetos, possuía Desenvolver e divulgar a metodologia de gerenciamento de projetos, buscando identificar suas m elhores práticas; Escolher e implantar as ferramentas definitivas de gestão de projetos, uma vez que durante a fase inicial do projeto foram implantadas somente as ferramentas básicas, enquanto as definitivas aguardavam a consolidação da metodologia; 84

85 Criar e manter base de dados de gerenciamento dos projetos ; Gerenciar o Plano de Comunica ão, divulgando informa es relevantes sobre os projetos e sensibilizando os patrocinadores para os problemas em que precisavam atuar junto ao gerente de projeto ou ao facilitador; Desenvolver a cultura de gerenciamento de projetos na organização; Garantir o alinhamento dos projetos à estratégia da organização; Antecipar os potenciais problemas, para que os respons veis de cada projeto pudessem atuar no sentido de cumprir os objetivos do projeto. Da organização interna do EGP, destaca-se que a mesma possuía um único líder e estava subordinada diretamente ao seu patrocinador. Outro papel de destaque no organograma do EGP era o de Coordenador de Programas, responsável por atuar junto aos gerentes de projetos, oferecendo suporte na utilização da metodologia, responsabilizando-se pela atualização dos cronogramas de eventualmente atuando como mentores. Por sua vez, os gerentes de projetos e projetos não faziam parte da organização interna do EGP, o que trazia algumas vantagens, podendo-se destacar: O EGP tornava -se mais ágil, capaz de atuar em diversos aumentar a equipe de forma excessiva; projetos, sem ter que A dissemina ão da cultura de gerenciamento de projetos era facilitada, pois como o gerente de projetos estava nas áreas funcionais e, na maioria das vezes, era um participante do Programa de Formação de Profissionais em Gerenciamento de Projetos, exercia papel fundamental na formação dos demais membros da equipe funcional; A estrutura de poder foi poupada, uma vez que os gerentes de projetos estavam subordinados às áreas funcionais das Diretorias de TI, estimulando a liderança e participação do diretor e seus gerentes funcionais. Com plem entarmente, para fazer com que a organização como um todo reconhecesse a função do EGP, mesmo sem estar formalmente no organograma da empresa, foi estabelecida uma sigla de fácil utilização, além de um logotipo, utilizado em todos os documentos e s emitidos pela equipe do EGP. Impactos da junção das empresas na operação do EGP Seis meses após a implantação do EGP, a em presa passou pelo já esperado processo de unificação com outro grupo empresarial. O EGP, que já estava em 85

86 funcionamento, continuou não sendo formalizado na nova estrutura organizacional. Primeiramente pela dificuldade de absorção de uma estrutura formal de EGP pela nova empresa que estava sendo formada, associada à perda do principal patrocinador do EGP, desligado da empresa, e ao clima de mudança presente em todas as áreas. Apesar disso, a mudança cultural estava consolidada, principalmente pela conclusão do Projeto de Formação de Profissionais em Gerenciamento de Projetos, pela divulgação da metodologia e pelos resultados que vinham sendo obtidos em projetos com a implantação do EGP. Assim, como as funções do EGP foram reconhecidas como essenciais, as lideranças que passaram a se envolver com a unificação da nova empresa buscaram garantir a contínua disseminação destas práticas de gerenciamento. Para tanto, distribuíram a equipe do EGP pelas novas diretorias de TI, especificamente nos projetos de consolidação iniciados logo após a unificação. Deste modo, existiria em cada projeto ao menos um profissional aplicando a metodologia e fornecendo suporte ao gerente de projetos no planejamento e controle do mesmo. Isso se deu porque essas lideranças estavam cientes da necessidade do gerenciamento de projetos para obtenção do sucesso nos projetos do programa de consolidação, que se tornaram ainda mais complexos após a junção das empresas. Com isso, acabaram por suportar o reinício da implantação do EGP, desta vez com as características da nova empresa. Também nesta época foi introduzido o conceito de time principal, também conhecido como core-team. Tratava-se de equipes multidisciplinares cujos membros possuíam as competências necessárias ao projeto, ao mesmo tempo em que representavam as principais áreas envolvidas. Essa estrutura foi proposta visando garantir a distribuição de responsabilidades, necessária no novo ambiente dos projetos que começara a surgir, pois proporcionava a participação formal de diferentes áreas funcionais, ao mesmo tempo em que diminuía a quantidade de canais de comunicação entre a equipe e o gerente do projeto. Além disso, essa forma de organização das equipes possibilitou a disseminação mais rápida da nova forma de trabalho por gerenciamento projetos e a criação de um comportamento voltado para o Uma vez que os objetivos dos de projetos e conseqüente cumprimento dos seus objetivos. projetos de consolidação eram ousados, principalmente na gestão dos prazos, o uso da metodologia de gerenciamento foi 86

87 um diferencial, uma vez que possibilitava a atuação focada nos objetivos, sendo os resultados percebidos ao longo de todas as fases e gerando confiança das áreas usuárias. Após um ano, foram iniciadas as implantações dos sistemas, todas bem sucedidas, sem im pactos às áreas operacionais ou aos clientes finais. Consolidação do EGP Após a implantação dos projetos de consolidação acima mencionados, novos projetos também de consolidação foram incluídos no programa5. Tais eram ainda mais complexos e abrangentes, razão pela qual passaram a ser tratados projetos como projetos estruturantes, e não mais como projetos de tecnologia, à medida que pressupunham, na consolidação das plataformas, a alteração da estrutura de processos, produtos e serviços. A existência do EGP, cuja atuação passou a estar além das fronteiras da área funcional de Tecnologia, foi apontada pelos patrocinadores e pelos gerentes desses projetos como garantia de sucesso. Deste modo, a formalização do EGP deu-se principalmente pela existência de projetos tidos como estratégicos, sendo esse um dos fatores citados por Kerzner (2002) como motivadores da busca da maturidade em gerenciamento de projetos. Nessa época, a estrutura organizacional da empresa, embora ainda na sua maior parte funcional, foi flexibilizada para adequar-se à nova realidade, sendo formalizadas duas estruturas de gerenciamento de projetos que permanecem na empresa até a ocasião da realização deste estudo de caso. A primeira é subordinada à área funcional de Tecnologia e com atuação nos É responsável pela manutenção da metodologia e das ferramentas de projetos desta área. gerenciamento de projetos, além de atuar como prestadora de serviços para a segunda estrutura, subordinada a uma das Vice-Presidências Operacionais. Esta vice-presidência é patrocinadora da maioria dos projetos estruturantes e atua especificam ente no cumprimento dos objetivos do Programa de Consolidação de Sistemas. No seu âmbito, é uma diretoria de estrutura matricial, tendo nas colunas os líderes dos projetos e, nas linhas, gerentes de função que atuam transversalmente em todos os projetos, desempenhando as funções: Tecnologia, Processos, Implantação e EGP. Essa segunda estrutura está condicionada à duração do Programa, estando os profissionais temporariamente alocados a ela, podendo retornar às suas áreas de origem ao final de cada projeto. 87

88 Dentre as principais funções exercidas pelo EGP após a Consolidação citam -se: Garan tir a aplicação da metodologia de gerenciamento de projetos ; Integrar os planos dos projetos dentro do próprio Programa e aos outros projetos de tecnologia; Garantir o alinhamento dos projetos à estratégia da organização; Atuar de forma preventiva, n o sentido de preservar o plano de cada projeto e do programa como um todo; Ressaltar os pontos de risco de cada projeto aos líderes de projetos, aos patrocinadores e aos demais interessados, auxiliando na definição e aplicação de ações preventivas ou cor retivas, no sentido de preservar o plano. Um fator crítico para o sucesso desta estrutura foi o fato da mesma ser considerada uma evolução natural de todo o processo de implantação do EGP, podendo contar com todas as ações anteriores de estruturação para implantação de um a nova cultura. A principal dificuldade enfrentada nesta fase está relacionada à forma de trabalho em uma estrutura matricial, onde cada profissional deve aprender a trabalhar com diversos níveis de subordinação e atuar com influência na estrutura funcional para atingir os objetivos do projeto, além de garantir a incorporação das entregas dos produtos dos projetos aos processos operacionais da estrutura funcional. Dentre os resultados atribuídos pela empresa, total ou parcialmente, à implantação do EGP encontram-se: Crescimento da empresa e atendimento da exigência de mercado em rela ão ao prazo de lançamento dos novos produtos; Implanta ão da metodologia de gerenciamento de projetos, com conseqüente obtenção de sucesso nos mesm os, ou seja, projetos implantados sem causar impacto nas operações da companhia ou ao cliente final. Mudan a de cultura, envolvendo todas as reas de negócio. RESULTADOS OBTIDOS Com relação às hipóteses formuladas sobre os fatores que influenciam o processo de consolidação do EGP, cada fator foi analisado conforme a seguir: 1) O desenvolvimento das competências em gerenciamento de projetos, de forma aderente às características organizacionais da empresa. 88

89 No caso analisado observou-se que o EGP respeitou a cultura da empresa em dois momentos: Na implanta ão, quando a jun ão das empresas era iminente e não caberia uma proposta de alteração do organograma. Neste momento, a alternativa adotada foi o investimento na formação dos profissionais e na consolidação da metodologia. Após a jun ão das empresas, quando se esperava a formaliza ão e a mesma não ocorreu. Como alternativa, investiu-se na aplicação da metodologia e do modelo operacional já estabelecido em projetos estratégicos e complexos, evidenciando o valor do EGP nesses projetos. Assim, ter como base a cultura da organização e a realização de treinamentos extensivos, durante a implantação do EGP, foram considerados fatores críticos de sucesso, coincidindo com os fatores apresentados por Kerzner (2002). Sendo capaz de se adaptar, o EGP mostrou seu valor e conquistou a formalização em uma estrutura especificamente criada para gerenciar os maiores e mais complexos projetos da empresa. Isso foi viabilizado pelo fato de o EGP ter se apoiado em pilares que promoviam a disseminação da cultura e da metodologia de gerenciamento de projetos, preparando a organização para a sua formalização, enquanto apresentando bons resultados e incrementando a demanda pelas funções de um EGP. Estes pilares foram apresentados no estudo de caso e estão resumidos a seguir: A equipe do EGP era pequena, gil e capaz de atuar em diversos projetos simultaneamente, através do papel do Coordenador de Programas; A dissem ina ão da cultura de gerenciamento de projetos foi facilitada pelos gerentes de projetos que haviam participado do Programa de Formação e que foram mantidos nas áreas funcionais, enquanto ajudados pelos Coordenadores de Programa. 2) O modelo da estrutura organizacional deve ser capaz de absorver as transformações necessárias à condução de projetos estratégicos e complexos. Neste estudo de caso, foi evidenciada a predisposição da empresa em adaptar sua organização formal à forma de trabalho em projetos. Mesmo antes de alterá-la formalmente, foi possível introduzir conceitos e formas de trabalho que serviram de aprendizado para a posterior formalização. 89

90 Uma das principais ferramentas utilizadas pelo EGP para ganhar flexibilidade e permeabilidade de suas funções na organização foi o conceito de time principal. Utilizando este conceito, o EGP garantiu a formalidade aos projetos organização a necessidade de se trabalhar com times multidisciplinares, capazes de agregar as competências necessárias aos projetos. Embora a estrutura flexível tenha permitido a consolidação do EGP, a mesma trouxe novas dificuldades, como os diversos níveis de subordinação, a atuação com influência na estrutura funcional para atingir os objetivos do projeto e a garantia das entregas dos produtos dos projetos a esta estrutura funcional. e m ostrou à Considerando os três níveis de EGP apresentados por Crawford (2002), constatouse que as funções do EGP, no caso estudado, estão distribuídas, principalmente, entre os níveis 1 e 3. Neste caso, o nível 1 (Escritório de Controle de Projetos ) refere-se aos EGPs que atuam com foco em cada um dos projetos estruturantes, enquanto o nível 3 (Escritório Estratégico de Projetos ) coordena os EGPs de nível 1 dos projetos estruturantes e faz o relacionamento com a estratégia da organização. O nível 2 está presente na estrutura de gerenciamento de projetos formalizada dentro da unidade de negócio de Tecnologia, que cuida de funções como metodologia e ferramentas de suporte. 3) O entendimento do EGP como meio de geração de resultados. Dentre as diversas razões mencionadas por Kerzner (2002) pelas quais as organizações decidem pela implantação das práticas de gerenciamento de projetos, foi possível observar neste caso específico a presença de duas delas: a existência de projetos estratégicos e o maior comprometimento dos gerentes executivos. Uma vez que a empresa em questão estava inserida em um ambiente dinâmico, com recursos escassos e metas agressivas, o EGP exerceu papel fundamental escolhendo ferramentas úteis para a equipe e para cada um dos projetos e relacionadas ao cumprimento de seus objetivos. Quanto à implantação do EGP, Crawford (2002) sugere como fator de sucesso que a organização imprim a certa velocidade à mesm a, de modo a apresentar os primeiros resultados em seis meses. No caso apresentado, esse fator foi verificado, 90

91 pois quatro meses após o início de sua estruturação e dois meses após sua implantação o EGP já apresentava resultado em projetos. 4) A influência do patrocinador. No caso apresentado, o EGP começou atuando em atividades operacionais que não trouxessem riscos à estrutura de poder e assim pôde se estabelecer como um aliado ao cumprimento dos objetivos dos projetos conduzidos por esta própria estrutura. Somente depois disto, começou a atuar em atividades estratégicas, conforme demanda da própria empresa, o que, aliado ao apoio do patrocinador forte, facilitou a atuação do EGP no nível 3. Ao longo de todo o histórico deste EGP foi possível perceber a importância de um patrocinador. No início o patrocinador era um único executivo, aos poucos, através de todas as estratégias de disseminação da cultura, foi se transformando em vários executivos das principais áreas de negócio, que passaram a apoiar o EGP e suas funções, facilitando, principalmente as funções relacionadas ao planejamento e controle dos projetos. A importância do apoio executivo também ficou evidente quando o mesmo não esteve presente, principalmente no momento de junção das empresas, quando a demarcação de poder era fator decisivo para os executivos e acabou dificultando a formalização do EGP, que foi deixado de lado e perdeu força. Somente no fim dessa fase o EGP obteve apoio executivo e voltou a ser entendido como fator fundamental para a execução de projetos estratégicos. Os resultados obtidos se tornam indícios de que as hipóteses inicialmente formuladas são válidas para o caso estudado e, considerando que foram observadas em estudos de caso análogos publicados na forma de artigos, podem servir de exemplo e nortear situações similares, desde que preservadas as características únicas de cada empresa. CONSIDERAÇÕES FINAIS O desenvolvimento do presente trabalho foi motivado pelo envolvimento dos autores com as práticas de gerenciamento de projetos e pela percepção dos mesmos em relação à ampla divulgação, no ambiente corporativo, do conceito de projeto, 91

92 enquanto forma de traduzir a estratégia da empresa, de conduzi-la rumo aos seus objetivos e, em última instância, transformá-la. De m odo particular, o interesse pelo caso em questão deu-se principalmente pelo contexto de junção de grupos empresariais, onde se esperava que o caráter formal do gerenciamento de projetos facilitasse a condução de projetos de mudança de cultura e proposição de novas estruturas de trabalho. Tal fato foi verificado no caso analisado e procurou-se evidenciar na sua descrição. Assim, ao mesmo tempo em que o EGP estudado atuou como agente de transição para projetos de consolidação de TI, também gerou a necessidade de adaptação da estrutura organizacional para uma estrutura mais flexível e capaz de absorver a forma de trabalho em equipes multidisciplinares. No entendimento dos autores, a formalização desta estrutura, mesmo que temporária (devido à própria natureza temporária dos projetos ), denotou a importância que a empresa estudada dá ao EGP. Além disso, diante dos estudos de caso e referências bibliográficas analisadas, foi possível entender que não existe uma forma única de implantação de EGP, sendo que cada caso depende da cultura organizacional e do contexto no qual a empresa estiver inserida. Adicionalmente, destaca-se que no caso analisado a escolha da estratégia de implantação do EGP adequou-se à maturidade da empresa: em cada momento distinto o EGP apresentou características diferentes. Porém, verificou-se no caso que a aceitação plena da metodologia somente foi verificada a partir da apresentação de resultados práticos e mensuráveis. Finalmente, o presente trabalho procurou contribuir cientificamente, à medida que foram identificados os fatores que influenciaram o processo de consolidação do EGP na empresa estudada e que podem ser considerados indícios para casos similares. Porém, como restrição do m étodo de pesquisa utilizado, tem -se a im possibilidade da generalização das suas conclusões. Tal generalização seria possível a partir da análise de uma amostra significativa dos EGPs de empresas brasileiras, podendo esta vir a ser objeto de novos estudos. 5 De acordo com o Project Management Institute (2004), programa é um conjunto de projetos relacionados, que devem ser gerenciados de maneira coordenada a fim de obter os benefícios e controles que não seriam possíveis se fossem gerenciados individualmente 92

93 Notas 1 De acordo com o Project Management Institute (2004), portfólio é o conjunto de projetos, programas ou qualquer outro tipo de trabalho que são tratados de forma conjunta, para permitir um efetivo gerenciamento e atender aos objetivos estratégicos do negócio. Os projetos e programas constantes do portfólio não necessariamente precisam estar relacionados ou ser interdependentes. 2 WEBSTER, F. Setting the Stage for a New Profession. PM Network, Abr JOHNSON, J. Turning CHAOS into SUCCESS. Software, Dez PMP Project Management Professional é a certificação emitida pelo PMI Project Management Institute, para aqueles profissionais que são aprovados no seu exame de certificação. Sobre os autores Andréia Pereira Martins Pesquisadora do Program a de Pós-Graduação ênfase em Gestão de Projetos Escola Politécnica da Universidade de São Paulo Departamento de Engenharia Naval e Oceânica Endereço: Av. Professor Mello Moraes, 2231 CEP São Paulo SP Brasil Telefone/fax: r Marcelo Ramos Martins Professor Dr. Escola Politécnica da Universidade de São Paulo Departamento de Engenharia Naval e Oceânica Endereço: Av. Professor Mello Moraes, CEP São Paulo SP Brasil Telefone/fax: r. 254 E-m ail: Marcia Moreira Martins Pereira Pesquisadora do Program a de Pós-Graduação ênfase em Gestão de Projetos Escola Politécnica da Universidade de São Paulo Departamento de Engenharia Naval e Oceânica Endereço: Av. Professor Mello Moraes, 2231 CEP São Paulo SP Brasil Telefone/fax: r Vergílio Antonio Martins Pesquisador do Programa de Pós-Graduação ênfase em Gestão de Projetos Escola Politécnica da Universidade de São Paulo 93

94 REFERÊNCIAS BIBLIOGRÁFICAS SKROBOT, L.C.; MAYER, S. Sistema de Gestão de Projetos TECPAR: 1,5 ano de experiência. In: Sim pósio de Gestão da Inovação Tecnológica, 19., São Paulo, Anais / Organizado por Roberto Sbragia, Jacques Marcovith, Eduardo Vasconcellos. São Paulo: USP/PGT/FIA/PACTo, p TELECO. Portal de informações em telecomunicações. Disponível em: <: Acesso em: 22 maio THE STANDISH GROUP INTERNATIONAL, INC. West Yarmouth, Extreme CHAOS. Disponível em : <http://www.standishgroup.com/sample_research /PDFpages/extreme_chaos.pdf>. Acesso em: 22 maio THE STANDISH GROUP INTERNATIONAL, INC. West Yarmouth, Third Quarter Research Report. Disponível em <http://standishgroup.com/ sample_research/pdfpages/q3-spotlight.pdf>. Acesso em: 22 maio YIN, R. K. Case study research: design and methods. 2. ed. Thousands: Sage Publications, ANSELMO, J. L.; MAXIMIANO, A. C. A. Escritório de Gerenciamento de Projetos: Um Estudo de Caso. In: CONGRESSO IBERO-AMERICANO DE GERÊNCIA DE PROJETOS, 4., São Paulo; Rio de Janeiro, Anais eletrônicos. São Paulo; Rio de Janeiro: Project Management Institute, Disponível em: <http://www.pmisp.org.br/congresso/>. Acesso em: 3 maio BARCAUI, A. B. Perfil dos Escritórios de Brasil Dissertação (Mestrado) Niterói, Projetos em organizações atuantes no Universidade Federal Fluminense. CAMPANÁRIO, M. A.; SILVA, M. M.; ROVAI, R. L. Gestão da inovação no setor de telecomunicações: Inovação Tecnológica e Políticas Públicas em Telecomunicações no Brasil. São Paulo: SBD/FEA/USP, CRAWFORD, J. K. The Strategic Project Office: A Guide to Improving Organizational Performance. New York: Marcel Dekker Inc, ENGLUND, R. L.; GRAHAM, R. J.; DINSMORE, P. C. Creating the Project Office: A Manager s Guide to Leading Organizational C hange. San Francisco: John Wiley & Sons, Inc., HELME, J.; REMINGTON, K. Effective Project Sponsorship: An evaluation of the role of the executive sponsor in complex infrastructure projects by senior project managers. Project Management Journal, v. 36, n. 3, p. 51, KERZNER, H. Gestão de Projetos : as melhores práticas. Trad. Marco Antonio Viana Borges, Marcelo Klippel e Gustavo Severo de Borba. Porto Alegre: Bookman,

95 KERZNER, H. Strategic Planning for a Project Office. Project Management Journal, v. 34, n. 2, p.13-25,2003. MERKT, M.; SANTOS, J.A.; PARIS, W. Estratégia e mudança organizacional: introdução do gerenciamento de projetos em uma organização não-projetizada. In: CONGRESSO IBEROAMERICANO DE GERÊNCIA DE PROJETOS, 4., São Paulo; Rio de Janeiro, Anais eletrônicos. São Paulo; Rio de Janeiro: Project Management Institute, Disponível em: <http://www.pmisp.org.br/congresso/>. Acesso em: 3 maio PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of knowledge (PMBOK Guide) - Third Edition. Newtown Square, PA: Project Management Institute Inc., RABECHINI JR., R.; CARVALHO, M. M.; LAURINDO, F. J. B. Fatores críticos para implementação de gerenciam ento por projetos : o caso de uma organização de pesquisa. Revista Produção, v. 12, n. 2, p.28-41, 2002 RABECHINI JR, R. O Gerente de Projetos na Empresa. São Paulo: Atlas, RAD, P. F., Establishing na organizational project office. AACE International Transactions, ABI/ INFORM Global, p. P13A, RAD, P. F. Is your organization a candidate for project management office (PMO)? AACE International Transactions. ABI/INFORM Global, p. PM71, SCHELP, M. X. Implantação de Escritórios de Gerenciamento de Projetos - Estudo de Caso em uma em presa do setor de autopeças. In: CONGRESSO IBERO-AMERICANO DE GERÊNCIA DE PROJETOS, 4., São Paulo; Rio de Janeiro, Anais eletrônicos. São Paulo; Rio de Janeiro: Project Management Institute, Disponível em: <http://www.pmisp.org.br/congresso/>. Acesso em: 3 maio

96 WGPMS: uma abordagem de inteligência artificial na gestão colaborativa de projetos na WEB Benedito Tourinho Dantas, José Maria N. David Faculdade Ruy Barbosa Salvador - Bahia - Brasil RESUMO A coordenação de um grupo, envolvido em diferentes atividades simultâneas de um projeto, necessita do apoio de ferramentas que permitam avaliar continuamente a participação de cada mem bro. Esta ação acontece em diferentes fases e momentos, tornando difícil para o coordenador identificar os percentuais de contr ibuição atribuídos aos membros do grupo. Tal fato se intensifica quando a quantidade de participantes e contribuições aumenta. Durante a execução das fases, diferentes discussões são geradas, em momentos distintos, dificultando a identificação das contribuições e participações. O objetivo deste trabalho é apresentar uma proposta de desenvolvimento de um módulo de coordenação inteligente para apoiar um groupware, produzindo indicadores e informações, e apontando níveis de contribuição e participação dos colaboradores do projeto. A representação deste conhecim ento, implementada em linguagem de primeira ordem contribui com um sistema de regras que ajuda a medir o nível de colaboração, oferecendo um cenário favorável ao coordenador do projeto. Esta proposta é parte integrante do projeto WGPMS (Web-based Groupware on Project Management Support). PALAVRAS-CHAVE: Groupware; Coordenação; Gerência de Artificial; PMBOK. Projetos ; Inteligência 1. INTRODUÇÃO Iniciar, planejar, executar, monitorar e encerrar projetos não são tarefas fáceis, considerando o conjunto de escopos, recursos e parâmetros que são exigidos em cada etapa. O Project Management Body Of Knowledge (PMBOK), desenvolvido pelo Project Management Institute (PMI) e apresentado em Cavalieri (2005) propôe o ciclo de vida do gerenciamento de projetos, descrevendo grupos de processos integrantes desse contexto. 96

97 Dentre esses grupos destaca-se o processo de monitoramento e controle, foco deste trabalho, que contempla ferramentas de comunicação para apoiar as diferentes etapas do projeto. São elas: (i) verificação e controle do escopo, do cronograma, dos custos, da qualidade; (ii) gerenciamento das comunicações, da equipe e das partes interessadas; (iii) monitoramento e controle do risco, e; (iv) administração e controle do projeto. Segundo Rosenau et al (1998), muitas companhias possuem diversos projetos e padecem de recursos para ajustar os esforços e a demanda. Alguns deles são valiosos e escassos, sendo perdidos em projetos de pouca importância, prejudicando outros de relevância. Dentre esses recursos destaca-se a capacidade intelectual instalada. O WGPMS é um sistema especificado para apoiar a gerência colaborativa de projetos na web. Ele utiliza a gerência de comunicações para implementar controles inteligentes que avaliam a participação dos membros. Além disso, essa gerência é responsável pelo planejamento das comunicações, distribuição das informações, produção de relatórios de desempenho e da gestão das partes interessadas, associada às tecnologias de groupware e inteligência artificial. O foco desta proposta está nas contribuições geradas pelas ferramentas de comunicação para apoiar a coordenação, não sendo o objetivo deste artigo apresentar o WGPMS na sua totalidade. Coordenação em groupware está relacionada às atividades necessárias para a articulação do trabalho para que o grupo consiga atingir o seu objetivo (Raposo, Fuks, 2002). Isso significa identificar conflitos e retrabalho (Ellis, Gibbs, Rein, 1991). Para tanto, cabe ao coordenador identificar os membros que, por algum motivo, não participam das atividades ou as executam com intensidades diferenciadas, apresentando distintos níveis de contribuição para sua conclusão. Para coordenar é necessário o apoio de ferramentas de comunicação. São essas ferramentas que promovem as interações e, ao mesmo tempo, geram resultados, realçam equívocos, identificam projeto. motivações e alinham as idéias do grupo em direção aos objetivos do O esforço dos coordenadores diante das informações geradas para qualificar e valorar as contribuições e as participações deve ser percebido pelo sistema de regras associado ao módulo de comunicação. Aplicações de groupware baseadas 97

98 na web podem oferecer soluções para apoiar a coordenação em diferentes contextos, permitindo um a definição mais precisa dessas medidas, racionalizando os recursos humanos e controlando as contribuições no tempo certo. Entretanto, compreender a participação dos envolvidos e medir cada um a delas, identificando os níveis de cooperação dos membros de um projeto é uma tarefa complexa, exigindo avaliações subjetivas em contextos, tempos e fases diferentes. O desafio concentrase em convergir vários interesses, às vezes antagônicos, diante da quantidade de ferramentas de apoio às atividades do projeto, agravando-se com o aumento da quantidade de diferentes coordenações, colaboradores e decisões envolvidas. Portanto, o controle e a coordenação das contribuições dos membros são fatores críticos para o sucesso do projeto. Entretanto, ao se considerar a articulação de atividades interdependentes e distribuídas entre diferentes ferramentas para o apoio à gestão de projetos na web, a coordenação se torna mais complexa. Nesse contexto, a coordenação de um grupo envolvida em diferentes atividades simultâneas necessita tam bém, de ferramentas que avaliam a participação e contribuição de cada membro. Os conceitos de participação e de contribuição já foram discutidos em contextos diferentes da gestão de projetos. Borges et al (1999) consideram que, no contexto das aplicações para apoio à preparação de reuniões, um membro do grupo pode participar apenas lendo as mensagens postadas. Enquanto que as suas contribuições serão consideradas a partir do momento em que uma mensagem é inserida. Já para o contexto da gestão de projetos, as contribuições e participações podem ser reveladas através do uso de diferentes ferramentas integradas ao ambiente, tais como: relatórios de três gerações; diagrama de PERT/CPM; diagrama de Gantt; plano de ação; diagrama de causa e efeito. A manipulação dessas ferramentas necessita revelar os níveis de produtividade. Percentuais baixos de participação e contribuição podem significar baixa motivação, desconhecimento do assunto, necessidade de treinamento, baixa produtividade e, portanto, devem ser prontamente identificados pelo coordenador para que os problemas consequentes sejam resolvidos e os prazos possam ser cumpridos. A baixa contribuição em ferramentas de comunicação pode significar que outras análises precisam ser realizadas. Por exemplo, caso essas contribuições gerem 98

99 mensagens de impacto, e provoquem a discussão, elas são necessárias para o andamento do projeto e, portanto, devem ser consideradas relevantes. Pode-se acrescentar o fato de que, ao longo do projeto, diferentes discussões são geradas em diferentes fases e atividades, dificultando mais ainda, o gerenciamento e a identificação de contribuições e participações. Para apoiar a exigência de controle das comunicações, que aborda as questões de planejamento das comunicações, distribuição das informações, relatórios de desempenho e gerenciamento das partes interessadas, propõe-se um groupware com coordenação inteligente que revele os níveis de contribuição e participação dos colaboradores do projeto. A inteligência artificial contribui com um sistema de regras que ajuda a medir e relacionar os indicadores, tais como: níveis de contribuição; nível de adequação e participação dos membros do projeto. Para verificar esse conjunto de relacionamentos será construído um sistema parametrizado de regras de primeira ordem, relacionando conceitos às diferentes ferramentas e fases do projeto, permitindo uma avaliação qualitativa das contribuições dos participantes. Elas devem variar conforme os requisitos do negócio de cada projeto e de sua evolução. A atualização dessa base de conhecim ento é o caminho para a adaptação do sistema a cada projeto, que tem base de conhecimento própria armazenada no mesmo sistema. Este projeto parte da hipótese de que ao aplicar técnicas e ferramentas de Inteligência Artificial (sistema de regras) para resolver os problemas do conflito das decisões em groupware, o esforço das coordenações no desenvolvimento e execução dos projetos pode ser reduzido, aumentando a produtividade e dim inuindo os custos e riscos envolvidos na tomada de decisões. Sistemas e modelos para apoiar a gestão de projetos colaborativos têm sido propostos na literatura de groupware (Bergamaschi et al, 2003) (Chen et al, 2003). O sistema WINK, por exem plo, foi desenvolvido para apoiar o gerenciamento de projetos colaborativos na web. Ele tem como objetivo integrar diferentes ferramentas de gerência e informações necessárias para um projeto distribuído. Tais informações podem ser obtidas através de consultas definidas pelo sistema ou pelo usuário (Bergamaschi et al, 2003). Entretanto, estas consultas não estão relacionadas especificamente às atividades de coordenação, através de um sistem a 99

100 inteligente. Já em Chen et al (2003), um modelo é proposto para apoiar a coordenação de projetos colaborativos, porém os itens relevantes para apoiar a coordenação em projetos distribuídos não são relacionados, tais como as contribuições, as participações e os conflitos desnecessários. A próxima seção aborda a metodologia que está sendo utilizada para implementação da solução, as tecnologias envolvidas e a forma de implementar a avaliação inteligente, quando das participações dos membros no projeto. 2. METODOLOGIA Gerenciar um projeto é controlar e comandar a execução do ciclo de vida de um conjunto de tarefas, tomar decisões, atender aos interessados, obedecer as regras da estrutura organizacional ao qual está submetido, conhecer e adequar essas ações ao ambiente socioeconômico e, fundamentalmente avaliar as ações dos colaboradores envolvidos. Para consolidar a avaliação dos membros propõe-se um sistema baseado na web, permitindo que cada conjunto dessas contribuições possua avaliações diferentes em cada uma das fases do projeto. A tabela 1 resume uma proposta de classificação do conjunto de colaborações por fase do projeto, mapeadas para o modelo 3C (Fuks, Gerosa, Pimentel, 2003) estruturando o sistema de regras que apoiará a coordenação dos membros do projeto. Existem particularidades em cada projeto que podem acrescentar outras contribuições às existentes na tabela. No entanto, são apresentados apenas os mapeamentos para os elementos de coordenação e de comunicação, considerando-se o escopo deste artigo. No contexto do projeto as relações existentes entre esses elementos, bem como aqueles associados à cooperação também foram mapeados, mas não estão representados na tabela 1. Percebe-se que, por exemplo, utilizar o diagrama de causa e efeito na fase de monitoramento e controle possui um peso diferente quando esta ferramenta é utilizada nas fases de planejamento e execução. Esse exem plo se repete para os diversos tipos de ferramentas e as diferentes contribuições e participações dos membros, o cumprimento dos prazos e orçamento, gerando um conjunto de regras que permitem a avaliação da contribuição dos participantes. Para que a solução seja genérica, se faz necessária a parametrização das regras, fatos e conceitos do negócio. Um módulo de suporte será implementado, 100

101 materializando as particularidades de cada projeto e permitindo que os dados da tabela 1 possam ser facilmente modificados. Desta forma o banco de conhecimento que apoia a avaliação das contribuições dos participantes do projeto deve ser mantido, tornando-se independente da estrutura de programação e gerando possibilidades de aprendizado com o desenvolvimento do projeto. A implementação dessas regras deverá ser decidida entre o PROLOG e o DROOLS. Segundo Bratko (1991), Prolog é a linguagem de programação para computação simbólica e não numérica. Ela foi especialmente desenvolvida para resolver problem as que envolvem objetos e relacionamento entre os objetos. Drools é um mecanismo de inferência com enfoque baseado em regras de produção, usado para implementar sistemas especialistas e é classificado como sistema de regras de produção (Drools, 2006). 3. RESULTADOS ESPERADOS No atual estágio do trabalho, os documentos de especificação e de projeto já foram concluídos e as etapas de escolha de tecnologia e im plem entação já se encontra em andamento. É bem verdade que para se avaliar a hipótese, previam ente formulada, torna-se necessário a implementação de uma quantidade significativa de ferramentas de apoio à comunicação e à coordenação, bem como de apoio à gestão de projetos. Entretanto, acredita-se que mesmo no estágio inicial, com as ferramentas previstas no modelo PMBOK e, encarnadas nos módulos de gerência de comunicação e do escopo, será possível realizar experimentos que evidenciem alguns resultados. Assim sendo, realiza-se, inicialmente, um experimento que busque avaliar sobretudo o esforço de coordenação sem a utilização do mecanismo de regras proposto e, em seguida, buscando avaliar se a coordenação foi potencializada com o uso dessa técnica. Dentre as atividades de coordenação cabe focalizar nas atividades apoio à tomada de decisões, bem como na forma pela qual o sistema de regras se manteve atualizado no decorrer dessas atividades. REFERÊNCIAS 101

102 Borges, M. R. S. et al, Key issues in the design of an asynchronous system to support meeting preparation. In Decision Support Systems The International Journal, 27, pp Bratko, Ivan Prolog programming for artificial intelligence. 2 ª Edição: Editora Addison-Wesley, Edinburgh Gate. Bergamaschi, S. et al, WINK: A Web-Based System for Collaborative Project Management in Virtual Enterprises. In Fourth International Conference on Web Information Systems Engineering (WISE'03), pp Cavalieri, Adriane et al, Como se tornar um profissional em gerenciamento de projetos : livro base de preparação para certificação PMP - Project Management Professional. supervisão: Paul Campbell Dinsmore; coordenação: Adriane Monteiro Cavalieri Barbosa. 2ª Edição; Editora Qualitymark, Rio de Janeiro. Chen, F. et al, A Collaborative Project Management Architecture. In Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS 03), Jan. 6-9, Computer Society Press. Drools, URL (acesso em 25/08/2006). Ellis, C., Gibbs, S. J., Rein, G. L., Groupware: Some Issues and Experiences. Communications of the ACM, v. 34, n. 1, pp , Jan. Fuks, H., Gerosa, M. A., Pim entel, M., Projeto de Comunicação em Groupware: Desenvolvimento, Interface e Utilização. XXII Jornada de Atualização em Informática, Anais do XXIII Congresso da Sociedade Brasileira de Computação, v2, cap. 7, pp Raposo, A., Fuks H., Defining Task Interdependencies and Coordination Mechanisms for Collaborative Systems. In Blay- Fornarino, M., Pinna-Dery, A. M., Schmidt, K. & Zaraté, P.; Cooperative Systems Design (vol 74 of Frontiers in Artificial Intelligence and Applications), Amsterdam, pp Rosenau, Milton D., Jr. et al, The PDMA handbook of new product development. 1ª Edição; Editora Wiley, New York. Conferência IADIS Ibero- Americana WWW/Internet

103 APLICAÇÃO DO MÉTODO SCAMPI PARA AVALIAÇÃO DO PROCESSO DE GERENCIAMENTO DE PROJETOS DE SOFTWARE NUMA INSTITUIÇÃO FINANCEIRA Anderson Itaborahy, Ernest o Radis, Fúlvio Longhi, Káthia M de Oliveira, Rejane M. da Costa Figueiredo Universidade Católica de Brasília (UCB) Campus Universitário II SGAN 916 Módulo B Brasília DF Brasil Resumo. Este artigo descreve uma experiência de aplicação do modelo CMMI e do método SCAMPI na avaliação do processo de gerenciamento de projetos de desenvolvimento de aplicativos de uma grande empresa do setor financeiro brasileiro. Essa avaliação utilizou a representação contínua do CMMI, concentrandose apenas nas áreas de processo que compõem a categoria de gerenciamento de projetos. Os resultados da avaliação foram utilizados para traçar uma série de recomendações para evolução desses processos na organização. 1. Introdução O software tem uma importância fundamental para as organizações atuais, independente de seu ram o de atividade. Cada vez mais os negócios dependem de sistemas que são cada vez mais complexos. Segundo observam Chrissis, Konrad e Shrum (2003), muitas organizações que não têm a produção de software com o seu negócio central como as instituições financeiras percebem que o software tornou-se um componente fundamental desse negócio, sendo considerado um fator crítico na vantagem competitiva. Capers Jones (1999) aponta o gerenciamento de projetos como o elo mais fraco no desenvolvimento de software, o que leva a considerar como crítica a implementação de práticas relacionadas a planejamento, estimativas, monitoramento, análise de risco, etc., nas organizações que produzam software. A empresa referenciada nesse artigo é uma grande instituição do se tor financeiro brasileiro com atuação em diversas áreas desse mercado, com abrangência nacional e presença também no exterior. Para suportar seus negócios, a empresa utiliza intensamente soluções de tecnologia da informação (TI). A maior parte dessas 103

104 soluções é desenvolvida e operada por uma área, organizada sob a forma de diretoria. Há algum tempo, buscando otimizar as respostas às demandas por soluções de TI, a organização reconheceu a importância da aplicação de uma abordagem sistemática das práticas de gerenciamento em seus projetos. Para isso criou um Project Management Office (PMO) com a atribuição de conduzir a implementação dessas práticas, definindo os processos e monitorando sua aplicação. A principal estratégia de implementação de processos pelo PMO foi abordar primeiramente aqueles aspectos que se m ostravam mais críticos no relacionamento da área de TI com seus clientes internos. O PMO acredita ter estabelecido as bases do gerenciamento de projetos em sua área de TI, mas passado o estágio inicial de sua atuação, ressente-se de uma abordagem mais sistemática para as práticas de gerenciamento de projetos, principalmente na área de desenvolvimento de software, a mais pressionada pelas demandas dos clientes internos. A partir dessa percepção, o PMO decidiu realizar uma avaliação interna de seu processo de gerenciamento de projetos de software e, com isso, estabelecer um plano consistente para a evolução desse processo. Para condução dessa avaliação foi selecionado o modelo CMMI-SE/SW Capability Maturity Model Integration for Systems Engineering and Software Engineering, versão 1.1 (2001) em sua abordagem contínua, focando as áreas de processo da categoria de gerenciamento de projetos. O método de avaliação escolhido foi o SCAMPI Standard CMMI Appraisal Method for Process Improvement, versão 1.1 (2001). Ao final desse trabalho chegou-se a uma avaliação do estágio atual do gerenciamento de projetos de software na organização e, a partir da análise dos resultados, foram propostas ações de melhoria para o processo que oferecessem as bases para um programa de evolução de longo prazo. Nas próximas seções serão apresentadas breves descrições do modelo CMMI (seção 2) e do método SCAMPI (seção 3), destacando os principais conceitos que foram aplicados nesse trabalho. Na seção 4 será descrita a avaliação conduzida na área de desenvolvimento de software da organização e ao final (seção 5) serão apresentadas as conclusões do trabalho. 104

105 2. Modelo de Processo CMMI O CMMI define um m odelo de referência para avaliação dos processos de uma organização a partir de um conjunto de áreas de processo (Process Areas Uma PA corresponde a um grupo de práticas relacionadas a uma área que, quando executadas de forma coletiva, satisfazem um conjunto de objetivos considerados importantes para produzir melhoria significativa naquela área. PA). A Figura 1 ilustra a estrutura de uma PA. Cada PA tem um conjunto de objetivos específicos que devem ser atingidos para que seja considerada executada. Além disso, um conjunto de objetivos genéricos, aplicáveis 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 m aturidade da organização em cinco níveis progressivos, e outra contínua, que identifica níveis de capacitação para cada PA, apontando seu grau de institucionalização. As PA 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 PA fundam entais, voltadas a estabelecer os objetivos básicos do processo, e PA progressivas, que representam avanços na capacitação da organização. A Tabela 1 mostra as PA fundamentais que compõem a categoria de projetos, indicando seus objetivos específicos (Specific Goals Tabela 1 Áreas de processo fundamentais de gerência de projetos SG). gerenciamento As PA fundamentais de gerenciamento de projetos contemplam as atividades básicas relativas a estabelecer e manter o plano de projeto e os compromissos necessários, monitorar o progresso do trabalho com relação ao plano, tomar as ações corretivas necessárias e gerenciar acordos de fornecimento. A Figura 2 ilustra a interação entre essas PA e delas com as demais categorias. O planejamento do projeto (PP) começa a partir dos requisitos que apontam o que será construído, definindo as várias atividades de engenharia e de gerenciamento que irão compor o projeto. A PA de monitoramento e controle (PMC) obterá dos planos do projeto os níveis apropriados de monitoramento e, quando percebido 105

106 algum desvio, indicará e gerenciará as ações corretivas necessárias. Requisitos do projeto que impliquem em aquisições externas serão tratados pela PA de 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. Área de Processo Objetivos Específicos Objetivos Genéricos Práticas Específicas Práticas Genéricas Propósito geral Objetivos Específicos (SG) Estabelecer Estimativas para o Projeto Desenvolver Plano do Projeto Obter Comprometimento com o Plano Monitorar o Plano de Projeto Gerenciar Ações Corretivas Estabelecer Acordos com Fornecedores Cum prir Acordos com Fornecedores PP PMC SAM Área de Processo (PA) Gerenciamento de Acordos com Fornecedores Monitoramento e Controle de Projetos Planejamento de Projetos Estabelecer e manter planos e definir atividades do projeto Prover entendimento do andamento do projeto e apontar ações corretivas Gerenciar a aquisição de produtos de fornecedores com base num acordo 3. Método de Avaliação SCAMPI A base de uma avaliação SCAMPI está na verificação dos Indicadores de Im plementação de Prática (Practice Implementation Indicators PII), representados por artefatos diretos e indiretos produzidos pela execução do processo, ou por afirmações da organização avaliada, que equivalem a artefatos indiretos. 106

107 Os artefatos diretos representam a finalidade básica da realização da prática, sem eles a prática não pode ser considerada realizada. Os artefatos indiretos apóiam a realização da prática, embora não sejam sua finalidade principal. Sua existência reforça a indicação de realização da prática. As afirmações são representadas por declarações orais ou escritas, colhidas em entrevistas e questionários, ou apresentações realizadas pela organização aos avaliadores, que confirmem a realização de uma prática. A partir da verificação dos PII, os avaliadores caracterizam a implementação de cada prática do CMMI. A Tabela 2 apresenta as possibilidades de caracterização de implementação das práticas e o critério para defini-las. Tabela 2 Caracterização de Implementação de Prática [SCAMPI,2001] Caracterização da Implementação de uma prática Com pletam ente Implementada (FI Fully Implemented) Apresenta artefatos diretos adequados, suportados por artefato indireto ou afirmação, sem falhas importantes. Largamente Implementada (LI Largely Implemented) Apresenta artefato direto adequado, suportado por artefato indireto ou afirmação, mas apresenta falhas importantes. Parcialmente Implementada (PI Partially Implemented) Artefatos diretos ausentes ou inadequados, mas existem artefatos indiretos e/ou afirmações que indicam a realização de alguns aspectos da prática. Não Implementada (NI Not Implemented) Caso não ocorra nenhuma das situações acima. 4. Avaliação das áreas de processo da categoria Gerenciamento de Projetos A avaliação relatada neste artigo partiu dos objetivos de negócio apontados pelos patrocinadores, conforme descrito na introdução deste artigo, e, seguindo o método SCAMPI, produziu um relatório final cujo índice é reproduzido na Figura 3. Figura 3 Índice do relatório de avaliação Esta seção apresenta uma descrição de como foi conduzida a avaliação e que resultados foram obtidos. Serão descritos os parâmetros de planejam ento e preparação, a forma e as estratégias de condução e os resultados apurados. A partir dos resultados apurados foram identificados os gaps do processo im plem entado na 107

108 organização com relação ao modelo e elaborado um conjunto de diretrizes de ação para a organização Planejamento e Preparação O objetivo da avaliação foi verificar os processos adotados no gerenciamento projetos de desenvolvimento de software na diretoria de tecnologia da organização, com o objetivo de fundamentar um plano de m elhoria desses processos na empresa. A avaliação adotou a representação contínua, uma vez que não pretendia avaliar a maturidade da organização como um todo, m as sim o nível de capacitação das áreas de processo da categoria gerenciamento de projetos. Foram consideradas inicialmente para avaliação as áreas básicas de processo da categoria, pois o interesse da organização era apurar se o processo estava sendo devidam ente executado. Depois de garantido o nível 1 para todas as PA avaliadas, a organização estabelecerá ações para se colocar integralmente no nível de maturidade 2, seguindo a visão em estágios do CMMI. Esse trabalho, entretanto, está fora do escopo do presente artigo. Dentre as práticas básicas de gerenciamento de projetos Planejamento de Projetos (Project Planning PP), Monitoramento e Controle de Projetos (Project Monitoring and Control PMC) e Gerenciamento de Acordos com Fornecedores (Supplier Agreement Management SAM) a terceira foi excluída da avaliação, pois, até o momento da realização deste trabalho, não era usual na organização incorporar produtos ou com ponentes adquiridos de terceiros nos softwares que desenvolve para seus clientes internos. A avaliação foi conduzida sobre três instâncias dos processos da organização, representadas por três projetos de desenvolvimento de software concluídos nos últim os 90 dias. A equipe foi formada por três avaliadores, sendo que um deles representava o PMO da organização. de 4.2. Condução da Avaliação A avaliação foi conduzida no modo de verificação, conforme definido no SCAMPI (2001), com a investigação de evidências, baseando-se em artefatos apresentados pela organização a partir de uma definição prévia dos avaliadores. 108

109 Para cada uma das práticas associadas aos objetivos específicos das PA de gerenciamento de projetos, os avaliadores apontaram um conjunto de artefatos diretos e indiretos, a partir de Ahern (2005) e Garcia (2004), descrevendo características que deveriam ser buscadas em cada um deles. Também foram relacionadas possíveis questões a serem apresentadas aos gerentes de projeto no caso de se considerar necessária um a entrevista complementar. Esses indicadores foram consolidados num conjunto de fichas que foram utilizadas na avaliação das evidências. A organização disponibilizou aos avaliadores a documentação completa dos projetos avaliados, na forma de documentos impressos e de dados armazenados no repositório de projetos corporativo. O representante do PMO na equipe de avaliação apontou na documentação a implementação dos artefatos diretos e indiretos solicitados nas fichas de avaliação. Os casos em que a análise dos artefatos não permitiu uma conclusão segura sobre o grau implementação da prática foram identificados para que posteriormente fossem objeto de entrevista com os gerentes de projeto. O grau de implementação das práticas avaliadas foi apurado com a aplicação dos critérios definidos na Tabela 2. Como complemento, foram registradas nas fichas de avaliação observações relativas a particularidades da implementação, pontos fortes ou deficiências percebidas naquela implementação. A Figura 3 abaixo exemplifica uma ficha de avaliação. Figura 3 Ficha de avaliação O sinal de interrogação à direita do registro do grau de implementação (PI, no caso) indica que essa prática foi posteriormente objeto de entrevista com o gerente do projeto, buscando afirm ações que validem as evidências encontradas Apuração dos Resultados Os resultados da avaliação da implem entação das práticas específicas em cada um dos projetos foram consolidados de forma a caracterizar o processo na organização. Para cada prática foi aplicado o critério descrito na Tabela 3, obtendose uma avaliação do grau de implementação da prática na organização como um todo. 109

110 Projeto P 1113 Projeto 1113 PA PMC Monitoramento e Controle de Projetos Objetivo SG 1 Monitorar o Plano do Projeto Prática SP Monitorar os Riscos do Projeto Avaliação da Prática PI? Artefato Direto Registros de monitoramento de riscos x Observar: Avaliações periódicas dos riscos identificados no plano Comunicações de riscos aos stakeholders relevantes Artefato Indireto Procedimentos para tratamento de riscos x Observar: Descrições de ações para monitoramento de riscos Alterações no quadro de riscos do projeto x Observar: Atualização de probabilidade, impacto, etc. Afirmações Entrevista com Líder do Projeto x Questionar: Qual o uso dado aos riscos identificados no plano? Como são avaliados os riscos nos relatórios de progresso? Os stakeholders são mantidos informados sobre os riscos? Com etários Artefato Monitora os riscos percebidos com relação àqueles identificados no plano do projeto Apropriado Obs1: No relatório de progresso há identificação de riscos e problemas, mas não há vinculação explícita aos riscos definidos no plano. Não Existe Com Falhas Tabela 3 Critérios de consolidação da avaliação instâncias de práticas Avaliações individuais Consolidação na organização Mesmo nível nos três projetos Este é o nível na organização Todas as práticas FI ou LI Prática Largam ente Implementada (LI) Ao menos um PI, mas nenhum NI LI ou PI, conforme as falhas observadas Ao menos um NI 110

111 PI ou NI, conform e as falhas observadas A satisfação dos objetivos específicos, por sua vez, foi apurada tendo por base os resultados consolidados de implementação das práticas na organização. Para que o objetivo seja considerado satisfeito, todas as práticas associadas devem ser consideradas largamente (LI) ou totalmente implementadas (FI) e, além disso, nenhuma falha significativa deve ser notada. Esta avaliação teve como objetivo identificar a realização das PA de gerenciamento de projetos na organização, portanto buscou-se verificar o nível de capacitação 1 Processo Executado para as PA Planejamento de Projetos (PP) e Monitoramento e Controle de Projetos (PMC). Para que seja considerado atingido o nível de capacitação 1, todos os objetivos específicos da PA devem ter sido considerados alcançados. As Tabelas 4 e 5 mostram os resultados consolidados da avaliação para cada uma das PA, indicando o nível de implementação de cada prática, a satisfação ou não dos objetivos e o nível de capacitação da PA. Tabela 4 Resultados consolidados da PA Planejamento de Projetos Na avaliação da PA Planejamento de Projetos, com relação à realização de estimativas e apuração de custos, foi verificado que não faz parte do modelo de negócios da organização calcular e repassar custos de desenvolvimento aos seus clientes. Os custos dos projetos são computados em termos de esforço, medidos em horas-homem. Esses custos de mão-de-obra, assim como ambiente, equipamentos, etc. são tratados como despesas administrativas da área de TI. Eventuais aquisições que representem custos do projeto são tratadas caso a caso. A organização utiliza-se de um repositório corporativo de dados e documentos de projetos que implementa perfis de usuário e controle de acesso no nível do projeto e de seus dados básicos, mas não no nível de documentos individuais, que são tratados com o anexos ao projeto na maioria dos casos. Tabela 5 Resultados consolidados da PA Monitoramento e Controle de Projetos Os projetos avaliados utilizam um relatório de progresso padrão que implementa práticas de monitoramento e controle. Neste relatório são registradas as ações realizadas, problemas observados e os próximos passos na condução do projeto. 111

112 Entretanto foram percebidas deficiências no gerenciamento das respostas a esses problem as, assim como no monitoramento e atualização do quadro de riscos definido no planejamento Identificação de gaps e diretrizes de ação Um gap representa a diferença entre o processo da organização e aquele prescrito pelo modelo de referência e ocorre sempre que a prática for avaliada como menos que totalmente im plementada [SCAMPI, 2001]. As áreas de processo no CMMI não são independentes. As PA numa categoria afetam PA em outras categorias, ou mesmo objetivos genéricos. Além disso, as relações internas na própria categoria, conforme descrito na Figura 2, mostram que os gaps na implementação de práticas de uma PA levarão a falhas em outras PA. A partir dos gaps observados na avaliação e da análise das relações entre as PA comentadas acima, foi produzido um conjunto de recom endações para a organização avaliada com o objetivo de elevar seus processos para o nível de capacitação 1, complementando o processo atual e preparando as bases para um futuro programa de melhoria contínua. A Tabela 6 apresenta um resumo da avaliação, quantificando, para cada PA e objetivo específico, as práticas por nível de implementação e a quantidade de gaps identificados. Tabela 6 Resumo dos resultados da avaliação Práticas PA SG FI LI PI NI Gaps 1 Estabelecer estimativas para o projeto Desenvolver Plano de Projeto PP 3 Obter comprometimento com o plano Monitorar o Plano de Projeto PMC 2 Gerenciar Ações Corretivas Total Incompleta Monitorar o Plano de Projeto Não satisfeito SP Monitorar parâmetros de planejamento do projeto LI SP

113 Monitorar compromissos LI SP Monitorar os Riscos do Projeto PI SP Monitorar a Gerencia de Dados NI SP Monitorar o envolvimento dos Stakeholders LI SP Conduzir as avaliações de progresso LI SP Conduzir as avaliações de Milestones LI Gerenciar Ações Corretivas Não satisfeito SP Analisar as ocorrências LI SP Tomar ações corretivas PI SP Gerenciar ações corretivas PI PA Monitoramento e Controle de Projetos SG 1 SG 2 Das 24 práticas avaliadas, 19 apresentaram gaps de implem entação, entretanto 11 delas estão largamente implementadas, exigindo um esforço menor de melhoria, e apenas três não estão implementadas. A Tabela 7 detalha parte das recomendações produzidas, na forma de um conjunto de diretrizes de ação associados aos principais gaps identificados. Tabela 7 Diretrizes de ação (exemplos) PA Objetivo Específico Gaps Ação SG2-Desenvolver Plano de Projeto - Não há definição de forma e critérios de acesso a dados e documentos do projeto - Não são explicitadas habilidades necessárias ao projeto - Não há plano para prover habilidades - Incluir no plano a definição dos documentos que serão gerados e dos dados que conterão - Estabelecer política de acesso aos documentos do projeto e controlá-lo - Implementar procedimento para definição de habilidades e seleção membros de equipe PP SG3-Obter com prometimento com plano - Não são identificados processos ou projetos que possam afetar o planejamento - Não é analisado o impacto do desenvolvimento de outros projetos paralelos - Identificar explicitamente projetos ou processos relacionados - Sincronizar plano de projeto às informações acima 113

114 PMC SG2- Gerenciamento de Ações Corretivas - Ações corretivas não alteram o plano original - Não há gerenciamento das ações corretivas - Garantir que todos os projetos produzam relatório de progresso das ações corretivas - Garantir que o quadro de riscos seja atualizado ao longo do projeto - Garantir que plano de projeto seja ajustado incluindo ações de resposta a problem as identificados Análise dos Resultados da Avaliação As áreas de processo fundamentais de gerenciamento de projetos ainda não estão completamente consolidadas na organização avaliada, na forma prescrita pelo CMMI. Os objetivos específicos definidos no modelo não são alcançados em sua totalidade, apresentando nível de capacitação 0 Processo Incompleto tanto na PA Planejamento de Projetos (PP) como em Monitoramento e Controle de Projetos (PMC). Como conseqüência dessa situação, e da importante inter-relação dessas com outras áreas de processo, a organização provavelmente experimentará problem as na condução de seus projetos, como instabilidade de prazos e custos, dificuldade de agir proativamente na ocorrência de problemas, falta de recursos adequados e devidamente treinados, variações na qualidade dos produtos gerados, dificuldades de comunicação, dificuldades de planejamento a longo prazo e abandono de processos e planejamento na ocorrência de crises. As respostas dos gerentes aos questionários aplicados confirmaram os resultados apurados com a observação dos artefatos diretos e indiretos. Uma análise desse quadro indicou que a maioria das práticas não atendidas é resultado de limitações no processo de gerenciamento de projetos definido e nos normativos da são executadas pelos gerentes de projeto. Apesar disso, a avaliação mostrou que muitas das práticas específicas já estão razoavelmente consolidadas na organização, indicando que, com algum esforço, o nível de capacitação 1 Processo Executado pode ser alcançado num curto espaço de tempo, a partir de ações gerenciais como a definição de diretrizes mais 114

115 completas para os gerentes de projeto e a adoção de ferramentas de apoio que permitam um gerenciamento mais efetivo de cada projeto e, também, do portfólio da organização. 5. Conclusões A organização avaliada neste trabalho, através de seu PMO, acreditava ter lançado as bases do gerenciamento de projetos em sua área de desenvolvimento de software, mas ressentia-se de uma abordagem mais sistem ática para essa questão. Com o objetivo de conhecer seu real nível de capacitação em gerenciamento de projetos, o PMO da organização patrocinou uma avaliação baseada no SCAMPI das PA Planejamento de Projetos (PP) e Monitoramento e Controle de Projetos (PMC). A avaliação mostrou que, embora as PA selecionadas tenham sido avaliadas como incompletas (nível de capacitação 0), algumas práticas definidas pelo modelo CMMI já estão totalmente implementadas, e várias estão largamente implementadas na organização, o que indica que, com um esforço relativamente baixo, o nível de capacitação 1 poderá ser alcançado. O trabalho conduzido na avaliação permitiu identificar os gaps existentes no processo da organização e, a partir desses gaps e de uma visão das relações entre as PA, foram apontadas diretrizes que irão guiar a organização na melhoria de seus processos conforme sugerido acima. A limitação da avaliação à categoria Gerenciamento de Projetos, entretanto, não permitiu explorar os impactos nos processos das demais categorias, que certamente existem. Trabalhos futuros poderiam explorar essas inter-relações mais profundam ente. A utilização do SCAMPI como método de avaliação mostrou ser um a abordagem eficiente e efetiva, proporcionando uma visão clara da realização das práticas na organização através dos artefatos produzidos, com consumo reduzido de recursos de mão-de-obra, tanto dos avaliadores quanto da organização avaliada. Pode-se concluir, também, que esse mesmo método poderia ser utilizado com relativa facilidade em outras organizações. A partir da experiência relatada neste artigo, o PMO está estabelecendo uma série de ações que permitam cobrir os gaps identificados e consolidar os processos de 115

116 gerenciamento de projetos na área de desenvolvimento de software. Essa consolidação irá compor as bases de um programa de melhoria de processos mais abrangente, a ser conduzido pela organização com o objetivo de alcançar o nível de maturidade 2 da representação em estágios do CMMI. A adoção do CMMI como modelo de referência para melhoria de processos na organização permitirá compor visões específicas de uma PA com um quadro geral da organização, possibilitando a construção de uma abordagem consistente para sua evolução contínua. O programa de melhoria construído dessa forma oferecerá importantes oportunidades para estudos futuros. REFERÊNCIAS Ahern, D.M., Armstrong, J., Clouse, A., Fergusson, J., Hayes, W. CMMI SCAMPI Distilled Appraisals for Process Improvement, Addison Wesley, Ahern, D.M., Clouse, A. e Turner, R., CMMI Distilled: A Practical Introduction to Integrated Process Improvement, Addison Wesley, Chrissis, M.B., Konrad, M. e Shrum, S., CMMI: Guidelines for Process Integration Improvement, Addison Wesley, and Product CMMI Product Team, Capability Maturity Model Integration, version 1.1 CMMI for Systems and Software Engineering (CMMI SE/SW v1.1) Continuous Representation, Software Engineering Institute, Carnegie Melon University, Garcia, S., Cepeda, S., Miluk, G., Staley, M.J. CMMI in Small Settings Toolkit Repository from AMRDEC SED Pilot Sites; Draft 14, Carnegie Mellon University, Jones, C. The Economics of Software Process Improvements, in: Elements of Process Assessment and Improvement, Editado por Khaled El Eman e Nazim H. Madhavji, IEEE Computer Society, Phillips, M, CMMI v 1.1 and Appraisal Tutorial, apresenta ão na European Software Engineering Process Group Conference, abril/2002, revisado em fevereiro/2004 ttp://www.sei.cmu.edu/cmmi/presentations/eurosepg-tutorial, Carnegie Mellon University, SCAMPI Members of the Assessment Method Integrated Team, Standard CMMI Appraisal Method for Process Improvement (SCAMPI), version 1.1: Method Definition Document, Software Engineering Institute, Carnegie Mellon University,

117 APLICAÇÃO DO MÉTODO SCAMPI PARA AVALIAÇÃO DO PROCESSO DE GERENCIAMENTO DE PROJETOS DE SOFTWARE NUMA INSTITUIÇÃO FINANCEIRA Universidade Católica de Brasília Fulvio Longhi Rejane Figueiredo Ernesto H. Radis Steinmetz Káthia Marçal de Oliveira Anderson Itaborahy Roteiro Contextualização Modelo CMMI e método SCAMPI A avaliação Planejamento Condução Resultados Conclusões Contextualização Grande organiza ão do setor financeiro brasileiro Solu es de software desenvolvidas in house Cria ão de Project Management Office (PMO) Definir metodologia de Gerenciamento de Projetos Implementar e monitorar processo Motiva ão da avalia ão Modelo CMMI e m todo SCAMPI Busca abordagem sistem tica para evolu ão Avalia ão para definir est gio atual Fundamento para plano de ev olução Contextualização Representa es Por est gios Maturidade da organiza ão como um todo Contínua Níveis de capacita ão para cada PA 117

118 CMMI Representa ão contínua Quatro categorias de rea de processo Gerenciamento de Processos Gerenciamento de projetos Engenharia Suporte Gerenciamento de Projetos PAs fundamentais Base do Gerenciamento de Projetos PAs progressivas Níveis mais avan ados de maturidade Evidências Artefatos diretos - Indicadores de Implementação de Prática (PII) Finalidade b sica da realiza ão da pr tica Artefatos indiretos Apóiam a realiza ão da pr tica Afirma es Entrevistas, question rios, apresenta es SCAMPI Caracterização da Implementação de uma prática Completamente Implementada (FI) Apresenta a rtefatos diretos adequados Suportados por artefato indireto ou afirma ão Sem falhas importantes. Largamente Implementada (LI) Apresenta artefato direto adequado, Suportado por artefato indireto ou afirm a ão, Apresenta falhas importantes. Parcialmente Implementada (PI) 118

119 Artefatos diretos ausentes ou inadequados Artefatos indiretos e/ou afirm a es que indicam a realiza ão de alguns aspectos da prática. Não Implementada (NI) Caso não ocorra nenhuma das situa es acim a. Objetivo: Verificar pr ocessos de gerenciamento de projetos de software Fundamentar um plano de melhoria desses processos Perfil -alvo tutop rominas.com.br Representa ão contínua Modo: verifica ão Planejamento da Avaliação Escopo PP - Planejamento de Projetos PMC - Monitoramento e Controle de Projetos Gerenciamento Fornecedores (SAM) Excluída da avalia ão a pro de Acordos com de software não incluem aquisições Planejamento da Avaliação Equipe 3 avaliadores 1 deles membro do PMO Projetos 3 projetos de desenvolvimento de software M dio porte J concluídos 7.000/8.000 horas Planejamento da Avaliação Elaboração de Ficha de Avaliação Relação de artefatos diretos e indiretos Organização disponibilizou base de documentos dos projetos 119

120 Representante do PMO na equipe apontou a implementação dos artefatos Entrevista com gerentes de projeto complementou informações Condução da Avaliação Avaliações individuais Consolidação na organização Mesmo nível nos três Este é o nível na organização Todas as práticas FI ou LI projetos Prática Largam ente Implementada (LI) Ao menos um PI, mas nenhum NI LI ou PI, conforme as falhas observadas Ao menos um NI PI ou NI, conform e as falhas observadas Objetivo Específico Objetivo Alcançado? Resultado da Avaliação Identificar riscos do projeto Planejar o gerenciamento dos dados Projeto 0779 Projeto 1113 Um plano de projeto é desenvolvido e mantido, servindo como base ao gerenciamento do projeto. Um plano é um documento formal, devidamente aprovado e atualizado ao longo do projeto. Planejar recursos do projeto Planejar habilidades e conhecimentos necessários Planejar envolvimento dos stakeholders Estabelecer o plano de projeto Prática Estabelecer orçamento e cronograma Condução da Avaliação PA Planejam ento de Incompleta Satisfeito Projetos 120

121 SP Estimar escopo do projeto FI SP Estabelecer estimativas para tarefas e produtos de trabalho LI SP Definir o ciclo de vida do projeto FI SP Determinar as estimativas de esforço e custo LI Desenvolver Plano do Projeto Não satisfeito SP Estabelecer orçamento e cronograma FI SP Identificar riscos do projeto FI SP Planejar o gerenciamento dos dados PI SP Planejar recursos do projeto PI SP Planejar habilidades e conhecimentos necessários NI SP Planejar envolvimento dos stakeholders FI SP Estabelecer o plano de projeto LI Não satisfeito SP Avaliar os planos que afetam o projeto NI SP Ajustar as atividades do projeto com os níveis de recursos LI SP Obter comprometimento com o Plano de Projeto LI SG 2 Planejamento de Projetos 121

122 Estabelecer Estimativas para o Projeto Obter Comprometimento com o Plano PA SG 1 SG 3 Apuração dos Resultados Gap Diferen a entre o processo avaliado e o modelo Ocorre sempre que o Totais 19 resultado for menor que FI Gerenciar ações corretivas Monitorar o plano de projeto PMC Obter com prometimento com plano 2 P 12LI Desenvolver plano de projeto 2-1.Estabelecer estimativas para o projeto PP NI FI Gap Práticas SG PA Análise de gaps valem a urtefatos indiretos. Não são explicitadas habilidades necessárias ao projeto Não há plano para prover habilidades Incluir no plano modelo a definição dos documentos que serão gerados Estabelecer política de acesso aos documentos e controlá-lo SP Gerenciar dados [PI] Não há definição de forma e critério de acesso a dados Ação Gap SG 2 Desenvolver Plano de Projeto Objetivo Planejamento de PA Recomendações Projetos Identificar explicitamente processos e Sincronizar planos de projeto com outros projetos relacionados projetos e processos contínuos 122

123 SP Avaliar planos [NI] Não são identificados processos ou projetos que possam afetar o planejamento Im pacto de projetos Ação Gap paralelos não é avaliado SG 3 Obter comprometimento com o plano Objetivo Planejamento de PA Recomendações Projetos Garantir que todos os projetos incluam ações corretivas em seus relatórios de progresso Garantir que o quadro de riscos seja atualizado ao longo do projeto Garantir que plano de projeto seja ajustado, incluindo ações de resposta aos riscos identificados SP Gerenciar ações [NI] Ações corretivas não alteram o plano original Não acompanhamento das ações corretivas até sua conclusão Ação Gap SG 2 Gerenciamento de ações corretivas Objetivo Monitoramento e Controle de PA Recomendações Projetos PA fundamentais Gerenciamento de Projetos Não estão estabelecidas Objetivos específicos não são alcan ados Nível de capacita ão 0 Processo Incompleto. Análise dos Resultados Muitas das práticas já estão razoavelmente consolidadas Para alcançar o nível 1 - Executado Ações gerenciais Definição de diretrizes 123

124 Ferramenta de apoio Esforço razoavelmente baixo Análise dos Resultados Organização buscava bases para melhoria Avaliação SCAMPI/CMMI apontou nível de capacitação e gaps Propostas diretrizes de ação para melhoria Conclusões PMO vai conduzir plano de ação para cobrir gaps identificados Organização estabelecerá programa de melhoria para atingir CMMI 2 Oportunidade de trabalhos futuros Acom panhar e medir plano de ação Estudar programa de melhoria contínua Conclusões Limitações: Avaliação apenas das práticas de GP Não mostrou impactos nas demais categorias Aplicação do método Eficiente Consumo reduzido de recursos e tempo Efetiva Visão clara da realização das práticas Pode ser replicado em outros casos 124

125 IMPLANTANDO UM PROGRAMA DE MELHORIA DE PROCESSO: uma experiência prática Evandro Polese Alves Ricardo de Almeida Falbo Departamento de Informática - UFES Resumo Este trabalho discute uma experiência inicial na implantação de um programa de melhoria de processo, tendo por base o modelo IDEAL. O resultado principal obtido até então foi um processo padrão para o desenvolvimento orientado a objetos. Palavras-chave : Definição de Processo, Implantação de Programa de Qualidade. 1. Introdução O aumento da demanda por sistemas de software, associado à importância do papel por eles desempenhado na sociedade atual, tem levado a um a preocupação constante com a produtividade no desenvolvimento e a qualidade dos produtos gerados. Prazos extrapolados, baixa produtividade, custos altos e qualidade deficiente são situações constantes na área de desenvolvimento de software. O aumento da qualidade de software depende muito menos do uso de novas tecnologias do que do emprego efetivo de práticas gerenciais adequadas. Treinar desenvolvedores e dar-lhes tempo para absorver o que aprenderam é fundamental. Im pedir os usuários de colocar prazos absurdos para seus pedidos é fundamental. Alocar recursos (tempo, dinheiro e pessoas) para trabalhar na melhoria do processo é também fundamental. Com eça a haver, então, uma necessidade de compreensão dos problemas envolvidos no desenvolvimento de software, que não são somente tecnológicos, mas, principalmente, gerenciais e organizacionais, para que se possa fazer um planejamento visando a melhoria do processo e, conseqüentemente, melhoria da qualidade dos produtos gerados. Este trabalho relata uma experiência na implantação de um estágio inicial de um programa de melhoria do processo de software em uma empresa de porte médio, a VixTeam Consultoria & Sistemas, que levou à elaboração de um Processo Padrão 125

126 para Desenvolvimento Orientado a Objetos. Como base para esta ação, foi utilizado o modelo IDEAL R [1]. O trabalho está estruturado da seguinte forma: na seção 2, é apresentado o Modelo IDEAL R. Na seção 3, são discutidas as fases do processo IDEAL R que foram realizadas neste trabalho, a saber: Inicial, Diagnóstico e Planejamento. Finalmente, a seção 4 apresenta as conclusões deste trabalho e discute quais os próximos passos a serem realizados. 2. O Modelo IDEAL R O modelo IDEAL é um modelo de programa de Melhoria de Processo de Software (Software Process Improvement - SPI), desenvolvido pelo Software Engineering Institute (SEI), que pode ser usado como um guia no desenvolvimento de um plano integrado de longo prazo para iniciar e gerenciar um programa SPI [1]. A Tabela 1 apresenta as cinco fases de uma iniciativa de SPI, que podem ocorrer de forma iterativa, bem como as atividades relacionadas com cada uma delas. Fase Atividades Relacionadas Inicial Aprender sobre SPI; Definir os Objetivos Gerais; Prever os Recursos Iniciais. Diagnóstico Avaliar o nível de maturidade do processo; Levantar as práticas e m étricas; Descrever o processo; Esboçar um plano de ação. Planejamento Estabelecer os objetivos; Estabelecer as prioridades; Montar o plano de ação. Ação Pesquisar e desenvolver soluções para os problemas do processo; Divulgar melhorias no processo para toda a organização. 126

127 Replanejamento Preparar o novo ciclo; Refinar o processo de SPI. Tabela 1 Estrutura do Modelo IDEAL. Além das cinco fases apresentadas, o modelo descreve, ainda, uma atividade para prover supervisão dos projetos de melhoria e resolver questões relacionadas. 3. O Programa SPI na VixTeam A VixTeam Consultoria & Sistemas é uma organização de desenvolvimento de software que existe há três anos e atua principalmente no desenvolvimento de sistemas de informação para o mercado corporativo do Espírito Santo, sob as plataformas cliente-servidor e Web, sendo que está iniciando trabalhos na área de produto de prateleira. A VixTeam possui um quadro de aproximadamente trinta colaboradores e seis clientes ativos. Tendo em vista sua área de atuação, a qualidade é uma das constantes preocupações da VixTeam. Associado a esta preocupação, há também um incentivo oferecido pela Prefeitura de Vitória, na forma de redução da alíquota de ISSQN (Lei 5.145/00), para as organizações que comprovarem a obtenção de Certificados de Sistemas de Garantias de Qualidade da família NBR ISO 9000, especificamente o NBR ISO 9001 ou NBR 9002 ou ISO 9126 (NBR 13596) [2], até 31 de dezembro de Sendo assim, a VixTeam decidiu investir na melhoria de seu processo de software e, para tal, decidiu fazer uso do Modelo IDEAL. No momento atual, o programa SPI encontra-se na fase de ação do referido modelo, já tendo sido realizadas, portanto, as três primeiras fases, que conduziram à definição de um Processo Padrão da organização. A seguir, apresentamos os passos realizados e seus principais produtos. 3.1 A Fase Inicial Nesta fase, a infraestrutura preliminar de m elhoria é estabelecida, os papéis e responsabilidades são atribuídos e os recursos iniciais alocados. Um plano é criado para guiar a organização até a fase de Planejamento e os objetivos gerais do programa SPI estabelecidos. 127

128 No caso da VixTeam, foi necessário realizar um estudo sobre qualidade de processo de software, procurando conhecer os conceitos relacionados à melhoria do processo de desenvolvimento e as principais normas e modelos de qualidade existentes. Com o objetivo geral do programa, foi estabelecida a adequação da organização à norma NBR-ISO [3]. Esta escolha deveu-se ao fato desta norma ser menos conclusiva e detalhista em seus itens, propondo apenas requisitos mínimos para um processo de qualidade. Desta form a, o escopo do trabalho foi reduzido, o que é mais adequado a um primeiro esforço de melhoria de processo em uma organização do porte da VixTeam, em função, principalmente de sua disponibilidade de recurso. Contudo, percebeu-se que a virtude da ISO , a simplicidade, é também sua fraqueza. Assim, para apoiar o programa, foi montado um quadro comparativo dos itens da norma com outros modelos, para permitir a utilização destes como referência complementar, principalmente nos pontos em que a ISO apresenta descrições muito superficiais. Sobretudo o CMM [4] e a norma ISO [5] foram bastante úteis neste trabalho. 3.2 A Fase de Diagnóstico Esta fase é a base para a realização das etapas subseqüentes. Atividades de avaliação são realizadas para estabelecer a linha base ( baseline) das práticas correntes da organização. Para estabelecer o estado corrente da organização, primeiramente, foram realizados um levantamento detalhado dos itens da norma e uma comparação destes itens com as atividades realizadas pela organização. Após, foram feitas entrevistas com os principais responsáveis pelas atividades listadas, levantando a prática atual. Para cada item da norma foi descrito um diagnóstico da empresa no atendimento ao item. Três categorias de itens foram identificadas: itens atendidos (A), itens parcialmente atendidos (PA) itens que a organização pratica, mas sem uma abordagem sistemática definida, variando substancialmente de projeto para projeto atendidos (NA). A tabela 2 mostra parte deste diagnóstico. Para os itens da norma não atendidos (NA) ou parcialmente atendidos (PA), foram propostas soluções. Item da Norma Descrição Situação 5.2 e itens não 128

129 Análise Crítica do Contrato NA 5.3 Especificação dos Requisitos do Comprador PA / Planejamento do Desenvolvimento PA Controle da Execução NA / Entradas e Saídas das Fases de Desenvolvimento NA Verificação de Cada Fase NA 5.5 Planejamento da Qualidade NA Projeto e Implementação - Generalidades A Projeto NA Im plementação PA Análise Crítica PA Planejamento de Testes NA / / 5.8 Testes, Validação e Aceitação PA / Entrega e Instalação A 6.1 Gerência de Configuração NA 6.3 / 6.4 Registro de Qualidade, Medição NA 6.6 Ferramentas e Técnicas A 129

130 6.8 Produto de Software Incluído A 6.9 Treinamento PA Tabela 2 Diagnóstico 3.3 A Fase de Planejamento Na fase de planejamento (ou estabelecimento), os aspectos que a organização decidiu considerar são priorizados e estratégias são estabelecidas [1]. No caso da VixTeam, decidiu-se definir um processo padrão para o desenvolvimento orientado a objetos (tecnologia utilizada na grande maioria dos base para os trabalhos da fase de ação. projetos ), a ser utilizado como A proposta apresentada tem como objetivo ser um modelo flexível, que permita a adaptação, de tal maneira que o processo padrão possa ser instanciado para projetos de diferentes tipos e tamanhos. O modelo é baseado na idéia de papéis, permitindo que as equipes sejam montadas para cada projeto e as responsabilidades troquem de acordo com os papéis. Em função do tamanho e do tipo dos projetos, mudarão os papéis necessários e a alocação das pessoas para cada papel, havendo uma tendência que, em projetos maiores, alguns papéis sejam realizados por mais de uma pessoa e, em projetos menores, que uma mesma pessoa realize mais de um papel. A Tabela 3 apresenta os papéis identificados, bem como suas responsabilidades. Além dos papéis, foram descritas, também, as atividades que compõem o processo padrão. Estas atividades, além de possuírem uma descrição do seu objetivo, relacionam os papéis por elas responsáveis, que artefatos precisam estar disponíveis para que possam ser realizadas e que artefatos devem ser gerados. Elas foram, ainda, agrupadas em três categorias: atividades de ciclo de vida, atividades de controle da qualidade e atividades de gerência, apresentadas, respectivamente, nas tabelas 4, 5 e 6. Papéis Responsabilidades Gerente de Produção 130

131 Alocação de recursos; Acompanhamento dos andamentos dos projetos ; Tomada de decisões estratégicas para correção de desvios. Gerente de Projeto Definir escopo do projeto; Planejamento do projeto; Monitoramento do andamento do projeto; Definição de prioridades; Reportar status de progresso do projeto; Identificar riscos e planejar sua mitigação; Obter aprovações do projeto; Tratar problemas detectados após a aceitação do software. Analista de Negócio Definir e especificar requisitos funcionais e não funcionais; Prototipar interface com usuário; Definir modelos de classes e diagramas de seqüência de negócio; Definir critérios de aceitação do software; Planejar e realizar testes de validação; Planejar e realizar testes de aceitação junto ao cliente. Projetista de Solução Da Aplicação Definir arquitetura do software; Sugerir componentes para o reuso; Projetar soluções arquiteturais para o software; Projetar classes reusáveis para o software. Projetista de Soluções Gerenciar base de conhecimento da em presa; Desenvolver projetos de tecnologia; Gerenciar os componentes reusáveis da empresa; Gerenciar padrões operacionais da empresa. Projetista de Aplicações Modelar classes da Interface com o Usuário; Modelar classes do Domínio; 131

132 Modelar os dados da aplicação; Elaborar documento de especificação de projeto contendo as descrições de operações. Desenvolvedor Construir código fonte; Realizar testes unitários; Corrigir defeitos apontados; Integrar código ao sistema; Verificar o desem penho do código gerado; Gerar programas executáveis. Engenheiro de Testes Montar plano de testes; Definir os casos de testes; Realizar os testes; Avaliar os resultados e elaborar relatório. Engenheiro de Qualidade Avaliar artefatos do projeto; Avaliar processo de desenvolvimento do projeto; Solicitar correções nos artefatos ou nos processos avaliados; Solicitar ajustes de não conformidades. Engenheiro de Processo Revisar processo padrão da empresa; Elaborar plano de qualidade da empresa; Assegurar o atendimento aos requisitos da ISO Administrador de Ambiente Administrar o ambiente operacional da produção de software da empresa; Gerência Sênior Analisar criticamente os contratos a serem assinados; Definir planejamento estratégico da empresa; Definir orçamento da em presa; Planejar treinam entos dos colaboradores. Tabela 3 Papéis do Processo Padrão VixTeam. 132

133 Atividade Artefato Insumo Artefato Produto Responsável Escopo do Software Gerente do projeto Definir Visão Projeto Responsável do Cliente Elaborar Plano de Projeto Escopo do Software Plano de Projeto Gerente de Projeto Proposta de Contrato Contrato Assinado Gerência Sênior Escopo do Software Aprovar Contrato Plano de Projeto Escopo do Software Modelo Caso de Uso Analista de Negócio Descrição Caso de Uso Descrição de Atores Glossário Protótipo de GUI Especificar Requisitos Ata de Avaliação Modelo Caso de Uso Modelo Classes Negócio Analista de Negócio 133

134 Descrição Caso de Uso Diagrama de Seqüência Negócio Descrição de Atores Diagrama de Estados Especificar Modelos de Negócio Glossário Modelo Caso de Uso Documento de Arquitetura Projeto de Soluções Aplicação Descrição Caso de Uso Projetar Arquitetura do Software Protótipo de GUI Documento de Arquitetura Documento de Arquitetura Projetista de Aplicação Modelo de Classes Negócio Diagrama Classes de Projeto Diagrama Sequência Negócio Diagrama Seqüência de Projeto Projetar Aplicação Diagrama de Estados Modelo de Dados Doc. de Arquitetura Código Fonte Desenvolvedor Diag. Classes de Projeto Diag. Seqüência Projeto 134

135 Codificar Aplicações Modelo de Dados Realizar Teste Unitário Código Fonte CheckList Teste Unitário Desenvolvedor Descrição Caso de Uso Plano de Testes Engenheiro de Testes Doc. de Arquitetura Casos de Testes Diagrama Classes de Projeto Relatório Resultado de Testes Diag. Seqüência Projeto Realizar Testes de Integração Código Fonte Descrição Caso de Uso Plano de Testes Gerente do projeto Doc. de Arquitetura Casos de Testes Analista de negócio Código Fonte Relatório Resultado de Testes Responsável do Cliente Realizar Testes de Aceitação 135

136 Ata de Aceitação Tabela 4 Atividades de Ciclo de Vida do Processo Padrão VixTeam. Atividade Artefato Insumo Artefato Produto Responsável Planejar Qualidade Itens do Plano de Projeto Plano de Qualidade Engenheiro de Qualidade Artefato a ser avaliado Ata de Avaliação Gerente de Projeto Ata de Aprovação Analista de Negócio Analisar Criticamente Responsável do Cliente Artefato a ser revisado Ata de Avaliação Engenheiro de Qualidade Ata de Aprovação Revisar Qualidade dos Artefatos Registro de Qualidade Processo de Desenvolvimento Processo de Desenvolvimento Revisado Engenheiro de Processo 136

137 Registros de Qualidade Padrões de Desenvolvimento Revisados Revisar Qualidade do Processo de Desenvolvimento Padrões de Desenvolvimento Ata de Aprovação Engenheiro de Qualidade Ata de Avaliação Registro de Qualidade Gerente de Projeto Ata de Aprovação Analista de Negócio Registrar Qualidade Relatório Resultado de Testes Engenheiro de Testes Solicitação de Alteração Ata de avaliação Gerente de Projeto Artefato a ser Alterado Plano de Projeto Gerenciar Configuração Artefato Modificado Versão anterior do padrão Padrão Operacional Alterado Projetista de Soluções Padrões relacionados Ata de aprovação 137

138 Engenheiro de Qualidade Elaborar Padrões Operacionais Engenheiro de Processo Produto de software Ata de avaliação Gerente de Projeto Especificação Produto Software Plano de integridade do produto de software Analista de Negócio Validação de Produto de Software Incluído Requisitos do Software Tabela 5 Atividades de Controle da Qualidade do Processo Padrão VixTeam. Atividade Artefato Insumo Artefato Produto Responsável Gerenciar e acompanhar andamento do projeto Plano de Projeto Plano de Projeto Revisado Gerente do Projeto Planejamento de Treinamento Plano de Treinamentos Anual Gerência Sênior Tabela 6 Atividades de Gerência do Processo Padrão VixTeam. 138

139 4. Conclusão Neste trabalho, apresentamos as primeiras fases de um programa de SPI, orientado pelo IDEAL R, que está sendo realizado na VixTeam e que conduziram à elaboração de um Processo Padrão para o desenvolvimento de software orientado a objetos. A fase de Ação do Modelo IDEAL R já está em andam ento. Foi formada uma Equipe Técnicos Especialistas (Technical Working Group - TWG), que está refinando a proposta do processo padrão de software, compatibilizando-a com o sistemática de gerenciamento de projetos da VixTeam e vice-versa. Já está definido um projeto piloto para a validação do processo padrão, que será acompanhado de perto pelo TWG que dará orientações e fará os ajustes necessários. A partir desta validação, o processo padrão deverá ser divulgado para toda a organização e, após um período de avaliação dos resultados obtidos, poderá ser replanejada (fase 5) uma nova entrada no ciclo do modelo IDEAL para aprimorar o processo de maneira a corrigir falhas no atendimento dos requisitos da norma ISO Nesta nova entrada do ciclo do IDEAL, deve ser feita uma revisão do programa de qualidade, adequando-o à nova versão da norma ISO 9000 (ISO 9001:2000) [6], que foi publicada quando a fase de planejamento do primeiro ciclo já havia sido concluído. Espera-se, assim, que até dezembro de 2002, a meta de obtenção da certificação seja atingida, já utilizando a nova versão da norma. REFERÊNCIAS BIBLIOGRÁFICAS [1] McFeeley, Bob. IDEALSM : A User s Guide for Software Process Improvem ent, [2] Rocha, A.R.C., et al., Qualidade de Software: Teoria e Prática, Prentice Hall, [3] NBR ISO :1993. Normas de gestão e garantia da qualidade parte 3,diretrizes para a aplicação da NBR ISO 9001 ao desenvolvimento, fornecimento e manutenção de software, [4] Fiorini, S., et al.; Engenharia de Software com CMM, Brasport, [5] ISO/IEC Information technology software life cycle processes, [6] ISO 9001:2000. Quality management systems. Requirements,

140 O USO DA EXTRANET NA COORDENAÇÃO DE PROJETOS: aplicação em estudo de caso Rosana Beatriz PICORAL M.Sc., Arq., Prof. FAU/FENG/PUCRS. Av. Fábio Araújo Santos, 1660, CEP Porto Alegre (RS) - Renato S. SOLANO Eng., Mestrando pelo CPGEP/UFSC. Av. Fábio Araújo Santos, 1660, CEP Porto Alegre (RS) - RESUMO Este trabalho mostra o resultado do uso da extranet como ferramenta de gerenciamento de documentos de projeto, fazendo parte dos procedim entos de coordenação de projetos realizada por empresa contratada especificamente para este fim. O empreendimento objeto deste trabalho foi um empreendimento comercial,com área aproxim ada de m INTRODUÇÃO A coordenação de projetos deve promover o controle e troca de informações entre os diversos intervenientes; definir diretrizes de projetos ; estabelecer cronograma de desenvolvimento dos mesmos; garantir que os diversos projetos estejam compatibilizados em todas as fases: estudos preliminares, anteprojeto, projeto legal, projeto executivo; visem a construtibilidade. Considerando todas estas atribuições, suas atividades podem ser agrupadas em: planejamento, compatibilização e gerência de documentos de projeto. No aspecto da gerência de documentos do projeto as extranets de projeto tem possibilitado um crescimento significativo na capacidade de comunicação entre os intervenientes de um empreendimento e tem apresentado um grande potencial para a implementação de sistemas de informação inter-organizacionais (CALDAS, C.; SOIBELMAN,L..2001). Analisaremos, neste trabalho, os resultados da experiência do uso de uma extranet de projetos na gerência de documentos do empreendimento, como parte das atividades da coordenação de projetos. 2. GERÊNCIA DE DOCUMENTOS COM AUXIILIO DA EXTRANET 140

141 Os sistemas de extranet permitem o compartilhamento e armazenamento de informações, comunicações, orçamentos, cronogramas, planejamento, arquivos de projetos, alterações, enfim todos os documentos que forem pertinentes a um dado empreendimento, em endereço exclusivo na Web, de acesso restrito apenas aos inscritos no projeto e habilitação controlada pelo coordenador de projetos, isto é, as possibilidades de acesso de cada membro são individualizadas e controladas. O aumento da capacidade de comunicação faz com que a extranet seja uma ferramenta importante na gerência de documentos de projeto, pois abrevia o tempo gasto com transporte de arquivos via motoqueiros; cria mecanismos (m onitorados pela coordenação) que garante que os arquivos disponibilizados para cada projetista sejam sempre os mais atualizados, independentemente da organização interna dos diversos escritórios; protocola o upload de cada arquivo e suas substituições; possui mecanismos de aviso automático aos interessados cada vez que ocorra a inserção de novo documento no sistema, possibilita a emissão de vários tipos de relatórios com registros de todos os acessos ao sistema: upload, download, bloqueio e/ou liberação de arquivos, mensagens; disponibiliza mecanismos de comunicação entre os intervenientes da obra. Todos estes registros passam a fazer parte do histórico da obra. Segundo SOIBELMANN (2001), 25% das empresas norte-americanas de construção civil utilizam-se das redes extranet e apesar da existência de dificuldades, após a adoção de um sistema deste tipo não existe registro de empresas que voltem atrás. 2.1 Aplicação do sistema extranet em estudo de caso O uso de um sistema extranet de projeto na coordenação de um empreendimento de porte permitiu verificar vantagens e dificuldades apresentadas por esta ferramenta. Para que se tenha êxito é necessário que toda comunicação seja feita através da extranet, isto é, desde o armazenamento de arquivos de projeto até o esclarecim ento de dúvidas dos intervenientes, substituindo a troca de s convencionais ou telefonemas por mensagens recurso de troca de s que ficam armazenados no histórico da obra e são enviados diariamente para os destinatários até que sejam solucionadas as dúvidas e dada a baixa da mensagem pelo remetente que a originou. Isto democratiza a informação, além de manter o registro da pendência até sua solução. Disciplinar os usuários neste sentido é uma 141

142 tarefa árdua do coordenador, não tendo-se conseguido chegar a 100% das situações. O sistema utilizado é de fácil aplicação, mas o fato de que nenhum dos interveniente havia trabalhado com um sistem a de extranet de projeto anteriormente fez com que fosse necessário a exposição do sistema em reunião coletiva e orientações individuais a medida que cada membro foi fazendo uso do mesmo. Uma das limitações é que o usuário tem que ter uma boa linha telefônica (de preferência banda larga). Como a coordenação de projetos não participou da contratação dos projetistas, este aspecto não foi levantado nesta etapa e gerou algumas dificuldades na hora da implantação do sistema. Dos 30 intervenientes cadastrados até o momento: 02 projetistas (6,66%) não quiseram aderir ao sistema; 03 projetistas (10%) tinham na empresa apenas uma linha telefônica. Isto dificultou as orientações individuais no momento que o projetista tinha alguma dúvida para uso do sistema pelo fato de não poder ficar conectado enquanto esclarecia a dúvida pelo telefone. Estes projetistas passaram a fazer o upload de seus arquivos preferencialmente fora do horários comercial; 03 projetistas (10%) tiveram problema de configuração de seu provedor fazendo com que o sistema ficasse extrem amente lento. Após a identificação deste caso, o próprio provedor, que era o mesmos dos 3 projetistas, resolveu o problema. A maioria dos projetistas: 22 = 73,4%, não teve qualquer dificuldade. A facilidade da extranet como canal de com unicação fez com que se agilizasse a emissão de dados para projetistas locais, e, principalmente os de outras cidades e/ou estados. O próprio investidor foi cadastrado como um dos usuários do sistema e pode acompanhar a evolução do processo. O fato do investidor não ser do setor imobiliário e não ter programas do tipo AUTOCAD não impossibilitou participação ativa, pois a própria autodesk disponibiliza o Volo View Express ( 1) gratuitamente na internet. A distribuição de documentos de projeto com o sistema extranet permitiu a eliminação de vários procedimentos de controle relativos a esta atividade, pois o próprio sistema tem mecanismos de registro e emissão de relatórios de todas operações realizadas. A agilização da disponibilidade dos documentos de projeto permitiu descentralizar a responsabilidade da plotagem de arquivos, que no processo anterior concentrava sua 142

143 em grande parte na coordenação de projetos. O sistema extranet utilizado apresenta também m ecanismos que facilita a comunicação com a copiadora. Considerando que os arquivos são armazenados no sistema (UpLoad) pelo seu nome, foi importante a orientação da coordenação para que no espaço destinado a coment rios fosse colocado o assunto contido no arquivo. Isto permitiu que os demais intervenientes não precisassem fazer era ou não de seu interesse. download para verificar se o arquivo No momento da substituição de arquivos já armazenados, foi importante a orientação da coordenação para que o novo arquivo tivesse exatamente o mesmo nome do anterior, inclusive no referente ao uso de letras maiúsculas e minúsculas. Apenas em um caso de substituição de arquivos não foi seguida esta orientação, mas o erro foi logo constatado pela coordenação que bloqueou os arquivos desatualizados. No decorrer do processo, o próprio sistema passou a apresentar um recursos novo, que no momento do cadastramento de qualquer arquivo ele identifica arquivos que tenham nomes parecidos. O objetivo é auxiliar o coordenador de modo que não fiquem disponibilizados no sistem a arquivos desatualizados. Outra orientação importante nesta operação é que no espa o coment rios fossem listados os aspectos alterados de uma versão para outra, para identificação rápida dos demais intervenientes. A aprovação de arquivos pela coordenação, que nos procedimentos anteriores ocorria através de carimbos em cópias plotadas, passou a ser liberado no próprio sistema. A coordenação pode disponibilizar (ou não) todos os arquivos para os diversos intervenientes para que possam processo de desenvolvimento dos acompanhar e trabalhar em paralelo no projetos. Cada arquivo quando cadastrado no sistema entra como não autorizado e na medida que estes projetos estejam plenam ente definidos e compatibilizados a critério do coordenador ele pode alterar o status do arquivo para autorizado. Quanto aos relatórios de documentos vigentes por projeto, o sistema disponibiliza uma lista de arquivos que relaciona além do nome do arquivo propriamente dito as várias datas que ele foi cadastrado nos sistema. Esta lista não se m ostrou pratica para necessidade dos projetistas, pois além de extensa não contém inform ações importantes, como por exemplo, a versão do documento. A coordenação de projetos precisou manter em procedimentos paralelos que permitiram emitir 143

144 relatórios para esta finalidade. Estas relações precisam ser recadastradas no sistema sem pre que ocorre acréscimo ou substituição de arquivos no sistema. Outro problema detectado, foi que o responsável pelo sistema extranet de projetos, cadastrado como um dos usuários do empreendimento apenas para fins de suporte, em determinado momento passou a utilizar o cadastro dos demais usuários para emissão de mensagens para os mesmos, independentemente do interesse da coordenação de projetos. Procedimento não aprovado pela coordenação de projetos e reconhecido pelo responsável do sistema como uma extrapolação de suas atribuições. 3. CONCLUSÃO O sistema extranet é, sem dúvida, uma ferramenta importante e de fácil implantação, mas que auxilia a coordenação apenas no que se refere a suas atividades de gerência de documentos do empreendimento. Mesmo em relação a estas atividades, o sistema não dispensa a participação da coordenação de projetos no referente a orientações diversas e na seleção de documentos disponilizados para cada usuário. As atividades de planejamento e compatibilização de projetos também de responsabilidade da coordenação continuaram sendo realizadas pelos procedimentos que já eram usuais da empresa (PICORAL, 2000), com a vantagem de pelo fato da sim plificação das atividades de gerenciamento sobrar mais tempo para as mesmas. A utilização de sistemas extranet de projetos significa um avanço significativo na área de transm issão de dados. Os problemas detectados foram facilmente contornados. Durante o período deste estudo de caso observou-se que o próprio sistema foi incorporando novos recursos. Quanto a necessidade de emissão de outros tipos de relatórios pelo sistema, como por exemplo, o relatório de documentos vigentes, foram feitas solicitações ao administrador da extranet. REFERÊNCIAS BIBLIOGRÁFIC AS CALDAS, Carlos H.S.; SOIBELMAN, Lúcio. Avaliação da logística da informação em processos interorganizacionais na construção civil. In. II Simpósio Brasileiro de Gestão da Qualidade e Organização do Trabalho no Ambiente Construído - SIBRAGEQ. Anais: Fortaleza,

145 PICORAL SOLANO, Rosana B. Coordenação de projetos: uma ferramenta para garantir a qualidade do projeto arquitetônico. Dissertação de Mestrado. UFRGS: PROPAR, RS RODRIGUES, Mariuza. Construção virtual. In. Téchne Revista de Tecnologia da Construção. São Paulo. PINI: março/abril 2001, número 51, p RODRIGUEZ, M. Arancibia; HEINECK, L. Fernando. Coordenação de projetos: uma experiência de 10 anos dentro de empresa construtora de médio porte. II Simpósio Brasileiro de Gestão da Qualidade e Organização do Trabalho no Ambiente Construído - SIBRAGEQ. Anais: Fortaleza, In. SOIBELMAN, L; CALDAS, Carlos H.S. O uso de extranets no gerenciamento de projetos: o exemplo norte americano. In: ENTAC, 80. Artigo técnico.salvador, BA V.1 p Disponível em: 145

146 SITES E LIVROS PARA CONSULTAS [PDF] Gerenciamento do escopo em projetos [PDF] de pmtech.com.br MA SOTILLE, CM Menezes Luís - Rio de Janeiro:, pmtech.com.br... 1 Curso de Especialização em Gerenciamento de Projetos com ênfase em Tecnologia da Informação Gerenciamento de Escopo em Projetos Mauro Sotille... PUCRS / PMI-RS RH Bibliografia As áreas do gerenciamento do projetos Com unicações Aquisições Integração... Citado por 6 - Artigos relacionados [PDF] Gerência de Risco em Processos de Qualidade de Software: um a Análise Com parativa [PDF] de cefetrn.br CMG de Gusmão - cefetrn.br... foco nos riscos técnicos de definição da arquitetura do software; Construção tratamento dos riscos lógicos envolvidos na construção do produto e; Transição os riscos funcionais de utilização do software [8]. O Instituto de Gerenciamento de Projetos (PMI Project... Citado por 10 - Artigos relacionados - Ver em HTML [PDF] Valor estratégico dos projetos de tecnologia de informação [PDF] de cefetrn.br AL Albertin - RAE, cefetrn.br... Os adm inistradores têm procurado m ais conhecimento do valor estratégico de TI e dos aspectos dos projetos dessa tecnologia, considerando suas particularidades e as melhores práticas de seu gerenciamento, constatando que esse conhecimento é essencial, pelo... Citado por 79 - Artigos relacionados - Ver em HTML - Todas as 9 versões [PDF] Um Modelo de Processo de Gestão de Riscos para Ambientes de Múltiplos Projetos de Desenvolvimento de Software [PDF] de ufpe.br CMG De Gusm ão bdtd.ufpe.br AMBIENTES DE GERENCIAMENTOas.com.br PROJETOS GERÊNCIADE RISCOS metas organizacionais. Em gerenciamento de projetos, para garantir o sucesso das metas organizacionais e... Citado por 7 - Artigos relacionados - Todas as 3 versões [PDF] Um Modelo de Gerenciamento de para um Ambiente de Desenvolvimento Distribuído de Software [PDF] de uem.br LNM ENAMI, EHM HUZITA - INTERNATIONAL, din.uem.br Dissertação apresentada ao Programa de Pós- Graduação em Ciência da Com putação da Universidade Estadual de Maringá, como requisito parcial para a obtenção do grau de Mestre em Ciência da Computação.... Orientadora: Profª. Drª. Tania Fatim a Calvi Tait. Citado por 7 - Artigos relacionados - Ver em HTML [PDF] Project management knowledge learning environm ent: ambiente inteligente de aprendizado para educação em gerenciamento de projetos 146

147 [PDF] de ufpe.br PGBC Torreão - php.cin.ufpe.br Ambiente Inteligente de Aprendizado para Educação em... Universidade Federal de Pernambuco Ambiente Inteligente de Aprendizado para Educação em... Este trabalho foi apresentado à Pós-Graduação em Ciência da... Citado por 7 - Artigos relacionados [PDF] A capacidade de regulação estatal na Argentina 5 [PDF] de geocities.ws O Oszlak, R Felder, LR Jones - Revista do Servi o, geocities.ws... Profissional em Gerenciamento de Projetos pelo Project Management Institute, EUA. Consultor em Gerenciamento de Programas e Projetos... Os Resultados, que são os produtos pelos quais a gerência do projeto se responsabiliza, exigem indicadores de acompanhamento Citado por 24 - Artigos relacionados - Ver em HTML - Todas as 3 versões [PDF] Ferramenta CASE para gerenciamento de projetos e métricas de software [PDF] de leonardonobre.com.br FB Vavassori, EW Souza - XV Simpósio Brasileiro de - leonardonobre.com.br RESUMO: Este artigo apresenta o Gemetrics, uma ferramenta CASE para o gerenciamento de projetos e métricas de software. O principal enfoque abordado é a integração de recursos para o planejamento, gerenciamento e métricas de software, sendo com isto possível produzir... Citado por 5 - Artigos relacionados - Ver em HTML - Todas as 6 versões [PDF] Gerência de Projetos O Modelo PMBOK [PDF] de ufpe.br H Perrelli - Centro de Inform tica da Universidade Federal de, cin.ufpe.br... ou tecnologia; a maioria falhará por falta de um gerenciamento de projetos habilidoso. [ Standish Group, 1999 ]...São realizados por pessoas Caem em duas categorias: Processos de gerenciamento de projetos : Relacionados à organização e realização do trabalho.... Citado por 5 - Artigos relacionados - Ver em HTML - Todas as 11 versões [PDF] Gerenciamento de projetos e simulação de processos: uma abordagem integrada [PDF] de inpe.br PRN Travassos - ANAIS do III WORCAP-INPE-, mtcm18.sid.inpe.br Este trabalho apresenta uma proposta para a criação de uma metodologia integrada e as suas ferramentas de apoio, para aplicação tanto em simulação de processos como na gerência e controle de projetos. As analogias e as diferenças entre essas áreas de estudo são... Citado por 5 - Artigos relacionados - Ver em HTML - Todas as 4 versões [PDF] A gestão de projetos como aprimoramento da terceirização [PDF] de pbh.gov.br AL Guedes - Informática Pública, ip.pbh.gov.br Dois tipos de terceirização em TI são atualmente utilizados: 1. por serviços, onde a 147

148 mão-de-obra é gerenciada pelo locador e os serviços são pagos com base nas horas trabalhadas; e 2. por projeto, onde a empresa estabelece prazos, recursos e custos para o desenvolvimento... Citado por 5 - Artigos relacionados - Todas as 2 versões [PDF] Corrente Crítica: Uma alternativa à gerência de projetos tradicional [PDF] de ufpe.br AB BARCAUI - Revista Pesquisa e Desenvolvimento, di.ufpe.br Revista Pesquisa e Desenvolvimento Engenharia de Produção n.2, p. 1 21, jul CORRENTE CRÍTICA: UMA ALTERNATIVA À GERÊNCIADE PROJETOS TRADICIONAL... Prof. André B. BARCAUI Mestrando em Sistemas de Gestão Laboratório de Tecnologia, Gestão de... Citado por 5 - Artigos relacionados - Todas as 6 versões [PDF] Perfil de escritórios de gerenciamento de projetos em organizações atuantes no Brasil [PDF] de unifei.edu.br AB BARCAUI - Revista Pesquisa e, revistaped.unifei.edu.br Revista Pesquisa e Desenvolvimento Engenharia de Produção n.2, p , jul PERFIL DE ESCRITÓRIOS DE GERENCIAMENTODE PROJETOS EM ORGANIZAÇÕES ATUANTES NO BRASIL...Prof. André B. BARCAUI Mestrando em Sistemas de Gestão Laboratório... Citado por 5 - Artigos relacionados - Todas as 2 versões [PDF] Uma ferramenta em busca do defeito zero [PDF] de tripod.com T Pyzdek - HSM Management, Maio-junho, unimoney.tripod.com... rápida. Use o gerenciamento de projetos e outras ferramen- tas de planejamento e gerenciamento para implementar a nova abordagem. Em pregue mé- todos estatísticos para validar a melhoria. Controle o novo sistema. Institucionalize... Citado por 12 - Artigos relacionados - Ver em HTML - Todas as 3 versões [PDF] U m Estudo Experimental sobre a Utilização de Modelagem e Simulação no Apoio à Gerência de Projetos de Software [PDF] de ufmg.br MDEO BARROS, CML WERNER - lbd.dcc.ufmg.br COPPE / UFRJ Departamento de Engenharia de Sistemas e Computação Caixa Postal: CEP Rio de Janeiro RJ Telefone: / Fax: {marcio, werner, artigo apresentam os um estudo experimental... Citado por 5 - Artigos relacionados - Ver em HTML [PDF] Portfolio management 148

149 [PDF] de iqpc.com HT Barra - iqpc.com... em um grupo de empresas com culturas distintas Nesta apresentação discutiremos sobre os desafios encontrados na implantação de uma metodologia única de seleção e priorização de projetos associada a disseminação da cultura em gerenciamento de projetos entre três... Citado por 9 - Artigos relacionados - Ver em HTML [LIVRO] Gestão de ONGs: principais funções gerenciais FG Tenório books.google.com... Page Gestão de ONGs: Principais Funções Gerenciais problemas que ameaçam a sua sobrevivência a curto prazo, principalmente quando os recursos se tornam escassos, comprometendo a condução de seus projetos e questionando sua própria razão de ser.... Citado por Artigos relacionados - Todas as 2 versões Definição de um Processo Ágil de Gestão de Riscos em Ambientes de Múltiplos Projetos [PDF] de pucrs.br L Ribeiro - HÍFEN, revistaseletronicas.pucrs.br Abstract. The Risk Management is one of the m ain interesting topics of Project Management to researchers, because it involves many challenges and unpredictable and difficult factors to control. However, due to the number of unsuccessful projects, Agile Methodologies... Citado por 4 - Artigos relacionados - Todas as 3 versões [PDF] Análise de Maturidade no Gerenciamento de Projetos de Tecnologia de Automação [PDF] de ufba.br RUYC DE BARROS - adm.ufba.br... Análise de Maturidade no Gerenciamento de Projetos de Tecnologia de Automação...ANÁLISE DE MATURIDADE NO GERENCIAMENTODE PROJETOS DE TECNOLOGIA DE AUTOMAÇÃO OCASO DA CIBA ESPECIALIDADES QUÍMICAS LTDA. NO SITE DE CAMAÇARI... Citado por 5 - Artigos relacionados - Ver em HTML - Todas as 2 versões [DOC] Gerência de projetos na engenharia de software em relação às práticas do PMBOK [DOC]de pr.gov.br CF MACHADO - QS- M TRICAS PARA, celepar7cta.pr.gov.br A comunidade de software tem desenvolvido muitos estudos sobre as causas da crise de software e novos m todos, t cnicas e ferram entas tem sido disponibilizados para ajudar a superá-la. Esse artigo descreve quais são as causas detectadas para a crise de... Citado por 4 - Artigos relacionados - Ver em HTML - Todas as 4 versões 149

150 [PDF] Gerência de projetos uma reflexão histórica w.uca pro M CODAS - Revista de Administração de Empresas, rae.com.br 1 Mollica F?, Arm ando. Gerenciamento do Prazo. São Paulo, (Seminários Planasa.) 2 Parsons, Jam es A. Operation research and related developments. Handbook of business adm inistration. New York, McGraw-Hill, Fitzgerald, JM & Fitzgerald, AF... Citado por 4 - Artigos relacionados - Todas as 4 versões [HTML] Os recursos hídricos no sem i-árido [HTML] de bvs.br R Garjulli - Ciência e Cultura, cienciaecultura.bvs.br... O DNOCS e a Companhia de Desenvolvimento do Vale do São Francisco (Codevasf) foram os principais órgãos públicos federais encarregados da implantação e do gerenciamento desses projetos, em todo o Nordeste. Im plantados... Citado por 8 - Artigos relacionados - Em cache - Todas as 4 versões [PDF] Maturidade em Gestão de Projetos Análise de um Caso e Proposição de um Modelo para de portaldeconhecimentos.org.br ACA Maximiano - de Gestão de, portaldeconhecimentos.org.br... Tem a: Gerenciamento de projetos tecnológicos.... Palavras-chave: Administração de Projetos ; Gerenciamento de Projetos ; Gestão de Projetos ; Maturidade em Gestão de Projetos ; Maturidade Organizacional; Project Management, Maturity Model, Project Manager Page Citado por 4 - Artigos relacionados - Ver em HTML - Todas as 2 versões Um ambiente de desenvolvimento distribuído de software disen [PDF] de ufmg.br EHM Huzita, TFC Tait, TE Colanzi - I Workshop de, lbd.dcc.ufm g.br... Interfaces para Gerenciamento de Projetos no DiSEN...Também, o modelo de gerenciamento de projetos e a ferramenta DIMANAGER foram validados por empresas desenvolvedoras de software que atestaram a sua viabilidade de utilização (Pedras, 2003; Enami, 2006).... Citado por 8 - Artigos relacionados - Ver em HTML - Todas as 2 versões [PDF] Gerenciamento de projetos ea aplicação da análise de valor agregado em grandes projetos [PDF] de usp.br com.br ANÁLISE DE VALOR AGREGADO EM GRANDES PROJETOS...ANÁLISE DE VALOR AGREGADO EM GRANDES PROJETOS...Este exemplar foi revisado e alterado em relação à versão original, sob...oliveira, Rodrigo César Franceschini de Gerenciamento de projetos ea... Citado por 5 - Artigos relacionados - Todas as 2 versões 150

151 [PDF] O ambiente de inovação ea gerência de projetos [PDF] de abepro.org.br R Rabechini Jr - Encontro Naciona l de Engenharia, abepro.org.br Doutorando do Depto de Eng. Produção - Escola Politécnica Universidade de São Paulo Pesquisador do IPT Instituto de Pesquisas Tecnológicas do Estado de São Paulo Av. Prof. Almeida Prado, 532 Cep São Paulo SP Brasil Tel: (011) Fax: (011) Citado por 4 - Artigos relacionados - Ver em HTML [PDF] Gerência de projeto de software em ambiente fisicamente distribuído: um estudo de caso [PDF] de pucrs.br R Zanoni - VIII Congreso Argentino de Ciencias de la, inf.pucrs.br O objetivo deste paper é apresentar os resultados de um estudo de caso desenvolvido no Centro de Pesquisa em e-business DELL/PUCRS, um ambiente fisicam ente distribuído onde os clientes, usuários e equipe de desenvolvimento estão localizados em locais diferentes,... Citado por 4 - Artigos relacionados - Ver em HTML - Todas as 3 versões [LIVRO] Cadeia de suprimentos- Projeto e Gestão D Simchi- Levi, P Kaminsky books.google.com Obra originalmente publicada sob o título Designing and managing the supply chain - concepts, strategies, and case studies 2000, The McGraw - Hill Companies, Inc. Todos os direitos reservados. ISBN Capa: Mário Rõhnelt Preparação do original:... Citado por 59 - Artigos relacionados [PDF] As peças do quebra-cabeças do gerenciamento do conhecimento [PDF] de pmtech.com.br T Koulopoulos - Internacional -Gerenciamento do Conhecimento São - pmtech.com.br Page 1. Gerenciamento de Projetos tech.com.br 1/4 As Peças do Quebra-cabeças do Gerenciamento do Conhecimento...Na realidade, o inverso é verdadeiro. Nos mercados de Page 2. Gerenciamento de Projetos 2/4... Citado por 7 - Artigos relacionados - Ver em HTML - Todas as 3 versões [PDF] Sistemática proposta para seleção de fornecedores em gestão de projetos [PDF] de scielo.br LH Alencar, A T ALMEIDA - Gestão & Produ ão, São, SciELO Brasil A gestão de projetos vem sendo alvo de inúmeros estudos nos últim os anos, uma vez que os projetos estão se tornando cada vez mais complexos. Os fornecedores exercem papéis cruciais na gestão de projetos, estando envolvidos em uma rede de atividades conectadas que,... Citado por 5 - Artigos relacionados - Ver em HTML - Todas as 4 versões 151

152 [PDF] Um m odelo estruturado de com petências e maturidade em gerenciamento de projetos [PDF] de scielo.br R Rabechini Jr - Revista Produção, SciELO Brasil Abstract This study presents a structured analytic model focused on project management applied to enterprise organizations. The vital importance of the topic regarding project management is pointed out, given that current enterprise status in the majority of economic branches... Citado por 7 - Artigos relacionados - Ver em HTML - Todas as 2 versões Tempo de implantação de sistemas ERP: análise da influência de fatores e aplicação de técnicas de gerenciamento de projetos [HTML] de scielo.br TCC Padilha, AFB Costa, JL Contador - Gest. Prod - SciELO Brasil Freqüentemente, a implantação de sistemas ERP é complexa e demorada, requerendo, em alguns casos, três ou quatro anos. Em geral, um sistema ERP divide-se em m ódulos cujas implantações são feitas em vários estágios. Um problem a sério é que os prazos para a implantação... Citado por 7 - Artigos relacionados - Em cache - Todas as 7 versões [PDF] Escritório de gerenciamento de projetos : um estudo de caso [PDF] de usp.br ACA Maximiano - Revista de Administra ão, revistasusp.sibi.usp.br Os estudos e a adoção de metodologias de gerenciamento de projetos vêm ganhando terreno desde as duas últimas décadas do século XX, devido a quatro fatores principais: surgim ento de negócios, como a tecnologia da informação, orientados para produtos feitos sob... Citado por 8 - Artigos relacionados - Ver em HTML - Todas as 3 versões [LIVRO] Gerência de projetos de tecnologia da informação J Phillips - books.google.com Informações essenciais para o seu upgrade profissional MARCOS Sf MÓI A GESTÃO SEGURANÇA Gestão de Segurança da Informação Nível: Iniciante - Intermediário Páginas: 184 ISBN: Aquisição de Produtos e Serviços de Software Aquisição de Produtos e... Citado por 9 - Artigos relacionados - Todas as 2 versões [PDF] Implantação e consolidação de escritório de gerenciamento de projetos : um estudo de caso [PDF] de scielo.br AP Martins, MR Martins, MMM Pereira - Revista Produção, SciELO Brasil Abstract The growth in telecommunications sector, mainly on m obile telephony, has been very significant since the end of 90 s due to the public policies adopted in Brazil. Among growth strategies, adopted for the four biggest m obile telephony companies in Brazil, there is the... Citado por 7 - Artigos relacionados - Ver em HTML - Todas as 5 versões [PDF] Munddos-um modelo de referência para desenvolvimento distribuído de software [PDF] de ufmg.br R Prikladnicki - XVIII Simpósio Brasileiro de Engenharia de - lbd.dcc.ufm g.br... processo é baseado em parte de outros processos conhecidos na 152

153 comunidade acadêmica e empresarial, tais como RUP (Rational Unified Process) para o desenvolvimento de software e a metodologia do PMI (Project Management Institute) para o gerenciamento de projetos.... Citado por 24 - Artigos relacionados - Ver em HTML - Todas as 6 versões [PDF] WGPMS: uma abordagem de inteligência artificial na gestão colaborativa de projetos na web [PDF] de iadis.net BT Dantas - Anais Conferência Iadis Ibero-Americana - iadis.net RESUMO A coordenação de um grupo, envolvido em diferentes atividades simultâneas de um projeto, necessita do apoio de ferramentas que permitam avaliar continuamente a participação de cada membro. Esta ação acontece em diferentes fases e momentos, tornando difícil... Citado por 6 - Artigos relacionados - Ver em HTML [PDF] Identificação de riscos em projetos de TI [PDF] de abepro.org.br DTV Nakashima - XXIV Encontro Nac. de Eng. de, abepro.org.br...neste artigo apresenta-se uma revisão das técnicas de gerenciamento de projeto, em especial das ferramentas de gestão de riscos aplicadas a projetos de Tecnologia da Informação (TI).... Palavras chave: Gerenciamento de Projetos, Riscos, Tecnologia da Informação.... Citado por 9 - Artigos relacionados - Todas as 2 versões [PDF] Método para gestão de riscos em implementações de sistemas ERP baseado em fatores críticos de sucesso [PDF] de usp.br FAR Gambôa, MS Caputo - Journal of Information, revistasusp.sibi.usp.br...m elhoria sem pre que possível. De acordo com duas importantes referências sobre gerenciamento de projetos, a norma NBR ISO 10006:2000 eo PMBOK (PMI, 2000), a gestão de risco em projetos envolve alguns processos:... Citado por 12 - Artigos relacionados - Ver em HTML - Todas as 6 versões [PDF] A importância da modelagem do processo de projeto para o desenvolvimento integrado de edificações [PDF] de portaldeconhecimentos.org.br FV ROMANO, N BACK - de projeto na, portaldeconhecimentos.org.br Fabiane Vieira ROMANO M. Eng. Produção, Eng. Civil, Doutoranda pelo Programa de Pós-Graduação em Engenharia de Produção, da Universidade Federal de Santa Catarina. Rua Maria Eduarda, 57/104 Pantanal Florianópolis, SC Brasil Correio... Citado por 9 - Artigos relacionados - Ver em HTML - Todas as 4 versões [LIVRO] Gestão do processo de projeto de edificações MAC Silva nomedarosa.com.br Este livro foi elaborado com o objetivo de fornecer a estas empresas e profissionais um instrumento prático para que o desenvolvimento do projeto de edifícios de toda 153

154 natureza seja dotado de mecanismos que possam assegurar a qualidade global deste processo. Assim, esta... Citado por 19 - Artigos relacionados - Ver em HTML [PDF] Fatores críticos para implementação de gerenciamento por projetos : o caso de um a organização de pesquisa [PDF] de scielo.br R Rabechini Jr, MM CARVALHO - Revista Produção, SciELO Brasil Abstract The project management methodology has been increasingly applied in companies nowadays. Nevertheless, in Brazilian panorama it is also difficult to verify the adoption of formal project management program. Companies searching for competitive advantages through... Citado por 19 - Artigos relacionados - Ver em HTML - Todas as 5 versões [PDF] Metodologia singular de gestão de projetos : condição suficiente para a maturidade em gestão de projetos [PDF] de scielo.br R Bouer - Revista Produção, SciELO Brasil Abstract The world in which organizations operate today is rapidly becoming more complex than ever before. Major shifts in technology and in the business and economic environment present many opportunities, but also many challenges, to organizations striving to manage and... Citado por 13 - Artigos relacionados - Ver em HTML - Todas as 5 versões [PDF] Liderança e influência nas fases da gestão de projetos [PDF] de scielo.br R RUSSO, JM Ruiz - Revista Produção, SciELO Brasil Abstract This article analyzes the role of leadership as a critical factor for success of project m anager. On the basis of a survey, it was identified some of competences and skills that most contributed to the success of the project, within the phases described by PMI (2004).... Citado por 11 - Artigos relacionados - Ver em HTML - Todas as 5 versões Fatores críticos de sucesso no gerenciamento de projetos de desenvolvim ento de produto em empresas de base tecnológica de pequeno e médio porte [HTML] de scielo.br JC TOLEDO, SL SILVA, GHS Mendes - Gest. Prod - SciELO Brasil As em presas de base tecnológica (EBTs) estão associadas à inovação tecnológica, principalmente de produto, o que torna o desenvolvimento de produto um processo crítico para tais empresas. O desempenho deste processo pode ser avaliado em função dos resultados,... Citado por 11 - Artigos relacionados - Em cache - Todas as 2 versões [PDF] Os escritórios de projetos como indutores de maturidade em gestão de projetos [PDF] de usp.br I Rodrigues, R RABECHINI JR - Revista de, revistasusp.sibi.usp.br Como decorrência da importância que os projetos vêm ganhando no seio das organizações, dois assuntos têm freqüentado a pauta das publicações especializadas em gerenciamento de projetos : os escritórios de 154

155 projetos (Project Management Office PMO) e os modelos... Citado por 11 - Artigos relacionados - Ver em HTML - Todas as 2 versões [PDF] Estruturas de gerenciamento de projetos e competências em equipes de projetos [PDF] de abepro.org.br LA PATAH - Encontro Nacional de Engenha ria de, abepro.org.br Abstract: The world today works with projects. This could be demonstrated by the number of companies adopting the project management methodology (Kerzner, 2000). Project management is the ability to coordinate activities with the main purpose to satisfy the stakeholders'... Citado por 9 - Artigos relacionados [PDF] Estendendo o SCRUM segundo as Áreas de Processo de Gerenciamento de Projetos do CMMI [PDF] de cesar.org.br ASC Mar al, BCC FREITAS, FSF Soares - CLEI Electronic, cesar.org.br Ana Sofia Cysneiros Marçal Universidade de Fortaleza, Mestrado em Informática Aplicada Fortaleza - CE, Brasil, CESAR Centro de Estudos e Sistem as Avançados do Recife Recife - PE, Brasil, Bruno Celso Cunha de Freitas, Felipe... Citado por 8 - Artigos relacionados - Ver em HTML - Todas as 2 versões [PDF] Escritório DE Gerenciamento DE Projetos Um Estudo DE Caso [PDF] de usp.br JL Anselm o ead.fea.usp.br Monografia apresentada à Faculdade de Economia, Administração e Ciências Contábeis, da Universidade de São Paulo, como parte dos requisitos para obtenção do título de Bacharel em Administração de Empresas.... Dedico este trabalho à memória de meu avô, Lilo. Citado por 10 - Artigos relacionados - Todas as 3 versões [LIVRO] Manual prático do plano de projeto : utilizando o PMBOK Guide R Vargas - books.google.com... Management Institute Global Operations Center, pelo apoio a este projeto ; - Microsoft Brasil, especialmente à sua área de Marketing, por ter disponibilizado o trial do Microsoft Office Project para este livro; - a toda a comunidade de gerenciamento de projetos do Brasil ea... PADILHA, Thais Cássia Cabral ; COSTA, Antônio Fernando Branco ; CONTADOR, José Luiz and MARINS, Fernando Augusto Silva. Tempo de implantação de sistemas ERP : análise da influência de fatores e aplicação de técnicas de gerenciamento de projetos. Gest. Prod. [online]. 2004, vol.11, n.1, pp ISSN X. doi: /S X Freqüentemente, a implantação de sistemas ERP é complexa e demorada, requerendo, em alguns casos, três ou quatro anos. Em geral, um sistema ERP 155

156 divide-se em m ódulos cujas implantações são feitas em vários estágios. Um problem a sério é que os prazos para a implantação desses módulos são críticos e raram ente são cumpridos. Esses atrasos geram insatisfação dos clientes, pois resultam em custos adicionais não previstos. A implantação de sistemas ERP depende de vários fatores, alguns dos quais têm muita influência nos prazos de implantação. Considera-se neste trabalho a técnica de planejamento de experimentos para a determinação dos principais fatores. Além disso, são usados métodos de caminhos críticos para a identificação das atividades que requerem mais investimentos para que haja redução no tempo total de implantação do projeto. Keywords : implantação de sistem as ERP; planejamento de experimentos; métodos de cam inhos críticos. [LIVRO] Gerenciamento de projetos RV Vargas books.google.com Copyright 2006 por Brasport Livros e Multimídia Ltda. Todos os direitos reservados. Nenhum a parte deste livro poderá ser reproduzida, sob qualquer meio, especial- m ente em fotocópia (xerox), sem a permissão, por escrito, da Editora. 1ª edição: ª edição: Citado por 45 - Artigos relacionados Guia para o exam e oficial do PMI, RV VARGAS, CEM GERENCIAMENTO - Rio de Janeiro:, go.trf1.gov.br Page 1. GERENCIAMENTODE PROJETOS Autor: CLELAND, DAVID I. Autor: IRELAND, LEWIS R. Editora: LTC Nível: intermediário... GERENCIAMENTODE PROJETOS Autor: VARGAS, RICARDO VIANA Editora: BRASPORT Nível: básico... Citado por 45 - Artigos relacionados - Ver em HTML - Todas as 3 versões [LIVRO] Gestão de Projetos : as Melhores Práticas-2a Edição H Kerzner books.google.com Obra originalmente publicada sob o título Advanced Project Management: Best Practices on Implementation, 2/Edition 2004, John Wiley & Sons, Inc. Todos os direitos reservados. Tradução autorizada da edição em língua inglesa publicada por John Wiley & Sons, Inc. ISBN... Citado por Artigos relacionados [PDF] Gerência de Projetos [PDF] de unipar.br KR da Costa Marchi - kessia.blogs.unipar.br... serviços e produtos e estabelecendo a aceitação do gerenciamento de projetos como um a disciplina e uma profissão. Jos Carlos Cordeiro Martins Page abordagem diferenciada para o gerenciamento de projetos. Page 11. Gerência de Projeto em Engenharia de Software... Artigos relacionados - Ver em HTML - Todas as 2 versões [PDF] Gestão de projetos 156

157 [PDF] de usp.br S Melhado - silviobm.pcc.usp.br 1. Justificativas para escolha do tema 2. Projetos precisam de gestão! 3. Projeto no contexto do empreendimento 4. Projeto : o individual eo coletivo 5. Gestão do processo de projeto 6. Planejamento do processo de projeto 7. Projetos na interface com a obra 8. Projetos ea... Artigos relacionados - Ver em HTML - Todas as 3 versões [PDF] Gerenciamento do Projeto [PDF] de oecd.org O PARANÁ - oecd.org Este trabalho foi iniciado em meados de 2005 tendo como objetivo especifico avaliar o impacto socioeconômico das instituições de ensino superior do estado do Paraná pertencentes ao governo do Estado. O objetivo geral era buscar subsídios para a elaboração da política de... Ver em HTML - Todas as 3 versões [DOC] GESTÃO DE PROJETOS [DOC]de advogado.adv.br MM da Silva - advogado.adv.br Num a árvore madura, um corte aqui ou um galho arrancado ali são de pouca ou nenhuma conseqüência. Porém, o menor arranhão na semente, as mais leves marcas no broto, resultam em deformidade irrevogável numa falha que as décadas por vir aprofundarão ao invés... Artigos relacionados - Ver em HTML [PDF] GESTÃO DE PROJETOS [PDF] de usp.br FDEA GALDINO - ead.fea.usp.br O objetivo deste artigo é estabelecer uma associação entre a teoria descrita por Chester Barnard com as definições existentes sobre projetos e gerenciamento de projeto elaboradas por diversos autores de importância destacada na área. Várias definições existem sobre projeto.... Artigos relacionados - Ver em HTML [LIVRO] Gerência de Projetos DG BRUZZI - books.google.com Há alguns anos, empresas têm usado esta nova metodologia na condução de seus negócios. Diretores, gerentes e funcionários se valem de todo tipo de ferramenta, e : de... Citado por 1 - Artigos relacionados [DOC] GESTÃO DE PROJETOS [DOC]de vbsi.com.br R Humanos, OP de Recursos Humanos - vbsi.com.br Um dos profissionais mais importantes em uma empresa é um analista de Recursos Hum anos, pois é ele que por muitas das vezes percebe as complicações, deficiências e problemas que estão acontecendo no ambiente interno da empresa e 157

158 por muitas vezes também as... Artigos relacionados - Ver em HTML - Todas as 2 versões PDF] An lise de Maturidade no Gerenciamento de Projetos de Tecnologia de Automação RUYC DE BARROS - adm.ufba.br... capítulo mostra o modelo teórico de referência de gerenciamento de projetos, extraído do Project Management Book Of Knowledge... Citado por 4 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [PDF] O uso da extranet na coordena ão de projetos : aplicação em estudo de caso RB PICORAL, RS SOLANO - WORKSHOP NACIONAL: gestão do processo de projeto na, lem.ep.usp.br... O uso de extranets no gerenciamento de projetos : o exemplo... alteração do desenho original lido porém, permitindo com base em uma referência externa criar... Citado por 7 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [PDF] SISTEMAS ERP: AN LISE DA INFLU NCIA DE FATORES E APLICAÇÃO DE TÉCNICAS DE GERENCIAMENTO DE PROJETOS TCC Padilha, AFB Costa, JL Contador, FAS Marins - SciELO Brasil... Referências Bibliográficas. CAMPOS, VF Gerenciamento pela rotina do trabalho do dia-a... CONTADOR, JL Algoritm o do corte mínimo para aceleração de projetos.... Citado por 3 - Artigos relacionados - Em cache - Pesquisa na web - Todas as 3 versões [CITAÇÃO] Gerência de Projetos de Sistemas: Uma Abordagem Prática. 2a. Edição. LTCLivros Téc nicos e AA FERNANDES, JLC KUGLER - Links Citado por 2 - Artigos relacionados - Pesquisa na web [LIVRO] Manual Prático do Plano de Projetos R Vargas - books.google.com... Possui oito livros publicados sobre gerenciamento de projetos, um DVD, além de publicações no Brasil e nos Estados Unidos, com mais de 75 mil livros vendidos... Citado por 8 - Artigos relacionados - Pesquisa na web [LIVRO] Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML JCC Martins - books.google.com... para catálogo sistemático: 1. Software : Desenvolvimento : Projetos : Gerenciamento : 158

159 Ciência da computação BRASPORT Livros e Multimídia Ltda.... Citado por 8 - Artigos relacionados - Pesquisa na web [PDF] Qualidade de software: vis es de produto e processo de software AN Tsukumo, CM Rêgo, CF Salviano, GF Azevedo, LK prodepa.psi.br... tratada pelo modelo de referência SPICE (Software... repetir sucessos anteriores em projetos de aplicação... Gerenciamento de requisitos Planejamento de projeto... Citado por 10 - Artigos relacionados - Pesquisa na web - Todas as 4 versões [PDF] GERENCIAM ENTO, AVALIAÇÃO E QUANTIFICAÇÃO DO RISCO DE PROJETOS AA de Souza, A Ligo, RW Moya - ead.fea.usp.br... identificação e gerenciamento do risco... prevê ações corretivas e utiliza como referência o modelo... fontes de risco e procedimentos dos projetos de inovação... Citado por 3 - Artigos relacionados - Pesquisa na web [PDF] Modelo de Referência e M todo de Avaliação para Melhoria de Processo de Software-versão 1.0 (MR- MPS KC Weber, E Ara jo, CAF Machado, D Scalet, CF - Anais do IV Simpósio Brasileiro de Qualidade de Software (, golden.softex.br... definições com uns eo detalhamento do Modelo de Referência para Melhoria... Organizacional AMP, Adaptação do Processo para Gerência de Projeto - APG... Citado por 6 - Artigos relacionados - Pesquisa na web - Todas as 3 versões [PDF] OS DIFERENTES CONCEITOS ADOTADOS ENTRE GER NCIA, COORDENA ÃO E COMPATIBILIZA ÃO DE PROJETO NA RC FERREIRA - do WORKSHOP NACIONAL GESTÃO DO PROCESSO DE PROJETO NA, lem.ep.usp.br... Em última instância, temos necessidade de ferramentas ágeis e operadores hábeis. REFERÊNCIAS BIBLIOGRÁFICAS... Gerência de Programas e Projetos. PDF] Um a Proposta para Implanta ão do SIG na Cidade de Londrina ONF Barros, MVF Barros, JH Caviglione - Geografia - uel.br... a Estrutura do Marco de Referência demonstrando uma... PARA O SIG LONDRINA Otimizar o gerenciamento administrativo do... de seus programas e projetos específicos.... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 3 versões [PDF] Aplicando o cen rio de desenvolvim ento de produtos em um caso prático de capacitação profissional A MUNDIM, H Rozenfeld, DC Amaral, SL da Silva, LC - Gestão & Produção, beta.bibvirt.futuro.usp.br 159

160 ... e testar, presentes nas atividades de projeto, essas etapas... o PDP é o desafio de gerenciar as incertezas... construindo, enfim, um modelo de referência (Figura 1... Citado por 9 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [PDF] Modelo de gestão dos recursos florestais na Am azônia atrav s da utiliza ão de Sensoriamento Remoto e ALB Longhi, PR Meneses, MAL Pucci, MG de - Simpósio Brasileiro de Sensoriam ento Remoto (SBSR), marte.dpi.inpe.br... 3 Main - Gerenciamento de Informações Ltda SCS Qd 7 - Torre A - Sala... e imagens do satélite LandSat fornecidas pelo Projeto Prodes Digital... Referências... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Gerenciamento dos riscos de incendios D Duarte, MS Leite, R Pontes - XVIII Encontro Nacional de Engenharia de Producao e IV, abepro.org.br... Dentro deste contexto, o gerenciamento dos riscos (vide Figura 1) é uma tentativa de m inimizar... REFERÊNCIAS... =Projeto e execução de obras de concreto armado... Citado por 3 - Ver em HTML - Pesquisa na web [PDF] M tricas de Software: Um Mapeamento entre Six Sigma e CMMI P Donegan, L Bandeira, M Sampaio, CG Pires, AD ). simpros. com. br - banasqualidade.com.br... de Software, com o objetivo de orientar a implantação eo gerenciamento de métricas, servindo com o referência para gerentes de projetos, analistas de... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões PDF] Um Plano Pedagógico de Referência para Cursos de Engenharia de Com putação CAC Teix eira, JSB Martins, AF do Prado, OM Junior, - Sociedade Brasileira de Com putação, sbc. org., jsmnet.com... disciplina, seus objetivos, requisitos, livros textos e... Projeto, Desenvolvimento e Implantação de Sistemas... Gerenciamento de Configuração e Engenharia de... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [DOC] PLANO DE ENSINO Uma Rede, M de Gerenciamento, ISO Terminologia, F - inf.unifra.br... O Modelo de Referencia OSI. O Modelo de Referencia TCP/IP.... Requisitos de um Projeto de Rede. Metas de Gerenciamento. Terminologia ISO para Gerenciamento de Redes... Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões 160

161 [PDF] Contribui es da Melhoria de Processo e Gerência de Projetos : Transformando Boas Id ias em CF Salviano - bfpug.com.br... O nível 2, que é a primeira referência a ser buscada das empresas, é focado exatam ente no estabelecimento de uma gerência de projetos.... [CITAÇÃO] Referências Bibliográficas _ 134 Apêndice A Requisitos _ 140 Apêndice B D Apêndice, MP de Artigos relacionados - Pesquisa na web Modelo de Documento de [PDF] Um modelo para o gerenciamento de múltiplos projetos de software aderente ao CMMI C de Informática - cin.ufpe.br... Muito tem sido feito e estudado em busca de uma área e disciplina de gerência de projetos consolidada e bem entendida. Os cursos e livros-texto em Engenharia... [PDF] Gestão de Projetos de Pesquisa e Desenvolvimento no âmbito da Cooperação Escola-Empresa IA de Lima, HG de Carvalho, JL Kovaleski - anpad.org.br ) talvez a maior dificuldade do gerenciamento da P&D... o processo de gestão de projetos no âmbito... um caso específico que se considera referência ou ideal... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Uma Metodologia para Teste de Software no Contexto da Melhoria de Processo AN Crespo, OJ da Silva, CA Borges, CF Salviano, M - Simpósio Brasileiro de Qualidade de Software, amplaconsultoria.com.br... ISO/IEC 1998] como referência e duas metodologias para dois processos específicos: a metodologia baseada no ProGer para o processo de gerência de projeto e a... Citado por 4 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [PDF] An lise da implementa ão de um gate system em uma ind stria fornecedora do setor autom otivo SG VALERI, LGS Martini, AL Serpa, MAN Diniz, H - 2º Congresso Brasileiro de Gestão de Desenvolvimento de, numa.org.br... Verificou-se que o sucesso do gerenciamento de um... Na maioria dos casos, o time de projeto pode apresentar... estão representadas no modelo de referência abaixo:... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web 161

162 [PDF] Uma experiência de capacita ão e iníc io de melhoria de processo de software com o método PRO2PI-WORK F de Petri, J Rodrigueiro, L Mapelli, VL Oliveira, - Anais do SIMPROS, simpros.com.br... No trabalho realizado foi utilizado como referência o modelo MR-MPS.... alinhados com as metas da empresa: GPR Gerência de Projetos ; GRE Gerência de... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] SUCESSOSW= CMM2+ PMBOK J Neto, F Bocoli - PMI Journal, Publicação da Seção do PMI-RS, pmirs.org.br... visa promover e ampliar o conhecimento existente sobre gerenciamento de projetos, assim com o... e solidificou-se como o fórum de referência dos profissionais... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [CITAÇÃO] ANÁLISE E PROPOSTA DE FORMAS DE GERENCIAMENTO DE ESTAÇÕES DE TRATAMENTO DE GUAS DE ABASTECIMENTO MPS PARSEKIAN Universidade de São Paulo Citado por 1 - Artigos relacionados - Pesquisa na web [PDF] ENGENHARIA CLÍNICA EA METROLOGIA EM EQUIPAMENTOS ELETROMÉDICOS MV Lucatelli, MMB Batista, HP da Silva, R Garcia - Anais do Congresso de Metrologia para a Vida, Recife, PE, hp.br.inter.net... [2] WB Beskow, Sistema de Informação para o Gerenciamento de Tecnologia Médico Hospitalar... [10] ANVISA, Termos de Referência Projeto Hospitais Sentinela.... Citado por 2 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [HTML] Avalia ão de estrat gias de gestão de ciência e te cnologia: um estudo de caso JCR PEREIRA, SG SAES - Rev. Saúde Pública, SciELO Public Health... se instrumento invariavelmente aplicado à gerência de projetos... ou de concepção do projeto, que deve... posters, slides, audiovisuais, manuais, livros, e outras... Citado por 8 - Artigos relacionados - Em cache - Pesquisa na web - Todas as 5 versões [PDF] WebAPSEE: Um Ambiente Livre e Flexível Para Gerência de Processos de Software 162

163 A Lima, B Fran a, H Schlebbe, M Silva, RQ Reis, - 7º Fórum Internacional de Software Livre-VII Workshop de, labes.ufpa.br... chegando ao sistema de gerenciamento de banco... processo de software utilizado no projeto NetBeans... artefatos (denominação genérica para referências de itens... Citado por 3 - Artigos relacionados - Ver em HTML - Pesquisa na web [CITAÇÃO] O PAPEL DAS INTERFACES NO SUCESSO DE UTILIZANDO EQUIPES VIRTUAIS LN Hassegawa Universidade de São Paulo PROJETOS [PDF] A IMPORT NCIA DA CARTOGRAFIA PARA O SUCESSO DA IMPLANTAÇÃO DO GEOPROCESSAMENTO NO MUNICÍPIO DE BELO TEPP DA SILVA, MV OTTONI, GDEI Urbanas-GIU - pbh.gov.br... São eles: Plantas de Referencia Cadastral - jogo... e cadastral, quando o gerenciamento das bases... importância para implantação de projetos urbanos, dentre... Citado por 2 - Artigos relacionados - Pesquisa na web - Todas as 2 versões [PDF] Uma Grade Com putacional Nacional baseada em Servi os B Schulze - arquivosweb.lncc.br... Page 4. 4 Projeto Grade SINAPAD RNP Internet(2)... Cria ão (Factory) Nomes Globais (GSH) & referências (GSR) Gerência de Ciclo de Vida... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [CITAÇÃO] PRODUTIVIDADE DA MÃO-DE-OBRA EM ESTRUTURAS JAE LOPES - São Paulo, 2001 Citado por 4 - Artigos relacionados - Pesquisa na web PROJETOS DE [PDF] Definindo, Implantando e Melhorando Processos de Software em Ambiente Acadêmico DMB Paiva, AP Freire, R Sanches, RPM Fortes - VI Simposio Internacional de Melhoria de Processo de, simpros.com.br... dos artefatos e facilitaram o aprendizado dos projetos.... a colaborar com as atividades de gerenciamento de conhecimento... e artigos técnicos, slides, livros, etc... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões Lideran a e influência nas fases d [PDF] a gestão de projetos RDEFSM Russo, JM Ruiz - Revista Produção, SciELO Brasil 163

164 ... do projeto, que avalia o grau de eficiência na gerência do projeto, analisando se... Dimensão 2: Impacto no cliente, tendo como referência a atenção... Citado por 3 - Artigos relacionados - Em cache - Pesquisa na web - Todas as 2 versões [PDF] e da Configura ão em um Ambiente Integrado para Apoio ao Desenvolvimento e Gestão de Projetos de M Abdala, C Lahoz, N SantAnna hermes2.dpi.inpe.br... todos os processos da garantia da qualidade e do gerenciamento da configuração Referências... para apoio ao desenvolvimento e gestão de projetos de software... Citado por 1 - Ver em HTML - Pesquisa na web PDF] M todo E Modelo DE Avalia ão PARA Melhoria DE Processos DE Software EM Micro E Pequenas Empresas A Anacleto, CG von Wangenheim - inf.ufsc.br... por um subconjunto dos processos descritos no modelo de referência da ISO... melhorados são SPL.1 Proposta do Fornecedor, MAN.3 Gerência de Projetos, MAN.5... Citado por 3 - Artigos relacionados - Pesquisa na web - Todas as 2 versões [CITAÇÃO] Gerenciamento de conhecimentos explícitos sobre o processo de desenvolvimento de produto DC AMARAL, H ROZENFELD - Florianópolis Congresso Brasileiro de Gestão do, 2001 Citado por 4 - Artigos relacionados - Pesquisa na web SC: III [CITAÇÃO] Desenvolvimento de Com petências da Equipe de Implem entação de Sistemas de Informação A CIDRAL, AF Abreu - Manuscrito do trabalho suportado pela FAPESP sob o no. BS Citado por 1 - Artigos relacionados - Pesquisa na web [PDF] Aplica ão do m todo SCAMPI pa ra avaliação do processo e gerenciamento de projetos de software numa A Itaborahy, E Radis, E Longhi, R Figueiredo, KM simpros.com.br... cobrir os gaps identificados e consolidar os processos de gerenciamento de projetos na área... A adoção do CMMI como modelo de referência para melhoria de... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Projeto de Sistemas para Gerência de Redes Utilizando Constru es Pr - definidas e Biblioteca C Maciel, MS Notare, EM Furlanetto, BG Andriso ic.uff.br 164

165 ... de implementação ou de realização do sistema) permite obter a implementação de referência mais completa. 4. Projeto de um Sistema de Gerência Proativa... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [CITAÇÃO] Metodologia de Gerenciamento de Projetos do Segmento de E&P da Petrobras WGR da Silva Citado por 1 - Artigos relacionados - Pesquisa na web [LIVRO] PROJETO E ARQUITETURA DE REDES JF DIMARZIO Citado por 2 - Artigos relacionados - Pesquisa na web [PDF] Processo de Aquisi ão de Produtos e Servi os de Software para uma Instituição Bancária MP de Sousa, VT de Olive ira S ndi, KM de Oliveira - simpros.com.br... estratégia de aquisições, onde faça referência aos objetivos... Plano de Gerenciamento de Aquisições: Documento de... todas as fases do projeto de aquisição... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Implantando um Programa de Melhoria de Processo: Uma Experiência Prática EP Alves, RA Falbo - VIII Workshop de Qualidade de Software, XV Simpósio, inf.ufes.br... modelos, para permitir a utilização destes como referência complem entar, principalmente nos... a com o sistemática de gerenciamento de projetos da VixTeam... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Com rcio Eletrônico: Uma An lise da Aplicabilidade de Modelos de Qualidade de Software LAF Gom es, ML Côrtes - Anais do I Simpósio Brasileiro de qualidade de software., lbd.dcc.ufmg.br... sobre o modelo, consultar as referências [11] e... segundo o próprio SEI, em projetos de software... implementando deverão orientar o gerenciamento dos processos. Administração de projetos : como transformar idéias em resultados ACA Maximiano - São Paulo - bases.bireme.br... Trata dos problemas do projeto dentro de uma organização focalizando a... Responsável: BR CIR - Biblioteca - Centro de Informação e Referência.... Citado por 98 - Artigos relacionados - Em cache - Pesquisa na web Gerência de Projetos uma reflexão histórica MMB CODAS - Revista de Administração de Empresas (RAE), rae.br 165

166 ... constitui um documento básico de referência.13 Paralelamente com o desenvolvimento do gerencia - mento na... tes sobre a implantação de projetos com qualidade... Citado por 7 - Artigos relacionados - Pesquisa na web [LIVRO] Gerenciamento da qualidade total TQM J Oakland books.google.com... gerenciam ento do desempenho Análise do projeto departamental deste livro em 1988, havia muito poucos livros sobre Gerenciamento da Qualidade... Citado por Artigos relacionados - Pesquisa na web - Todas as 2 versões [PDF] lgebra linear S Lipschutz unc.br... Metodologia para análise e projeto de banco de... Aspectos operacionais de gerência de banco de da-... Referências Bibliográficas: Barbieri, Carlos, Modelagem e... Citado por 75 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 2 versões [LIVRO] Capacitação em gerenciamento de projetos guia de referência didática M Possi Brasport Citado por 5 - Artigos relacionados - Pesquisa na web [LIVRO] Gerência de projetos guia para o exame oficial do PMI K Heldman Campus Citado por 16 - Artigos relacionados - Pesquisa na web Análise Estruturada Moderna E YOURDON - Rio de Janeiro: Campus, orton.catie.ac.cr... 1 / 1 Seleccione referencia / Select reference.... modelos%ferramentas adicionais de modelagem%ferramentas de modelagem para gerenciamento de projetos %o modelo... Citado por Artigos relacionados - Em cache - Pesquisa na web [CITAÇÃO] Gerência de projetos de sistemas: uma abordagem prática AA FERNANDES, JLC KUGLER - Rio de Janeiro, LTC-Livros Técnicos e Científicos, 1989 Citado por 8 - Artigos relacionados - Pesquisa na web [PDF] MuNDDoS -Um Modelo de Referência para Desenvolvimento Distribuído de Software R Prikladnicki, JLN Audy - XVIII Simpósio Brasileiro de Engenharia de Software lbd.dcc.ufmg.br... de referência proposto neste estudo. A seguir apresentam-se as lições identificadas, que estão detalhadas em [16]. Lição 1: A gerência de projetos ea [PDF] Uso de t cnica de line of balance repetividade estudo de caso: -LOB-em empreendimentos com grande 166

167 G BLAK, L SÉLLOS, EL QUALHARINI - ENCONTRO NACIONAL DE ENGENHARIA DE PRODUÇÃO, abepro.org.br... VARGAS, RV - Gerenciamento de Projetos com o MS Project 98: Estratégia, Planejamento e Controle - Braspost Livros, Rio de Janeiro, RJ, Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] EM PORTO ALEGRE: UMA FERRAMENTA AUXILIAR PARA A ANÁLISE CRITICA DE PROJETOS E AVALIA ÃO EXPEDITA DE RS SOLANO, LFM HEINECK - eesc.sc.usp.br... científica e normativa citada nas referências bibliográficas deste... que não facilitam o gerenciamento da produção.... aos dados extraídos dos projetos e dos... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 4 versões [PDF] GED COMO FERRAMENTA NA GER NCIA DO CONHECIMENTO EXPLÍCITO ORGANIZACIONAL JA RIOS - CINFORM-ENCONTRO NACIONAL DE CIÊNCIA DA INFORMAÇÃO, cinform.ufba.br... o aprendizado foi explicitado em livros e os... por iniciar esta jornada com os projetos de gerência... ferramentas e conceitos de GED ( Gerenciamento Eletrônico de... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web - Todas as 3 versões [PDF] EduQNet: Um Modelo de Qualidade de Processo para Curso s a Distância Mediados pela Internet FJC Rapchan, D Cury, C Menezes, R de Almeida Falbo inf.ufes.br... Am ericanos tais como os padrões de referência da IHEP... consenso na literatura de que a gerência é um dos aspectos mais críticos dos projetos de software... PDF] M todo E Modelo DE Avalia ão PARA Melhoria DE Processos DE Software EM Micro E Pequenas Empresas A Anacleto, CG von Wangenheim - inf.ufsc.br... por um subconjunto dos processos descritos no modelo de referência da ISO... melhorados são SPL.1 Proposta do Fornecedor, MAN.3 Gerência de Projetos, MAN.5... Citado por 3 - Artigos relacionados - Pesquisa na web - Todas as 2 versões [CITAÇÃO] Gerenciamento de conhecimentos explícitos sobre o processo de desenvolvimento de produto DC AMARAL, H ROZENFELD - Florianópolis SC: III Congresso Brasileiro de Gestão do, 2001 Citado por 4 - Artigos relacionados - Pesquisa na web [CITAÇÃO] Desenvolvimento de Com petências da Equipe de Implem entação de Sistemas de Informação 167

168 A CIDRAL, AF Abreu - Manuscrito do trabalho suportado pela FAPESP sob o no. BS Citado por 1 - Artigos relacionados - Pesquisa na web [PDF] Aplica ão do m todo SCAMPI para avalia ão do processo e gerenciamento de projetos de software numa A Itaborahy, E Radis, E Longhi, R F igueiredo, KM simpros.com.br... cobrir os gaps identificados e consolidar os processos de gerenciamento de projetos na área... A adoção do CMMI como modelo de referência para melhoria de... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web Projeto de Sistemas para Gerência de Redes Utilizando Constru es Pr [PDF] - definidas e Biblioteca C Maciel, MS Notare, EM Furlanetto, BG Andriso ic.uff.br... de implementação ou de realização do sistema) permite obter a implementação de referência mais completa. 4. Projeto de um Sistema de Gerência Proativa... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [CITAÇÃO] Metodologia de Gerenciamento de Projetos do Segmento de E&P da Petrobras WGR da Silva Citado por 1 - Artigos relacionados - Pesquisa na web [LIVRO] PROJETO E ARQUITETURA DE REDES JF DIMARZIO Citado por 2 - Artigos relacionados - Pesquisa na web [PDF] Processo de Aquisi ão de Produtos e Servi os de Software para uma Instituição Bancária MP d e Sousa, VT de Oliveira S ndi, KM de Oliveira - simpros.com.br... estratégia de aquisições, onde faça referência aos objetivos... Plano de Gerenciamento de Aquisições: Documento de... todas as fases do projeto de aquisição... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Implantando um Programa de Melhoria de Processo: Uma Experiência Prática EP Alves, RA Falbo - VIII Workshop de Qualidade de Software, XV Simpósio, inf.ufes.br... modelos, para permitir a utilização destes como referência complem entar, principalmente nos... a com o sistemática de gerenciamento de projetos da VixTeam... Citado por 1 - Artigos relacionados - Ver em HTML - Pesquisa na web [PDF] Com rcio Eletrônico: Uma An lise da Aplicabilidade d e Modelos de Qualidade de Software LAF Gom es, ML Côrtes - Anais do I Simpósio Brasileiro de qualidade de software., lbd.dcc.ufmg.br... sobre o modelo, consultar as referências [11] e... segundo o próprio SEI, em projetos. 168

169 ORIENTAÇÕES PARA BUSCA DE ARTIGOS CIENTÍFICOS NO SCIELO Após a escolha do tema do TCC, pertinente ao seu curso de Pós-graduação, você deverá fazer a busca por artigos científicos da área, em sites especializados, para a redação do seu próprio artigo científico. O suporte bibliográfico se faz necessário porque toda informação fornecida no seu artigo deverá ser retirada de outras obras já publicadas anteriormente. Para isso, deve-se observar os tipos de citações (indiretas e diretas) descritas nesta apostila e a maneira como elas devem ser indicadas no seu texto. Lembre-se que os artigos que devem ser consultados são artigos científicos, publicados em revistas científicas. Sendo assim, as consultas em revistas de ampla circulação (compradas em bancas) não são permitidas, mesmo se ela estiver relatando resultados de estudos publicados como artigos científicos sobre aquele assunto. Revistas como: Veja, Isto é, Época, etc., são meios de comunicação jornalísticos e não científicos. Os artigos científicos são publicados em revistas que circulam apenas no meio acadêmico (Instituições de Ensino Superior). Essas revistas são denominadas periódicos. Cada periódico têm sua circulação própria, isto é, alguns são publicados impressos mensalmente, outros trimestralm ente e assim por diante. Alguns periódicos também podem ser encontrados facilmente na internet e os artigos neles contidos estão disponíveis para consulta e/ou download. Os principais sites de buscas por artigos são, entre outros: SciELO: Periódicos Capes: Bireme: PubMed: A seguir, temos um exemplo de busca por artigos no site do SciELO. Lembrando que em todos os sites, embora eles sejam diferentes, o método de busca não difere muito. Deve-se ter em mente o assunto e as palavras-chave que o levarão à procura pelos artigos. Bons estudos! 169

170 Siga os passos indicados: Para iniciar sua pesquisa, digite o site do SciELO no campo endereço da internet e, depois de aberta a página, observe os principais pontos de pesquisa: por artigos; por periódicos e periódicos por assunto (marcações em círculo). Ao optar pela pesquisa por artigos, no campo método (indicado abaixo), escolha se a busca será feita por palavra-chave, por palavras próximas à forma que você escreveu, pelo site Google Acadêmico ou por relevância das palavras. 170

171 Em seguida, deve-se escolher onde será feita a procura e quais as palavras- chave deverão ser procuradas, de acordo com assunto do seu TCC (não utilizar e, ou, de, a, pois ele procurar por estas palavras tamb m). Clicar em pesquisar. 171

172 Lembre-se de que as palavras-chave dirigirão a pesquisa, portanto, escolhaas com atenção. Várias podem ser testadas. Quanto mais próxim as ao tema escolhido, mais refinada será sua busca. Por exemplo, se o tem a escolhido for relacionado à degradação ambiental na cidade de Ipatinga, as palavras-chave 172

173 poderiam ser: degradação; ambiental; Ipatinga. Ou algo mais detalhado. Se nada aparecer, tente outras palavras. Isso feito, uma nova página aparecerá, com os resultados da pesquisa para aquelas palavras que você forneceu. Observe o número de referências às palavras fornecidas e o número de páginas em que elas se encontram (indicado abaixo). A seguir, estará a lista com os títulos dos artigos encontrados, onde constam: nome dos autores (Sobrenome, nome), título, nome do periódico, ano de publicação, volume, número, páginas e núm ero de indexação. Logo abaixo, têm-se as opções de visualização do resumo do artigo em português/inglês e do artigo na íntegra, em português. Avalie os títulos e leia o resum o primeiro, para ver se vale à pena ler todo o artigo. 173

174 Ao abrir o resumo, tem-se o nome dos autores bem evidente, no início da página (indicado abaixo). No final, tem-se, ainda, a opção de obter o arquivo do artigo em PDF, que é um tipo de arquivo compactado e, por isso, mais leve, Caso queria, você pode fazer download e salvá-lo em seu computador. 174

175 175

Os escritórios de projetos como indutores de maturidade em gestão de projetos

Os escritórios de projetos como indutores de maturidade em gestão de projetos Os escritórios de projetos como indutores de maturidade em gestão de projetos Ivete Rodrigues Roque Rabechini Júnior João Mário Csillag RESUMO Como decorrência da importância que os projetos vêm ganhando

Leia mais

Carlos Henrique Santos da Silva

Carlos Henrique Santos da Silva GOVERNANÇA DE TI Carlos Henrique Santos da Silva Mestre em Informática em Sistemas de Informação UFRJ/IM Certificado em Project Management Professional (PMP) PMI Certificado em IT Services Management ITIL

Leia mais

PMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE

PMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE ESTUDO DE BENCHMARKING EM GERENCIAMENTO DE PROJETOS 2009 Brasil Uma realização dos Chapters Brasileiros do PMI - Project Management Institute PMI-SP PMI-RJ PMI-AM PMI-SC PMI-BA ANEXO 1 PMI-RS PMI PMI-CE

Leia mais

PMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE

PMI-SP PMI-SC PMI-RS PMI PMI-PR PMI-PE ESTUDO DE BENCHMARKING EM GERENCIAMENTO DE PROJETOS 2009 Brasil Uma realização dos Chapters Brasileiros do PMI - Project Management Institute PMI-SP PMI-RJ PMI-AM PMI-SC PMI-BA ANEXO 2 PMI-RS PMI PMI-CE

Leia mais

CARACTERÍSTICAS DE UM PROJETO

CARACTERÍSTICAS DE UM PROJETO CARACTERÍSTICAS DE UM PROJETO Temporário: significa que cada projeto tem um início e um fim muito bem definidos. Um projeto é fundamentalmente diferente: porque ele termina quando seus objetivos propostos

Leia mais

A estrutura do gerenciamento de projetos

A estrutura do gerenciamento de projetos A estrutura do gerenciamento de projetos Introdução O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK ) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é

Leia mais

Gerência de Projetos de Software CMM & PMBOK

Gerência de Projetos de Software CMM & PMBOK Gerência de Projetos de Software CMM & PMBOK http://www.sei.cmu.edu/ Prefácio do CMM Após várias décadas de promessas não cumpridas sobre ganhos de produtividade e qualidade na aplicação de novas metodologias

Leia mais

Trilhas Técnicas SBSI - 2014

Trilhas Técnicas SBSI - 2014 brunoronha@gmail.com, germanofenner@gmail.com, albertosampaio@ufc.br Brito (2012), os escritórios de gerenciamento de projetos são importantes para o fomento de mudanças, bem como para a melhoria da eficiência

Leia mais

2. Gerenciamento de projetos

2. Gerenciamento de projetos 2. Gerenciamento de projetos Este capítulo contém conceitos e definições gerais sobre gerenciamento de projetos, assim como as principais características e funções relevantes reconhecidas como úteis em

Leia mais

Projetos (PMO) : Oportunidades de Sinergia

Projetos (PMO) : Oportunidades de Sinergia Escritórios de Processos (BPM Office) e de Projetos (PMO) : Oportunidades de Sinergia Introdução...2 Uniformizando o entendimento dos conceitos... 4 Entendendo as principais similaridades... 5 Entendendo

Leia mais

MASTER IN PROJECT MANAGEMENT

MASTER IN PROJECT MANAGEMENT MASTER IN PROJECT MANAGEMENT PROJETOS E COMUNICAÇÃO PROF. RICARDO SCHWACH MBA, PMP, COBIT, ITIL Atividade 1 Que modelos em gestão de projetos estão sendo adotados como referência nas organizações? Como

Leia mais

Pesquisa realizada com os participantes do 12º Seminário Nacional de Gestão de Projetos. Apresentação

Pesquisa realizada com os participantes do 12º Seminário Nacional de Gestão de Projetos. Apresentação Pesquisa realizada com os participantes do de Apresentação O perfil do profissional de Projetos Pesquisa realizada durante o 12 Seminário Nacional de, ocorrido em 2009, traça um importante perfil do profissional

Leia mais

ESCRITÓRIO RIO DE PROJETOS

ESCRITÓRIO RIO DE PROJETOS PMO PROJETOS PROCESSOS MELHORIA CONTÍNUA PMI SCRUM COBIT ITIL LEAN SIX SIGMA BSC ESCRITÓRIO RIO DE PROJETOS DESAFIOS CULTURAIS PARA IMPLANTAÇÃO DANIEL AQUERE DE OLIVEIRA, PMP, MBA daniel.aquere@pmpartner.com.br

Leia mais

Oficina de Gestão de Portifólio

Oficina de Gestão de Portifólio Oficina de Gestão de Portifólio Alinhando ESTRATÉGIAS com PROJETOS através da GESTÃO DE PORTFÓLIO Gestão de portfólio de projetos pode ser definida como a arte e a ciência de aplicar um conjunto de conhecimentos,

Leia mais

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

Questionário de Avaliação de Maturidadade MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Gerenciamento de Programas e Projetos nas Organizações" 4ª Edição (a ser lançada) Autor: Darci Prado Editora INDG-Tecs - 1999-2006

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos Em conformidade com a metodologia PMI 1 Apresentações Paulo César Mei, MBA, PMP Especialista em planejamento, gestão e controle de projetos e portfólios, sempre aplicando as melhores

Leia mais

Gerência de projetos: arte ou disciplina? By André Barcaui, MsC, PMP is a consultant and management coach, Brazil. bbbrothers@bbbrothers.com.

Gerência de projetos: arte ou disciplina? By André Barcaui, MsC, PMP is a consultant and management coach, Brazil. bbbrothers@bbbrothers.com. Gerência de projetos: arte ou disciplina? By André Barcaui, MsC, PMP is a consultant and management coach, Brazil bbbrothers@bbbrothers.com.br O equilíbrio necessário para se tornar um excelente gerente

Leia mais

Proposta de Papéis e Atribuições para o Escritório de Projetos

Proposta de Papéis e Atribuições para o Escritório de Projetos Proposta de Papéis e Atribuições para o Escritório de Projetos SERVIÇO SOCIAL DA INDÚSTRIA DEPARTAMENTO NACIONAL CONTRATO Nº 9225/2007 Outubro 2007 SUMÁRIO APRESENTAÇÃO...3 1 CONTEXTUALIZAÇÃO DE ESCRITÓRIO

Leia mais

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP

Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP DARCI PRADO Questionário de Avaliação de Maturidade Setorial: Modelo de Maturidade Prado-MMGP Versão 2.0.0 Janeiro 2014 Extraído do Livro "Maturidade em Gerenciamento de Projetos" 3ª Edição (a publicar)

Leia mais

QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE

QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE MMGP Darci Prado QUESTIONÁRIO DE AVALIAÇÃO DE MATURIDADE Extraído do Livro "Maturidade em Gerenciamento de Projetos" - 1ª Edição Versão do Modelo 1..0-01/Fev/008 - Editora INDG-Tecs - 008 WWW.MATURITYRESEARCH.COM

Leia mais

PMONow! Serviço de Implantação de um Escritório de Projetos

PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos PMONow! Serviço de Implantação de um Escritório de Projetos As organizações em torno do mundo estão implantando processos e disciplinas formais

Leia mais

CURSOS GERENCIAIS 20/12/2010 Antonio Roberto Grazzia, MBA, PMP

CURSOS GERENCIAIS 20/12/2010 Antonio Roberto Grazzia, MBA, PMP CURSOS GERENCIAIS 20/12/2010 Antonio Roberto Grazzia, MBA, PMP Em um ambiente de negócios competitivo, a condução de projetos de forma eficiente e sem desperdícios é um grande diferencial para o sucesso.

Leia mais

Gestão de Portfólio Práticas e Competências Necessárias

Gestão de Portfólio Práticas e Competências Necessárias Gestão de Portfólio Práticas e Competências Necessárias Margareth Carneiro, PMP, MSc PMI GovSIG past-chair PMA Diretora Executiva Wander Cleber da Silva, PhD Fundação Funiversa 1 O Guia do PMBoK O Guia

Leia mais

IV Seminário Internacional. Maturidade em Gerenciamento de Projetos. Como Medir o Nível de Maturidade em GP de uma Empresa

IV Seminário Internacional. Maturidade em Gerenciamento de Projetos. Como Medir o Nível de Maturidade em GP de uma Empresa IV Seminário Internacional Maturidade em Gerenciamento de Projetos Como Medir o Nível de Maturidade em GP de uma Empresa Palestrante: Leon Herszon F.,MSc, PMP Leon Herszon F., MSc, PMP Diretor Executivo

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

Gerenciamento de Projetos Modulo I Conceitos Iniciais

Gerenciamento de Projetos Modulo I Conceitos Iniciais Gerenciamento de Projetos Modulo I Conceitos Iniciais Prof. Walter Cunha falecomigo@waltercunha.com http://waltercunha.com Bibliografia* Project Management Institute. Conjunto de Conhecimentos em Gerenciamento

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

Leia mais

Escritório de Gerenciamento de Projetos ( Project Management Office PMO)

Escritório de Gerenciamento de Projetos ( Project Management Office PMO) MBA em Gestão de Projetos Escritório de Gerenciamento de Projetos ( Project Management Office PMO) Flávio Feitosa Costa, MSc. PMP (flaviopmp@gmail.com) MBA em Gerência de Projetos Escritório de Gerenciamento

Leia mais

MBA ARQUITETURA DE INTERIORES

MBA ARQUITETURA DE INTERIORES MBA ARQUITETURA DE INTERIORES Coordenador: Carlos Russo Professor: Fábio Cavicchioli Netto, PMP 1 APRESENTAÇÃO DO PROFESSOR CONHECENDO OS PARTICIPANTES EXPECTATIVAS DO GRUPO 2 SUMÁRIO PMI / PMBoK / Certificados

Leia mais

DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1

DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1 DESENVOLVENDO A MATURIDADE EM GESTÃO DE PROJETOS NAS EMPRESAS ATRAVÉS DA IMPLANTAÇÃO DO PMO 1 Marcelo Campolina de Castro 2 Resumo Com o novo cenário econômico, muitas empresas estão investindo alto na

Leia mais

Pró-Reitoria de Pós-Graduação e Pesquisa MBA em Gerenciamento de Projetos Trabalho de Conclusão de Curso

Pró-Reitoria de Pós-Graduação e Pesquisa MBA em Gerenciamento de Projetos Trabalho de Conclusão de Curso Pró-Reitoria de Pós-Graduação e Pesquisa MBA em Gerenciamento de Projetos Trabalho de Conclusão de Curso ESCRITÓRIO DE GERENCIAMENTO DE PROJETOS: UM ESTUDO SOBRE A IMPORTÂNCIA E A ADEQUAÇÃO DE SUAS FUNÇÕES

Leia mais

PÓS - GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO MBA EM GERENCIAMENTO DE PROJETOS

PÓS - GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO MBA EM GERENCIAMENTO DE PROJETOS PÓS - GRADUAÇÃO LATO SENSU ESPECIALIZAÇÃO MBA EM GERENCIAMENTO DE PROJETOS 2014 1. COORDENAÇÃO ACADÊMICA Prof.º André Bittencourt do Valle 2. FUNDAÇÃO GETULIO VARGAS É uma instituição de direito privado,

Leia mais

PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS

PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS ISSN 1984-9354 PROPOSTA UNIFICADORA DE NÍVEIS DE MATURIDADE EM GERENCIAMENTO DE PROJETOS Debora Athayde Herkenhoff (Latec/UFF) Moacyr Amaral Domingues Figueiredo (Latec/UFF) Gilson Brito de Lima (UFF)

Leia mais

Lista de Exercícios - COBIT 5

Lista de Exercícios - COBIT 5 Lista de Exercícios - COBIT 5 1. O COBIT 5 possui: a) 3 volumes, 7 habilitadores, 5 princípios b) 3 volumes, 5 habilitadores, 7 princípios c) 5 volumes, 7 habilitadores, 5 princípios d) 5 volumes, 5 habilitadores,

Leia mais

Pesquisa sobre Iniciativas em BPM

Pesquisa sobre Iniciativas em BPM Pesquisa sobre Iniciativas em BPM Apresentação...2 1. Perfil dos Participantes da Pesquisa...3 2. Como as organizações estão adotando o BPM... 4 2.1. Como as organizações entendem o conceito de BPM?...

Leia mais

FORMAÇÃO DA CULTURA EM GESTÃO POR PROJETOS: O CASO DE UMA ORGANIZAÇÃO PRIVADA DE FINALIDADE PÚBLICA

FORMAÇÃO DA CULTURA EM GESTÃO POR PROJETOS: O CASO DE UMA ORGANIZAÇÃO PRIVADA DE FINALIDADE PÚBLICA FORMAÇÃO DA CULTURA EM GESTÃO POR PROJETOS: O CASO DE UMA ORGANIZAÇÃO PRIVADA DE FINALIDADE PÚBLICA Jorge Luciano Gil Kolotelo (UTFPR) kolotelo@uol.com.br Pedro Carlos Carmona Gallego (FESP) carmona@fesppr.br

Leia mais

MODELO DE EXCELÊNCIA EM GESTÃO (MEG), UMA VISÃO SISTÊMICA ORGANIZACIONAL

MODELO DE EXCELÊNCIA EM GESTÃO (MEG), UMA VISÃO SISTÊMICA ORGANIZACIONAL MODELO DE EXCELÊNCIA EM GESTÃO (MEG), UMA VISÃO SISTÊMICA ORGANIZACIONAL Alessandro Siqueira Tetznerl (1) : Engº. Civil - Pontifícia Universidade Católica de Campinas com pós-graduação em Gestão de Negócios

Leia mais

PLANO DE GERENCIAMENTO DA QUALIDADE - UMA PROPOSTA DE INSTRUMENTALIZAÇÃO EM GERENCIAMENTO DE PROJETOS

PLANO DE GERENCIAMENTO DA QUALIDADE - UMA PROPOSTA DE INSTRUMENTALIZAÇÃO EM GERENCIAMENTO DE PROJETOS ISSN 1984-9354 PLANO DE GERENCIAMENTO DA QUALIDADE - UMA PROPOSTA DE INSTRUMENTALIZAÇÃO EM GERENCIAMENTO DE PROJETOS Maíra Cecília Lewin (LATEC/UFF) Resumo Em uma organização certificada e projetizada,

Leia mais

PMO DE SUCESSO PRECISA TER FOCO! Uma proposta de modelo para Escritórios de Projetos

PMO DE SUCESSO PRECISA TER FOCO! Uma proposta de modelo para Escritórios de Projetos PMO DE SUCESSO PRECISA TER FOCO! Uma proposta de modelo para Escritórios de Projetos por Mario Trentim em http://blog.mundopm.com.br/2013/01/21/pmo-de-sucesso-precisa-terfoco/ Caro amigo leitor, que tal

Leia mais

PMBOK 4ª Edição I. Introdução

PMBOK 4ª Edição I. Introdução PMBOK 4ª Edição I Introdução 1 PMBOK 4ª Edição Um Guia do Conhecimento em Gerenciamento de Projetos Seção I A estrutura do gerenciamento de projetos 2 O que é o PMBOK? ( Project Management Body of Knowledge

Leia mais

Visão Geral sobre Gestão de Projetos e Iniciação de Projetos Aula 2

Visão Geral sobre Gestão de Projetos e Iniciação de Projetos Aula 2 Visão Geral sobre Gestão de Projetos e Iniciação de Projetos Aula 2 Miriam Regina Xavier de Barros, PMP mxbarros@uol.com.br Agenda Bibliografia e Avaliação 1. Visão Geral sobre o PMI e o PMBOK 2. Introdução

Leia mais

Perfis Profissionais e Modelo de Carreira da Informática em Saúde. Versão 1.0 para CONSULTA PÚBLICA

Perfis Profissionais e Modelo de Carreira da Informática em Saúde. Versão 1.0 para CONSULTA PÚBLICA Perfis Profissionais e Modelo de Carreira da Informática em Saúde Versão 1.0 para CONSULTA PÚBLICA Janeiro de 2012 SUMÁRIO 1. Estrutura dos Perfis Funcionais... 5 2. Perfis Funcionais por Área de Domínio...

Leia mais

A Importância das Competências Comportamentais para Profissionais de Gerenciamento de Projetos. Ivo M. Michalick Vasconcelos, MSc, PMP, PMI-SP

A Importância das Competências Comportamentais para Profissionais de Gerenciamento de Projetos. Ivo M. Michalick Vasconcelos, MSc, PMP, PMI-SP A Importância das Competências Comportamentais para Profissionais de Gerenciamento de Projetos Ivo M. Michalick Vasconcelos, MSc, PMP, PMI-SP Por que projetos falham? Gestão Moderna (anos 90 em diante):

Leia mais

PMO (Project Management Office) - Implantação de Escritório de Projetos

PMO (Project Management Office) - Implantação de Escritório de Projetos PMO (Project Management Office) - Implantação de Escritório de Projetos Orientações para o Projeto, Implantação, Gerenciamento e Avaliação de Maturidade do Escritório de Projetos Objetivo O que leva as

Leia mais

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com)

CMMI Conceitos básicos. CMMI Representações contínua e por estágios. Professor Gledson Pompeu (gledson.pompeu@gmail.com) CMMI Conceitos básicos 113 CMMI integra as disciplinas de engenharia de sistemas e de engenharia de software em um único framework de melhoria de processos. 114 No tocante às disciplinas de engenharia

Leia mais

Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol

Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol Maturidade Organizacional: Melhorando a Qualidade do Gerenciamento de Projetos Leonardo Luiz Barbosa Vieira Cruciol Resumo. O gerenciamento de projetos tem se tornado, durante os últimos anos, alvo de

Leia mais

Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa. Atila Belloquim Gnosis IT Knowledge Solutions

Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa. Atila Belloquim Gnosis IT Knowledge Solutions Qualidade de Software no Contexto Organizacional: Arquitetura Corporativa Atila Belloquim Gnosis IT Knowledge Solutions TI e Negócio 10 entre 10 CIOs hoje estão preocupados com: Alinhar TI ao Negócio;

Leia mais

CONCLUSÃO E CONSIDERAÇÕES FINAIS

CONCLUSÃO E CONSIDERAÇÕES FINAIS CAPÍTULO VI CONCLUSÃO E CONSIDERAÇÕES FINAIS 1 - Conclusão Cada vez mais fica evidente que não há caminho para abordar o processo decisório de estratégia em Tecnologia da Informação - TI de maneira improvisada.

Leia mais

Gerenciamento de Projetos

Gerenciamento de Projetos Gerenciamento de Projetos PMI, PMP e PMBOK PMI (Project Management Institute) Estabelecido em 1969 e sediado na Filadélfia, Pensilvânia EUA, o PMI é a principal associação mundial, sem fins lucrativos,

Leia mais

MBA EM GERÊNCIA DE PROJETOS

MBA EM GERÊNCIA DE PROJETOS Ribeirão Preto, Franca, Araraquara e São Carlos MBA EM GERÊNCIA DE PROJETOS COORDENAÇÃO: Profº Edmarson Bacelar Mota, M.Sc APOIO: SOBRE O CURSO Com a abertura dos mercados e o enorme aumento da competitividade,

Leia mais

Modelo de Maturidade Organizacional de Gerência de Projetos. Organizational Project Management Maturity Model - OPM3

Modelo de Maturidade Organizacional de Gerência de Projetos. Organizational Project Management Maturity Model - OPM3 Modelo de Maturidade Organizacional de Gerência de Projetos Introdução Organizational Project Management Maturity Model - OPM3 Um trabalho voluntário A idéia de um modelo não é novidade, as organizações

Leia mais

TREINAMENTOS MAGAZINE 3 WORKSHOP INTERNACIONAL DE LIDERANÇA 5 GERENCIAMENTO DE RISCOS EM PROJETOS 7 INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS

TREINAMENTOS MAGAZINE 3 WORKSHOP INTERNACIONAL DE LIDERANÇA 5 GERENCIAMENTO DE RISCOS EM PROJETOS 7 INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS TREINAMENTOS MAGAZINE 3 WORKSHOP INTERNACIONAL DE LIDERANÇA Líderes eficazes devem encontrar maneiras de melhorar o nível de engajamento, compromisso e apoio das pessoas, especialmente durante os períodos

Leia mais

Escritório de Projetos

Escritório de Projetos 1 Escritório de Projetos Módulo 3 Gestão de Projetos Aluno: Humberto Rocha de Almeida Neto hran@cin.ufpe.br Professores: Hermano Perrelli e Alexandre Vasconcelos 19 de outubro de 2009 Agenda Índice do

Leia mais

Questionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br)

Questionário de avaliação de Práticas X Resultados de projetos - Carlos Magno Xavier (magno@beware.com.br) Obrigado por acessar esta pesquisa. Sei como é escasso o seu tempo, mas tenha a certeza que você estará contribuindo não somente para uma tese de doutorado, mas também para a melhoria das práticas da Comunidade

Leia mais

APÊNDICE A QUESTIONÁRIO APLICADO AOS GESTORES

APÊNDICE A QUESTIONÁRIO APLICADO AOS GESTORES 202 INSTRUÇÕES DE PREENCHIMENTO ALGUNS COMENTÁRIOS ANTES DE INICIAR O PREENCHIMENTO DO QUESTIONÁRIO: a) Os blocos a seguir visam obter as impressões do ENTREVISTADO quanto aos processos de gestão da Policarbonatos,

Leia mais

Pesquisa realizada com os participantes do 16º Seminário Nacional de Gestão de Projetos APRESENTAÇÃO

Pesquisa realizada com os participantes do 16º Seminário Nacional de Gestão de Projetos APRESENTAÇÃO Pesquisa realizada com os participantes do de APRESENTAÇÃO O perfil do profissional de projetos Pesquisa realizada durante o 16 Seminário Nacional de, ocorrido em Belo Horizonte em Junho de, apresenta

Leia mais

APLICAÇÃO DO MODELO DE AVALIAÇÃO DE MATURIDADE PMI- OPM3 NA PETROBRAS E&P-SERV/US-PO ARTIGO PUBLICADO NA REVISTA MUNDO PM - ANO 1 - NRO 06

APLICAÇÃO DO MODELO DE AVALIAÇÃO DE MATURIDADE PMI- OPM3 NA PETROBRAS E&P-SERV/US-PO ARTIGO PUBLICADO NA REVISTA MUNDO PM - ANO 1 - NRO 06 APLICAÇÃO DO MODELO DE AVALIAÇÃO DE MATURIDADE PMI- OPM3 NA PETROBRAS E&P-SERV/US-PO Marco Antônio Gomes de Lima 1, Alonso Mazini Soler 2 e Luciana Palmieri 3 1 Coordenador de Projeto de Poço Exploratório

Leia mais

GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge)

GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge) GOVERNANÇA DE TI PMBoK (Project Management Body of Knowledge) Governança de TI AULA 08 2011-1sem Governança de TI 1 Introdução ao Gerenciamento de Projetos HISTÓRIA PMI Project Management Institute: Associação

Leia mais

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK

Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA. PMBoK Exercícios: Governança de TI Prof. Walter Cunha http://www.waltercunha.com PRIMEIRA BATERIA PMBoK 1. (FCC/ANALISTA-MPU 2007) De acordo com o corpo de conhecimento da gerência de projetos, as simulações

Leia mais

ASPECTOS GERAIS DE PROJETOS

ASPECTOS GERAIS DE PROJETOS ASPECTOS GERAIS DE PROJETOS O que é PROJETO Um empreendimento com começo e fim definidos, dirigido por pessoas, para cumprir objetivos estabelecidos dentro de parâmetros de custo, tempo e especificações.

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS ADMINISTRAÇÃO GERAL GESTÃO DE PROJETOS Atualizado em 31/12/2015 GESTÃO DE PROJETOS PROJETO Para o PMBOK, projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.

Leia mais

IMPLANTAÇÃO DE ESCRITÓRIO DE PROJETOS (PMO)

IMPLANTAÇÃO DE ESCRITÓRIO DE PROJETOS (PMO) IMPLANTAÇÃO DE ESCRITÓRIO DE PROJETOS (PMO) Msc. Cassio Germano, PMP Diretor PORTFOLIO Gestão e Capacitação Presidente Project Management Institute Seção Ceará 06/11/2009 Apresentação Prof. Msc. Cassio

Leia mais

IDENTIFICAÇÃO E DESENVOLVIMENTO DE COMPETÊNCIAS PARA A GESTÃO DE PROJETOS

IDENTIFICAÇÃO E DESENVOLVIMENTO DE COMPETÊNCIAS PARA A GESTÃO DE PROJETOS IDENTIFICAÇÃO E DESENVOLVIMENTO DE COMPETÊNCIAS PARA A GESTÃO DE PROJETOS Claudio Oliveira Aplicações de CRM Claudio Oliveira Apresentação Claudio Oliveira (cloliveira@usp.br) Professor da Fundação Vanzolini

Leia mais

PANORAMA DA FORMAÇÃO EM GESTÃO DE PROJETOS EM CURSOS DE ENGENHARIA

PANORAMA DA FORMAÇÃO EM GESTÃO DE PROJETOS EM CURSOS DE ENGENHARIA PANORAMA DA FORMAÇÃO EM GESTÃO DE PROJETOS EM CURSOS DE ENGENHARIA Débora Ayumi Kawanami (USP) deborak@gmail.com Marly Monteiro de Carvalho (USP) marlymc@usp.br Pressionadas pela crescente competitividade

Leia mais

www.pmbasis.com.br CONHEÇA TODAS AS SOLUÇÕES EM NEGÓCIOS, PROJETOS E FORMAÇÃO QUE A PMBASIS TEM PARA SUA EMPRESA OU INSTITUIÇÃO.

www.pmbasis.com.br CONHEÇA TODAS AS SOLUÇÕES EM NEGÓCIOS, PROJETOS E FORMAÇÃO QUE A PMBASIS TEM PARA SUA EMPRESA OU INSTITUIÇÃO. www.pmbasis.com.br CONHEÇA TODAS AS SOLUÇÕES EM NEGÓCIOS, PROJETOS E FORMAÇÃO QUE A PMBASIS TEM PARA SUA EMPRESA OU INSTITUIÇÃO. Crescer, Desenvolver, Multiplicar-se. Nossos melhores sonhos começam assim.

Leia mais

Modelos de Maturidade (CMMI, MPS-BR, PMMM)

Modelos de Maturidade (CMMI, MPS-BR, PMMM) UNEB - UNIVERSIDADE DO ESTADO DA BAHIA DEPARTAMENTO DE CIÊNCIAS EXATAS E DA TERRA - DCET1 COLEGIADO DE SISTEMAS DE INFORMAÇÃO DISCIPLINA: ENGENHARIA DE SOFTWARE PROFESSOR: EDUARDO JORGE Modelos de Maturidade

Leia mais

O papel de um Escritório de Projetos dentro de uma organização: um estudo de caso

O papel de um Escritório de Projetos dentro de uma organização: um estudo de caso O papel de um Escritório de Projetos dentro de uma organização: um estudo de caso Marcelo Guedes (MBA-FCAV/USP) mguedes@kuaitema.com.br Marly Monteiro de Carvalho (POLI/USP) marlymc@usp.br Resumo: Nos

Leia mais

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto,

14 Os principais documentos de um projeto são: o termo de. 15 Elemento integrante do gerenciamento do escopo do projeto, De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir.

No que se refere a conceitos básicos do gerenciamento de projetos, segundo o PMBoK, julgue os itens a seguir. De acordo com o comando a que cada um dos itens de 1 a 70 se refira, marque, na folha de respostas, para cada item: o campo designado com o código C, caso julgue o item CERTO; ou o campo designado com

Leia mais

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3.

Conteúdo. Apresentação do PMBOK. Projeto 29/07/2015. Padrões de Gerenciamento de Projetos. Fase 01 1.PMBOK e PMI. 2. Conceitos 3. 02m Conteúdo Apresentação do PMBOK Brasília, 25 de Junho de 2015 Fase 01 1.PMBOK e PMI 2. Conceitos 3.Processos Fase 02 4. Áreas de Conhecimento 10m Gerenciamento de Projetos Projeto A manifestação da

Leia mais

MBA Gestão da Tecnologia de Informação

MBA Gestão da Tecnologia de Informação MBA Gestão da Tecnologia de Informação Informações: Dias e horários das aulas: Segundas e Terças-feiras das 18h00 às 22h00 aulas semanais; Sábados das 08h00 às 12h00 aulas quinzenais. Carga horária: 600

Leia mais

A TECNOLOGIA DA INFORMAÇÃO E A GESTÃO DAS ORGANIZAÇÕES. Evolução do TI e Gestão das Organizações Gestão de Projetos Métodos Ágeis

A TECNOLOGIA DA INFORMAÇÃO E A GESTÃO DAS ORGANIZAÇÕES. Evolução do TI e Gestão das Organizações Gestão de Projetos Métodos Ágeis A TECNOLOGIA DA INFORMAÇÃO E A GESTÃO DAS ORGANIZAÇÕES Evolução do TI e Gestão das Organizações Gestão de Projetos Métodos Ágeis Vamos nos conhecer e definir as diretrizes de nosso curso??? www.eadistancia.com.br

Leia mais

Ambientação nos conceitos

Ambientação nos conceitos Ambientação em Gestão de Projetos Maria Lúcia Almeida Ambientação nos conceitos Gestão de áreas funcionais e gestão de projetos Qualquer um pode ser gerente de projetos? Qual a contribuição da gestão de

Leia mais

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS

GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS GERENCIAMENTO DE PROJETOS EM UM ESCRITÓRIO DE ARQUITETURA: VISÃO TRADICIONAL X NEGÓCIOS BASEADOS EM PROJETOS Ana Carolina Freitas Teixeira¹ RESUMO O gerenciamento de projetos continua crescendo e cada

Leia mais

M B A P Ó S - G R A D U A Ç Ã O E S P E C I A L I Z A Ç Ã O E M G E R E N C I A M E N T O D E P R O J E T O S * Programa sujeito a alterações

M B A P Ó S - G R A D U A Ç Ã O E S P E C I A L I Z A Ç Ã O E M G E R E N C I A M E N T O D E P R O J E T O S * Programa sujeito a alterações depto. mkt. IBE FGV * Programa sujeito a alterações RESOLUÇÃO DO MEC Os cursos MBA Pós-Graduação Especialização da Fundação Getulio Vargas atendem aos requisitos da Resolução CNE / CES nº 01, de 08/06/07.

Leia mais

5 Conclusões 5.1. Conclusões e implicações

5 Conclusões 5.1. Conclusões e implicações 5 Conclusões 5.1. Conclusões e implicações O presente trabalho tem caráter descritivo-exploratório e portanto não tem o intuito de se chegar a conclusões definitivas, sendo sua principal contribuição a

Leia mais

Padrões de Qualidade de Software

Padrões de Qualidade de Software Universidade Federal do Vale do São Francisco Padrões de Qualidade de Software Engenharia de Software I Aula 4 Ricardo Argenton Ramos Agenda da Aula Introdução (Qualidade de Software) Padrões de Qualidade

Leia mais

A IMPLANTAÇÃO DE UM ESCRITÓRIO DE GESTÃO DE PROJETOS: ESTUDO DE CASO DA UNI JÚNIOR CONSULTORIA E GESTÃO EMPRESARIAL

A IMPLANTAÇÃO DE UM ESCRITÓRIO DE GESTÃO DE PROJETOS: ESTUDO DE CASO DA UNI JÚNIOR CONSULTORIA E GESTÃO EMPRESARIAL A IMPLANTAÇÃO DE UM ESCRITÓRIO DE GESTÃO DE PROJETOS: ESTUDO DE CASO DA UNI JÚNIOR CONSULTORIA E GESTÃO EMPRESARIAL Eliana Maria dos Santos Pereira Alves (UNIVALI) eliana_santos@hotmail.com Ovidio Felippe

Leia mais

Políticas de Qualidade em TI

Políticas de Qualidade em TI Políticas de Qualidade em TI Prof. www.edilms.eti.br edilms@yahoo.com Aula 03 CMMI Capability Maturity Model Integration Parte II Agenda sumária dos Processos em suas categorias e níveis de maturidade

Leia mais

GERENCIAMENTO DE PORTFÓLIO DE PROJETOS E INVESTIMENTOS CONSULTORIA

GERENCIAMENTO DE PORTFÓLIO DE PROJETOS E INVESTIMENTOS CONSULTORIA GERENCIAMENTO DE PORTFÓLIO DE PROJETOS E INVESTIMENTOS CONSULTORIA SOBRE A CONSULTORIA Como realizar inúmeros projetos potenciais com recursos limitados? Nós lhe mostraremos a solução para este e outros

Leia mais

METODOLOGIA HSM Centrada nos participantes com professores com experiência executiva, materiais especialmente desenvolvidos e infraestrutura tecnológica privilegiada. O conteúdo exclusivo dos especialistas

Leia mais

O Padrão do PMI para Gerenciamento de Programas

O Padrão do PMI para Gerenciamento de Programas Project Management Institute Capítulo Minas Gerais O Padrão do PMI para Gerenciamento de Programas Ivo M. Michalick Vasconcelos, MsC, PMP Vice-Presidente de Certificação e Estudos Técnicos Belo Horizonte,

Leia mais

GERENCIAMENTO DE PORTFÓLIO

GERENCIAMENTO DE PORTFÓLIO PMI PULSO DA PROFISSÃO RELATÓRIO DETALHADO GERENCIAMENTO DE PORTFÓLIO Destaques do Estudo As organizações mais bem-sucedidas serão aquelas que encontrarão formas de se diferenciar. As organizações estão

Leia mais

Governança de TI Prof. Carlos Henrique Santos da Silva, MSc

Governança de TI Prof. Carlos Henrique Santos da Silva, MSc Governança de TI Prof. Carlos Henrique Santos da Silva, MSc PMP, PMI-RMP, PMI-ACP, CSM, CSPO, ITIL & CobiT Certified Carlos Henrique Santos da Silva, MSc, PMP Especializações Certificações Mestre em Informática

Leia mais

Gestão de equipes e escritórios de gerenciamento de projetos: uma análise crítica

Gestão de equipes e escritórios de gerenciamento de projetos: uma análise crítica Gestão de equipes e escritórios de gerenciamento de projetos: uma análise crítica Eduardo Vimecarti de Sá (UNINOVE) eduardovimecartisa@gmail.com Hérmani Magalhães Olivense do Carmo (UNINOVE) hermani_record@hotmail.com

Leia mais

Professor: Disciplina:

Professor: Disciplina: Professor: Curso: Disciplina: Marcos Morais de Sousa marcosmoraisdesousa@gmail.com marcosmoraisdesousa.blogspot.com Sistemas de informação Engenharia de Software II Gerenciamento de Qualidade CMMI e MPS.BR

Leia mais

OTIMIZAÇÃO DE RECURSOS E INVESTIMENTOS ATRAVÉS DO GERENCIAMENTO DE PROGRAMAS CONSULTORIA

OTIMIZAÇÃO DE RECURSOS E INVESTIMENTOS ATRAVÉS DO GERENCIAMENTO DE PROGRAMAS CONSULTORIA OTIMIZAÇÃO DE RECURSOS E INVESTIMENTOS ATRAVÉS DO GERENCIAMENTO DE PROGRAMAS CONSULTORIA SOBRE A CONSULTORIA Alcance melhores resultados através da gestão integrada de projetos relacionados ou que compartilham

Leia mais

Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo

Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo Quais são as Balas de Prata no Gerenciamento de Projetos? (Autores: Carlos Magno da Silva Xavier e Alberto Sulaiman Sade Júnior) Resumo A metáfora bala de prata se aplica a qualquer ação que terá uma extrema

Leia mais

Abordagens para a Governança de BPM (parte 2)

Abordagens para a Governança de BPM (parte 2) Abordagens para a Governança de BPM (parte 2) Introdução...... 2 Apresentação de abordagens de Governança de BPM (Parte 2)... 3 Governança em Richardson... 4 Governança em Hammer... 5 Governança em Miers...

Leia mais

1 Introdução 1.1. Problema de Pesquisa

1 Introdução 1.1. Problema de Pesquisa 1 Introdução 1.1. Problema de Pesquisa A motivação, satisfação e insatisfação no trabalho têm sido alvo de estudos e pesquisas de teóricos das mais variadas correntes ao longo do século XX. Saber o que

Leia mais

Definição do Framework de Execução de Processos Spider-PE

Definição do Framework de Execução de Processos Spider-PE Definição do Framework de Execução de Processos Spider-PE 1. INTRODUÇÃO 1.1 Finalidade Este documento define um framework de execução de processos de software, denominado Spider-PE (Process Enactment),

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

Estudo do CMM e do CMMI

Estudo do CMM e do CMMI Estudo do CMM e do CMMI Autores Félix Carvalho Rodrigues fcrodrigues@inf.ufrgs.br Georgina Reategui gg@inf.ufrgs.br Manuela Klanovicz Ferreira mkferreira@inf.ufrgs.br Motivação Grande quantidade de projetos

Leia mais

Questionário de Governança de TI 2014

Questionário de Governança de TI 2014 Questionário de Governança de TI 2014 De acordo com o Referencial Básico de Governança do Tribunal de Contas da União, a governança no setor público compreende essencialmente os mecanismos de liderança,

Leia mais

Declaração de trabalho do projeto. Caso de negócio. Fatores ambientais da empresa. Estratégia de gerenciamento das partes interessadas.

Declaração de trabalho do projeto. Caso de negócio. Fatores ambientais da empresa. Estratégia de gerenciamento das partes interessadas. 30 Estratégia de gerenciamento das partes interessadas. Eles serão descritos nas subseções a seguir. Declaração de trabalho do projeto A declaração de trabalho do projeto descreve o produto, serviço ou

Leia mais

CENTRO UNIVERSITÁRIO PADRE ANCHIETA Jundiaí / SP QUESTÕES SIMULADAS DE GESTÃO DE PROJETOS PARA 1ª AVALIAÇÃO

CENTRO UNIVERSITÁRIO PADRE ANCHIETA Jundiaí / SP QUESTÕES SIMULADAS DE GESTÃO DE PROJETOS PARA 1ª AVALIAÇÃO QUESTÕES SIMULADAS DE GESTÃO DE PROJETOS PARA 1ª AVALIAÇÃO Gabarito: 1D, 2B, 3A, 4C, 5C, 6A, 7C, 8B, 9D, 10A, 11D, 12B, 13A, 14B, 15D, 16B, 17D, 18D, 19B Fórmulas: VC = VA - CR VPR = VA - VP IDC = VA /

Leia mais

Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos. White Paper

Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos. White Paper Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos White Paper TenStep 2007 Saiba Como Convencer os Executivos Sobre o Valor do Gerenciamento de Projetos Não há nenhuma duvida

Leia mais

MATURIDADE NA GERÊNCIA DE PROJETOS DE EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO: UM ESTUDO ANALÍTICO E EXPLORATÓRIO

MATURIDADE NA GERÊNCIA DE PROJETOS DE EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO: UM ESTUDO ANALÍTICO E EXPLORATÓRIO MATURIDADE NA GERÊNCIA DE PROJETOS DE EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO: UM ESTUDO ANALÍTICO E EPLORATÓRIO Claudiane Oliveira Universidade Federal de Lavras/Brasil claudianeo@gmail.com Ramon Abílio,

Leia mais

União Metropolitana de Educação e Cultura. Interdisciplinar I Módulo CSTs: RH, Logística e GESCOM

União Metropolitana de Educação e Cultura. Interdisciplinar I Módulo CSTs: RH, Logística e GESCOM União Metropolitana de Educação e Cultura Interdisciplinar I Módulo CSTs: RH, Logística e GESCOM Lauro de Freitas - BAHIA 2013 2 JUSTIFICATIVA A principal justificativa para o desenvolvimento e implementação

Leia mais