GESTÃO-DE-PROJETOS-APLICADA

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
2 
 
SUMÁRIO 
1 INTRODUÇÃO ..................................................................................... 3 
2 PROCESSO DE DESENVOLVIMENTO DE UM NOVO PRODUTO OU 
SOFTWARE ............................................................................................................ 4 
3 GERENCIAMENTO CLÁSSICO DE PROJETOS ................................ 8 
3.1 PROJETOS E O GERENCIAMENTO CLÁSSICO DE 
PROJETOS.... ..................................................................................................... 8 
3.2 PROCESSOS DO GERENCIAMENTO CLÁSSICO DE 
PROJETOS.... ................................................................................................... 11 
4 PROJETOS DE DESENVOLVIMENTO DE SOFTWARE ................. 20 
4.1 SUCESSO E FRACASSO NO GERENCIAMENTO DE 
PROJETOS.... ................................................................................................... 25 
4.2 VISÃO TRADICIONAL DO SUCESSO DE UM PROJETO ......... 26 
4.3 DESEMPENHO DOS PROJETOS DE DESENVOLVIMENTO DE 
SOFTWARE... ................................................................................................... 29 
4.4 VISÃO MODERNA DE SUCESSO DE UM PROJETO ............... 33 
5 REFERÊNCIAS BIBLIOGRÁFICAS .................................................. 39 
 
 
 
 
 
 
 
 
 
 
 
 
3 
 
1 INTRODUÇÃO 
 
Prezado aluno! 
 
O Grupo Educacional FAVENI, esclarece que o material virtual é 
semelhante ao da sala de aula presencial. Em uma sala de aula, é raro – quase 
improvável - um aluno se levantar, interromper a exposição, dirigir-se ao professor 
e fazer uma pergunta, para que seja esclarecida uma dúvida sobre o tema tratado. 
O comum é que esse aluno faça a pergunta em voz alta para todos ouvirem e todos 
ouvirão a resposta. No espaço virtual, é a mesma coisa. Não hesite em perguntar, 
as perguntas poderão ser direcionadas ao protocolo de atendimento que serão 
respondidas em tempo hábil. 
Os cursos à distância exigem do aluno tempo e organização. No caso da 
nossa disciplina é preciso ter um horário destinado à leitura do texto base e à 
execução das avaliações propostas. A vantagem é que poderá reservar o dia da 
semana e a hora que lhe convier para isso. 
A organização é o quesito indispensável, porque há uma sequência a ser 
seguida e prazos definidos para as atividades. 
Bons estudos! 
 
 
 
 
 
 
 
 
 
 
4 
 
2 PROCESSO DE DESENVOLVIMENTO DE UM NOVO PRODUTO OU 
SOFTWARE 
O desenvolvimento de novos produtos tornou-se o foco da concorrência 
industrial. A origem dessa tendência está relacionada ao período pós-guerra 
(Segunda Guerra Mundial) e às três principais forças que surgiram em muitos 
setores do mundo nas décadas de 1970 e 1980: a expansão do espaço de 
competição nacional além das fronteiras nacionais; o mercado fragmentado com 
necessidades específicas após o surgimento de tecnologias transformadoras, como 
o surgimento de microeletrônica, tecnologia da informação e comunicação, o 
processo de mudança tecnológica (eliminação rápida) se acelerou. 
Novas tecnologias e novos entendimentos das tecnologias existentes 
geram um conhecimento cada vez mais profundo com base nos fenômenos por trás 
de aplicativos específicos, aumentando assim a capacidade de criar novas opções 
com base nas necessidades específicas de novos clientes ou consumidores. 
A longo do tempo, o desenvolvimento de novos produtos mudou a 
competitividade da empresa e de seus produtos. O sucesso do desenvolvimento de 
novos produtos parece ser “[...] padrão de consistência global do sistema de 
desenvolvimento, incluindo estrutura organizacional, habilidades técnicas, processo 
de resolução de problemas, cultura e estratégia. Tal consistência jaz não só sobre 
os princípios e a arquitetura do sistema, mas também sobre os detalhes no nível 
operacional e de gestão” (CLARK; FUJIMOTO, 1991, p.7). 
Para os gerentes seniores de todo o mundo, desenvolver produtos melhores 
com mais rapidez e eficácia é a questão central da agenda competitiva. Há 
evidências de que efetivamente projetar e desenvolver novos produtos tem um 
impacto significativo no custo, qualidade, satisfação do consumidor e vantagem 
competitiva (CLARK; FUJIMOTO, Ibid.). 
 
Uma empresa de sucesso com base nesse padrão competitivo refere-se a 
uma empresa que pode articular corretamente seus objetivos em estrutura 
estratégicas e gerenciar seu portfólio de produtos de P&D para adaptá-lo ao objetivo 
 
 
5 
 
de desenvolver novos produtos e recursos. Recursos disponíveis interna e 
externamente. O sucesso dessas empresas também depende de seu grau de 
entrada no campo técnico, de sua contribuição para o posicionamento de longo 
prazo, permitindo que eles criem novos recursos importantes, reduzam 
gradualmente o tempo para desenvolver novos produtos e satisfaçam as 
necessidades e especificações do produto. (SCHILLING; HILL, 1998). 
Esses autores sugerem que, como as principais funções essenciais no 
desenvolvimento de novos produtos, fatores relacionados a quatro dimensões 
básicas: estratégia técnica, ambiente organizacional, equipe de projeto e 
ferramentas para o processo de melhoria contínua (conforme mostrado na figura 
abaixo). Por esse modelo, fica claro que Schilling e Hill (ibid.) recomendam um plano 
de desenvolvimento de produto novo na forma de um projeto. 
A construção e o uso de equipes para desenvolver novos produtos sempre 
foram objeto de muitos estudos, o que mostra que a multifuncionalidade é essencial 
para o sucesso de empresas e clientes. Diz-se que a razão para fazer tal hipótese 
é que, devido à superação de erros na produção, os produtos desenvolvidos estão 
melhor adaptados ao potencial da cadeia de suprimentos, às necessidades dos 
compradores e / ou usuários e à "manufaturabilidade" da linha de produção da 
empresa. 
Nesse sentido, Schilling e Hill (1998) enfatizaram a importância de adaptar 
a estrutura da equipe (funcional, leve, pesada ou autônoma) ao tipo de projeto 
devido ao nível de coordenação e comunicação entre as equipes do projeto. Pode 
ser compatível da mesma maneira, e as habilidades de liderança do gerente de 
projeto ou advogado, como a capacidade de gerenciar conflitos e se comunicar com 
áreas diferentes, devem ser consistentes com o tipo de projeto. 
 
 
 
 
6 
 
 
Fonte: ADAPTADO DE SCHILLING; HILL, 1998, p.70 
Outros requisitos relativos à composição e operação da equipe do projeto 
são determinar as tarefas, objetivos e responsabilidades, bem como os detalhes 
das atividades a serem realizadas e os resultados a serem alcançados para garantir 
uma comunicação clara. Além de ser uma ferramenta para monitorar e avaliar o 
desempenho da equipe, esses métodos também podem fornecer um foco claro e 
incentivá-los a se comprometerem com o desenvolvimento do produto. 
(SCHILLING; HILL, 1998). 
 
 
7 
 
