Fundao Getlio Vargas Programa FGV Management MBA em Gerenciamento de Projetos

Douglas Laurindo (ISAE-FGV) dlaurindo@gmail.com Marcos dos Santos (ISAE-FGV) msanator@hotmail.com Pablo Valentini (ISAE-FGV) pablondrina@gmail.com Raquel Sanches Calvo (ISAE-FGV) raquelsanchescalvo@hotmail.com

Desenvolvimento de metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade

Londrina (PR) Maio 2011

Douglas Laurindo Marcos dos Santos Pablo Valentini Raquel Sanches Calvo

Desenvolvimento de metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade

Trabalho apresentado ao curso MBA em Gerenciamento de Projetos, Ps-Graduao lato sensu, da Fundao Getlio Vargas, como requisito parcial para a obteno do Grau de Especialista em Gerenciamento de Projetos. Orientadora: Prof. Denise Bascal

Londrina (PR) Maio 2011

Fundao Getlio Vargas Programa FGV Management MBA em Gerenciamento de Projetos

O Trabalho de Concluso de Curso Desenvolvimento de metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade elaborado por Douglas Laurindo, Marcos dos Santos, Pablo Valentini e Raquel Sanches Calvo e aprovado pela Coordenao Acadmica do curso de MBA em Gerenciamento de Projetos, foi aceito como requisito parcial para a obteno do certificado do curso de psgraduao, nvel de especializao do Programa FGV Management.

Londrina (PR), 01 de maio de 2011.

________________________________________ Carlos A. C. Salles Jr. Coordenador Acadmico Executivo

_______________________________________ Denise Bascal Orientadora

TERMO DE COMPROMISSO

Os alunos Douglas Laurindo, Marcos dos Santos, Pablo Valentini e Raquel Sanches Calvo, abaixo assinados, do curso de MBA em Gerenciamento de Projetos, Turma GP01LON2009 do Programa FGV Management, realizado nas dependncias do ISAE, no perodo de 2009 a 01/05/2011, com 456 h/a, declaram que o contedo do Trabalho de Concluso de Curso intitulado Desenvolvimento de metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade autntico, original e de nossa autoria exclusiva.

Londrina (PR), 01 de maio de 2011.

_______________________________________ Douglas Laurindo

__________________________________ Marcos dos Santos

___________________________________ Pablo Valentini

____________________________________ Raquel Sanches Calvo

A todos que souberam entender nossas limitaes, mas que nunca deixaram de acreditar em nossas potencialidades.

AGRADECIMENTOS

Agradecemos primeiramente a Deus por nos iluminar e nos dar foras para trilhar nossos caminhos. Agradecemos a professora Denise Basgal durante toda a orientao deste trabalho e dos demais trabalhos que tivermos a oportunidade e o privilgio de a termos como orientadora. Agradecemos a todos os professores do curso pelos ensinamentos e por contriburem para a nossa formao. Aos amigos adquiridos durante o curso que fizeram com que fizeram a diferena em muitos momentos de desespero e falta de esperana. A todos aqueles que nos ajudaram a finalizar este MBA, em especial as nossas famlias, esposas, namorados, amigos, que atravs de seu apoio e carinho de tornaram este momento possvel.

RESUMO

Este trabalho tem como objetivo apresentar uma metodologia simplificada de gerenciamento de projetos capaz de atender com qualidade e eficincia projetos pequenos em ambientes de baixa maturidade, buscando o aprimoramento da gesto do conhecimento em empresas oriundas desse cenrio. No primeiro momento procura-se conceituar o tipo de projeto a ser aplicado essa metodologia, alm de definir as caractersticas de empresas que possuem um ambiente de baixa maturidade. Tambm ser explanado sobre a importncia da gesto do conhecimento, como forma de agregar valores a empresa, a fim de alcanar maturidade, desenvolvendo assim os processos, as pessoas e os produtos. Por fim, ser apresentada a metodologia de gerenciamento de projetos baseada nos conceitos contidos nas metodologias geis, e na adaptao das melhores prticas sugeridas pelo PMBOK (Project Management Body of Knowledge).

PALAVRAS-CHAVE Gerenciamento de projetos, maturidade, metodologia, mtodos geis e PMBOK.

ABSTRACT This paper aims to present a simplified methodology for project management capable of dealing with quality and efficiency of small projects in low maturity environments, seeking to improve the knowledge management in companies from this scenario. At first, the aim is to conceptualize the type of project to apply this methodology, and define the characteristics of companies with an environment of low maturity. Also it will be explained on the importance of knowledge management as a way to add value to the company, in order to reach maturity, thus developing the processes, people and products. Finally, you see the project management methodology based on concepts contained in agile methodologies, and adapting the best practices suggested by the PMBOK (Project Management Body of Knowledge).

KEY WORDS Project Management, Maturity, Methodology, gile Methods and PMBOK.

LISTA DE ABREVIATURAS E SIGLAS

PMBOK - Project Management Body of Knowledge PMI - Project Management Institute PRINCE2 - Project IN Controlled Enviroment OGC - Office Government Commerce XP - eXtreme Programming FDD - Feature Driven Development OPM3 - Organizational Project Management Maturity Model CMMI - Capability Maturity Model Integration GP - Gerenciamento de Projetos ISI - Internationals Project Framework PMMM - Project Management Maturity Model SEI - Software Engineering Institute

LISTA DE TABELAS

Tabela 1 - reas do Conhecimento do PMBOK e suas descries. 16

LISTA DE FIGURAS

Figura 1 - Ciclo de vida do SCRUM............................................23 Figura 2 - Ciclo de vida do FDD.................................................27 Figura 3 - Dimenses e Nveis de Maturidade............................34 Figura 4 - 17 Processos da Metodologia Proposta......................37 Figura 5 - Etapas do processo Gerar Oramento........................38

SUMRIO 1 INTRODUO........................................................................13 2 REFERENCIAL TERICO.........................................................15

2.1 O Gerenciamento de Projetos segundo o PMBOK ......................15
2.1.1 O conceito geral para projetos........................................................................15 2.1.2 Processos de gerenciamento de projetos segundo o PMBOK............................15

2.2 Metodologias de Gerenciamento de Projetos.............................17

2.2.1 Projetos em ambientes controlados (PRINCE2).................................................17 2.2.2 Metodologias geis..........................................................................................20 2.2.3 Manifesto gil...................................................................................................20 2.2.4 SCRUM.............................................................................................................21 2.2.5 Extreme Programming XP..............................................................................24 2.2.6 Feature Driven Developmento - FDD................................................................26 2.2.6.1 Desenvolvimento de um Modelo Global.....................................................28 2.2.6.2 Construir uma Lista de Funcionalidades....................................................28 2.2.6.3 Planejar por Funcionalidade.......................................................................28 2.2.6.4 Modelar por Funcionalidade e Construir por Funcionalidade......................29

3 DEFINIO DO CENRIO........................................................30
3.1 Projetos de Pequeno Porte........................................................30 3.2 Modelos de Nvel de Maturidade em Gerenciamento de Projetos. 31
3.2.1 Modelo OPM3....................................................................................................31 3.2.2 Modelo CMMI....................................................................................................32 3.2.3 Modelo Prado-MMGP.........................................................................................33

4 METODOLOGIA......................................................................34 5 APRESENTAO E ANLISE DE RESULTADO............................38 6 RECOMENDAES.................................................................43 7 CONCLUSO.........................................................................44 8 BIBLIOGRAFIA.......................................................................45 9 APNDICES POR AUTOR INDIVIDUAL.......................................48
9.1 Douglas Laurindo......................................................................48 9.2 Marcos dos Santos....................................................................55 9.3 Pablo Valentini.........................................................................60

INTRODUO..........................................................................60 CONTEXTO.............................................................................61 RESULTADOS..........................................................................61 CONCLUSO...........................................................................70 BIBLIOGRAFIA.........................................................................71

9.4 Raquel Sanches Calvo...............................................................72

INTRODUO..........................................................................72 CONTEXTO.............................................................................72

APRESENTAO E ANLISE DE RESULTADO..............................73 CONCLUSO .........................................................................78 BIBLIOGRAFIA.........................................................................78

13

1 INTRODUO
Para alcanar o sucesso e a sustentabilidade no mercado atual, as empresas necessitam constantemente buscar a inovao e otimizar suas atividades e controles. E cada vez mais, a orientao por projetos se torna uma constante dentro das instituies, independente de seu porte ou nvel de maturidade. Deste modo, torna-se cada vez mais necessrio o uso de metodologias de gerenciamento de projetos por parte das empresas, visto que as mesmas vem investindo em projetos, para implementar suas estratgias, e que vm constatando que a orientao por projetos garante maiores resultados em suas aes estratgicas. Assim, o presente trabalho tem como objetivo sugerir uma metodologia de gerenciamento de projetos para gerir de forma eficiente e simplificada pequenos projetos em empresas que apresentam um nvel de maturidade baixa, buscando compilar os processos essenciais sugeridos pelas boas prticas do gerenciamento de projetos, com nfase na simplicidade, na agilidade, resposta gil s mudanas e na otimizao das interaes em pequenas equipes, defendidos, em linhas gerais, pelas metodologias geis. Como referncia para constituio da metodologia deste trabalho foi utilizado o guia do Project Management Body of Knowledge (PMBOK), de autoria do Project Management Institute (PMI) e os conceitos fornecidos por Metodologia de Gerenciamento de Projetos como o PRINCE2 (Projetos em Ambientes Controlados), Manifesto gil e pelas Metodologias geis como Extreme Programming XP, SCRUM e Feature Driven Development FDD, enfatizando a otimizao das boas prticas, baseada na reduo do nmero de processos que compe o gerenciamento de projetos com base no PMBOK. Em um primeiro momento apresentaremos um referencial terico sobre o conceito geral de projeto e os processos de gerenciamento de projetos segundo o PMBOK, para em seguida apresentar as acima citadas metodologias de gerenciamento de projetos.

14 Em seguida, faremos uma definio do cenrio proposto para o trabalho, delimitando o conceito de projeto de pequeno porte, alm de apresentar modelos de nvel de maturidade no gerenciamento de projetos como o Modelo OPM3, CMM e Prado-MMGP, a fim de obter a delimitao de ambiente de baixa maturidade. Por fim, apresentaremos nossa proposta de metodologia de gerenciamento de pequenos projetos em ambientes de baixa maturidade, elencando e/ ou integrando os processos, que acreditamos serem elementares para o Gerenciamento de Projetos, compilados pelo PMBOK, e definindo as inter-relaes e funes que os mesmo geram junto ao gerenciamento de pequenos projetos, para ao final, apresentar nossas consideraes sobre a viabilidade e sustentabilidade da aplicao desta proposta de metodologia gerenciamento de projetos.

15 2

REFERENCIAL TERICO

2.1

O GERENCIAMENTO

DE

PROJETOS

SEGUNDO O

PMBOK

2.1.1

O conceito geral para projetos

O guia PMBOK (a Guide of Project Management Body of

Knowledge), principal publicao das melhores prticas de gerenciamento de projetos do PMI (Project Management Institute), conceitua projeto como um empreendimento temporrio com o objetivo de criar um produto nico. Conforme coloca Valle et alli (2007) os projetos compartilham de caractersticas comuns: agregam valor com o aprendizado contnuo por meio dos erros; tem carter temporrio, singular, e de desenvolvimento progressivo, em etapas incrementais, e diferentemente do trabalho operacional, que contnuo, os projetos devem atingir o objetivo traado e ser finalizado, enquanto que um trabalho operacional deve ter como objetivo a manuteno do negcio

2.1.2 Processos de gerenciamento de projetos segundo o PMBOK

Embora o gerenciamento de projetos ocorra desde a

antiguidade, seu tratamento como rea de conhecimento recente. Devido sobretudo a demandas militares, no perodo aps a II Guerra Mundial foi relacionado a projetos espaciais, de armamentos e grandes obras de engenharia civil. Contudo, foi a partir dos anos 70 que o gerenciamento de projetos comeou a se desenvolver em diversos setores da economia. Atualmente, esta prtica utilizada nos mais diversos ramos de atividade e apresenta fundamental importncia na transformao de planejamento em resultados, na otimizao do uso de recursos, na mitigao de riscos.

16 Segundo Vale at alli (2007) o Gerenciamento de Projetos :

a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender as suas demandas, sendo realizado por meio da integrao dos seguintes processos: iniciao, planejamento, execuo, monitoramento e controle, e encerramento.

