Apostila GERENCIAMENTO DE PROJETOS DE APLICAÇÕES WEB

Prévia do material em texto

1 
 
 
GERENCIAMENTO DE PROJETOS DE APLICAÇÕES WEB 
1 
 
 
SUMÁRIO 
 
NOSSA HISTÓRIA ..................................................................................................... 2 
1. INTRODUÇÃO ..................................................................................................... 3 
1.1 Modelo do processo de negócio ............................................................................................... 4 
1.2 Particionamento ....................................................................................................................... 6 
1.3 Arquitetura de Sistema ............................................................................................................. 6 
1.4 Desdobramento da Função Qualidade - QFD ............................................................................ 7 
1.5 Conceito de Projeto .................................................................................................................. 8 
1.6 Organização ............................................................................................................................. 9 
1.7 Escopo...................................................................................................................................... 9 
2. INÍCIO DO PROJETO ........................................................................................ 11 
2.1 Equipe .....................................................................................................................................12 
2.2 Prazos e orçamentos ...............................................................................................................13 
2.3 Cronograma ............................................................................................................................15 
2.4 Comunicação ...........................................................................................................................16 
2.5 Documentação ........................................................................................................................16 
3 Competências em gestão de projetos ................................................................ 17 
3.1 Boas práticas em gestão de projetos .......................................................................................20 
3.2 Mind Map ...............................................................................................................................22 
3.2.1 Procedimentos do mind map ............................................................................................23 
3.3 Estudo de caso ........................................................................................................................23 
3.4 Emergência da governança em TI ............................................................................................26 
3.5 Ciclo de inovação tecnológica ..................................................................................................27 
3.5.1 Processo de avaliação e seleção de projetos .....................................................................28 
Referências Bibliográficas ..................................................................................... 31 
 
 
 
 
 
 
 
 
2 
 
 
 
 
NOSSA HISTÓRIA 
 
 
A nossa história inicia com a realização do sonho de um grupo de empresários, em 
atender à crescente demanda de alunos para cursos de Graduação e Pós-Graduação. Com 
isso foi criado a nossa instituição, como entidade oferecendo serviços educacionais em nível 
superior. 
A instituição tem por objetivo formar diplomados nas diferentes áreas de 
conhecimento, aptos para a inserção em setores profissionais e para a participação no 
desenvolvimento da sociedade brasileira, e colaborar na sua formação contínua. Além de 
promover a divulgação de conhecimentos culturais, científicos e técnicos que constituem 
patrimônio da humanidade e comunicar o saber através do ensino, de publicação ou outras 
normas de comunicação. 
A nossa missão é oferecer qualidade em conhecimento e cultura de forma confiável e 
eficiente para que o aluno tenha oportunidade de construir uma base profissional e ética. 
Dessa forma, conquistando o espaço de uma das instituições modelo no país na oferta de 
cursos, primando sempre pela inovação tecnológica, excelência no atendimento e valor do 
serviço oferecido. 
 
 
 
 
 
 
 
 
 
 
 
 
3 
 
 
 
1. INTRODUÇÃO 
 
Os projetos de software, devido a sua natureza, estão sujeitos a uma série de 
incertezas e riscos relacionados com custos, escopo/requisitos, recursos humanos e 
materiais, prazos, expectativas do cliente, da equipe, do investidor, dentre outros. Tais 
incertezas e riscos são acentuados em projetos que envolvem aplicações Internet, 
desde a construção de um simples site institucional até sites de comércio eletrônico 
(B2C – Business-to-Consumer e B2B – Business-to-Business), em virtude da 
competição mercadológica na busca de disponibilizar cada vez mais novidades em 
serviços eletrônicos e virtuais em tempos cada vez menores (denominado Internet 
timing) (BROWN, 2000). 
Quando estas incertezas e riscos não são adequadamente gerenciados, a 
qualidade do produto final pode ser comprometida, a expectativa do cliente pode não 
ser atendida, e a equipe que precisa conviver com ansiedades e conflitos durante a 
vida do projeto pode ter sua produtividade reduzida. 
Em projetos de desenvolvimento de aplicações Web, muitas vezes, os prazos 
de implantação dos sistemas são curtos e pré-definidos pelo cliente (conceito de time-
boxing), cabendo então uma definição de escopo e requisitos adequada para garantir 
a qualidade e adequação da expectativa em relação ao produto a ser entregue. 
Outro ponto crítico está no foco adotado para a gestão de projetos de 
aplicações Web – foco na tecnologia ou foco no processo de negócio. Muitas vezes, 
por preciosismo, o projetista ou o desenvolvedor se foca nos requisitos tecnológicos 
mais sofisticados ou inovadores, mas que não trazem benefícios para o cliente do 
ponto de vista de negócio. Este fato causa então dificuldades na homologação do 
software pelo cliente, por este não atender suas expectativas e/ou necessidades 
(McCONNEL, 1996). 
Considerando o ciclo de vida de um projeto, as incertezas e riscos 
relacionados com o escopo do projeto e requisitos do produto são grandes nas fases 
iniciais do projeto (concepção e planejamento) e tendem a diminuir nas fases 
posteriores. 
4 
 
 
Por outro lado, os custos envolvidos na identificação de problemas e 
inconsistências nas fases iniciais de um projeto são muito menores se comparados 
com os custos na identificação de problemas em fases posteriores, em virtude dos 
retrabalhos. Segundo Pressman (2005), uma mudança identificada na fase de 
desenvolvimento custa de 1,5 a 6 vezes mais do que se ela fosse identificada na fase 
de definição de requisitos e de 60 a 100 vezes mais na fase de manutenção, depois 
que o sistema está implantado. 
Portanto, a adoção de métodos e técnicas que apoiam a definição clara e 
precisa do escopo de um projeto de software, bem como a priorização e aderência 
dos requisitos do produto com as necessidades do cliente já nas fases iniciais do 
projeto permitem garantir a qualidade do produto final, reduzindo custos de retrabalho 
e expectativas inadequadas. 
De maneira resumida, pode-se afirmar que os projetos de aplicações Web 
estão frequentemente sujeitos a aumento de custos, prazos e retrabalhos. 
 