Outros requisitos relativos à composição e operação da equipe do projeto 
são determinar as tarefas, objetivos e responsabilidades, bem como os detalhes 
das atividades a serem realizadas e os resultados a serem alcançados para garantir 
uma comunicação clara. Além de ser uma ferramenta para monitorar e avaliar o 
desempenho da equipe, esses métodos também podem fornecer um foco claro e 
incentivá-los a se comprometerem com o desenvolvimento do produto. 
(LAZAREVIC, 2003). 
Nos últimos anos, o desenvolvimento de software recebeu crescente 
atenção nas organizações. Porter e Millar (1985) e Booch (2001) apontaram que a 
tecnologia da informação é uma ferramenta extremamente poderosa que pode 
promover a transformação social e econômica. Seu valor e importância podem ser 
percebidos como “[...] a tecnologia penetra na cadeia de valores de uma empresa e 
extrapola as tecnologias associadas diretamente ao produto” (PORTER, 1989, p. 
153). Cada atividade devalor sempre cria ou usa informações e tecnologias da 
informação para coordenar e otimizar as conexões entre indivíduos e 
departamentos. Porter enfatizou que a eficiência interna, as capacidades 
operacionais, a capacidade de fornecer produtos e serviços, a agilidade e a 
flexibilidade e outras vantagens competitivas necessárias para a sobrevivência e o 
crescimento de uma organização são atualmente fortemente influenciadas pelos 
sistemas de informação. (Porter,1989) 
Atualmente, a indústria de software é uma das indústrias mais importantes 
do mundo. Sua existência direta ou indiretamente possibilita o surgimento de novos 
negócios e a melhoria da eficiência comercial tradicional (BOOCH, 2001). 
De acordo com Veloso et al (2003), A indústria de software é dominada por 
grandes países desenvolvidos, incluindo Estados Unidos, Alemanha e Japão, 
representando cerca de 2% do PIB desses países. Em outros países, como Israel 
e Irlanda, essa contribuição é ainda maior, representando aproximadamente 3,4% 
e 7,4% do PIB do país em 2001, respectivamente. 
Impulsionada pela própria tecnologia da informação, a chegada da Internet 
e a globalização trouxeram grandes mudanças no mercado de desenvolvimento de 
software. Para competir na economia digital, as empresas devem ser capazes de 
 
 
8 
 
desenvolver software de alta qualidade para clientes, com padrões de alta qualidade 
a uma velocidade cada vez maior, e ainda ser capazes de lidar com as mudanças 
no ambiente de negócios. (BASKERVILLE et al, 2003; MAURER; MARTEL, 2002; 
COCKBURN; HIGHSMITH, 2001). 
 Laitinen et al (2000) ressaltaram que a Internet permite que pequenas 
organizações ocupem seu espaço no controverso mercado de desenvolvimento de 
software, fornecendo produtos valiosos. No Brasil, a Internet criou milhares de 
empregos (BRASIL, 2001a). 
 
3 GERENCIAMENTO CLÁSSICO DE PROJETOS 
 Voltando aos quatro principais fatores de sucesso para o desenvolvimento 
de novos produtos propostos pela estratégia tecnológica, ambiente organizacional, 
equipe e ferramentas, fica claro que o desenvolvimento de novos produtos (ou 
software) pode e deve ser gerenciado por meio de projetos. Considerando que os 
planos de desenvolvimento de software são realizados na forma de projetos, e o 
sucesso desses projetos pode depender do sucesso da organização, este tópico 
apresenta os principais conceitos relacionados ao gerenciamento de projetos, aqui 
chamados de gerenciamento clássico de projetos. (SCHILLING; HILL, 1998; 
KERZNER, 2002). 
Observe que "clássico" é usado no momento para distinguir esse método 
do gerenciamento ágil de projetos. Esse é o termo usado por Chin (2004) e 
Highsmith (2004) ao citar o método de gerenciamento de processos proposto pelo 
PMI (2004). 
3.1 PROJETOS E O GERENCIAMENTO CLÁSSICO DE PROJETOS 
Para entender melhor o gerenciamento de projetos, primeiro é necessário 
conhecer um projeto. Embora esses projetos existam desde os tempos antigos, 
desde a década de 1960, esse tópico atraiu maior interesse e ganhou popularidade 
 
 
9 
 
(MEREDITH; MANTEL, 2000, vii). Embora a literatura sugira várias definições, uma 
análise mais próxima nos fez perceber que quase não há diferença conceitual entre 
eles. (LEWIS, 1997, p. 1; VERZUH, 1999, p. 3; GRAY; LARSON, 2003, p. 5; 
KERZNER, 2002, p. 17; MEREDITH; MANTEL, 2000, p. 9; MAXIMIANO (2002, p. 
26); ISO, 1997; PMI, 2004, p. 5). 
Segundo o PMI (2004, p. 5) “Um projeto é um esforço temporário 
empreendido para criar um produto, serviço ou resultado exclusivo”. Temporário 
significa que todos os projetos definiram início e fim. Exclusividade ou singularidade 
significa que o produto, serviço ou resultado gerado difere em certa medida de todos 
os outros produtos, serviços ou resultados que já existem. Essas entregas 
exclusivas podem ser: 
 
 Produtos ou objetos mensuráveis, sejam eles produtos finais ou 
componentes; 
 A capacidade de executar serviços, como funções de negócios que 
dão suporte à produção ou distribuição; 
 Resultados, como resultados finais ou documentos. 
 
Como os projetos envolvem a realização de coisas que nunca foram feitas 
antes, eles podem estar associados a um certo grau de complexidade e incerteza 
(Ibid., p. 6). Os projetos têm propriedades surpreendentes que os distinguem das 
atividades diárias ou operações contínuas, e essa distinção deve ser perfeitamente 
absorvida. De acordo com o PMI (2004), o objetivo do projeto é atingir suas metas 
declaradas e, em seguida, desligar, enquanto as operações contínuas geralmente 
visam manter os negócios. 
 Martin e Tate (2001) enfatizaram o fato de o projeto ser temporário e 
produzir resultados únicos, em contraste com a operação contínua, o mesmo 
processo é repetido várias vezes para produzir sempre os mesmos resultados. No 
entanto, o plano de trabalho do projeto ainda é incerto e precisa ser constantemente 
atualizado, mas em operação contínua, o plano é claro. 
 
 
10 
 
Também é preciso mencionar que os projetos geralmente são 
implementados para permitir a realização do plano estratégico da organização e 
geralmente são aprovados de acordo com uma ou mais definições estratégicas 
(PMI, 2004, página 7; KERZNER, 2002, página 17) 
 
 Uma demanda de mercado; 
 Uma necessidade organizacional; 
 Uma solicitação de um cliente; 
 Um avanço tecnológico 
 Um requisito legal. 
 
O gerenciamento clássico de projetos foi objeto de pesquisa de vários 
autores e pesquisadores, apresentando suas definições e pontos de vista sobre o 
tema. Esses autores têm a mesma linha conceitual, ou seja, a estrutura de 
gerenciamento de projetos por meio de processos, o que é consistente com as 
ideias reveladas pelo PMI (2004, p. 8). 
Em relação à padronização e aplicação prática de conceitos, o PMI (2004, 
p. 8) descreve o gerenciamento de projetos como “[...] a aplicação de 
conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto, a fim 
de atender aos seus requisitos”. Realçar que “gerenciamento de projetos é realizado 
através da aplicação e da integração dos seguintes processos de gerenciamento de 
projetos: iniciação, planejamento, execução, monitoramento e controle e 
encerramento” (PMI, Ibid.). 
 
De acordo com o PMI (Ibid.), os itens de gerenciamento incluem: 
 
 A identificação das necessidades; 
 O estabelecimento de objetivos claros e alcançáveis; 
 O balanceamento de demandas conflitantes de qualidade, escopo, 
tempo e custo; 
 
 
11 
 
 A adaptação das especificações, dos planos e da abordagem às 
diferentes preocupações e expectativas das diversas partes 
interessadas. 
 
