EDUARDO BENEDITO LIMA DE SOUSA

ANLISE DA GESTO DE ESCOPO EM GESTO DE PROJETOS: UM ESTUDO DE CASO EM EMPRESA DO SETOR DE BENS DURVEIS

Trabalho de Formatura apresentado Escola Politcnica da Universidade de So Paulo para obteno do diploma de Engenheiro de Produo

So Paulo 2007

EDUARDO BENEDITO LIMA DE SOUSA

ANLISE DA GESTO DE ESCOPO EM GESTO DE PROJETOS: UM ESTUDO DE CASO EM EMPRESA DO SETOR DE BENS DURVEIS

Trabalho de Formatura apresentado Escola Politcnica da Universidade de So Paulo para obteno do diploma de Engenheiro de Produo

Orientadora: Prof. Dr. Marly Monteiro de Carvalho

So Paulo 2007

FICHA CATALOGRFICA

Dedico esse trabalho aos meus pais, a quem devo tudo.

AGRADECIMENTOS

professora Marly Monteiro de Carvalho, pela orientao dada para a realizao deste trabalho.

Aos meus pais, Vera e Antnio, que me apoiaram durante o perodo de graduao para que eu pudesse realizar o curso de Engenharia de Produo.

minha gerente, que permitiu que o presente trabalho fosse realizado na rea de gesto de projetos.

Aos meus colegas de trabalho, que forneceram as informaes que viabilizaram a realizao do trabalho.

Ao meu amigo Andr, pelos valiosos conselhos sobre gesto de escopo.

Escola Politcnica, por proporcionar uma excelente formao.

RESUMO

O presente trabalho consiste do estudo da gesto de escopo dos projetos de desenvolvimento de novas tecnologias em uma empresa do setor de bens durveis. So abordados os processos de gesto de escopo descritos pelo PMI (2004) e outros aspectos relacionados gesto de escopo, como a gesto de requisitos e o estudo dos stakeholders do projeto. Atravs de um estudo de caso, so diagnosticados os processos de gesto de escopo praticados na rea utilizada como objeto de estudo e, por fim, so feitas recomendaes empresa com o objetivo de melhorar o processo de gerenciamento de escopo.

ABSTRACT

This paper consists of studying the project scope management in technology development projects in a durable goods company. It is brought up procedures of scope management described by PMI (2004) and other aspects related with scope management such as requirement management and the study of project stakeholders. Through a case study, were found some scope management process in the field where it was studied. To conclude, recommendations are offered to the company in order to improve their scope management process.

SUMRIO

LISTA DE FIGURAS LISTA DE TABELAS

LISTA DE QUADROS 1 INTRODUO ...................................................................................................................13

1.2 A Empresa ......................................................................................................................13 1.3 O Estgio ........................................................................................................................13 1.4 Definio do objeto da pesquisa.....................................................................................14

1.4.1 O Problema..............................................................................................................14 1.4.2 Relevncia do tema..................................................................................................14 1.4.3 Objetivos do estudo .................................................................................................15

1.5 Estrutura do trabalho de formatura.................................................................................15

2 REVISO BIBLIOGRFICA ...........................................................................................17

2.1 Conceito de Projeto ........................................................................................................17 2.2 Conceito de Gesto de Projetos ......................................................................................17

2.2.1 Gerenciamento de integrao do projeto .................................................................17 2.2.2 Gerenciamento de tempo do projeto........................................................................18 2.2.3 Gerenciamento de custos do projeto........................................................................18 2.2.4 Gerenciamento da qualidade do projeto ..................................................................19 2.2.5 Gerenciamento de recursos humanos do projeto.....................................................19 2.2.6 Gerenciamento das comunicaes do projeto .........................................................19 2.2.7 Gerenciamento de riscos do projeto ........................................................................20 2.2.8 Gerenciamento de aquisies do projeto .................................................................20

2.3 Gesto de Escopo ...........................................................................................................20 2.3.1 Planejamento e definio do escopo........................................................................21 2.3.2 Criao da WBS ......................................................................................................22

2.3.2.1 A WBS e outras estruturas analticas ...............................................................23 2.3.2.2. O Processo de Decomposio..........................................................................25

2.3.3 Verificao e controle do escopo.............................................................................28 2.4 Gesto de Escopo e Tipos de Projetos............................................................................29

2.4.1 Definio dos termos hard e soft .............................................................................30 2.4.2 As dimenses hard e soft .........................................................................................32 2.4.3 O framework das dimenses hard e soft..................................................................34

2.5 Gesto de Escopo e Gesto de Requisitos ......................................................................35 2.5.1 O modelo de Kano...................................................................................................36 2.5.2 Quality Function Deployment (QFD) .....................................................................39

2.6 Gesto de Escopo e os Stakeholders do Projeto .............................................................41 2.6.1 Anlise dos stakeholders .........................................................................................45

2.7 Modelos de Maturidade e a Gesto de Escopo...............................................................48 2.7.1 Capability Maturity Model (CMM).........................................................................48 2.7.2 Project Management Maturity Model (PMMM).....................................................49

3 ABORDAGEM METODOLGICA .................................................................................51

3.1 Classificao dos projetos do Programa X .................................................................... 52 3.2 Seleo dos Projetos....................................................................................................... 54

3.2.1 Instrumentos de pesquisa e modelo de referncia................................................... 57

4 O ESTUDO DE CASO ....................................................................................................... 58

4.1. rea de gesto de projetos ............................................................................................ 58 4.2. Estrutura Organizacional do Programa ......................................................................... 59 4.3. Gesto de projetos no Programa X ............................................................................... 60 4.4 Gesto de Escopo no Programa X.................................................................................. 61 4.5 Classificao dos Projetos.............................................................................................. 65 4.6 Escolha dos Projetos a Serem Estudados....................................................................... 67 4.7 Anlise da Gesto de Escopo dos projetos escolhidos................................................... 69

4.7.1 Projeto A ................................................................................................................. 69 4.7.2 Projeto B ................................................................................................................. 75 4.7.3 Anlise Cruzada dos Projeto A e B......................................................................... 82 4.7.4 Anlise da Gesto de Escopo na organizao......................................................... 83

4.8 Sugestes de Melhoria ................................................................................................... 86

5 CONCLUSES E RECOMENDAES ......................................................................... 90

6 REFERNCIAS BIBLIOGRFICAS .............................................................................. 92

7 ANEXOS .............................................................................................................................. 95

LISTA DE FIGURAS

Figura 1.1 Objetivos primrios de projetos (Adaptada de Carvalho e Rabecnini Jr, 2005)..15 Figura 1.2 Estrutura do trabalho de formatura ..................................................................... .16 Figura 2.1 Principais processos para se estabelecer o planejamento.....................................25 Figura 2.2 WBS orientada a subsistemas (Adaptada de Globerson, 1994)...........................26 Figura 2.3 WBS com orientao geogrfica (Adaptada de Globerson, 1994) ......................26 Figura 2.4 WBS com orientao por funes (Adaptada de Globerson, 1994) ....................27 Figura 2.5 WBS com orientao por ciclo de vida (Adaptada de Globerson, 1994) ............27 Figura 2.6 WBS com orientao mista (Adaptada do PMI, 2004)........................................28 Figura 2.7 Inter-relao entre os atributos do paradigma hard (POLLACK, 2006) .............30 Figura 2.8 Inter-relao entre os atributos do paradigma soft (POLLACK, 2006)...............31 Figura 2.9 Framework das sete dimenses (Adaptada de Crawford e Pollac, 2004)............34 Figura 2.10 Processo do gerenciamento de integrao (Adaptada do PMI, 2004) ...............35 Figura 2.11 Aspectos funcionais e disfuncionais (Adaptada de Matzler e Hinterhuber, 1998)..................................................................................................................................................37 Figura 2.12 Casa da Qualidade (Adaptada de Carvalho e Rabechini Jr, 2005, e de Matzler e Hinterhuber, 1998) ...................................................................................................................41 Figura 2.13 Tipologia dos stakeholders (MITCHELL et al, 1997).......................................43 Figura 2.14 Mapa dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002)..............46 Figura 2.15 Nveis de maturidade do CMM (Adaptada de Carvalho e Rabechini Jr, 2005) 49 Figura 2.16 Project Management Maturity Model (Adaptada de Carvalho e Rabechini Jr, 2005).........................................................................................................................................50 Figura 4.1 Organograma geral da rea de planejamento da engenharia................................59 Figura 4.2 Estrutura organizacional da Empresa X.............................................................. .60 Figura 4.3 Estrutura organizacional do Programa X........................ .....................................61 Figura 4.4 Fases de desenvolvimento de projetos do Programa X .......................................62 Figura 4.5 Grfico hard/soft........................................ ..........................................................66 Figura 4.6 Fluxo dos processos de gesto de escopo no Projeto A..(Adaptada de Carvalho e Rabechini Jr, 2005)...................................................................................................................74 Figura 4.7 Fluxo dos processos da gesto de escopo no Projeto B (Adaptada de Carvalho e Rabechini Jr, 2005)...................................................................................................................79 Figura 4.8 WBS parcial do Projeto B .................... ...............................................................80 Figura 4.9 Resultados da pesquisa de maturidade da Empresa X (Adaptada de Vidal e Carvalho, 2007) ........................................................................................................................84 Figura 4.10 Resultados da pesquisa de maturidade no Programa X....... ..............................85 Figura 4.11 Fontes de Requisitos dos Projetos .....................................................................87

LISTA DE TABELAS

Tabela 2.1 Resultados da avaliao de Kano................................................................. .......39 Tabela 2.2 Anlise dos coeficientes................................. .................................................... .39 Tabela 3.1 Caracterizao dos Projetos........................................... ......................................55 Tabela 4.1 Classificao dos projetos: hard e soft............................................... .................66 Tabela 4.2 Dados para a realizao da escolha dos projetos................................................ .67 Tabela 4.3 Escolha dos projetos ............................................................................................68

LISTA DE QUADROS