Alm de considerar os grupos de processos citados acima, o guia PMBOK tambm organiza os processos de gerenciamento de projetos em termos das nove reas de conhecimento apresentadas na tabela abaixo.
Tabela 1 - reas do Conhecimento do PMBOK e suas descries rea do conhecimento Descrio dos processos Processos envolvidos na verificao de que o projeto que inclui todo o trabalho necessrio, e apenas o trabalho necessrio, para que seja concludo com sucesso. Ele consiste nos processos de gerenciamento de projetos: Coletar requisitos, Definio do escopo, Criar EAP (Estrutura Analtica do Projeto), Verificao do escopo e Controle do escopo. Processos relativos ao trmino do projeto no prazo correto. Ele consiste nos processos de gerenciamento de projetos: Definio da atividade, Sub-seqenciamento de atividades, Estimativa de recursos da atividade, Estimativa de durao da atividade, Desenvolvimento do cronograma e Controle do cronograma. Processos envolvidos em planejamento, estimativa, oramentao e controle de custos, de modo que o projeto termine dentro do oramento aprovado. Ele consiste nos processos de gerenciamento de projetos: Estimativa de custos, Oramentao e Controle de custos. Processos relativos realizao do gerenciamento de riscos em um projeto. Ele consiste nos processos de gerenciamento de projetos: Planejamento do gerenciamento de riscos, Identificao de riscos, Anlise qualitativa de riscos, Anlise quantitativa de riscos, Planejamento de respostas a riscos e Monitoramento e Controle de riscos. Processos que organizam e gerenciam a equipe do projeto. Ele consiste nos processos de gerenciamento de projetos: Planejamento de recursos humanos, Contratar ou mobilizar a equipe do projeto, Desenvolver a equipe do projeto e Gerenciar a equipe do projeto. Processos envolvidos na garantia de que o projeto ir satisfazer os objetivos para os quais foi realizado. Ele consiste nos processos de gerenciamento de projetos: Planejamento da qualidade, Realizar a garantia da qualidade e Realizar o controle da qualidade. Processos relativos gerao, coleta, disseminao, armazenamento e destinao final das informaes do projeto de forma oportuna e adequada. Ele consiste nos processos de gerenciamento de projetos: Planejamento das comunicaes,

Gerenciamento de Escopo

Gerenciamento de Tempo

Gerenciamento de Custo

Gerenciamento de Riscos

Gerenciamento de Recursos Humanos

Gerenciamento da Qualidade

Gerenciamento da Comunicao

17
Distribuio das informaes, Relatrio de desempenho e Gerenciar as partes interessadas. Processos que compram ou adquirem produtos, servios ou resultados, alm dos processos de gerenciamento de contratos. Ele consiste nos processos de gerenciamento de projetos: Planejar compras e aquisies, Planejar contrataes, Solicitar respostas de fornecedores, Selecionar fornecedores, Administrao de contrato e Encerramento do contrato. Processos e as atividades que integram os diversos elementos do gerenciamento de projetos, que so identificados, definidos, combinados, unificados e coordenados dentro dos grupos de processos de gerenciamento de projetos. Ele consiste nos processos de gerenciamento de projetos: Desenvolver o termo de abertura do projeto, Desenvolver a declarao do escopo preliminar do projeto, Desenvolver o plano de gerenciamento do projeto, Orientar e gerenciar a execuo do projeto, Monitorar e controlar o trabalho do projeto, Controle integrado de mudanas e Encerrar o projeto. Fonte: PMBOK 4 edio

Gerenciamento de Aquisies

Gerenciamento de Integrao

2.2

METODOLOGIAS

DE

GERENCIAMENTO

DE

PROJETOS

2.2.1 Projetos em ambientes controlados (PRINCE2)

O Project IN Controlled Enviroment PRINCE2 uma

metodologia para o gerenciamento de projetos bastante difundido na Europa, visto que foi desenvolvida na Inglaterra e uma marca registrada do OGC (The Office Government Commerce) e teve seu primeiro lanamento em 1996. O PRINCE2 uma abordagem estruturada, com processos, papis e responsabilidades bem definidos, que orienta o gerente e time do projeto na conduo do projeto. Fazendo uma comparao, enquanto o PMBOK Guide mostra o que necessrio fazer e o PRINCE2 mostra como fazer. Deste modo trata-se de padro de gerenciamento de projetos, ou seja, uma metodologia da gerncia de projeto focada na organizao, na gerncia e no controle. Cada processo definido com: entradas e sadas chaves, objetivos a serem conseguidos, e atividades a serem realizadas.

18 O PRINCE2 baseado em princpios, o que significa que um projeto PRINCE2 inclui sete princpios: Contnua justificativa comercial; Aprenda com a experincia; Papis e responsabilidades bem definidos; Administrar por etapas; Gerir por exceo; Foco nos produtos; Ajuste para se adequar ao ambiente de projeto. Essa metodologia baseia-se em seis variveis e/ou seis metas de desempenho: Prazos, Custos, Qualidade, Escopo, Benefcios e Riscos. Prazos: A pergunta a fazer para escalas de tempo: quando o projeto ser concludo? Custo: Os projetos tm de dar um retorno sobre o investimento e, portanto, as perguntas a fazer so: Os custos so controlados? E estamos dentro do oramento? Qualidade: o produto ser til no final do projeto (em outras palavras adequadas sua finalidade)? Escopo: O escopo bem definido e claro para todos os interessados? Que cuidados devem ser tomados pelo gestor do projeto, para evitar aumento de escopo, que permitir que novos requisitos sejam adicionados durante o projeto? Benefcios: Por que estamos fazendo este projeto e quais so os benefcios? Os benefcios devem ser claros e conhecidos pelo Gerente do Projeto, e os benefcios precisam ser entregues.

19 Risco: Todos os projetos so nicos e, portanto, tm risco. Quanto que podemos assumir de risco? E como os mesmos podem ser controlados? Por exemplo, num projeto de construo de uma casa em andamento, o que acontece se um dos subempreiteiros no aparece? PRINCE2 um mtodo que lida com o planejamento, delegao, acompanhamento e controle de todas as seis variveis do projeto, as quais o PMBOK se refere como restries do projeto. O mtodo PRINCE2 composto de 4 partes principais, ou os elementos que compe o projeto. O manual diz que o PRINCE2 tem quatro elementos integrados. Estes so os princpios, temas, processos e adaptao. Princpios: O PRINCE2 diz que cada projeto deve ser composto de sete princpios PRINCE2 (em outras palavras, as "melhores prticas"). Temas: O elemento Temas responde pergunta, quais itens devem ser acatados (valorizados) em cada projeto, por exemplo, Caso de Negcio, Organizao, Qualidade e Gerenciamento de Configurao. Processos:O elemento Processos responde pergunta, quais atividades so realizadas durante o projeto e por quem. Processos tambm responde "Que produtos esto a ser criadas e quando?" Adaptao: Adaptao responde a uma das perguntas mais comuns de um Gerente de Projeto: "Como posso aplicar melhor o PRINCE2 ao meu projeto ou o meu ambiente?" O mtodo PRINCE2 quando bem entendido e compreendido, fornece o controle no uso dos recursos e controle dos riscos, permitindo aos projetos terem comeo, meio e fim controlados e organizados, pontos de deciso flexveis, participao da gerncia e dos stakeholders em pontos apropriados, alm de incentivar os canais de comunicao entre o projeto, a gerncia de projeto e o stakeholders.

20

2.2.2 Metodologias geis

No passado as empreitadas de trabalho comumente eram precedidas de pouco planejamento e desenvolviam-se gradualmente por meio do emprego de testes e prottipos para verificar o sucesso de seus objetivos. medida que a complexidade dos cenrios aumentava, tornou-se bvia a necessidade de criar um novo modelo de trabalho, onde processos detalhados foram sugeridos baseados em longas fases de planejamento. Estes modelos muitas vezes reconhecidos como burocrticos - se tornaram muito populares. Porm, as crticas em relao a sua estrutura persistem, por investirem um longo tempo em fases que precedem a fase de execuo ou desenvolvimento do projeto. neste cenrio que as metodologias geis se encaixam. O ambiente adequado para as metodologias geis pode ser encontrado por incertezas, expertise nica e velocidade. Todos estes itens, principalmente a incerteza, quando combinados, criam um ambiente de mudanas de requerimentos, que resulta em grandes dificuldades no gerenciamento de um projeto. Este o ambiente que as tcnicas das metodologias geis so totalmente aplicveis.

2.2.3 Manifesto gil

Segundo Highsmith (2001), em fevereiro de 2001, dezessete pessoas, representantes das metodologias geis, criaram uma aliana, chamada Agile Alliance e firmaram um manifesto denominado agile manifesto que destaca quatro valores:

21 Indivduos e iteraes so mais importantes que processos e ferramentas; Software funcional mais importante que documentao detalhada; Colaborao do cliente mais importante que negociao de contratos; Responder s mudanas mais importante que seguir um plano. Como citado anteriormente, esse manifesto surgiu em

resposta aos problemas nos projetos das metodologias tradicionais, como atrasos na entrega, entregas incompletas ou software obsoleto. Segundo Barbosa, os princpios do manifesto vieram a reduzir esses problemas ajudando a cumprir os objetivos traados para o projeto.

2.2.4 SCRUM

Criado por Jeff Sutherland em 1990 e aperfeioado por Schwaber e Beedle em 1996, o SCRUM tem uma abordagem simples e interessante, voltado para equipes pequenas. Essa abordagem vem obtendo sucesso e ganhando espao no mercado de desenvolvimento de software. O SRUM trabalha com ciclo de vida iterativo e incremental com releases rpidas e constantes, dessa forma a mudana e/ou incluso de requisitos e prioridades no se torna um problema ou agravante. recomendado que a equipe tenha profissionais experientes, uma vez que tm funes bem definidas. O SCRUM se baseia em alguns princpios, dentre eles esto: Equipes pequenas, organizadas de forma que cada um explore o mximo de suas habilidades, otimize a comunicao, para superar mais rapidamente os obstculos atravs da troca de conhecimentos e minimizar a necessidade de superviso;

22 O processo deve prever a necessidade de modificaes tanto em nvel de requisitos quanto em nvel tecnolgico, para que possa ser produzido o sistema com a maior qualidade; O processo deve produzir releases freqentes, que possam ser testadas e inspecionadas; As funes das equipes e trabalhos devem estar bem definidas e bem dividas; Conforme o produto vai sendo construdo, a cada release, vo sendo feitos os documentos e os testes. Esses princpios norteiam todas as tarefas em SCRUM, independentemente da fase: requisitos, anlise, projeto, evoluo ou entrega (PRESMAN, 2006). Para proceder com um projeto utilizando SCRUM trs papeis so requeridos, dentre os quais os envolvidos se dividem: Stakeholders: So os representantes do lado do cliente, eles definem requisitos e prioridades de entrega, ordenando assim o desenvolvimento e validando os releases. Scrum Master: Assemelha-se ao gerente de projetos. Geralmente o mais experiente do grupo e conhecedor da metodologia. Scrum Team: Time de desenvolvimento. Geralmente com 7-10 profissionais, todos com funes bem definidas de acordo com o projeto e rea de conhecimento. O primeiro passo uma reunio com os clientes para fazer um levantamento de requisitos do sistema, fase de requisitos. Esses requisitos so divididos em pacotes denominados product backlogs, que devem ser ordenados de acordo com a sua prioridade de desenvolvimento. Dessa forma a incluso de um novo conjunto de funcionalidades, ou a determinao tardia de urgncia de algum conjunto j previsto, no afeta o desenvolvimento do produto, uma vez que este item pode entrar no topo da lista de prioridade.

23 Uma vez definidos os product backlogs, esses por sua vez devem ser ordenados de acordo com a sua prioridade e divididos em pacotes menores, denominados sprint backlogs. Cada Sprint backlog deve ter uma estimativa de tempo de desenvolvimento entre 2-4 semanas, que o tempo da iterao, denominada Sprint. Durante o Sprint so feitas reunies denominadas Daily Meetings. Como o nome sugere so reunies dirias, com durao mdia de 30 minutos. Lideradas pelo Scrum Master, com o Scrum Team, geralmente os Stakeholers no participam dessa reunio. Nessa reunio deve-se apenas responder trs perguntas: O que voc fez desde a ltima reunio? Encontrou algum obstculo ou problema? Qual? O que vai fazer at a prxima reunio? Dessa forma todos os participantes do projeto, sabem qual a evoluo do mesmo, quais as eventuais causas de atraso, podem ajudar com sugestes, alm de identificarem complicadores to cedo quanto possvel, fazendo com que se perca menos tempo com eles, facilitando assim, o cumprimento do cronograma.
Figura 1 - Ciclo de vida do SCRUM