1.1 Modelo do processo de negócio 
O modelo do processo de negócio permite estabelecer os fluxos dos 
processos e informações de um processo de negócio, independente do grau de 
automação previsto. 
A formalização destes modelos pode ser feita utilizando-se diversas notações. 
As mais utilizadas atualmente são o SADT/IDEF0, que permite a descrição dosprocessos e subprocessos de negócio, destacando as entradas, saídas, ferramentas, 
mecanismo e regras de negócio (MARCA, 1988) e o UML Use Case, que permite a 
descrição detalhada das diversas situações de uso do processo de negócio segundo 
as necessidades do usuário. 
Tais modelos formalizados podem ser validados com o cliente ou usuário, 
garantindo o entendimento e alinhamento do processo e das regras de negócio. 
O estabelecimento do escopo e dos requisitos do produto de software de 
acordo com este modelo permite o alinhamento da automação com os objetivos do 
negócio. Este é o foco mais adequado para um sistema de software: ser uma 
5 
 
 
ferramenta que apoia um processo de negócio e nunca o contrário, ou seja, o foco 
deve ser eficácia e não eficiência. 
Portanto, destaca-se que o modelo de negócio é uma entrada fundamental 
para o estabelecimento do escopo do projeto de software. 
No desenvolvimento de software, escopo pode ser definido como: 
Capturar o contexto, os requisitos e restrições mais importantes para assim, 
definir os critérios de aceite do produto final. (KRUCHTEN, 1998). 
A utilização de técnicas de gerenciamento de projetos em organizações 
focadas em Tecnologia da Informação (TI) tem se intensificado nos últimos anos. No 
contexto organizacional, os modelos de maturidade têm se difundido entre eles 
destacam-se o Capability Maturity Model (CMM e CMMI) e o Organizational Project 
Management Maturity Model (OPM3) (CARVALHO et al, 2003). Já no âmbito do 
gerenciamento de projetos o uso de guias de referência como o Project Management 
Body of Knowledge (PMBoK) e a certificação profissional Profissional Project 
Management (PMP), fornecido pelo Project Management Institute (PMI), têm crescido 
significativamente entre os profissionais da área de TI (CARVALHO; RABECHINI Jr, 
2005). 
 Segundo o guia PMBOK (PMI, 2004), existem cinco processos relevantes 
para a condução da gerência do escopo do projeto, quais sejam: planejamento do 
escopo, definição do escopo, criação da estrutura analítica do projeto - EAP (work 
breakdown structure - WBS), verificação do escopo e controle de mudanças do 
escopo. 
Este trabalho enfatiza os três processos iniciais da Gestão do Escopo, ou seja, 
o desdobramento dos principais subprodutos do projeto de software em partes 
menores e mais fáceis de gerenciar. 
A abordagem do PMBOK (2004) sugere a utilização de modelos de estrutura 
analítica do projeto (EAP) e decomposição como ferramentas para o detalhamento do 
escopo. 
Não obstante, no contexto da engenharia de software, a técnica de 
particionamento proposta por Pressman (2005) pode trazer uma contribuição 
relevante como ferramenta para o processo de detalhamento do projeto, aliada ao 
6 
 
 
método QFD para a decomposição sucessiva em partes mais gerenciáveis para a 
equipe, mas garantindo o alinhamento com os objetivos do negócio. 
1.2 Particionamento 
 
Segundo Pressman (2005), o particionamento é uma técnica que permite dividir 
um projeto complexo em partes menores, garantindo um melhor gerenciamento e 
controle dos requisitos e escopo da partição (conceito do “dividir para conquistar”). 
Esta técnica também permite que os prazos de entrega sejam reduzidos, em virtude 
de entregas parciais e desenvolvimentos simultâneos. 
Assim, quando se trata de projetos para Internet, esta técnica pode ser bem 
aplicada, garantindo entregas mais rápidas, mesmo que com escopo reduzido, porém 
controlado e negociado com o cliente. Versões posteriores do produto irão 
complementar as entregas parciais iniciais, permitindo o desenvolvimento incremental 
e evolutivo. 
O desafio na aplicação desta técnica consiste em escolher as partições a serem 
entregues para o cliente e que lhes sejam úteis. Neste sentido, esta técnica é utilizada 
em conjunto com o modelo de processo de negócio, ou seja, o particionamento é 
orientado pelo processo de negócio, o que consiste em uma estratégia adequada para 
o cliente. 
 
1.3 Arquitetura de Sistema 
 
Quando o usuário estabelece os requisitos de um software, em geral, ele se 
preocupa com os requisitos e funcionalidades de negócio, pois são estes que atendem 
diretamente suas necessidades. No entanto, outros requisitos são de fundamental 
importância para garantir a qualidade do produto de software como um todo, tais como 
infra-estrutura de hardware, software, comunicação e segurança. 
A arquitetura de um sistema pode ser caracterizada por um conjunto de 
visões, como apresentado na Figura 1 (ver ISO 9126/ NBR 13596, ABNT, 1997). 
7 
 
 
Esta abordagem permite estabelecer todos os requisitos considerando os 
requisitos solicitados pelo cliente (geralmente os de negócio) e também os demais 
requisitos fundamentais para a qualidade do produto final. Assim, a abordagem da 
Arquitetura de Sistema permite garantir completeza dos requisitos de um sistema de 
software. 
 
 
Figura 1.1 – Visões da arquitetura de um Sistema 
 
1.4 Desdobramento da Função Qualidade - QFD 
 
O QFD (Quality Function Deployment) é um método que permite o 
desdobramento e priorização dos requisitos do cliente nas características e processos 
de qualidade a serem implementados, garantindo alinhamento com as necessidades 
do cliente. O QFD orienta a organização dos recursos disponíveis, priorizando-os de 
acordo com a visão do cliente. 
O SQFD (Software Quality Function Deployment) representa a transferência da 
utilização do QFD em um ambiente industrial para o mundo do desenvolvimento de 
software (Spinola, 2000). As principais vantagens da utilização do SQFD são: 
8 
 
 
 Aumento da produtividade no período de programação, por garantia de 
escopo bem definido; 
 Menor necessidade de realizar modificações futuras no software; 
 Menor necessidade de manutenção, possibilitando que os recursos 
sejam destinados para o desenvolvimento de novos projetos. 
 
1.5 Conceito de Projeto 
 
