1

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

2
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!

3
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

4
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.

5
 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).

6
 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 de valor 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

7
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

8
(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.

9
 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;

10
  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 ciclo de 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

11
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.

12
 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;

13
  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.

14
 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

15
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

16
 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

17
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 processo de gerenciamento de
projetos de acordo com o PMI (2004, página 70) e sua associação com grupos de
processos e áreas de conhecimento.

18
 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.

19
 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

20
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.

21
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.).

22
 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 diferentes paí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).

23
 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

24
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.

25
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

26
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

27
 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ção e 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

28
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

29
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.

30
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.

31
 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.

32
 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 de se 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

33
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

34
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.

35
 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

36
 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;

37
  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.

38
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.

39
 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 IT Journal, [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.

40
 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

41