anexo

NOSSAS ETAPAS DE PESQUISA

ste livro baseado em quinze anos de estudo sobre o gerenciamento de projetos, que comeou no incio dos anos de 1990. Durante esse perodo, coletamos dados em mais de 600 projetos nos Estados Unidos e em Israel. Nossa pesquisa aconteceu em vrias fases e seus modelos evoluram gradualmente em um processo longo, iterativo e raramente estvel, alternando entre dados e teoria. Alguns modelos eram aparentes desde o comeo; outros emergiram medida que mais dados eram coletados e testados. Do mesmo modo, os tipos especficos de projetos continuaram evoluindo at que o quadro final estivesse bem-definido e inalterado por dados adicionais. Alguns projetos exibiram caractersticas adicionais (fora do modelo); assim sendo, ns as mencionamos como idias adicionais por todo o livro. As etapas e as fases de nosso estudo foram as seguintes: Comeamos com uma fase conceitual, sugerindo um efeito possvel da tecnologia nos estilos de gerenciamento de projetos (Shenhar, 1991, 1993). O trabalho fazia a distino entre quatro grupos de projetos associados com nveis diferentes de incerteza tecnolgica. Em 1992, usamos esse conceito para analisar o gerenciamento do projeto de desenvolvimento do nibus espacial e discutir suas implicaes no acidente do Challenger (Shenhar, 1992). Logo depois adicionamos a noo de complexidade do projeto com base na hierarquia de sistemas e subsistemas (Shenhar, Dvir e Shulman, 1995). Durante a primeira fase de coleta de dados documentamos 26 projetos nos quais aplicamos uma abordagem mltipla de estudo de caso, focando nas dinmicas dentro de cen-

Reinventando GeRenciamento de PRojetos aneXos

rios simples (Yin, 1984; Eisenhardt, 1989). A anlise de dados confirmou nossa hiptese de que existem grandes diferenas entre os projetos e os estilos de gerenciamento de projetos, baseadas em nveis diferentes de incerteza tecnolgica e complexidade do sistema (Shenhar, 1998). A prxima etapa envolveu a coleta de dados quantitativos em 127 projetos em 76 empresas, em Israel, nos setores comercial, de defesa e sem fins lucrativos. Os projetos que estudamos variavam em oramento, de $40 mil a $2.5 bilhes, e em durao, de trs meses a 12 anos. Usamos esses dados para construir uma teoria tipolgica de gerenciamento de projetos (Shenhar e Dvir, 1996) e para ampliar o conceito clssico da teoria de contingncia na arena de gerenciamento de projetos (Shenhar, 2001). Durante este perodo comeamos a explorar a questo das dimenses de sucesso dos projetos. Com base em estudos anteriores sobre as medidas de sucesso de unidades comerciais estratgicas (Dvir e Shenhar, 1992), tentamos ampliar o conceito de Placar Balanceado aos projetos. Os dados mostraram que podemos avaliar o sucesso de projetos usando pelo menos quatro medidas diferentes de sucesso (Shenhar, Dvir e Levy, 1997; Shenhar, Dvir, Levy e Maltz, 2001). O foco da terceira fase foi ampliar os conceitos bem-conhecidos dos fatores de sucesso de projetos para fazer a distino entre os tipos de projetos. Tambm continuamos nossa investigao das diferenas entre projetos e das medidas de sucesso. Para esta fase, coletamos dados em 110 projetos de desenvolvimento de defesa. Os dados eram qualitativos e quantitativos, e para cada projeto entrevistamos de trs a oito stakeholders dentro e fora do projeto. Vrias descobertas caracterizaram essa etapa. Primeiro, conseguimos mostrar que existem fatores de sucesso diferentes para tipos diferentes de projetos (Tishler, Dvir, Shenhar e Lipovetsky, 1996). Tambm testamos quais dimenses tm mais impacto na classificao de projetos, mostrando que a dimenso de complexidade provou ser um dos principais determinantes (Dvir, Lipovetsky, Shenhar e Tishler, 1998). Por ltimo, testamos a importncia relativa das medidas de sucesso do projeto. Descobrimos que o benefcio para o cliente o fator mais importante (Lipovetsky, Tishler, Dvir e Shenhar, 1997). Em seguida, empreendemos um esforo contnuo para coletar dados adicionais de casos em projetos nos Estados Unidos. Esse trabalho produziu mais de 280 casos de estudo detalhados em uma ampla variedade de setores. Nosso trabalho com vrias corporaes importantes e agncias governamentais proporcionou insights adicionais e permitiu a avaliao da implementao dessas estruturas. Neste estgio adicionamos a dimenso de ritmo ao nosso modelo (Shenhar, Dvir, Lechler e Poli, 2002).

aneXo 1

nossas etaPas de PesQUisa

Depois de comearmos a planejar este livro, percebemos que trs dimenses no eram suficientes para lidar com a novidade dos produtos no mercado. Assim sendo, adotamos a classificao de Steven Wheelright e Kim Clark (1992), a qual chamamos de novidade. Os dados provaram, sem dvidas, que esta uma dimenso separada e pelo menos to importante para a classificao do projeto quanto s outras trs, completando assim o modelo diamante.

Referncias
Dvir, Dov e Aaron J. Shenhar. Measuring the Success of Technology-Based Strategic Business Units. Engineering Management Journal 4, no 4 (1992): 3338. Dvir, Dov, Eli Segev e Aaron J. Shenhar. Technologys Varying Impact on the Success of Strategic Business Units within the Miles and Snow Topology. Strategic Management Journal 14 (1992): 155-162. Dvir, Dov, Stan Lipovetsky, Aaron J. Shenhar e Asher Tishler. In Search of Project Classification: A Non-Universal Approach to Project Success Factors. Research Policy 27 (1998): 915-935. Dvir, Dov, Aaron J. Shenhar e Shlomo Alkaher. From a Single Discipline Product to a Multidisciplinary System: Adapting the Right Style to the Right Project. System Engineering 6, no 3 (2003): 123-134. Eisenhardt, Kathleen M. Building Theories from Case Study Research. Academy of Management Review 14 (1989): 532-550. Lipovetsky, Stan, Asher Tishler, Dov Dvir e Aaron J. Shenhar. The Relative Importance of Project Success Dimensions. R&D Management 27, no 1 (1997): 97-106. Raz, Tzvi, Aaron J. Shenhar e Dov Dvir. Risk Management, Project Success, and Technological Uncertainty. R&D Management 32, no 2 (2002): 101-109. Shenhar, Aaron J. Project Management Style and Technological Uncertainty: From Low-to High Tech. Project Management Journal 22, no 4 (1991): 11-17. Shenhar, Aaron J. Project Management Style and the Space Shuttle Program: A Retrospective Look. Project Management Journal 23, no 1 (1992): 32-37. Shenhar, Aaron J. From Low- to High-Tech Project Management. R&D Management 23, no 3 (1993): 199-214 Shenhar, Aaron J., Dov Dvir e Yechiel Shulman. A Two Dimensional Taxonomy of Products and Innovation. Journal of Engineering and Technology Management 12, (1995): 175-200. Shenhar, Aaron J. e Alexander Laufer Integrating Product and Project Management: A New Synergistic Approach. Engineering Management Journal 7, no 3 (1995): 11-15.

Reinventando GeRenciamento de PRojetos aneXos

Shenhar, Aaron J. e Dov Dvir. Toward a Typological Theory of Project Management Style. Research Policy 25 (1996): 607-632. Shenhar, Aaron J., Dov Dvir e Ofer Levy. Mapping the Dimensions of Project Success. Project Management Journal 28, no 2 (1997): 5-13. Shenhar, Aaron J. From Theory to Practice: Toward a Typology of Project Management Styles. IEEE Transactions on Engineering Management 41, no 1 (1998): 33-48. Shenhar, Aaron J. One Size Does Not Fit All Projects: Exploring Classical Contingency Domains. Management Science 47, no 3 (2001): 394-414. Shenhar, Aaron J., Dov Dvir, Ofer Levy e Alan Maltz. Project Success: A Multidimensional, Strategic Concept. Long Range Planning 34 (2001): 699725. Shenhar, Aaron J., Dov Dvir, Thomas Lechler e Michael Poli. One Size Does Not Fit All: True for Projects, True for Frameworks. Trabalho apresentado na PMI Research Conference, Seattle, 2002. Tishler, Asher, Dov Dvir, Aaron J. Shenhar e Stan Lipovetsky. Identifying Critical Success Factors in Defense Development Projects: A Multivariate Analysis. Technological Forecasting and Social Change 51, no 2 (1996): 151171. Wheelright, Steven C. e Kim B. Clark. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency and Quality. New York: The Free Press, 1992. Yin, Robert K. Case Study Research: Design and Methods. Beverly Hills,CA: Sage Publishing, 1984.

anexo

QUESTIONRIO DE AVALIAO DO SUCESSO DO PROJETO