Um projeto pode ser a produção de um TCC, a criação de um logo, um site, 
uma empresa, um produto, um serviço ou ainda processos de trabalho. Pode ainda 
ser a produção e claro a adoção de uma tecnologia. Qualquer coisa que exija 
organização de um ou mais processos ou trabalho é um projeto. Organizar sua agenda 
do dia é um projeto. Veremos itens como escopo, cronograma, estratégia e outros, 
mas tenha em mente, o que é explicado acima e o que será explicado a seguir. O que 
difere de um projeto para outro é seu grau de importância ou complexidade de 
desenvolvimento, mas o conceito do que é um projeto é simples como exemplificado 
acima. O conceito pode ser apropriado de uma ação de marketing, uma necessidade 
de algum departamento, mas em geral o conceito pode agregar pessoas no empenho 
dos resultados práticos positivos de um projeto. 
Exemplo: criação de uma intranet (hoje claro, com uma cara de rede social 
interna), as pessoas querem se comunicar mais e melhor, então elas acabam 
contribuindo. 
A clareza do conceito espelha a facilidade com que todos podem ver, entender 
e colaborar num projeto. Muitas vezes o título do projeto é o conceito por extensão, 
as pessoas tendem a fazer julgamento de primeiro impulso assim que leem ou ouvem 
algo. Observe a diferença ao ler os dois exemplos abaixo, assim que ler, pense a que 
remetem ou que sensação ou pensamento vem à cabeça: 
Projeto: montagem de uma intranet 
Projeto: montagem de uma rede social 
9 
 
 
O conceito deve sempre ser claro, porque as pessoas precisam se sentir 
confortáveis ao participar de um projeto. 
 
1.6 Organização 
O entendimento de que tudo deve começar na sua mente é o ponto principal, 
por quê? Por que se você organizar tudo em um software, a partir de uma metodologia 
seja ela qual for, mas não ter claro tudo em sua mente, é um risco desnecessário. Por 
quê? Por que o software poderá falhar (eles não são feitos para prever variáveis que 
só um ser humano pode) e aí pouco importa a metodologia.Sua mente pode prever 
situações ou ações que um software não irá, então use sua mente para organizar 
detalhada e logicamente tudo que for referente ao projeto, colocando tudo no papel 
ou num documento ou mesmo construído um fluxograma, na verdade não importa 
como você fará, desde que faça. 
É preciso que você tenha em mente que um projeto para ter sucesso precisa 
inicialmente de três pontos críticos: 
1) Objetivo; 
2) Topificação; 
3) Agenda. 
É preciso que você tenha em mente que um projeto para ter sucesso precisa 
inicialmente de três pontos críticos: 
Organizar a agenda: 
1) Objetivo – Organizar a agenda; 
2) Topificação – Listar os compromissos do dia; 
3) Agenda – Definir horário para cada compromisso. 
Se você seguir estes três itens críticos, todo o resto derivará deles, importante 
salientar novamente, não importando o software ou a metodologia a ser usada. 
1.7 Escopo 
O conceito de escopo basicamente é, um esboço das atividades que deverão 
ser implementadas no projeto. É no escopo que é topificado tudo o que será feito para 
10 
 
 
serem organizados e desenvolvidos no projeto. Muitas vezes um projeto não evolui 
ou é cancelado por que o escopo foi mal dimensionado; 
Estabeleça o que vai e o que não vai ser feito no projeto, durante as reuniões 
com quem atribuiu o projeto a você. 
Pergunte tudo o que precisa ser perguntado durante estas reuniões (não peça 
nova reunião para tirar dúvidas, tire-as nas reuniões prévias). Deixe claro o que irá 
ficar de fora do escopo do projeto e por que. 
Defina o que será necessário para que o projeto seja executado com êxito. Ter 
múltiplos cenários (pessimista, realista e otimista) não é adequado. Defina claramente 
o que você terá, pelo que está recebendo (recursos financeiros, ferramentas, recursos 
de terceiros, equipe e prazos), assim os ajustes se farão antes mesmo de iniciar tudo. 
Definir as atividades e ações do projeto, junto à equipe, para atender ao escopo. 
Gerenciar o escopo do projeto é muito importante, principalmente quando se é forçado 
a ajustes ou mudanças de requisitos, ou de orçamento. Fazer uma avaliação de 
impacto das mudanças sobre todo o escopo também é importante, porque pode 
mostrar se o projeto está caminhando para um bom resultado ou se ele tem alguma 
falha. Geralmente as falhas são de prazo ou de orçamento, e em muitos casos, 
ambas. 
O escopo do projeto é certamente um dos pontos chaves onde você irá se 
apoiar tanto na avaliação geral do projeto, como durante a execução, na apresentação 
de relatórios e claro na entrega do projeto. Portanto um escopo documentado é 
fundamental para que depois não exijam ou cobrem algo que não estava no escopo, 
a documentação será sua garantia e respaldo, perante aqueles que atribuíram a você 
a gerencia do projeto. Um escopo claro, transparente e simplificado é garantia de 
resultados positivos, por isto invista tempo nele, será vantajoso durante e depois do 
projeto. 
Resumindo o escopo deve ser pensado sempre pelos critérios de: 
 Definir; 
 Planejar; 
 Verificar; 
 Controlar. 
11 
 
 
 
2. INÍCIO DO PROJETO 
 
Estruture um modelo que seja simples, funcional, enxuto, mas em cada parte 
do modelo, avalie que variáveis podem ou devem fazer parte do modelo. Por exemplo: 
recursos complementares, novas ferramentas, fornecedores etc. Em termos de planos 
para o gerenciamento, considere quatro planos chaves, plano de gerenciamento de 
trabalho, plano de gerenciamento de mudanças, plano de comunicação e plano de 
resposta a riscos. As atividades que formam o projeto devem ser definidas e 
organizadas através de uma metodologia, que especifique inclusive quem deverá 
realizá-las, como deverão ser realizadas e em que momento deve acontecer cada 
atividade. Para que a equipe não se perca em termos do que caberá a cada um, 
estabeleça um padrão para as atividades. Você pode organizar o projeto em quatro 
anteprojetos, exemplo: 
 Projeto conceitual; 
 Projeto preliminar; 
 Projeto avançado; 
 Projeto final. 
O simples é sempre o melhor, lembre-se: menos é mais em tudo, até mesmo 
em um projeto. 
Algumas atitudes recomendadas, é que converse em separado com cada 
pessoa da equipe. Reúna a equipe e fale francamente do projeto. Debata com a 
equipe, para que ela contribua para as atividades iniciais do projeto. Se você busca a 
simplificação em termos conceituais do gerenciamento de um projeto ele pode ser 
resumido em: 
 Avaliação; 
 Iniciação; 
 Objetivação; 
 Planejamento; 
 Monitoramento; 
 Execução; 
12 
 
 
 Finalização. 