(Fonte: http://www.heptagon.com.br/images/scrum.jpg)

24 Como pode ser observado na Figura 2, ao final de cada Sprint integrado uma nova verso ao sistema corrente, agregando, a cada release, valor funcional ao sistema. Caso a funcionalidade a ser desenvolvida naquele perodo seja complexa ou grande demais, ao menos, uma verso demonstrativa entregue para validao.

2.2.5 Extreme Programming XP

Programao extrema (do ingls eXtreme Programming), ou simplesmente XP, provavelmente a metodologia gil mais difundida atualmente. Seu desenvolvimento foi publicado pela primeira vez por Kent Beck em 1999 (PRESMAN, 2006). O XP bem flexvel e encontra uma boa alternativa para a abordagem gil de desenvolvimento. Embora possa ser aplicado em projetos de alto risco e com mudana constante de requisitos, o XP no deve ser aplicado a qualquer tipo de projeto, podendo at mesmo comprometer a produtividade da equipe. Segundo Oshiro (2006), o XP indicado para projetos que tenham: Grupos de 2-10 programadores; Integrao total entre programadores, gerentes e clientes; A possibilidade de gerar testes unitrios e funcionais com muita freqncia; Comprometimento de todos os integrantes da equipe de desenvolvimento para no comprometer a alta produtividade; A comunicao com o cliente deve ser imediata, a pessoa por parte do cliente que faz contato com a equipe deve ter liberdade para tomar decises rpidas. O XP segue um conjunto de valores bsicos para o sucesso do projeto, so eles: comunicao, simplicidade, feedback e coragem. Baseados nesses valores surgem as doze prticas do XP. Note que para o

25 sucesso do projeto importante usar todas as prticas, uma vez que as mesmas se completam. So elas: 1. Processo de Planejamento: Consiste na definio do valor funcional dos recursos pelo cliente e atravs de estimativas geradas pelos desenvolvedores, decidir o que tem prioridade e o que pode ser adiado; 2. Pequenas Verses: Baseados em ciclos curtos, a equipe entrega pequenas verses integrando o sistema que est sendo desenvolvido; 3. Metfora do Sistema: A equipe usa nomes e descries ao invs de termos tcnicos para facilitar a comunicao com o cliente; 4. Projeto Simples: Focado no valor de negcio do produto, a equipe desenvolve o projeto mais simples possvel que satisfaa os requisitos atuais do cliente. No h a preocupao com requisitos futuros. Esses requisitos sero tratados quando aparecerem; 5. Teste: Durante todo o processo de desenvolvimento o cliente valida os requisitos do sistema, a equipe fornece uma verso de testes antes da codificao completa para garantir que os recursos esto sendo desenvolvidos a contento; 6. Reconstruo: A busca pela melhoria de cdigo constante, o cdigo fica mais legvel, e vo se adicionando recursos faltantes, resultando em um cdigo simples, porm legvel; 7. Programao em Pares: Os programadores se dividem em pares para codificar, um codifica e o outro contribui na lgica e na limpeza de cdigo. Est comprovada a drstica diminuio de erros no cdigo alm da melhoria na qualidade do produto;

26 8. Propriedade coletiva: O cdigo no tem dono. Assim no h a necessidade de um programador solicitar mudanas para outro, atrasando o projeto, todos tem liberdade para fazer; 9. Integrao contnua: A integrao constante do sistema permite que todos os programadores estejam sabendo de tudo que acontece no projeto, aumentando assim a agilidade no seu progresso; 10. 40 horas de trabalho semanal: Equipes cansadas diminuem a produtividade e o interesse, cometendo assim mais erros; 11. Cliente dedicado: Todo projeto em XP precisa de um cliente em contato constante com a equipe, fornecendo requisitos, ajustando prioridades e testando o sistema. Com essa relao direta e alta comunicao, existe a diminuio da documentao que tem uma grande representatividade no custo e tempo do projeto; 12. Cdigo padro: Todos os programadores seguem um mesmo padro de codificao, dessa forma aumenta a legibilidade do cdigo, facilitando tanto a programao em pares quanto a propriedade coletiva de cdigo. Com documentao mnima, entregas rpidas e diminuio do custo, o XP se difunde a cada dia, atendendo as necessidades dos clientes, reduzindo prazos e riscos de projeto.

2.2.6 Feature Driven Developmento - FDD

FDD - Feature Driven Development (Desenvolvimento Guiado por Funcionalidades) - outro exemplo desse novo conceito de desenvolvimento de software e consiste em um desenvolvimento voltado a funcionalidades. O FDD um processo com foco no desenvolvimento de sistemas utilizando mtodos de fcil compreenso e implementao,

27 trazendo consigo tcnicas de resoluo de problemas e diretrizes para os relatrios, de forma a suprir as necessidades dos interessados com informaes durante todo o ciclo de vida do processo. Desta maneira o FDD apresenta uma forma gil e adaptativa de desenvolver sistemas. O FDD no abrange todo o processo de desenvolvimento de software, ao invs disso, ele tem como seu foco e objetivo a fase de modelagem e construo do sistema. O FDD tem em sua estrutura cinco processos desde a modelagem e at a construo do sistema, so eles: Desenvolver um Modelo Global; Construir a Lista de Funcionalidades; Planejar por Funcionalidade; Modelar por Funcionalidade; e Construir por Funcionalidade conforme pode ser visualizado na figura abaixo.
Figura 2 - Ciclo de vida do FDD

(Fonte: COAD, 2000)

Como visto na Figura 3, o FDD conta com uma fase seqencial composta pelos trs primeiros processos, enquanto os dois ltimos compem a parte iterativa do processo. So estes processos, da parte iterativa, que evidenciam as caractersticas do FDD como um processo gil de desenvolvimento. Como a modelagem da funcionalidade, no processo quatro, ocorre imediatamente antes da construo, permite sem maiores problemas, mudanas tardias nos requisitos. Cada iterao, formada pelo

28 quarto e quinto processos, finalizando a construo de uma

funcionalidade, tem a durao mxima de duas semanas. Um detalhamento dos processos ser apresentado a seguir. 2.2.6.1 Desenvolvimento de um Modelo Global O processo Desenvolvimento de um Modelo Global tem como objetivo garantir que o sistema seja devidamente compreendido antes que se inicie o desenvolvimento. Seu formato lembra diagramas de entidaderelacionamento, contendo, neste momento, mais forma que contedo. 2.2.6.2 Construir uma Lista de Funcionalidades Portando as descries do modelo global, pode-se construir a lista de funcionalidades do sistema a ser desenvolvido. Nesta lista, ser apresentada pelo time de desenvolvimento, cada uma das funcionalidades do sistema, sempre tendo em vista o seu valor percebido. Estas funcionalidades (Features) so extradas em ordem hierrquica e devem ser divididas de acordo com a sua relevncia dentre as subreas do domnio (Major Feature Sets) e divididas novamente, agora dentro destas reas, em conjuntos de funcionalidades (Feature Sets). A lista de funcionalidades revisada e validada por usurios e patrocinadores do sistema, caso existam. Importante destacar, que o tempo mximo para a construo de cada funcionalidade no pode ultrapassar duas semanas. Dessa maneira, as funcionalidades mais complexas devem ser subdividas em duas ou mais funcionalidades. 2.2.6.3 Planejar por Funcionalidade Planejar por funcionalidade criar um plano em alto nvel, ordenando os conjuntos de funcionalidades numa seqncia, de acordo com a prioridade de cada conjunto e dependncias, caso existam. Neste processo necessrio que marcos sejam estabelecidos para os conjuntos de funcionalidades. Esses marcos servem para o

29 acompanhamento do progresso do desenvolvimento dos conjuntos de funcionalidades. A execuo detalhada e cuidadosa deste processo trar benefcios na construo do sistema nos prximos processos. Este planejamento deve considerar dependncias e prioridades, coerncia em relao alocao de recursos e sobrecarga de tarefas, na complexidade e risco das funcionalidades a serem implementadas, e no planejamento dos marcos do projeto. 2.2.6.4 Modelar por Funcionalidade e Construir por Funcionalidade Os dois ltimos processos do FDD sero descritos em conjunto, pois eles formam a fase iterativa do ciclo de vida. No processo Modelar por Funcionalidade, um grupo de funcionalidades selecionado, mas elas no necessariamente precisam pertencer ao mesmo conjunto de funcionalidades (Feature set), tambm so selecionados os times necessrios para desenvolver cada uma das funcionalidades escolhidas. Uma vez definidos os times, cada time comea a modelar e construir suas funcionalidades. Durante o processo de modelagem possvel que ocorra o levantamento de novos requisitos em funo do melhor entendimento da funcionalidade. Com essas dvidas sanadas e novos requisitos coletados, possvel evitar que o desenvolvimento atrase, ou seja, equivocado por falta de informao. Ao fim do processo de modelagem, inicia-se o quinto e ultimo processo do ciclo de vida, Construir por Funcionalidade, onde se constri efetivamente as funcionalidades escolhidas e modeladas no processo anterior. Resultando na finalizao das funcionalidades do pacote. Durante estes processos so realizas as atividades de inspeo de modelagem e codificao, teste unitrio e de integrao. Aps a finalizao de uma iterao, as funcionalidades que foram completamente construdas so integradas ao sistema principal e um novo conjunto de funcionalidades escolhido para a prxima iterao.

30 Novas iteraes so feitas at que todas as funcionalidades estejam construdas e atendendo os requisitos.

3 DEFINIO DO CENRIO

3.1 PROJETOS

DE

PEQUENO PORTE

Existem vrias maneiras de se classificar o porte de um projeto. No que se refere compatibilidade com a metodologia que ser proposta, resolveu-se adotar como parmetro as seguintes reas de conhecimento em gerenciamento de projetos: tempo, custos e recursos humanos. Quanto ao tempo de execuo do projeto, podemos considerar de pequeno porte um projeto com durao mdia de 1 a 6 meses, considerando desde a autorizao do projeto at a entrega completa e validada. Do ponto de vista do oramento, consideramos empiricamente como projetos de pequeno porte aqueles que se encaixam numa faixa de 2 mil at 20 mil reais. Analisando somente a quantidade de recursos humanos utilizados, admitimos como de pequeno porte projetos que englobam equipe interna de 2 a 10 pessoas.

31 Embora a variao entre os valores mnimo e mximo estipulados acima possa ser considerada uma faixa relativamente extensa, importante ressaltar que a rea de atuao da empresa altamente relevante para determinar essa classificao. De fato, a amplitude da variao descrita poderia ser ainda maior, todavia na ocasio deste trabalho de concluso de curso sero adotados os valores acima para definir projetos de pequeno porte 3.2 MODELOS

DE

NVEL

DE

MATURIDADE

EM

GERENCIAMENTO

DE

PROJETOS

Para conseguir estabelecer metodologias e procedimentos que se apliquem melhor aos projetos imprescindvel que as empresas conheam seu nvel de maturidade. Por meio desse conhecimento de seu nvel de maturidade que elas podero aumentar suas chances de sucesso nos projetos. O PMI publicou em 2003 seu modelo de avaliao de maturidade no gerenciamento projetos chamado OPM3 (Organizational Project Management Maturity Model). O OPM3 sugere um mtodo para as organizaes compreenderem seus processos de Gerenciamento de Projetos (GP) e medir suas capacidades para se preparar para melhorias. Existem outros modelos de anlise de maturidade como o Capability Maturity Model Integration (CMMI), o Internationals Project Framework (ISI), Project Management Maturity Model (PMMM) e o Modelo Prado-MMGP. A seguir, explicaremos alguns desses modelos.

3.2.1 Modelo OPM3

O modelo OPM3 o modelo desenvolvido pelo PMI conforme mencionado acima e pode ser traduzido como Modelo de Maturidade em Gerenciamento de Projetos Organizacionais. Sua aplicao est baseada em trs elementos: Conhecimento, Auto-Avaliao e Processo de Melhoria. O primeiro elemento, Conhecimento, sugere que a empresa deve conhecer o conjunto de conhecimentos que compem o modelo OPM3. Esse conjunto de conhecimento est representado sob a forma de

32 diretrios compostos pelos seguintes elementos bsicos: Boas Prticas, Capacidades ou Pr-Requisitos, Resultado, Indicadores Chaves de Desempenho (KPIs) e Caminhos e ligaes lgicas. O segundo elemento, Auto-Avaliao, formado por um questionrio de escolhas dicotmicas (sim ou no) no qual se deve responder sobre a presena ou no de processos associados ao gerenciamento de projetos. De acordo com o resultado encontrado, definida uma lista de Boas Prticas recomendada empresa. E o ltimo elemento, Processo de Melhoria, estabelece que com base na lista de Boas Prticas faa uma anlise e um plano com aes de melhorias mais apropriadas a situao encontrada que visem o alcance de uma maior maturidade.

3.2.2 Modelo CMMI

O modelo CMMI um modelo desenvolvido pelo SEI (Software Engineering Insitute) que procura formar um modelo nico para o processo de melhoria. Ele amplamente utilizado em organizaes que trabalham na rea de desenvolvimento e engenharia de software. O CMMI possui duas formas de representao: por estgios e contnua. Na forma estagiada existem cinco nveis de maturidade: Nvel I Inicial Nvel II Gerenciado Nvel III Definido Nvel IV Quantitativamente Gerenciado Nvel V Otimizado J na forma contnua h seis nveis de maturidade: Nvel 0 Incompleto Nvel I Realizado Nvel II Gerenciado

33 Nvel III Definido Nvel IV Quantitativamente Gerenciado Nvel V Otimizado A representao estagiada indicada para organizaes que j utilizam algum modelo de maturidade por estgios e que desejam comparar o nvel de maturidade alcanado com outras empresas. J a representao contnua indicada quando deseja melhorar a maturidade de apenas alguns processos e no pretende ter um modelo de comparao com outras organizaes.

3.2.3 Modelo Prado-MMGP

Desenvolvido pelo consultor Darci Prado e publicado em 2002, o modelo Prado-MMGP visa avaliar o grau de maturidade de um setor das organizaes. Esse modelo foi criado a partir das experincias prticas do autor em diversas empresas. um modelo que foi criado utilizando os seguintes critrios: simplicidade, utilizao dos mesmos nveis do modelo SW-CMM (Carnegie Mellon University), universalidade e avaliao de caractersticas dos setores relacionadas habilidade de executar projetos com sucesso. O modelo apresenta cinco nveis de maturidade, conforme a Figura 1, e a evoluo de cada nvel ocorre em seis dimenses.

34
Figura 3 - Dimenses e Nveis de Maturidade

(Fonte: http://www.mundopm.com.br/noticia.jsp?id=259)

Os Padronizado, Uso de

cinco

nveis e

de

maturidade J

so: as

Inicial,

Conhecido, so: e

Gerenciado

Otimizado.

seis

dimenses

Conhecimentos de Gerenciamento, Uso de Metodologia, Informatizao, Estrutura Organizacional, Relacionamentos Humanos Alinhamento Estratgico.

4 METODOLOGIA

35 Aps a apresentao do referencial terico, o objetivo do presente trabalho desenvolver uma proposta de metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade. Para isso, verificamos na pesquisa bibliogrfica que os conceitos oriundos das metodologias geis e do manifesto gil poderiam servir de norte para nossa proposta, tendo por base as boas prticas sugeridas pelo PMBOK. Deste modo, das metodologias geis, utilizamos o conceito baseado no princpio que desenvolver um projeto funcional mais importante que uma documentao detalhada. Ou melhor, processos e aes concretos que gerem resultados que atendam ao projeto so primordiais, ante a documentao excessiva. Os processos de iniciao de nossa metodologia esto permeados do conceito de modelagem prvia. Na coleta dos requisitos, para gerar um oramento do projeto, sugere-se um modelo global de ao, e durante o processo, o escopo vai se refinando e afunilando, at atingir a conformidade das entregas. H a locao de prioridades e a mudana de escopo bem vinda, corroborando com os valores defendidos pelas metodologias geis. A referncia que adotamos do PRINCE2, foi o fato que essa metodologia busca adequar a qualquer porte de empresa e tipo de projeto sua metodologia, e busca administrar o projeto por etapas, alm de basear-se em metas de desempenho: prazo, custo, qualidade, escopo e risco. Alm disso, h pontos de deciso flexvel durante o processo, ao se considerar que o escopo sofre refinamento, como poder ser verificado na apresentao de nossa metodologia. A presente metodologia est aberta ao questionamento, pois permite adaptaes a fim de ser melhor aplicada em determinado projeto e/ ou determinado ambiente, indo de encontro com que defende o PRINCE2. No que tange ao PMBOK, o guia convenciona que os processos de gerenciamento de um projeto se desenvolvem em ciclos que podem

36 ser agrupados em (1) Iniciao; (2) Planejamento; (3) Execuo; (4) Monitoramento e Controle; e (5) Encerramento. Examinando esta concepo, possvel verificar que os referidos ciclos de um projeto segundo o PMBOK trazem o amplamente reconhecido conceito de gesto intitulado de ciclo PDCA1 ao lxico do universo de gerenciamento de projetos. Assim, os cinco grupos de processos de gerenciamento permeiam inexoravelmente a atuao do gerente de projeto para o desenvolvimento coeso do mesmo, de forma estratgica. Analisando a dinmica do desenvolvimento de um projeto, desde o surgimento de uma determinada demanda at a implementao da soluo projetada, dos requisitos levantados s resolues adotadas, das informaes compartilhadas s tarefas realizadas, sobretudo considerando as variadas partes interessadas no projeto, podemos estabelecer abordagens distintas especialmente quanto ao fluxo de informaes, definio de aes e atribuies de responsabilidade. Como o intuito deste trabalho desenvolver uma metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade, subitamente decorrem pelo menos dois pressupostos. O primeiro priva por propor uma metodologia simplificada. Por exemplo, a destilao dos inmeros processos em diretrizes mais sintticas ou a adequao da terminologia empregada para palavras com significado mais claro e objetivo. O segundo aponta que, se a metodologia em questo ser praticada primordialmente pelo gerente de projeto, cuja maturidade reconhecida como baixa, que esta aborde os eventos privilegiando nitidamente o seu ponto de vista, e que as diretrizes sejam estabelecidas a partir da sua esfera de atuao. Apesar da aparente obviedade, tais premissas so decisivas na direo do presente trabalho. Pois, ao tomarmos por base as boas prticas
O ciclo PDCA (Plan-Do-Check-Act / Planejar-Fazer-Verificar-Agir) consiste em uma seqncia de passos utilizada para controlar qualquer processo definido. uma ferramenta que auxilia na organizao do processo de implementao de melhorias, dando uma diretriz para a conduo de tais projetos / processo. (GODOY, 2010. Disponvel em: http://www.cedet.com.br/index.php?/Tutoriais/Gestao-da-Qualidade/ciclopdca-plan-do-check-act-planejar-fazer-verificar-agir.html
1

37 do PMBOK, objetivamos identificar nos ciclos do projeto, as reas do conhecimento e os procedimentos estritamente relevantes e que geram impacto direto em pequenos projetos em ambientes de baixa maturidade, ou que exijam uma carga de objetividade e reduo de documentos maior. Em sntese, o grupo de Iniciao compreende o levantamento de todas as informaes para que seja possvel iniciar de fato o projeto. Pode-se admitir que o domnio deste grupo de processos essencialmente externo ao gerente, uma vez que necessrio buscar informaes junto a clientes, patrocinadores ou outras partes interessadas. Independentemente da metodologia praticada, o primeiro grupo onde se faz a leitura inicial do cenrio do projeto. Por sua vez, os processos de Planejamento encontram-se pronunciadamente sob competncia do gerente de projeto. Aqui se estabelece o que ser de fato realizado e como se dar a conduo das atividades. Pode-se afirmar que o grupo de planejamento aborda a atribuio fundamental do gerente de projeto. O grupo relativo Execuo discorre sobre os processos evidentemente ligados s aes para gerar o produto, o servio ou o resultado especificado no planejamento. Embora o mbito da execuo admita eventual envolvimento direto do gerente, o guia PMBOK no alega sua obrigatoriedade. Assim, ainda que o gerente execute as atividades por ele planejadas ao invs de deleg-las, a incumbncia da execuo do projeto no se encontra na esfera gerencial. Os processos de Monitoramento e Controle estabelecem, em suma, mecanismos de avaliao e resposta quanto ao andamento ou desempenho da execuo. Tais processos tm o nico objetivo de garantir a obteno dos resultados conforme o planejamento. Em outras palavras, compara o executado com o planejado. Assim, embora o Monitoramento e Controle ocorra em absoluta sincronia com a execuo, enquanto processo de gerenciamento compreende como continuao da atividade de planejamento. Dessa forma, retornamos ao ncleo de competncia do gerente de projeto.

38 O ltimo grupo de processo, o grupo de Encerramento ocorre quando o projeto atinge seus objetivos ou quando, por algum motivo, ele finalizado antes do alcance final dos objetivos planejados. nesse processo que deve ser conferido as entregas, encerrados os contratos, desmobilizada a equipe, assinado o aceite final pelo cliente, entre outras atividades. Adiante, ser possvel entender o esprito de nossa proposta, cuja plataforma so as boas prticas do gerenciamento de projetos segundo o PMBOK e os conceitos, valores e inteno de praticidade e desburocratizao dos procedimentos, mais alinhados a empresas de nvel baixo de maturidade e projetos de pequeno porte, so oriundos do que defende e apresenta as metodologias geis e o PRINCE2.

5 APRESENTAO E ANLISE DE RESULTADO

O objetivo de desenvolver a proposta de metodologia para gerenciamento de pequenos projetos em ambientes de baixa maturidade, alm da imerso no referencial terico citado, requer selecionar das abordagens analisadas as prticas mais relevantes para o nosso cenrio. Com isso, encontramos os seguintes processos (em ordem seqencial) que acreditamos serem os processos mais significativos para o gerenciamento de pequenos projetos em ambientes de baixa maturidade. No grupo de processos de Iniciao, os processos de Gerar oramento, Apresentar Proposta e Autorizar Projeto esto compondo-o. Dentro do processo de Gerar Oramento fazem parte tambm Coletar requisitos, Definir entregas com viso macro, Estimar trabalho das entregas, Identificar riscos e medidas preventivas, Identificar possveis aquisies e Estimar custos e Gerar Preo. O grupo de processos de Planejamento composto pelos processos Refinar Coleta de Requisitos, Criar EAP, Definir equipe do projeto, Identificar atividades definindo tempo e recursos, Criar Cronograma, Definir Canal de Comunicao e Planejar Aquisies.

39 J no grupo de Execuo, os processos presentes so Tomar medidas preventivas aos riscos, Executar aquisies e Orientar e gerenciar a execuo do trabalho. No grupo Monitoramento e Controle temos trs processos: Realizar o controle integrado de mudanas (sob demanda), Reportar status (de acordo com os marcos adotados) e Verificar escopo. Por ltimo, no grupo de Encerramento temos o processo de Encerrar o projeto. Podemos verificar os processos e seu seqenciamento na figura abaixo.

Figura 4 - 17 Processos da Metodologia Proposta

37

(Fonte: autores)
PROCESSO DE INICIAO
Gerar Oramento
Refinar Coleta dos Requisitos

PROCESSOS DE PLANEJAMENTO
Identificar Atividades definindo tempo e recursos

LEGENDA
INTEGRAO RISCO

Criar a EAP

Criar Cronograma

Definir Canal de Comunicao

Planejar as Aquisies

ESCOPO

AQUISIO

TEMPO

COMUNICAO

Apresentar Proposta Comercial

PROCESSOS DE EXECUO

PROCESSOS DE MONITORAMENTO E CONTROLE

PROCESSOS DE ENCERRAMENTO

Autorizar do Projeto

Tomar Medidas Preventivas ao Risco

Executar Aquisies

Orientar e Gerenciar a Execuo do Projeto

Realizar o controle integrado de mudanas

Reportar Status

Verificar o escopo

Encerrar o projeto

38 A partir da figura 4, acima mencionada, podemos descrever cada processo, lembrando que os processos esto numa seqncia que deve ser seguida para a melhor eficcia da metodologia proposta. Dentro do grupo Iniciao, o processo Gerar Oramento composto por outros componentes, conforme pode-se verificar na figura 5.
Figura 5 - Etapas do processo Gerar Oramento

COLETAR REQUISITOS

DEFINIR ENTREGAS COM VISO MACRO

ESTIMAR TRABALHO DE ENTREGAS

IDENTIFICAR RISCOS E MEDIDAS PREVENTIVAS

IDENTIFICAR POSSVEIS AQUISIES

ESTIMAR CUSTOS Em Coletar Requisitos, pode-se considerar basicamente como a compreenso da idia do cliente, atravs de um briefing para embasar o escopo da proposta. Em Definir Entregas com Viso Macro, gera-se uma prvia da EAP somente com as entregas maiores, demonstrando, em alto nvel, a soluo proposta para o projeto que ir materializar a idia do cliente em forma de produto. J o componente Estimar Trabalho das Entregas prope a estimativa, atravs da anlise do trabalho para as entregas previstas no

39 item Definir Entregas com Viso Macro, o tempo de execuo estimado, para se chegar a um prazo de concluso do projeto. O quarto componente Identificar Riscos e Medidas Preventivas informa que preciso identificar riscos para o projeto que possam impactar em um aumento de custos ou prazo e, para aqueles que podem ser prevenidos, identificar quais as medidas preventivas a serem adotadas. Depois de definidos pode ser que tenha que fazer alguns ajustes nos prazos definidos no componente anterior. Aps a identificao dos riscos e medidas preventivas, preciso Identificar Possveis Aquisies. Neste componente, como o prprio nome diz, devem-se identificar as aquisies necessrias para completar o projeto. Em se tratando de projetos de pequeno porte, consideramos nestas aquisies somente compra de insumos para as atividades, como materiais ou a contratao de servios de terceiros, desde que sejam pontuais, que a equipe de projeto precise somente do resultado deste servio. Alm de identificar, necessrio fazer uma pesquisa pra identificar custos dessas aquisies, mesmo que no sejam valores precisos. Novamente podem ser feitos ajustes de prazos definidos em Estimar Trabalho das Entregas devido a tempo de entrega de alguma das aquisies. E o ltimo componente do processo Gerar Oramento Estimar Custos. Nele deve-se ser estimado os custos de execuo das atividades, adicionando-se os valores das aquisies identificadas, custos para a tomada de medidas preventivas para mitigar riscos, entre outros. Em seqncia ao processo Gerar Oramento, vem o processo Apresentar Proposta Comercial. Atravs da estimativa de custos realizada no processo anterior, devem ser adicionados os valores empresariais envolvidos na proposta como rateios administrativos pelo tempo de durao do projeto, parcela de lucro, entre outros, para gerar o preo total do projeto.

40 neste momento tambm que se deve definir um prazo passvel de entrega do projeto concludo, com base nas estimativas de tempo gerada pelos processos Estimar Trabalho das Entregas, Identificar Riscos e Medida Preventivas e Identificar Possveis Aquisies. Para terminar os processos do grupo Iniciao, temos o processo Autorizar do Projeto. Este processo a autorizao formal, junto ao patrocinador, do projeto, seja registrada atravs de um simples email ou assinatura de contratos. O segundo grupo de processos o Planejamento. Neste grupo temos os seguintes processos: Refinar Coleta de Requisitos, Criar EAP, Identificar Atividades definindo Tempo e Recursos, Criar Cronograma, Definir Canal de Comunicao e Planejar Aquisies. Aps a autorizao do projeto, onde j esto acordados os recursos e prazo limite, deve-se detalhar, tanto quanto possvel, todos os requisitos do escopo do produto, refinando a coleta de requisitos e pesquisas feitas durante o processo de Gerar Oramento. Assim, deve-se consultar especialistas, realizar visitas tcnicas, questionar o cliente para sanar todas as dvidas que envolvem o escopo. Uma vez definidos com requisitos, passa-se ao processo de gerar EAP (Estrutura Analtica De Projetos). Neste processo, as entregas e os pacotes de trabalho que as compe devem ser definidos com preciso. Julgamos como importante a criao de um Dicionrio de EAP para que seja identificada, de forma simples e direta, uma breve descrio da entrega, bem como seu critrio de aceitao, para que possa servir de consulta para a equipe do projeto. O prximo processo Identificar Atividades definindo Tempo e Recursos onde as atividades que compe cada um dos pacotes de trabalho so identificadas juntamente com seu tempo de durao de desenvolvimento, alm da identificao dos insumos que sero necessrios e quem sero os colaboradores que desempenharo cada atividade. Desta forma, com a soma dos colaboradores envolvidos com a equipe de gesto, se define a equipe do projeto.

41 Com a finalizao do processo Identificar Atividades definindo Tempo e Recursos possvel seqenciar as atividades, encadear dependncias, e com isso, chegar a um cronograma de atividades. Para esse processo, damos o nome de Criar Cronograma. Na seqncia, vem o processo Definir Canal de Comunicao. Neste processo, deve ser definido de forma simples e direta quem so os responsveis pela tomada de decises tanto do lado da empresa contratada, geralmente o prprio gerente do projeto, neste caso, quanto do lado do cliente. Outro aspecto importante definir um canal oficial de comunicao. Mesmo que seja uma forma de registro no to formal, como um email por exemplo. E para finalizar, ajudando tanto a controlar as expectativas do cliente, quanto evitar surpresas quando no h mais tempo de tomar medidas, deve-se definir a freqncia com que o gerente do projeto deve reportar status do projeto para o responsvel do lado do cliente. As aquisies devem ser planejadas neste prximo processo: Planejar Aquisies. Os produtos que sero adquiridos em funo da necessidade, como insumo para atividades das listadas, ou qualquer outra coisa que seja comprada deve ser planejada aqui, seja produto que vai ser consumido, que sirva de apoio, que v junto com o produto para o cliente ou que fique como legado para a empresa. Estes foram os processos do segundo grupo de processos, o grupo de Planejamento. Execuo. O grupo de Execuo formado por trs processos: Tomar Medidas Preventivas aos Riscos, Executar Aquisies e Orientar e Gerenciar a Execuo do Trabalho. No processo Tomar Medidas Preventivas aos Riscos, iremos realizar as medidas j identificadas no processo Identificar Riscos e Medidas Preventivas realizado no grupo de Iniciao caso haja necessidade. Como em um projeto pequeno no h pessoas e/ou oramento suficientes, essas medidas so medidas preventivas de riscos Agora, veremos os processos do grupo de

42 que esto ao alcance e controle da equipe do projeto. Riscos envolvendo probabilidades como clima, no sero identificados e no tero suas medidas preventivas tomadas. Aps, as aquisies sero efetuadas, no processo Executar Aquisies. nesse processo que realmente sero executadas as compras que foram planejadas no processo de Planejar Aquisies. O prximo processo, Orientar e Gerenciar a Execuo do Trabalho o processo onde o gerente do projeto ir orientar e gerenciar a execuo de todos os processos planejados anteriormente. Este processo muito importante, pois como os projetos sugeridos para adotar essa metodologia so projetos pequenos, nesse processo na figura do Gerenciar a Execuo que o monitoramento e controle sero desenvolvidos juntamente. Aps a execuo do processo Orientar e Gerenciar a Execuo do Trabalho, entramos nos processos do grupo de Monitoramento e Controle. O grupo de monitoramento e Controle formado por trs processos. O primeiro processo o Realizar o Controle Integrado de Mudanas. Esse processo um processo que ser feito sob demanda, ou seja, caso o cliente solicite alguma alterao ele realizado. Muitas vezes ele ser realizado durante a prpria execuo do projeto. O segundo processo do grupo Reportar Status. Esse reporte dever ocorrer de acordo com a freqncia estabelecida no Canal de comunicao para que o cliente saiba como est o andamento do projeto, e para que a equipe do projeto saiba como est o andamento das expectativas do cliente. O terceiro e ltimo processo deste grupo o Verificar Escopo. Este processo um marco para entrarmos no grupo de Encerramento. Este processo muito importante, pois nele que se verifica se o escopo est ok, incluindo tambm a verificao da qualidade para garantir que o projeto seja entregue conforme especificado. Aps esse processo, entramos no ltimo processo da metodologia, que o processo Encerrar o Projeto que faz parte do grupo

43 de Encerramento. Nele, ser realizado o aceite formal do cliente seja atravs de um email ou de um contrato.

6 RECOMENDAES
O presente trabalho visa a criao de uma metodologia de gerenciamento de pequenos projetos em ambientes de baixo nvel de maturidade, qualquer que seja o projeto, qualquer que seja a empresa. Porm, percebeu-se no decorrer do desenvolvimento do mesmo, que essa metodologia melhor se aplicaria em projetos de servio. Isso no impede a utilizao da mesma em projetos de outra natureza, apenas que para projetos de servio, foi percebido que a metodologia proposta poderia ser de uma mais fcil aplicao e trazer resultados mais imediatos do que em outros tipos de projetos, como por

44 exemplo projetos de desenvolvimento de produtos, processos, entre outros.

7 CONCLUSO
Em todo nosso processo de desenvolvimento acadmico relacionado ao Gerenciamento de Projetos, privamos em adaptar as boas prticas do PMOK a nossa realidade, alm de evidenciar empiricamente, em diferentes nveis de conhecimento de gesto de projetos por parte das empresas e de quem as coordena, o carter estratgico dos projetos para as empresas no ambiente econmico atual.

45 Assim, das principais doutrinas de gerenciamento de projetos, buscou-se aqui compilar os aspectos e processos mais adequados ao cenrio de pequenos projetos em ambiente de baixa maturidade gerencial. O resultado dessa anlise rene o pragmatismo no planejamento e a interatividade das Metodologias geis com os princpios de gesto do conhecimento e controle do PMBOK. Por focar em projetos de pequeno porte, a metodologia tende a ser mais enxuta e objetiva que as metodologias convencionais, e busca propiciar um bom gerenciamento de projetos, sem comprometer seu custo e seu prazo com muitos documentos e aes que no se enquadrem no contexto de projetos de pequeno porte e em empresas de baixo nvel de maturidade. Uma vez que a metodologia aqui proposta ainda no tenha sido submetida experimentao real, sugerimos a aplicao da mesma para validar ou no sua eficcia. Alm do que, vislumbra-se possvel, obter seu aprimoramento, visto que, principalmente as metodologias geis, que hoje em dia, so comuns no setor de Tecnologia da Informao, tm muito a oferecer para o aprimoramento na gesto de projetos em setores mais convencionais e menos maduros nesse tipo de governana, pois privilegiam a simplicidade das aes, o aprimoramento do conhecimento das equipes e os processos enxutos de documentao. Deste modo, a adoo de projetos e seu gerenciamento de forma adequada ser uma constante em todo e qualquer tipo de empresa, observando as devidas propores. Assim, toda e qualquer ao que vise melhorar essa realidade, oferecendo o aprimoramento da gesto das empresas e de seus projetos valida e inestimvel para alcanar a sustentabilidade, no s dos grupos econmicos, mas de toda economia.

BIBLIOGRAFIA

VILA, S. & VALADARES, L. Planos de comunicao em projetos de Engenharia. Artigo de concluso do curso da Ps-Graduao em Gesto

46 de Projetos promovida pela PUC-Minas (IEC), coordenador do curso Prof. Clemenceau Chiabi, 2009. Disponvel em: http://www.ipma.com.br/artigosmainmenu-25/102-planos-de-comunica-em-projetos-de-engenharia.pdf BARBOSA, A. Metodologia gil: Feature Driven Development. Disponvel em: http://paginas.fe.up.pt/~aaguiar/es/artigos %20finais/es_final_22.pdf. Acessado em: 06 de abril de 2007. COAD. P. et al. Java Modeling. In: Color With UML. 2000 GODOY, A. L. Ciclo PDCA. Verso: 25/03/2010 Veculo: CEDET Centro de Desenvolvimento Profissional e Tecnolgico. Disponvel em: http://www.cedet.com.br/index.php?/Tutoriais/Gestao-da-Qualidade/ciclopdca-plan-do-check-act-planejar-fazer-verificar-agir.html. Acessado em: 01 de maro de 2011. HIGHSMITH, J. History: The Agile Manifesto, 2001. Disponvel em: http://www.agilemanifesto.org/history.html. Acessado em: 06 de abril de 2007. MARTINS, D.; CELESTINO, F.R.; MAZUR, J.O.; STIVAL, M.; OLIVEIRA JR, W.R. A anlise da maturidade e recomendaes de melhores prticas de gerenciamento de projetos em empresas de pequenos porte de desenvolvimento de software. Trabalho de concluso do curso Gerncia de Projetos pela FGV, coordenador do curso Prof. Carlos A. C. Salles Jr, 2009. OSHIRO A. K; NOVELLI A. D. P; CASELI H. M; LUCENA P. Extreme Programming, um novo modelo de processo para o desenvolvimento de software. 2006. Disponvel em: http://www.dc.ufscar.br/~rosangel/mds/Aula-09-XP/ArtigoXP.pdf. Acessado em: 01 de agosto de 2007

47 PMI (Project Management Institute). Project Management Body of Knowledge 2004. PRADO, D. Maturidade Notcias e o em Gerenciamento de Projetos. Data: Seo: em: Disponvel

28/04/2008 Veculo: Revista MundoPM-Project Management Mercado.

http://www.mundopm.com.br/noticia.jsp?id=259. Acessado em: 08 de janeiro de 2011. PRESSMAN, ROGER S. Engenharia de Software. (6 edio), So Paulo, Ed. McGrawHill, 2006. RIBEIRO, R. Qual melhor, PRINCE2 ou PMBOK Guide? Postagem: 29/03/2010. guide/ TONINI, A. C.; CARVALHO, M. M.; SPINOLA, M. M. Contribuio dos modelos de qualidade e maturidade na melhoria dos processos de software. Produo, v. 18, n. 2, p. 275-286, 2008. Disponvel em: http://www.scielo.br/pdf/prod/v18n2/06.pdf. Acessado em: 23 de maro de 2011. TURLEY, F. The PRINCE2 Training Manual. Version 1.0g. United Kingdom, MgmtPlaza Affiliate of TAG, 2010. VALLE, A. B. do, SOARES, C. A. P., FINOCCHIO JR., J., SILVA, L. S. F. da. Fundamentos do Gerenciamento de Projetos. Rio de Janeiro: Ed. FGV, 2007. Site: WWW.2rprojetos.com. Disponvel em: http://www.2rprojetos.com/2010/03/29/qual-e-melhorprince2-ou-pmbok-

48

APNDICES POR AUTOR INDIVIDUAL

9.1 DOUGLAS LAURINDO

ADAPTAO DA METODOLOGIA PROPOSTA AO DESENVOLVIMENTO DE SIMULADORES.

Introduo Em contraponto a realidade na qual discorreu o

desenvolvimento deste trabalho, que se situava em ambientes de baixa ou nenhuma maturidade em gerenciamento de projetos, para projetos de curto prazo, poucos envolvidos e oramento baixo, existem projetos em ambientes de muita maturidade, e projetos enormes tanto em prazo quanto oramento e equipe. Em algum ponto intermedirio existem os projetos, que esto sendo considerados de mdio porte, com prazos entre 10 a 12 meses, at 15 pessoas envolvidas diretamente em seu desenvolvimento e oramento entre 80 e 350 mil reais. este tipo de projeto que ser referenciado aqui. Cenrio Uma vez definido o tipo do projeto, preciso definir o ambiente. A metodologia ser adaptada a um ambiente que j tem o conceito de projeto bem estabelecido, com uma estrutura organizacional matricial, tendendo fortemente projetizada, tendo como fator que ainda

49 a mantm matricial a alocao de recursos quando em momentos entre projetos, em pesquisa e desenvolvimento, e seus custos devem ser vinculados a algum centro de custo, por isso o conceito de setor. Outro ponto importante a ser definido sobre o ambiente sua rea de atuao: desenvolvimento de simuladores. Neste contexto de simuladores pode-se considerar simuladores tanto com foco em treinamento quanto demonstrao, e para os mais variados ramos do mercado como, por exemplo, agrcola, automao industrial, maquinas pesadas ou transito. Estes simuladores so, sem sua maior parte, o que chamamos de softwares embarcados, ou seja, softwares desenvolvidos para serem executados em um hardware especifico, tambm considerado entrega do simulador. Seguindo este contexto, ser apresentada uma adaptao da metodologia proposta para esta nova realidade. Adaptao A metodologia proposta como base para este trabalho pode ser aplicada tambm no cenrio do desenvolvimento de simuladores, mas por se tratar de software e ter um ambiente habituado ao gerenciamento de projetos, possvel inserir algumas mudanas capazes de dar mais leveza e dinamismo metodologia, para que se encaixe melhor ao cenrio. A modificao mais importante trata da diviso da fase de planejamento para incluso de uma fase interativa. A segunda alterao envolve a substituio de alguns processos. A abaixo segue imagem da metodologia aps estas alteraes.

50

A seguir sero demonstrados os processos por grupo de processos, incluindo a nova diviso com duas partes de planejamento e a parte interativa. Processos Processos de Iniciao

Os processos de iniciao se mantm inalterados ao que foi sugerido anteriormente, o que vale anotar neste momento que o processo Gerar Oramento com todas as suas componentes deve tomar mais tempo e ter tanto detalhamento quanto possvel, pois se tratando, principalmente, de um escopo mais complexo e aquisies de maior porte, os riscos aumentam.

51 Processos de Planejamento Linear

Primeira fase do planejamento aps a autorizao do projeto. Esta fase conta com 3 processos: Refinar da EAP, Seqenciar Entregas e Definir Canal de Comunicao. Estes processos sero descritos em detalhes a seguir. Refinar EAP Neste processo se deve detalhar melhor as entregas, definir entregas menores para as entregas maiores definidas em Gerar Oramento; Seqenciar Entregas A partir do resultado do processo anterior, com a EAP mais detalhada, deve-se seqenciar as entregas em nvel de importncia. Pode ser por mais urgncia ou por dependncia entre as entregas. Isto acontece pois a equipe de desenvolvimento costuma ser compartilhada entre atividades da mesma natureza Definir Canal de Comunicao O canal de comunicao deve ser estabelecido e comunicado. Este canal geralmente atravs da troca de emails dos responsveis pelo lado do cliente, da empresa e de eventuais parceiros.

52 Fase Iterativa A partir deste ponto em que a maior diferena aparece. Deste momento em diante os processos passam a ser com foco na entrega. Os processos de planejamento interativo, execuo e monitoramento e controle so feitos sempre olhando entrega a entrega, seguindo a seqncia definida no planejamento linear. Processos de Planejamento Iterativo

O grupo de processos de planejamento interativo conta com 3 processos: Refinar coleta de Requisitos, Identificar Atividades definindo tempo e recursos, e Planejar as Aquisies. Refinar coleta de Requisitos A coleta de requisitos, neste momento, deve ser to detalhada quanto possvel, contando com pesquisas, documentos, visitas tcnicas, referncias visuais com fotos e vdeos, para servir de subsidio para o prximo processo. Identificar Atividades definindo tempo e recursos Tomando como base a coleta de requisitos refinada, deve-se identificar as atividades para gerar o resultado da entrega. Estas atividades devem ter estimativa de tempo e definio do colaborador que

53 a executar, alem da organizao de dependncias e seqenciamento. Com isso pode-se gerar o cronograma da entrega. Planejar as Aquisies Quando se trata de softwares embarcados, geralmente tem-se que adaptar equipamentos j existentes, adquirir peas, componentes ou at mesmo licenas de softwares intermedirios de suporte. Estas aquisies devem ser planejadas especificamente, com descries, modelos, custos e fornecedor. Processos de Execuo

Esta fase no se difere da fase de execuo da metodologia proposta inicialmente, exceto pelo fato de que ser a execuo da entrega e no do projeto completo. Processos de Monitoramento e controle

54 Os processos de monitoramento e controle tm dois

momentos, o primeiro que no tem ordem especifica, ocorre durante todo o planejamento iterativo e o ultimo processo que s executado quando a entrega est pronta para ser encerrada. Os processos so: Controlar Escopo, Controlar Cronograma e Verificar Escopo. Controlar Escopo No processo de controlar escopo deve-se monitorar para que o escopo do projeto no seja modificado de forma negativa, e caso seja realmente necessrio, que essa mudana seja feita de forma responsvel e com o menor impacto possvel. importante lembrar que no basta controlar o que envolve a entrega atual, mas verificar o impacto sobre entregas j desenvolvidas. Com relao mudanas a entregas que esto por vir, a preocupao deve ser somente o impacto em tempo e, conseqentemente, custo, pois seu refinamento no foi executado ainda. Controlar Cronograma Neste processo deve-se avaliar e monitorar o desempenho e produtividade do desenvolvimento das atividades que compe a entrega. Se necessrio deve-se tomar providencias para evitar atrasos. Vale lembrar que ao controlar o cronograma, na prestao de servios, controla-se tambm os custos do projeto.

Verificar Escopo Este processo deve ser executado sempre que a iterao acabar, para confirmar se o resultado representa o escopo planejado e, caso esteja correto, integra as entregas concludas, caso haja alguma conformidade, o processo iterativo desta entrega para correo das no

55 conformidades. Vale anotar que este processo executa em partes uma verificao de qualidade da entrega. Processos de Encerramento

Bem como os processos de iniciao, o processo de encerrar o projeto permanece inalterado. Concluso Com o conhecimento das boas praticas, uma parcela de viso de todo e algumas pequenas modificaes possvel aumentar em muito a eficincia de uma metodologia para se adequar rea de atuao da empresa.

9.2 MARCOS

DOS

SANTOS

A UTILIZAO DAS BOAS PRTICAS DO PMBOK CONECTADAS COM CONCEITOS ORIUNDOS DA

56

METODOLOGIA GIL NA PRESTAO DE SERVIOS DE CONTABILIDADE.

Nos dias atuais cada vez mais necessrio s empresas, independente do porte e do grau de maturidade na gesto de seus processos, buscar o aprimoramento e desenvolver novas formas de gerir seus negcios. E na prestao de servio contbil no diferente, visto que esse mercado bastante concorrido, e a qualidade no atendimento e no servio e a garantia de proporcionar segurana so primordiais. O prestador de servio contbil tem que estar diariamente em contato com a legislao vigente e realizar uma conexo constante nas diferentes reas (trabalhista, previdenciria, tributria federal e estadual) a fim de executar suas funes e prestar uma assessoria de qualidade. Deste modo, um dos caminhos que podem permitir ao prestador de servio contbil alcanar um diferencial estratgico a adoo das boas prticas do Gerenciamento de Projetos a fim de definir melhor seu escopo de trabalho ao cliente, ao se orientar por projetos. Verifica-se tambm vivel anexar a esses procedimentos, conceitos das metodologias geis, a fim de customizar uma metodologia, ou no mnimo, adotar procedimentos, geis e simplificados no gerenciamento de projetos e alcanar resultados que possam ser controlados e verificados em um processo contnuo de anlise e aprimoramento do conhecimento. Porm, importante demonstrar aqui os dilemas que essa inovao enfrenta. A prestao de servio um desempenho essencialmente intangvel, que no resulta na propriedade de algo. O servio pode ou no estar ligado a um produto fsico. Ainda, segundo a definio de Gronroos (1995, p. 36):
o servio uma atividade ou uma srie de atividades de natureza mais ou menos intangvel que normalmente, acontece durante as interaes entre clientes e empregados de servios e ou fsicos e ou sistema do fornecedor de servios que fornecida como soluo ao (s) problemas (s) do (s) cliente (s).

57

Definir com qualidade, ou atingir com a mesma eficincia a conformidade do escopo do produto fator crucial na prestao de servio, visto que ainda conforme Cronroos (1995) a qualidade de percebida de um servio pode ter duas dimenses: tcnica e funcional. A dimenso tcnica est relacionada com o resultado do processo que produz um determinado servio, e se refere a o que o cliente recebe e ao que fica com o cliente quando o processo de produo termina. Enquanto que a funcional est relacionada ao processo de produo de servio, ou seja, a como o cliente recebe e vivencia o servio. Em se tratando da prestao de servios contbeis, a grande dificuldade do prestador de servios deixar claro para o cliente o que lhe entregue, visto que as entregas muitas vezes no so ao cliente diretamente, mas aos rgos governamentais ou a terceiros (instituies financeiras e outros). Contudo, ao se dedicar ao Gerenciamento de Projetos, uma das sadas para definir melhor esse campo, deixando claro o entregvel, o conceito de marco, uma entrega factual que demarca o trmino de uma fase, quando de domnio do prestador de servio contbil ser uma arma para permitir uma visualizao do cliente ao que adquire. Podemos perceber que o cliente, em uma prestao de servios contbeis ao fechar um contrato de prestao de servio est adquirindo um corpo fsico baseado estritamente em documentos, mais est adquirindo uma sistemtica segura de contabilizao do seu patrimnio e reporte ao fisco e outras obrigaes acessrias. Faz-se necessrio delimitar para o cliente os processos e procedimentos que justificam o preo que ele para por determinado servio contbil, que em contrapartida lhe garantem controle e segurana fisco-econmica. Outro campo que o Gerenciamento de Projetos pode ajudar o prestador de servios contbeis e na definio e sustentabilidade do planejamento corporativa :
o modelo de decises de uma empresa que determina e revela seus objetivos, propsitos ou metas, produz as principais

estratgico.

Segundo

Mintzberg

(2006)

estratgia

58
polticas e planos para atingir essas metas e define o escopo de negcios que a empresa vai adotar (...).

Durante todo percurso de estudo em Gerenciamento de Projeto foi se cristalizando intrinsecamente a necessidade do prestador de servio buscar ferramentas que permitam agregar valor a prestao de servio, por meio de processos mais delimitados, na reduo da intangibilidade do escopo e na satisfao do cliente com um produto, no s desejado, como tambm melhorado e que supere as expectativas. E assim, tem-se sua verificado estratgia que de a adoo das boas prticas no gerenciamento de projetos permite ao prestador de servio contbil readequar mercado, adquirindo um diferencial competitivo pautado na eficincia dos processos, uma melhor definio do escopo e o realinhamento do escopo do negcio. Contudo na prestao de servio do setor contbil, por exemplo, verifica-se um terreno arenoso: como definir o que pode ser considerado projeto ou trabalho estritamente operacional? Conforme coloca Valle et alli (2007) os projetos compartilham de caractersticas comuns: agregam valor com o aprendizado contnuo por meio dos erros; tem carter temporrio, singular, e de desenvolvimento progressivo, em etapas incrementais, e diferentemente do trabalho operacional, que contnuo, os projetos devem atingir o objetivo traado e ser finalizado, enquanto que um trabalho operacional deve ter como objetivo a manuteno do negcio. O objetivo aqui no definir definitivamente o que da prestao de servio contbil estritamente operacional, para aquilo que considerado projeto. Podemos colocar da seguinte forma, muitas atividades possuem um carter operacional ao longo de toda prestao de servio, que baseada na confiana e controle contnuo das informaes, mas que dentro de um ano calendrio ou competncia (ms do ano) adquire um carter de projeto, pois dependendo das exigncias dos rgos governamentais e do prprio cliente tem seu escopo amplamente alterado e especificado, e com uma data de incio e trmino bem definidos.

59 Ainda segundo Vale at alli (2007) o Gerenciamento de Projetos :

a aplicao de conhecimento, habilidades, ferramentas e tcnicas s atividades do projeto a fim de atender as suas demandas, sendo realizado por meio da integrao dos seguintes processos: iniciao, planejamento, execuo, monitoramento e controle, e encerramento.

No que tange a utilizao das metodologias geis, as iteraes permitem que os processos sejam simplificados, sem falar que a documentao reduzida. Uma tcnica do Scrum, como exemplo, que permite o monitoramento e controle, adequada a agilidade da prestao de servio contbil o Daily Meetings, como prprio nome sugere so reunies dirias, com durao mdia de 30 minutos. Lideradas pelo Scrum Master (gerente de projetos), com o Scrum Team (time do projeto), geralmente os Stakeholers no participam dessa reunio. Nessa reunio deve-se apenas responder trs perguntas: O que voc fez desde a ltima reunio? Encontrou algum obstculo ou problema? Qual? O que vai fazer at a prxima reunio? Assim, podemos considerar que a adoo das boas prticas do Gerenciamento de Projetos, conjunta com os conceitos das metodologias geis permitem a profissionalizao da prestao de servio de contabilidade, visto que garantem o aprimoramento dos processos, define as linhas limtrofes entre o tangvel e o intangvel do escopo do produto (a prestao de servio contbil), alm de garantir um monitoramento e controle das atividades e desenvolve a gesto do conhecimento no setor de servios.

BIBLIOGRAFIA

GRONROOS, C. Marketing: Gerenciamento e Servios: a competio por servios na hora verdade. Rio de Janeiro: Campus, 1995. 377 p.

60 MINTZBERG, H. O processo da estratgia: conceitos, contextos e casos selecionados. 4 Ed. Porto Alegre: Bookman, 2006. TAVARES, A. Gerencia de Projeto com PMBOK e SCRUM: um estudo de caso. Trabalho de Concluso do Curso de Tecnologia da Informao (TI) da Faculdade Cenecista Nossa Senhora dos Anjos Gravata (SC), 2008. VALLE, A. B. do, SOARES, C. A. P., FINOCCHIO JR., J., SILVA, L. S. F. da. Fundamentos do Gerenciamento de Projetos. Rio de Janeiro: Ed. FGV, 2007.

9.3 PABLO VALENTINI

ADAPTAO DA METODOLOGIA DESENVOLVIDA PARA GERENCIAMENTO DE PEQUENOS PROJETOS GRFICOS EM AMBIENTE DE BAIXA MATURIDADE
INTRODUO O objetivo deste apndice adaptar a metodologia proposta a projetos especficos da rea de design. Para isso, o mesmo princpio de revisar, analisar, selecionar, excluir e fundir processos e prticas das metodologias abordadas, bem como da metodologia proposta pelo trabalho em grupo, permanece como linha mestra. Dessa maneira, espera-se adaptar a metodologia empregada para se adequar realidade profissional em questo. Em segundo plano, o presente apndice tem o intuito de estabelecer as bases para o desenvolvimento de uma nova metodologia para a rea de criao, que carece desse tipo de abordagem, a ser apresentado como artigo numa prxima ocasio.

61

CONTEXTO As nuances da rea de criao de projetos grficos, j abordadas anteriormente em seminrio durante o curso de Gerenciamento de Projetos, no so foco deste apndice. Limita-se aqui ento a definir mais especificamente o cenrio de pequeno porte e baixa maturidade dos projetos grficos. Os projetos grficos a serem tratados pela metodologia apresentada se enquadram bem na definio do cenrio do trabalho de concluso do curso. Tm durao mdia de 1 a 6 meses e raramente ultrapassam 1 ano, cabem no oramento em torno de mil a 20 mil reais e geralmente utilizam equipes de 2 a 10 pessoas. Quanto maturidade, basta declarar que projetos grficos so geralmente liderados por profissionais de criao, e no por gestores de formao. Mesmo no sendo foco do presente apndice, vale citar que existem estudos atualmente correlacionando a questo da criatividade falta de ateno, concentrao, inteligncia lgico-matemtica, percepo deficitria de tempo e seqenciamento de eventos, entre outros distrbios mentais como dislexia e TDA. O fato que o designer no est capacitado a gerenciar projetos plenamente. RESULTADOS Para adaptar a proposta de metodologia para gerenciamento de pequenos projetos grficos em ambiente de baixa maturidade fez-se necessrio revisar alm da prpria metodologia apresentada, toda a referncia bibliogrfica novamente, agora com foco no cenrio especfico de projetos grficos. Convencionou-se chamar aqui os produtos ou os objetos de entrega dos projetos grficos como artefatos. O intuito ajustar os termos utilizados na rea de tecnologia da informao como software, cdigo ou

62 sistema, para um termo adequado ao contexto do design, mas mantendose importante nvel de generalidade para no comprometer a abrangncia da metodologia a diferentes aplicaes dentro da prpria rea ou em disciplinas correlacionadas. Abaixo pode-se observar um resumo dos processos resultantes da metodologia desenvolvida pelo trabalho em grupo: 1. Iniciao 1.1 1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.3 1.4 2.1 2.2 2.3 2.4 2.5 2.6 2.7 3.1 3.2 3.3 4.1 4.2 Gerar oramento Coletar requisitos Definir entregas com viso macro Estimar trabalho das entregas Identificar riscos e medidas preventivas Identificar possveis aquisies Estimar custos Gerar preo Apresentar proposta Autorizar projeto Refinar coleta de requisitos Criar EAP Definir equipe do projeto Identificar atividades definindo tempo e recursos Criar cronograma Definir canal de comunicao Planejar aquisies Tomar medidas preventivas aos riscos Executar aquisies Orientar e gerenciar a execuo do trabalho Realizar o controle integrado de mudanas (sob demanda) Reportar status (de acordo com os marcos adotados)

2. Planejamento

3. Execuo

4. Monitoramento e Controle

63 4.3 Verificar escopo (marco para o encerramento)

5. Encerramento 5.1Encerrar o projeto (aceite formal do cliente) A seguir pode-se verificar uma reviso dos principais conceitos das metodologias geis estudadas, considerando-os agora com breves adaptaes ao contexto de projetos grficos, apenas para melhor compreenso da terminologia. Do manifesto gil extraiu-se os seguintes princpios: - Indivduos e iteraes so mais importantes que processos e ferramentas; - Soluo funcional mais importante que documentao detalhada; - Colaborao do cliente mais importante que negociao de contratos; - Responder s mudanas mais importante que seguir um plano. Da metodologia Scrum, considerou-se adotar ciclo de vida iterativo e incremental com revises rpidas e constantes. Dessa forma a mudana ou incluso de requisitos e prioridades no se torna um problema ou agravante. Nesse caso recomendado que a equipe tenha profissionais experientes, uma vez que tm funes bem definidas. Abaixo segue algumas premissas da utilizao do mtodo: - Funciona bem para identificar rapidamente qualquer mudana no escopo. - Leva em conta equipes experientes e auto-gerenciveis. - Prazos so dados pela mdia aritmtica consultada junto aos profissionais. - S est pronto quando conferido que o que foi pedido est pronto. - A praxe dita pagamento de honorrios contra entregas.

64

Os princpios do Scrum a serem considerados so: - Equipes pequenas (organizadas de forma que cada um explore o mximo de suas habilidades, otimize a comunicao, para superar mais rapidamente os obstculos atravs da troca de conhecimentos e minimizar a necessidade de superviso); - O processo deve prever a necessidade de modificaes tanto em nvel de requisitos quanto em nvel tecnolgico (para que possa ser produzido o artefato com a maior qualidade); - O processo deve produzir prottipos freqentes (que possam ser testados e inspecionados); - As funes das equipes e trabalhos devem estar bem definidas e bem dividas (conforme o produto vai sendo construdo, a cada prottipo, vo sendo feitos os documentos e os testes); Em relao s partes interessadas no projeto, o Scrum elenca os seguintes papis no seu desenvolvimento: Patrocinador: representante do cliente, define requisitos e

prioridades de entrega, ordenando assim o desenvolvimento e validando os prottipos. - Gerente do projeto: geralmente o mais experiente do grupo e conhecedor da metodologia. - Time de desenvolvimento: equipe pequena de at 10 profissionais, todos com funes bem definidas de acordo com o projeto e rea de conhecimento. Segundo PRESMAN o Scrum se desenvolve nas fases de (1) requisitos, (2) anlise, (3) projeto e (4) evoluo ou entrega. Assim, adaptando o fluxo de trabalho ou ciclo de vida de um projeto baseado na metodologia Scrum s prticas comuns da profisso de designer grfico, pode-se considerar os seguintes processos:

65

- Levantamento de requisitos - Lista de prioridades - Ordens de servio - Jornadas de desenvolvimento (de 1 a 4 semanas) - Reunies dirias (mximo 30 minutos em p) - Produo - Evoluo ou Entrega Do mtodo da programao extrema, ou XP, pode-se

considerar principalmente a documentao mnima, entregas rpidas e diminuio do custo para atender as necessidades dos clientes. Com isso pode-se reduzir os prazos e riscos de projeto. Conforme OSHIRO recomenda, a metodologia indicada para projetos que compreendam: - Grupos de 2-10 desenvolvedores; - Integrao total entre desenvolvedores, gerentes e clientes; - Possibilidade de gerar prottipos com muita frequncia; Comprometimento de todos os integrantes da equipe de desenvolvimento para no comprometer a alta produtividade; - Comunicao com o cliente deve ser imediata, a pessoa por parte do cliente que faz contato com a equipe deve ter liberdade para tomar decises rpidas. Os valores bsicos do XP que podem ser adotados para o contexto so a comunicao, simplicidade, respostas rpidas (feedback) e coragem. Com relevncia para projetos grficos, do XP pode-se utilizar as seguintes prticas: - Planejamento breve: definio do valor funcional dos recursos pelo cliente, Estimativas geradas pelos desenvolvedores e Lista de prioridades; - Projeto simples: focado no valor de negcio do produto, a equipe desenvolve o projeto mais simples possvel que satisfaa os requisitos

66 atuais do cliente. No h a preocupao com requisitos futuros. Esses sero tratados quando aparecerem; - Cliente dedicado: todo projeto precisa de um cliente em contato constante com a equipe, fornecendo requisitos, ajustando prioridades e revisando o trabalho. Com essa relao direta e alta comunicao, existe a diminuio da documentao que tem uma grande representatividade no custo e tempo do projeto; - Uso de metforas: a equipe usa nomes e descries ao invs de termos tcnicos para facilitar a comunicao com o cliente; - Pequenas verses: baseados em ciclos curtos, a equipe entrega pequenas verses integrando o produto que est sendo desenvolvido; - Prototipagem: durante todo o processo de desenvolvimento o cliente valida os requisitos do produto, a equipe fornece um prottipo antes da produo completa para garantir que as especificaes esto sendo desenvolvidas a contento; - Desenvolvimento em duplas: os desenvolvedores se organizam em duplas para produzir, um modela e o outro contribui na lgica e na limpeza de rudos. Est comprovada a drstica diminuio de erros alm da melhoria na qualidade do produto; - Propriedade coletiva: a arte no tem dono. Assim no h a necessidade de um desenvolvedor solicitar mudanas para outro, atrasando o projeto, todos tem liberdade para fazer; - Padronizao: todos os desenvolvedores seguem um mesmo padro de organizao, nomenclatura, formato de arquivo, sobretudo compartilham da mesma tica esttica, dessa forma aumenta a legibilidade do trabalho, facilitando tanto o desenvolvimento em duplas quanto a propriedade coletiva da arte. - Reconstruo: a busca pela melhoria do produto constante, logo sua composio estruturada e expansvel. Sobre essa base vo se adicionando recursos faltantes, resultando em um produto simples e legvel pelos demais integrantes da equipe;

67 - Integrao contnua: a integrao constante do sistema permite que todos os desenvolvedores estejam sabendo de tudo que acontece no projeto, aumentando assim a agilidade no seu progresso; - 40 horas de trabalho semanal: equipes cansadas diminuem a produtividade e o interesse, cometendo assim mais erros; O desenvolvimento guiado por funcionalidades, ou FDD, apresenta uma forma gil e adaptativa de desenvolver artefatos. O FDD no abrange todo o processo de desenvolvimento, ao invs disso, ele tem como seu foco e objetivo a fase de modelagem e construo, muito til ao contexto de projetos grficos. Dos processos do FDD pode-se destacar: No planejamento ou etapa seqencial: - Desenvolver um Modelo Global; - Descrio e compreenso da demanda - Diagramas de entidade-relacionamento - Privilgio da forma sobre o contedo - Construir a Lista de Artefatos; - Foco no valor percebido - Ordem hierrquica em nveis macro e micro - Deve ser revisado e validado por usurios e patrocinadores - Tempo mximo de construo de 2 semanas - Artefatos mais complexos devem ser sub-dividos - Planejar por Artefato; - Considerar dependncias e prioridades - Coerncia em relao alocao de recursos e sobrecarga de tarefas Complexidade e risco das especificaes a serem implementadas - Planejamento dos marcos do projeto. No desenvolvimento ou etapa iterativa com no mximo 2 semanas de durao:

68

- Modelar por Artefato; e Construir por Artefato. - Selecionar grupo de artefatos - Selecionar times necessrios para desenvolver cada um - Cada time comea a modelar e construir seus artefatos - possvel eventual levantamento de novos requisitos importante observar que durante estes processos so realizas as atividades de inspeo da modelagem, reviso unitria e de integrao. Aps a finalizao de uma iterao, as funcionalidades que foram completamente construdas so integradas ao sistema principal e um novo conjunto de funcionalidades escolhido para a prxima iterao. Novas iteraes so feitas at que todas as funcionalidades estejam construdas e atendendo os requisitos. A Metodologia Adaptada a Projetos Grficos Com base no exposto pelo trabalho em grupo e pela apresentao acima detalhada, pode-se verificar abaixo o resultado da anlise focada no contexto de pequenos projetos grficos em ambiente de baixa maturidade. Convenciona-se aqui que os mtodos sero apresentados por meio de verbos no infinitivo, para enfatizar a percepo de atividade, prtica ou ao. Aps a anlise, seleo, excluso e fuso dos processos e prticas estudados, o ciclo de vida resultante pode ser considerado em fases de anlise e desenvolvimento, onde os grupos de processos do PMBOK ocorrem em concomitncia, e no necessariamente em seqncia. 1. ANLISE (Iniciao) 1.1. Modelar diagrama de necessidades 1.2. Listar artefatos

69 1.2.1. Coletar requisitos 1.2.2. Priorizar (Planejamento) 1.3. Planejar por artefato 2. DESENVOLVIMENTO (Execuo) Para cada artefato demandado: 2.1. Trabalhar jornadas semanais de desenvolvimento 2.2. Modelar 2.3. Obter aprovao 2.4. Continuar modelagem ou prosseguir construo 2.5. Construir (Monitoramento e Controle) 2.6. Realizar reunies dirias rpidas 3. RESPOSTA (Encerramento) 3.1. Entregar ou despachar para produo 3.2. Cobrar honorrios Com o intuito de aumentar a chance de sucesso da adoo da metodologia, alm do ciclo de vida de processos e prticas acima, sugerese a observao dos seguintes valores e princpios extrados do referencial terico estudado: Valores: 1. Comunicao e resposta imediata 2. Simplicidade 3. Coragem Princpios:

70

1.

Soluo

funcional

mais

importante

que

documentao

detalhada; 1.1. Foco: satisfazer os requisitos atuais do cliente. No h a preocupao com requisitos futuros. Esses sero tratados quando aparecerem; 2. Responder s mudanas mais importante que seguir um plano; 2.1. O processo deve prever a necessidade de modificaes; 2.2. O processo deve produzir prottipos freqentes; 3. Equipes pequenas: suas funes devem estar bem definidas e bem dividas; 3.1. Grupos de 2-10 desenvolvedores; 3.2. Integrao total entre desenvolvedores, gerentes e clientes; 3.3. Comprometimento de todos os integrantes para no comprometer a alta produtividade; 4. Colaborao do cliente mais importante que negociao de contratos; 4.1. Comunicao com o cliente deve ser imediata, a pessoa por parte do cliente que faz contato com a equipe deve ter liberdade para tomar decises rpidas. CONCLUSO Considerando a metodologia desenvolvida pelo trabalho de concluso de curso, bem como as principais doutrinas de gerenciamento de projetos, buscou-se aqui recompilar e adaptar os aspectos mais relevantes e adequados ao cenrio de pequenos projetos grficos num ambiente de baixa maturidade gerencial. Para o cenrio distinto em questo, utilizou-se critrios especficos de filtragem dos processos do guia PMBOK e das prticas das metodologias geis. Dessa forma, adotando a mesma filosofia do trabalho em grupo, este artigo individual buscou analisar a relevncia dos

71 processos e prticas levantadas. A resultante diferente porm obtida por meio da adaptao do mesmo princpio metodolgico desenvolvido durante TCC, que o de selecionar, excluir e fundir os processos resumindo-os ao estritamente necessrio ao contexto. Assim, observou-se que os grupos de processos do PMBOK ocorrem de forma discreta em meio aos princpios e prticas estabelecidas. E tambm como concluso do presente trabalho, importante relatar que pde-se observar com clareza a condio do PMBOK como guia de boas prticas e no como metodologia. A partir desta concepo admite-se a convivncia harmoniosa com outras prticas de gerenciamento de projetos estabelecidas sob forma de metodologia. Da mesma forma, uma vez que o mtodo aqui proposto ainda no tenha sido submetido experimentao real, sugere-se a aplicao do mesmo para validar ou no sua eficcia. BIBLIOGRAFIA

CHIN, G. Agile Project Management: How to Succeed in the Face of Changing Project Requirements. AMACON, 2004. BECK, K.; BEEDLE M.; BENNEKUM, A.; COCKBURN, A.; CUNNINGHAM, W.; FOWLER, M.; GRENNING, J.; HIGHSMITH, J.; HUNT, A.; JEFFRIES, R.; KERN, J.; MARICK, B.; MARTIN, R. C. .; MELLOR, S.; SCHWABER, K.; SUTHERLAND, J.; THOMAS, D.; Agile Manifesto. Fevereiro, 2001 http://www.agilemanifesto.org/

72

9.4 RAQUEL SANCHES CALVO

DESENVOLVIMENTO DE METODOLOGIA PARA GERENCIAMENTO DE PEQUENOS PROJETOS EM AMBIENTES DE BAIXA MATURIDADE: UM ESTUDO DE CASO EM UMA INDSTRIA DE PRODUTOS ODONTOLGICOS.
INTRODUO Empresas com um alto nvel de maturidade em gerenciamento de projetos, em muitos casos, possuem uma metodologia prpria para gerenciar seus projetos. J em outras, com um nvel no to elevado, o gerenciamento feito atravs de boas prticas ou de outras metodologias j existentes. O presente trabalho objetivou a criao de uma nova metodologia que pudesse ser utilizada em pequenos projetos por empresas de nvel de maturidade baixo. Uma metodologia que fosse simples e fcil de ser entendida e aplicada. Este apndice visa verificar se a metodologia proposta no trabalho atende as necessidades do gerenciamento de projetos de uma indstria de produtos odontolgicos na regio de Londrina, Paran. CONTEXTO

73 A empresa do estudo de caso uma empresa que atua h 20 anos no ramo de fabricao de produtos odontolgicos. Situada na regio de Londrina, a empresa conta com sessenta e dois funcionrios e possui duas unidades fabris. uma empresa reconhecida por ser uma das primeiras de sua rea a receber os certificados ISO 9001, Boas Prticas de Fabricao da ANVISA Agncia Nacional de Vigilncia Sanitria e Marcao CE. Ela atende todo o mercado nacional e exporta para mais de quarenta pases dos continentes: Europa, sia, Amrica Latina, Oceania e frica. Seu canal de distribuio o indireto, onde a venda realizada para um distribuidor que depois ir atender ao consumidor final. Possui um portflio com mais de cinqenta produtos, dentre os quais todos, com exceo de quatro, no so vendidos ao mercado internacional. E esse portflio est sempre em aumento devido a demanda, no ramo odontolgico, em se ter sempre produtos inovadores. A empresa possui um nvel de maturidade em gerenciamento de projetos baixo. Os coordenadores de setor tiveram treinamento no final do ano de 2009 e comeo do ano de 2010 onde foram introduzidos alguns conceitos de gerenciamento de projetos adotados pelo PMBOK. Todavia, apesar de ter sido feito alguns exerccios de treinamento de gerenciamento de projetos, os projetos realizados para este fim no foram desenvolvidos depois do final treinamento. Nem novos projetos foram criados, no dando continuidade ao processo de introduo do gerenciamento de projetos. Desse modo, na empresa tem-se um conhecimento bsico sobre gerenciamento de projetos, porm, no algo que est enraizado em sua gesto.

APRESENTAO E ANLISE DE RESULTADO Os projetos que a empresa ir desenvolver sero projetos internos, ou seja, projetos onde ela ir desenvolver para benefcio dela,

74 sejam projetos de desenvolvimento de novos produtos ou melhorias em processos. Ento veremos como os processos propostos na nova metodologia podem funcionar ou no para essa situao. No grupo de Iniciao temos trs processos: Gerar Oramento, Apresentar Proposta Comercial e Autoriza do Projeto. O processo Gerar Oramento por sua vez subdivido em seis: Coletar Requisitos, Definir Entregas com Viso Macro, Estimar Trabalho das Entregas, Identificar Riscos e Medidas Preventivas, Identificar Possveis Aquisies e Estimar Custos. 1. Gerar Oramento 1.1Coletar Requisitos: como so projetos internos, normalmente, a prpria rea executora do projeto ser o cliente. Nestes casos, ela mesma ter definido o escopo, no necessitando de reunies de briefing com o cliente. 1.2Definir Entregas com Viso Macro: este processo poderia ser excludo, deixando a criao da EAP no processo Criar EAP que est no grupo de Planejamento. 1.3Estimar Trabalho das Entregas: este processo seria interessante mant-lo, pois iria nos mostrar, mesmo que previamente e estimado, a durao do total do projeto. 1.4 Identificar Riscos e Medidas Preventivas: este processo muito importante mant-lo. Os riscos tm-se tornado o diferencial para muitos projetos. atravs da identificao dos riscos e de um plano de preveno que muitos projetos obtm sucesso. Conforme afirma Salles at alli:
(...) podemos concluir que o gerenciamento de riscos fator crtico de sucesso em projetos, e decidir no fazer significa comprometer intencionalmente os resultados do mesmo, (...)

75 1.5Identificar Possveis Aquisies: este processo continua como foi proposto na metodologia. 1.6Estimar Custos: para auxiliar na deciso de aceite ou no do projeto, importante que uma estimativa de custo seja realizada, pois com ela pode ser feitos mudanas no escopo j no inicio do projeto sem que tome tempo e/ou dinheiro da empresa. Esses custos englobam as aquisies, medidas preventivas dos riscos, mo-de-obra e todos os custos que possam ocorrer no projeto. 2. Apresentar Proposta Comercial: como so projetos internos, no haver a incidncia de valores empresariais, como rateios administrativos, parcelas de lucros, entre outros. Porm a definio do prazo de entrega importante manter. Mesmo um projeto interno tem seus clientes (internos) que precisam que o projeto esteja pronto no prazo. 3. Autorizar do Projeto: todo e qualquer projeto tem que ser autorizado por algum. E projetos internos no fogem a esta regra. Deste modo a diretoria da empresa (patrocinador) dever autorizar o projeto. No grupo de Planejamento temos seis processos: Refinar Coleta de Requisitos, Criar EAP, Identificar Atividades definindo Tempo e Recursos, Criar Cronograma, Definir Canal de Comunicao e Planejar Aquisies. 4. Refinar Coleta de Requisitos: esse processo pode ser excludo, pois como a prpria empresa ou setor da empresa quem ser o cliente, eles mesmos devem saber os requisitos do escopo. 5. Criar EAP: este processo continua como foi proposto na metodologia.

76 6. Identificar Atividades definindo Tempo e Recursos: este processo continua como foi proposto na metodologia. Apesar de no processo seguinte (Criar Cronograma) poder identificar as atividades definindo tempo e sua seqncia, este processo importante, pois nele sero verificado as pessoas que iro fazer parte da equipe do projeto. 7. Criar Cronograma: este processo continua como foi proposto na metodologia. Com o processo anterior, fica muito mais fcil desenvolver este processo. 8. Definir Canal de Comunicao: neste processo devem-se definir os responsveis pela tomada de deciso, neste caso, como um projeto interno, o gerente do projeto o responsvel do lado da empresa contratada e do cliente. Alm disso, deve-se definir se a diretoria quer ou no receber o follow-up dos projetos e em caso afirmativo por qual canal oficial de comunicao: email, relatrio, reunies e qual a freqncia desses follow-ups. 9. Planejar as Aquisies: este processo continua como foi proposto na metodologia. No grupo de Execuo temos trs processos: Tomar Medidas Preventivas aos Riscos, Executar Aquisies e Orientar e Gerenciar a Execuo do Trabalho. 10.Tomar Medidas Preventivas ao Risco: este processo continua como foi proposto na metodologia devido a grande importncia j comentada que o gerenciamento de riscos tem no sucesso de projetos. 11.Executar Aquisies: este processo, para ser validado, dever ter suas ordens de compras devidamente autorizadas pela diretoria, mesmo que o projeto j tenha sido previamente autorizado. Alm

77 disso, todas as aquisies feitas em projetos devero passar pelo setor de Compras da empresa, visto que o mesmo quem cuida de qualificao de fornecedores, entrada de notas fiscais, entre outros processos. 12.Orientar e Gerenciar a Execuo do Projeto: este processo continua como foi proposto na metodologia. No grupo de Monitoramento e Controle tambm temos trs processos: Realizar o Controle Integrado de Mudanas, Reportar Status e Verificar o Escopo. 13.Realizar o Controle Integrado de Mudanas: como o prprio setor que gerencia o projeto o cliente, esse processo ir realizar caso tenha faltado algum requisito do escopo, ou caso por alguma interferncia o escopo precise ser alterado. Porm, em projetos internos, as mudanas so em menor nmero do que em projetos externos. 14. Reportar Status: este processo continua como foi proposto na metodologia. Apenas o cliente dever ser a diretoria da empresa, caso a mesma, queira receber os follow-ups dos projetos. 15.Verificar o Escopo: este processo continua como foi proposto na metodologia, servindo de marco para entrarmos no grupo de Encerramento. E o ltimo grupo formado por um s processo: Encerrar o Projeto. 16.Encerrar o Projeto: este processo dever conter o aceite da diretoria da empresa para que o projeto seja formalmente encerrado, com

78 todas as prestaes de contas e relatrio de lies aprendidas j pronto.

CONCLUSO Pode-se concluir que mesmo com as recomendaes de que a metodologia proposta seria desenvolvida melhor em projetos de servio, com algumas pequenas modificaes ela facilmente aproveitada para outros tipos de projetos. E conforme analisado, essa metodologia pode ser utilizada nos projetos da organizao do referido estudo de caso.

BIBLIOGRAFIA SALLES JR., Carlos Alberto Corra; SOLER, Alonso Mazini; VALLE, Jos Angelo Santos do; RABECHINI JR., Roque. Gerenciamento de riscos em projetos. Rio de Janeiro: Ed. FGV, 2006.