esponda a cada uma das declaraes seguintes sobre seus projetos. Indique seu grau de concordncia ou discordncia com a declarao assinalando uma resposta para cada item.
Discorda Totalmente Discorda Concorda Concorda Totalmente N/A

D1 Eficincia do Projeto d11 o projeto foi completado a tempo ou antes. d12 o projeto foi completado dentro ou abaixo do oramento. d13 o projeto teve apenas pequenas mudanas. d14 outras medidas de eficincia foram alcanadas. D2 Impacto no Cliente / Usurio d21 o produto melhorou o desempenho do cliente. d22 o cliente ficou satisfeito. d23 o produto satisfez os requisitos do cliente. d24 o cliente est usando o produto. d25 o cliente pretende voltar para trabalhos futuros.

Discorda Totalmente

Discorda

Concorda

Concorda Totalmente

N/A

Reinventando GeRenciamento de PRojetos aneXos

Discorda Totalmente Concorda Totalmente

D3 Impacto na Equipe d31 a equipe do projeto ficou bastante satisfeita e motivada. d32 a equipe foi totalmente leal ao projeto. d33 a equipe do projeto tinha alto moral e energia. d34 a equipe achou divertido trabalhar neste projeto. d35 os membros da equipe passaram por um crescimento pessoal. d36 os membros da equipe queriam continuar na organizao. D4 Sucesso Comercial e Organizacional Direto d41 o projeto teve um sucesso comercial discreto. d42 o projeto aumentou a lucratividade da organizao. d43 o projeto teve um retorno positivo sobre o investimento. d44 o projeto aumentou a participao da organizao no mercado. d45 o projeto contribuiu para o valor dos acionistas. d46 o projeto contribuiu para o desempenho direto da organizao. D5 Preparao para o futuro d51 o resultado do projeto contribuir para projetos futuros. d52 o projeto levar a produtos adicionais. d53 o projeto ajudar a criar novos mercados. d54 o projeto criar novas tecnologias para uso futuro. d55 o projeto contribuiu para novos processos do negcio. d56 o projeto desenvolveu capacidades administrativas melhores.

Discorda

Concorda

N/A

Discorda Totalmente

Discorda

Concorda

Concorda Totalmente

N/A

Discorda Totalmente

Discorda

Concorda

Concorda Totalmente

N/A

D6 Dimenses adicionais de sucesso relevantes a este projeto. Informe e avalie o sucesso. d61 d62 D7 Sucesso geral d71 no geral, o projeto foi um sucesso.

anexo

3a

CONSTRUINDO A ABORDAGEM DE CONTINGNCIA AO GERENCIAMENTO DE PROJETOS

ara entender os meios fundamentais por meio dos quais organizaes podem classificar seus projetos, podemos examinar a contingncia clssica da teoria da inovao. Essa teoria afirma que condies diferentes podem requerer ambientes organizacionais diferentes, e que a eficcia da organizao contingente na quantidade de adequao entre as variveis estruturais e ambientais.1 Mas como os argumentos clssicos de contingncia se mantm no mundo dinmico, temporrio e instvel de projetos? Diferentemente das empresas, os projetos so organizaes temporrias. Eles tm um tempo limitado, geralmente fazem parte de uma organizao maior e realizam, em sua maioria, tarefas novas que no foram feitas anteriormente. Ainda assim, ironicamente, a teoria clssica no teve um impacto significativo no gerenciamento de projetos contemporneo.2 Embora vrias idias tenham sido mencionadas no passado, nenhum padro empiricamente baseado, foi at agora, adotado.3 Contudo, em busca de maiores distines entre projetos, vrias observaes podem ser feitas.4 Primeiro, a natureza fundamental de projetos como tarefas que nunca foram feitas, naturalmente, nos leva a considerar a incerteza do projeto como uma dimenso principal para selecionar projetos.5 Segundo, alguns projetos podem ser mais complexos do que outros, e, assim sendo, a

Reinventando GeRenciamento de PRojetos aneXos

complexidade da tarefa e da organizao outro candidato claro para distino.6 Notadamente, a combinao de incerteza e complexidade tambm tem sido muitas vezes mencionada como uma base para distino.7 Por ltimo, uma vez que cada projeto tem um limite de tempo, podemos tambm considerar a restrio de tempo como uma base para diferenciao do projeto.8

A Estrutura Terica Bsica: O Modelo ICR

Nossa pesquisa identificou trs dimenses iniciais para fazer a distino entre as tarefas do projeto: incerteza, complexidade e ritmo. Juntos, o denominamos de o modelo ICR, e eles formam uma estrutura terica livre de contexto para selecionar o estilo gerencial apropriado (veja a Figura 1).9 Vamos examinar essas dimenses em mais detalhes e tentar ver como elas podem afetar o gerenciamento de projetos. Incerteza. Incerteza significa o quanto no sabemos no incio do projeto. Projetos diferentes apresentam, no incio, nveis diferentes de incerteza. As incertezas do projeto podem ser externas ou internas, dependendo do ambiente ou da tarefa especfica e da habilidade para realiz-la. Por exemplo, enviar os primeiros seres humanos Lua foi uma tarefa altamente incerta. Ela representava incertezas enormes de misso e tcnica. Por contraste, a construo de uma nova casa representa menos incerteza, tanto em tarefa quanto em meios, e a habilidade de se prever o resultado muito melhor. Avaliar corretamente e definir a incerteza do projeto no incio , portanto, o principal fator no geren-

Figura 1

O Modelo ICR
Complexidade

Risco

incerteza: no momento de iniciao do projeto complexidade: tamanho, nmeros de elementos, variedade, interconectividade Ritmo: perodo de tempo disponvel

Incerteza

Ritmo

aneXo 3a

constRUindo a aBoRdaGem de continGncia...

ciamento de projetos. Ela claramente tem um impacto nos planos, nos recursos, na inteireza dos requisitos, no tempo necessrio e muitos mais. Complexidade. Ela depende da complexidade do produto e da tarefa mais especificamente, da estrutura do produto e sua funcionalidade, assim como o nmero e a variedade de elementos, as subtarefas e as interconexes entre eles. Complexidade no a mesma coisa que incerteza. O desenvolvimento de um novo bairro, com centenas de prdios pode ser um projeto altamente complexo, porm bastante certo em termos de meios e da habilidade para realiz-lo. A complexidade do produto e da tarefa pode ter um impacto na complexidade da organizao do projeto e nos processos e ferramentas usados para planejar e monitorar o projeto. Ritmo. A terceira dimenso envolve a urgncia e a criticidade das metas de tempo. O ritmo depende do tempo disponvel alocado para a concluso do projeto e do grau de urgncia. Quando o Apollo 13 corria o risco de no retornar, o projeto para salvar seus astronautas tornou-se um projeto de crise. Em contraste, quando o Opera House de Sidney foi construdo, o tempo realmente no teve muita importncia para os tomadores de decises polticas. A mesma meta com um ritmo diferente requer estruturas diferentes de projetos, ateno gerencial diferente e taxas diferentes de tomada de decises.

anexo

3B

QUESTIONRIO DE CLASSIFICAO DE PROJETOS

Nmero do Projeto_________________________________ Nome do Projeto________________________________

1XX Setor

01 Farmacutico 02 eletrnicos para consumo 03 telecomunicaes 04 tecnologia da informao 05 servios Financeiros 06 automotivo 07 defesa 08 energia 09 software 10 manufatura

11 Propaganda 12 entretenimento 13 sade 14 seguro 15 construo 16 viagem 17 consultoria 18 comrcio eletrnico 19 outro

Descrio do Produto Descrio do Projeto

Uma breve descrio do produto produzido pelo projeto: Uma breve descrio do escopo do trabalho no projeto: TIPO DE PROJETO

20X Novidade do Produto

1 derivativo (melhoria). 2 Plataforma (Uma nova gerao em uma linha existente de produto). 3 inovao (Um produto novo-para-o-mundo).

aneXo 3B
30X Incerteza Tecnolgica

QUestionRio de cLassiFicao de PRojetos

11

1 tipo a Baixa-tecnologia (nenhuma nova tecnologia). 2 tipo B mdia-tecnologia (alguma tecnologia nova). 3 tipo c alta-tecnologia (todas ou quase todas as tecnologias novas, mas existentes). 4 tipo d super-alta-tecnologia (Projeto usar tecnologias no existentes no incio).

40X Complexidade (Escopo do Sistema)

1 montagem (Um subsistema realizando uma funo nica). 2 sistema (Uma coleo de subsistemas realizando funes mltiplas).