2.1 Equipe 
Você pode ser sua equipe, mas pode também comandar uma equipe de uma a 
cem pessoas, o número de pessoas não importa, o que importa é você entender que 
não pode ser um chefe, deve ser um líder. Apenas um líder consegue que as pessoas 
não abandonem um projeto; apenas um líder consegue estimular uma equipe durante 
momentos de crise; apenas um líder consegue tirar o máximo de cada pessoa da 
equipe; apenas um líder consegue que um projeto seja executado no prazo e sem que 
o orçamento estoure. 
Para muitos é fácil esquecer que está lidando com seres humanos e não 
máquinas, máquinas não tem sentimento ou problemas pessoais. Se você não sabe 
lidar com isto, seja profissional e abandone o projeto para que outro assuma. Afinal 
se ele fracassar e vai, a culpa será sua. 
Escolher a equipe certa, montar uma equipe com o que é oferecido pela 
empresa, é quase uma ciência. Encontrar a pessoa certa para cada função, ter o 
feeling para sentir se tal ou qual pessoa é a adequada, é talvez a tarefa mais complexa 
que existe, quando se quer ter a grande equipe, para um projeto. Como escolher? É 
um misto de experiência, feeling, informação, senso crítico, observação e um pouco 
de sorte. 
Geralmente uma equipe quando conduzida por um líder se amolda a ele e tudo 
flui, gerando grandes resultados. Quando, no entanto, é gerida por um chefe, é uma 
equipe diluída, pronta para se dispersar e abandonar um projeto, que muitos não 
abandonam, por medo de perder o emprego. 
Uma das coisas mais difíceis para a maioria dos gestores de projetos é o ato 
de delegar, mas acredite delegar é o ato mais sensato, para o bem de um projeto. 
Quando se fez a primeira coisa correta em relação a equipe, que foi escolhe-la 
corretamente, delegar só trará bons resultados. Acredite quando se tem uma equipe 
bem escolhida, atribuir a alguém uma tarefa que nem você, nem ela já fez antes, 
gerará uma atitude de desafio, para ela. A pessoa irá encarar a tarefa como um desafio 
e encontrará uma maneira de apresentar uma solução adequada. 
13 
 
 
Acredite uma equipe menor sempre gera melhor resultado. Portanto saiba 
avaliar cada um que você poderá ter em sua equipe. Existem técnicas para a gestão 
de pessoas, principalmente em se tratando de liderança, administração de tempo e 
resolução de conflitos e eles são itens fundamentais num projeto, mas basta refletir 
um pouco, usando de lógica para se entender o que se precisa fazer nestes casos. 
Um ponto essencial ao definir a equipe é o estabelecimento das 
responsabilidades individuais, parece óbvio, mas muitas vezes por não ficar claro, 
para cada um, o julgamento pessoal das responsabilidades, torna cobranças, foco de 
atritos. Portanto estabeleça claramente os níveis de responsabilidade de cada um e 
como isto impacta no trabalho do seguinte do grupo. 
 
 Figura 2.1 – Trabalho em equipe 
 
2.2 Prazos e orçamentos 
Colocamos os dois tópicos juntos porque eles andam juntos, estão amarrados 
e por isto um pode comprometer o outro. Isto de modo geral acontece principalmente 
em projetos longos ou complexos ou ambos. Ou pode alavancar um ao outro, para 
isto depende do bom gerenciamento total do projeto. No entanto no momento de 
montar seu modelo para o gerenciamento do projeto, separe os dois em tópicos 
distintos, porque serão avaliados e geridos distintamente. 
14Garantir que prazos podem ser cumpridos é fundamental para não 
comprometer o orçamento. No entanto o orçamento não deve jamais estrangular o 
projeto, para que não comprometa os prazos. O equilíbrio na decisão do tamanho do 
orçamento é fundamental para garantir uma execução de projeto sem sobressaltos. 
Um item que certamente implicará em prazos e orçamento é a solicitação de 
mudanças, por isto fique atento a este item quando e se surgir. 
Os prazos devem ter um mínimo de margem, é fundamental, porque, variáveis 
não controláveis, como doença de pessoas da equipe, podem comprometer um 
projeto. Como definir uma margem? Bom senso é a melhor resposta, a experiência 
anterior é um balizador excelente. 
Exemplo: produção de um produto com determinadas características idênticas 
a de outro já produzido antes, que consumiu 90 dias, estabeleça entregar o site em 
95 dias, 5 dias será sua margem. Se tudo correr bem e você entregar em 90 dias, o 
cliente (seja ele externo ou seu chefe) vai ficar muito contente por ter entregado antes 
do prazo. 
Orçamentos são peças flexíveis, porque podem receber todo tipo de valores, 
mas ter critério, na hora de preparar um é fundamental. Por quê? Porque ele irá refletir 
características relevantes positivas como: responsabilidade e honestidade; em outros 
aspectos pode ainda refletir, economia e comprometimento. 
Mas o principal é que o orçamento não seja uma peça de ficção, ele tem de 
refletir as necessidades reais de um projeto. Cada componente individual do 
orçamento tem seu peso, então avalie a necessidade real de cada item, na 
composição de um orçamento. 
Adicione uma margem mínima ao orçamento, para que ela seja administrada e 
usada em caso de emergência. Ser previdente em termos de orçamento é também 
muito importante, lembre-se disto, quando estiver elaborando ou participando da 
elaboração de um orçamento. Em qualquer projeto que envolva uma equipe e 
orçamento, planejamento de compras, aquisições e contratações, bem como a 
administração de contrato se seleção de fornecedores são fundamentais e devem ser 
pensados como parte do planejamento, muito antes de fazer parte do gerenciamento 
dele. Isto envolve também etapas como encerramento de contratos e processo 
licitatório, principalmente quando é um projeto voltado para o serviço público. 
15 
 
 
Prazos e orçamento devem ser a base do planejamento de um projeto. Existem 
apenas três partes de um projeto que podem tornar um projeto um sucesso ou um 
fracasso, orçamento, prazos e equipe (componente que faz parte dos outros dois). 
Planejar cada um deles de forma consistente é sinal de sucesso futuro. 
Resumindo o orçamento deve ser pensado sempre pelos critérios de: 
 Estimar; 
 Orçar; 
 Controlar. 
 
2.3 Cronograma 
 É tão importante quanto o escopo, porque ele não só define os prazos das 