Quadro 2.1 Os paradigmas hard e soft na teoria e na prtica (Adaptado de Pollack, 2006).31 Quadro 2.2 Requisitos dos clientes para esqui (Adaptado de Matzler e Hinterhuber, 1998)................................................................................................................................................. .37 Quadro 2.3 Avaliao de Kano (Adaptado de Matler e Hinterhuber, 1998).........................38 Quadro 2.4 Identificao dos stakeholders especficos (Adaptada de Elias, Cavana e Jackson, 2002) ..........................................................................................................................46 Quadro 2.5 Interesses dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002) .......47 Quadro 2.6 Interesse vesus poder do stakeholders (Adaptada de Elias, Cavana e Jackson, 2002)........................................................................................................................................ .47 Quadro 2.7 Anlise da dinmica dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002).........................................................................................................................................48 Quadro 3.1 Modelo de questionrio adotado para classificao dos projetos (Adaptada de Crawford e Pollack, 2004)........................................................................................................53 Quadro 3.2 Critrios de avaliao para a seleo dos projetos .............................................55 Quadro 3.3 Roteiro de entrevistas com os Gerentes de Projeto ........................................... .56 Quadro 4.1 Classificao dos impactos dos projetos ............................................................72 Quadro 4.2 Avaliao dos impactos das mudanas no Projeto A .........................................72 Quadro 4.3 Avaliao da gravidade prazo x custo no Projeto A...........................................73 Quadro 4.4 Avaliao dos impactos das mudanas no Projeto B ........................................ .77 Quadro 4.5 Avaliao da gravidade prazo x custo no Projeto B...........................................78 Quadro 4.6 Anlise comparativa dos projetos A e B ............................................................82 Quadro 4.7 Grupos de stakeholders ......................................................................................89

13

1 INTRODUO

Neste captulo, ser feita uma breve descrio da empresa utilizada como objeto de estudo, uma descrio do estgio, a definio do objeto de pesquisa e, por fim, ser apresentada a estrutura do trabalho.

1.2 A Empresa

Trabalho foi conduzido em uma empresa de grande porte do setor de bens durveis. Infelizmente, devido poltica de proteo de informao da empresa, no ser possvel identificar a empresa e nem fornecer dados detalhados sobre os produtos e tecnologias. Nem mesmo o setor em que atua ser possvel caracterizar, pois seria muito fcil identific-la, ento se categorizou de maneira macro como bens de consumo durvel. Dessa forma, a empresa ser doravante denominada Empresa X.

Acredita-se, porm, que para os objetivos pretendidos com o trabalho, o fato da empresa no ser identificada, no causar grandes impactos na anlise realizada.

1.3 O Estgio

O estgio teve seu incio em maro de 2007 numa rea relativamente nova na empresa. A rea denominada Planejamento da Engenharia e, tem como objetivo, gerar e publicar anlises e indicadores de desempenho, dos recursos e de estabilidade de projetos.

A rea dividida em equipes alocadas nos diversos programas da Empresa X. O autor deste trabalho realiza seu estgio em uma das equipes de planejamento que trabalha junto ao programa que cuida do desenvolvimento de novas tecnologias da Empresa X. O programa citado ser denominado Programa X.

As atividades realizadas no estgio so:

Realizar a coleta de dados para a execuo do relatrio de avaliao mensal do andamento do projeto;

Elaborar o relatrio mensal de anlise do projeto; Propor melhorias na metodologia de gesto de projetos e anlise de dados; Realizar estudo sobre gesto de escopo para a confeco do TF e melhoria dos

processos da empresa.

14

1.4 Definio do objeto da pesquisa

1.4.1 O Problema

Durante as primeiras semanas de estgio, o autor desse trabalho percebeu que a linha base de custo (baseline) dos projetos do Programa X, em geral, mudava constantemente, o que dificultava algumas anlises realizadas. Em conversa com funcionrios experientes da Empresa X, constatou-se que uma possvel causa para esse problema era a alterao constante do escopo dos projetos. Esse problema, segundo os funcionrios, no ocorria somente no Programa X, mas era detectado em outros programas da Empresa X.

1.4.2 Relevncia do tema

Dado o cenrio competitivo atual, em que aes rpidas e coerentes so exigidas, o gerenciamento de projetos tem se mostrado atraente por ser uma metodologia consagrada em vrias empresas, fornecendo elementos para viabilizar o sucesso dos projetos.

Dentro do gerenciamento de projetos, a gesto de escopo de fundamental importncia para o sucesso do projeto. A definio e o gerenciamento do escopo do projeto influenciam o sucesso do projeto (PMI 2004, p. 107).

Segundo Carvalho e Rabechini Jr (2005), Os objetivos primrios do projeto so: escopo, prazo e custo. O sucesso do projeto depende do equilbrio dessa trade, como ilustrado na Figura 1.1.

15

Custo

Escopo

Prazo

Bom Gerenciamento

Projeto acima do limite orado, entregue em

atraso e fora do escopo

Figura 1.1 Objetivos primrios de projetos (Adaptada de Carvalho e Rabechini Jr, 2005)

1.4.3 Objetivos do estudo

O presente trabalho tem como objetivo a realizao de um estudo de caso, abordando o tema de gesto de escopo no Programa X da Empresa X. Pretende-se atravs do estudo de caso investigar as causas dos possveis problemas de gesto de escopo no programa e a proposio de solues. Como objetivos especficos destacam-se:

Fazer uma reviso da literatura sobre gesto de escopo e gesto de projetos Estudar o modo como realizada a gesto de escopo no Programa X

Identificar possveis problemas de gesto de escopo no Programa X

Identificar as causas dos provveis problemas

Propor solues para esses problemas No est no escopo desse trabalho a aplicao das solues propostas. Devido s

restries de prazo, a aplicao das solues propostas seria invivel.

1.5 Estrutura do trabalho de formatura

Esse trabalho de formatura constitudo de 5 captulos. Esse captulo introdutrio apresenta o trabalho, seguido do Captulo 2, que corresponde reviso bibliogrfica, na qual so abordados conceitos relacionados a gerenciamento de projetos e em especial gesto de escopo. Na seqncia, o Captulo 3 apresenta a abordagem metodolgica utilizada na pesquisa. O Captulo 4 apresenta a pesquisa de campo, com a exposio e anlise das

16

informaes levantadas atravs de documentos e entrevistas. Finalmente, o Captulo 5 traz as concluses e recomendaes, conforme ilustra a Figura 1.1.

Figura 1.2 Estrutura do trabalho de formatura

Captulo 2 Reviso da Literatura

Captulo 5 - Concluses e Recomendaes

Captulo 4 Estudo de Caso

Anlise dos Resultados Descrio do Caso Sugestes de Melhoria

Captulo 3 Abordagem Metodolgica

Gesto de Projeto Gesto de Escopo

17

2 REVISO BIBLIOGRFICA

Neste captulo so apresentados os principais conceitos relacionados Gesto de Projetos, com nfase no gerenciamento do escopo.

2.1 Conceito de Projeto

Segundo o PMI (2004) um projeto um empreendimento temporrio feito para criar um produto, servio ou resultado nico. O projeto , portanto, um vetor de mudanas nas companhias, mercados e sociedade (CARDINAL; MARLE, 2006, p. 226). Assim, o projeto deve ter um incio e um trmino bem definidos e deve produzir um resultado com caractersticas nunca vistas, tornando-o nico.

Quando se pensa em um projeto como sendo um empreendimento temporrio, no se deve confundir com um empreendimento de curta durao, e sim, com uma durao finita. Alm disso, aps o trmino do projeto, seus resultados podem ter um longo tempo de durao.

2.2 Conceito de Gesto de Projetos

O gerenciamento de projetos consiste em todos os processos, mtodos, ferramentas e conceitos que so utilizados para conduzir o projeto desde seu incio at o seu fim, entregando os resultados e atingindo os objetivos do projeto.

As tcnicas de gerenciamento de projetos podem ser aplicadas em projetos de diversas empresas em praticamente todas as reas. Um bom gerenciamento pode melhorar o desempenho de um projeto, fazendo com que tenha mais chances de ser bem sucedido.

De acordo com o PMI (2004), so nove as reas de conhecimento do gerenciamento de projetos. Apresenta-se a seguir uma breve descrio de cada uma das reas, deixando a gesto de escopo, foco deste trabalho, para uma seo a parte.

2.2.1 Gerenciamento de integrao do projeto

A integrao dos processos de fundamental importncia para a conduo do projeto. De acordo com o PMI (2004), esta rea de conhecimento engloba os processos para identificar, definir, combinar, unificar e coordenar os processos referentes ao gerenciamento de projetos. Alm disso, a gesto da integrao fornece documentos para o controle das

18

alteraes em um projeto. Os processos de gerenciamento de integrao definidos pelo PMI so:

Desenvolver o termo de abertura do projeto Desenvolver a declarao de escopo preliminar do projeto Desenvolver o plano de gerenciamento do projeto Orientar e gerenciar a execuo do projeto Monitorar e controlar o trabalho do projeto Controle integrado de mudanas

Encerrar o projeto

2.2.2 Gerenciamento de tempo do projeto

O objetivo do gerenciamento de tempo fazer com que o projeto seja concludo no prazo determinado. Os processos de gerenciamento de tempo, segundo o PMI (2004), so:

Definio das atividades

Sequenciamento das atividades

Estimativa dos recursos das atividades

Estimativa de durao das atividades

Desenvolvimento do cronograma

Controle do cronograma

2.2.3 Gerenciamento de custos do projeto

O gerenciamento de custos inclui os processos que objetivam assegurar que o projeto termine dentro dos custos programados. Os processos envolvidos no gerenciamento de custos so:

Estimativa de custos

Oramentao

Controle de custos

19

2.2.4 Gerenciamento da qualidade do projeto

O gerenciamento da qualidade tem como objetivo assegurar que o projeto satisfaa os clientes em sua concluso. Segundo o PMI (2004) os processos de gerenciamento da qualidade so:

Planejamento da qualidade Realizar a garantia da qualidade

Realizar o controle da qualidade

O gerenciamento dos requisitos, que est ligado nesse tpico, ser tratado em um captulo a parte.

2.2.5 Gerenciamento de recursos humanos do projeto

Segundo o PMI (2004, p. 199), o gerenciamento de recursos humanos do projeto inclui os processos que organizam e gerenciam a equipe do projeto. Os processos de gerenciamento de recursos humanos apresentados pelo PMI (2004) so:

Planejamento de recursos humanos Contratar ou mobilizar a equipe de projeto Desenvolver a equipe do projeto Gerenciar a equipe do projeto

2.2.6 Gerenciamento das comunicaes do projeto

O gerenciamento das comunicaes do projeto tem como objetivo fornecer informaes para que a comunicao ocorra de forma adequada, atravs dos seguintes processos:

Planejamento das comunicaes Distribuio das informaes

Relatrio de desempenho

Gerenciar as partes interessadas

20

2.2.7 Gerenciamento de riscos do projeto

Tem como objetivo diminuir a probabilidade e o impacto de eventos negativos e aumentar a probabilidade e o impacto de eventos positivos. Os processos abordados pelo PMI (2004) so:

Planejamento e gerenciamento dos riscos Identificao de riscos

Analise qualitativa dos riscos

Analise quantitativa dos riscos

Planejamento de respostas a riscos Monitoramento e controle de riscos

2.2.8 Gerenciamento de aquisies do projeto

O objetivo do gerenciamento de aquisies a aquisio de bens e servios de terceiros. Os processos utilizados so:

Planejar compras e aquisies Planejar contrataes Solicitar respostas de fornecedores

Selecionar fornecedores

Administrao de contrato

Encerramento do contrato

2.3 Gesto de Escopo

Segundo Carvalho e Rabechini Jr (2005) o escopo do projeto engloba o trabalho a ser realizado para a concluso do projeto. Os autores destacam ainda que a gesto do escopo pode ser dividida em: escopo do projeto e escopo do produto. Neste trabalho uma das questes mais crticas o gerenciamento do escopo do produto, pois a Empresa X produz sistemas complexos.

A gesto de escopo rene cinco processos necessrios para que todo o trabalho necessrio para a concluso do projeto seja realizado: planejamento do escopo, definio do escopo, criao da WBS, verificao do escopo e controle do escopo (PMI, 2004).

21

2.3.1 Planejamento e definio do escopo

A declarao do escopo do projeto, segundo Carvalho e Rabechini Jr (2005) um processo que visa elaborar e documentar, progressivamente, todo escopo do projeto para atingir seus objetivos. De acordo com o PMI (2004), ela deve conter as seguintes informaes:

Objetivos do projeto Incluem os critrios de sucesso do projeto. Alm disso podem incluir as metas de custo, cronograma e qualidade

Descrio do escopo do produto Deve descrever as caractersticas do produto, servio ou resultado do projeto.

Requisitos do projeto Dever incluir os requisitos que as entregas do projeto devero atender a fim de satisfazer um contrato, norma ou especificao ou outro documento formal.

Limites do projeto Declara o que est incluso no projeto e tambm o que no est incluso para que uma parte interessada no pense que um determinado resultado esteja includo no projeto quando na verdade no est.

Entregas do projeto As entregas englobam as entregas associadas ao produto ou resultado final e as entregas auxiliares como documentao e relatrios.

Critrios de aceitao do produto Define os processos e critrios para aceitar o produto terminado

Restries do projeto Descreve as restries associadas ao escopo do projeto que limitam as opes da equipe, como por exemplo, as clusulas contratuais.

Premissas do projeto Descreve as premissas que impactam no escopo do projeto e o impacto potencial dessas premissas

Organizao inicial do projeto So listados os membros da equipe do projeto e as partes interessadas

Riscos iniciais Identifica os riscos conhecidos

Marcos do cronograma Marcos ou datas impostas no cronograma, identificados pela organizao executora ou pelo cliente.

Limitao de fundos Limitao de recursos financeiros ou imposta em prazos.

Estimativa de custos Indica o custo total esperado do projeto. Requisitos do gerenciamento de configurao do projeto Descreve o nvel de

gerenciamento de configurao e mudana do projeto.

22

Especificaes do projeto Identifica os documentos de especificao com os quais o projeto deve estar de acordo.

Requisitos de aprovao Identifica os requisitos de aprovao do projeto.

Uma vez realizada a declarao do escopo do projeto, faz se necessrio o detalhamento do escopo. Esse detalhamento obtido atravs da decomposio das entregas (deliverables) do projeto. A decomposio expressa pela Estrutura Analtica do Projeto (EAP), do ingls, Work Breakdown Structure (WBS).

2.3.2 Criao da WBS

Segundo o PMI (2004), a WBS a decomposio do trabalho do projeto a fim de atingir os objetivos do projeto, criando as entregas necessrias. O trabalho do projeto subdividido em partes menores e mais facilmente gerenciveis, sendo seus elementos de mais baixo nvel denominados pacotes de trabalho.

A correta criao da WBS de fundamental importncia para o planejamento do projeto. Para Cleland e Ireland (2002), a WBS a considerao mais bsica no planejamento do projeto. A WBS a espinha dorsal do prprio planejamento, execuo e controle de um projeto (BACHY; HAMERI, 1997, p. 211).

De acordo com Lamers (2002), atravs da WBS tm-se meios para integrar a trade: escopo, custo e tempo. Utilizando-se da WBS, podem-se estabelecer relaes mais claras entre as entidades da trade, tendo como base que essas entidades compartilham os pacotes de trabalho como um atributo comum.

Consequentemente, a WBS uma pea importante para o sucesso do projeto. O uso correto da WBS contribui significativamente para a probabilidade de sucesso de o projeto ser concludo (GLOBERSON, 1994, p. 166).

Apesar da grande importncia da WBS, diversos autores afirmam que o assunto no tratado de forma satisfatria pela literatura (TURNER, 2000; BACHY; HAMERI, 1997; LAMERS, 2002).

23

2.3.2.1 A WBS e outras estruturas analticas

Algumas estruturas analticas tm relao direta com a WBS. Entre elas podem-se citar a Product Breakdown Structure (PBS), a Assembly Breakdown Structure (ABS) e a Organizational Breakdown Structure (OBS). Segundo a viso de Bachy e Hameri (1997), essas estruturas podem ser difinidas como:

Product Breakdown Structure (PBS) a decomposio do produto em suas partes elementares atravs de uma estrutura em rvore, descrevendo a configurao completa do produto. Alm disso, a PBS deve conter instrues de manufatura em cada nvel da estrutura e descrio tcnica das partes elementares.

Assembly Breakdown Structure (ABS) Mostra a sequncia de montagem dos componentes.

Organizational Breakdown Structure (OBS) Provm uma viso das pessoas e suas funes dentro de um projeto

Alguns autores realizaram estudos sobre o modo como a WBS constituda e sua interao com essas estruturas (BACHY; HAMERI, 1997; LAMERS, 2002; TURNER, 2000).

Os principais pontos abordados por Turner (2000) so: A WBS uma matriz formada pela PBSxOBS. Primeiramente deve-se construir a

PBS, que ir gerar todos os componentes que devem ser construdos. Aps isso, construir a OBS, que dar a viso da capacidade de realizar as entregas da PBS. Essas duas estruturas devero ter o mesmo nmero de nveis e cada nvel um elemento da matriz formada pelo PBSxOBS, definir o trabalho a ser feito associado habilidade de realiz-lo.

No se consegue gerenciar o trabalho de um projeto e sim suas entregas (PBS) e os recursos necessrios para realiz-las (OBS). O autor faz uma comparao com a manufatura em batch, no sentido de que se deve definir a lista de materiais e as mquinas necessrias para fabricar os componentes dessa lista. Assim, ele compara o trabalho operao da mquina. Ele afirma que o os planejadores do produto no esto interessados no trabalho, e sim no processo produtivo.

As pessoas interpretam erroneamente a palavra Work Breakdown Structure. O autor afirma que as pessoas tomam como ponto de partida que a WBS o trabalho

24

que deve ser realizado, acarretando em trabalho desnecessrio durante a execuo do projeto. Para ele, deve-se gerenciar o projeto voltado para a execuo de deliverables.

Lamers (2002), apresenta um ponto de vista que difere em vrios aspectos dos de Turner (2000). Entre os pontos divergentes, pode-se destacar:

A WBS no uma matriz formada pela PBSxOBS. A WBS uma estrutura por si s, e construda depois da PBS e sem muita relao com a OBS. Segundo o autor, primeiro deve-se definir o produto, depois os processos para fabric-lo, em seguida o controle desses processos e por ltimo a estrutura organizacional para realizar os processos e controla-los.

O trabalho humano deve ser gerenciado. Gerenciar pessoas complicado, pois so difceis de se controlar. Portanto, deve-se gerenciar o trabalho das pessoas.

A palavra WBS no interpretada corretamente. As pessoas tendem se voltar mais para o produto do que para o processo em si. Alm disso, os verbos no so usados onde deveriam, ou seja, nos pacotes de trabalho.

Bachy e Hameri (1997) tm uma viso semelhante em alguns pontos de Lamers (2002). Eles Apresentam uma seqncia lgica de definio das estruturas PBS, ABS, WBS e OBS (figura 2.1) para projetos de larga escala e como essas estruturas daro origem fase de planejamento do projeto. Abaixo, explica-se resumidamente essa seqncia:

1. Primeiramente deve-se construir a PBS, que definir os componentes do produto. 2. De posse da PBS, deve-se construir a ABS, que fornecer a seqncia de

montagem.

3. Uma vez que os nveis mais altos da PBS e da ABS esto prontos (elas no precisam estar detalhadas), deve-se pensar nos processos para a construo da WBS.

4. Por fim, a OBS definida da WBS. A fase de planejamento pode comear com a WBS definida, mas no pode ser completada at que a OBS esteja pronta.

25

Figura 2.1 Principais processos para se estabelecer o planejamento

2.3.2.2. O Processo de Decomposio

O PMI (2004, p. 114) define decomposio como [...] a subdiviso das entregas do projeto em componentes menores e mais facilmente gerenciveis, at que o trabalho e as entregas estejam definidos at o nvel de pacote de trabalho.

Dependendo do tamanho e da complexidade do projeto, o nvel de detalhe dos pacotes de trabalho pode variar. Alm disso, poder haver variao de nveis dentro de uma mesma WBS, ou seja, para algumas entregas, o trabalho pode exigir mis nveis de decomposio.

Entretanto, Bachy e Hameri (1997) advertem para o perigo de um detalhamento excessivo ou pobre demais. Um detalhamento excessivo da WBS poder levar a um trabalho administrativo extra e um detalhamento pobre, por sua vez, poder conduzir a um controle pobre dos custos e do progresso do projeto. Muitos nveis de WBS enchem a organizao de muita informao e complicam o processo de gerenciamento do produto. Poucos nveis geram dificuldades de comunicao e uma coordenao pobre entre as unidades organizacionais (GLOBERSON, 1994, p. 168).