3 matriz (sistema de sistemas uma coleo amplamente dispersa de sistemas que servem a uma misso comum). 50X Ritmo 1 Regular (atrasos no so crticos). 2 Rpido/competitivo (tempo para o mercado uma vantagem competitiva). 3 de tempo crtico (tempo para concluso crtico para o sucesso, janela de oportunidade). 4 Blitz (Projetos para crises). 60X Metas Empresarias 1 operacional (extenso de um negcio existente). 2 estratgica (criao de um novo negcio). 70X Cliente 1 externo (contratos ou consumidores externos). 2 interno (Usurios internos ou outro departamento). 80X Meta Estratgica 1 extenso (aperfeioando, melhorando um produto existente). 2 estratgica (Principal criao de novas posies estratgicas nos negcios por meio de novos produtos ou mercados). 4 manuteno (manuteno de rotina, resoluo de problemas regulares). 5 Utilidade (manter as luzes acesas adquirir e instalar novos equipamentos ou software, implementar novos mtodos ou novos processos, reorganizao, reengenharia). 6 Pesquisa e desenvolvimento (estudo explorao de idias futuras, nenhum produto especfico em mente). Data de Incio do Projeto Durao do Projeto Oramento (ms/ano) (meses) ($)

3 Resoluo de problemas (adquire ou desenvolve uma nova tecnologia ou nova capacidade).

anexo

3c*

PRINCPIOS E ELABORAO DE SISTEMAS DE CLASSIFICAO

lassificao uma maneira de fazer com que o conhecimento do mundo seja mais gerencivel. Na realidade, classificar to comum em nossas vidas que muitas vezes no nos damos conta de sua difuso, e alguns autores sugerem que a necessidade de classificar, rotular ou agrupar as coisas caracterstica inata da natureza humana.10 Sistemas de classificao arbitrrios e intuitivos, que focam primariamente nas classes, tm pouco valor alm do uso de curto prazo e instrumental para o qual eles podem ser rapidamente atribudos. Um sistema de classificao slido baseado na seleo meticulosa e na definio das classes e dos atributos que as distinguem, garantindo que as diferenas significativas sero reconhecidas. Deve-se expressar os relacionamentos entre as classes de maneira a realar seu entendimento sobre o fenmeno, e idealmente a classificao possui habilidades previsveis. Se isso for alcanado, e tambm for atribudo a um propsito especfico, tendo em mente a necessidade dos usurios, ento o sistema de classificao ter um potencial slido para compartilhar e criar novos conhecimentos e contribuir para o desenvolvimento de uma teoria.
*Este anexo baseado em Lynn Crawford, Brian Hobbs e Rodney J. Turner, Project Categorization Research Report (Newton Square, PA: Project Management Institute, Research Development, 2004). Agradecemos a Lynn Crawford por ter preparado anotaes adicionais sobre classificao, as quais nos ajudaram a moldar este anexo.

aneXo 3c

PRincPios e eLaBoRao de sistemas de cLassiFicao

13

Funes e Propsitos da Classificao

As classificaes podem ser usadas para proporcionar fcil acesso aos itens, dandolhes um contexto ou subsistema por meio do qual interpretar uma rea ou definir e estabelecer seus limites. O propsito da classificao determina quais atributos so significativos para identificar a diferena entre esta e outras entidades. A classificao nos auxilia a dar sentido ao mundo, proporcionando meios para descrever ou representar entidades que encorajam a consistncia de representaes mentais, dentre e entre os indivduos.11 As classificaes focam na identificao de similaridades e diferenas entre entidades e nos auxilia no armazenamento e no uso de experincias passadas. Os sistemas de classificao proporcionam uma linguagem padronizada, um sistema de navegao e uma base para comparao que fundamental na transmisso de conhecimento transfervel, acessvel e aproveitvel. Kwasnik defende que os esquemas de classificao no apenas refletem o conhecimento ao serem baseados na teoria e demonstrarem-na de maneira til... mas as classificaes em si tambm funcionam do mesmo modo que as teorias e servem a uma funo similar na investigao: esta a funo da explicao, descrio parcimoniosa e elegante, e gerao de novo conhecimento.12 Jacob nos proporciona um exemplo excelente: Ao agrupar os pacientes de acordo com as similaridades observveis, os mdicos conseguem acesso ao conhecimento com base em experincias passadas, as quais prevem a utilidade de abordagens alternativas terapia e conseguem aplicar esse conhecimento no tratamento de indivduos. Desse modo, a apreenso da similaridade traz conhecimento.13

Princpios de Classificao
Na pratica, geralmente nos referimos classificao de coisas em categorias e usamos os termos classificao e categorizao de maneira intercambivel.14 Mas a interpretao rgida faz a distino entre classificao como designar objetos, eventos ou propriedades... em classes mutuamente exclusivas dentro da estrutura hierrquica imposta pelo ordenamento arbitrrio e pr-determinado da realidade, e categorizao como um processo de dividir o mundo de experincias em grupos ou categorias cujos membros carregam certo relacionamento percebido de similaridade entre si.15 Essa definio de categorizao pode ser considerada pragmaticamente mais aplicvel aos projetos do que a definio de classificao. Os sistemas de classificao tm duas funes principais: definio e organizao. Definio a determinao de classes de entidades que compartilham atributos caractersticos, e organizao envolve um ordenamento sistemtico de classes que expressam relacionamentos conceituais dentro da estrutura em geral.16

14

Reinventando GeRenciamento de PRojetos aneXos

Os esquemas de classificao apresentados neste livro assumem a forma de categorias. Aqui, os fenmenos sendo classificados (projetos) so agrupados em classes de acordo com as caractersticas compartilhadas ao longo de duas ou mais dimenses. Cada projeto compartilha a caracterstica representada por cada uma das dimenses, porm em nveis diferentes. Por exemplo, a dimenso nvel de incerteza tecnolgica (T) dividida em quatro nveis: baixa, mdia, alta e superalta-tecnologia. O relacionamento entre os itens demonstrado pelas suas posies compartilhadas em uma grade ou matriz. Essa matriz pode ser considerada como uma forma de anlise de facetas, nas quais as dimenses da matriz so as facetas do projeto e cada dimenso ou faceta da matriz tem suas prprias regras especficas para divises posteriores.17 Segundo Bowker e Star, quando elaboramos um esquema de classificao, devemos considerar trs parmetros: comparabilidade, visibilidade e controle.18 Comparabilidade se refere habilidade do esquema de classificao em proporcionar comparabilidade entre os locais para certificar-se de que h regularidade na semntica e objeto de um para o outro, acentuando, assim, a comunicao. Visibilidade envolve o problema segundo o qual enquanto o conhecimento permanecer invisvel ele no pode ser classificado. Controle indica que a complexidade precisa ser atrelada para proporcionar alguma forma de entendimento das complexidades desenvolvidas no esquema de classificao. H tenso entre liberdade e estrutura, mas necessria alguma forma de controle para que a informao faa sentido.19 Se um sistema de classificao for altamente detalhado e complicado, ele no ser usado.

Caractersticas dos Sistemas de Classificao

Embora a teoria clssica de classificao exija a existncia de atributos crticos comuns, o conceito de categorias baseado em semelhanas, onde possa haver limites obscuros entre as categorias, mais apropriado para entidades como projetos. Para evitar complexidade excessiva, todos os sistemas de classificao deixam passar algo ou no conseguem capturar certos aspectos do fenmeno de interesse.20 Um esquema de classificao deve ser moldado pelo seu propsito. Na realidade, o propsito direciona a seleo de categorias e atributos que significam diferenas. Assim sendo, cada sistema de classificao tende a ser especfico ou aplicvel apenas a um campo limitado, embora no seja raro que o mesmo sistema de classificao seja usado para propsitos diferentes.21 Por exemplo, possvel usar o mesmo sistema de classificao de projetos como a base para alocao de recursos, garantindo, assim, alinhamento com sua estratgia, monitoramento do projeto e controle, assim como o relatrio gerencial em um portfolio de projetos. comum que esquemas diferentes de classificao sejam aplicados ao mesmo corpo de conhecimento ou conjunto de entidades.

aneXo 3c

PRincPios e eLaBoRao de sistemas de cLassiFicao

15

importante lembrar que uma classe no um fenmeno objetivo esperando para ser descoberto, e sim uma construo que proporciona o significado mais coerente aos usurios dentro do limite de seus conhecimentos e , portanto, dependente da experincia humana.22 As questes de limite surgem das linhas de demarcao entre as categorias em um esquema de classificao. Por exemplo, decises precisam ser tomadas a respeito do nvel de detalhes (quantas categorias) que devem ser identificados, assim como o que deve ser definido e o que deve permanecer invisvel dentro da estrutura. Uma considerao adicional o grau de diferenciao em uma estrutura classificada que significa o limite entre as classes. Uma vez que o sistema de classificao criado, as pessoas provavelmente se socializaro com os atributos das categorias eleitas e espera-se que o sistema influencie o comportamento.23 O trabalho pode mudar para se adaptar a um esquema de classificao. Um esquema de classificao no , portanto, uma estrutura objetiva ou neutra, mas tem sim o potencial de agir sobre as interaes em seu ambiente e influenci-las. Um aspecto disso que a memria organizacional filtrada atravs dos sistemas de classificao, e esses sistemas influenciam quais informaes so gravadas e como elas podem ser recuperadas.24

A Elaborao dos Sistemas de Classificao de Projetos