etapas, mas também o prazo final. Acredite atrasos nas etapas acarretará atraso no 
prazo final, então defina prazos realistas para as etapas. 
Você pode e eu recomendo definir dois cronogramas, o cronograma da 
proposta e o cronograma da equipe, o cronograma da proposta são os prazos 
definidos como absolutos e o da equipe com prazos menores. 
Em termos de formulário, o cronograma deve ser estruturado em dois: 
cronograma sumarizado e cronograma detalhado (trabalho e atividades), isto quer 
dizer que você tem uma margem de 15 dias para atrasos (que acabarão ocorrendo, 
afinal pessoas não são máquinas e mesmo máquinas pifam). Porque isto? Porque 
uma variável que muitos esquecem é a variável do imponderável, conte sempre com 
ela. 
Cronograma é muito mais do que itens de prazos, é a forma como você vai 
gerenciar o tempo vinculando a ele às etapas e atividades de um projeto, parece óbvio, 
mas acredite, muitos esquecem isto. Planejar bem o cronograma garantirá que você 
se se atenha a ele sem grande estresse. Em termos de formulário a planilha do 
orçamento deve conter: consolidado por item de custo, custos diretos por recurso/ 
atividade e custo mensal. 
 
 
16 
 
 
2.4 Comunicação 
 
 Por incrível que pareça muitos esquecem ou não tem tempo para comunicar o 
andamento de um projeto. Se ignorar a comunicação completa (não apenas para 
quem atribuiu o projeto a você) os riscos de inclusive desmotivar a equipe e 
comprometer o projeto são grandes. Comunique a todos e a equipe os objetivos do 
projeto e assegure-se de que haja entendimento e consenso sobre o resultado final 
do mesmo. Ouça todos, quando digo todos significa todos os envolvidos, da pessoa 
que entregou o projeto para você e todos da equipe. 
Um ponto fundamental na comunicação é o do entendimento correto do 
resultado do projeto, ou seja, o foco não é o que precisa ser feito, mas o resultado do 
que será feito. Mas em termos de comunicação ela deve ser de mão dupla, ou seja, a 
equipe também deve comunicar a você o andamento das atividades. Isto significa que 
é necessário o compartilhamento das informações. Pense nisto quando estabelecer 
as formas e meios de comunicação de seu projeto. 
Crie uma rotina de relatórios, compromete uma parcela do tempo do projeto, 
mas garante que o projeto no final, não seja comprometido. Comunicação com toques 
de motivação torna tudo mais fluido, assim como uma comunicação truncada ou mal 
elaborada pode criar situações que levem ao risco. Eliminar o risco na comunicação 
é fundamental, porque ele impacta diretamente nos resultados do trabalho, dúvidas 
sobre o sucesso e consequentemente do resultado do próprio projeto. 
 
2.5 Documentação 
Documente sempre os eventos de acompanhamento e utilize esta 
documentação para na próxima reunião. Aliás muitos sugerem que atas de reuniões 
façam parte da documentação do projeto, de forma geral pode parecer necessário, 
mas considere reduzir o volume de burocracia em torno da documentação, para que 
o projeto não seja engessado. Relatório de acompanhamento por outro lado é o tipo 
de documento fundamental, mas simplifique o modelo. Assim como a agenda 
(formulário) das atividades realizadas da semana e atividades programadas para a 
próxima semana. 
17 
 
 
A documentação no plano de projetos deve ter itens como: a qualidade 
esperada e variação de custo e prazo. Documente as mudanças – qualquer alteração 
de escopo, prazo ou custo que tenha impacto no projeto deve ser acordada com todos 
e posteriormente documentada. Documente avaliações da equipe e detalhe em 
separado, cada pessoa participante do projeto. 
Toda a documentação deve ser objetiva, sintética, para que você possa 
inclusive fazer uma apresentação se for necessário. Apenas no que tange a equipe a 
documentação pode ser subjetiva, afinal pessoas não são dados secos e duros. 
Compartilhe a documentação para evitar surpresas, neste caso dependendo 
do tamanho do projeto, considere enviar relatórios periódicos para o centro de 
decisão. Lembre-se que e-mails trocados entre você e sua equipe, ou entre você e 
seus superiores também são documentos. Use-os se for necessário. A sugestão é 
que toda e qualquer documentação esteja online para consulta e edição. 
Delegue a organização e formatação da documentação, assim que estabelecer 
como será, mas monitore também este procedimento. Apresente uma documentação 
efetiva do projeto. 
 
3 Competências em gestão de projetos 
 
A palavra competência vem do latim competere, composta de com, que 
significa um conjunto, e petere, que significa esforço. Desta gênese, Rabechini Jr. e 
Carvalho (2003) definem competência em gestão de projetos como o conjunto de 
esforços em gestão de projetos que será capaz de levar a organização a construir 
uma vantagem competitiva sustentável, vital no contexto estratégico. 
Rabechini Jr. (2003) propõe um modelo de competências em gestão de 
projetos alicerçado em três pilares: estratégia, processos e efetivação da mudança. 
Esses pilares são capazes de sustentar as camadas de competências envolvidas nainstitucionalização de gerenciamento de projetos, que são: indivíduo, equipes e 
organização. O autor argumenta que a institucionalização da gestão de projeto sem 
uma empresa só acontece se forem geradas competências de forma integrada nestas 
camadas. 
18 
 
 
As competências que configuram a camada do indivíduo envolvem o domínio 
das técnicas e ferramentas em gerenciamento de projetos, visão abrangente do 
sentido de governar ou ser governado, mediante a necessidade de alinhamento de 
projetos às estratégias organizacionais, bem como do desenvolvimento das 
habilidades gerenciais e da capacidade em aplicar as técnicas e ferramentas de 
gerenciamento de projetos. Já as competências relacionadas à camada das equipes 
estão à busca proativa por resultados, através de uma orientação voltada para tarefas 
e atividades, mas regida por um espírito de colaboração e comprometimento com os 
requisitos de gerenciamento do projeto. 
Finalmente, as competências na camada da organização se traduzem pelo 
ímpeto de institucionalizar a gestão de projetos como forma moderna de 
administração de suas atividades não rotineiras, através da sensibilização dos 
envolvidos, da disponibilização dos recursos, da adequação às estratégias, da 
divulgação de resultados de projetos, entre outras ações em âmbito organizacional. 
A Figura 3.0 ilustra o modelo, que cria uma perspectiva estruturada, que 
representa valores, variáveis e relacionamentos. 
 
 Figura 3.0 – Modelo de competências em gerenciamento de projetos 
 