A estruturao da WBS pode assumir vrias formas. O PMI (2004) e Globerson (1994) apresentam alguns modelos de construo da WBS, caracterizados pelo primeiro nvel de decomposio, ou seja, o segundo nvel da WBS. Assim, essas decomposies podem ser orientadas a subsistemas, geografia, funes, fases do ciclo de vida ou vrias abordagens. Exemplos dessas estruturas so apresentados nas figuras 2.2 a 2.6, cada uma com uma orientao especfica.

PBS

ABS

WBS Fase de Planejamento

OBS

26

Figura 2.2 WBS orientada a subsistemas (Adaptada de Globerson, 1994)

Figura 2.3 WBS com orientao geogrfica (Adaptada de Globerson, 1994)

27

Figura 2.4 WBS com orientao por funes (Adaptada de Globerson, 1994)

Figura 2.5 WBS com orientao por ciclo de vida (Adaptada de Globerson, 1994)

28

Figura 2.6 WBS com orientao mista (Adaptada do PMI, 2004)

Por fim deve-se avaliar se a decomposio est correta, verificando se os nveis mais baixos so suficientes para completar as tarefas dos nveis superiores.

2.3.3 Verificao e controle do escopo

A verificao e o controle do escopo so feitos atravs de revises que so planejadas de acordo com as necessidades de verificao do escopo. Segundo Carvalho & Rabechini Jr (2005), as revises podem ser de trs tipos:

Peridicas: Previstas para serem realizadas em determinados perodos do projeto. Fase: Feitas aps a realizao de uma determinada fase do projeto com o objetivo

de aprovar a fase anterior e iniciar a prxima fase.

Espordicas: Revises pontuais onde so apresentados os avanos do projeto pelo gerente e sua equipe.

As revises servem para o gerente do projeto saber como est o desenvolvimento do projeto em relao ao seu escopo. Se o escopo est sendo atingido dentro do planejado, no h necessidade de mudanas no desenvolvimento. Se houver necessidade de mudanas no escopo, o gerente dever fazer um novo planejamento em que a WBS dever ser revista e dever ser feita uma nova avaliao dos impactos de prazo e custo.

29

O sistema de controle de mudanas estabelecido pelo gerente do projeto, geralmente em projetos de grande porte em que mudanas de escopo ocorrem mais frequentemente. Segundo o PMI (2004), o sistema de controle de mudanas define os procedimentos para efetuar mudanas no escopo do projeto.

De acordo com Carvalho e Rabechini (2005), a principal entrada para o sistema de controle de mudanas a solicitao de mudanas. Esse documento deve apresentar em seu contedo dados das mudanas e os impactos que elas podem causar no projeto.

O PMI (2004) define como as sadas do controle do escopo: Atualizao da declarao de escopo do projeto Com a mudana no escopo do

projeto, a declarao de escopo deve ser revista, se tornando a nova linha base do projeto.

Atualizao da WBS A WBS dever ser revista, refletindo as mudanas aprovadas.

Mudanas solicitadas Descrio das mudanas solicitadas

Aes corretivas recomendadas Aes recomendadas para que o desempenho futuro do projeto fique de acordo com a declarao de escopo do projeto

Atualizaes dos ativos de processos organizacionais Documentao das causas das variaes, as razes que motivaram as aes corretivas escolhidas e outros tipos de lies aprendidas.

Atualizao do plano de gerenciamento do projeto atualizao da linha de base dos custos e da linha de base do cronograma do projeto.

2.4 Gesto de Escopo e Tipos de Projetos

Levando-se em conta que o gerenciamento do escopo fortemente influenciado pelas caractersticas do projeto, conveniente caracterizar os tipos de projeto em termos das incertezas envolvidas (ATKINSON; CRAWFORD; WARD, 2006). Nessa seo ser apresentada a tipologia que caracteriza os tipos de projeto em hard e soft.

30

2.4.1 Definio dos termos hard e soft

Segundo Crawford e Pollack (2004) os termos hard e soft esto entrando na linguagem do gerenciamento de projeto, mas esses termos so comumente usados de maneira vaga. O termo hard geralmente associado a abordagens objetivas e realistas, j o termo soft associado a abordagens subjetivas.

Atkinson, Crawford e Ward (2006) citam que na prtica, os termos hard e soft esto em lados opostos de um espectro. O termo hard associado a projetos grandes, autnomos e com objetivos e produtos finais bem definidos; o termo soft associado a mltiplos projetos, que no so pr-definidos, mas so abertos negociao durante seu ciclo de vida.

As Figuras 2.7 e 2.8 mostram a inter-relao entre os atributos dos paradigmas hard e soft, ajudando na compreenso das idias apresentadas.

Figura 2.7 Inter-relao entre os atributos do paradigma hard (POLLACK, 2006)

31

Figura 2.8 Inter-relao entre os atributos do paradigma soft (POLLACK, 2006)

Segundo Pollack (2006), as diferenas entre os paradigmas hard e soft tm mltiplas implicaes nos nveis tericos e prticos e, sendo assim, deve-se examinar ambos os nveis para entender as influncias desses paradigmas no gerenciamento de projetos. O Quadro 2.9 relaciona os paradigmas hard e soft com a teoria e a prtica.

hard soft

teoria Positivista/realista Interpretativa

prtica Resoluo de problemasEstruturao de

problemas

Quadro 2.1 Os paradigmas hard e soft na teoria e na prtica (Adaptado de Pollack, 2006)

32

2.4.2 As dimenses hard e soft

Crawford e Pollack(2004) identificam sete dimenses para a anlise dos aspectos hard e soft de um projeto: clareza de meta/objetivo, tangibilidade de meta/objetivo, medidas de sucesso, permeabilidade do projeto, nmero de opes de soluo, grau de participao e expectativas do stakeholder. Essas dimenses podem ser definidas da seguinte forma:

Clareza de meta/objetivo

Os projetos com caractersticas soft no possuem um objetivo bem definido e as especificaes so passveis de ambigidade na interpretao. Atkinson, Crawford e Ward (2006), afirmam que as metas surgem de negociaes e so construdas ao longo do projeto. J em projetos que possuem caractersticas hard, os objetivos costumam ser definidos no comeo e, alm disso, so mais claros e bem definidos.

Tangibilidade de meta/objetivo

De acordo com Crawford e Pollack (2004), existe uma forte ligao entre o grau de definio dos objetivos e sua tangibilidade. Os autores citam como exemplo os setores de construo e engenharia, em que os objetivos so tangveis e, portanto, mais facilmente definidos. J os projetos com objetivos intangveis, como um projeto de mudana organizacional, so mais difceis de serem definidos. Entretanto, a ligao entre o grau de definio e os objetivos nem sempre existe. Crawford e Pollack (2004) citam como exemplo um treinamento, em que os objetivos e metas so definidos, mas no existe um produto tangvel.

Medidas de Sucesso

As medidas podem ser classificadas em qualitativas e quantitativas. As medidas qualitativas esto associadas ao paradigma soft, provendo uma anlise mais subjetiva do problema. J as medidas quantitativas, esto associadas ao paradigma hard, tendo uma abordagem objetiva do problema. Para Atkinson, Crawford e Ward (2006), medir o sucesso dos projetos mais difcil em projetos com produtos intangveis.

33

McElroy (1996) afirma que mais fcil medir o sucesso dos projetos do tipo hard do que os projetos soft. O julgamento a respeito do sucesso dos projetos mais difcil de ser feito em projetos com produtos intangveis (ATKINSON; CRAWFORD; WARD, 2006, p. 692).

Permeabilidade do projeto

A permeabilidade do projeto, segundo Crawford e Pollack (2004), tem relao com o grau com que os objetivos, os processos e os resultados do projeto so afetados por influncias foras do controle do projeto.

Se pensar no projeto como um sistema, a linha imaginria entre as influncias internas e externas ao controle do projeto determina a fronteira do projeto. Atkinson, Crawford e Ward (2006) afirmam que projetos que possuem uma fronteira bem definida, provendo um grau de isolamento do ambiente, permitem o uso de ferramentas e tcnicas tradicionais do gerenciamento de projetos. J em projetos com fronteiras mais permeveis, ou seja, que assumem caractersticas soft, o uso dessas ferramentas mais difcil. Alm disso, em projetos com caractersticas soft, o escopo mais difcil de ser definido.

Nmero de opes de soluo

Em projetos com caractersticas soft, as solues so desenvolvidas atravs de negociao e debate entre mltiplos stakeholders existe mltipla viso de mundo. J para os projetos hard, h um foco na eficincia no h discusso das idias.

Grau de participao

Mtodos hard tendem a ser menos participativos medida que as pessoas sabem o seu papel e as tarefas a serem executadas.

Mtodos soft so mais colaborativos e participativos e as pessoas so encorajadas a ultrapassar as fronteiras do trabalho.

Expectativa do Stakeholder

34

Segundo Crawford e Pollack(2004), ser atento s diferenas das expectativas dos stakeholders pode ser vital para o sucesso do projeto.

Em projetos com caractersticas hard as relaes so vistas de maneira mais lgica e clara. As pessoas so vistas como parte de um sistema em que suas aes so pr-determinadas.

Em projetos soft existe uma grande interao entre os stakeholders. As pessoas so vistas como parte de um sistema cultural, com valores e expectativas individuais.

2.4.3 O framework das dimenses hard e soft

O framework definido por Crawford e Pollack(2004), apresentado logo abaixo (fig. 2.10).

Cada uma das sete dimenses apresenta uma escala variando de 0 at 100. O valor 0 indica o mximo da caracterstica hard e o valor 100 o mximo da caracterstica soft.

0 100

0 100

0 100

0 100

0 100

0 100

0 100

Metas/Objetivos ambiguamente definidos

Artefato fsicoTangibilidade do Objetivo

Conceito abstrato

Claridade do ObjetivoMetas/Objetivos claramente

definidos

Somente medidas quantitativas

Medidas de SucessoSomente medidas

qualitativas

No sujeito influncias externas

Permeabilidade do ProjetoAltamente sujeito influncias externas

Valorizao da tecnica, performance e eficincia, gerenciada por controle

Expectativas dos Stakeholders Valoriza o relacionamento cultura e significado,

gerenciado por negociao

Refinamento de uma soluo nica

Nmero de Opes de SoluoExplorao de muitas alternativas de soluo

Participao mais rgida/Sem participao dos

stakeholders