Nosso exame do material sobre categorizao fora da literatura de gerenciamento de projetos identificou dois pontos importantes. Primeiro, os sistemas de categorizao so direcionados pelos propsitos que eles servem e a categorizao serve a muitas necessidades. Segundo, a elaborao e o uso de um sistema de categorizao, em um contexto profissional ou organizacional, trazem tona muitas questes no relacionadas. A literatura sobre o gerenciamento de projetos focou em um conjunto ilimitado de usos que podem abrigar os sistemas de categorizao de projetos.

Atributos Usados para Organizar Projetos em Categorias

O sistema de uma organizao para categorizar os projetos pode ser visto como um composto de atributos, rtulos e definies. Atributos so as caractersticas bsicas usadas para categorizar projetos. Um exemplo simples o tamanho. Os rtulos so os nomes que a organizao usa para identificar os grupos de projetos. Um exemplo grande e pequeno. Em alguns exemplos, o rtulo autoexplicativo, assim como so muitas das categorizaes por localizao geogrfica. Em outros, uma definio deve ser atribuda para que o rtulo tenha significado. Um exame dos muitos exemplos de sistemas de categorias encontrados na literatura e nas organizaes revela muitas semelhanas nos atributos usados,

16

Reinventando GeRenciamento de PRojetos aneXos

mas h uma semelhana menos significativa nos agrupamentos especficos, rtulos e definies. Por exemplo, muitas organizaes agrupam seus projetos por localizaes geogrficas, mas cada sistema especfico s localizaes cobertas pela organizao. O tamanho outro atributo comumente usado para agrupar projetos em categorias. No entanto, o que um projeto grande para uma organizao, pode ser muito pequeno para outra.25 Assim sendo, existem muitas semelhanas em nvel de atributos usados para categorizar projetos, mas as categorias que so usadas pelas organizaes tendem a ser especficas ao contexto. Dentro de um contexto organizacional especfico, existe uma ligao clara entre o propsito organizacional e as categorias em uso. So encontrados muitos exemplos dos mesmos propsitos sendo perseguidos por organizaes diferentes, usando atributos diferentes para categorizar seus projetos. Similarmente, existem muitos exemplos nos quais organizaes diferentes usam os mesmos atributos para propsitos diferentes. Por exemplo, o atributo comum de regies geogrficas usado por muitas organizaes para muitos propsitos. Alguns o usam para indicar em qual escritrio regional eles faro o trabalho, outros o usam para adaptar as diferenas em estruturas regulatrias e outros o usam para alinhar suas estratgias de penetrao no mercado. Similarmente, muitas organizaes agrupam projetos em categorias para desenvolver ferramentas e mtodos especficos para cada categoria. Tudo depende das fontes relevantes de variao entre os projetos da organizao. Para algumas organizaes, o tipo de produto ou a tecnologia a fonte primria de variao. Para outras, a diviso geogrfica, sendo que os projetos internacionais so gerenciados diferentemente dos projetos domsticos. Para outras organizaes, a variao pode ser primariamente por tipo de contrato, por complexidade, por nvel de risco ou por tamanho. O relacionamento entre os propsitos organizacionais, servidos pelos sistemas, e os atributos, que so mais relevantes, so especficos ao contexto. Duas organizaes que buscam o mesmo objetivo em contextos diferentes, usaro atributos diferentes para categorizar seus projetos. Essa separao entre propsitos organizacionais e atributos faz com que a construo de modelos nesse campo seja mais complexa.

anexo

NOVIDADE DO PROJETO E GERENCIAMENTO DE PROJETOS TRADICIONAL

este Anexo observamos o impacto dos vrios nveis de novidade sobre os processos clssicos de gerenciamento de projetos. Usamos as nove reas de conhecimento comuns do PMBOK. A Tabela 1 mostra como os vrios nveis de novidade do produto afetam essas reas. Quanto maior a novidade de seu produto, menos claras sero as coisas no incio. Assim sendo, as estimativas so menos precisas e o risco maior, e voc precisa ter mais flexibilidade e criatividade para levar os projetos a uma concluso bem-sucedida.

TaBELa 1

18

Novidade do projeto e reas de conhecimento do PMBOK

NVEL DE NOVIDADE DO PROJETO Plataforma Inovao

rea de conhecimento Derivativo do PMBOK integrao integrao simples baseada em experincias prvias; foca no valor derivativo adicionado e na transferncia rpida para operaes e vendas.

escopo

tempo

custo

Qualidade

Recursos humanos

Reinventando GeRenciamento de PRojetos aneXos

comunicaes

Risco

aquisies

Funes cruzadas extensivas; foca na integrao de novos integrao focada nas funes centrais para provar a elementos e nas novas capacidades da nova gerao; testes validade do conceito do produto; incorpora feedback extensivos durante o perodo de integrao. do cliente por meio de prottipos rpidos e testes betas de sites; integra as funes organizacionais para criar percepo de mercado. Foca principalmente no trabalho necessrio para define o trabalho de cima para baixo desde o comeo; Gerenciamento flexvel do escopo para permitir incorporar valor ao produto. controle rgido do escopo para garantir a introduo suave mudanas baseadas no feedback do mercado e em do produto. testes. Gerenciamento de tempo de processamento Planeja tempo suficiente para maximizar as novas Permite verses suficientes do produto antes da acelerado para garantir a entrega rpida para o capacidades do produto e eliminar todas as falhas do definio final; flexvel em considerar novas idias; mercado. produto; mas o tempo para o mercado importante em evita atalhos; faz planos de contingncia para as termos de competitividade. possveis dificuldades. Feito de acordo com o custo e o controle rgido do Planejamento detalhado do custo e controle cuidadoso; controle de custo flexvel antes da definio final do oramento; melhora a eficcia em termos de custo. aloca oramento para testes completos; ciente dos excessos produto; aloca recursos para prottipos e teste de potenciais causados por adies desnecessrias. mercado. Foca na melhoria contnua e incremental da Planejamento extenso da qualidade e garantia da qualidade; a qualidade no to crtica por causa da novidade qualidade do produto. remoo contnua de falhas durante todo o projeto. do produto; h pouco planejamento da qualidade nos estgios posteriores do projeto. Pessoas conscientes da eficincia, do custo e do membros da equipe bem- organizados e multifuncionais; Procura pessoas criativas e inovadoras em vrias tempo; estilo gerencial rgido. pessoas que enxergam alm; estilo gerencial semi-rgido. funes; permite liberdade para expressar e testar novas idias; estilo gerencial altamente flexvel. canais curtos e rpidos de comunicao; nvel canais de comunicao extensos e mltiplos entre todas comunicao informal extensa e freqente, se mnimo de comunicao formal. as reas funcionais; comunicao formal e documentao possvel, considere co-locao; documentao formal complementada por interao formal. das decises finais. Risco mnimo; gerenciamento de riscos foca as Plano extenso de gerenciamento de riscos; identifica alto risco em virtude das muitas incgnitas; mudanas no produto. logo no incio as reas potenciais de risco; cria planos abordagens diferentes de projeto acopladas com os de contingncia e redundncias para proteger contra os planos de contingncia. fracassos. Quando possvel, uso de itens fceis de encontrar; envolve fornecedores na definio e projeto dos principais Usa qualquer fonte disponvel, incluindo verses uso de fontes mltiplas para garantir custo mais componentes e subsistemas; usa fontes mltiplas para outros de teste para garantir a vantagem substancial do baixo e evitar atrasos na introduo no mercado. componentes. produto nos primeiros prottipos; garante as fontes de fornecimento para a verso final.

anexo

5a

RESULTADOS EMPRICOS PARA TECNOLOGIA DO PROJETO

s partes quantitativas de nosso estudo reforam a validade de descobertas qualitativas ao medir as diferenas estatsticas nas variveis gerenciais entre os vrios tipos de projetos e definir as tendncias de contingncia.26 A Tabela 2 contm informaes sobre os recursos diferentes consumidos pelos vrios tipos de projetos. Esta inclui as estatsticas descritivas para quatro nveis de incerteza tecnolgica. O valor em escala associado ao oramento foi de 1 (menos de $100 mil) para 6 (mais de $1 milho). O valor em escala da durao do projeto foi de 1 (menos de 6 meses) a 6 (mais de 8 anos). As outras duas variveis eram a mdia do nmero de funcionrios durante a execuo e a porcentagem de pessoas com grau acadmico. A tabela tambm contm os resultados dos testes de ANOVA (Anlise das Variaes) para cada varivel, e os coeficientes de correlao de Pearson entre essas variveis e a incerteza tecnolgica. Os dados na Tabela 2 mostram claramente que incerteza mais alta requer aumento nos oramentos e projetos mais longos; ainda assim, o nmero mdio de trabalhadores empregados no projeto no est relacionado incerteza tecnolgica. O aumento no oramento e no tempo no caso de projetos com tecnologia mais alta pode ser atribudo complexidade do projeto e no necessidade de empregar mais pessoas. Entretanto, os projetos de tecnologia mais alta empregam mais trabalhadores com grau acadmico do que os projetos de tecnologia mais baixa.

20
TaBELa 2

Reinventando GeRenciamento de PRojetos aneXos