Conforme ilustra a Figura 3.0, as camadas de competências apoiam-se em 
distintos pilares, capazes de viabilizar seus respectivos desenvolvimentos. O primeiro 
pilar se refere às questões da estratégia e norteia o desenvolvimento das outras 
19 
 
 
dimensões deste modelo. No contexto do modelo, o pilar estratégia enfatiza o 
desenvolvimento de diretrizes para o escritório de projetos, para a carreira do gerente 
de projeto e capacitação das equipes, bem como para a gestão do portfólio. 
O pilar processos se refere a procedimentos ou maneiras especificadas de 
abordar situações definidas (DRUCKER, 1981). Este pilar visa ao desenvolvimento 
das funções que integram os requisitos da gestão de projetos na empresa para as três 
camadas do modelo. O terceiro pilar, efetivação da mudança, representa os 
elementos necessários para se configurar o entendimento do gerenciamento da 
mudança organizacional e de suas barreiras ocasionadas durante a implantação da 
gestão por projetos. Este pilar contempla o monitoramento e o controle dos 
indicadores de desempenho dos projetos, considerando-se a possibilidade de analisar 
as competências das três camadas sugeridas. 
Como síntese do modelo, RabechiniJr. (2003) propõe a matriz de maturidade, 
composta de dois eixos: indicadores de estratégia e indicadores de processo. O eixo 
de indicadores de estratégia reflete o nível de atendimento às necessidades 
estratégicas, enquanto o eixo de indicadores de processo reflete o nível de 
atendimento dos processos traçados. A matriz resulta em quatro cenários de 
maturidade, conforme ilustra a Figura 3.01. 
 
Figura 3.01 – Matriz de maturidade 
20 
 
 
O cenário I, iniciante, caracteriza-se pelo baixo nível de atendimento às 
exigências das estratégias alcançadas e pela baixa ênfase nos processos. O cenário 
II, intuitivo, mostra projetos que satisfazem ao conjunto de indicadores estratégicos, 
mas com baixo nível de atendimento aos fatores de processos. O cenário III, 
desalinhado, representa a categoria de projetos com boa estrutura gerencial em que 
os processos de gerenciamento de projetos estão bem definidos, mas os resultados 
de desempenho estratégico são insuficientes, o que demonstra falta de alinhamento 
dos processos com as estratégias delineadas. Por fim, o cenário IV, maduro, 
demonstra a efetivação da mudança em processos e nas estratégias, ou seja, os 
projetos que atenderam aos requisitos de gerenciamento e também conseguiram 
resultados estratégicos esperados. 
 
3.1 Boas práticas em gestão de projetos 
 Desde sua primeira versão em 1996, o PMBoK configurou-se como um guia 
abrangente, capaz de, em linhas gerais, apresentar uma estrutura para boas práticas 
em gerenciamento de projetos. Três conceitos são importantes para entender o 
PMBoK: processos, ciclo de vida e áreas de conhecimentos em gestão de projetos. 
Estes três conceitos formam a base da estrutura do PMBoK, conforme ilustra a Figura 
3.1. 
 
 
 Figura 3.1 – Estrutura do PMBook 
21 
 
 
 
Os grupos de processos em gestão de projetos foram inspirados no ciclo PDCA 
(plan-do-check-act), proposto por Shewart e difundido por Deming, que se configurou 
como um dos pilares do conceito de melhoria contínua na gestão da qualidade 
(CARVALHO; PALADINI, 2005). Foram propostos cinco grupos de processo no 
PMBoK: inicialização, planejamento, execução, controle e encerramento (PMI, 2004). 
A estes processos vincularam-se as nove áreas de conhecimento em gestão 
de projetos, que são: escopo, prazos, custos, recursos humanos, suprimentos, 
qualidade, comunicação, riscos, que são integradas por uma área específica à gestão 
da integração. Estas áreas possuem processos específicos, conforme ilustra a Figura 
3.11. A área de integração é que possui maior número de processos, sete, seguida 
pelas áreas de prazo, risco e suprimentos, com seis processos. 
Carvalho e Rabechini Jr. (2005) enfatizam, no entanto, que existem projetos 
com necessidades que extrapolam as nove áreas de conhecimento e outros, 
evidentemente, que não requerem tanta sofisticação 
 
 
 Figura 3.1.1 – Áreas e processos de gerenciamento de projetos 
22 
 
 
O último conceito importante é o de ciclo de vida, que define as fases que 
conectam o início do projeto ao seu fim. O conceito de ciclo de vida tem ajudado os 
gerentes a administrarem os projetos, evidenciando as saídas e os requisitos 
esperados em cada fase, permitindo um controle mais profissional. O ciclo de vida 
está associado à natureza do projeto e com seu produto final e intermediários, os 
deliverables. 
 
3.2 Mind Map 
Há muitas técnicas no arsenal do moderno gerenciamento de projetos. 
Algumas foram desenvolvidas para lidar com a necessidade de visão sistêmica e a 
incerteza que são intrínsecas ao desenvolvimento de novos produtos. São 
ferramentas que facilitam, por exemplo, o raciocínio lógico sobre a interdependência 
das atividades, a identificação de todos os stakeholders e a comunicação entre eles, 
a monitoração e o controle do desempenho e a avaliação de riscos (KEELLING, 2002). 
Dentre essas técnicas, destaca-se a estrutura analítica do projeto (EAP ou WBS, work 
breakdown structure). A WBS divide o resultado final desejado em tarefas e 
representa graficamente a ligação do produto principal com seus componentes, 
permitindo visualizar a totalidade dos objetivos a serem alcançados ao longo do ciclo 
de vida do projeto (HELDMAN, 2003; KEELING,2002; MAXIMIANO, 2002). A 
importância da WBS no planejamento de projeto revela-se em levantamento feito pelo 
PMI. Cerca de 70% dos respondentes afirmaram que o método preferido de 
planejamento tem por base a definição da WBS (DOUGLAS III, 2004). 
O mind map é uma ferramenta que oferece aos gerentes de projetos um auxílio 
para a elaboração da WBS. Buzan (1991a) e Buzan e Buzan (1996), seus criadores, 
definiram-no como técnica gráfica que potencializa o aprendizado e a clareza do 
raciocínio. O mind map é uma forma de planejar e estruturar o pensamento, permitindo 
exploração rápida e profunda das ideias associadas ao tema central que está sendo 
focalizado no caso dos projetos, o produto principal (NORTHapud POLLITT, 1999).O 
mind map é de particular utilidade em processos gerenciais de fundo criativo, como a 
definição do escopo e a construção da estrutura analítica do projeto (WBS). 
Colocando o escopo e as atividadesem um mind map, o gerente de projeto e sua 
equipe ganham a compreensão sistêmica dos componentes e da interdependência 
23 
 
 
das atividades, o que facilita a comunicação dentro da equipe. O mind map também 
proporciona o envolvimento e enseja o entusiasmo da equipe, possibilitando ao 
gerente identificar em que parte do projeto os membros da equipe estão mais 
interessados ou com alguma dúvida, graças à visão geral e gráfica do mapa (BROWN; 
HYER, 2001). 
 