O gerenciamento de projetos fornece às empresas ferramentas poderosas 
que podem melhorar a capacidade de planejar, organizar, executar e controlar 
atividades, a fim de alcançar os resultados esperados dentro do tempo e custo 
esperados, mesmo em situações muito complexas. (MEREDITH; MANTEL, 2000). 
Kerzner (2002) adiciona que, para ser bem-sucedido, o gerenciamento de 
projetos requer fluxo de trabalho e coordenação horizontal (não mais vertical como 
o gerenciamento tradicional), com foco em comunicação, produtividade, eficácia e 
eficiência, especialmente o papel e as responsabilidades do gerente de projetos. 
Depois que o projeto e o gerenciamento de projetos forem conceituados, 
forneceremos agora uma visão geral do processo clássico de gerenciamento de 
projetos. 
3.2 PROCESSOS DO GERENCIAMENTO CLÁSSICO DE PROJETOS 
Como mencionado no tópico anterior, alguns autores lidam com o 
gerenciamento de projetos de acordo com uma abordagem de processo. (VERZUH, 
1999, p. 19; KERZNER, 2002, p. 4-5; DINSMORE; NETO, 2004, p. 1; MAXIMIANO, 
2002, p. 40; PMI, 2004, p. 36-37). 
Verzuh (1999) propôs a estruturação do projeto através do processo de 
"definir, planejar, executar e finalizar", e mencionou que esses processos devem ser 
repetidos em todas as etapas do projeto e no ciclode vida do produto. Maximiano 
(2002) apontou que o processo de gerenciamento do projeto - planejamento, 
organização, execução e controle - é necessário para todo o projeto e para cada 
estágio de todo o ciclo de vida, e essa visão também é a mesma. 
Kerzner (2002) também estudou essa estrutura por meio de um processo e 
acrescentou discussões importantes sobre o papel da cultura organizacional no 
processo de gerenciamento de projetos. Apontou que quase duas empresas não 
 
 
12 
 
gerenciam seus projetos da mesma maneira, portanto, a implementação do 
gerenciamento de projetos deve ser baseada na cultura de cada organização. 
Forsberg et al. (1996) explicaram a importância de criar um modelo que 
sirva como guia ou base para o gerenciamento de projetos. Os autores dizem que 
esses modelos ajudam a descrever como as coisas são feitas, são usadas para 
explicar o todo, fornecem uma base conceitual única, explicam regras de uma 
maneira simples e ajudam a identificar e comunicar relacionamentos e elementos-
chave, também a eliminar conscientemente a confusão dos elementos bem 
definidos aplicado ao gerenciamento de projetos garante: 
 
 O entendimento, pela equipe do projeto, dos objetivos e da forma 
como o projeto será gerenciado; 
 Uma perfeita comunicação entre as partes interessadas acerca dos 
diferentes aspectos do projeto, incluindo informações sobre a saúde 
e o progresso do projeto; 
 A avaliação de caminhos alternativos e o aproveitamento de 
oportunidades que venham a surgir 
 
Para serem efetivos, os modelos ou os processos de gerenciamento de 
projetos devem possuir as seguintes características (FORSBERG et al., p. 17): 
 
 Definição explícita e operacional, utilizando estruturas, variáveis e 
relacionamentos; 
 Serem óbvios e intuitivos a todos os interessados no projeto; 
 Aplicabilidade ao ambiente de projeto, assegurando o tratamento das 
complexidades e do dinamismo inerentes aos processos do projeto 
e aos requisitos do projeto; 
 Podem ser validados empiricamente no mundo real do 
gerenciamento de projetos. 
 
 
 
13 
 
O PMI (2004, p. 37-38) acredita “o gerenciamento de projetos é realizado 
através de processos, usando conhecimento, habilidades, ferramentas e técnicas 
do gerenciamento de projetos que recebem entradas e geram saídas”. O processo 
é definido como “um conjunto de ações e atividades inter-relacionadas realizadas 
para obter um conjunto pré-especificado de produtos, resultados ou serviços”. 
Basicamente, existem duas categorias principais de processo em um projeto: 
 
a) Processo de gerenciamento de projetos: é comum na maioria dos 
projetos na maioria das vezes, pois esses processos às vezes 
interagem entre si de maneira complexa para atingir uma meta 
integrada. O objetivo é iniciar, planejar, executar, monitorar e 
controlar e fechar projeto. Esses processos descrevem, organizam e 
complementam as atividades do projeto; 
 
b) Processos orientados ao produto: esses processos especificam e 
criam os produtos do projeto, que variam com a área de aplicação e 
são definidos no ciclo de vida do produto. 
 
Verzuh (1999) e o PMI (2004) alega-se que o processo de gerenciamento 
do projeto e o processo orientado ao produto se sobrepõem e interagem por todo o 
projeto. No entanto, dado o foco deste trabalho, apenas o processo de 
gerenciamento de projetos é discutido aqui. 
O Guia PMBoK (PMI, 2004, p. 41) apresenta diferentes processos de 
gerenciamento de projetos baseados em definições de boas práticas, bem como 
seus respectivos objetivos e integrações. Esses processos são divididos em cinco 
grupos, a saber: 
 
 Grupo de processos de inicialização: defina e autoriza o projeto ou a 
fase do projeto; 
 
 
14 
 
 Grupo de processos de planejamento: define e melhora os objetivos 
e planeja as medidas necessárias para atingir os objetivos e o 
escopo do projeto de design; 
 Grupo de processos de execução: integra pessoal e outros recursos 
para executar o plano de gerenciamento do projeto; 
 Um conjunto de processos de monitoramento e controle: mede e 
monitora periodicamente o andamento do projeto para identificar 
mudanças relacionadas ao plano, para que sempre sejam 
necessárias ações corretivas quando necessário para atingir as 
metas do projeto; 
 Grupo de processos de checkout: determina formalmente a 
aceitação final de produtos, serviços ou resultados e guia o projeto 
ou a fase para um fim ordenado. 
 
Os grupos de processos propostos pelo PMI (ibid.) estão relacionados aos 
objetivos que eles produzem e raramente representam eventos únicos. Geralmente, 
eles têm atividades sobrepostas, requerem diferentes níveis de trabalho ao longo 
do projeto e interagem entre si no mesmo estágio ou em vários estágios do ciclo de 
vida. Ao dividir um projeto em vários estágios, esses processos geralmente são 
repetidos em cada estágio de todo o ciclo de vida do projeto para efetivamente levar 
o projeto à conclusão. Nas diferentes fases do projeto, a estrutura dos grupos de 
processos e como esses grupos de processos se sobrepõem e mudam em cada 
fase pode ser vista nas ilustrações abaixo. 
 
 
15 
 
Fonte: PMI, 2004, p. 69 
 
 
 
Fonte: PMI, 2004, p. 68 
A figura a seguir descreve sequencialmente a interação entre diferentes 
grupos de processos. Esta figura mostra as principais informações e / ou 
 
 
16 
 
documentos trocados entre grupos de processos, que são usados como entrada e 
/ ou saída de cada processo do "gerenciamento clássico de projetos". 
 
 
Fonte: PMI, 2004, p. 42 
 
 
17 
 
 
Composto pelos cinco grupos de processos mencionados, há um total de 
44 processos de gerenciamento de projetos. Esses processos estão espalhados por 
nove áreas de conhecimento, a saber (PMI, 2004, p 70): 
 
1. Gerenciamento da integração do projeto; 
2. Gerenciamento do escopo do projeto; 
3. Gerenciamento de tempo do projeto; 
4. Gerenciamento de custos do projeto; 
5. Gerenciamento da qualidade do projeto; 
6. Gerenciamento de recursos humanos do projeto; 
7. Gerenciamento das comunicações do projeto; 
8. Gerenciamento de riscos do projeto; 
9. Gerenciamento das aquisições do projeto 
 