Recursos do projeto para os vrios nveis de incerteza tecnolgica

BT Mdia (D.P) 3,03 (1,17) 2,39 (1,10) 142 (382) 20,2 (29,9) INCERTEZA TECNOLGICA MT AT SAT Mdia Mdia Mdia (D.P) (D.P) (D.P) 3,11 (1,16) 2,88 (0,78) 45 (90) 55,1 (27,2) 3,51 (0,78) 3,15 (0,95) 38 (36) 59,3 (25,5) 3,70 (0,67) 3,40 (0,96) 80 (126) 66,6 (17) ANOVA

Variveis nvel em escala do oramento do projeto nvel em escala de durao do projeto mdia de mo-de-obra empregada Porcentagem de grau acadmico
*p < 0,05

df 3.123 3.123 3.123 3.123

F 2,04 6,12*** 1,99

Correlao 0,218* 0,318***

-0,142 15,2*** 0,452***

**p < 0,01 ***p < 0,001

A principal distino entre os projetos demonstrada pelos nveis ascendentes das atividades de engenharia, com o aumento na incerteza tecnolgica (veja a Tabela 3). A primeira varivel o nmero de atividades includas na rede de planejamento do projeto varia de 1 (menos de 100) para 4 (mais de 10 mil). A segunda e a terceira variveis descrevem o nmero de ciclos de projetos realizados antes de o projeto ser congelado e o quartil no qual esse congelamento aconteceu (zero significa que o plano foi congelado antes do incio do projeto). As revises e os planejamentos do projeto indicam o nvel de esforo investido na realizao das tarefas de engenharia no projeto. O planejamento inclui trs variveis: o nvel de uso de mtodos computadorizados de planejamento, marcos detalhados e planejamento integrativo do oramento e do cronograma (todos em uma escala Likert de 1 a 7). Como podemos ver, essas variveis esto positivamente associadas incerteza tecnolgica, o que indica a necessidade de melhor planejamento e controle em projetos de alta e super-alta-tecnologia. O restante da Tabela 3 descreve diversas variveis combinadas do processo de engenharia do projeto (nas escalas Likert de 1 a 7). Por exemplo, a medida do gerenciamento de risco representa as variveis para questes como a identificao inicial de riscos do projeto, a avaliao provvel dos riscos e a incluso de um plano detalhado para mitigao do risco. A medida de engenharia de sistemas inclui quatro variveis, tais como o uso de procedimentos estruturados de engenharia de sistemas, o uso do gerenciamento de configurao e o uso de vrios tipos de software. O gerenciamento da qualidade representa trs variveis que medem at que ponto o plano de qualidade total foi preparado, as metas de qualidade foram selecionadas e o controle estatstico foi realizado no projeto. Todas as variveis de engenharia aumentam com a incerteza tecnolgica quando vamos de projetos de baixa-tecnologia para projetos de alta-tecnologia.

aneXo 5a

ResULtados emPRicos PaRa tecnoLoGia do PRojeto

21

Para algumas variveis (revises do projeto e engenharia de sistemas), no h aumento adicional para os projetos de super-alta-tecnologia. Concluindo, os projetos de tecnologia mais alta requerem mais ciclos de planejamento, congelamento do plano mais tarde e aumento da ateno s consideraes do projeto, gerenciamento de riscos, engenharia de sistemas e gerenciamento da qualidade.27

TaBELa 3

Estatsticas descritivas e resultados da ANOVA para vrios nveis de incerteza tecnolgica: variveis relacionadas engenharia e ao projeto
BT Mdia (D.P) 1,50 (0,83) 1,03 (0,33) 0,25 (0,52) 3,13 (2,3) 3,92 (1,9) 1,87 (1,7) 2,74 (2,2) 3,59 (2,3) INCERTEZA TECNOLGICA MT AT SAT Mdia Mdia Mdia (D.P) (D.P) (D.P) 1,66 (0,72) 2,07 (0,60) 1,95 (1,0) 5,29 (1,9) 4,83 (1,4) 2,38 (1,5) 3,95 (1,8) 3,87 (1,8) 1,93 (0,69) 2,60 (0,95) 2,3 (0,83) 5,97 (1,3) 5,20 (1,4) 2,8 (1,4) 4,99 (1,5) 4,72 (1,7) 2,30 (0,48) 2,70 (1,2) 2,6 (0.96) 5,6 (1,8) 6,06 (1,1) 3,25 (0,94) 4,58 (1,8) 4,85 (1,5) ANOVA

Variveis nvel em escala das atividades nmero de ciclos de planejamento Quartil de congelamento do plano Revises do projeto Planejamento Gerenciamento de risco engenharia de sistemas Gerenciamento da qualidade
*p < 0,05

df 3.121 3.121 3.121

F 12,16*** 28,7*** 37,65***

Correlao 0,301*** 0,608*** 0,581***

3.117 3.120 3.89 3.92 3.96

12,66*** 5,95*** 2,07 6,31** 2,35

0,416*** 0,351*** 0,255* 0,364*** 0,247*

**p < 0,01 ***p < 0,001

anexo

5B

TECNOLOGIA DO PROJETO E GERENCIAMENTO DE PROJETOS TRADICIONAL

omo vimos, a movimentao ao longo da dimenso de incerteza est associada principalmente maneira como os problemas tcnicos so resolvidos. Ela afeta o nmero de ciclos de planejamento, o tempo dedicado s mudanas no projeto, a necessidade de construir prottipos, a extenso de testes e a freqncia e complexidade das decises intercambiveis. Cada uma dessas preocupaes poder ter um impacto no gerenciamento de projetos tradicional, como mostrado na Tabela 4.

TaBELa 4

Incerteza tecnolgica e as reas de conhecimento do PMBOK

NVEL DE INCERTEZA TECNOLGICA Mdia-tecnologia Alta-tecnologia Foca na integrao de novos Funcionalidade cruzada extensiva elementos empresa; envolve os e envolvimento do cliente; testes clientes em novas reas para garantir extensivos durante a integrao; o cumprimento dos requisitos. integra as funes organizacionais para criar percepo de mercado.

rea de conhecimento do PMBOK Baixa-tecnologia integrao integrao simples baseada em experincias prvias; rpida transferncia para operaes e vendas.

escopo

tempo

custo

aneXo 5B tecnoLoGia do PRojeto e GeRenciamento de PRojetos tRadicionaL

Qualidade

Super-alta-tecnologia integrao focada nas funes centrais para provar a validade de conceito do sistema; esforo extenso na integrao de tecnologias recm-desenvolvidas; integra o feedback do usurio com base em prottipos rpidos. controle rgido do escopo desde o Permite mudanas apenas antes do define o trabalho de cima para baixo Gerenciamento flexvel do escopo incio do projeto; permite apenas congelamento do plano; controle rgido desde o comeo; permite mais tempo para permitir mudanas baseadas na mudanas requisitadas e aprovadas do escopo aps o congelamento do para ciclos de planejamento; controle viabilidade tecnolgica e no teste do pelo cliente. plano. rgido do escopo aps o congelamento prottipo. do plano para garantir a integridade do produto. controle rgido do cronograma desde mantm uma reserva gerencial para Planeja tempo suficiente para a Permite verses suficientes do produto o comeo; planeja o incio precoce da permitir tempo para novas peas; integrao e o teste para eliminar antes de o produto final ser congelado; maioria das atividades; pequena controle rgido do cronograma aps a todas as falhas do produto. flexvel sobre a incorporao de reserva para riscos externos. eliminao dos riscos iniciais; o tempo novas tecnologias e idias; faz planos para o mercado importante para a de contingncia para possveis competitividade. dificuldades. oramento baseado em projeto Projeto de acordo com o custo e o controle detalhado do custo com base controle flexvel do custo antes da detalhado e experincias prvias; controle rgido do oramento; no planejamento detalhado; aloca definio final do produto; aloca controle rgido do oramento. pequena reserva para dificuldades o oramento para testes completos; recursos para prottipos e testes; tecnolgicas imprevistas. ciente dos excessos potenciais em reservas relativamente grandes para os virtude de adies desnecessrias. planos de contingncia. aderncia estrita s especificaes Foco nas reas tecnolgicas novas Planejamento extenso da qualidade nfase no desempenho do produto; contratuais; uso de componentes bem- para a empresa; projeto para e garantia da qualidade; remoo outros aspectos da qualidade so conhecidos e confiveis. a confiabilidade, manufatura e contnua de falhas; projeto para menos importantes em virtude da sustentabilidade. a confiabilidade, manufatura e inovao do produto; um pouco de sustentabilidade. planejamento nos estgios posteriores do projeto. (continua)

23

TaBELa 4 (continuao)

24

Incerteza tecnolgica e as reas de conhecimento do PMBOK