Grau de Participao Participao mais liberal/ Alto envolvimento dos

Stakeholders

Figura 2.9 framework das sete dimenses (Adaptada de Crawford e Pollack, 2004)

35

2.5 Gesto de Escopo e Gesto de Requisitos

Conforme comentado anteriormente, esse trabalho tem especial ateno e aspectos relacionados ao escopo do produto, que na literatura tambm abordado em gesto de requisitos do projeto.

Segundo Carr (2000), os requisitos so descries de propriedades, atributos ou servios que so necessrios em um produto para o cumprimento das metas do sistema. Entretanto, a determinao dos requisitos deve apresentar uma necessidade, mas no especificar uma soluo de design.

De acordo com o PMI (2004), no termo de abertura do projeto devem constar, entre outros, os requisitos que satisfazem as necessidades dos clientes, patrocinador e outras partes. Existe uma ligao entre o termo de abertura do projeto e a definio do escopo do projeto (figura 2.10)

Figura 2.10 Processo do gerenciamento de integrao (Adaptada do PMI, 2004)

Uma vez que os requisitos so entradas para a definio do escopo do projeto, e que, mudanas nesses requisitos durante o ciclo de vida do projeto podem acarretar mudanas no escopo, percebe-se a real importncia da definio satisfatria dos requisitos.

Desenvolver o termo de abertura do projeto

Cliente ou patrocinador do projeto

Desenvolver a declarao preliminar do escopo do projeto

Definio do escopo

36

2.5.1 O modelo de Kano

Matzler e Hinterhuber (1998) em seus estudos, apresentaram uma abordagem interessante do modelo de Kano. Os autores propuseram uma metodologia para investigar as necessidades declaradas e no declaradas dos clientes e enquadra-las em diferentes categorias que, por sua vez, tm diferentes impactos na satisfao do cliente. Kano (1984) apud Matzler e Hinterhuber (1998), classifica os requisitos do produto em trs tipos:

Requisitos Obrigatrios Se esses requisitos no forem satisfeitos, o cliente ficar muito insatisfeito. Entretanto, uma vez que o cliente tem esses requisitos como

certos, o atendimento destes no aumentar a sua satisfao.

Requisitos Unidimensionais O nvel de satisfao do cliente proporcional ao nvel de atendimento do requisito. medida que o requisito atendido de forma mais completa, a satisfao do cliente aumenta.

Requisitos Encantamento Esses requisitos no so explicitados e nem esperados pelos clientes. Atender a esses requisitos significa uma satisfao mais que proporcional do cliente. J o no atendimento, no provoca um sentimento de insatisfao no cliente.

Matzler e Hinterhuber (1998) mostram como construir o questionrio baseado nas idias de Kano, utilizando como exemplo um estudo de caso da indstria de esqui, seguindo 4 passos, conforme segue:

Passo 1: Identificao dos Requisitos

O ponto de partida so os requisitos do produto para a construo do questionrio. O levantamento dos requisitos pode ser feito atravs de entrevistas individuais. Esse tipo de entrevista pode ser eficaz para a identificao de requisitos visveis do produto, mas normalmente no suficiente para identificar potenciais novos requisitos, j que no so esperados pelos clientes. Para um melhor levantamento desses requisitos escondidos, deve-se estudar detalhadamente o ambiente em que o produto est inserido, os problemas a serem solucionados, as condies de aplicao, etc (ver exemplo no Quadro 2.1)

37

Boa aderncia das bordas em pistas difceisGrande facilidade de manobraEsqui muito leveDispositivo anti-roubo integradoServio de disponibilizao de informaes regulares com dicas sobre os esquis

Quadro 2.2 Requisitos dos clientes para esqui (Adaptado de Matzler e Hinterhuber, 1998)

Passo 2: Construo do questionrio de Kano

Para cada caracterstica do produto, formula-se um par de questes e, para cada uma das duas questes, o cliente tem cinco opes de resposta. A primeira questo diz respeito a como a cliente se sente se o produto tiver a caracterstica, sendo denominada forma funcional da questo. A segunda, diz respeito a como ele se sente se o produto no tiver a caracterstica, sendo denominada forma disfuncional da questo.

Forma funcional da questo

Eu gosto dissoIsso deve ser assimSou neutroEu posso conviver com isso Eu no gosto disso

Eu gosto dissoIsso deve ser assimSou neutroEu posso conviver com isso Eu no gosto disso

Forma disfuncional da questo

Se as bordas do seu esqui aderem bem em uma pista difcil, como voc se sente?

Se as bordas do seu esqui no aderem bem em uma pista difcil, como voc se sente?

Figura 2.11 Aspectos funcionais e disfuncionais (Adaptada de Matzler e Hinterhuber 1998)

Aps a formulao das questes, deve-se combinar as duas respostas na tabela de anlise de Kano. O Quadro 2.2 apresenta as categorias A, M, O, I, Q e R, que significam:

Categoria A Requisitos Encantamento

Categoria M Requisitos Obrigatrios

Categoria O Requisitos Unidimensionais

Categoria I Significa que o cliente indiferente caracterstica do produto

38

Categoria Q Significa que o resultado questionvel, provocado talvez por m interpretao da resposta.

Categoria R Significa que a caracterstica indesejvel e o cliente espera o contrrio.

1. Eu gosto disso

2. Isso deve ser assim

3. Sou neutro 4. Eu posso conviver com isso

5. Eu no gosto disso

1. Eu gosto dissoQ A A A O

2. Isso deve ser assim R I I I M

3. Sou neutroR I I I M

4. Eu posso conviver com isso R I I I M

5. Eu no gosto disso R R R R Q

Forma disfuncional da questo

Forma funcional da

questo

Requisitos do produto

Quadro 2.3 Avaliao de Kano (Adaptado de Matzler e Hinterhuber, 1998)

Passo 3: Realizar entrevistas com os clientes

Segundo Matzler e Hinterhuber (1998), entrevistas padronizadas so mais apropriadas para os levantamentos do mtodo de Kano, pois reduzem a influncia do entrevistador, tem uma alta taxa de retorno e em caso de dvidas, o entrevistador pode fornecer explicaes.

Passo 4: Avaliao e interpretao

Um dos mtodos mais simples para a avaliao dos resultados atravs da freqncia das respostas, ou seja, as maiores freqncias indicam a caracterstica dominante do requisito. De acordo com a Tabela 2.1, a aderncia da borda do esqui um requisito obrigatrio (49,3%), facilidade de manobra um requisito de uma dimenso (45,1%) e servio um requisito atrativo (63,8%).

39

Tabela 2.1 Resultados da avaliao de Kano (Adaptada de Matzler e Hinterhuber 1998)

Requisitos do Produto A O M I R Q Total Categoria

Aderncia da borda 7 32,3 49,3 9,5 0,3 1,5 100% MFacilidade de manobra 10,4 45,1 30,5 11,5 1,2 1,2 100% OServio 63,8 21,6 2,9 8,5 0,7 0,7 100% A

Outro mtodo chamado de coeficiente de satisfao do cliente. Esse coeficiente exprime se a satisfao pode ser aumentada alcanando-se um requisito do produto. Esse coeficiente um indicativo do quo forte uma caracterstica de um produto pode influenciar a satisfao ou, em caso de no atendimento, a insatisfao do cliente. A Tabela 2.2 mostra os resultados obtidos no exemplo da indstria de esqui.

Extenso da satisfao

IMOAOA

+++

+