O gerenciamento de integração de projetos inclui todos os processos e 
atividades necessários para identificar, definir, combinar, unificar e coordenar vários 
processos e atividades de gerenciamento de projetos no grupo de processos de 
gerenciamento de projetos. O gerenciamento do escopo do projeto inclui garantir 
que o projeto inclua todo o trabalho necessário e inclua apenas todos os processos 
necessários para a entrega bem-sucedida do projeto. O gerenciamento do tempo 
do projeto inclui todos os processos necessários para concluir o projeto no prazo. 
No gerenciamento de custos do projeto, todos os processos envolvidos no 
planejamento, estimativa, orçamento e controle de custos são considerados para 
concluir o projeto dentro do orçamento estimado. O gerenciamento da qualidade do 
projeto inclui a execução de todas as atividades da organização, que definem 
responsabilidades, objetivos e políticas de qualidade para atender aos requisitos 
que impulsionam sua realização. O gerenciamento de recursos humanos do projeto 
inclui todos os processos de organização e gerenciamento da equipe do projeto. O 
gerenciamento de comunicação do projeto reúne os processos necessários para 
 
 
18 
 
garantir que a geração, coleta, distribuição, armazenamento, recuperação e destino 
final das informações do projeto sejam oportunas e adequadamente garantidas. O 
gerenciamento de riscos inclui o processo de identificação, análise, resposta a 
sugestões, monitoramento e controle dos riscos do projeto. Finalmente, o 
gerenciamento de compras do projeto abrange o processo de compra ou compra 
de produtos, serviços ou resultados necessários fora da organização do projeto 
(PMI, 2004). 
A Tabela abaixo mostra o mapeamento do processode gerenciamento de 
projetos de acordo com o PMI (2004, página 70) e sua associação com grupos de 
processos e áreas de conhecimento. 
 
 
 
 
 
19 
 
 
 
Fonte: ADAPTADO DE PMI, 2004, p. 70 
Embora o "Guia PMBoK" forneça todas as informações detalhadas, o PMI 
(2004) retém conhecimentos, habilidades e processos de gerenciamento de 
projetos não devem ser aplicados uniformemente na retenção de todos os projetos. 
O gerente de projeto trabalha com a equipe do projeto e é responsável por 
selecionar e determinar o processo apropriado a ser aplicado a um projeto 
específico e o rigor de cada processo. 
 
 
20 
 
Portanto, de acordo com o PMI (ibid.), para que um projeto seja bem-
sucedido, o gerente e a equipe do projeto devem: 
 
 Selecione o processo apropriado necessário para atender às metas 
do projeto no grupo de processos de gerenciamento de projetos; 
 Use métodos definidos para ajustar os planos e especificações do 
produto para atender aos requisitos do produto e do projeto; 
 Atender às necessidades, expectativas e expectativas dos 
participantes do projeto 
 Equilibre as necessidades conflitantes entre escopo, tempo, custo, 
qualidade, recursos e riscos para produzir produtos de alta 
qualidade. 
 
Finalmente, ao analisar as "Diretrizes do PMBoK" (PMI, 2004), com base 
em uma definição ampla e completa do escopo do projeto e em um planejamento 
bem preparado para cada área de conhecimento, as pessoas acreditam que uma 
abordagem de gerenciamento de projeto muito estruturada pode ser adotada O 
progresso do projeto é formalmente monitorado em termos de escopo, prazo e 
custo, e as alterações do projeto são rigorosamente controladas. Esses são 
considerados os principais recursos do chamado gerenciamento clássico de 
projetos. 
 
4 PROJETOS DE DESENVOLVIMENTO DE SOFTWARE 
Thomsett (2002) apontou que todos os projetos de engenharia (o autor inclui 
esses projetos de desenvolvimento de software) basicamente têm que lidar com 
dois aspectos - um é o aspecto técnico, o outro é o aspecto do gerenciamento - 
representando o "gerenciamento técnico" x o "gerenciamento de projetos" 
Dualidade. ". Segundo o autor (ibid.), até a década de 1950, os atributos de 
gerenciamento desses projetos (cronograma detalhado, orçamento, controle de 
 
 
21 
 
mudanças, gerenciamento de contratos) eram de responsabilidade do arquiteto do 
projeto. No entanto, em alguns casos, os aspectos técnicos e a visão de todo o 
projeto estão concentrados nas mãos de uma pessoa, levando a conflitos de 
interesse. Thomsett (2002) comentou que leva algum tempo para o próprio 
gerenciamento de projetos ser considerado uma disciplina, e as funções e 
responsabilidades técnicas e de gerenciamento são tratadas separadamente. Nas 
últimas décadas, o desenvolvimento de software passou por um processo de 
melhoria, e seu foco inicial está nos aspectos técnicos, ou seja, no próprio método 
de desenvolvimento. Como muitos processos evolutivos, essa melhoria é baseada 
na análise de problemas encontrados em processos e modelos anteriores e na 
definição de novas formas de comportamento. 
De acordo com Beck (1999), o modelo em cascata é o primeiro modelo que 
busca construir software adaptado às necessidades do usuário. É baseado em 
documentos detalhando os requisitos e funções de software. Este documento é 
obtido através da interação com usuários e clientes e, em uma etapa chamada 
"análise", a interação pode durar vários meses. A partir deste documento 
abrangente, engenheiros de software, especialistas em bancos de dados e outros 
profissionais definem a arquitetura do software em uma fase chamada design. Nas 
etapas subsequentes, o programador desenvolverá o código e facilitará o teste e a 
entrega de procedimentos completos e completos de implementação e teste de 
software. 
Beck (1999) apontou que o modelo parece perfeito na teoria, mas na 
prática, existem alguns problemas. Primeiro, quase sempre o usuário precisa mudar 
após meses ou até anos de pesquisa, especificação e construção de diagramas e 
processos, alguns usuários ainda não sabem o que desejam, mas apenas sabem o 
que não desejam produzir. A segunda questão envolve a alteração de requisitos 
durante o processo de desenvolvimento. Bohem (2002) apontou que, em qualquer 
método clássico de desenvolvimento, a primeira dificuldade será encontrada ao 
solicitar alterações de código, pois, para atender a esses requisitos, é necessário 
reunir programadores, arquitetos de software e analistas de banco de dados. 
Análise e alterações de documentos e subsequente implementação de alterações. 
 
 
22 
 
O modelo em cascata é uma maneira de tentar resolver essa situação, evitando o 
congelamento de requisitos de software, ou seja, nenhuma alteração é permitida 
durante o projeto. No entanto, verifica-se que isso não é viável na prática (BECK, 
ibid.). Da perspectiva do gerenciamento de projetos, o modelo em cascata assume 
um congelamento do escopo do produto e do projeto (THOMSETT, 2002). 
Para aprimorar esse modelo, surgiram técnicas iterativas e incrementais, a 
interrupção do ciclo de desenvolvimento de software e o modelo em cascata foi 
repetido ao longo do processo. Este novo método visa reduzir o tempo de 
desenvolvimento. Como no modelo em cascata, todos os requisitos de software são 
analisados antes do início da codificação, mas são divididos em incrementos de 
funções básicas. Pode ser desenvolvido em paralelo com o objetivo de economizar 
tempo (Beck, 1999). 
Os modelos incrementais se concentram na redução do tempo, enquanto 
outros métodos (como desenvolvimento iterativo e modelos em espiral) tentam 
responder melhor às necessidades e gerenciar riscos. 
De acordo com Cohen et al. (2003, p. 3), esses modelos lidam com fatores 
de risco de maneira estruturada e planejada, em vez de tentar mitigar os fatores de 
risco apenas quando eles aparecem. 
O autor ressalta que o desenvolvimento iterativo apresenta avanços nos 
projetos de desenvolvimento de software em iterações de termo variável e, em cada 
iteração, é fornecido um conjunto completo de funções com base em documentos 
previamente preparados (COHEN et al., 2003, p. 3). Na primeira iteração, funções 
básicas serão geradas e essas funções básicas serão adicionadas em outras 
iterações. Embora cada iteração passe por todos os estágios do modelo em 
cascata: " Análise, Desenho, Implementação e Teste", mas como existe apenas um 
conjunto completo de requisitos fixos na iteração, o desenvolvimento iterativo pode 
lidar melhor com as alterações. Para outras iterações, as alterações podem ser 
feitas antes da fase "análise". O modelo permite absorver mudanças tecnológicas 
ou mudanças nos requisitos do cliente até um certo ponto (COHEN et al., Ibid.). 
 
 
 