Mdia-tecnologia NVEL DE INCERTEZA TECNOLGICA Alta-tecnologia Super-alta-tecnologia Lderes com habilidades tcnicas excepcionais e capacidade de avaliar o valor potencial em tecnologias ainda no desenvolvidas; pessoas criativas e inovadoras em vrias funes; permite a liberdade de expressar e testar novas idias; estilo gerencial altamente flexvel. comunicao informal extensa e freqente; se possvel, considere a co-location; documentao formal das decises finais. Procura os problemas; alto risco em virtude das muitas incgnitas; abordagens diferentes de projeto acopladas aos planos de contingncia. Usa qualquer fonte disponvel, incluindo as verses para teste, para garantir viabilidade tecnolgica nos primeiros prottipos; garante as fontes de fornecimento para a verso final.

rea de conhecimento do PMBOK Baixa-tecnologia

Recursos humanos

Pessoas conscientes da eficincia; estilo membros da equipe bem-organizados e Lderes com altas habilidades tcnicas; pessoas criativas e inovadoras nas gerencial rgido. multifuncionais; pessoas criativas funes de desenvolvimento; estilo e inovadoras nas funes de gerencial flexvel nas primeiras desenvolvimento; estilo gerencial semi-rgido. fases; estilo gerencial rgido aps o congelamento do plano.

comunicao

canais de comunicao curtos, rpidos comunicao formal e documentao vrios canais formais e informais de e menos intensos; a maioria dos canais complementada por certa interao comunicao para interao entre os so formais. informal. membros da equipe; documentao formal das decises finais. Plano extensivo de gerenciamento de riscos; cria planos de contingncia e redundncias para proteger contra os fracassos. envolve os fornecedores na definio e no projeto dos principais componentes e subsistemas; usa vrias fontes para garantir um custo mais baixo e evitar atrasos na introduo no mercado.

Risco

Quase no h risco interno ou identifica as reas possveis de risco tecnolgico; o gerenciamento de riscos e foca nelas para evitar atrasos e focado em fontes externas. excessos no oramento.

Reinventando GeRenciamento de PRojetos aneXos

aquisio

Uso apenas de itens fceis de encontrar;sempre que possvel usa itens fceis de garante as fontes de fornecimento encontrar; envolve os fornecedores na antes do incio do projeto. definio e no projeto de componentes para fins especiais e subsistemas.

anexo

6a

RESULTADOS EMPRICOS PARA A COMPLEXIDADE DO PROJETO

omo mencionado no Anexo 5A, a poro quantitativa de nossos estudos refora a validade das descobertas qualitativas. Aqui, examinamos a complexidade.28 A Tabela 5 contm informaes sobre os recursos consumidos por vrios tipos de projetos. Ela inclui as estatsticas descritivas para vrios nveis de complexidade. Os valores em escala, em termos de oramento, so de 1 (menos de $100 mil) a 6 (mais de $1 bilho). Os valores em escala de durao so de 1 (menos de 6 meses) a 6 (mais de 8 anos). As outras duas variveis so o nmero mdio de funcionrios durante a execuo e a porcentagem de pessoas com grau acadmico. A Tabela 5 tambm contm os resultados dos testes de ANOVA (Anlise das Variveis) para cada varivel, e os coeficientes de correlao de Pearson entre essas variveis e a complexidade do projeto, representados por uma escala de 1 (montagem) a 3 (matriz). Como descobrimos, parece haver uma associao entre complexidade e tamanho. O oramento e a durao aumentam significativamente com o escopo. Em contraste, descobrimos que a porcentagem de funcionrios que tm grau acadmico diminui com a complexidade, provavelmente porque a construo de projetos de alta complexidade requer um nmero grande de construtores e arteses e uma poro pequena de pessoas acadmicas, que so geralmente engajadas no projeto, planejamento, anlise e teste. Tambm observamos uma grande distino entre projetos com base nas variveis gerenciais. A Tabela 6 inclui as estatsticas descritivas, a ANOVA e os co-

26
TaBELa 5

Reinventando GeRenciamento de PRojetos aneXos

Recursos do projeto para vrios nveis de complexidade do projeto

COMPLEXIDADE DO PROJETO Montagem Sistema Matriz Mdia Mdia Mdia (D.P.) (D.P.) (D.P.) 2,47 (0,99) 2,50 (0,96) 11 (17) 57,2 (28,0) 3,47 (0,81) 3,00 (0,90) 54 (79) 49,6 (31,3) 4,55 (0,88) 3,66 (1,11) 393 (623) 23,3 (23,1) ANOVA

Varivel nvel em escala do oramento do projeto nvel em escala da durao do projeto mdia de mo-de-obra empregada Porcentagem de trabalhadores com grau acadmico
*p < 0,05

df 2.124 2.124 2.124 2,124

F 31,45*** 8,12** 18,26*** 4,52*

Correlao 0,548*** 0,308*** 0,359*** -0,229**

**p < 0,01 ***p < 0,001

eficientes de correlao obtidos para essas variveis. As duas primeiras variveis esto em uma escala de 1 a 5 e representam uma combinao de algumas subvariveis. Por exemplo, a medida de engenharia de sistemas inclui quatro subvariveis, como o uso de procedimentos estruturados da engenharia de sistemas, o uso de gerenciamento de configurao e o uso de vrios tipos de software. Como podemos ver, o uso de engenharia de sistemas e prticas de gerenciamento da qualidade aumenta significativamente em projetos de sistema e de matriz, em comparao aos projetos de montagem, mas a engenharia de sistemas mais comum em projetos de sistemas do que em projetos de matriz. Por ltimo, o nmero de atividades do projeto e a extenso do planejamento, controle e documentao parecem aumentar significativamente com a complexidade do projeto. O nmero de atividades includas na rede de planejamento do projeto est codificado em quatro nveis: 1 (menos de 100); 2 (entre 100 e 1.000); 3 (entre 1.000 e 10.000) e 4 (mais de 10.000). As outras variveis na Tabela 6 so medidas combinadas de escala de 7 pontos que representam a extenso na qual os mtodos formais foram usados em cada um desses grupos de variveis. A Tabela 6 indica claramente a necessidade de recorrer a procedimentos mais formais quando a complexidade do projeto aumenta. Todas as variveis gerenciais na tabela esto significativamente associadas complexidade. Uma exceo interessante o planejamento do projeto. O nvel mais alto de planejamento encontrado em projetos de sistemas em vez de projetos de matriz.

aneXo 6a
TaBELa 6

ResULtados emPRicos PaRa a comPLeXidade do PRojeto

27

Estatsticas descritivas e resultados da ANOVA para vrios nveis de complexidade do projeto

Varivel COMPLEXIDADE DO PROJETO Montagem Sistema Matriz Mdia Mdia Mdia (D.P.) (D.P.) (D.P.) 3,20 (1,9) 3,52 (1,9) 1,18 (0,47) 3,75 (2,2) 3,99 (1,7) 3,90 (1,5) 4,75 (1,6) 4,84 (1,6) 4,63 (1,8) 1,89 (0,68) 5,09 (1,6) 5,26 (1,4) 4,82 (1,3) 5,45 (1,1) 3,81 (2,5) 4,28 (1,6) 2,66 (0,86) 5,91 (0,91) 4,66 (1,5) 5,14 (1,2) 5,91 (0,96) ANOVA

df 2.93 2.97 2.122 2.105 2.121 2.124 2.123

F 8,55*** 3,71* 46,2*** 7,07** 7,95* 5,88** 4,49*

Correlao 0,264*** 0,214*** 0,524*** 0,340*** 0,247** 0,282* 0,168

engenharia de sistemas Gerenciamento da qualidade atividades estrutura de diviso de trabalho Planejamento controle documentao

*p < 0,05

**p < 0,01 ***p < 0,001

anexo

6B

COMPLEXIDADE DO PROJETO E GERENCIAMENTO DE PROJETO TRADICIONAL

Tabela 7 mostra como os nveis diferentes de complexidade podem afetar os processos de gerenciamento de projetos segundo as principais reas de conhecimento do PMBOK.

TaBELa 7

Complexidade do projeto e as reas de conhecimento do PMBOK

NVEL DE COMPLEXIDADE DO PROJETO Montagem Sistema Matriz

rea de conhecimento do PMBOK

integrao

integrao simples; rpida transferncia para operaes e vendas.

Perodo de integrao extensivo para certificar-se integrao de susbsistemas por subcontratados; de que o sistema est funcionando como planejado; casos raros de integrao em larga escala pelo envolvimento funcional cruzado e do cliente; contratado principal. integrao gradual de subsistemas; testes extensos durante a integrao do sistema.

escopo

Permite apenas as mudanas que possam melhorar Permite mais tempo para os ciclos de planejamento; controle rgido do escopo; congelamento precoce a eficcia em termos de custo; o escopo poder controle rgido do escopo depois do congelamento do plano na arquitetura de matriz, para permitir o mudar por causa das especificaes especiais dos do plano para garantir a integridade do produto. trabalho de contratados em nvel de sistemas. fabricantes oem. Planeje tempo suficiente para testar os subsistemas, mantm uma reserva gerencial para permitir os integrao dos sistemas e testes para eliminar atrasos dos contratados; planeje tempo suficiente todas as falhas do produto. para a coordenao total da disposio das funes. controle detalhado do custo com base no planejamento cuidadoso; aloca o oramento para testes completos; ciente dos excessos potenciais em razo das adies desnecessrias. oramento em geral administrado pelo contratado principal; flexibilidade na alocao do oramento para os contratados; mantm uma reserva gerencial para permitir a coordenao prolongada no local.