3.2.1 Procedimentos do mind map 
 
O procedimento para aplicação do mind map tem quatro etapas: 
1. O tema principal é colocado como imagem central no mapa. 
2. Tópicos (ou ideias primárias) irradiam desse tema central como ramos, 
desdobrando-o em ideias relacionadas. 
3. Cada ramo pode conter palavras ou imagens associadas ao tema. 
4. Subtópicos são incluídos como ramos secundários, e assim 
sucessivamente. 
Cada ramo do mind map funciona como multiplicador, com possibilidades 
exponenciais de amplificação. Segundo Murkejea (2004), os intangíveis, como ideias, 
informações e relacionamentos, tornam-se tangíveis por meio desse procedimento. 
 
3.3 Estudo de caso 
Entre os anos de 2003 e 2005, o gerente responsável pelos produtos TR e TA 
conduziu três grandes projetos, com mais de um ano de duração, e seis outros de 
menor porte. Nos três projetos de grande porte, o mind map foi usado nos processos 
de idealização e gestão do escopo dos negócios. A decisão de usar a ferramenta foi 
do próprio gerente, não da empresa. 
1. No Projeto Ticket Express (canal de vendas de TR e TA específico para 
pequenas empresas), o mind map foi utilizado na concepção e no 
planejamento do escopo do plano de negócios, identificando recursos 
necessários, parcerias, riscos, atividades e outras variáveis do processo 
de gestão. 
24 
 
 
2. No Projeto Ticket Parceiro, crédito rotativo para estabelecimentos 
(restaurantes, bares, padarias e mercados), parceiros credenciados pela 
Ticket Serviços, exclusivo para aquisição de alimentos, o mind map foi 
utilizado na definição do escopo do plano de redesenho conjuntural do 
produto que não tivera o desempenho esperado no mercado 
3. No Projeto Ticket Restaurante Eletrônico -TRE (substituição dos 
vouchers de papel por cartão eletrônico), o conceito do mind map foi 
utilizado na elaboração da árvore de decisão do produto, enquanto se 
discutiam as vantagens e desvantagens do cartão magnético ou smart 
(com chip). 
Segundo o gerente desses projetos, a ferramenta produziu uma reflexão 
exaustiva e colaborativa no processo de planejamento, em que foram identificadas as 
fases do projeto, os fatores de risco e os recursos necessários. Usada em grupo para 
construir um mapa coletivo, mostrou-se mais eficaz que para compartilhar mapas 
idealizados individualmente. O trabalho em grupo trouxe comprometimento como 
resultado da colaboração. 
Além de exaurir o processo de reflexão e geração de ideias, a técnica mostrou-
se vantajosa para organizar ideias, reduzir os erros na definição do escopo, visualizar 
o todo, retomar o raciocínio a partir de um ponto e concentrar a atenção no problema. 
Ajudou na identificação completa dos riscos, mesmo aqueles que não eram, 
inicialmente, relevantes, e na revisão e reavaliação dos riscos já identificados 
25 
 
 
 
 Figura 3.3 – Mind map do estudo de caso 
 
As seguintes desvantagens ficaram evidentes na utilização nesses três 
projetos: 
 Falta de uma ''linha do tempo''. Por não oferecer a visualização da 
dimensão temporal, o mind map exige tratamento separado da gestão 
dos prazos. 
 Falta de visualização dos recursos financeiros, exigindo também o 
tratamento separado do gerenciamento dos custos. 
 Dificuldade no cruzamento de dimensões, impossibilitando a 
visualização de quem faz o quê. 
 Necessidade de algum talento para desenho, ou pelo menos 
diagramação, no caso de pessoas que prefiram construir o mapa a mão, 
sem utilização de softwares. 
 Compartilhamento e leitura, por terceiros, de mapas desenvolvidos 
individualmente. O mind map é um excelente recurso para se usar em 
conjunto quando elaborado em conjunto. Se alguém cria um mapa 
26 
 
 
individualmente e tenta discuti-lo com um grupo, os ganhos não são 
significativos, devido às diferenças nas formas de organizar o raciocínio. 
 Falta de disseminação da metodologia na organização - ''se todos 
utilizassem o mind map seria mais fácil discutir com outros, uma vez que 
é necessário explicar seus princípios antes das reuniões'' 
 
3.4 Emergência da governança em TI 
 
Como atesta Fagundes (2005), ''atualmente, é impossível imaginar uma 
empresa [ou organização pública] sem uma forte área de sistemas de informações 
(TI), para manipular os dados operacionais e prover informações gerenciais aos 
executivos para tomadas de decisões''. Obviamente, isso inclui a gestão de 
suprimentos. Nas áreas mais afeitas ao setor público, fala-se em regulação e em 
práticas de governo que se destinam a atender às funções alocativa (estímulos diretos 
e indiretos para aplicação de recursos públicos e privados em setores de interesse 
social e econômico) e distributiva (busca de critérios socialmente aceitos de 
distribuição de renda), como orçamento participativo, ações de desenvolvimento local 
e regional, alocação eficiente de recursos públicos etc. Esses elementos remetem ao 
conceito de governança em TI. 
A governança em TI é uma estrutura de processos de operação, gestão e 
relacionamentos integrados com as estratégias corporativas cujo objetivo supremo 
consiste em adicionar valor às informações necessárias ao desenvolvimento dos 
negócios decorrentes das atividades operacionais. Nesse sentido, é parte integrante 
da governança corporativa. Contudo, é necessário esclarecer que a governança em 
TI tem apresentado um autodesenvolvimento independente da governança 
corporativa. Esta tem por principais objetivos a otimização do desempenho corporativo 
e a garantia de satisfação e proteção dos interesses de todas as partes interessadas 
(investidores, acionistas, funcionários, colaboradores, clientes, fornecedores, 
credores, sociedade civil, governos, sindicatos, ONGs e outros grupos específicos). A 
rigor, as principais práticas de governança corporativa estão associadas a objetivos 
de transparência, isonomia e equidade no tratamento de todas as partes envolvidas 
de maneira direta e indireta na geração de valor, prestação de contas e obtenção de 
27 
 
 
resultados em termos da oferta do mix de produtos e ou serviços, tal qual indicado 
pelo Instituto Brasileiro de Governança Corporativa. 
 