23 
 
Da mesma forma, o modelo em espiral evita a necessidade de especificar 
e definir os requisitos finais do software no início do projeto. No entanto, é diferente 
do desenvolvimento iterativo, pois prioriza o desenvolvimento e considera os fatores 
de risco, e não a função em si. Considerando o gerenciamento de projetos, o modelo 
iterativo e espiral significa que o projeto tem um escopo aberto inicial, que é 
explicado em detalhes durante cada iteração (THOMSETT, 2002). 
O surgimento desses novos modelos de desenvolvimento de software 
promoveu progresso no campo da tecnologia, mas nada foi feito no campo do 
gerenciamento. Cohen et al. (Ibid.) apontaram que, com o surgimento do SW-CMM 
(Software Capability Maturity Model), a maneira como as organizações gerenciam 
projetos de desenvolvimento de software passou por grandes mudanças. O SW-
CMM foi criado em 1986 pelo Software Engineering Institute (SEI) da Universidade 
Carnegie Mellon, e é um modelo para promover a maturidade das organizações no 
processo de desenvolvimento de software. Em anos recentes, o SW-CMM foi 
organizado em diferentespaíses do mundo. Amplamente difundido na China (SEI, 
1995; Paulk, 2001). 
O SW-CMM contém cinco níveis de maturidade (inicial, reproduzível, 
definição, gerenciamento, otimização) e sua estrutura é de 52 objetivos, distribuídos 
em 18 áreas principais, descrevendo as melhores práticas de engenharia 
(desenvolvimento de software) e gerenciamento, além de apontar maneiras de 
melhorar o processo de construção de software na organização (PAULK, 2001, p. 
19). Você pode ver essa estrutura na tabela abaixo. Cohen et al. (Ibid.) confirmam 
que o principal objetivo do SWCMM é permitir que as organizações obtenham a 
melhor consistência, previsibilidade e confiabilidade no processo de 
desenvolvimento de software (nível de maturidade 5). 
 
 
 
24 
 
 
 
Fonte: PAULK, 2001, p. 20. 
Vale ressaltar que o SW-CMM não é um modelo de desenvolvimento de 
software, mas um modelo projetado para promover a maturidade do processo de 
desenvolvimento de software. A métrica de maturidade do SW-CMM é usada para 
classificar as organizações com base na consistência, previsibilidade e 
confiabilidade do processo de desenvolvimento de software (PAULK, 2001, p. 19). 
Apesar da ampla disseminação na comunidade de desenvolvimento de 
software, Paulk (2001, p. 25) enfatizou que a maioria das organizações ainda está 
no primeiro estágio de maturidade inicial e pouco otimizado. O autor também 
comentou que o formalismo inerente à maioria dos processos de melhoria propostos 
pelo SW-CMM permite que o modelo se concentre em grandes projetos com 
rigorosos requisitos de confiabilidade. No entanto, também apontou que, apesar 
disso, o princípio SW-CMM ainda pode ser aplicado a empresas e projetos menores. 
Os modelos de desenvolvimento de software apresentados até agora 
(modelo em cascata, modelo iterativo e modelo espiral) são exemplos dos 
chamados métodos clássicos de desenvolvimento de software, cujas principais 
 
 
25 
 
características são o formalismo e a preparação de um grande número de 
documentos. Em termos de gerenciamento de projetos, as entradas de 
gerenciamento e processo fornecidas pelo SW-CMM (SEI, 1995) tornam o conceito 
de gerenciamento de projetos clássico consistente com o do gerenciamento de 
projetos tradicional (PMI, 2004). 
Finalmente, deve-se ressaltar que, embora o modelo espiral e o modelo 
iterativo possam proporcionar maior agilidade ao desenvolvimento de software, eles 
ainda são criticados por não promoverem a resposta às mudanças a uma 
velocidade adequada para a empresa real. A formalização e manutenção de 
documentação detalhada típica desses modelos, juntamente com o foco no 
planejamento e controle do gerenciamento de projetos, é considerada uma barreira 
à verdadeira agilidade no desenvolvimento de software (COHEN et al., 2003). 
 
4.1 SUCESSO E FRACASSO NO GERENCIAMENTO DE PROJETOS 
 
Voltando à posição de Schilling e Hill (1998) e Kerzner (2002) de que o 
sucesso do projeto pode depender do sucesso da organização, e considerando o 
modelo conceitual desta pesquisa, é necessário discutir o sucesso e o fracasso da 
gestão. Projete e avalie o desempenho do projeto de desenvolvimento de software. 
Assim como em vários conceitos relacionados ao projeto, a definição de 
sucesso do projeto muda com o tempo. Portanto, devemos primeiro restaurar a 
visão tradicional do sucesso e analisar o desempenho dos projetos de 
desenvolvimento de software e, em seguida, apresentar uma visão "moderna" do 
sucesso, que é a base do chamado método ágil de desenvolvimento de software e 
gerenciamento ágil de projetos. 
 
 
 
26 
 
4.2 VISÃO TRADICIONAL DO SUCESSO DE UM PROJETO 
 
Para empreender uma jornada, é indispensável ter um destino e 
um plano para chegar até ele. O destino precisa ser claramente 
identificado, caso contrário nunca se saberá quando a viagem acaba. De 
certa forma, as mesmas questões são válidas para as práticas de 
gerenciamento de projetos. (KERZNER, 2002, 43). 
 
Como identificar projetos de sucesso? O sucesso do projeto deve ser 
medido em termos de satisfação do cliente, lucratividade, geração de novos 
negócios ou aumento da participação de mercado? Ou deve ser definido como 
atendendo às especificações / expectativas do cliente ou excedê-las? Ou até 
"simples" para completar o plano estabelecido? 
Perguntas como essas nem sempre são respondidas corretamente na 
organização. De fato, poucas empresas se preocupam em definir o significado de 
sucesso para os gerentes e, quando o fazem, sua definição desse objetivo é baixa. 
Formulação inadequada de expectativas causará grandes problemas no processo 
de gerenciamento de projetos (KERZNER, 2002, p. 43). 
Segundo Kerzner (2002), nos estágios iniciais do gerenciamento de 
projetos, o sucesso é medido apenas em termos técnicos, isto é, se os produtos 
produzidos são adequados. Não precisa se preocupar com custo ou prazo de 
entrega, nem com o sucesso dos negócios. Quando a empresa começou a melhorar 
o gerenciamento de projetos, essa postura inicialmente defendida pelos gerentes 
seniores da organização mudou. O sucesso de um projeto é entendido como a 
conclusão da programação no prazo, pelo custo e por um nível predeterminado de 
qualidade (KERZNER, 2002, p. 44). No entanto, o autor ressalta que essa ainda é 
uma medida incompleta, pois esses indicadores retratam a definição interna de 
sucesso. 
Kerzner (2002, p. 44-45) continuou o desenvolvimento do conceito. “melhor 
explicação de sucesso é aquela que o mensura em termos de fatores primários e 
secundários”. Considera-se que os principais fatores atendem ao cronograma, ao 
 
 
27 
 