tempo

controle rgido do cronograma desde o comeo; pequena reserva para riscos externos.

custo

oramento baseado no projeto detalhado e em experincias prvias; projeto feito de acordo com o custo; controle rgido do oramento.

Qualidade

aderncia estrita s especificaes contratuais; uso de componentes bem-conhecidos e confiveis; projeto para a confiabilidade e manufatura.

Planejamento extensivo da qualidade e garantia da nfase na interface entre os sistemas; incorporao qualidade; remoo contnua de falhas por todo o de testes centrais e/ou remotos, e anlise das projeto. falhas. Lderes com altas qualidades de sistemas assim como habilidades tcnicas; membros da equipe bem-organizados e multifuncionais; estilo gerencial flexvel nas primeiras fases; estilo gerencial rgido aps o congelamento do plano. Lderes com habilidades gerenciais execepcionais, com extensa experincia prvia e habilidades em relaes humanas; prefira um gerente de programa com habilidades diplomticas e habilidade em lidar com autoridades locais e governamentais; estilo gerencial altamente flexvel. (continua)

Recursos humanos

Foco principal nas habilidades tcnicas e projeto para eficincia, custo e tempo.

TaBELa 7 (continuao)

30

Complexidade do projeto e as reas de conhecimento do PMBOK

NVEL DE COMPLEXIDADE DO PROJETO Montagem Sistema Matriz Principalmente comunicao formal e documentao com os principais contratados; documentao formal de todas as decises que tenham implicaes contratuais. Risco associado principalmente a sistemas que trabalham em conjunto; gerenciamento de risco de cada sistema conduzido como independente pelo seu contratado. Usa contratados com experincia anterior no desenvolvimento dos subsistemas requeridos; prefere contratados que compartilham uma cultura similar.

rea de conhecimento do PMBOK

comunicaes

canais curtos e rpidos e principalmente informais; se possvel, considere co-locao; vrios canais documentao formal das decises finais. formais e informais de comunicao para interao entre os membros da equipe; documentao formal das decises finais. Plano de gerenciamento de risco extensivo; planos de contingncia e redundncias para proteger contra as falhas. envolve os fornecedores na definio e no projeto dos principais componentes e subsistemas; usa fontes mltiplas para garantir custo mais baixo e evitar atrasos na introduo no mercado.

Risco

Gerenciamento de risco mnimo focado na incorporao de tecnologias e fontes externas que possam causar atrasos e excessos no oramento.

Reinventando GeRenciamento de PRojetos aneXos

aquisio

Uso de itens fceis de encontrar, quando possvel; garante as fontes de fornecimento antes de o projeto comear.

anexo

RITMO DO PROJETO E GERENCIAMENTO DE PROJETOS TRADICIONAL

Tabela 8 descreve como os vrios nveis de ritmo de projetos afetam o gerenciamento de projetos segundo as principais reas de conhecimento do PMBOK. Como podemos ver, com o aumento no ritmo, a ateno no gerenciamento torna-se cada vez mais focada na reduo do risco de atrasos no projeto.

TaBELa 8

32

Ritmo do projeto e as reas de conhecimento do PMBOK

NVEL DE RITMO DO PROJETO Regular integrao intensiva e teste para garantir a entrada em tempo oportuno para o mercado. Perodos de integrao cuidadosamente planejados para garantir a preparao adequada em tempo. controle rgido do escopo para evitar mudanas desnecessrias que possam atrasar o projeto. Rpido/Competitivo Tempo crtico Blitz no h tempo para integrao nos projetos blitz.

rea de conhecimento do PMBOK

integrao

integrao gradual at que o sistema final seja completado e testado.

escopo

Uso de tcnicas regulares de gerenciamento do escopo.

Gerenciamento do escopo flexvel para permitir as mudanas com base no feedback do mercado e das aes dos concorrentes. o tempo para o mercado importante para a competitividade; usa processamento acelerado e congelamento precoce das especificaes e do projeto para garantir a entrega rpida para o mercado; a alta gerncia monitora o tempo mediante a concluso de marcos importantes. o tempo extremamente crtico; usa todos os recursos disponveis para cumprir com as metas de tempo; faz planos de contingncia para as possveis dificuldades; planeja tempo suficiente para eliminar todas as falhas do produto; a alta gerncia est bastante envolvida e monitora o desempenho de tempo freqentemente. aloca oramento para solues alternativas e testes completos para garantir a concluso no tempo previsto.

no h controle do escopo.

Reinventando GeRenciamento de PRojetos aneXos

tempo

o tempo no crtico; leva o tempo necessrio para garantir a integridade do produto.

o tempo extremamente crtico; usa todos os recursos disponveis para solucionar as situaes de crises; prepara planos de contingncia para as situaes possveis; envolvimento contnuo da alta gerncia para garantir a resoluo da crise em tempo oportuno.

custo

controle detalhado do custo com base no planejamento cuidadoso.

aloca recursos para prottipos rpidos e teste de mercado; o tempo tem precedncia sobre o custo.

custo no uma questo importante.

Qualidade

Foca na melhoria incremental contnua da qualidade do produto

Planejamento extensivo da qualidade e garantia da qualidade para assegurar tempo para o mercado. equipes multifuncionais; estilo gerencial semi-rgido. Pessoas sensatas que possam enxergar a criticalidade da restrio de tempo; estilo gerencial rgido Fora tarefa treinada antes e liberada de outras obrigaes; usa pessoas de fora para resolver os problemas crticos. comunicao informal extensa e contnua durante toda a crise.

Planejamento extensivo da qualidade e garantia da qualidade para evitar qualquer atraso.

no h nfase especfica na qualidade.

Recursos humanos

no h um foco especfico na seleo da equipe do projeto; estilo gerencial flexvel.

comunicao

a maior parte da comunicao est focada em questes profissionais.

canais de comunicao extensivos e mltiplos por todas as reas funcionais; documentao formal complementada por certa interao informal.

canais curtos e freqentes de comunicao; faz co-location dos membros da equipe na mesma instalao, se possvel.

Risco Plano extensivo do gerenciamento de risco; identifica as reas potenciais de risco logo no incio; abordagens diferentes ao projeto para reduzir os riscos de atrasos. envolve o fornecedor na definio e no projeto dos principais componentes e subsistemas; usa fontes mltiplas para garantir custo mais baixo e evitar atrasos na introduo no mercado.

no h foco especfico no risco de atrasos.

identifica as reas potenciais de risco logo no incio; cria planos de contingncia e redundncias para proteger contra o fracasso de cumprir o prazo de entrega. Usa itens fceis de encontrar, quando possvel; depende de fornecedores conhecidos; cria contratos guarda-chuva para a aquisio mais rpida de componentes e materiais sem a necessidade de renovar os contratos.

importncia especial dos planos de contingncia preparados antecipadamente para vrios cenrios.

aquisio

Uso de vrias fontes de fornecimento, como requerido; garante as fontes de fornecimento para a verso final do produto.

Usa qualquer fonte disponvel, incluindo as verses para teste; prepara procedimentos de aquisio de emergncia e canais antecipadamente.

NOTAS DOS ANEXOS

1.

2. 3.