Extenso da insatisfao

)1()( ++++

IMOAMO

Tabela 2.2 Anlise dos coeficientes

Requisitos do Produto A O M I Total CategoriaExtenso

da Satisfao

Extenso da Insatisfao

Aderncia da borda 7 33 50 10 100% M 0,4 -0,83Facilidade de manobra 11 46 31 12 100% O 0,57 -0,78Servio 66 22 3 9 100% A 0,89 -0,25

2.5.2 Quality Function Deployment (QFD)

Segundo Carvalho (2002) apud Carvalho e Rabechini Jr (2005), o uso do mtodo Quality Function Deployment (QFD) permite a coleta e o tratamento das informaes provenientes do mercado de forma sistematizada e ordenada. O QFD pode ser definido como uma forma de comunicar sistematicamente informao relacionada com a qualidade e de explicitar ordenadamente o trabalho relacionado com a obteno da qualidade [...] (CHENG; FILHO, 2007, p. 44).

40

O modelo da ASI citado por Carvalho e Rabechini (2004) descreve o desdobramento da qualidade em quatro matrizes. Esse modelo parte do planejamento do produto, que desdobra em partes e subconjuntos, que por sua vez desdobra em processos crticos e por fim obtm-se as mtricas de controle de produo.

A primeira matriz do QFD conhecida como Casa da Qualidade, do ingls, House of Quality (HoQ). Essa matriz fornece as seguintes informaes:

A traduo das necessidades dos clientes em caractersticas para a qualidade do produto

Permite selecionar as caractersticas que maximizam a satisfao dos clientes

As caractersticas chave em que se devem concentrar os recursos disponveis para o desenvolvimento

O estabelecimento de metas quantitativas para as caractersticas de qualidade

Matzler e Hinterhuber (1998) ilustram uma aplicao do QFD baseada no modelo de Kano. Os passos para a aplicao do mtodo so:

Identificar as necessidades dos clientes isso pode ser feito atravs de entrevistas ou atravs de grupos foco.

Estruturar as necessidades e prioriz-las As necessidades devem ser estruturadas em uma hierarquia de requisitos Obrigatrios, Unidimensionais e Encantamento.

Comparar a percepo dos clientes Com o objetivo de verificar se a melhora de certos atributos de um produto leva a um ganho competitivo, deve-se comparar a qualidade percebida nos produtos da empresa com a dos produtos do competidor. Isso deve ser feito atravs de pesquisa de mercado.

Identificar atributos de design o time de desenvolvimento do produto traduz as necessidades dos consumidores em caractersticas de engenharia.

Desenvolver a matriz de relacionamento Nesta etapa, verifica-se o quanto os atributos de design influenciam as necessidades dos clientes.

Desenvolver a matriz teto Essa matriz deve quantificar a relao fsica entre os atributos de design, j que algumas vezes, a melhora de um atributo de design pode piorar outro.

Estimar custos, exeqibilidade e dificuldade tcnica Os custos, a exeqibilidade e as dificuldades tcnicas devem ser quantificados.

41

A Figura 2.12 apresenta da Casa da Qualidade, incluindo a anlise de Kano, destacada em cinza.

Figura 2.12 Casa da Qualidade (Adaptada de Carvalho e Rabechini Jr, 2005, e de Matzler e Hinterhuber, 1998)

2.6 Gesto de Escopo e os Stakeholders do Projeto

O gerenciamento do escopo do projeto deve estar atento s necessidades dos stakeholders (partes interessadas) no s na fase inicial, mas ao longo do ciclo de vida do projeto (CARVALHO; RABECHINI JR, 2005).

Aps a construo da WBS, deve-se obter a aprovao do seu contedo pelas partes interessadas. O escopo do projeto e as entregas so apresentados aos stakeholders do projeto que verificam se o trabalho atende aos requisitos do produto. O PMI (2004) denomina esse

42

processo de inspeo e, indica vrios nomes para esse processo, tais como revises, reviso do produto, auditorias e homologaes.

Segundo Carvalho e Rabechini Jr (2005), na reunio de projeto, o gerente do projeto dever garantir que cada pacote de trabalho dever garantir a entrega e ser associado a um responsvel.

Stakeholder qualquer indivduo ou grupo que so direta ou indiretamente impactados pelo projeto (SUTTERFIELD; FRIDAY-STROUD; SHIVERS-BLACKWELL, 2006). Os stakeholders podem ser internos ou externos ao projeto e, determinar se um grupo interno ou externo ao projeto uma percepo que depende do ponto de vista do observador. De acordo com Wang e Huang (2006), o gerente de projetos no limita o time de projeto nas fronteiras de sua organizao, mas inclui outros stakeholders como parte do time de projeto.

O gerente de projetos deve captar as entradas (inputs) dos stakeholders a fim de obter o sucesso do projeto (WANG, HUANG, 2006). Os stakeholders tm interesse na organizao e, como resultado da percepo desse interesse, eles tm certas expectativas, apresentando diferentes comportamentos. Segundo Sutterfield, Friday-Stroud e Shivers-Blackwell (2006), os stakeholders comportam-se da maneira que eles acham que ir ajudar a completar os objetivos do projeto e, esse comportamento, pode estar ou no de acordo com a viso do gerente de projetos.

Outro aspecto interessante na teoria dos stakeholders a dinmica dos stakeholders. Com o passar do tempo, a composio dos stakeholders pode mudar, ou seja, novos stakeholders podem ser includos enquanto outros podem sair (ELIAS; CAVANA; LAURIE, 2002).

Mitchell at al. (1997), apresentam um estudo interessante em que os stakeholders podem ser identificados pela posse de um ou mais atributos, sendo eles o poder, a legitimidade e a urgncia. Esses atributos podem ser definidos da seguinte forma:

Poder tem acesso a meios coercivos, utilitrios e normativos com a finalidade de impor sua vontade no relacionamento. Esse acesso tem carter transitrio, ou seja, ele pode ser adquirido ou perdido.

Legitimidade uma percepo de que as aes das entidades so desejveis, peculiares ou prprios dentro de alguns sistemas socialmente construdos de normas, valores, crenas e definies (SUCHMAN, 1995 apud ELIAS, CAVANA; JACKSON, 2002).

Urgncia o grau com que o stakeholder reivindica por ateno imediata.

43

A salincia dos stakeholders definida como o grau com que o gerente atribui prioridade reivindicao do stakeholder. A salincia ser positivamente associada com o nmero de atributos que um stakeholder possui. As classes de baixa salincia, chamadas de stakeholders latentes, so caracterizadas por possurem apenas um dos atributos. Os stakeholders de salincia moderada so chamados de stakeholders expectantes e so caracterizados por possurem dois atributos. A combinao dos trs atributos origina os stakeholders definitivos que possuem alta salincia. A tipologia dos stakeholders apresentada na figura 2.13

Figura 2.13 Tipologia dos Stakeholders (MITCHELL et al, 1997)

Stakeholders Latentes

Devido a limitao de tempo e recursos, possvel que os gerentes no dediquem seu tempo aos stakeholders que possuem apenas um dos atributos acima e to pouco reconheam a existncia desses stakeholders. Os stakeholders latentes podem ser de trs tipos: adormecido; arbitrrio e exigente.

44

Stakeholder adormecido Os stakeholders adormecidos possuem o poder como o atributo relevante para impor suas vontades na organizao, mas no possuem legitimidade de relacionamento e nem urgncia de pedido, ou seja, seu poder no usado. Estes stakeholders possuem pouca interao com a empresa, mas a gerncia est ciente da existncia desses stakeholders devido o potencial de adquirirem outros atributos.

Stakeholders arbitrrios Os stakaholders arbitrrios possuem o atributo da legitimidade, mas no possuem poder para influenciar a organizao, nem reivindicaes urgentes.

Stakeholders exigentes Os stakeholders exigentes so aqueles que reivindicam sem ter poder nem legitimidade. Mitchell, Agle e Wood (1997) comparam esses stakeholders a mosquitos zumbindo no ouvido da gerncia. Onde os stakeholders no conseguem poder ou legitimidade para mover suas reivindicaes para um estado de maior salincia, o barulho da urgncia insuficiente para projetar a reivindicao alem da latncia.

Stakeholders expectantes

Os stakeholders que possuem dois atributos so vistos como aqueles que esperam algo. A combinao de dois atributos leva o stakeholder para uma postura ativa versus passiva, com um aumento da sensibilidade da empresa a respeito dos interesses dos stakeholders. So definidas trs classes de stakeholders expectantes: dominante; dependente e perigoso.

Stakeholders dominantes Nos casos em que os stakeholders so poderosos e possuem legitimidade, a influncia na empresa assegurada. Esses stakeholders so caracterizados como dominantes devido reivindicao ser legtima e por possurem a habilidade de agir sobre essa reivindicao.

Stakeholders dependentes Os stakeholders que no possuem poder, mas tm reivindicaes legtimas so chamados de dependentes. Isso ocorre devido esses stakeholders dependerem de outros para obterem o poder necessrio para executar suas vontades.

45

Stakeholders perigosos Os stakeholders que possuem poder e urgncia, mas no tm legitimidade, so caracterizados como perigosos. Mitchell, Agle e Wood (1997) relatam que esses stakeholders so coercivos e possivelmente violentos. Os autores citam como exemplo as greves, sabotagem e terrorismo.

Stakeholders definitivos

Os stakeholders definitivos so os que possuem os trs atributos (legitimidade, poder e urgncia). Como visto anteriormente, um stakeholder que possui poder e legitimidade, far parte da coalizo dominante da empresa. Se a reivindicao desses stakeholders urgente, os gerentes daro prioridade para tais reivindicaes.

2.6.1 Anlise dos stakeholders

Elias, Cavana e Jackson (2002), apresentam em seus estudos, uma metodologia para a anlise dos stakeholders de um projeto de Pesquisa e Desenvolvimento (P&D), do ingls, Research and Development (R&D). As principais etapas destacadas so:

1. Desenvolver um mapa dos stakeholders do projeto 2. Preparar um quadro dos stakeholders especficos 3. Identificar os interesses dos stakeholders 4. Preparar um quadro de poder versus interesse 5. Analisar a dinmica dos stakeholders

Desenvolver um mapa dos stakeholders do projeto

Elias, Cavana e Jackson apresentam um mapa (figura 2.14) para o projeto de P&D de avaliao de uma estrada.

46

Figura 2.14 Mapa dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002).

Preparar um quadro dos stakeholders especficos

Para o exemplo citado, o quadro 2.3 apresenta os stakeholders especficos.

Interno FinanceiroEnvironment Commitee Members Transfund New ZealandRegional Land Transport Commitee Members The Treasury

Mdia ComunidadeTV New Zealand Property Owners

Ao dos cidados Grupos especiais interessadosTransmission Gully Action Council

Cliente Legal/PolticoRegional Chamber of CommerceComercial Road Users Association

Governo FornecedorTransit New Zealand Booz Allen & Hamilton-Consultants

Quadro 2.4 Identifiao dos stakeholders especficos (Adaptada de Elias, Cavana e Jackson, 2002).

47

Identificar os interesses dos stakeholders

O quadro 2.4 apresenta os principais interesses dos stakeholders do projeto tomado como exemplo

Regional Land Transport Commitee Transfund New Zealand Transit New Zealand

Responsabilidade pelo desenvolvimento do

sistema de transporte regional

Alocao dos fundos disponveis

Gerenciamento das necessidades dos

usurios da rodovia e comunidades

Comercial Road Users Association

Transmission Gully Action Council

Regional Chamber of Commerce

Usurios frequentes da rodovia

Necessidades da comunidade local

Desenvolvimento de negcios regionais

Quadro 2.5 Interesses dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002)

Preparar um quadro de poder versus interesse

O prximo passo da anlise a preparao de um quadro bi-dimensional em que a primeira dimenso categoriza os stakeholders pelo interesse e, a segunda, pelo poder (ver quadro 2.5).

Formal Econmico Poltico

Participao/Ao

Econmico Transfund New Zealand The Treasure

InfluenciadoresRegional Land

Transport Committee

PoderInteresse

Quadro 2.6 Interesse versus poder dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002)

48

Analisar a dinmica dos stakeholders

Segundo Elias, Cavana e Jackson (2002), as atitudes dos stakeholders em relao ao projeto e a salincia desses stakeholders segundo a percepo dos gerentes de projeto mudam com o tempo. Sendo assim, capturar essa dinmica enriquece a anlise dos stakeholders de um projeto de P&D. No quadro 2.6, pode-se ver o exemplo para o caso do projeto de P&D para avaliao de uma rodovia.

Adormecido Arbitrrio Exigente Dominante

Booz Allen & Hamilton The Treasure

Perigoso Dependente Definitivo No-Stakeholder

Transmission Gully Action Council

Transit New Zealand

Quadro 2.7 Anlise da dinmica dos stakeholders (Adaptada de Elias, Cavana e Jackson, 2002)

2.7 Modelos de Maturidade e a Gesto de Escopo

Uma das caractersticas das organizaes com um nvel de maturidade maior so processos comuns, em que existe uma documentao formal e melhoria contnua. Se pensar que a gesto de escopo deve ser realizada de forma sistemtica, com documentao formal e o processo deve ser comum por toda organizao, percebe-se que o nvel de maturidade tem influncia na qualidade da gesto de escopo praticada em uma determinada rea da organizao.