custo e ao nível de qualidade definidos pelo cliente. Os fatores secundários são a 
aceitação do projeto pelo cliente e se o cliente concorda em divulgar seu nome como 
referência. Segundo o autor, somente quando o cliente está tão satisfeito com o 
resultado ele pode ver a definição absoluta de sucesso, para que seu nome possa 
ser usado como referência. (KERZNER, Ibid.). 
Kerzner (ibid.) também apontou que os principais fatores podem ser 
alterados de acordo com a organização para aumentar ou diminuir seu escopo, por 
exemplo, incluindo conformidade com padrões de segurança, regulamentos 
governamentais, regulamentos ambientais, etc. O posicionamento da empresa no 
projeto também pode alterar a definição de sucesso. 
Ao discutir esse tópico, Verzuh (1999, p. 17) apontou os três elementos do 
sucesso do projeto: atingir o prazo esperado, atingir o custo esperado e a alta 
qualidade do produto resultante, incluindo os requisitos de funcionalidade e 
desempenho. O autor menciona que essas são as três principais variáveis do 
projeto e são interdependentes. Qualquer alteração em um deles afetará o outro ou 
todos. Verzuh (ibid.) aponta que o maior desafio para os gerentes de projeto é 
encontrar o melhor equilíbrio entre "prazo-custo-qualidade", que é a visão comum 
de Meredith e Mantel (2000, p. 4). Esses autores se referem a eles como três 
objetivos do projeto, como mostra a Figura abaixo. 
 
Fonte: Meredith; mantel, 2000, p. 4 
 
 
28 
 
Verzuh (1999) no entanto, acrescentou que apenas atingir as metas de 
custo, tempo e qualidade do projeto não é suficiente. É importante que o cliente e o 
gerente do projeto compartilhem a visão de um equilíbrio "prazo-custo-qualidade" 
para garantir a consistência das expectativas. Reconhecendo que o sucesso do 
projeto também está intimamente relacionado às opiniões de outros participantes, 
essa é uma grande motivação para buscar consenso em torno de seus objetivos. 
Pinto e Kharbanda (1995) também defenderam a ideia de que o sucesso do 
projeto não pode ser medido apenas com base nas restrições triplas tradicionais 
(prazo, custo e qualidade (desempenho)). Considerando o ambiente de negócios e 
a crescente ênfase na satisfação do cliente, o autor destaca que é necessário 
estender o conceito de sucesso à quarta variável: satisfaçãoe agregar valor aos 
clientes. Pinto e Kharbanda (1995) enfatizaram que todos os esforços realizados no 
projeto devem se concentrar em ouvir e entender as preocupações e opiniões dos 
clientes, a fim de produzir um produto final que atenda às suas necessidades, 
garantindo assim uma transição e aceitação do projeto. 
Dinsmore e Neto (2004, p. 15) reforçam que “[...] executar projetos dentro 
do prazo e orçamento previstos, atender à qualidade especificada e satisfazer às 
expectativas da organização responsável pelo projeto são indicadores de sucesso 
na gerência de programas e projetos, independentemente da natureza dos 
mesmos”. 
Note-se, no entanto, que Meredith e Mantel (2000, p.4) refutaram a ideia de 
criar uma quarta variável de sucesso (além das metas de tempo, custo e qualidade), 
que representavam as expectativas do cliente e declaravam que os requisitos eram 
" Uma parte inerente da especificação do projeto ". O autor enfatiza que separar as 
necessidades ou expectativas do cliente das especificações do projeto significa 
inserir e estimular conflitos entre o cliente e a equipe do projeto, o que é contrário 
às expectativas de um bom gerenciamento de projetos. 
Com base na suposição de que, se um projeto atender aos quatro critérios 
de tempo, custo, eficácia e satisfação do cliente, o projeto será considerado bem-
sucedido. Pinto e Slevin (1988), depois de estudar os gerentes de projeto, 
construíram um modelo de dez fatores considerados críticos. Para o sucesso do 
 
 
29 
 
projeto. Jiang et al. (1996) chegaram a uma conclusão semelhante ao realizar 
pesquisas com profissionais da área de sistemas de informação. A tabela a seguir 
lista esses fatores em ordem de importância 
 
 
Fonte: Adaptado De Pinto; Slevin, 1988 
De acordo com a pesquisa de Meredith e Mantel (2000), os principais 
fatores para o sucesso do projeto variam de acordo com os tipos de setor. 
Do exposto até o momento, pode-se dizer que sob a ótica tradicional de 
definição do sucesso de um projeto, o estabelecimento dos objetivos de custo, prazo 
e qualidade do projeto, refletidos num planejamento realista e adequado, assim 
como o correto entendimento dos requisitos e das expectativas dos clientes e 
demais interessados no projeto, constituem os fatores básicos para o sucesso de 
um projeto. 
 
4.3 DESEMPENHO DOS PROJETOS DE DESENVOLVIMENTO DE 
SOFTWARE 
Nos últimos anos, a avaliação de desempenho de projetos de 
desenvolvimento de software tem sido uma preocupação de muitos autores e 
organizações. Conduziu várias pesquisas para determinar os indicadores de 
 
 
30 
 
desempenho dos projetos e os principais fatores de sucesso para esses projetos 
(Jiang et al, 1996; GIGA INTERNATIONAL GROUP, 2002; STANDISH GROUP 
INTERNATIONAL, 1999, 2001 e 2003). Frequentemente, os resultados dessas 
pesquisas apontam situações desagradáveis e descrevem altas taxas de falhas em 
projetos de desenvolvimento de software. 
Nas várias edições da pesquisa do STANDISH GROUP INTERNATIONAL 
(op. cit.), o desempenho dos projetos foi classificado em três modalidades: 
 
a) Sucesso – compreender os projetos entregues no prazo, de acordo 
com os padrões de qualidade aceitos pelo cliente dentro do 
orçamento; 
b) Insucesso – incluindo projetos que foram cancelados ou nunca 
implementados antes da conclusão; 
c) Sucesso parcial – coloque os projetos fechados e em execução 
juntos, mas seus indicadores de tempo e custo apresentam 
alterações negativas em comparação às previsões, ou a qualidade 
da entrega é inferior à qualidade especificada. 
 
De acordo com o relatório publicado em 2003 (STANDISH GROUP 
INTERNATIONAL, 2003), nos últimos dez anos, a análise de aproximadamente 
50.000 projetos de TI de diferentes empresas em todo o mundo foi combinada, mas 
os resultados não são satisfatórios - a porcentagem de projetos concluídos com 
êxito ou parcialmente bem-sucedidos ainda é relativamente alta (66% em 2002 ). 
Embora os resultados gerais dos projetos de desenvolvimento de software tenham 
mostrado melhorias significativas durante esse período, o percentual de projetos 
bem-sucedidos variou de 16% em 1994 a 34% em 2002. 
Por um lado, se o gasto excedente do orçamento for reduzido de 180% em 
1994 para 43% em 2002, o prazo e os indicadores de desempenho da qualidade se 
deteriorarão após um período de melhoria. Em 2002, o crescimento inesperado 
aumentou da média para 82% e em 2000 foi de 63%. Apenas 52% dos projetos 
atendem às especificações de qualidade, em comparação com 67% em 2000. 
 
 
31 
 
