Embed Size (px)
Citation preview
Hermano Perrelli de Moura
Universidade Federal de Pernambuco
Software Project Framework
The Framework
Recife, 29 de março de 2011
2
Resumo
Cada vez mais, organizações e indivíduos estão se organizando em torno de projetos
essenciais para o desempenho de suas atividades. A pesquisa sobre projetos e práticas de
gestão de projetos têm evoluído como uma resposta a esta abordagem à organização do
trabalho. Este artigo inicia com o relato de um estudo sobre a evolução do pensamento em
gerenciamento de projetos. Uma perspectiva histórica, sobre as abordagens na arte e na
ciência do gerenciamento de projetos, é apresentada por meio de uma metodologia de
revisão sistemática. O objetivo da análise resultante é verificar como o gerenciamento de
projetos e pesquisas relacionadas têm evoluído ao longo dos anos e identificar as
tendências relacionadas. A revisão sistemática aqui relatada tem por objetivo alcançar
uma melhor compreensão sobre projetos e sua gestão.
Explora-se ainda a definição de projeto de software e gerenciamento de projetos de
software. O principal objetivo é a compreensão profunda da própria natureza de um
projeto de software. Ao fazer isso, o desenvolvimento de uma melhor compreensão da
gestão de tais projetos é esperada. A partir de uma revisão sistemática da evolução do
pensamento em gestão de projetos e da compreensão da natureza do software e do
projeto de software, um framework para gestão de tais projetos é então proposto.
O framework para projetos de software (SPF) é proposto através da definição dos seus
elementos. Um conjunto de novas dimensões para a gestão de projetos de software é
definido: Aprendizado, Complexidade, Conhecimento, Incerteza, Inovação, Liderança,
Marketing, Metodologias, Mudança, Política, Simplicidade, Social, Stakeholder e Valor. Um
estudo da literatura relacionada com algumas dessas dimensões é feita, o que permite um
melhor entendimento das mesmas.
Finalmente, conclusões e oportunidades para pesquisas futuras são indicadas.
Palavras-chave
Projetos, software, projetos de software, gerenciamento de projetos de software,
gerenciamento de projetos, estrutura de gerenciamento de projetos de software,
pensamento em gerenciamento de projetos, ideias, história, evolução da gestão de
projetos.
3
Conteúdo
INTRODUÇÃO 4
CONTEXTUALIZAÇÃO 4
OBJETIVOS 5
METODOLOGIA 6
EVOLUÇÃO DO PENSAMENTO NA GESTÃO DE PROJETOS 7
ANTES DE 1960 7
1960-1969 8
1970-1979 8
1980-1989 9
1990-1999 10
2000-2009 12
2010 17
SOFTWARE E PROJETOS DE SOFTWARE 22
A NATUREZA DOS PROJETOS DE SOFTWARE 25
UM FRAMEWORK PARA PROJETOS DE SOFTWARE 26
FUNDAMENTOS 26
DIMENSÕES 27
COMPLEXIDADE 27
INCERTEZA 30
INOVAÇÃO 33
VALOR 35
RELACIONAMENTOS 37
SUCCESSO E FRACASSO 37
TIPOLOGIA E CATEGORIZAÇÃO 38
PROCESSOS, MÉTODOS, TÉCNICAS E FERRAMENTAS 38
CONCLUSÕES E PERSPECTIVAS 39
AGRADECIMENTOS 39
REFERÊNCIAS 39
4
Introdução Organizar o trabalho em projetos tem sido um fenômeno crescente em nossa sociedade.
Organizações e indivíduos estão se organizando em torno de projetos. Nós nos tornamos
uma sociedade orientada por projetos. A pesquisa e prática na área de gestão de
gerenciamento de projetos (PM – Project Management) têm evoluído como uma resposta a
esse fato.
As organizações vivem atualmente grande competitividade mercadológica, demandando
rápidas decisões, melhor alocação de recursos e uma clara definição de foco. Em um
ambiente de desenvolvimento de software típico não é diferente. Vários tipos de projetos
são propostos, com diferentes objetivos, em que é preciso gerenciar estrategicamente e de
acordo com as metas organizacionais.
A previsão do francês Hubert Landier, professor do Institut d’Études Politiques de Paris e
diretor da revista Management et Conjoncture Sociale, é de que em 2015, mantido o ritmo
atual das mudanças, as empresas não terão mais a concepção que têm hoje: corpórea,
cercada de muros e fronteiras. Segundo ele, em boa parte do planeta estará consolidado o
conceito de empresa virtual, operando a partir de estruturas altamente flexíveis, voltadas
para o atendimento de multiprojetos. "O ator principal da vida econômica será, então, o
projeto e não mais a empresa. Cada projeto, de acordo com o seu status, envolverá outras
empresas, que se ocuparão de partes específicas." Especializado em mudanças e
reestruturação organizacional, Landier tem percorrido o mundo, nos últimos anos, como
pesquisador, consultor e conferencista (MVC, 2003;, management-social.com, 2003). A
importância da utilização de teorias, métodos e ferramentas na gerência de projetos é cada
dia mais reconhecida em todas as áreas da atividade humana (Prado, 2000; PMI, 2004).
Após essa introdução, uma contextualização e reflexão sobre a gestão do é feita. A
metodologia utilizada para a revisão da literatura é apresentada. A evolução do
pensamento de gerenciamento de projetos é apresentada em seguida. Um estudo sobre
software e a natureza dos projetos de software é feito e apresentado na sequência. O
framework para projetos de software é definido e algumas de suas dimensões detalhadas
em termos de uma revisão da literatura. Finalmente, conclusões e oportunidades para
trabalhos futuros são indicadas.
Contextualização A relevância levantada na seção anterior é reconhecida por organizações, comunidade e
pessoas, tanto no setor público quanto no setor privado. Na área de software e tecnologia
da informação (TI) o assunto assume a cada dia uma importância maior. Isto se deve, em
parte, pelo entendimento de que parte significativa do insucesso em projetos de software
está relacionada com uma má gerência de projetos ou, algumas vezes, por uma ausência
completa de gerenciamento (The Standish Group, 1994).
A gestão de projetos de software, por sua vez, tem características singulares devido à
peculiaridade do produto resultante desses projetos. Segundo Walker Royce, a melhor
característica relacionada a software também é a pior: sua flexibilidade (Royce, 1998). A
característica que permite ao software transformar-se em “quase qualquer coisa” torna
difícil planejar, monitorar e controlar o desenvolvimento do software (Kruchten, 2002).
5
Podemos enxergar o processo produtivo de software sobre dois aspectos: o aspecto
técnico (ou de engenharia do produto) e o aspecto gestão (da gestão do projeto de
software). O aspecto gestão tem recebido tanta atenção no desenvolvimento de novas
abordagens, métodos, técnicas e educação de pessoas quanto o aspectp técnico. Mesmo em
livros texto de Engenharia de Software encontramos, a cada edição de um dado livro, um
conteúdo maior e mais relevante do aspecto gestão. Processos como o RUP e o Scrum
trazem explicitamente suporte ao aspecto gestão.
Na tecnologia da informação (TI) e no ambiente da indústria de software não é diferente:
as empresas e seus negócios são baseados em projetos. Os projetos são, muitas vezes, o
instrumento para organizar a produção e o engajamento com clientes.
Este trabalho é parte de um programa de pesquisa em andamento cujo objetivo é estudar
e teorizar sobre projetos de software, procurando novas formas paradigmáticas para
gerenciar tais projetos. Analisando agora a evolução do pensamento sobre PM espera-se
tomar melhores decisões no futuro, no que tange o desenvolvimento de novas dimensões
para uma melhor compreensão de projetos de software. Acredita-se que essa nova
abordagem será mais eficaz na compreensão e gestão de projetos de software. Abordagens
instrumentais não são suficientes para um artefato de alta flexibilidade, incerto, inovador
e vagamente definido como software.
Objetivos O objetivo da pesquisa aqui apresentada foi estudar o pensamento e estado da arte em
gerenciamento de projetos de software sob quatro eixos iniciais – complexidade,
incerteza, inovação e valor, propondo um “modelo de referência” que contemple o
relacionamento entre estes eixos (e, possivelmente, outros eixos). Esses eixos serão
denominados “dimensões”.
A contribuição esperada dar-se-á, principalmente, pela definição de um framework para
gerenciamento de projetos de software, que contemple novos paradigmas de
gerenciamento e que contribua para responder a desafios da pesquisa atual em
gerenciamento de projetos (Santana & Moura, 2005; Saad Neto, 2008; Agile Alliance,
2009).
Além das quatro dimensões estudadas, outras dimensões são definidas. Por exemplo,
simplicidade. Embora paradoxal, a busca pela simplicidade nos projetos pode ser uma
abordagem promissora para lidar com a complexidade (Agile Alliance, 2009; Andersen,
2008; Schumpeter, 2004). De fato, metodologias ágeis exibem simplicidade; os princípios
declarados no Manifesto para Desenvolvimento Ágil de Software e seus autores tinham
por objetivo buscar formas mais simples e eficientes de construir software (Highsmith,
2004; Winter et al., 2006; Bjørn et al., 2004).
Na presente proposta, embora a identificação de outras dimensões seja feita, pretende-se
delimitar o estudo apenas às quatro dimensões já mencionadas (complexidade, incerteza,
inovação e valor).
6
Metodologia A pesquisa realizada foi teórica (tem como objetivo ampliar generalizações, definir leis
mais amplas, estruturar sistemas e modelos teóricos, relacionar e enfeixar hipóteses),
exploratória (caracterização inicial do problema, sua classificação e sua definição,
constituindo-se no primeiro estágio de toda pesquisa científica), bibliográfica e qualitativa
(os modelos qualitativos são aqueles formulados a partir de descrições intuitivas do
pesquisador ou do indivíduo pesquisado).
A metodologia para desenvolvimento do projeto foi baseada em um processo iterativo e
incremental de gerenciamento de projetos (Kruchten, 2002; Rational Software
Corporation, 2000; Meneses, 2001): o resultado foi obtido através de ciclos de
desenvolvimento (iterações), onde cada ciclo é planejado, executado e avaliado.
A escolha da abordagem metodológica foi orientada pelo objetivo de mostrar uma
perspectiva histórica (evolução) do pensamento em PM com base na literatura existente.
Neste contexto, uma revisão sistemática (SR1) foi realizada para identificar as fontes
significativas de informações (dados).
Uma revisão sistemática é um resumo da pesquisa que usa métodos explícitos para
realizar uma pesquisa bibliográfica minuciosa e avaliação crítica de estudos individuais
para identificar evidências válidas e aplicáveis. É geralmente aplicada no contexto
biomédico ou de ciências da ‘saúde, mas as revisões sistemáticas podem ser aplicados em
qualquer domínio da investigação. Seleção ou triagem de artigos para a inclusão é
geralmente realizada através da revisão dos títulos e resumos dos artigos identificados, e
excluindo aqueles que não atendem aos critérios de elegibilidade. Frequentemente, mas
nem sempre, usa técnicas de estatística (meta análise) para combinar estes estudos
válidos, ou pelo menos usa classificação dos níveis de provas, dependendo da metodologia
utilizada (Wikipedia, 2010b). As revisões sistemáticas podem ser aplicadas a: (i) resumir a
evidência existente sobre um fenômeno, (ii) identificar as lacunas existentes em matéria
de investigação, (iii) estabelecer um arcabouço para posicionar uma pesquisa, (iv) apoiar a
geração de novas hipóteses, (v )realizar uma revisão da literatura (completa e imparcial)
(Travassos et al., 2006). Revisões sistemáticas têm por objetivo sintetizar as pesquisas
existentes de maneira justa (sem viés), rigor (de acordo com um procedimento definido) e
aberta (garantindo que o processo de revisão é visível para outros investigadores).
O objetivo da SR realizada foi verificar, com base na literatura, como a pesquisa e
pensamento em PM tem evoluído. Além disso, esperava-se identificar tendências na
pesquisa e no pensamento em PM. Como mencionado anteriormente, essa SR está no
contexto de um programa de pesquisa que visa definir um novo framework para a PM (em
especial para projetos de software). Assim, espera-se coletar informações para ajudar a
definir este framework e para identificar as suas dimensões.
Definir um novo framework para a PM é uma tarefa desafiadora. A evolução do
pensamento e da pesquisa em PM foram considerados como um ponto de partida.
Identificar as agendas, as questões de pesquisa, os problemas práticos e pensamento é um
processo caro. Além disso, se esse contexto não está claramente identificado e
1 SR – do inglês Systematic Review.
7
compreendido, o futuro framework pode não ser relevante. Assim, o presente trabalho
visa responder às seguintes questões de investigação: (i) como o pensamento e a pesquisa
em PM têm evoluído? e (ii) quais são as perspectivas futuras para PM pensamento e de
pesquisa em PM? O restante desta seção apresenta o protocolo de pesquisa e os estudos
(artigos) resultantes da seleção.
Os seguintes termos foram definidos para identificação das fontes de informação: project,
project management, project management directions, project management history, project
management philosophy, project management research, project management researchers,
project management thinking, project management rethinking. Um conjunto de 38 estudos
estava disponível antes do início da revisão sistemática. As seguintes áreas de aplicação
são beneficiadas com os resultados da revisão sistemática: gerenciamento de projetos,
gestão. Tipos de profissionais que serão beneficiados: os pesquisadores de gerenciamento
de projetos, gerentes de projeto, gerentes, associações de gerenciamento de projetos
profissionais. Uma análise qualitativa foi realizada como meta-análise. Os seguintes
critérios para seleção das fontes de estudos foram definidos: revistas indexadas no ISI;
revistas de gerenciamento de projetos; periódicos de gestão; disponibilidade on-line, a
disponibilidade de mecanismos de busca.
Evolução do Pensamento na Gestão de Projetos Esta seção apresenta um subconjunto dos dados coletados a partir dos estudos
selecionados na SR (incluindo os estudos indiretos). A sequência cronológica é seguida.
Esse resultado, aqui apresentado, é uma seleção de trechos (texto) dos trabalhos originais.
No entanto, algumas partes foram editadas para melhor apresentação.
Antes de 1960 As ideias e realizações de Taylor - princípios da administração científica (1911) - foram
um marco para a gestão e, posteriormente, para todo o desenvolvimento do
gerenciamento de projetos como ainda hoje é entendida. Também a atividade
administrativa de Fayol, envolvendo planejar, organizar, comandar, coordenar e controlar,
teve uma grande influência sobre como os projetos são gerenciados hoje. Por exemplo, o
Project Management Institute (PMI) PMBOK fases do projeto e grupos de processos -
iniciação, planejamento, execução, monitoramento e controle, e encerramento (Project
Management Institute, 2008) - são muito semelhantes às funções administrativas de Fayol
atividade. trabalho Adamiecki (1896) sobre harmonograms e Gantt na criação do gráfico
de Gantt (1919) também são importantes na compreensão das ideias da época: relacionar
as tarefas de produção e de seu progresso no tempo. A inclusão da dimensão tempo é,
talvez, um dos aspectos mais relevantes das contribuições de Adamiecki e Gantt (Wren,
1994). A Segunda Guerra Mundial (1939-1945) coloca novos desafios em matéria de
gestão de produção. O esforço de guerra nos EUA deram a oportunidade para aplicação
dos instrumentos de gestão desenvolvido na primeira metade do século XX. Durante os
dois primeiros períodos da Guerra Fria (1947-1962) os métodos de diagramação de redes
foram desenvolvidos: o CPM (1957) e PERT (1957). Projetos são conjuntos de tarefas em
rede. Projetos e gerenciamento de projetos foram, na década de 1950, melhor
compreendidos e diferenciados da gestão dos sistemas de linha de produção. O
pensamento sistêmico (1950) abriu uma novo linha a ser explorada para resolver
8
problemas de gestão. No entanto, naquela época, não houve aplicação a gerenciamento de
projetos. Gestão por objetivos Drucker (1955) lançado no contexto de gestão, mais tarde,
influencia contextos relacionados com PM. Em particular, o gerente de projeto é visto
como o executivo do projeto e no comando da entrega dos resultados do projeto. Vários
grandes projetos certamente começaram a construir um conhecimento prático que nas
décadas mais tarde viria a contribuir para o corpo de conhecimento em gestão do projetos.
Empire State Building (1930-1931), a represa Hoover (1931-1936), a construção do
Pentágono (1940-1941), e o desenvolvimento dos mísseis Polaris (1956-1961) são
exemplos de grandes projetos dessa época.
1960-1969 O desenvolvimento da abordagem Cost/Scheduling Control System Criteria (C/SCSC), por
parte do governo federal dos EUA produziu alguns bons resultados (Archibald e Villoria,
1967). CPM e PERT foram aplicados em projetos reais durante os anos 1960 como a
citação abaixo, sobre a Expo 67, de Montreal ilustra:
Apr 28, 1967 – To get Expo built in time, Churchill used the then new project
management tool known as the critical path method (CPM). On April 28, 1967, opening
day, everything was ready, with one exception: Habitat 67, which was then displayed
as a work in progress2.
Evolução no domínio da gestão de projetos na década de 1960 também incluiu a formação
de duas importantes associações profissionais (Stretton, 2007): IPMA – International
Project Management Association (INTERNET naquela época), em 1965, e o PMI – Project
Management Institute, em 1969. Esta foi uma clara indicação de uma forte atividade
prática associada com a disciplina de gerenciamento de projetos. As disciplinas de análise
de sistemas (AS) e engenharia de sistemas (SE) foram a linha principal de pensamento na
década, o que constituiu a chamada abordagem de sistemas ao gerenciamento de projetos.
O livro de Cleland e King (1983) é uma boa referência para essa linha de pensamento.
Entre os grandes projetos da década pode-se citar: Expo 67 (1962-1967) e os programas
Mercury, Gemini e Apollo (1961-1969).
1970-1979 O modelo de gestão de projetos de Galbraith (1971) é um dos muitos modelos (Wideman,
2003) que apareceram para formalizar a gestão dos projetos. A ideia principal é ver o
gerenciamento de um projeto como um processo. Shenhar (1996) observa um foco no
trabalho em equipe como uma característica definidora da gestão de projetos na década de
1970, enquanto Stretton (2007) observa uma ênfase em estruturas de divisão (breakdown
structures) e o conceito de sistemas. O contexto organizacional de um projeto é uma
questão importante. Em particular, alternativas de estruturas organizacionais para
acomodar a execução do projeto foi um tema comum de estudo. Uma combinação de
estruturas funcionais com estruturas baseadas em projetos deu origem ao arranjo
matricial. Muitas das técnicas de gerenciamento de projetos que foram desenvolvidas ou
refinadas durante os anos 1970 parecem dever muito às abordagens racionais para
resolver problemas que eram característicos dos conceitos de sistemas da época. Estes
incluem WBS (Work Breakdown Structure), OBS (Organizational Breakdown Structure),
2 Source: http://en.wikipedia.org/wiki/Expo_67.
9
matrizes de atribuição de responsabilidade, e métodos de "valor agregado" (Stretton,
2007). Aplicação do gerenciamento de projetos se espalha para muitas indústrias,
incluindo defesa, construção, produtos farmacêuticos, química, bancária, contabilidade,
publicidade, direito, governo e agências governamentais e as Nações Unidas (Kerzner,
1979). Análise de sistemas e engenharia de sistemas continuam a ser a base para reflexões
sobre PM.
1980-1989 A estrutura de adhocracia de Mintzberg (1983) é uma indicação da forte influência da
disciplina de gerenciamento de projeto sobre a organização executora do projeto. Uma
compreensão mais abrangente dos projetos começa a emergir, como ilustrado por
Högberg e Adamsson (1983):
“PM is not an exact science following given laws or established rules. It is, rather, a task
which is largely based on human relations and the specific knowledge, experiences,
character and cultural background of each individual.”
Estruturas de gerenciamento de projetos organizacionais são um tema recorrente.
Goldratt (1984) apresenta sua Teoria das Restrições (TOC). Um marco é o artigo de Larson
e Gobeli (1985), onde cinco termos utilizados por acadêmicos para definir estruturas de
PM (matriz, sistemas dispersos, gestão bipolar, e fase V) não puderam ser identificados
pelos profissionais. A tecnologia vem a desempenhar um papel importante em muitos
aspectos dos projetos. Esta década viu a popularização do PC3 (computador pessoal) e do
início da Internet e da web. Löwstedt (1985) apela à necessidade de novos frameworks
para investigar o significado da tecnologia no projeto (design) das organizações. O Guide to
the Project Management Body of Knowledge (PMBOK Guide) foi publicado, como um white
paper, pela primeira vez pelo PMI em 1987. Archibald posiciona projetos como veículos
para o crescimento estratégico (Russell D. Archibald, 1988). Esta é uma nova linha de
pensamento relevante: projetos em um contexto mais estratégico. Até agora, os projetos
eram vistos como arranjos operacionais. Projetos com características semelhantes são
frequentemente agrupados em programas e uma boa gestão estratégica do crescimento
futuro de uma organização requer uma seleção correta de projetos de crescimento
(Russell D. Archibald, 1988). Em (Kumar, 1989), a importante questão do planejamento é
abordada. No entanto, Kumar não apresenta nenhuma justificativa para as estratégias e
filosofias propostas, que foram baseadas em um projeto específico para o setor da
construção. Uma abordagem de sistemas para gestão de projetos estratégicos é
apresentado por Milosevic (1989). O artigo aborda um modelo de sistemas de gestão de
projetos estratégicos que podem ajudar o gerente de projeto a melhorar os resultados do
projeto. Como motivação Milosevic menciona que, apesar de vários modelos terem sido
desenvolvidos de apoio de gestão operacional do projeto (WBS, CPM, o conceito de valor
agregado, RAM - Atribuição de Responsabilidade Matrix, etc), há uma forte necessidade de
um modelo que aborde uma visão sistêmica sobre gestão de projetos estratégicos. No
modelo proposto por Milosevic, o ambiente é separado do sistema de gerenciamento de
projetos (PMS). No entanto, a questão sobre como incluir os elementos do ambiente é
colocada. Entradas e saídas são o resultado de uma troca de materiais, energia e
informações entre a PMS e outros sistemas. O PMS é apenas um subsistema de um sistema
3 PC – Personal Computer.
10
maior. Ferramentas de software para PM baseadas no PC começaram a surgir, refletindo
uma mudança de plataformas do mainframe/microcomputadores para o PC.
1990-1999 Voropajev e Scheinberg (1992) afirmam que o desenvolvimento de métodos e ferramentas
para o gerenciamento de projetos do século 21 é um problema atual, cuja solução deveria
se tornar um grande projeto internacional de pesquisa e desenvolvimento (R&D) (o
programa PM-XXI). Métodos e ferramentas para a fase inicial têm sido ativamente
desenvolvidos para projetos de médio e grande porte técnicos e organizacionais. É
necessário modificar esses métodos para os programas nacionais e internacionais,
especialmente nos domínios econômico e social. No artigo mais citado da década de 1990,
James Barker provê uma descrição etnográfica de como um sistema de controle da
organização evoluiu em resposta a uma mudança de gestão do controle hierárquico
burocrático para controle concertivo sob a forma de auto-gestão de equipes (Barker,
1993). Ao contrário de alguns defensores de tais sistemas, controle concertivo não liberta
os trabalhadores da jaula de ferro de controle racional de Weber. A ironia da mudança
nesta organização pós-burocrática é que, em vez de afrouxar, a gaiola de ferro com base
em regras de controle racional, como Max Weber chamava, na verdade, tornou-a ainda
mais apertada. Yeo (1993) traz a relevância do pensamento sistêmico ao gerenciamento
de projetos. O pensamento sistêmico emergiu como uma das disciplinas intelectuais mais
importantes, e tem provido um framework mental poderoso de referência na
compreensão de situações problema e para orientar a tomada de decisões no dia-a-dia. A
prática do gerenciamento de projetos tem sua origem na análise de sistemas e engenharia
de sistemas. A análise de sistemas exige a definição de objetivos claros e credíveis e a
formulação de alternativas viáveis. Engenharia de sistemas (SE) é orientada a metas (goal-
seeking), e enfatiza o controle de comunicação e feedback. O trabalho de Yeo tem a
finalidade de construir pontes entre a gestão de projetos com o corpo estendido do
conhecimento em pensamento sistêmico, incorporando a metodologia sistêmica soft.
Segundo Yeo houve, no entanto, uma mudança gradual de ênfase em pensamento
sistêmico: das abordagens estruturadas ou ´hard´, "sistemáticas" dos anos 1950-60 para
uma abordagem “sistêmica”, ´soft´ no anos 1970-80. Finalmente, o autor sugere que é hora
de reunir gerenciamento de projetos com o corpo estendido de conhecimento em sistemas
de pensamento. Em (Lundin & Söderholm, 1995), o segundo artigo mais citados da década
de 1990, os autores afirmam que a ideia da empresa como uma entidade eterna
possivelmente veio com a era do industrialismo. Em qualquer caso, as consequências
práticas dessa ideia contrasta nitidamente com muitas ideias sobre projetos e
organizações temporárias. As principais teorias da organização são baseadas na suposição
de que as organizações são ou devem ser permanentes, teorias sobre configurações
organizacionais temporárias (por exemplo, projetos) são muito menos frequente. O artigo
aborda a necessidade de uma teoria das organizações temporárias, buscando assim,
complementar a sabedoria tradicional sobre gestão de projetos. Alguns componentes
dessa teoria são sugeridos, através da elaboração de determinadas ideias sobre projetos.
“Ação”, em oposição a “decisão”, é um componente, que é central para uma teoria da
organização temporária. O papel do “tempo” na empresa é diferente em relação ao seu
papel na organização temporária. Packendorff (1995) faz uma análise crítica do atual
corpo de conhecimentos em gerenciamento de projetos, e propõe uma agenda alternativa
de pesquisa sobre métodos de pesquisa, teorias e focos em estudos empíricos. “A WBS tem
11
a mesma finalidade da especialização e divisão do trabalho no planejamento de produção
em massa: atribuir tarefas diferentes para pessoas diferentes, identificando sequências de
ação controlável. O problema do projeto como sendo de fato um fenômeno multifacetado,
depende da natureza da tarefa e as características ambientais, tem recebido atenção
apenas esporádicas na literatura de gerenciamento de projetos”. O impacto sobre a
pesquisa empírica, portanto, ainda está por vir. De acordo Packendorff, projetos são vistos
como ferramentas, não como organizações. O conceito de organização temporária é dado.
Uma organização temporária: (i) é um curso (coletivo) organizado de ação que visa evocar
um processo não-rotineiro e/ou a finalização de um produto não-rotineiro, (ii) tem um
ponto pré-determinado no tempo ou estado condicional temporal quando a organização
e/ou sua missão é coletivamente esperado deixar de existir, (iii) tem algum tipo de
critérios de avaliação de desempenho; (iv) é tão complexa em termos de funções e número
de papéis que requer esforços de organização consciente (ou seja, não uma auto-
organização espontânea). Partington (1996) afirma que o gerenciamento de projetos é
cada vez mais usado para gerenciar iniciativas de mudança organizacional e não há
evidência do uso inadequado de sistemas para a gestão de tais projetos. Isso pode estar
contribuindo para o fracasso de muitos projetos de mudança organizacional, que é
amplamente relatado e para que a má gestão é frequentemente culpado. Ele examina as
forças de mudança para uma abordagem baseada em projetos de gestão e considera
potencialmente produtivos novos rumos para a investigação de gerenciamento de projetos
no contexto da mudança organizacional. Uma ideia importante encontrada em papel
Partington é que “os sistemas de gestão prescritos raramente são transferíveis”. O objetivo
do Shenhar e Dvir (1996) é abordar algumas das questões teóricas de gestão de projetos e
de sugerir uma taxonomia bidimensional de projetos e seus estilos gerenciais. Apesar da
crescente utilização da prática de gerenciamento de projetos, como dizem os autores, a
literatura a maioria das pesquisas sobre a gestão de projetos é relativamente jovem e
ainda sofre de uma base teórica escassas e uma falta de conceitos. Shenrar e Dvir citam
Pinto e Covin (1989): “a tendência predominante entre a maioria dos acadêmicos tem sido
a de caracterizar todos os projetos como fundamentalmente similares”, e “a visão implícita
de muitos acadêmicos poderiam ser representada pelo axioma: ´um projeto é um projeto é
um projeto´”. Apesar da linha universal do pensamento existente, projetos reais
frequentemente apresentam diferenças extensivas. Seus resultados sugerem que os
projetos têm de fato uma ampla gama de variações e que, em contraste com a citação de
Covin e Pinto, "um projeto não é um projeto não é um projeto". Incerteza tecnológica
emergiu como o principal fator que influenciou as características dos projetos, e seus
quatro níveis diferentes apresentam padrões distintos de estilos gerenciais e práticas de
gestão. A identificação explícita, clara do tipo de projeto antes da execução deverá
proporcionar uma base para uma boa adaptação das atitudes gerenciais e para uma
melhor seleção de ferramentas gerenciais. Tal abordagem adaptativa pode aumentar a
probabilidade de sucesso do projeto e contribuir para uma melhor eficácia organizacional.
No entanto, outra fonte de incerteza pode ser a extensão da equivocidade (equivocality) do
projeto e a dificuldade de articular precisamente os requisitos do cliente. Algumas missões
do projeto não estão bem definidas, causando muitas vezes uma mudança no escopo do
projeto no meio do caminho. A publicação da primeira edição do PMBOK pelo PMI (1996)
é um marco desta década. O gerenciamento de projetos está estruturado em nove áreas de
conhecimento. Alguns processos, como a Gestão de Recursos Humanos do Projeto, são
superficiais refletindo uma abordagem mais orientada a sistemas no padrão. Em (Dawson,
12
1997), o foco é uma questão metodológica (método de investigação processual). No
"mundo real" exemplos de experiência da empresa, estudos de caso processual são
capazes de contar sua própria história de mudar a maneira se desdobra na prática, e como
a substância, contexto e política de mudar tudo de interconexão e sobreposições na
definição da odisseia dinâmica de trabalho mudar. Como tal, a pesquisa processual oferece
a possibilidade de alargar as nossas interpretações, possibilitando a apresentação de
dados de mudança complexos. Foi alegado que não pode haver nenhum substituto para os
investigadores "sujar as mãos" em fazer a pesquisa. Dvir et al. (1998) tenta responder a
duas perguntas: Existe um caminho natural para classificar os projetos e quais são os
fatores específicos que influenciam o sucesso de vários tipos de projetos? Talvez um dos
principais obstáculos para a compreensão das razões por trás do sucesso de um projeto
tem sido a falta de especificidade dos construtos empregados em estudos de
gerenciamento de projetos. Muitos estudos dos fatores de sucesso do projeto usaram uma
abordagem universalista, assumindo uma semelhança fundamental entre os projetos. O
objetivo deste estudo é combinar a teoria dos fatores de sucesso do projeto com a busca de
uma classificação natural do projeto. No entanto, diferentemente da pesquisa anterior, que
apresentou um dado construir e, em seguida, identificou fatores específicos de cada tipo,
essa busca primeira pesquisa para um sistema de classificação apropriado usando análise
discriminante linear e então usa esta classificação, a fim de identificar os fatores de
sucesso de projetos específicos para diferentes classes de projetos . Lechler (1998), em
uma análise detalhada, mostra a importância fundamental das pessoas no sucesso do
projeto. Esta análise indicou uma tendência crescente para reconhecer o lado “humano” da
gestão de projetos como crucial para o sucesso do projeto. O Japan Project Management
Forum (JPMF) é fundado em dezembro de 1998 como uma divisão da Associação para o
Progresso da Engenharia do Japão (ENAA) para promover a gestão do projeto no Japão.
Mais tarde (em 2005) se combina com o Project Management Professionals Centro de
Certificação (PMCC) para dar forma à Project Management Association do Japão (PMAJ).
Em (Evaristo & Fenema, 1999), o objetivo é, em primeiro lugar, a introdução de uma
tipologia de novas formas de gerenciamento de projetos. Enraizado na literatura existente
de gerenciamento de projetos, o modelo compreende duas dimensões essenciais captar a
essência dos novos desafios à gestão de projetos: projetos em sites únicos versus projetos
multi-site e projeto único versus múltiplos projetos. Em segundo lugar, o artigo identifica
os padrões de evolução dos projetos através de três níveis através de formas projeto. O
modelo de estrutura e evolução servir como um guia para os profissionais de mapear o
tipo de projeto que estão envolvidos, e determinar quais as questões críticas surgem em
diferentes tipos de projetos. Novos métodos e ferramentas podem ser desenvolvidas para
se encaixarem em diferentes tipos de projetos. Em segundo lugar, o modelo suporta os
pesquisadores em gestão de projetos para estruturar a investigação e considera como sua
experiência se enquadra na tipologia. Vários grandes projetos muito ocorrem nesta
década, incluindo o Bug do Milênio, As Três Gargantas (China) e o Channel Tunnel Rail Link
(Reino Unido).
2000-2009 Em (Hobday, 2000) – o artigo mais citado na década de 2000 - o objetivo é identificar
algumas das características da organização baseada em projeto (PBO – project-based
organization), olhando em profundidade como os projetos CoPS são gerenciados em um
grande PBO, comparando-os com projetos CoPS produzidos em uma divisão funcional da
13
mesma empresa. O propósito de adotar uma perspectiva “bottom-up” do projeto é
explorar a dinâmica das estruturas de projetos, processos e desempenho na PBO em
relação a uma organização funcional. CoPS são projetos de alta tecnologia, bens de capital
business-to-business usados para produzir bens e serviços para consumidores e
produtores. por exemplo, os sistemas aviônicos para aeronaves. Usando uma abordagem
de estudo de caso, o artigo compara a eficiência e a eficácia da organização funcional
orientada matriz, com o PBO, apontando os pontos fortes e fracos do PBO na gestão de
CoPS. Nightingale (2000) propõe que as tecnologias são construídas seguindo um conjunto
de tarefas de solução de problemas inter-relacionados que restringem a gama de
processos de inovação possíveis. O autor desenvolve uma estrutura que liga produtos a
seus processos de inovação, para mostrar como a complexidade de bens de capital
sistêmica produz problemas específicos de inovação que não são normalmente
encontrados em outros ambientes. Ao vincular conhecimento, tecnologia e organização, o
artigo explica como ambas as incertezas de projeto e o número de loops de feedback e
redesign podem ser reduzidos, mas não eliminada, produzindo um processo de
desenvolvimento mais eficaz de menor custo. Por fim, o framework argumenta que bens
de capital complexos têm problemas específicos de gestão da inovação que não são
encontrados na mesma medida em produtos simples. Em (Prencipe & Tell, 2001), o
objetivo é discutir a capacidade de aprendizagem em empresas baseadas em projeto. Os
autores do estudo se e como as empresas com base no projeto são capazes de capitalizar o
conhecimento que é adquirido durante a execução de um projeto e sua capacidade de
transferi-lo para outros projetos ou partes da organização. O foco é em CoPS. Em (White &
Fortune, 2002) os resultados de uma investigação destinada a captar a experiência do
"mundo real" de pessoas ativas na gestão de projetos é relatado. A pesquisa foi realizada
com um questionário a ser enviado para 995 gerentes de projeto que representa 620
organizações nos setores público e privado no Reino Unido. Dos 995 questionários que
foram enviados no inquérito principal, 236 foram devolvidos (taxa de resposta de
23,72%). Os três critérios utilizados para julgar o sucesso dos projetos mais citados na
literatura (no tempo, para o orçamento, com a especificação) também foram mais altos os
critérios de sucesso classificado identificados na pesquisa. No entanto, eles não foram o
único critério pelo qual resultado do projeto foi julgado, o ajuste entre o projeto e a
organização e as consequências do projeto para o desempenho da empresa também foram
relatados como critérios importantes. Steyn (2002) ilustra a utilização da Teoria das
Restrições (TOC) (Goldratt, 1984) para áreas como a gestão de riscos do projeto e
gerenciamento de custos do projeto. A possibilidade de aplicar TOC para seleção de
projetos é sugerido para investigação posterior. Até agora TOC foi aplicada na
programação do projeto único para reduzir a duração do projeto e simplificar o controle
do projeto (Goldratt, 1997). Em (Cooke & Arzymanow-Davies, 2003) os resultados de uma
investigação sobre a natureza e a extensão das variações entre as práticas de
gerenciamento de projetos em seis indústrias são apresentados. A investigação teve o
objetivo concreto de apoiar um grupo de organizações farmacêuticas de I & D na busca de
um modelo ideal de gestão de projetos. Um total de 10 'domínios' foi identificado através
de métodos qualitativos em seis indústrias. Cada entrevista suscitou uma avaliação
quantitativa das práticas relativas ao domínio, usando escalas pré-determinadas, e
comentários qualitativos sobre as práticas com base nas experiências do entrevistado. As
diferenças entre as empresas e indústrias de existir em cada domínio. Os modelos de
projeto de gestão mais desenvolvidos (que poderia ser dito que equivale a medida da
14
maturidade em gerenciamento de projeto) foram encontrados nas indústrias
petroquímicas e de defesa, que, em média, teve alta na maioria das dimensões. Outras
indústrias (R&D Farmacêutica, Construção, Telecomunicações e Serviços Financeiros)
apresentado algumas diferenças interessantes em diferentes domínios, mas não mostrar a
coerência ou as pontuações dos dois principais indústrias. Em (Engwall, 2003), o segundo
papel mais citados da década de 2000, menciona que, com poucas exceções (por exemplo,
(Brown & Eisenhardt, 1997), (Eskerod, 1998), (Hobday, 2000)), a pesquisa PM tem sido
dominada por uma perspectiva baseada na "o projeto só". Há provavelmente poucos
teóricos organizacionais hoje que iria desafiar a ideia de que fatores externos influenciam
fortemente a vida interna de uma organização. Estudos com uma abordagem de sistemas
mais abertos a projetos são raros. O trabalho aborda a importância da análise dos
processos interiores de um projeto em relação ao seu contexto histórico e organizacional,
ou seja, o ambiente de projeto. Assim, o que exige uma mudança ontológica, em vez de
sistemas solitário e fechado, os projetos têm de ser conceituada como contextualmente
sistemas embarcados aberto, aberto no tempo, bem como no "espaço". Söderlund (2004a)
elabora um framework para análise das pesquisas relacionadas a projetos. Conceitos como
a gestão de projetos e gestão por projetos apontam claramente para a devoção do atual
projeto de pesquisa para a gestão das empresas com base no projeto. Pesquisadores
ocupados com o desenvolvimento do conhecimento sobre os projetos vêm de diversas
disciplinas, tais como a sociologia, a geografia econômica, teoria das organizações,
comportamento organizacional e gestão estratégica. Por exemplo, o trabalho tem girado
em torno da política, a complexidade, mudança, tempo e aprendizagem. Esta pesquisa
reconhece claramente a perspectiva de que Packendorff (1995) rotula de organizações
temporária sem dar referência à pesquisa publicada em outras áreas, sobre temas
semelhantes. Söderlund sugere o termo “ecologias de projeto” de interesse desta pesquisa
nas ligações entre projetos e intervenientes (por exemplo, empresas), a sociologia dos
projetos, a economia dos projetos e na relação entre participação no projeto e
desenvolvimento da empresa. Investigação sobre ecologias do projeto, portanto, tem
interesse no estudo das inter-relações entre os projetos e seus ambientes. Lundin e
Söderholm (1998), por exemplo, destacar a importância dos descritores macro de
projetos, a fim de analisar a sociedade projetizada (projectified). Para Söderlund (2004b)
gerenciamento de projetos tem sido considerado como um campo acadêmico de técnicas
orientadas ao planejamento e, em muitos aspectos, uma aplicação da ciência da
engenharia e da teoria da otimização. Muita pesquisa tem sido dedicado à busca de fatores
genéricos de sucesso do projeto. O gerenciamento de projetos, no entanto, na última
década recebeu maior o interesse de outras disciplinas acadêmicas. Como o campo se
expande rapidamente, a necessidade de uma discussão interna e do debate sobre o
aumento projeto de pesquisa de gestão. Projeto de gestão e organização do projeto é um
assunto complexo e, argumentam os autores, é útil examinar a partir de diversas
perspectivas. O artigo discute as perspectivas emergentes no campo do projeto e também
apresenta uma série de perguntas que a pesquisa sobre projeto, em maior medida deve
reconhecer. As perguntas dizem respeito a questões como por que as organizações de
projeto existem, como eles se comportam e porque diferem, qual é a função ou de valor
acrescentado através, unidade de gestão do projeto, o que determina o sucesso ou fracasso
das organizações do projeto? O argumento principal é que muito esforço tem sido
dedicado a esclarecer as razões do sucesso do projeto e do fracasso, enquanto
minimizando uma série de questões de pesquisa importantes que precisam ser discutidos,
15
a fim de promover o conhecimento sobre gerenciamento de projetos. Em (Dvir e Lechler,
2004), com base numa amostra de 448 projetos, as interações entre três variáveis de
planejamento do projeto, a qualidade do planejamento, mudanças de objetivos, mudanças
de planos e o sucesso do projeto são analisados. Os resultados mais importantes deste
estudo são as interações entre as variáveis de planejamento e suas influências sobre o
sucesso do projeto. Ao usar a modelagem de equações estruturais, um insight sobre estas
relações indiretas complexas foi ganho. Os resultados mostram claramente que o efeito
positivo total da qualidade do planejamento é quase completamente substituído pelo
efeito negativo das mudanças objetivo. Este artigo é um bom exemplo de pesquisa
quantitativa PM. Em (Ibert, 2004) a principal característica dos projetos é a sua natureza
como "organizações temporário". Este artigo analisa a interação dos projetos e do seu
contexto social em relação à criação de conhecimento e aprendizagem organizacional. A
principal diferença entre um projeto e uma empresa é sua concepção de tempo. O artigo
apresenta um estudo exploratório de um setor dinâmico (software) para revelar os modos
específicos de aprendizagem organizacional relacionados com projetos e empresas e
delinear o relacionamento entre estes modos. O pressuposto teórico deduzido de uma
complementaridade entre o projeto - e firme - modos específicos de aprendizagem é
confrontado com os resultados empíricos a partir da ecologia software Munique. Em
(Hoegl & Proserpio, 2004) como o grau de proximidade dos membros da equipe afeta
processos colaborativos de desempenho relevantes equipe é investigada. Nesta
investigação, no entanto, os autores enfocaram o grau em que os membros da equipe estão
em proximidade geográfica (ou dispersão) e identificar como isso afeta a qualidade do
trabalho de equipa realizado. O estudo investiga a influência da proximidade dos membros
da equipe com a colaboração de equipes de desenvolvimento de software, atuando como
profissionais de TI com tecnologia avançada, tais como Computer Aided Software
Engineering (CASE), ferramentas. Para além de uma "única melhor maneira" para
descrever o campo, Tanaka (2004), na apresentação da sua visão histórica dos modelos de
gestão do projeto ao longo de quatro gerações, oferece uma vista sobre as oportunidades e
os desafios de gerenciamento de projetos no futuro. modelos de gestão do projeto pode
ser elaborado a partir de atributos como a estrutura de gerenciamento de projetos e
métodos, os motoristas socioeconômicas que solicitam que o acúmulo do modelo em
questão, as técnicas de projeto típico de gestão oferecidos pelo modelo, as áreas de
aplicação primária, e o mecanismo para a popularização do modelo. modelos de gestão de
projeto são classificados em sete modelos ao longo dos quatro gerações. Uma hipótese é
que um modelo de "versátil" (quarta geração) é próximo no futuro em que a gerência geral
tradicional terá sido substituída ou se fundir em gerenciamento de projetos. Em (Jugdev &
Müller, 2005), a compreensão evolutiva do sucesso do projeto durante um período de 40
anos é avaliada. Condições para o sucesso, fatores críticos de sucesso e os frameworks de
sucesso são discutidos. Em (Winter et al, 2006), o artigo de abertura da edição especial do
IJPM sobre Repensando a Gestão de Projetos, os resultados de uma rede britânica de
investigação denominado "Repensando Gerenciamento de Projetos: Desenvolvimento de
uma Nova Agenda de Investigação" são apresentados. A Rede RPM4, entre 2004 e 2006,
definiu cinco novos rumos para futuras pesquisas que indica, na sua essência, a
necessidade de um novo pensamento nas áreas da complexidade do projeto, o processo
social, a criação de valor, a conceituação de projeto e desenvolvimento profissional. Em
4 RPM – Rethinking Project Management.
16
essência, a Rede tem encontrado é necessário que haja um foco muito maior em pesquisas
futuras sobre os conceitos e teorias de perto em ressonância com estas realidades,
podendo fornecer aos seus conceitos e abordagens práticas mais em alinhamento com o
pensamento contemporâneo. A última teoria posição, na prática, é essencialmente uma
referência ao modo como os praticantes aprendem seu ofício e como eles realmente
exercer seu ofício por meio da teoria relevante da literatura sobre gerenciamento de
projetos. Em (Cicmil et al, 2006) uma posição controversa sobre a investigação de PM é
apresentada. De acordo com os autores, sabemos muito pouco sobre a realidade do
trabalho baseado em projeto e sua gestão. O objetivo do trabalho é formular e mapa de
uma vertente de investigação no campo da gestão de projeto que trata de forma adequada
a "atualidade" do projeto de base de trabalho e de gestão. Um framework para
conceituação da "realidade do projeto" é proposto. A prática de gestão de projetos é vista
como um condutor social, definido pela história, contexto, valores individuais e
frameworks estruturais mais abrangentes. Pesquisando a realidade dos projetos significa
focar no processo social e como pensam os profissionais em ação, a situação local de um
presente vivo. Este trabalho representa uma mudança em direção a uma teoria da práxis
baseada e investigação, que incide sobre a realidade empírica dos projetos, tendo em
conta diferentes contextos em que gerenciamento de projetos é promulgada, eliminando
assim a complexidade, não-linearidade, valores, perspectivas múltiplas e processos sociais
em ambientes de projeto. Pesquisando a realidade dos projetos, portanto, consiste em
"reunir, analisar e disseminar conhecimento sobre as pessoas que trabalham em conjunto
com as coisas, tecnologias, e uns aos outros e os meios através dos quais essas relações são
coordenadas e controladas, para que fins" (Clegg & Ross-Smith, 2003). O artigo, referindo-
se a um conjunto de estudos na literatura, demonstra que os profissionais competentes
têm uma compreensão muito mais ampla e intelectualmente complexos de gerenciamento
de projetos do que o discurso embutido no Guia PMBOK - mas que eles sentem que devem
pedir desculpas por usar algumas das habilidades “virtuosas” que não são reconhecidas no
discurso tradicional. Isto implica uma visão alternativa sobre o conhecimento e
competências gerenciais, desafiando a imagem tradicional do gerente do projeto
'profissional' como pensador, propositivo, decisivo e racional. Cicmil e Hodgson (2006)
abordam a necessidade de identificação fora do espaço da paisagem bem definidos e
densamente povoadas conceitual de gestão de projetos comuns onde a outras
perspectivas, outras preocupações, e outra agenda podem ser articulados e explorados. As
questões fundamentais se colocam como um guia para a reflexão sobre como os projetos
são concebidos e como eles poderiam ser concebidos: existe uma explicação universal de
que os projetos são projetos e como evoluir? Qual é o significado por trás dos conceitos em
uso, ou seja, os termos "projeto" como "gerenciamento de projetos" e "o sucesso do
projeto"? Quais são as implicações do atuais definições de "projeto" e "gerenciamento de
projetos" para a natureza do conhecimento e os fundamentos intelectuais de estudos de
organização de projeto, trabalho e gestão? Quais são as consequências do projeto de
organização, tal como atualmente previsto, tanto para os gerentes de projeto e de
trabalhadores do projeto? Que perspectivas alternativas sobre os projetos existem para
além do mainstream? Quais interesses estão sendo atendidos pela reprodução do status
quo no campo? Não são apenas projetos considerados formas adequadas para controlar os
esforços em um ambiente turbulento, mas também mais importante, eles são
considerados como a forma adequada de estimular um ambiente de aprendizagem e
estimular a criatividade de forma a oferecer produtos complexos (Hobday, 2000). Apesar
17
da contradição intrínseca entre esses dois argumentos para a organização de projetos
(Tjaeder & Thomas, 2000), é precisamente sobre essa promessa ambiciosa para entregar
os dois “controlabilidade e aventura” (Sahlin-Andersson & Soderholm, 2002) que a atração
da organização "projectification" é encontrado. O direcionamento resultante para a
profissionalização da disciplina de gerenciamento de projetos tem sido acompanhado pela
luta e as tensões envolvendo conceituar, promover e concordar com o documento
universalmente aceitável que deve delinear o corpo de conhecimento formal de
gerenciamento de projetos. Procurando diagnósticos e prescrições para as questões
fundamentais de gestão de projetos, Cicmil e Hodgson salientam que foi principalmente na
década de 1990 que a análise crítica do poder social e político associados a projetos como
os aspectos organizacionais e sociais, e gestão de projetos como prática e como um
agrupamento social emergiu. Os argumentos se voltam para estudos críticos em
administração, destacando as implicações dessa tradição intelectual para estudos de
projetos, gerenciamento de projetos, o desempenho do projeto, e as habilidades e
competências individuais para lidar com arranjos sociais rotulados como "projetos". Fazer
projetos críticos é a trajetória nova proposta. Cicmil et al. (2009), depois de uma
caracterização do contexto e das ambições da pesquisa crítica em projetos, apresentam
seis artigos incluídos numa edição especial da revista ephemera intitulada Project
management behind the façade. Como janelas na fachada do gerenciamento de projetos
"que contribuem novos insights sobre as realidades da prática no trabalho do projeto e
novas perspectivas teóricas que podem inspirar a pesquisa crítica sobre estas práticas. Em
relação ao pensamento e a pesquisa em PM a década de 2000 foi a mais produtiva e
diversificada até agora. Vários grandes projetos ocorrem nesta década como o Airbus 380,
Boeing 787 Dreamliner.
2010 Em (Sage et al., 2010) os autores a apresentar um pequeno resumo dos "projetos críticos
de Movimento (CPM). Em seguida, examina a abordagem reflexiva de destaque nesse
movimento crítico. Em segundo lugar, posições essas abordagens dentro da tradição
dialética da criação do conhecimento. Em terceiro lugar, se baseia em críticas dialética
dentro da gestão organizacional crítica e os estudos que sugerem alguns pressupostos
importantes irrefletida que têm consequências para a gestão de forma reflexiva tem sido
conceituada como central para a produção de conhecimentos novos projetos. um grupo de
autores diferentes, mas que passa a ser articulada com mais evidência por autores de auto
identificados como 'crítica' na orientação. A intenção deste trabalho é proporcionar uma
intervenção teórica crítica, em outras palavras, para abordar o pensamento existente
sobre a prática, em vez de dar um contributo imediato a prática de gestão do projeto. Em
(Blomquist et al., 2010) os autores afirmam que há uma necessidade de ir além dos
modelos de gestão de projetos, avaliação do programa A Project Management Body of
Knowledge (PMBOK® Guide), planos de projeto, a estrutura de divisão de trabalho (WBS),
e técnica de revisão (PERT), e os horários de Gantt (Maylor, 2001) quando se tenta
entender projetos. Projetos estão no nível mais básico de uma organização de sistema
aberto com muitas dependências contextuais, bem como a variação individual. Esta ainda
é a investigação sobre os projetos. Mas esta é a investigação sobre o que as pessoas fazem
em projetos (prática) e não sobre a confirmação de modelos de melhores práticas para
gerenciamento de projetos. Os autores defendem uma perspectiva prática, que começa
com ações individuais e pergunta quais são os modelos e conceitos básicos resultantes
18
dessas ações. O objetivo é delinear elementos para projeto de pesquisa como prática e
discutir as principais questões que precisam ser abordados na presente abordagem. Os
autores não estão descartando o conhecimento atual sobre os projetos. Em vez disso, eles
estão sugerindo uma abordagem complementar. Em (Eskerod, 2010) o pensamento
reflexivo, ou seja, pessoas envolvidas em uma determinada atividade refletindo sobre o
que eles fizeram, é reconhecido como uma forma eficiente de facilitar o desenvolvimento
de liderança (Parkes, 1998). No entanto, a investigação tem demonstrado que “a reflexão
não é natural nem fácil para a maioria dos gerentes” e “tentativas explícitas para
incentivar a adopção de aprendizagem e de práticas reflexivas, quer através de explicações
lógicas ou sessões de desenvolvimento têm falhado” (Smith, 2001). A aprendizagem pela
ação (action learning)pode ser uma maneira promissora de facilitar o desenvolvimento de
liderança, uma vez que envolve o pensamento reflexivo (Smith, 2001). Com base no estudo
de caso, o artigo discute as condições necessárias para melhorar o desenvolvimento das
competências entre os gerentes de projeto através de uma ação de aprendizagem. De
acordo com Lehmann (2010), associar gerenciamento da mudança (CM – Change
Management) com gerenciamento de projetos (PM) tornou-se, recentemente, um novo
desafio para as organizações: elas querem que mudanças sejam mais bem sucedidas e
veem em gerenciamento de projetos uma forma de ganho de desempenho. Usando
“mudanças como projetos", ele traz à tona a ideia de que (todas) mudanças dependendo
de seus objetos podem ser tratadas como projetos. Em seu estudo Lehmann resume as
duas abordagens – as escolas tradicionais e renovação – na gestão de projetos. Tal como
no gerenciamento de mudanças, essas duas abordagens representam dois polos de um
continuum e não são abordagens opostas. Uma nova abordagem para o estudo das
mudanças de gestão de projetos baseada em três elementos: a abordagem mineral,
orgânica e a abordagem mista é apresentada. Leybourne (2010) observa um sector onde
as técnicas de projeto são usados extensivamente: a construção de alto valor
"superyachts". A questão das mudanças é uma dificuldade específica, os contratos maiores
podem levar de 6 a 7 anos desde a concepção até o lançamento, em uma indústria em
algumas áreas da tecnologia está mudando rapidamente. Este artigo propõe a utilização de
uma variedade de dados, incluindo entrevistas individuais com os gerentes de projeto e
executivos da indústria de superyachts do Reino Unido, juntamente com os dados do
projeto e dos dados secundários a partir de dentro e fora do setor, a considerar alguns dos
desafios inerentes à gestão de projetos destes projetos complexos. Dentro desta pesquisa,
no entanto, o foco está no desvio daquilo que é inicialmente acordado, mas muitas vezes a
natureza improvisada de qualquer solução é devido à necessidade de cumprir as metas de
entrega que são de algum tempo longe, indicando que a bricolagem não é sempre a
exigência predominante. Isso gera pressão temporal dentro do projeto. Essa atividade
ocorre geralmente no final da construção, resultando em compressão dos prazos e
complexidade, que tem de ser resolvido. Isso nos leva à consideração do tempo nas
organizações. Há provas de uma confiança na experiência e capacidade para desenhar em
uma biblioteca pré-experimental de intervenções bem sucedidas anteriormente
improvisação, que podem ser adaptadas e ajustadas para atender a um requisito específico
para resolver um problema baseado em projeto. Indiscutivelmente, esta é uma mudança
do paradigma tradicional baseado em projeto de "planejar, depois executar", mas no
domínio cada vez mais complexo, estudado aqui, onde a aceitação do modelo de sistema
complexo adaptativo. Saynisch (2010) argumenta que mudanças fundamentais nas
ciências oferecem novas perspectivas para a gestão da complexidade. Maior complexidade
19
na sociedade, economia e tecnologia exige uma nova organização e adequados e de gestão.
Um fenômeno é a variação de crescimento rápido da complexidade, as novas tecnologias
(inovação) em produtos industriais e sociais (os resultados dos projetos) - por exemplo, os
microssistemas, os sistemas de bioenergia, nanotecnologia e suas conexões com
dimensões da escala “humana” (Kroy, 2004) bem como a biológica ou sistemas vivos com
mega características complexas, especialmente os sistemas sociais humanos, e espaços
virtuais. Outro fenômeno mencionado por Saynisch é a "dinâmica de instabilidade", como
afirmado por Ervin Laszlo: o desenvolvimento do nosso mundo e da sociedade com os
seus mercados, tecnologias, pessoas e organizações, não é previsível (ou seja, estável e
linear). Na vida real é instável e não-linear. Os fenómenos exigem uma nova abordagem de
gestão. Os métodos tradicionais e do pensamento mecanicista perdem sua eficiência. Os
resultados do programa de longo alcance de pesquisa (iniciada em 1990) para além das
fronteiras tradicionais da Gestão de Projetos são apresentados. O conceito de "projeto de
gestão de segunda ordem", como principal resultado do programa de investigação, é
discutido. Em (Skulmoski & Hartman, 2010) as competências soft por fase de projeto que
são requeridas pelos gerentes de projetos de sistemas de informação (SI) para o sucesso
do projeto são investigadas. Os autores realizaram 33 entrevistas qualitativas para coletar
dados de uma amostra de 22 é gerentes de projeto e líderes de negócios localizado em
Calgary, Alberta, Canadá. Os autores identificaram as principais habilidades para cada uma
das fases do projeto de SI (iniciação, planejamento, implementação e close-out). As
competências foram classificadas em categorias de competências: os atributos pessoais
(por exemplo, olho para detalhes), comunicação (por exemplo, eficaz interrogatório), a
liderança (por exemplo, criar um ambiente de projeto efetivo), as negociações (por
exemplo, a construção de consenso), o profissionalismo (por exemplo, ao longo da vida
aprendizado), habilidades sociais (por exemplo, o carisma), e competências de gestão de
projetos (por exemplo, gerenciar as expectativas). Cada uma das competências mais
importante é discutida e as interconexões entre as competências identificadas.
Com base nos resultados obtidos a partir do estudo sobre evolução do pensamento em
gerenciamento de projetos, uma linha do tempo com os principais marcos identificados é
apresentada na Figura 1.
Figura 1. Timeline do pensamento em gerenciamento de projetos.
1898 Adamiecki´s harmonograms
1911 Principles of Scientific Management (Taylor)
1919 Gantt´s charts
1954 Drucker´s management by objectives
1957 CPM
1957 PERT
1950 Systems thinking
1959 PDM initiated
1960s EVM
1965 IPMA (INTERNET) created
1969 PMI created
1979 Kerzner´s book first edition
1983 First issue of International Journal of Project Management
1984 First PMP certifications were awarded
20
1987 PMI “The Project Management Body of Knowledge” published
1993 IRNOP created
1994 IRNOP Conference on PM and Temporary Organization
1995 New directions for project management research (Scandinavian Journal of
Management)
1996 PMBOK (first edition) published
2002 Frontiers of Project Management Research (PMI)
2003 Making Projects Critical Workshops (Critical Projects Movement)
2006 RPM Network Final Report (UK EPSRC)
2009 Project Management Behind the Façade (ephemera special issue)
A Tabela 1 resume as principais características de cada período estudado.
Tabela 1. Características de cada período estudado.
Período Principais Características Antes de 1960 CPM, PERT, projects as networked sets of tasks. 1960-1969 Systems analysis, systems engineering, systems
approach to project management, professional associations.
1970-1979 Project management as a process, techniques, tools, organizational structures.
1980-1989 Strategic PM, standards, wider PM context, human relations becomes a strong issue, PM tools implemented for the PC.
1990-1999 Hard and soft PM, systemic approach, systems thinking, temporary organization, “brackets”, formalization of PM, projects are different, different theories for different projects, project equivocality, multiproject contexts, foundations for the critical movement.
2000-2009 Critical management perspective, management of projects, reflective approach.
2010 Beyond PM models, project-as-practice research, reflective thinking, action learning, changes as projects, management of complexity.
O estudo da evolução do pensamento PM foi um esforço intelectual e reflexivo, que deu
origem a muitas perguntas. Quais são as atuais correntes ou escolas de gestão de projetos?
O que está à frente em termos de investigação e questões práticas? Qual o papel da
tecnologia no processo de projeto? O que faz uma disciplina de projeto? Como projeto de
educação e formação deve proceder? Caso projeto metodologias de pesquisa de gestão
sejam distintas metodologias de pesquisa de gestão? Cada uma dessas questões - talvez já
abordadas por alguns pesquisadores – merecem um estudo completo per si. Na sequência,
algumas considerações preliminares sobre elas são feitas.
Muitos pesquisadores seguem a ideia básica de que as duas abordagens (soft e hard) para
gerenciamento de projetos são complementares. Para Lehmann (2010) "essas duas
abordagens representam dois polos de um continuum e não são abordagens opostas".
21
É precisamente sobre a promessa ambiciosa de entregar ambos "controlabilidade e
aventura" (Sahlin-Andersson & Soderholm, 2002) que a atração de "projectification"
organizacional é encontrada. A abordagem quântica à gestão de projetos vai nessa direção:
você pode ter previsibilidade de cronograma ou riscos controlados, mas não ambos, em,
por exemplo, projetos inovadores.
Os processos de produção foram fortemente influenciados por mudanças tecnológicas. O
processo do projeto deve ser transformado pela mudança de tecnologia nas próximas
décadas. Novas tecnologias da informação, as tecnologias nano, experiências sociais, redes
de sensores, a ciência neural, novos processos de aprendizagem, entre outros podem
influenciar fortemente o processo de projeto. Nos sistemas de informação em particular,
visto como o principal integrador e sintetizador dessas tecnologias podem desempenhar
um papel importante. Estudos sobre o impacto da mudança tecnológica sobre o processo
de projeto (bem como sobre a organização) são, então, necessário, pois ele pode
remodelar completamente o ambiente de projeto (Löwstedt, 1985).
Embora artigos foram a fonte básica de informação neste estudo, vários livros apontam
para novas direções para a compreensão dos projetos e sua gestão. Vale a pena citar
alguns deles aqui:
The social psychology of organizing, by Karl Weick (1979).
The reflective practitioner: how professionals think in action, by Donald Schön
(1983).
Sensemaking in organizations, by Karl Weick, (1995).
Of grammatology, by Jacques Derrida (1998).
Projects as arenas for renewal and learning processes, by Rolf A. Lundin and Midler,
editors (1998).
Making sense of the organization, by Karl Weick (2000).
Projects as business constituents and guiding motives, by Rolf A. Lundin and Francis
Hartman, editors (2000).
Making social science matter: why social inquiry fails and how it can succeed again,
by Bent Flyvbjerg (2001).
Making projects critical, by Damian Hodgson and Svetlana Cicmil (2006).
A grammar of organizing, by Maria Bengtsson (2007).
Making sense of project realities: theory, practice and the pursuit of performance, by
Charles Smith (2007).
Images of projects, by Mark Winter and Tony Szczepanek (2009).
Existe uma "nova vertente na forma de pensar" sobre projetos ou gerenciamento de
projetos? Embora esta seja uma questão de desafio, pode-se ver a partir deste estudo que
há uma série de investigações na direção da abordagem suave. Em particular, após a Rede
RPM (Winter et al., 2006) e o número especial da revista ephemera sobre PM (Cicmil et al.,
22
2009) novas ideias e direções começaram a ser discutidas. As publicações em 2010, em
ambas as publicações sobre gerenciamento de projetos, sinalizam uma tendência na
direção de novas formas de pensar sobre os projetos e sua gestão. Este novo pensamento
considera a abordagem hard combinada com novas dimensões, como as interações sociais,
a análise da realidade do projeto, sensemaking, etc
Projeto é o elemento central de estudo e investigação. Gestão é um aspecto de um projeto.
Projeto como uma organização é um conceito prático, pois ele pode nos permite usar todas
as linhas de pesquisa em administração no estudo de projetos. A seguir, são áreas de
investigação possível (ou disciplinas) para estudos de projeto: a teoria do projeto, a
estrutura do projeto e design, análise de projetos, análise de macro do projeto, análise de
projetos de micro, gerenciamento de projetos, etc. Gerenciamento de projetos é, então,
uma disciplina em particular (ou fase), no estudo e na prática de projetos. Projeto de
educação deve seguir uma estrutura semelhante de disciplinas.
Em relação à generalidade dos métodos e técnicas de projeto, sugere-se a introdução dos
quantificadores universal e existencial. Estes quantificadores (lógico "para todos" e
"existe") deve ser usado para tornar claro como a teoria geral ou um determinado projeto
ou modelo. Juntamente com as imagens dos projetos (Winter & Szczepanek, 2009) e uma
abordagem quântica projetos uma nova forma de pensar em projetos emerge.
A investigação sobre tempo (não cronograma ou timing) e reflexividade em estudos
organizacionais pode contribuir para fomentar a nossa compreensão sobre projetos e sua
gestão.
Pesquisando a realidade dos projetos (Dawson, 1997; Cicmil et al, 2006) apontam para
uma disciplina mais geral do análise de projeto do que o método baseado em análise de
sistemas. O controle concertivo por equipes de auto-gestão (Barker, 1993) representa um
tema com potencial para futuras pesquisas.
Fatores de sucesso do projeto tem sido um tema de estudo frequentemente encontrado
nas duas principais revistas de gestão de projetos. A disciplina sugerida de análise de
projetos pode ser uma forma de estruturar o estudo do sucesso do projeto. Isso também
pode ser combinado com a abordagem de pesquisa de realidade de projetos (project
actuality).
O conceito de ciclo de vida do projeto deverá ser ampliado, integrando-se com o
desenvolvimento do produto e o ciclo de vida da organização. Isso certamente ajudará a
compreender melhor os ambientes do projeto e as novas abordagens. Em particular, o pré-
desenvolvimento (front-end) e o desenvolvimento de novos produtos merecem
tratamento especial neste ciclo de vida ampliado.
Software e Projetos de Software Esta seção explora a definição de projeto de software e gestão de projetos de software
(SPM). O principal objetivo é a compreensão profunda da natureza de um projeto de
software. Ao fazer isso, espera-se uma melhor compreensão da gestão de tais projetos.
23
Apresenta-se aqui os dados coletados a partir da revisão de literatura realizada sobre
gerenciamento de projetos de software. Cada parágrafo desta seção é uma extração da
fonte real. Algumas mudanças foram feitas pelo autor para melhorar a legibilidade. Por
questões de espaço, somente um subconjunto dos trabalhos pesquisados é mostrado.
Simpson (1987) usa a "gestão do programa" para se referir à gestão de programas de
software ou computador. De acordo com Simpson "a gama de postos de trabalho
abrangidos pelo projeto de software expressão parece, à primeira vista, ser tão diverso
que não há procedimentos simples podem ser formuladas para cobrir todo o campo. Até
certo ponto isso é verdade. Existem, certamente, os projetos de software chamado de
código que envolvem tão pouco e tão pouca interação com o mundo exterior, que a gestão
formal é necessária ". Um projeto de software é composto por um conjunto de tarefas que
estão relacionados uns aos outros e todos devem ser preenchidos para o total do projeto
para ser concluída conforme o planejado. Simpson apresenta um diagrama de primeira
passagem simples para um plano de projeto composto por tarefas como a definição,
concepção, desenvolvimento, etc codificação, teste, quando falamos de projetos de
software em geral, não é tão óbvio como uma grande tarefa, estamos nos referindo ou que
metodologias devem ser empregadas para completar a tarefa. Neste contexto, a
classificação do tamanho do projeto de software e metodologias é desejável. Simpson
oferece oito níveis de classificação de tamanho com base no número de linhas de código
(LOC).
Whitten (1995) apresenta “disciplina” como "a cola que mantém tudo junto". A disciplina é
uma dimensão particular do desenvolvimento de software. Whitten apresenta uma
maneira para implementação da disciplina em um projeto: (1) definir metas realistas; (2)
obter compromissos; (3) acompanhar o progresso em relação ao planejado (4); cobrar o
compromisso.
Turner (2004) chama a atenção para projetos web. Muitas definições de e-projetos são
apresentados: "um e-projeto é um projeto que envolve a criação ou alteração de código
fonte que está implantado na Internet", "a transformação dos processos de negócios
através da utilização de tecnologias da Internet". As principais características dos projetos
web são apresentadas. características inerentes: prazos mais curtos, o alcance global com
as exigências de diversos usuários, gerenciados fora da organização de TI, equipes
multidisciplinares com alto foco em criatividade e usabilidade, ampla gama de
necessidades dos usuários (requisitos). Características temporais: diversas tecnologias,
aplicações menos provadas, de evolução rápida, indústria imatura, com a escassez de
competências; metodologias indefinidas integrando todos os elementos de projetos web;
rápida mudança na indústria, maior risco percebido. Turner também apresenta as
diferenças entre projetos Web e é projetos de SI. Projetos Web são mais do que apenas
projetos de SI/TI. Esta é a sua principal característica, mas como a maioria dos projetos SI,
os projetos de entrega da web não são só sobre tecnologia da informação, são projetos de
mudança; projetos de inovação; projetos de reengenharia do processo empresarial,
projetos editoriais, projetos de marketing.
Segundo McConnell software não é soft. A noção de que o software é fácil de mudar se
tornou uma das ideias mais perniciosas no desenvolvimento de software (McConnell,
2004).
24
Stepanek (2005) questiona a peculiaridade do software: o software é complexo, software é
abstrato, a tecnologia muda rapidamente, a tecnologia é um vasto domínio, os requisitos
são incompletos; melhores práticas não estão maduras; experiência em tecnologia é
incompleta; trabalho repetitivo é automatizado; desenvolvimento de software é pesquisa;
construção é realmente design, a mudança é considerada fácil, a mudança é inevitável.
Armour (2001) apresenta uma metáfora interessante, onde o cenário Zeppelin representa
projetos do passado, 20 ou mais anos atrás, e o cenário avião a jato representa os projetos
de hoje. Ao olhar para as características de cada um, algumas semelhanças são
apresentadas. Zeppelin: alvo em movimento lento, grandes e bem definidos (em
comparação com a velocidade do projétil), a abordagem determinística e previsível, a
resposta previsível do alvo dentro do alcance da operação de regime de metas, o sucesso
definido pelo conhecimento prévio e precisão. Avião a jato: alvo móvel rápido, pequeno,
pode estar utilizando medidas de segurança, resposta imprevisível, velocidade do alvo
próxima da velocidade do projétil, o sucesso determinado pela flexibilidade da resposta.
Os atuais projetos avião-a-jato são muito diferentes. O alvo aparece e desaparece através
de uma janela de oportunidade cada vez mais estreita. Temos de lançar o projeto, às vezes
sem a certeza de um sucesso. Lançamos, não com uma estimativa exata, mas com a melhor
probabilidade de atingir o alvo, e temos que aceitar probabilidades de menos de 100%. O
projeto pode fugir de nós tão rapidamente quanto podemos rastreá-lo. Ele certamente vai
mudar de direção e os progressos podem ser cíclicos. O próprio ato atirar (tentativa de
construir o sistema) fará com que o alvo escape (requisitos para a mudança). Esta é uma
situação intrinsecamente não-determinística, que não pode ser efetivamente controlada
inteiramente do “chão”. Os projetos devem ser não somente muito mais rápidos do que
costumavam ser, elas também devem ser muito mais flexíveis (Armour, 2001).
Um relatório de um grupo de trabalho da Royal Academy of Engineering e da British
Computer Society (BCS) traz aspectos importantes dos projetos de TI (BCS, 2004). De
acordo com a conclusão do relatório "a importância do gerenciamento de projetos não é
bem compreendida e, geralmente, subestimada, e gerentes seniores são muitas vezes mal
qualificados para lidar com questões relativas a projetos complexos de TI. Este estudo
preocupa-se projetos de TI de grande escala com um componente de software significativo
e complexo. O termo "sistema IT" ou "projeto de TI ' é usada em todo o relatório para se
referir a estes sistemas complexos baseados em software e projetos. Características dos
projetos de TI no relatório: falta de restrições ("o software fornece alcance ilimitado "para
a funcionalidade, sem o inconveniente de restrições existentes nas leis da física, não há
nada que você não possa fazer com software”; visualização (“se eu fosse um diretor
formado em direito ou contabilidade eu não iria pedir a um engenheiro para construir um
lance de 1.000 metros de concreto suspenso por um lado, porque sei que não pode ser
feito, eu tenho uma perspectiva física sobre ele. Com o software, nunca é assim, não temos
qualquer base para sentir se algo é mesmo viável”); flexibilidade (“as pessoas acreditam
que software é flexível e, portanto, que eles podem flexibilizá-lo além dos limites
razoáveis”); complexidade (“em um grande projeto de software é uma sorte se uma pessoa
em 50 tem qualquer coisa parecida com uma compreensão global da estrutura conceitual
do projeto, e divinamente abençoado, se essa pessoa tem a capacidade explicá-la em
termos leigos”); incerteza (“o resultado de qualquer projeto de software é
necessariamente incerto... Não existe problema em ´produzir´ um software – o problema é
25
saber o que produzir”); software e falha (“em cada pedaço de software do mundo real, há
embutido um número ilimitado de suposições. A maioria das premissas não são decisões
que você tomou, mas coisas sobre as quais você não tinha pensado.”); apoio à mudança
(“projetos de software são raramente, ou nunca, unicamente para a entrega do software
em si”). Quanto à gestão de projetos de engenharia de software o relatório afirma que "os
processos de gestão que tradicionalmente são aplicadas a projetos de software foram
derivadas, em grande parte dos processos que eram vistos como ser bem sucedido em
outras áreas da engenharia. Não é óbvio que esta abordagem histórica para o
desenvolvimento do software foi totalmente bem sucedida, apesar das muitas tentativas
por pessoas talentosas para acomodar as suas deficiências”.
Vários outros estudos abordam aspectos da natureza do projeto de software: Tulip (1986),
(Keil, 1995) , (Mahaney et al., 2003), (de Amescua et al., 2004), (McManus, 2004), (Verner
& Cerpa, 2005), (Fichman, 2005), (Shenhar et al., 2005), (Agarwal, 2006), (Summer et al.,
2006), (Procaccino et al., 2006), (Nelson, 2007), (He et al., 2007), (Petter, 2008), (McBride,
2008), (Al-Ahmad et al., 2009), (Tynjälä, 2009), (Rivard, 2009), e (Sauer & Reich, 2009).
A Natureza dos Projetos de Software A partir dos dados coletados na revisão da literatura, as seguintes características resumem
a caracterização de um projeto de software.
• Prazos mais curtos, alcance global com requisitos de usuários diversificados,
equipes multidisciplinares, com foco na criatividade e usabilidade, ampla gama de
requisitos dos usuários; diversas tecnologias, aplicações pouco provadas, de
evolução rápida, indústria imatura e com escassez de competências; rápida
mudança na indústria; risco maiores percebidos. Projetos Web não são somente
sobre tecnologia da informação, eles são: projetos de mudança, projetos de
inovação; projetos de reengenharia de processos empresariais; projetos editoriais,
projetos de marketing.
• Software é complexo, software é abstrato, a tecnologia muda rapidamente, a
tecnologia é um domínio vasto; os requisitos são incompletos; melhores práticas
não estão maduras; experiência com tecnologia é incompleta; trabalho repetitivo é
automatizado, desenvolvimento de software é pesquisa; construção é realmente
design; a mudança é considerada fácil; a mudança é inevitável.
• Os projetos de software são rápidos, com alvo pequeno, pode estar utilizando
medidas de segurança, resposta imprevisível, alvo com velocidade próxima a
velocidade do projétil, o sucesso determinado pela flexibilidade da resposta.
Gestão dos stakeholders, engenharia, qualidade e gestão são aspectos importantes.
• Características dos projetos de TI: falta de restrições; visualização; flexibilidade,
complexidade; incerteza, software e fracasso; apoio à mudança.
• A incerteza é um fato da vida para a maioria dos grandes investimentos de capital
em TI.
• A orientação psicológica dos profissionais de TI influencia seus estilos de liderança
do projeto, porque a liderança eficaz inclui “soft skills”, como a capacidade de
gerenciar pessoas e comunicação eficaz.
• Como projetos de desenvolvimento adaptam-se a mudanças circunstanciais, a
gestão desses projetos também deve se adaptar.
26
• Foco em valor; profunda identificação pessoal com as metas do projeto,
investimento em confiança; responsabilidade coletiva descentralizada; vontade de
se adaptar continuamente, desenvolvimento de pessoas, orientação a
aprendizagem, criatividade e inovação; visão proativa. Tensões principais: entre
controlar a mudança e abraçar a mudança, entre o controle de decisões e o
empowering da equipe; e entre conseguir resultados a curto prazo e construir uma
infraestrutura sólida para o futuro.
• “Valor” pode ser a promoção de estratégias de organização, melhoria no
desempenho dos principais processos, ou o aprimoramento do processo decisório.
Neste trabalho, como uma tentativa inicial de um novo framework para gestão de projetos
de software um conjunto de dimensões foi definido: Aprendizado, Complexidade,
Conhecimento, Incerteza, Inovação, Liderança, Marketing, Metodologias, Mudança,
Política, Simplicidade, Social, Stakeholder e Valor. Estas dimensões podem ser utilizadas
como áreas para uma melhor compreensão e gestão de projetos de software.
Um Framework para Projetos de Software Baseado no estudo da evolução do pensamento em gestão de projetos, na investigação da
natureza do projeto de software e sua gestão, em trabalhos anteriores e experiências
profissionais do autor, um framework para projetos de software é proposto. Tal
framework tem implicações para pesquisa e para a prática. A seguir passamos a descrever
os principais elementos do framework aqui denominado Software Project Framework –
SPF.
Fundamentos O elemento “fundamentos” define a base, através da definição de princípios e disciplinas,
sobre a qual o framework proposto está construído. Princípios constituem linhas gerais de
pensamento, paradigmas, valores que norteiam a aplicação do framework. Disciplinas são
corpos de conhecimento usados nos demais elementos do framework.
São os seguintes os princípios (iniciais) que norteiam o SPF:
Organizing.
Sensemaking.
Constructivism.
Reflective Learning.
Singularity. One size does not fit all.
Critical Thinking.
Integration.
Temporary.
As seguintes disciplinas, entre outras, são fontes de conhecimento para o SPMF:
Engenharia de Software
Administração (Management – Gestão)
Gestão de Projetos
Gestão da Inovação
27
Pensamento Sistêmico.
Dinâmica de Sistemas.
Análise de Sistemas.
Engenharia de Sistemas.
Desenvolvimento de Novos Produtos.
Marketing.
Sociologia.
Comportamento Organizacional.
Aprendizagem Organizacional.
Gestão do Conhecimento.
Os princípios e disciplinas acima foram oriundas do levantamento sobre evolução do
pensamento em gestão de projetos e o estudo da natureza dos projetos de software.
Dimensões O elemento “dimensões” reflete uma visão de variabilidade e complexidade do projeto de
software (images). Ele incorpora também o conceito de foco ou aspecto: entendimento do
projeto sob um determinado aspecto (ou dimensão). São as seguintes as dimensões do
SPMF:
Aprendizado (Learning)
Complexidade
Conhecimento (Knowledge)
Incerteza
Inovação
Liderança
Marketing
Metodologias
Mudança
Política
Simplicidade
Social
Stakeholder
Valor
Uma forma mais prática de ver as dimensões é focar no aspecto de gestão das mesmas. Por
exemplo, gestão do aprendizado do projeto, gestão da complexidade do projeto, e assim
por diante.
Na sequencia descrevemos, brevemente, as seguintes dimensões: Complexidade,
Incerteza, Inovação e Valor. As demais dimensões ainda são objetos de pesquisa e
detalhamento.
Complexidade
Em (Gonzalez 2005) complexidade do software é definida como uma medida dos recursos
que devem ser gastos no desenvolvimento, teste, depuração, manutenção, treinamento de
usuários, operação, e correção de produtos de software (Shooman, 1983). A complexidade
é uma propriedade do ciclo de vida do software, mas por medir as propriedades do
28
programa como um produto final do processo de desenvolvimento, pode-se aferir o nível
de complexidade em um sistema de software. Esta complexidade depende (1) a natureza
do problema em si, (2) o número de objetos criados na concepção da solução (módulos
funcionais e estruturas de dados), (3) as interfaces e relações entre os objetos (4), o
algorítmica e infraestrutura lógica dos programas (5), métodos e ferramentas utilizadas
no desenvolvimento de soluções, (6) linguagens de programação usadas para implementar
soluções (7), o nível de conhecimentos humanos envolvidos no processo de
desenvolvimento (8) o hardware do computador e ambiente de software (9), organização
do projeto, e (10) de gerenciamento de projetos. Quando pensamos sobre os problemas do
computador, vemos a solução de software não apenas em uma camada, mas em várias
camadas paralelas ou domínios. Esses domínios têm certa relação e interdependência,
porque os mesmos componentes do programa desempenham papéis distintos em
diferentes domínios. Esta ideia pode ser uma poderosa ferramenta em ligar o texto
estático de um programa com o processo dinâmico que invoca em execução (Mills, 1972).
Neste contexto, um programa pode ser concebido em três domínios fundamentais de
complexidade: sintático, funcional e computacional. Cada um tem três magnitudes:
comprimento, tempo e nível. Isso é semelhante a magnitudes padrões da física
fundamental como comprimento, tempo e massa. Assim, estamos diante de um problema
multidimensional de complexidade do software.
Williams (1999) discute o que constitui a complexidade do projeto. Ela pretende ser
inclusiva e não exclusiva. Destacadas estão complexidade estrutural, o número e
interdependência de elementos (na sequência de um artigo de Baccarini) e da incerteza
nos objetivos e meios (após um trabalho de Turner e Cochrane). O artigo considera se
estes aspectos podem ser operacionalizados. Ele dá algumas ideias sobre o porquê de a
complexidade do projeto estar aumentando, em particular a complexidade crescente dos
produtos que estão sendo desenvolvidos, e o movimento para prazos mais curtos.
Baccarini (1996) propõe uma definição de complexidade do projeto como “constituída por
muitas” peças variadas inter-relacionadas, que ele operacionaliza em termos de
diferenciação – o número de elementos variados e interdependência - o grau de inter-
relacionamento entre estes elementos (ou conectividade ). Essas medidas devem ser
aplicadas em relação a várias dimensões do projeto, e ele discute duas delas. (i) Em termos
de complexidade organizacional, 'diferenciação significaria o número de níveis
hierárquicos, o número de unidades formais organizacionais, divisão de tarefas, o número
de especializações, etc; "interdependência" seria o grau de interdependências
operacionais – dependências entre os elementos organizacionais. (ii) Em termos de
complexidade tecnológica, “diferenciação”' significaria o número e a diversidade de
entradas, saídas, funções ou especialidades; “interdependência” seriam as
interdependências entre as tarefas, equipes, tecnologias ou insumos.
Sensemaking é uma perspectiva bem estabelecido na gestão estratégica e estudos de
organização, mas até agora teve pouco impacto sobre a análise da teoria e da prática de
gerenciamento de projetos. Em (Alderman et al., 2005), os autores consideram os insights
da literature sobre sensemanking na análise de projetos de engenharia liderado por
serviços (complex long-term service-led engineering project), que combina o fornecimento
de bens de capital ou infraestrutura com uma prestação de serviço a longo prazo. Usando
um estudo de caso do trem de inclinação Pendolino, que ilustra como descontinuidades
29
significativas deram origem à necessidade de sentido de decisões pelos participantes do
projeto diferente e as partes interessadas e como as narrativas diversificadas expressas
por diferentes grupos sociais em forma de gestão e progresso do projeto. Sensemaking está
menos preocupado com a identificação de formas específicas de organização para atender
a circunstâncias particulares ou tarefas e muito mais com o processo de organizar-se, isto
é, os meios pelos quais a organização está continuamente decretada e cumprida. Neste
artigo, ilustram esse processo de sentido no contexto de um grande projeto complexo que
envolve a concepção, montagem, entrega e manutenção de trens de alta velocidade para a
ferrovia West Coast Main Line do Reino Unido (WCML). Este projeto representa um tipo
cada vez mais comum de projetos complexos, onde o projeto ciclo de vida é estendido para
a fase de exploração da atividade. Os autores denominam tais projetos de service-led
projects, uma vez que é conduzido por as exigências dos clientes do serviço se manifesta
durante esta fase de operações. Essa complexidade adicional cria uma exigência de sentido
de decisões pelos participantes do projeto e sugerimos que os insights da literatura de
fazer sentido fornecem uma maneira de compreender algumas das atividades e decisões
que foram observados durante o projeto e a maneira pela qual as diferentes perspectivas e
os diferentes intervenientes e interessados no projeto foram interpretados e reconciliada.
Projetos de software podem ser vistos como service-led projects. E talvez uma abordagem
baseada em sensemaking possa ajudar a entender melhor esses projetos.
Descontinuidades significativas nos projetos complexos necessidade de criar um sentido
de decisão por atores diferentes e mundos sociais (usuários, clientes, empreiteiros,
fornecedores, engenharia e outras disciplinas técnicas). Por exemplo, descontinuidades
pode ocorrer na tradução dos requisitos do cliente em especificações de projeto, de
especificação em detalhamentos de projeto, de projetos em artefatos de trabalho e
sistemas, e a tradução desses artefato na operação do serviço. Neste contexto, o
gerenciamento de projetos pode ser entendida como o processo pelo qual as narrativas de
fazer sentido, são postos em comunicação com o outro a evoluir a solução mais satisfatória
para todos os interessados. A perspectiva de sensemaking, portanto, se coloca em oposição
a visões convencionais da função de gestão do projeto e como ela deve ser realizada.
Projetos de software são ricos em descontinuidades (Alderman et al., 2005).
A complexidade do software (complexidade do produto) influencia a complexidade do
projeto, mas ela própria é tratada por vários métodos de engenharia de software (como os
métodos formais) e linguagens de programação. Mas também a existência (ou não) de
métodos bem definidos e comprovados fazem parte da percepção da complexidade do
projeto.
Vale ressaltar, que a dimensão Complexidade pode incluir também a medida da
complexidade do software (produto) com base em algum artefato utilizado durante o ciclo
de vida do desenvolvimento.
Finalmente, diagramas UML talvez possam ser vistos em termos de imagens distintas para
um mesmo projeto (visões). Portanto, precisamos estender UML para incorporar imagens
de projetos. Um relacionamento entre imagens e a complexidade de projetos de software
pode ser estabelecida.
30
Incerteza
Projetos de software podem ser caracterizados como projetos que envolvem alto nível de
incerteza. Como veremos adiante, tal nível de incerteza tem uma relação com o nível de
inovação desses projetos.
Souder e Moenaert (1992) afirmam que a inovação tecnológica na empresa pode ser
modelada como um processo de redução da incerteza. Necessidades do usuário, ambientes
tecnológicos, ambientes competitivos e recursos organizacionais são, segundo os autores,
as principais fontes de incertezas. Eles defendem a integração e colaboração entre as
funções de pesquisa e desenvolvimento (R&D) e marketing para redução das incertezas.
Neste contexto, um framework é apresentado que mostra o efeito determinante da
trasferência de informação interfuncional.
Nidumolu (1995) conduziu um estudo sobre os efeitos de mecanismos de coordenação e
riscos (como as incertezas de um projeto) no desempenho de projetos de
desenvolvimento de software. Um modelo de pesquisa foi desenvolvido usando a
perspectiva contingencial estrutural (da Teoria Organizacional) e a perspectiva baseada
em risco da Engenharia de Software. O modelo sugere que os riscos de desempenho
residuais, isto é, a dificuldade em estimar resultados relacionados com desempenho
durante os estágios finais de um projeto podem clarificar a relação entre incerteza,
mecanismos de coordenação e desempenho.
Tatikonda e Rosenthal (2000) usam o construto da incerteza da tarefa para estudar os
relacionamentos entre as características de projetos de desenvolvimento de produtos e os
seus resultados. Projetos de desenvolvimento de produtos são caracterizados em termos
das suas inovações tecnológicas e níveis de complexidade. Esta caracterização é baseada
na literatura sobre desenvolvimento de produtos e na teoria de processamento da
informação organizacional. Segundo os autores, as características de inovação tecnológica
e complexidade do projeto contribuem para a incerteza das tarefas do projeto que estão,
por sua vez, relacionadas com os resultados da execução do projeto.
Apesar de terem um relacionamento forte, riscos (Charette, 1990; Gusmão & Moura, 2004)
e incertezas oferecem perspectivas diferentes em termos de gerenciamento de projetos
(De Meyer et al., 2002; Ward & Chapman, 2003; Ramgopal, 2003). Ward e Chapman [39]
argumentam os atuais processos de gerenciamento de riscos induzem a um foco restrito
no gerenciamento das incertezas de um projeto. Isto tem causa no fato que o termo “risco”
encoraja uma perspectiva de ameaça e pelo fato de que este termo tem sido associado a
“eventos” não a fontes mais gerais de incertezas relevantes. Ward e Chapman discutem as
razões para esta visão e argumentam que o foco na “incerteza” no lugar do risco pode
melhorar o gerenciamento dos riscos e, principalmente, das oportunidades do projeto.
Uma visão geral de como modificar o processos de gerenciamento de riscos para facilitar a
perspectiva de gerenciamento de incertezas é apresentada.
Em (Bjørn et al., 2004), os autores argumentam que o lucro potencial de um projeto está
inversamente relacionado com o seu grau de incerteza. Uma caracterização do perfil de
projetos baseada em incertezas é feita. Uma análise de quatro grandes projetos mostra
que a escolha da estratégia de um projeto pode alterar fortemente o seu perfil de incerteza
e, consequentemente, seu potencial de lucro.
31
Galbraith (1974) afirma que "quanto maior a incerteza da tarefa, maior a quantidade de
informação que tem queser processado entre os tomadores de decisão durante a execução
da tarefa para obter um determinado nível de desempenho". A incerteza reduz a
capacidade de planejar uma atividade. Galbraith considera que as variações nas
organizações são as variações nas estratégias para aumentar a capacidade pré-
planejamento e para diminuir o nível de desempenho exigido para a continuidade da sua
viabilidade". Nesse contexto, um ponto relevante é como uma melhor compreensão da
estrutura/design organizacional pode vir a reduzir as incertezas de um projeto. Um estudo
sobre esse relacionamento pode clarificar esse ponto.
Em (Pich et al., 2002) duas contribuições são feitas. Primeiro, com base na teoria da
decisão sequencial, conceituamos um projeto como uma função payoff do projeto que
depende de estados do mundo e uma rede de ações escolhidas. Usando este modelo
conceitual, os autores mostram que a ambiguidade e complexidade são os fatores que
explicam a coexistência de diferentes abordagens para a gestão do projeto.
Em (Ward at al., 2003) os autores argumentam que todo o gerenciamento de risco atual
projeto de processos de induzir um foco restrito sobre a gestão da incerteza do projeto.
Em parte isso éporque 'risco ' do termo estimula uma perspectiva de ameaça. Em parte
isso ocorre porque "risco" o termo passou a ser associado com "eventos" em vez de fontes
mais geral de incerteza significativa. O artigo discute as razões para essa visão, e sustenta
que o foco em 'incerteza' de risco e não pode melhorar a gestão de riscos do projeto,
fornecendo uma importante diferença em perspectiva, incluindo mas não limitado a, o
reforço de gestão de oportunidades. O artigo descreve como os processos de gestão de
riscos, podem ser modificadas para facilitar uma perspectiva de gestão da incerteza. Risco
é definido no PMBOK Guide 2000 como um evento ou condição incerta que, se ocorrer,
tem um efeito positivo ou negativo em um objetivo do projeto. Essa visão mais ampla
corrobora a necessidade da dimensão Incerteza.
Ramgopal (2003) fala sobre gestão da incerteza e considera o que poderia ser feito para
desenvolver uma abordagem de gestão da incerteza, que engloba todas as formas de
incerteza relacionados ao projeto. Os processos de gestão de risco são um ponto de partida
óbvio, mas estes precisam de modificações e ampliação se forem usados para facilitar o
tratamento global de incerteza do projeto:
• Revisar Terminologia
• Endereçar a Incerteza sobre Relacionamentos Fundamentais, Design e Logística
• Endereçar a Incerteza sobre Objetivos e Prioridades
• Expor e Investigar a Variabilidade
• Clarificar a Incerteza sobre a Base de Estimativas
• Endereçar a Incerteza Associada com a Natureza Condicional das Estimativas
Os resultados acima podem ser usados na definição de processos, métodos, técnicas e
ferramentas para dimensão Incerteza do SPF.
Em (Na et al., 2004) encontra-se uma menção às incertezas relacionadas com requisitos.
Em particular, a instabilidade dos requisitos de software em um projeto de software é
fator preponderante no desenvolvimento do projeto. Os autores afirmam que é
amplamente aceito que a gestão eficaz de incerteza dos requisitos pode substancialmente
32
afetar o desempenho do projeto. Também foi demonstrado que o nível padronização das
saídas (ou seja, marcos) e comportamentais impactam o desempenho do projeto. Técnicas
para gerir a incerteza dos requisitos e a padronização tornaram-se procedimentos comuns
em engenharia de software (Ropponen, 1999).
Em (Atkinson et al., 2006), os autores afirmam que, ao considerar-se o escopo apropriado
para gestão de projetos e a correspondente gestão da incerteza, é útil caracterizar os
diversos tipos de projetos e contextos em termos do alcance da incerteza envolvida.
Abordagens convencionais de gerenciamento de projeto pode ser mais eficaz para alguns
tipos de projeto do que outros. Na prática, o conceito de ´projeto´ foi ampliado a partir de
um enfoque inicial na gestão de grandes projetos, unitários e isolados, com objetivos bem
definidos e acordados, e produtos finais, para um conceito que inclui múltiplos projetos e
programas que são multidisciplinares, e que não são “pré-definido”, mas '”permeável,
contestável e totalmente aberto a renegociação”. Estas duas extremidades de um espectro
são referidas muitas vezes como 'hard' e 'soft ', mas na realidade há uma série de
dimensões de dureza e suavidade dos projetos. Projetos e programas podem exibir,
simultaneamente, as duas características (hard e soft) sobre essas dimensões e essas
características podem mudar ao longo do ciclo de vida do projeto.
Crawford e Pollack (2004) identificam sete dimensões de “dureza” e “suavidade” de
projetos com base em: pesquisas anteriores, o uso dos termos “hard” e 'soft', na prática de
gerenciamento de projetos e na literatura, e nas diferenças de base filosófica da dicotomia
hard/soft. Estas sete dimensões de dureza e maciez são ilustrados na Figura 2 (Crawford &
Pollack, 2004).
Figura 2. Dimensões de “dureza” e “suavidade” de projetos. Fonte: (Crawford & Pollack,
2004).
33
O objetivo de (Perminova et al., 2008) é discutir o fenômeno da incerteza em projetos e
tentar integrá-lo como parte do gerenciamento de projetos. Apesar do fato de que o
projeto da disciplina de gestão de risco tem ganhado muita atenção nos últimos dez anos
da academia e profissionais, ainda há um considerável potencial de desenvolvimento neste
campo. As recentes tendências em gerenciamento de projetos evidenciam a necessidade
de retomar a questão da incerteza. Embora se possa encontrar a noção de incerteza no
risco do projeto e da literatura tradicional incerteza de gestão com bastante frequência,
não há entendimento comum entre os estudiosos, como o que este termo significa. Com
base na análise das pesquisas existentes, apresentamos nossa própria definição de
incerteza como um elemento crucial na gestão de projetos. Argumenta-se que os
elementos-chave na gestão de incerteza são reflexivos de aprendizagem e sensemaking
como catalisadores de flexibilidade e rapidez na tomada de decisão quanto à escolha de
alternativas de ação em resposta à situação. Esta abordagem é sugerida a fim de facilitar e
maximizar o resultado de práticas de gestão de riscos. A incerteza não é um termo
autoexplicativo, e consideramos que é importante para distingui-lo do termo "risco". De
acordo com a descrição dos riscos apresentados acima, pode-se fazer uma conclusão de
que o risco é a incerteza. No entanto, esses dois fenômenos não são sinônimos, pois eles
são mais bem descritos como causas e consequências. Fazendo uma distinção entre
incerteza e risco é necessário para ser capaz de explicar a influência destes sobre o
desempenho do projeto. Do ponto de vista gerencial, definindo a incerteza é um elemento
importante da gestão orientada para o desempenho do projeto de risco. Um importante
insight no entendimento da incerteza é fornecido por Karl Weick, cuja pesquisa mostrou
exemplos de organizações “proativas em relação a seus ambientes ao invés de reativas a
eles" Karl Weick (1977, apub Perminova et al., 2008). Além disso, ele argumenta que
compreensão (understanding) e a sensemaking afetam as decisões estratégicas e,
consequentemente, o desempenho da empresa.
A presença de incertezas em projeto de software não é um fato novo. Lehman (1990) já
mencionava a incerteza existente nas aplicações computacionais.
Finalmente, falar de incertezas nos conduz aos princípios da Física Quântica e sua
aplicação à gestão de projetos. Brenner (2008) apresenta algumas idéias: na Física
Quântica alguns fenômenos são inerentemente desconhecidos. Por exemplo, o quanto
mais sabemos sobre a posição de um corpo em movimento, menos sabemos sobre sua
velocidade; e vice-versa. A Física Clássica não tem esta restrição. Pode-se fazer uma
analogia com gerenciamento: se queremos saber o custo e o prazo precisamente, devemos
reduzir a inovação, porque a inovação cria riscos. Se aceitarmos riscos, devemos esperar
uma menor previsibilidade de custo e prazo. O gerenciamento quântico reconhece que não
se pode ter precisão em um contexto de risco. Temos que escolher: inovação ou
previsibilidade; mas não ambos (Brenner, 2008).
Inovação
Em geral, o termo inovação significa uma nova maneira de fazer alguma coisa. Pode se
referir a mudanças incrementais, radicais ou revolucionárias na forma de pensar,
desenvolver produtos, definir e melhorar processos e estruturar organizações. Inovação é
um tema de estudo importante na economia, administração, tecnologia, sociologia e
engenharia. Desenvolvimento de produtos e projetos são áreas onde o tema é cada dia
mais relevante em termos de busca de uma maior competitividade de organizações e da
34
sociedade de forma mais geral. Schumpeter define inovação (econômica) como a
introdução de um novo método de produção ou na forma de manusear comercialmente
uma commodity (Schumpeter, 1934).
Van de Ven (1986) identifica os problemas principais no gerenciamento da inovação. Em
(Shenhar & Dvird, 1996) os autores argumentam que a distinção encontrada na literatura
sobre inovação entre inovação incremental e radical não é encontrada no gerenciamento
de projetos. Publicações na área de gerenciamento de projetos tendem a assumir que
projetos são fundamentalmente similares. Segundo os autores, no entanto, projetos
exibem variações consideráveis. Como um passo na direção do desenvolvimento de uma
teoria para gerenciamento de projetos, os autores apresentam uma tipologia
bidimensional para definir o espectro dos diversos projetos e seus diversos estilos de
gerenciamento.
Gann e Salter (2000) mostram a necessidade de um melhor entendimento conceitual e
novas práticas de gerenciamento para ligar processos de projeto e de negócio.
Keegan e Turner indagam se empresas baseadas em projetos proveem um contexto de
apoio à inovação ou se de fato tais empresas veem a inovação como útil. Baseados em uma
pesquisa envolvendo empresas de uma variedade de setores, incluindo sistemas de
informação, computadores, telecomunicação, financeiro, engenharia, aquisição e
construção, o artigo revela que os mesmos sistemas de controle de projetos em torno dos
quais as empresas operam servem para sufocar a inovação.
Em (Bresnen et al., 2003), os autores descobriram que processos de captura, transferência
e aprendizado do conhecimento em ambientes centrados em projetos baseiam-se muito
fortemente em padrões sociais, práticas e processos de maneira a enfatizar o valor e a
importância da adoção de uma abordagem baseada em comunidades (comunidades de
prática) para o gerenciamento do conhecimento. Thieme et al. (2003) desenvolveram um
modelo conceitual para desenvolvimento de novos produtos (NPD – New Product
Development), baseado em artigos seminais, para responder à seguinte questão: que
características do gerenciamento de projetos fomentam o desenvolvimento de novos
produtos que têm maior chance de sobreviver no mercado?
Argyris e Schon (1982) focam em modelos de aprendizagem de laço único (single loop) e
laço duplo (double loop) para o gerenciamento da atenção que pode melhorar o processo
de inovação.
Em (Glass et a., 1994) a natureza do trabalho de desenvolver um software é investigada. O
trabalho é predominantemente de software de escritório, intelectual ou criativo? Uma
série de opiniões sobre o assunto atualmente coexistir no campo, e eles não podem ser
válidos: O software é simples de construir, construção de software é automatizável,
construção de software é a atividade mais complexa já realizada pela humanidade, o
software não pode ser construída sem atos criativos. Este artigo relata a continuação de
um estudo prévio sobre a questão. Ele resume as conclusões do estudo anterior - que o
trabalho intelectual do software é de 80% e 20% de escrita - e explora a questão ainda do
grau em que o trabalho é criativo. Os resultados, embora interessantes, não são definitivos.
Eles sugerem, no entanto, que esta resposta é pelo menos possível: as tarefas de software
exige um certo grau de criatividade. A extensão do que a criatividade ainda não foi
35
determinado Isto ajuda a compreender a natureza inovadora e criativa de
desenvolvimento de software.
Em (Quinn et al., 1997), com o objetivo de tirar vantagem da inovação baseada em
software, os autores argumentam que as empresas devem ter a capacidade de, pelo
menos, gerenciar o desenvolvimento de software para suas necessidades específicas. Isso
inclui o projeto da sua infraestruturas, com foco na inovação e não apenas na redução de
custos, reconhecendo e gerenciando o fato de que software restringe os modos de
interação humana, utilizando software como ferramenta de aprendizagem para gerar
inovação, e instituindo uma abordagem sistemática para o desenvolvimento software
apropriado.
Koc (2007) investiga a relação entre fatores organizacionais e capacidade de inovação em
empresas de desenvolvimento de software. Por meio desta investigação o trabalho tem
como objetivo determinar os fatores organizacionais que tenham impacto significativo na
capacidade de inovação das empresas. Para este efeito, uma pesquisa empírica, incluindo
91 pequenas e médias empresas de desenvolvimento de software foi realizada. O estudo
revela que as empresas de software inovadoras levam em conta três indicadores básicos
muito importantes para a capacidade de inovação. Geração de ideias e recursos humanos
impactaram a capacidade de inovação positivamente. No entanto, o terceiro indicador, a
integração interfuncional, impactou negativamente a capacidade de inovação.
Finalmente, Highsmith (2004) associa o gerenciamento ágil de projetos à criação de
produtos inovadores e, em (Burgelman et al., 2008), os autores abordam o importante
tema da gestão estratégica da tecnologia e a inovação.
Valor
Kerzner e Saladis (2009) afirmam que “por mais de 40 anos, a visão tradicional de
gerenciar-mento do projeto foi baseadaem uma crença de que se completou o projeto,
respeitando o bem - conhecido triplarestrição de tempo, custo e desempenho, o projeto foi
considerado bem-sucedido .Talvez nos olhos do gerente de projeto e possivelmente o
patrocinador, o projeto surgiupara ser um sucesso. Mas aos olhos do cliente ou mesmo o
pai ou empresapatrocinadora da alta administração, o projeto pode ser considerado um
fracasso. A mudança do clima econômico eo ambiente cada vez mais competitivo global,
está impulsionando os gerentes de projeto para tornar-se mais orientadas para empresas.
Projetos estão agora a ser visto de uma perspectiva estratégica, como parte de umnegócio
ou empresa com a finalidade de proporcionar valor para ambos, cliente final eda empresa-
mãe. Os gerentes de projeto devem compreender as operações de negócios muito mais
hoje do que no passado”.
Nas diretrizes para pesquisa em gerenciamento de projetos apresentadas em (Winter et
al., 2006) (Diretriz 3) o estudo indica uma mudança do foco principal (no desenvolvimento
de teorias para apoiar as práticas): da criação de produto para a criação de valor. Para
muitas organizações, a principal preocupação atualmente não é mais o principal ativo,
sistema ou infraestrutura, etc, mas sim o desafio crescente de alinhar e ligar a estratégia
organizacional aos projetos, maximizando a geração de receita, e gerenciando a entrega de
benefícios em relação a diferentes grupos de interessados (stakeholders). No entanto,
atualmente, a principal preocupação da corrente principal do pensamento sobre
36
gerenciamento de projetos é essencialmente aquela da criação de produto: o
desenvolvimento ou o aperfeiçoamento de um produto físico, sistema ou infraestrutura,
etc, de acordo com a especificação, custo e prazo. Mesmo o conjunto de ideias conhecido
como “gerenciamento do valor” é historicamente e intelectualmente mais alinhado com a
perspectiva de criação de produto do que a perspectiva de criação de valor (Winter et al.,
2006).
Assim, uma das tendências para a pesquisa em gerenciamento de projetos para os
próximos anos é o estudo da ênfase na criação de valor pelos projetos (Skibniewski et al.,
2001; Skibniewski, 2004). Este tema envolve uma maior preocupação com o alinhamento
dos projetos aos objetivos estratégicos das organizações. No contexto dos projetos de
desenvolvimento de software, tal preocupação passa pela revisão das metodologias de
desenvolvimento de software que os suportam. A Engenharia de Software Baseada em
Valor (Value-Based Software Engineering, ou VBSE) (Biffl et al., 2006) é uma abordagem
que adiciona considerações de valor aos aspectos técnicos da engenharia de software,
estabelecendo um conjunto de elementos necessários à evolução das técnicas e práticas
atuais para que enfatizem a criação de valor. D´Anunciação (2009) faz uma análise do
Rational Unified Process, um framework de processos de software, quanto à ênfase em
criação de valor que ele possibilita, usando os elementos-chave da VBSE como diretriz
para a análise. A aderência do RUP aos elementos-chave é analisada, e uma extensão do
processo é proposta para suprir as lacunas encontradas.
Em (Thiry, 2001) esta perspectiva de sensemaking afirma que não há avaliação
"definitiva" de uma situação ou uma solução para um problema, mas sim um "válido"
(Thiry, 1997) ou "plausível" (Weick, 1995) de avaliação ou solução, que é aquele que "faz
sentido" para os agentes interessados, para quem "em risco".
Sensemaking tem sido descrita, tanto, como uma atividade individual ou como um
processo individual fundamentada na interação social , por causa da natureza social de VM
este trabalho concentrá-se na última perspectiva.
Devido à sua substância, sensemaking é muito influenciado por um conceito chamado de
ansiedade cartesiana (Bernstein, 1984). A expressão significa que, mantido por Descartes
e os seus discípulos, a maioria das pessoas acredita que tem que haver uma explicação
lógica para cada situação. Se isso não for possível porque eles estão em um contexto de
fluidos e mutáveis, constante negociação e subjetividade são a regra, se encontram em um
estado de ansiedade ou insegurança. “Tendo a escolha não é necessariamente um
sentimento agradável, que bem pode ser vivenciado como um fardo. "(Deetz, 1995, p. 71).
A ansiedade Cartesian desencadeia a necessidade de sensemaking e ancoragem aos
paradigmas existentes. Devido à sua substância, sensemaking é muito influenciado por um
conceito chamado de ansiedade cartesiana (Bernstein, 1984). A expressão significa que,
mantido por Descartes e os seus discípulos, a maioria das pessoas acredita que tem que
haver uma explicação lógica para cada situação. Se isso não for possível porque eles estão
em um contexto de fluidos e mutáveis, constante negociação e subjetividade são a regra, se
encontram em um estado de ansiedade ou insegurança. Tendo a escolha não é
necessariamente um sentimento agradável, que bem pode ser vivenciado como um fardo”
(Deetz, 1995, p. 71). A ansiedade cartesiana desencadeia a necessidade de sensemaking e a
ancoragem aos paradigmas existentes.
37
Uma baixa concordância e certeza vai exigir uma perspectiva construtivista, com objetivos
mais subjetivos e um processo de negociação, mais associada a questões 'soft' de VM.
Uma vez que os praticantes valor tornam-se conscientes deste problema, uma série de
técnicas passarão a fazer parte da sua “caixa de ferramentas” para análise funcional:
análise SWOT, cadeias de valor, Mindmaps, metodologia de sistemas soft, análise de gap,
etc. Estas técnicas e outras são as “representações existentes”, que permitem ao praticante
efetivamente dar sentido às necessidades e expectativas dos stakeholers e construir tanto
uma representação compartilhada de uma situação existente e a representação negociada
da situação desejada.
Relacionamentos Espera-se que o estudo dos relacionamentos existentes entre os vários elementos do SPF
ajudem a compreender melhor o framework, sua integração e a aplicação prática do
mesmo.
Em (Thiry, 2002) gerenciamento de valor (VM – Value Management) e aprendizado são
estudados. O autor acredita que VM pode oferecer aos gestores de programas as
ferramentas e técnicas que estão faltando em gerenciamento de projetos para lidar com o
ciclo de aprendizagem do programa.
Relacionamentos entre Valor e Sucesso e Fracasso existem. Yu et al. (2005) propõem uma
abordagem conceitual centrada em valor para medir o sucesso do projeto. O artigo adota
uma definição de projeto baseada em produto e um correspondente modelo de ciclo de
vida do projeto.
Successo e Fracasso A compreensão do sucesso e fracasso de projetos de software certamente contribui para
projetos com maior índice de sucesso no futuro. Existe um enorme esforço da comunidade
de pesquisa em gestão de projetos no estudo dos fatores de sucesso e fracasso dos
projetos. O aprendizado em projetos (incluindo o conceito de lições aprendidas) pode ser
exercitado através da análise dos fatores de sucesso e insucesso de projetos. Dessa forma,
esse elemento do SPF reúne e sistematiza esse conhecimento com o objetivo de aplicá-lo.
Em particular, esse elemento contribui diretamente para a estruturação e design de um
novo projeto, incluindo a singularização das suas dimensões e dos processos, métodos,
técnicas e ferramentas associadas.
Whitty e Maylor (2009) propõe a seguinte questão de pesquisa na investigação de projetos
complexos (que os autores denominam “major projects”):
Qual tem sido as causas principais de fracasso em projetos complexos (major
projects?
Sucesso e Fracasso, como um dos elementos do framework proposto, parece ser relevante,
podendo funcionar também como um parâmetro para atualizações do próprio framework
– por exemplo, ajudando a identificar novas dimensões ou descartados já existentes.
38
Tipologia e Categorização Reconhecendo a singularidade de projetos (one size does not fit all), define-se esse
importante element do SPF. A arquitetura associada a esse elemento deve permitir a
singularização, por exemplo, das dimensões da abordagem dado um projeto específico.
Vários trabalhos têm abordado a questão de categorização e adaptação de projetos.
Abaixo alguns trabalhos relevantes:
Shenhar, A.J., and D. Dvir, “Toward a Typological Theory of Project Management,”
Research Policy, 25 (1996), pp. 607–32.
Jaafari, Ali (2003). Project Management in the Age of Complexity and Change. PMJ
34(4).
Shenhar, A.J., and D. Dvir, “How Projects Differ, and What to Do About It,” in The
Wiley Guide to Managing Projects (P.W.G. Morris and J.K. Pinto eds.), Wiley & Sons
(2004), pp. 1265–86.
Shenhar, Aaron, Dov Dvir, Dragan Milosevic, Jerry Mulenburg, Peerasit Patanakul,
Richard Reilly, Michael Ryan, Andrew Sage, Brian Sauser, Sabin Srivannaboon, Joca
Stefanovic, Hans Thamhain (2005). Toward a NASA-Specific Project Management
Framework. Engineering Management Journal, 17(4), December 2005.
McLain, David (2009). Quantifying Project Characteristics Related to Uncertainty.
PMJ 40(4), pp. 60-73.
Barbosa, Igor de Mesquita (2009). Uma Proposta de um Modelo de Referência para
Categorização de Projetos. Dissertação de Mestrado, Universidade Federal de
Pernambuco, agosto, 2009.
Ebert, Cassiano (2009). Uma proposta para gerenciamento ágil de projetos de TI
baseada em sua complexidade. Dissertação de Mestrado, Universidade Federal de
Pernambuco, outubro, 2009.
Howell, D., Windahl, C., Seidel, R. (2010), A project contingency framework based
on uncertainty and its consequences. International Journal of Project Management
28 (2010), pp. 256–264.
Shenhar e Dvir (2004) sugerem um modelo que consiste de quatro dimensões: inovação
(novelty), complexidade, tecnologia e velocidade (pace), oNCTP ("Diamond” Model).
Processos, Métodos, Técnicas e Ferramentas O SPF é concretizado, do ponto de vista de aplicação prática, através de um conjunto de
processos, métodos, técnicas e ferramentas. Este conjunto habilitará membros da equipe
de projeto e demais stakeholders a aplicação prática do framework proposto.
A singularização de um dado projeto, através do elemento Tipologia e Categorização, deve
facilitar a escolha de processos, métodos, técnicas e ferramentas para tal projeto.
Não está no escopo desse artigo um maior detalhamento desse elemento, que é deixado
para estudos futuros.
39
Conclusões e Perspectivas Como dito no início este esforço de pesquisa é parte de um programa de pesquisa cujo
objetivo é desenvolver um framework para a gestão de projetos de software, procurando
novas paradigmas que permitam entender e gerenciar tais projetos. Aprendizado,
Complexidade, Conhecimento, Incerteza, Inovação, Liderança, Marketing, Metodologias,
Mudança, Política, Simplicidade, Social, Stakeholder e Valor são as novas dimensões
extraídas deste estudo e com potencial para um melhor entendimento de projetos de
software e sua gestão.
Um desafio que se coloca para aplicação prática do SPF é o grande número de dimensões
(14; por exemplo, o PMBOK do PMI tem 9 áreas de conhecimento). O processo de
singularização de projetos poderá sem dúvida amenizar essa dificuldade.
Embora ambicioso, o SPF é também um framework para pesquisa. Os seus elementos,
incluindo suas dimensões, representam uma nova agenda para pesquisa em gestão de
projetos.
Algumas limitações do processo de SR devem ser indicadas. Palavras-chaves de pesquisa
adicionais poderiam ser utilizadas (“teoria”, “futuro” são, por exemplo, novas palavras-
chaves que foram pensadas após a SR). Uma validação mais independente do protocolo de
pesquisa poderia também ser realizada. No entanto, o último conjunto de estudos obtido
pareceu bastante consistente. De forma mais geral, há necessidade de validação do
framework aqui proposto. Esse assunto será endereçado em um trabalho futuro.
Segundo Bredillet (2010) “estamos nos movendo de um velho paradigma – positivista –
para um novo ou para um mais equilibrado que combine o positivismo, o construtivismo, e
subjetivismo, o que nos permite abordar complexidade, incerteza e ambiguidade, porque o
antigo não está mais funcionando”.
Finalmente, de forma mais ampla, espera-se que este trabalho de pesquisa dê sentido e
uma melhor compreensão da natureza dos projetos e sua gestão.
Agradecimentos A todos os meus alunos e orientandos com os quais aprendi e aprendo muito. A todos que
fazem o Centro de Informática da UFPE, pela manutenção desse excelente ambiente
acadêmico. A Capes, CNPq, Finep e Facepe pelo apoio em vários projetos desenvolvidos
durante nossa vida acadêmica.
Referências Aaron J. Shenhar and Dov Dvirb (1996). Toward a typological theory of project
management. Research Policy. Volume 25, Issue 4, June 1996, Pages 607-632. 1999.
Abraham, T., C. Beath, C. Bullen, K. Gallagher, T. Goles, K. Kaiser, and J. Simon. (2006). “IT
Workforce Trends: Implications for IS Programs,” Communications of the Association for
Information Systems (17), pp. 1147-1170.
40
Agarwal, Nitin, Urvashi Rathod (2006). Defining success for software projects: An
exploratory revelation. International Journal of Project Management 24 (2006) 358–370.
Agile Alliance (2009). www.agilealliance.org. Última visita em 25 de maio de 2009.
Al-Ahmad, Walid, Khalid Al-Fagih, Khalid Khanfar, Khalid Alsamara, Saleem Abuleil, Hani
Abu-Salem (2009). A Taxonomy of an IT Project Failure: Root Causes. International
Management Review, Vol. 5 No. 1, 2009.
Alderman, N., Chris Ivory, Ian McLoughlin, Roger Vaughan (2005). Sense-making as a
process within complex service-led projects. International Journal of Project Management
23 (5) (2005), pp. 380–385.
Andersen, Erling S. (2008). Rethinking Project Management – An Organizational
Perspective. Pearson Education. May 2008.
André Felipe Lemos Santana, Hermano Perrelli de Moura (2005). Programas de Melhoria
de Processos de Software: Reflexões sob a Ótica de uma Teoria de Intervenção. SBQS 2005.
Andrew H. Van de Ven (1986) . Central Problems in the Management of Innovation.
Management Science, Vol. 32, No. 5, Organization Design (May, 1986), pp. 590-607.
Published by: INFORMS. URL: http://www.jstor.org/stable/2631848. 1986.
Archibald, Russel D., & Villoria, R. L. (1967). Network-based management systems
(PERT/CPM) (p. 508). Wiley.
Archibald, Russell D. (1988). Projects: Vehicles for Strategic Growth. Project Management
Journal, 19(4), 31-34.
Armour, Phillip (2001). Zeppelins and Jet Planes: A Metaphor for Modern Software
Projects. Communications of the ACM, October 2001/Vol. 44, No 10.
Atkinson, R., Lynn Crawford, Stephen Ward (2006). Fundamental uncertainties in projects
and the scope of project management. International Journal of Project Management 24
(2006) 687–698.
Audi, R. (2008). Cambridge Dictionary of Philosophy. Paw Prints.
Baccarini, D. (1996). The concept of project complexity—a review. International Journal of
Project Management, 1996, 14, 201–204.
Barker, J. R. (1993). Tightening the Iron Cage: Concertive Control in Teams. Administrative
Science Quarterly, 38(3), 408-437.
Bernstein, R. (1984). Beyond objectivism and relativism. Philadelphia: University of
Pennsylvania Press, 1984.
Betts, M., & Lansley, P. (1995). International Journal of Project Management: a review of
the first ten years. International Journal of Project Management, 13, 207-217.
41
Bjørn, Johs. Kolltveit, Jan Terje Karlsen, and Kjell Grønhaug (2004). Exploiting
Opportunities in Uncertainty During the Early Project Phase. J. Mgmt. in Engrg. Volume 20,
Issue 4, pp. 134-140 (October 2004) Issue Date: October 2004.
Blomquist, T., Hällgren, M., Nilsson, A., & Söderholm, A. (2010). Project-as-Practice: In
Search of Project Management Research That Matters. Project Management Journal.
Bredillet, C. N. (2010). Blowing Hot and Cold on Project Management. SKEMA Business
School, Lille, France.
Bredillet, C. N. (2008). Mapping the Dynamics of the Project Management Field: Project
Management in Action (Part 1). Project Management Journal, 39(4), 2-4. Also parts 2-6
(2008-2010).
Brenner, Richard (2008). Quantum Management. In www.chacocanyon.com. Última visita
em 25 de maio de 2008.
Brown, S. L., & Eisenhardt, K. M. (1997). The Art of Continuous Change: Linking Complexity
Theory and Time-paced Evolution in Relentlessly Shifting Organizations. Administrative
Science Quarterly, 42(1), 1-34.
Ebert, Cassiano (2009). Uma proposta para gerenciamento ágil de projetos de TI baseada
em sua complexidade. Dissertação de Mestrado, Universidade Federal de Pernambuco,
outubro, 2009.
Charette, R (1990).. Application Strategies for Risk Analysis. New York: MultiScience Press.
pp 17-21. 1990.
Cicmil, S, & Hodgson, D. (2006). New possibilities for project management theory: a critical
engagement. Project Management Journal, 37(3), 111-122.
Cicmil, S, Williams, T., Thomas, J., & Hodgson, D. (2006). Rethinking project management:
researching the actuality of projects. International Journal of Project Management, 24,
675-686.
Cicmil, Svetlana, Hodgson, Damian, Lindgren, M., Packendorff, Johann, Case, P., Piñeiro, E.,
et al. (2009). theory & politics in organization. ephemera, 9(2), 78-194.
Clegg S., Ross-Smith A. (2003). Revising the boundaries: management education and
learning in postpositivist world. Acad Manage Learn Educ, 2(1), 85–98.
Cleland, D., King W. (1983). Systems analysis and project management. McGraw-Hill Book
Company, 509 pages.
Cooke-davies, T. J., & Arzymanow, A. (2003). The maturity of project management in
different industries: An investigation into variations between project management models.
International Journal of Project Management, 21, 471-478.
Crawford L, Pollack J. (2004). Hard and soft projects: a framework for analysis.
International Journal of Project Management ;22(8):645–53.
42
Crawford, L., Pollack, J., & England, D. (2006). Uncovering the trends in project
management: Journal emphases over the last 10 years. International Journal of Project
Management, 24, 175-184.
d´Anunciação, Gustavo (2009). Análise e extensão do Rational Unified Process com relação
à ênfase na criação de valor. Dissertação de Mestrado, Universidade Federal de
Pernambuco, Centro de Informática.
David M. Gann and Ammon J. Salter (2000). Innovation in project-based, service-enhanced
firms: the construction of complex products and systems. SPRU – Science and Technology
Policy Research, University of Sussex, Mantell Building, Brighton BN1 9RF, UK. Elsevier
Science. 2000.
Dawson, P. (1997). In at the deep end: conducting processual research on organisational
change. Scandinavian Journal of Management, 13(4), 389-405.
de Amescua, Antonio, José García, Manuel Velasco, Paloma Martínez, Belén Ruiz, Juan
Llorens, Luis García, Antonio Calvo-Manzano, and Tomás San Feliu (2004). Software
project management framework. Information Systems Management. Spring 2004.
De Meyer, Arnoud, Christoph H. Loch, Michael T. Pich (2002). Managing Project
Uncertainty: From Variation to Chaos. Dec 1, 2002. 10p.
Deetz, S. (1995). Transforming communication, transforming business. Creskill, NJ:
Hampton Press, 1995.
Drucker, Peter F. (1955). The practice of management. Allied Publishers.
Dvir, D, Lipovetsky, S., Shenhar, A., & Tishler, A. (1998). In search of project classification: a
non-universal approach to project success factors. Research Policy, 27, 915-935.
Dvir, Dov, & Lechler, T. (2004). Plans are nothing, changing plans is everything: the impact
of changes on project success. Research Policy, 33, 1-15.
Engwall, M. (2003). No project is an island: linking projects to history and context.
Research Policy, 32(5), 789-808.
Eskerod, P. (1998). The human resource allocation process when organizing by projects.
In R. Lundim & C. Midler (Eds.), Projects as Arenas for Renewal and Learning Processes
(pp. 125-131). Kluwer Academic.
Eskerod, P. (2010). Action learning for further developing project management
competencies: A case study from an engineering consultancy company. International
Journal of Project Management, 28(4), 352-360. Elsevier Ltd and IPMA.
Evaristo, R., & Fenema, P. C. V. (1999). A typology of project management: emergence and
evolution of new forms. International Journal of Project Management, 17(5), 275-281.
Fichman, Robert G., Mark Keil, Amrit Tiwana (2005). Beyond Valuation: “Options
Thinking” in IT project management. California Management Review vol. 47, no.2, winter
2005.
43
Galbraith, J. R. (1971). Matrix Organization Designs - How to Combine Functional and
Project Forms. Business Horizons, 29-40.
Galbraith, J. R. (1974). "Organization Design: An Information Processing View" Interfaces,
4 (1974), 28-36.
Glaser, John (2009). Strategies for ensuring an IT project delivers value. Healthcare
Financial Management, July 2009.
Glass, Robert L., Iris Vessey (1994). Software Tasks: Intellectual, Clerical ... or Creative?
Computing Trends.
Goldratt, E. M. (1984). The goal. Great Barrington: The North River Press.
Goldratt, E. M. (1997). Critical chain. Great Barrington: The North River Press.
Gonzalez, R. R. (1995). A Unified Metric of Software Complexity: Measuring Productivity,
Quality, and Value.
Gusmão, C. M. G e Moura, H. P. (2004.) Gerência de Risco em Processos de Qualidade de
Software: uma Análise Comparativa. III Simpósio Brasileiro de Qualidade de Software.
Artigo Técnico. SBC. Brasília, Distrito Federal. Junho 2004.
Harzing, A.-W. (2010). The publish or perish book (p. 250). Melbourne: Tarma Software
Research Pty Ltd.
Hazebroucq, J. M., & Badot, O. (1997). Le management de projet (Collection.). Paris, France:
Editions PUF.
He, Jun, Brian S. Butler, William R. King (2007). Team Cognition: Development and
Evolution in Software Project Teams. Journal of Management Information Systems, Fall
2007, Vol. 24, No. 2, pp. 261–292.
Highsmith, J. (2004). Agile project management: creating innovative products. Addison
Wesley Longman Publishing Co., Inc. Redwood City, CA.
Hobday, M. (2000). The project-based organisation: an ideal form for managing complex
products and systems. Research Policy, 29, 871-893.
Hodgson, Damian, & Cicmil, Svetlana (Eds.). (2006). Making projects critical (p. 361).
Palgrave Macmillan.
Hoegl, M., & Proserpio, L. (2004). Team member proximity and teamwork in innovative
projects. Research Policy, 33, 1153-1165.
Hogberg, O., & Adamsson, A. (1983). A Scandinavian view of project management.
International Journal of Project Management, 216-219.
Howell, D., Windahl, C., Seidel, R. (2010), A project contingency framework based on
uncertainty and its consequences. International Journal of Project Management 28 (2010),
pp. 256–264.
44
Ibert, O. (2004). Projects and firms as discordant complements: organisational learning in
the Munich software ecology. Research Policy, 33, 1529-1546.
Jonassen, D.A., Hernandez-Serrano, J. (2002). Case-based reasoning and instructional
design: using stories to support problem solving. ETR&D 50 (2), 65–77.
Jugdev, K., & Müller, R. (2005). A retrospective look at our evolving understanding of
project success. Project Management Journal, 36(4), 19-31.
Keil, Mark (1995). Pulling the Plug: Software Project Management and the Problem of
Project Escalation. MIS Quarterly/December, 1995.
Kerzner, H. (1979). Project Management: A Systems Approach to Planning, Scheduling and
Controlling (p. 487). Van Nostrand Reinhold.
Kerzner, Harold, Frank P. Saladis (2009). Value-Driven Project Management. Wiley.
Kitchenham, B., Budgen, D., Brereton, P., Woodall, P. (2005). An investigation of software
engineering curricula. Journal of Systems and Software 74 (3), 325–335.
Kloppenborg, T., & Opfer, W. (2002). The current state of project management research:
trends, interpretations and predictions. Project Management Journal, 33(2), 5-19.
Koc, Tufan (2007). Organizational determinants of innovation capacity in software
companies. Computers & Industrial Engineering 53, 373–385.
Kruchten, P. (2002). “The Rational Unified Process: An Introduction”, Addison-Wesley,
Second Edition. 2002.
Kumar, D. (1989). Developing strategies and philosophies early for successful project
implementation. International Journal of Project Management, 7(3), 164-171.
Langley, A., & Royer, I. (2006). Perspectives on doing case study research in organisations.
Management, 9(3), 73-86.
Larson, E. W., & Gobeli, D. (1985). Project Management Structures: Is There a Common
Language?. Project Management Journal, 16(2), 40-44.
Lechler, T (1998). When it comes to project management, it´s the people that matter.
Proceedings of IRNOP III Conference: The Nature and Role of Projects in the Next 20
Years: Research Issues and Problems, Calgary, Alberta, Canada.
Lee, D. M. S., E. M. Trauth, and D. Farwell. (1995). “Critical Skills and Knowledge
Requirements of IS Professionals: A Joint Academic/Industry Investigation,” MIS Quarterly
(19)3, pp. 313-340.
Lehman, M.M. (1990) Uncertainty in Computer Application, Communications of the ACM,
Technical Correspondence 33(5) (1990) 584–586.
Lehmann, V. (2010). Connecting changes to projects using a historical perspective:
Towards some new canvases for researchers. International Journal of Project
Management, 28, 328-338.
45
Leybourne, S. (2010). Project Management and High-Value Superyacht Projects: An
Improvisational and Temporal Perspective. Project Management Journal, 41(1), 17-27.
Linberg KR (1999). Software developer perceptions about software project failure: a case
study. J Syst Software 1999;49:177–92.
Liu, J.Y.-C., et al., (2010). Relationships among interpersonal conflict, requirements
uncertainty, and software project performance, Int. J. Proj. Manag. (2010),
doi:10.1016/j.ijproman.2010.04.007.
Löwstedt, J. (1985). Contingencies or cognitions? Two paths for research on organization
and technology. Scandinavian Journal of Management Studies, 1(3), 207-225.
Lundin, Rolf A, & Söderholm, A. (1995). A theory of the temporary organization.
Scandinavian Journal of Management, 11(4), 437-455.
Lundin, Rolf A, Söderholm A. (1998). Conceptualizing a projectified society: discussion of
an eco-institutional approach to a theory on temporary organizations. In Rolf A. Lundin &
C. Midler (Eds.), Projects as arenas for learning and renewal. Boston: Kluwer Academic.
Lundin, Rolf A., & Midler, Christophe (Eds.). (1998). Projects as arenas for renewal and
learning processes. Kluwer Academic. 259 pages
Lyons, M. (1985). The DP Psyche. Datamation. August 15.
Mahaney, Robert C., Albert L. Lederer (2003). Information systems project management:
an agency theory interpretation. The Journal of Systems and Software 68 (2003) 1–9.
Management-social.com (2003). Groupe Management social. http://www.management-
social.com. Hubert Landier. Última visita em 23 de fevereiro de 2003.
Maylor, H. (2001). Beyond the Gantt chart: Project management moving on. European
Management Journal, 19(1), 92-100.
McBride, Tom (2008). The mechanisms of project management of software development.
The Journal of Systems and Software 81 (2008) 2386–2395.
McConnell, S. (2004). Professional software development: shorter schedules, higher
quality products, more successful projects, enhanced careers. Addison-Wesley, 2004. 243
páginas. ISBN 0321193679, 9780321193674.
McManus, John (2004). A Stakeholder Perspective in Software Project Management.
Management Services, May 2004.
Meneses, Javé (2001). Inspector: Um Processo de Avaliação de Progresso para Projetos de
Software. Dissertação de Mestrado, Universidade Federal de Pernambuco. 2001.
Mike Bresnen, Linda Edelmanb, Sue Newellb, Harry Scarbrougha and Jacky Swana (2003).
Social practices and the management of knowledge in project environments. International
Journal of Project Management. Volume 21, Issue 3, April 2003, Pages 157-166. 2003.
46
Milosevic, D. Z. (1989). Systems approach to strategic project management. International
Journal of Project Management, 7(3), 173-179.
Morris, P. W. G. (2000). Researching the unanswered questions of project management.
Paris: PMI Research Conference.
MVC (2003). Site do Futuro. Instituto MVC.
http://www.institutomvc.com.br/Futuro/Temporaria/empre_conceitos.htm. Última visita
em 22 de fevereiro de 2003.
Na, Kwan-Sik, Xiaotong Li, James T. Simpson, Ki-Yoon Kim (2004). Uncertainty profile and
software project performance: A cross-national comparison. The Journal of Systems and
Software 70 (2004) 155–163.
Nelson, R. Ryan (2007). IT project management: infamous failures , classic mistakes, and
best practices. MIS Quarterly Executive Vol. 6 No. 2 / June 2007, 67-78.
Nidumolu, Sarma (1995). The Effect of Coordination and Uncertainty on Software Project
Performance: Residual Performance Risk as an Intervening Variable. Information Systems
Research. Vol. 6, No. 3, September 1995, pp. 191-219. DOI: 10.1287/isre.6.3.191.
Nightingale, P. (2000). The product-process-organisation relationship in complex
development projects. Research Policy, 29, 913-930.
Packendorff, J. (1995). Inquiring into the temporary organization: new directions for
project management research. Scandinavian Journal of Management, 11(4), 319-333.
Parkes, D. (1998). Action learning: business applications in North America. Journal of
Workplace Learning, 10(3), 165-168.
Partington, D. (1996). The project management of organizational change. International
Journal of Project Management, 14(1), 13-21.
Perminova, Olga, Magnus Gustafsson, and Kim Wikström (2008). Defining uncertainty in
projects – a new perspective. International Journal of Project Management. Volume 26,
Issue 1, January 2008, Pages 73-79. European Academy of Management (EURAM 2007)
Conference.
Petter, Stacie (2008). Managing user expectations on software projects: Lessons from the
trenches. International Journal of Project Management 26 (2008) 700–712.
Pich, 2002: Michael T., Christoph H. Loch, Arnoud De Meyer (2002). On Uncertainty,
Ambiguity, and Complexity in Project Management. Management Science © 2002
INFORMS Vol. 48, No. 8, August 2002 pp. 1008–1023.
Pinto, J. K., & Covin, J. G. (1989). Critical factors in project implementation: a comparison of
construction and R&D projects. Technovation, 9, 49-62.
Prado, D.(2000). Gerenciamento de Projetos nas Organizações, Vol-I, Belo Horizonte, FDG.
2000.
47
Prencipe, A., & Tell, F. (2001). Inter-project learning: processes and outcomes of
knowledge codification in project-based firms. Research Policy, 30, 1373-1394.
Procaccino, J. Drew, June M. Verner (2006). Software project managers and project
success: An exploratory study. The Journal of Systems and Software 79 (2006) 1541–
1551.
Project Management Institute (1996). A guide to the project management body of
knowledge (PMBOK Guide). Project Management Institute.
Project Management Institute (2008). A guide to the project management body of
knowledge (PMBOK Guide) – Fourth Edition. Project Management Institute. 459 pages.
Project Management Institute (PMI) (2004) “A Guide to the Project Management Body of
Knowledge: PMBOK® Guide Third Edition”, USA. 2004.
Quinn, James Brian, Jordan J. Baruch, and Karen Anne Zien (1997). Innovation Explosion:
Using Intellect and Software to Revolutionize Growth Strategies, by New York: The Free
Press, 1997. 448 pages.
R. A. Burgelman, C. M. Christensen, S. C. Wheelwright (2008). Strategic management of
technology and innovation. McGraw-Hill/Irwin.
R. Jeffrey Thieme, X. Michael Song, and Geon-Cheol Shin (2003). Project Management
Characteristics and New Product Survival. Journal of Product Innovation Management.
Volume 20 Issue 2, Pages 104-119.
Ramgopal, Maruboyina (2003). Project uncertainty management. Cost engineering. ISSN
0274-9696. 2003, vol. 45, n 12, pp. 21-24. Association for the Advancement of Cost
Engineering, Morgantown, WV, US. 2003.
Ramgopal, Maruboyina (2003). Project Uncertainty Management. Cost Engineering Vol.
45/No. 12 DECEMBER 2003.
Rational Software Corporation, (2000). “Rational Solutions for Windows – Rational Unified
Process”, versão 2001.03.00. Propriedade e direitos reservados da Rational Software
Corporation. 2000.
Rivard, Suzanne, Ruth Dupré (2009). Information Systems Project Management in PMJ: A
Brief History. December 2009, Project Management Journal. DOI: 10.1002/pmj.
Royce, Walker (1998). “Software Project Management: A Unified Framework”, Addison-
Wesley. ISBN: 0201309580. 416 pages, September 1998.
Saad Neto, Emílio Georges (2008). Uma avaliação das ferramentas de gerenciamento de
múltiplos projetos. Trabalho de Graduação, Centro de Informática, Universidade Federal
de Pernambuco. Janeiro, 2008.
Sage, D., Dainty, A., & Brookes, N. (2010). A consideration of reflexive practice within the
critical projects movement. International Journal of Project Management, 28(6), 539-546.
Elsevier Ltd and IPMA.
48
Sahlin-Andersson, K., & Söderholm, A. (Eds.). (2002). Beyond project management: new
perspectives on the temporary-permanent dilemma. Liber.
Sauer, Chris, Blaize Horner Reich (2009). Rethinking IT project management: Evidence of a
new mindset and its implications. International Journal of Project Management 27 (2009)
182–193.
Saynisch, M. (2010). Beyond Frontiers of Traditional Project Management: An Approach to
Evolutionary, Self-Organizational Principles and the Complexity Theory - Results of the
Research Program. Project Management Journal, 41(2), 21-37.
Schmidt R, Lyytinen K, Keil M, Cule P (2001). Identifying software project risks: an
international Delphi study. J Manage Inform Syst 2001;17(4):5–36.
Schumpeter, Peter (1934). The Theory of Economic Development. Harvard University
Press, Boston. 1934.
Shenhar, A. J. (1996). Project management theory: the road to better practice. Project
Management Institute 27th Annual Seminar.
Shenhar, A. J., & Dvir, Dov. (1996). Toward a typological theory of project management.
Research Policy, 25, 607-632.
Shenhar, A.J., and D. Dvir (2004). How Projects Differ, and What to Do About It, in The
Wiley Guide to Managing Projects (P.W.G. Morris and J.K. Pinto eds.), Wiley & Sons (2004),
pp. 1265–86.
Shenhar, Aaron, Dov Dvir, Dragan Milosevic, Jerry Mulenburg, Peerasit Patanakul, Richard
Reilly, Michael Ryan, Andrew Sage, Brian Sauser, Sabin Srivannaboon, Joca Stefanovic,
Hans Thamhain (2005). Toward a NASA-Specific Project Management Framework.
Engineering Management Journal, 17(4), December 2005.
Simpson, W. D. (1987). New techniques in software project management. Wiley, 1987. 250
pp. ISBN 0471855510, 9780471855514.
Skibniewski, M. (2004). Critical Factors in Assuring Application Success of Web-Based
Project Management Systems in Construction. Invited Keynote Theme Speaker, INCITE
2004 – International Conference on Construction Information Technology, Langkawi,
Malaysia, February 2004.
Skibniewski, M., Harmelink, D., Jiang, J-P. (2001) “Methodology for Valuation of
Information Technology for Construction Management Applications, Zeszyty Naukowe
(Scientific Letters), Vol. 5, College of Communication and Management (WSKiZ), Poznan,
ISSN 1640-2839, pp. 16-38.
Skulmoski, G. J., & Hartman, F. T. (2010). Information Systems Project Manager Soft
Competencies: A Project-Phase Investigation. Project Management Journal, 41(1), 61-80.
Smith, P. A. C. (2001). Action learning and reflective practice in project environments that
are related to leadership development. Management Learning, 32(1), 31-48.
49
Söderlund, J. (2004). On the broadening scope of the research on projects: a review and a
model for analysis. International Journal of Project Management, 22, 655-667.
Söderlund, Jonas. (2004). Building theories of project management: past research,
questions for the future. International Journal of Project Management, 22, 183-191.
Souder, William E. and Rudy K. Moenaert (1992). Integrating marketing and R&D project
personnel within innovation projects: an information uncertainty model. Journal of
Management Studies. Volume 29, Issue 4, pages 485-512. 1992.
Stamelos, Ioannis (2010). Software project management anti-patterns. The Journal of
Systems and Software 83 (2010) 52–59.
Stefan Biffl, Aybüke Aurum, Barry Boehm, Hakan Erdogmus, Paul Grünbacher (Editors).
Value-Based Software Engineering. Springer. 2006.
Stepanek, G. (2005). Software project secrets: why software projects fail. Apress, 2005.
166 páginas. ISBN 1590595505, 9781590595503.
Steyn, H. (2002). Project management applications of the theory of constraints beyond
critical chain scheduling. International Journal of Project Management, 20, 75-80.
Stretton, A. (2007). A Short History of Modern Project Management. PM World Today,
IX(X), 1-18.
Summer, Mary, Douglas Bock, and Gary Giamartino (2006). Exploring the linkage between
the characteristics of it project leaders and project success. Information Systems
Management, Fall 2006.
Tanaka, H. (2004). The Changing Landscape of Project Management. Originally published
at the Global Symposium New Delhi, hosted by the Project Management Associates (PMA),
India, in December 2003.
Tatikonda, M.V. e Rosenthal, S.R. (2000). Technology novelty, project complexity, and
product development project execution success: a deeper look at task uncertainty in
product innovation. In IEEE Transactions on Engineering Management. Volume: 47, Issue
1, pages 74-87. ISSN: 0018-9391. February, 2000.
The British Computer Society – BCS (2004). The Challenges of Complex IT Projects. The
report of a working group from The Royal Academy of Engineering and The British
Computer Society. 2004.
The Standish Group (1994). The Chaos Report – 1994. The Standish Group.
www.standishgroup.com. Última visita em 9 de março de 2008.
Thiry, M. (1997). Value management practice. Sylva, NC: Project Management Institute,
1997.
Thiry, Michel (2001). Sensemaking in value management practice. International Journal of
Project Management 19 (2001) 71–77.
50
Thiry, Michel (2002). Combining value and project management into an effective
programme management model. International Journal of Project Management 20 (2002)
221–227.
Tjaeder, J., & Thomas, J. (2000). On learning and control—competing paradigms or co-
existing requirements for managing projects in ambiguous situations? International
Research Network on Organizing by Projects (IRNOP) fourth bi-annual conference,
Australia. Unpublished.
Travassos, G., Kitchenham, B., Dybå, T. (2006). Systematic reviews in Software
Engineering. Presentation. Available from http://www.cos.ufrj.br/~ese.
Tulip, Arthur (1986). Project management techniques applied to Computing. Project
Management. Vol. 4 No. 3. August 1986. 128-131 pp.
Turner, J. R. (2004). Managing Web projects: the management of large projects and
programmes for Web-space delivery. Gower Publishing, Ltd., 2004. 228 páginas. ISBN
0566085674, 9780566085673.
Turner, J. R. (2010). Evolution of project management research as evidenced by papers
published in the International Journal of Project Management. International Journal of
Project Management, 28, 1-6. Editorial.
Tynjälä, Päivi, Maritta Pirhonen, Tero Vartiainen, Laura Helle (2009). Educating IT Project
Managers through Project-Based Learning: A Working-Life Perspective. Communications
of the Association for Information Systems. Volume 24, Article 16, pp. 270-288, February
2009.
Verner, J. M., N. Cerpa (2005). Australian Software Development: What Software Project
Management Practices Lead to Success? Proceedings of the 2005 Australian Software
Engineering Conference (ASWEC’05), 2005.
Voropajev, V., & Scheinberg, M. (1992). Project-management methods and tools for the
21st century: the SOVNET view. International Journal of Project Management, 10(4), 253-
257.
Ward, Stephen and Chris Chapman (2003). Transforming project risk management into
project uncertainty management. International Journal of Project Management, Volume
21, Issue 2, February 2003, pages 97-105.
Ward, Stephen, Chris Chapman (2003). Transforming project risk management into
project uncertainty management. International Journal of Project Management 21 (2003)
97–105.
Wateridge J. (1998). How can IS/IT projects be measured for success. Int J Project Manage
1998;16(1):59–63.
Weick, K. (1977). Entactment processos nas organizações. In: M. Staw e G.R. Salancik,
Editors, Novos Rumos em Comportamento Organizacional, St. Clair, Chicago (1977).
Weick, K. E. (1995). Sensemaking in organizations. London: Sage, 1995.
51
White, D., & Fortune, J. (2002). Current practice in project management - an empirical
study. International Journal of Project Management, 20, 1-11.
Whitten, Neal (1995). Managing software development projects: formula for success.
Wiley, 1995. ISBN 047107683X, 9780471076834. 384 pp.
Whitty, Stephen Jonathan, Harvey Maylor (2009). And then came Complex Project
Management (revised).
Wideman, R. M. (2003). Modeling Project Management. Available from
http://www.maxwideman.com/papers/pm-models/intro.htm.
Wikipedia. (2010a). Wikipedia idea article. Wikipedia. Retrieved from
http://en.wikipedia.org/wiki/Idea.
Wikipedia. (2010b). Systematic review article. Wikipedia. Retrieved from
http://en.wikipedia.org/wiki/Systematic_review.
Williams, T. M. (1999). The need for new paradigms for complex projects.
Winter, M., & Szczepanek, T. (2009). Images of Projects. Gower Publishing. 264 pages.
Winter, M., Smith, C., Morris, P. e Cicmil, S. (2006). Directions for future research in project
management: The main findings of a UK government-funded research network.
International Journal of Project Management, vol. 24, pp. 638-649, 2006.
Winter, M., Smith, C., Morris, P., & Cicmil, S. (2006). Directions for future research in
project management: The main findings of a UK government-funded research network.
International Journal of Project Management, 24(8), 638-649.
Wren, D. (1994). The evolution of management thought. John Wiley. 466 pages.
Yeo, K. T. (1993). Systems thinking and project management - time to reunite.
International Journal of Project Management, 11pp, 111-117.
Yu, Angus G. Yu, Peter D. Flett, John A. Bowers (2005). Developing a value-centred
proposal for assessing project success. International Journal of Project Management 23
(2005) 428–436.
![Organizando el estudio[1]](https://img.pdfslide.net/doc/110x75/55c57c72bb61eb8c518b45da/organizando-el-estudio1.jpg)