Apresentar-se- brevemente dois modelos de maturidade disponveis na literatura, o Capability Maturity Model (CMM) e o Project Management Maturity Model (PMMM).

2.7.1 Capability Maturity Model (CMM)

De acordo com Carvalho e Rabechini (2005), o CMM tem sua origem na indstria de software, sendo desenvolvido pelo Software Engineering Institute (SEI). A figura 2.15

49

apresenta os nveis de maturidade do modelo, onde a cada nvel de maturidade corresponde um conjunto de reas-chave de processo.

Figura 2.15 Nveis de maturidade do CMM (Adaptada de Carvalho e Rabechini Jr, 2005)

2.7.2 Project Management Maturity Model (PMMM)

Segundo Carvalho e Rabechini Jr, a estrutura do PMMM engloba instrumentos de benchmarking para medir o progresso da organizao ao longo do modelo de maturidade. A Figura 2.16 apresenta o modelo PMMM

50

Figura 2.16 Project Management Maturity Model (Adaptada de Carvalho e Rabechini Jr, 2005)

51

3 ABORDAGEM METODOLGICA

Este captulo tem como principal objetivo apresentar a abordagem metodolgica adotada para a anlise da gesto de escopo.

Adotou-se a abordagem de estudo de caso, desenvolvido na Empresa X, cuja unidade de anlise foi o Programa X da empresa em estudo.

As questes-chave que se pretende abordar face a reviso de literatura apresentada no Captulo 2 so:

Quais as caractersticas dos projetos do Programa X com relao aos aspectos hard e soft?

Como feito o gerenciamento do escopo dos projetos? Caso o gerenciamento do escopo dos projetos seja feito de forma insatisfatria,

quais as causas?

Quais so as principais ferramentas utilizadas para o gerenciamento do escopo? Qual a participao dos stakeholders no gerenciamento do escopo dos projetos?

Os dados para a anlise da organizao foram coletados atravs de entrevistas (n de entrevistados, nvel hierrquico e projetos selecionados sim ou no) e de documentos da rea. Os documentos utilizados foram modelos (templates), apresentaes, documentao dos projetos e apostilas de treinamento. Com esses documentos foram obtidos dados de como a rea realiza a gesto de escopo dos projetos.

As entrevistas foram realizadas em quatro etapas: 1. Conversas preliminares para fazer um diagnstico inicial de como feita a gesto

de escopo na rea. 2. Entrevistas para analisar os aspectos hard e soft dos projetos. Foram aplicados

questionrios baseados no modelo terico j visto no captulo de reviso bibliogrfica.

3. Conversas informais foram feitas com vrios gerentes de diferentes projetos a fim de se determinar alguns dados preliminares, como por exemplo, a disponibilidade de informao dos projetos, ou seja, quais projetos teriam mais informaes disponveis em forma de documentos e, se o gerente do projeto tinha disponibilidade para fornecer as informaes necessrias. Essas entrevistas foram feitas para ajudar na seleo dos dois projetos analisados no estudo de caso.

52

4. Entrevistas com os gerentes dos dois projetos escolhidos para o estudo de caso. Essas entrevistas abordaram aspectos relacionados ao modo como feita a gesto de escopo dos projetos escolhidos.

As premissas adotadas foram:

Acesso s informaes importantes para a anlise do trabalho

Confiabilidade das informaes fornecidas

A primeira premissa tem relao com a disponibilidade da empresa em fornecer as informaes necessrias para uma anlise satisfatria. A empresa possui um controle rgido quanto publicao de informaes internas. Alm disso, nem todos os funcionrios possuem a mesma viso a respeito dessa poltica, e assim, alguns poderiam se negar a fornecer algumas informaes relevantes para a realizao do trabalho. J a segunda premissa diz respeito ao conhecimento sobre a real situao do projeto que os possveis entrevistados possuem.

3.1 Classificao dos projetos do Programa X

O primeiro passo para a anlise classificar os tipos de projeto da Empresa X de acordo com o as caractersticas Hard e Soft. A importncia dessa anlise preliminar, como citado anteriormente, reside no fato de que se precisa entender o nvel de complexidade dos projetos e o quanto eles esto suscetveis a mudanas de escopo.

Para a realizao da anlise, estrutura-se um questionrio com as sete dimenses Hard e Soft. O modelo do questionrio apresentado no Quadro 3.1.

53

Questo Caractersticas A Caractersticas B

1Seu projeto possui metas

e objetivos claramente definidos

0 10 20 30 40 50 60 70 80 90 100

Seu projeto possui metas e objetivos no definidos claramente, passveis de

ambiguidade

2Seu projeto entrega um artefato fsico em sua

concluso0 10 20 30 40 50 60 70 80 90 100

Seu projeto entrega um conceito abstrato em sua

concluso

3As medidas de sucesso de

seu projeto so todas quantitativas

0 10 20 30 40 50 60 70 80 90 100As medidas de sucesso de

seu projeto so todas qualitativas

4Seu projeto no est sujeito influncias

externas0 10 20 30 40 50 60 70 80 90 100 Seu projeto est sujeito influncias externas

5 Existe uma nica soluo 0 10 20 30 40 50 60 70 80 90 100 Vrias solues so propostas

6

Sem participao dos stakeholders. Pouco

participativo. Pessoas presas em sua fronteira de

0 10 20 30 40 50 60 70 80 90 100

Participao dos stakeholders. Pessoas vo

alm da sua fronteira de trabalho

7

Os Stakeholders valorizam a tcnica, performance e

eficincia. Preferem gerenciamento por

controle

0 10 20 30 40 50 60 70 80 90 100

Os Stakeholders valorizam o relacionamento e a

cultura organizacional. Gerenciamento por meio

da negociao

Assinale as notas que correspondem s caractersticas de seu projeto. Notas prximas de zero correspondem

caractersticas prximas de "A" e notas prximas de cem, correspondem caractersticas prximas de "B"

Quadro 3.1 Modelo de questionrio adotado para classificao dos projetos (Adaptada de Crawford e Pollack, 2004)

Para cada dimenso, solicita-se aos entrevistados que quantifiquem cada dimenso, estabelecendo uma nota variando de 0 at 100, onde 0 est do lado hard do espectro e 100 do lado soft. O tamanho de amostra foi de 10 respondentes, todos envolvidos diretamente s atividades relacionadas aos projetos. Essas pessoas foram escolhidas com base no conhecimento de gesto de projetos que demonstraram durante o estgio e com base no tempo que trabalham na rea (foram escolhidas pessoas com pelo menos mais de um ano de rea). Portanto, devido ao conjunto de restries estabelecidas acima, o nmero de possveis entrevistados se reduziu para aproximadamente 10.

Os entrevistados receberam o questionrio impresso e, na presena do autor desse trabalho, davam as notas para cada dimenso. Em caso de dvida a respeito do significado das dimenses, o autor sanava a dvida.

54

3.2 Seleo dos Projetos

A deciso do nmero de projetos a serem estudados foi realizada em conjunto com o professor orientador desse trabalho. Decidiu-se que o nmero de projetos escolhidos seria de dois, pois seria suficiente para atender ao escopo desse trabalho de graduao, contribuindo para o aprendizado do autor e para a empresa no sentido de melhorar seu processo de gesto de projetos, dentre das restries de prazo para concluso desse trabalho.

O primeiro passo para a determinao dos projetos que faro parte do estudo de caso foi um levantamento de dados a respeito dos projetos do portfolio. Foram levantados dados de oramento, prazo, efetivo e disponibilidade de informao dos projetos. No que tange disponibilidade de informao, foram realizadas conversas rpidas com os gerentes dos projetos a fim de se verificar:

O conhecimento de cada gerente a respeito do projeto A disponibilidade do gerente para passar as informaes relacionadas ao projeto

A escolha dos dois projetos a serem estudados foi baseada nos seguintes fatores: Oramento Acredita-se que o oramento est relacionado importncia e

complexidade dos projetos da rea. Facilidade de obteno de informao A facilidade de obteno de informao

importante para o entendimento das caractersticas do projeto Efetivo O efetivo outra caracterstica que pode estar relacionada

complexidade do projeto. Durao Quanto maior a durao do projeto, melhor ele deve ser para efeito de

anlise, pois um projeto mais longo possui uma complexidade maior e estar mais sujeito a apresentar alteraes de escopo.

Grau de concluso do projeto Essa caracterstica importante para efeito de anlise. importante a escolha de projetos com maior grau de concluso possvel, j que eles tendem a possuir um histrico mais completo.

Primeiramente foram coletados os dados iniciais para caracterizao dos projetos, tais como: porcentagem do oramento total; durao e efetivo (n de participantes). Esses dados iniciais foram dispostos na Tabela 3.1.

55

Tabela 3.1 Caracterizao dos Projetos

Projeto % do oramento Efetivo Incio Fim

Durao (meses)

Projeto A 23 35 mai/06 set/11 64Projeto B 14 22 mai/06 dez/11 67Projeto C 7 22 mai/06 set/11 64Projeto D 6 20 abr/06 abr/10 48Projeto E 6 14 jun/07 jan/11 43Projeto F 4 15 mai/06 dez/11 67Projeto G 2 3 jun/07 jan/11 43

Dados iniciais dos projetos

...

Na Tabela 3.1, foram dispostos os dados dos projetos mais relevantes, ou seja, aqueles que possuem maior custo e complexidade no contexto do PROGRAMA X.

Aps a coleta desses dados preliminares, montou-se o Quadro 3.2, para auxiliar no processo decisrio. Nesse quadro, os projetos so dispostos em linhas e os fatores, em colunas. Para cada fator de cada projeto, estabelecido um peso e uma nota. A multiplicao do peso x nota resulta de uma pontuao e, os dois projetos que possuam as maiores pontuaes, foram os escolhidos.

Pontuao

Peso Nota Peso Nota Peso Nota Peso Nota Peso Nota PesoxNotaProjeto AProjeto BProjeto CProjeto DProjeto E

........

OramentoFacilidade de obteno de informao

EfetivoProjeto Durao

Grau de concluso do

projeto

Quadro 3.2 Critrios de avaliao para seleo dos projetos

56

Coleta de dados sobre a gesto de escopo: entrevistas