Essas mudanças indicam que há um certo grau de instabilidade nos resultados do 
projeto, e os benefícios não são consistentes ao longo do tempo. No gráfico abaixo, 
você pode ver claramente a evolução histórica do desempenho do projeto de 
desenvolvimento de software de 1994 a 2002. O gráfico é baseado em dados 
categorizados e resultados de pesquisas conduzidas pelo STANDISH GROUP 
INTERNATIONAL (1999; 2001; 2003). Obviamente, há uma mudança entre os 
casos extremos, ou seja, a taxa de projetos malsucedidos diminui, enquanto a 
porcentagem de projetos bem-sucedidos aumenta. No entanto, com exceção de 
1996, o índice de projetos classificados como "parcialmente bem-sucedidos" 
permaneceu quase inalterado, em cerca de 50%. 
 
Fonte: standish group international, 2003. 
Outro aspecto importante da pesquisa realizada pelo STANDISH GROUP 
INTERNATIONAL (2001; 2003) é determinar os principais fatores de sucesso em 
projetos de desenvolvimento de software. Esses fatores são classificados de acordo 
com seu impacto no sucesso do projeto e estão listados na tabela abaixo. 
 
 
32 
 
 
Fonte: Adaptado De Standish Group International, 2001 
Segundo relatórios publicados, entre 1994 e 2002, muitas organizações 
participantes do estudo investiram em maneiras de melhorar seus processos e 
métodos de gerenciamento de projetos. Segundo relatos, a melhoria nos resultados 
do projeto é parcialmente devida à adoção de boas práticas relacionadas ao 
gerenciamento de projetos (STANDISH GROUP INTERNATIONAL, 2001; 2003). 
Nesse sentido, pode-se dizer que os principais fatores que causam essa 
transformação incluem: implementar projetos menores, usar melhores ferramentas 
para monitoramento, controle de projetos e nomear gerentes de projetos 
qualificados com experiência e proficiência. 
Apesar de algumas conquistas, o STANDISH GROUP INTERNATIONAL 
(2003) apontou que muitos projetos fracassam ou estão fadados ao fracasso, não 
por falta de fundos ou falta de domínio técnico, mas por falta de conhecimento ou 
uso incorreto das práticas de gerenciamento de projetos. Para Thomsett (2002), 
Chin (2004) e Highsmith (2004), os métodos clássicos de gerenciamento de projetos 
não provaram ser totalmente eficazes para o desenvolvimento de software. Esses 
autores explicam essa diferença pelo fato de que, geralmente, os projetos de 
desenvolvimento de software são inseridos em um ambiente de negócios muito 
dinâmico e mudam constantemente, o que está além do padrão do gerenciamento 
de projetos clássico. Fowler (2003) também acrescentou que existem grandes 
dificuldades em medir o desempenho de projetos de desenvolvimento de software. 
 
 
33 
 
A análise dessas informações parece indicar que existem algumas 
inconsistências ou lacunas entre as práticas clássicas de gerenciamento de projetos 
adotadas pela organização e as necessidades de desenvolvimento de software da 
organização. Vários estudiosos e profissionais de desenvolvimento de software 
sentiram esse desconforto e finalmente encontraram uma maneira alternativa de 
resolver o problema. 
Como resultado da pesquisa os projetos de desenvolvimento de software 
permanecem, invariavelmente, associados ao insucesso, sendo que parcela deste 
mau desempenho é justificada pelo emprego incorreto ou pela inadequação das 
práticas de gerenciamento de projetos, o que sugere a necessidade dese repensar 
a disciplina de gerenciamento de projetos aplicada ao desenvolvimento de software 
(STANDISH GROUP INTERNATIONAL, 2001; 2003). 
Nesse momento de reflexão sobre a prática, alguns autores, como Thomsett 
(2002) e Cohen e Graham (2002), propuseram que os critérios para medir o sucesso 
do projeto também fossem alterados, acreditando que as formas tradicionais de 
avaliação podem ser um dos fatores que levam ao fracasso. 
4.4 VISÃO MODERNA DE SUCESSO DE UM PROJETO 
Os proponentes acreditam que o gerenciamento de projetos não é apenas 
um processo técnico, Cohen e Graham (2002, p. Vii) acreditam que o 
gerenciamento de projetos “[...] transformou-se em um processo de negócio de 
importância crítica” os gerentes devem sempre procurar melhorar a contribuição do 
projeto para os resultados da organização. Eles enfatizaram que a tomada diária de 
decisões do gerente de projetos deve ser orientada para atender às necessidades 
das expectativas dos acionistas, e a lucratividade futura da empresa também deve 
ser considerada ao gerenciar o projeto. 
Para resolver o problema do sucesso no gerenciamento de projetos, Cohen 
e Graham (2002, p. vii-ix) introduziram um conceito inovador chamado Ciclo de Vida 
do Resultado do Projeto (POL). Sob a defesa de Thomsett (2002, 27-29), a 
 
 
34 
 
responsabilidade do gerente de projeto não termina mais no final da fase de 
desenvolvimento do projeto, mas se estende a toda a fase pós-implementação. 
 
 
Fonte: thomsett, 2002, p. 28 
Nesse modelo, é essencial que os gerentes e funcionários do projeto 
entendam e adotem a perspectiva da alta administração - a necessidade de gerar 
valor econômico ao planejar e executar os projetos. (COHEN; GRAHAM, 2002, p. 
vii-ix.). 
Cohen e Graham (2002) mostraram em seu trabalho que a "velha" visão de 
sucesso medida alcançando resultados esperados e cumprindo prazos e metas de 
custo perdeu sua validade. Pelo contrário, eles recomendam aumentar o valor 
econômico como o principal critério para avaliar o sucesso do gerenciamento de 
projetos. 
De uma perspectiva mais extrema, Thomsett (2002, p. 69) até mencionou 
“[...] o conceito da restrição tripla levou mais projetos ao insucesso, do que qualquer 
outro mito do gerenciamento de projetos”. Segundo o autor, para cumprir prazos e 
metas de custo, vários projetos foram restringidos durante o processo de 
 
 
35 
 
desenvolvimento, e o resultado final não foi satisfatório. Embora defenda a visão do 
ciclo de vida dos resultados do projeto, Thomsett (2002, p. 69-77) não se limita ao 
conceito de valor econômico, mas recomenda-se definir o sucesso como um padrão 
que atenda às expectativas do cliente. Isso está totalmente relacionado ao 
entendimento do ambiente do cliente. Está relacionado ao entendimento da cultura 
do cliente, pressão dos negócios, foco e objetivos. Tom Sett (ibid.) explorou ainda 
mais o conceito de expectativas, apontando que as expectativas podem ser 
definidas de acordo com os sete indicadores principais a seguir: 
 
 Grau de satisfação dos clientes: Como o cliente se sente sobre o 
projeto? 
 Atendimento aos objetivos e requisitos do projeto: O que o cliente 
deseja do projeto? 
 Entrega do projeto dentro do orçamento: Quanto o cliente está 
disposto a pagar pelo projeto? 
 Entrega do projeto no prazo: Quando o cliente precisa desse projeto? 
 Entrega de valor à organização: Quando o cliente precisa desse 
projeto? 
 Atendimento aos requisitos de qualidade: Qual é o nível de 
construção do produto? 
 Satisfação da equipe de projeto: Como a equipe se sente sobre o 
projeto? 
 
A importância de cada um dos indicadores acima varia de projeto para 
projeto. Portanto, Thomsett (ibid.) recomenda o uso de uma escala que indique se 
um determinado indicador é eficaz para o projeto de pesquisa e sua importância 
(veja a figura abaixo). A localização de cada indicador deve ser determinada em 
conjunto pelo cliente, patrocinador e gerente de projeto e comunicada à equipe do 
projeto. Em seguida, os projetos devem ser planejados e executados sob a 
orientação dessas diretrizes para aumentar as chances de sucesso. 
 
 
36 
 