3.5 Ciclo de inovação tecnológica 
 
A inovação tem sido uma das estratégias mais eficazes para garantir a 
sobrevivência e o crescimento das empresas. Jonash e Sommerlatte (2001) sugerem 
que o processo de inovação envolva várias dimensões da organização: Processo de 
Inovação; Estratégia; Organização; e Recursos. A relação entre a estratégia 
tecnológica e a estratégia corporativa é discutida por Matheson e Matheson (1998). 
Os autores apresentam uma estrutura de relacionamento entre: Identidade 
Organizacional; Estratégia Corporativa; e Estratégia de Negócios. 
Quando se trata de Estratégia Tecnológica, os aspectos envolvidos referem-se 
a posicionamento e renovação, a decisões entre P&D interno, alianças e aquisições 
se à própria organização de P&D. Analisando a estratégia de Gestão de Portfólio, a 
atenção passa a ser dirigida ao balanceamento dos projetos em andamento (longo 
prazo x curto prazo, inovação radical x incremental, prioridades do negócio) e à 
otimização do uso dos recursos (orçamento total x de cada projeto, instalações, 
equipamentos e pessoas).A gestão do processo de inovação usualmente é composta 
de várias fases(TIDD et al., 2001): Processamento de Informações; Análise 
Estratégica; Alocação de Recursos; Implementação; e Feedback. Focalizando sua 
atenção no âmbito daGestão do P&D industrial, Shtubetal. (1994) apresentam um 
processo composto de três estágios, com quatro fases de avaliação intermediárias: 
Coleta de Ideias; Análise de Viabilidade; Desenvolvimento; Teste de Mercado e 
Comercialização. A primeira avaliação realizada entre a coleta de ideias e a análise 
de viabilidade envolve custos bem baixos e tem caráter informal. Os projetos não 
aprovados são arquivados para futuras análises. A segunda avaliação, ao final do 
estágio de análise de viabilidade, envolve critérios quantitativos. Se aprovado para o 
estágio de desenvolvimento, haverá maior comprometimento de recursos financeiros. 
Os projetos não aprovados são arquivados. Durante o desenvolvimento, há avaliações 
formais e periódicas. Findo o desenvolvimento, passa-se para o estágio 3 de testes 
28 
 
 
de mercado. Há ainda avaliações de resposta do mercado e eventuais alterações de 
pequena monta. Se aprovado, o produto/serviço passa para comercialização. 
 
3.5.1 Processo de avaliação e seleção de projetos 
 
Na busca do sucesso em desenvolvimento de novos produtos, são duas as 
rotas que se apresentam, de forma algumas exclusivas: (I) executar os projetos 
deforma correta e (2) trabalhar nos projetos corretos. A seleção dos projetos que virão 
a fazer parte de um portfólio é focada na rota n º 2. Trabalhar nos projetos corretos 
significa mais que a simples seleção de projetos individuais; a seleção tem por objeto 
o conjunto dos projetos que representam o total de investimentos da empresa em 
tecnologia para desenvolvimento de novos produtos (COOPERet al., 2003). 
Sua abrangência se estende para além das técnicas de avaliação e do 
exercício de tomada de decisão e alocação de recursos convencionais. Algumas das 
características desse processo, que nos permite caracterizá-lo como uma disciplina 
particularmente desafiadora de tomada de decisões, são listadas abaixo: 
 Trata-se de um processo focado no futuro, seus eventos e 
oportunidades. 
 Os fatores envolvidos na tomada de decisões estão em permanente 
mudança (o status bem como o valor agregado dos projetos no portfólio 
variam continuamente). 
 Os projetos do portfólio encontram-se em diferentes estágios de 
implementação. 
 Os recursos, financeiros e humanos são, como sempre, limitados. Uma 
imagem frequentemente utilizada para ilustrar o processo de seleção de 
novos projetos a fazer parte do portfólio é a do funil (Figura 3.5.1), cuja 
“boca” é larga, representando o estímulo à criatividade na geração e 
gestação de ideias, que são a seguir submetidas a uma série de crivos 
cada vez mais exigentes a fim de aumentar a probabilidade de os 
resultados finais atenderem efetivamente à estratégia do negócio. 
 
29 
 
 
 
Figura 3.5.1 – O processo de avaliação e seleção de projetos 
 
Uma visualização mais abrangente das etapas envolvidas no processo desde 
a geração de ideias até o acompanhamento da performance do produto no mercado 
é fornecida na Figura 3.5.1.1. Após cada etapa há um ponto onde são tomadas as 
decisões go!kill baseadas inicialmente na análise de projetos individuais, que 
posteriormente deverão ser integradas com as análises referentes ao conjunto de 
projetos como um todo. 
 
Figura 3.5.1.1 – Principais etapas e pontos de decisão no processo de gestão de portifólio 
 
30 
 
 
A literatura distingue três objetivos principais para o gerenciamento de 
portfólio de projetos (COOPER et al., 2001): 
I. Alinhamento estratégico 
Trata-se de garantir que o conjunto de projetos esteja orientado 
segundo a estratégia do negócio. Os projetos são classificados com 
base nas prioridades estratégicas e os recursos alocados segundo esta 
classificação. 
II. Maximização de valor 
Maximizar o valor agregado pelo portfólio em termos de algum objetivo 
do negócio como lucratividade. 
III. Balanceamento 
Busca-se atingir um certo equilíbrio no conjunto de projetos em termos 
de alguns parâmetros como duração (longa duração versus curta 
duração), risco (alto risco versus baixo risco) e também no que diz 
respeito a mercados, tecnologias e tipos de projetos etc. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
31 
 
 
Referências Bibliográficas 
 
CARVALHO, M. M. Modelo Seis Sigma. ln: CARVALHO, M. M.; PALADINI, E. P.(Org.). 
Gestão de qualidade: teoria e casos. Rio de Janeiro: Campus, 2006. p. 125-152 
BOUER, Ruy; CARVALHO, Marly Monteiro de. Metodologia singular de gestão de 
projetos: condição suficiente para a maturidade em gestão de projetos? Produção, v. 
15, n º 3, p.347-361, dez. 2005 
Making project management indispensable for business results. 2004 ANNU-AL 
REPORT, 2005. 
PMBOK. Guide to the project management body of knowledge. New York: Project 
Manage-ment Institute (PMI), 2004. 
WEILL,P.;ROSS, J. W. IT Governance. Harvard Business School Press, 2004.