Paul R. Lawrence e Jay William Lorch, Organization and Environment: Managing Differentiation and Integration (Boston: Harvard University, 1967); Robert Drazin e Andrew H. Van de Ven, Alternative Forms of Fit in Contingency Theory, Administrative Science Quarterly 30 (1985): 514-539; Johannes M. Pennings, Structural Contingency Theory: A Reappraisal, Research in Organizational Behavior 14 (1992): 267-309. Aaron J.Shenhar, One Size Does Not Fit All Projects: Exploring Classical Contingency Domains, Management Science 47, n 3 (2001): 394-414. Por exemplo, Stewart P. Blake (Managing for Responsive Research and Development, So Francisco: Freeman & Co., 1978) sugeriu uma distino normativa entre os projetos com pequenas mudanas (alfa) e os projetos com grandes mudanas (beta); e Steven C. Wheelwright e Kim B. Clark (Revolutionizing Product Development, New York: The Free Press, 1992) mapearam os projetos de desenvolvimento do produto na empresa de acordo com o grau de mudana que eles fazem no portfolio do produto. Alguns adaptaram a distino radical versus a incremental (por exemplo, Chee Meng Yap e William E. Souder, Factors Influencing New Product Success and Failure in Small Entrepreneurial High-Technology Electronics Firms, Journal of Product Innovation Management, 11 (1994): 418-432; Shona L.Brown e Kathleen M. Eisenhardt, The Art of Continuous Change: Linking Complexity Theory and Time-paced Evolution in Relentlessly Shifting Organizations, Administrative Science Quarterly 42 (1997): 1-34; e William E. Souder e Michael X. Song, Contingent Product Projeto and Marketing Strategies Influencing New Product Success and Failure in U.S. and Japanese Electronics Firm, Journal of Product Innovation Management 14 (1997): 21-34) e outros sugeriram estruturas mais refinadas (por exemplo, Lowell W. Steele, Innovation in Big Business (New York: Elsevier Publishing Company, 1975); Niv Ahituv, Michael Hadass e Seev Neumann, A Flexible Approach to Information System Development, MIS Quarterly (junho,1984): 69-78; James

notas dos aneXos

35

4.

5.

6.

I. Cash Jr., Warren F. McFarlan e James L. McKenney, Corporate Information Systems Management (Homewood, IL: Irwin, 1988); e Alan W. Pearson, Innovation Strategy, Technovation 10, n 3 (1990): 185-192. Dov Dvir, Stan Lipovetsky, Aaron J. Shenhar e Asher Tishler, In Search of Project Classification: A Non-Universal Approach to Project Success Factors, Research Policy 27 (1998):815-935. Em busca dessa estrutura, poderamos voltar a 1967, quando trs trabalhos influentes foram publicados independentemente. Eles haviam tido um impacto significativo na teoria da contingncia. Paul Lawrence e Jay Lorch (Organization and Environment: Managing Differentiation and Integration) focaram em como os nveis diferentes de mudana em tecnologia, cincias e mercados afetam a habilidade de uma organizao em lidar com essas mudanas. Com o uso de uma marca integrada de incerteza, eles concluram que em um campo mais diverso e dinmico, organizaes eficazes devem ser altamente diferenciadas e integradas, ao passo que em um ambiente mais estvel e menos diverso, as organizaes eficazes podem ser menos diferenciadas, mas ainda assim elas devem alcanar um alto grau de integrao. James D. Thompson (Organizations in Action, New York: McGraw-Hill, 1967) sugeriu que lidar com a incerteza o problema central para organizaes complexas e que a tecnologia e os ambientes so as principais fontes de incerteza. E Charles C.Perrow (A Framework for the Comparative Analysis of Organizations, American Sociological Review 32 (1967): 194-208) usou uma perspectiva integrada sobre a tecnologia e organizaes complexas, ao mesmo tempo tratando a tecnologia como a varivel independente e a estrutura como a varivel dependente. Ao usar a tecnologia para distinguir entre problemas analisveis e no analisveis, ele identificou quatro tipos de indstrias: artesanal, de rotina, de no-rotina e de engenharia. Para lidar com a complexidade, a natureza hierrquica de sistemas e seus subsistemas h muito tem sido a base da teoria geral de sistemas (Kenneth Boulding, General Systems Theory: the Skeleton of Science, Management Science (abril de 1956): 197-208; John P. Van Gigch, Applied General Systems Theory,2 ed. (New York: Harper and Row, 1974); e Aaron J. Shenhar,On System Properties and System-hood, International Journal of General Systems 18, n 2 (1991): 167-174). Boulding, por exemplo, sugeriu uma classificao hierrquica de sistemas que inclua nove nveis, comeando com o tipo mais baixo de estruturas estticas e aumentando para sistemas transcendentais. Obviamente, pelo fato de produtos serem compostos de elementos, e sistemas de subsistemas, as hierarquias em produtos so quase sempre abordadas em livros de praticantes e monografias que lidam com os problemas de projeto da engenharia (por exemplo, Gehard Pahl e Wolfgang Beitz, Engineering Projeto (New York: Springer-Verlag, 1984); William Lewis e

36

Reinventando GeRenciamento de PRojetos

Andrew Samuel, Fundamentals of Engineering Projeto (New York: Prentice hall, 1989); e Eberhardt Rechtin, Systems Architecting, Englewood Cliffs, NJ: Prentice Hall, 1991). 7. Vrios estudos importantes caracterizaram ainda mais a natureza da inovao como realador ou destruidor da competncia (Philip W. Anderson e Michael L. Tushman, Technological Discontinuities and Dominant Project: A Cyclical Model of Technological Change, Administrative Science Quarterly 35, n 4 (1990): 604-633; e Clayton M. Christensen, The Innovators Dilemma, Boston: Harvard Business School Press, 1998), como central ou perifrico (Carliss Y.v Baldwin e Kim B. Clark, Design Rules: the Power of Modularity, Cambridge, MA: MIT Press, 2000), e como arquitetural e geracional (Rebecca M. Anderson e Kim B. Clark, Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Administrative Science Quarterly 35 (1990): 9-30; e Hubert Gatignon, Michael L. Tushman, Wendy Smith e Philip W. Anderson, A Structural Approach to Assessing Innovation: Construct Development of Innovation Locus, Type, and Characteristics, Management Science 48, n 90 (2002): 1103-1122. 8. Embora a teoria clssica tenha focado em organizaes sustentveis, dois fenmenos constrangedores na organizao moderna devem ser abordados: primeiramente, qualquer estrutura para distino de projetos deve refletir a natureza temporria dos projetos e as limitaes comuns de tempo que existem para completar uma tarefa. Segundo, a alta velocidade na qual as decises so tomadas e os ciclos de vida dos produtos e mercados encurtados, tambm fizeram com que o tempo fosse um fator inseparvel em qualquer investigao moderna na organizao. Kathleen M. Eisenhardt e Behna N. Tabrizi, Accelerating Adaptive Processes: Product Innovation in the Global Computer Industry, Administrative Science Quarterly 40 (1995): 84-110; e Shona L. Brown e Kathleen M. Eisenhardt, The Art of Continuous Change: Linking Complexity Theory and Time-paced Evolution in Relentlessly Shifting Organizations, Administrative ScienceQuarterly 42 (1997): 1-34. 9. Aaron J. Shenhar e Dov Dvir, Toward a Typological Theory of Project Management, Research Policy 25 (1996): 607-632; e Aaron J. Shenhar e Dov Dvir, How Projects Differ and What to Do About It, no Handbook of Managing Projects, Jeffrey Pinto e Peter Morris, editores (New York: Wiley, 2004). 10. Geoffrey C.Bowker e Susan Leigh Star, Sorting Things Out: Classification and Its Consequences (Cambridge, MA: MIT Press, 1999). 11. Barbara H. Kwasnik, The Role of Classification Structures in Reflecting and Building Theory, Proceedings of the 3rd ASIS SIG/CR Classification Research Workshop, Advances in Classification Research 3 (1992): 63; citao de George Rey, Concepts and Stereotypes, Cognition 15 (1983): 237-262.

notas dos aneXos

37

12. Kwasnik, The Role of Classification Structures, 63. 13. Elin K. Jacob, Classification and Categorization: Drawing the Line, Proceedings of the 3rd2nd ASIS SIG/CR Classification Research Workshop, Advances in Classification Research, Washington, DC (1991): vol. 2, 67-83. 14. Ibid.; e Howard Gardner, The Minds New Science: A History of the Cognitive Revolution (New York: Basic Books, 1987). 15. Jacob, Classification and Categorization, 78. 16. Ibid., 67. 17. A anlise da faceta envolve analisar um fenmeno em termos de aspectos fundamentais e ento sintetiz-lo em uma expresso til (Kawasnik, The Role of Classification Structures, 72). Esta abordagem atribuda a Rananathan (em Kwasnik, The Role of Classification Structures e em S. I. Star, Grounded Classification: Grounded Theory and Faceted Classification, em Proceedings of Information Systems and Quality Research Conference, IFIPS WG 8.2, Filadlfia, 1977). 18. Bowker e Star, Sorting Things Out, 231. 19. Ibid., 232. 20. Kwasnik, The Role of Classification Structures, 72. 21. Lynn Crawford, Brian Hobbs e Rodney Turner, Project Categorization Systems (Newtown Square, PA: Project Management Institute, 2004). 22. Michel Foucault, The Order of Things (NewYork: Random House, 1970), 147; cotao de Jeffrey Parsons e Yar Wand, Choosing Classes in Conceptual Modeling, Communications of the ACM 40, n 6 (1997): 7. 23. Bowker e Star, Sorting Things Out, 230. 24. Ibid., 267. 25. John H. Payne e Rodney J. Turner, Company-wide Project Management: The Planning and Control of Programmes of Projects of Different Types, International Journal of Project Management 17, n1 (1999): 55-60; e Rodney J. Turner, The Handbook of Project-based Management, 2a ed. (Londres: McGraw-Hill, 1999). 26. Shenhar, One Size Does Not Fit All Projects. Veja tambm Dvir et al., In Search of Project Classification; e Aaron J. Shenhar, Dov Dvir e Shlomo Alakaher, From a Single Discipline Product to a Multidisciplinary System: Adapting the Right Style to the Right Project, System Engineering 6, n 3 (2003): 123-124. 27. Eisenhardt e Tabrizi, Accelerating Adaptive Processes. 28. Shenhar, One Size Does Not Fit All Projects. Veja tambm Dvir et al., In Search of Project Classification.