A adoção desses novos métodos para medir o sucesso do projeto criou um 
novo paradigma de gerenciamento de projetos, transformando o conceito de 
restrições triplas (MEREDITH; MANTEL, 2000, p. 4) em possibilidades, como 
mostrado nas tabelas abaixo, principalmente para promover os fundamentos do 
sistema de controle (COHEN; GRAHAM, 2002, p. 6-23; THOMSETT, 2002, p. 69-
77). 
 
 
Fonte: thom sett, 2002, p. 75 
 
 
37 
 
 
Fonte: cohen; graham, 2002, p.14. 
 
Fonte: cohen; graham, 2002, p.14. 
As conseqüências desta nova orientação se traduzem numa alteração da 
forma de mensuração do sucesso dos projetos (COHEN; GRAHAM, 2002): 
 
 Desde o cumprimento de especificações rigorosas até a satisfação 
do cliente e a implementação de intenções estratégicas; 
 Do cumprimento de orçamentos rigorosos ao gerenciamento do fluxo 
de caixa para aumentar o valor para o acionista; 
 Do prazo prescrito à escolha do melhor horário para entrar no 
mercado e reduzir o tempo para empate; 
 Do foco interno no projeto ao foco externo em clientes, mercado, 
concorrência e todo o ciclo de vida do projeto; 
 
 
38 
 
 Desde a simples execução do projeto até a implementação de 
estratégias organizacionais. 
Os gerentes de projeto devem entender o significado desses novos padrões 
e descobrir como gerenciar seus projetos para alcançar resultados satisfatórios, 
com foco na rentabilidade dos negócios. Lembrando que esses resultados não são 
estáticos, o projeto é afetado pela turbulência do ambiente organizacional, 
especialmente pelas forças do mercado global (COHEN; GRAHAM, ibid; 
THOMSETT, 2002). 
Nesse novo ambiente, o gerente de projetos deve ser capaz de tomar 
decisões imediatas à medida que o ambiente muda e ser capaz de tratar o projeto 
como uma empresa completa (COHEN; GRAHAM, 2002; THOMSETT, 2002). Em 
outras palavras, o autor defendeu a mudança do conceito clássico de 
gerenciamento de projetos para um modelo mais ágil que proporcionou aos 
gerentes e equipes de projeto maior autonomia. 
 
 
 
 
 
 
 
 
 
 
 
 
 
39 
 
5 REFERÊNCIAS BIBLIOGRÁFICAS 
SCHILLING, M.A., HILL, C.W.L. Managing the new product development 
process: strategic imperatives. Academy of Management Executive, [S.l.:s.n], 
v.12, n.13, p. 67-81, 1998. 
CLARK, K. B., FUJIMOTO T. Product development performance: strategy, 
organization, and management in the world auto industry. Boston, Mass.: 
Harvard Business School Press, 1991. 
LAZAREVIC, George. An exploratory study of the new product 
development utilized by software companies using agile product development 
approach. Oct. 2003. Disponível em 
<http://www.agilealliance.org/articles/articles/agileOct.pdf>. Acesso em agosto, 
2005. 
PORTER, M. E.; MILLAR, V. E. How information gives you competitive 
advantage. Harvard Business Review, v. 63, n. 4, p. 149-160, Jul.-Aug. 1985. 
BOOCH, G. Developing the future. Communications of the ACM. ACM 
Press, [S.l.], v. 44, n. 3, p. 118–121, 2001. 
PORTER, Michael E. A vantagem competitiva das nações. Trad. 
Elizabeth Maria de Pinto Braga. Rio de Janeiro: Campus, 25 ed. 1989. 
INTERNATIONAL DATA CORPORATION – IDC. Directions 2004. [S.l.]: 
2004. Disponível em <www.idc.com>. Acesso em dezembro, 2004. 
BASKERVILLE, R. et al. Is internet-speed software development 
different? IEEE Software, [S.l.], v. 20, n. 6, p. 70–77, 2003 
MAURER, Frank.; MARTEL, Sebastien. Extreme programming: rapid 
development for webbased applications. IEEE Internet Computing, [S.l.], v. 6, n. 
1, p. 86–90, Jan. 2002. 
 
 
40 
 
COCKBURN, A.; HIGHSMITH, J. Agile software development: the 
business of inovation. IEEE Computer Magazine, [S.l.], p. 131-133, sep 2001a. 
HIGHSMITH, Jim. Adaptative management: patterns for the e-business 
era. Cutter ITJournal, [S.l.], v. XII, n. 9, sep. 1999. 
CHIN, Gary. Agile project management: how to succeed in the face of 
changing project requirements. NY: Amacon, 2004. 
PROJECT MANAGEMENT INSTITUTE - PMI. PMBOK guide: Um guia do 
conjunto de conhecimentos do gerenciamento de projetos. Pennsylvania: 
Project Management Institute, 2000 ed, 2000. 
MEREDITH, Jack R., MANTEL, Samuel J. Project management: a 
managerial approach, New York: John Wiley & Sons, Inc., 2000. 
______. Guia PMBoK: Um guia do conjunto de conhecimentos do 
gerenciamento de projetos. Pennsylvania: Project Management Institute, 3. ed, 
2004. 
KERZNER, Harold. Project Management: a systems approach to 
planning, scheduling and controlling. New York: Van Nostrand Reinhold, 1992. 
VERZUH, E. The fast foward in MBA in project management. John Wiley 
& Sons, Inc., 1999. 
DINSMORE, P. C.; NETO, F. H. S. Gerenciamento de projetos: como 
gerenciar seu projeto com qualidade, dentro do prazo e custos previstos. Rio 
de Janeiro: Qualitymark, 2004. 
MAXIMIANO, A. C. A. Administração de projetos: como transformar 
idéias em resultados. São Paulo: Atlas, 2 ed. 2002. 
FORSBERG, K. et al. Visualizing project management: a model for 
business and technical success. John Wiley & Sons, Inc, 1996. 
THOMSETT, R. Radical Project Management. NJ: Prentice Hall, 2002. 
 
 
41 
 
BECK, K. Embrance Change with Extreme Programming. IEEE 
Computer Magazine, [S.l.], Oct 1999, p. 70-77. 
BOHEM, Barry. Get ready for agile methods, with care. IEEE Computer 
Magazine, [S.l.], Jan. 2002, p. 64-69. 
COHEN, David et al. Agile software development: a DACS state of art report. 
NY: Data Analysis Center for Software - Fraunhoufer Center for Experimental 
Software Engineering Maryland and The University of Maryland, 2003. 
Disponível em <http://www.thedacs.com/techs/agile/>. Acesso em abril, 2005. 
PAULK, Mark. C. ExtremepProgramming from a SW-CMM perspective. 
IEEE Software, [S.l.], v. 18, n. 6, p. 19–26, Nov. 2001. 
SOFTWARE ENGINEERING INSTITUTE – SEI. The capability maturity 
model for software: guidelines for improving the software process. Boston: 
Addison-Wesley, 1995. 
PINTO, Jeffrey K.; KHARBANDA, O.P. Successful project managers. 
New York: Van Nostrand Reinhold, 1995a. 
JIANG, J. J. et al. Ranking of system implementation success factors. 
Project Management Journal, [S.l.], December, 1996. 
STANDISH GROUP INTERNATIONAL. The chaos report, 1999. 
Disponível em 
<http://www.standishgroup.com/sample_research/PDFpages/Chaos_1999.pdf>. 
Acesso em novembro 2004. 
THOMSETT, R. Radical Project Management. NJ: Prentice Hall, 2002 
UDO, N., KOPPENSTEINER, S. Will agile change the way we manage 
software projects? Agile from a PMBoK guide perspective. Projectway, [S.l.], 
2003. 
COHEN, Dennis. J.; GRAHAM, Robert. J. Gestão de projetos: MBA 
executivo. Trad. Afonso Celso da Cunha Serra. Rio de Janeiro: Campos, 2002