Para a coleta de dados sobre o gerenciamento do escopo na unidade de anlise em geral, Programa X, e nos projetos selecionados, foi elaborado um roteiro de questionrio para entrevistas. De posse deste questionrio, foram realizadas entrevistas presenciais com os gerentes dos dois projetos selecionados. medida que os entrevistados respondiam as perguntas, o autor anotava as repostas numa folha a parte. O modelo do questionrio apresentado no Quadro 3.3.

1 Quais as ferramentas de gesto de escopo que voc conhece?2 Quais as ferramentas de gesto de escopo que voc utiliza ou utilizou em seu projeto?3 O projeto apresentou alteraes de escopo durante seu andamento? Descreva as alteraes4 Em sua opinio, quais foram os motivos que levaram a essas alteraes?

5 Como foram determinados os requisitos do projeto? Quem definiu os requisitos? 6 Houve alterao dos requisitos durante o andamento do projeto? Quem solicitou?7 Quais pessoas foram responsveis pela definio do escopo do seu projeto? Como isso foi feito?8 Quais pessoas foram responsveis pela elaborao da WBS do projeto?9 Para a elaborao da WBS, foram utilizados padres ou mtodos definidos?

10 Existe algum mtodo de controle de alterao de escopo definido pela rea? Qual?11 Em seu projeto, foi utilizado algum mtodo de controle de alterao de escopo? Qual?12 O escopo foi acordado com todos os stakeholders do projeto?

Questionrio preliminar

Quadro 3.3 Roteiro de entrevista com os Gerentes de Projeto

Com base nas respostas obtidas do questionrio acima, pretende-se realizar uma anlise dos dois projetos escolhidos como estudo de caso. Ao fim dessa anlise objetiva-se propor templates ou um check list para auxiliar na gesto de escopo dos projetos da Empresa X.

Para ajudar a compreender o contexto organizacional, tambm ser aplicado o questionrio de maturidade de Kerzner (2001), mais conhecido como Project Management Maturity Model (PMMM), que corresponde ao segundo nvel de maturidade. Esse questionrio possui vinte questes, conforme apresentado no Anexo 1.

57

Adota-se como premissa que os gerentes dos dois projetos escolhidos iro disponibilizar as informaes necessrias para a realizao da anlise proposta.

A hiptese adotada que o Programa X possui falhas em sua metodologia de gesto de escopo, o que se pretende demonstrar ao analisar os dados coletados. Uma vez confirmada essa hiptese, sero propostas solues como j citado acima. A anlise quantitativa teve como finalidade mensurar o nvel de maturidade da organizao na gesto de projetos e tambm o grau de sucesso de projetos. Foram utilizados questionrios a partir da literatura, tanto para a anlise de maturidade quanto para a anlise de sucesso na gesto de projetos.

3.2.1 Instrumentos de pesquisa e modelo de referncia

No caso da anlise quantitativa de maturidade, foi utilizado o questionrio de maturidade de Kerzner (2001), mais conhecido como Project Management Maturity Model (PMMM), que corresponde ao segundo nvel de maturidade, que representa a transio entre a imaturidade (nvel 1) e a maturidade (nvel 3). Essa escolha pode ser suportada pelo seguinte motivo: estudos mostram que a maior parte das indstrias que utilizam gesto de projetos no atingiram ainda o terceiro nvel de maturidade. Dessa forma, bastante provvel que a montadora analisada neste trabalho esteja no primeiro ou segundo nvel de maturidade. O questionrio de segundo nvel de maturidade proposto por Kerzner (2001) possui vinte questes com uma escala de sete nveis, variando de discordo totalmente a concordo totalmente. Esse questionrio encontra-se no Anexo 1.

58

4 O ESTUDO DE CASO

Esse captulo traz os resultados do estudo de caso desenvolvido na Empresa X. Inicialmente faz-se uma descrio geral da rea de gesto de projetos, seguida de uma anlise da unidade de anlise do Programa X. Na seo seguinte so analisados os resultados das entrevistas e da pesquisa documental em projetos selecionados. Finalmente a ltima seo apresenta as sugestes de melhoria.

4.1. rea de gesto de projetos

A rea de gesto de projetos, como j citado, uma rea relativamente nova na empresa e tem como objetivo gerar e publicar anlises e indicadores de desempenho, dos recursos e de estabilidade de projetos. A rea formada por um gerente responsvel e uma equipe de aproximadamente 30 pessoas, dentre os quais se tem funcionrios efetivos e estagirios. A equipe trabalha alocada em pequenos grupos (normalmente de uma a quatro pessoas) nos diversos programas da empresa. Cada grupo responsvel por coletar e analisar dados de carga/capacidade, custo e prazo de cada programa. Os dados coletados de custo e efetivo dizem respeito apenas engenharia, ou seja, somente so contemplados os engenheiros e tcnicos diretamente ligados execuo do projeto (ver Figura 4.1).

59

Figura 4.1 Organograma geral da rea de planejamento da engenharia

Ao final de cada ms, os grupos de planejamento alocado devem gerar, cada um, um relatrio sobre o andamento de cada programa. O relatrio deve conter:

Anlise dos ndices de carga/capacidade

Anlise da curva de carga/capacidade

Anlise EVM (Earned Value Management) Informativo das alteraes do planejamento corrente devido s mudanas de

escopo e/ou reprogramaes

4.2. Estrutura Organizacional do Programa

A Empresa X conduz vrios projetos simultaneamente e, com o objetivo de maximizar a utilizao dos recursos, a empresa apresenta uma estrutura organizacional do tipo matricial

60

(ver Figura 4.2). Nessa estrutura, existe o programa, onde esto inseridas as gerncias de projeto, e as reas funcionais. A gerncia de projeto solicita os recursos das reas funcionais, que por sua vez, alocam seu efetivo de maneira a atender s necessidades dos diversos projetos. As reas funcionais so divididas de acordo com o conhecimento tcnico.

Para facilitar a integrao do projeto com as reas funcionais, criou-se a figura do Lder de Equipe (LE), que tem a funo de coordenao da equipe funcional para a realizao das atividades do projeto.

Figura 4.2 Estrutura organizacional da Empresa X

4.3. Gesto de projetos no Programa X

A rea de desenvolvimento tecnolgico, aqui chamada de Programa X, possui um portfolio de 18 projetos. Dentro do programa, existe a figura do Lder de Produto, que responsvel pelo portfolio de projetos do programa. As atribuies do lder de produto so:

Gesto do Desenvolvimento Integrado do Produto

Responsabilidade pelo produto integrado

Atendimento aos requisitos, qualidade e desempenho do produtos

Atendimento s metas do programa (prazos, investimentos e custo dos produtos) de acordo com o MAP (sigla interna para Memorando de Ativao do Projeto)

Liderana operacional das equipes

Programa A Programa B Programa C

rea Funcional A

rea Funcional A

rea Funcional A

61

O programa e a rea funcional nomeiam, para cada projeto, um Lder de Projeto (LP), que responsvel por gerenciar a equipe do projeto. Logo abaixo, pode-se ver um esquema da estrutura organizacional do programa de Desenvolvimento Tecnolgico (ver Figura 4.3)

Figura 4.3 Estrutura organizacional do Programa X

Dentro dos projetos, em especial os de maior complexidade, alguns pacotes de trabalho de alto nvel possuem lderes que esto abaixo do lder de projeto. Em geral, os projetos so desdobrados em estudos de tecnologias que iro compor a tecnologia estudada. Para cada sub-tecnologia, em geral nomeado um lder, que ser o Lder do Pacote de Trabalho, sendo responsvel pelo desenvolvimento da sub-tecnologia.

4.4 Gesto de Escopo no Programa X

Antes de apresentar como elaborado e controlado o escopo um projeto que compem o programa objeto desse estudo, importante entender como so estabelecidos novos projetos desse programa referido como Programa X, e cujo foco principal o desenvolvimento e internalizao na empresa de novas tecnologias.

A aprovao dos projetos do Programa X passa tipicamente pelas quatro fases mostradas na Figura 4.4. Cada fase composta por um conjunto mais ou menos padro de atividades. Ao final de cada fase tm-se revises de passagem de fase (Gates) onde o projeto

62

avaliado quanto ao atendimento dos critrios estabelecidos para cada fase. Somente aqueles que atingem os critrios estabelecidos so aprovados para a fase seguinte.

Figura 4.4 Fases de desenvolvimento de projetos do Programa X

Fase 1

A Fase 1 caracterizada pela identificao de oportunidades ou necessidades, e a consolidao da mesma em uma proposta inicial de projeto. Essa necessidade ou oportunidade de um novo projeto pode surgir nas reas funcionais, dos programas da empresa, ou pode surgir como resultado do trabalho da equipe de inteligncia tecnolgica. Nessa fase elaborada uma proposta para o projeto, que um documento simplificado de uma nica pgina onde descrito a idia bsica do problema ou oportunidade, histrico, empresas e entidades players, etc. Essa proposta apresentada para a gerncia da rea de prospeco do Programa X onde avaliada a aderncia da proposta (1) ao portfolio e (2) objetivos estratgicos da empresa. Caso seja aprovado, o projeto receber um enquadramento de nvel de maturidade tecnolgica, que ir definir o caminho que ele ir seguir a partir daqui. Duas vertentes estaro presentes: Propostas envolvendo (a) tecnologias de baixa maturidade, e (b) propostas envolvendo tecnologias de adequado grau de maturidade tecnolgica.

A) Projetos envolvendo tecnologias de baixa maturidade: Projeto de Prospeco Tecnolgica

Para projetos de baixa maturidade so estabelecidos Projetos de Prospeco Tecnolgica. Projetos de Prospeco tm como principal objetivo a elevao do grau de conhecimento tcnico da empresa acerca da tecnologia objeto do projeto. O resultado tpico de um projeto de prospeco a criao de uma viso concreta sobre o estado da arte da tecnologia e um relatrio de viabilidade de aplicao da tecnologia. Para esse tipo de projeto

Gerao da proposta do projeto

Elaborao do Project Charter (ou MAP)Figura 1

Execuo do Projeto

Encerramento do projeto

63

tem-se basicamente a Elaborao o Termo de Abertura (Project Charter) (ver Fase 2) seguida pela Execuo do projeto (ver Fase 3) e encerramento (ver Fase 4).

Fase 2 Elaborao do Project Charter Projetos de Prospeco

Nessa fase um time inicial formado para a elaborao do Project Charter do projeto. Esse time pequeno (de trs a quatro pessoas) e composto por pessoas da rea