FACULDADES ASSOCIADAS DE SO PAULO - FASP INSTITUTO DE PS-GRADUAO PS-GRADUAO EM GESTO DE PROJETOS EM TI DISCIPLINA DE PLANEJAMENTO E CONTROLE DE PROJETOS

Gerenciamento de Projetos: Escopo, Custo e Tempo

Carlos Augusto dos Santos Cinthia Gazzani Henry Franklin Duailibe da Costa Miladin Ramos Mihajlovic Ronnei Fausto Xavier Nunes Wellington Alves dos Santos

So Paulo - SP 2005

FACULDADES ASSOCIADAS DE SO PAULO - FASP INSTITUTO DE PS-GRADUAO PS-GRADUAO EM GESTO DE PROJETOS EM TI DISCIPLINA DE PLANEJAMENTO E CONTROLE DE PROJETOS

Gerenciamento de Projetos: Escopo, Custo e Tempo

Trabalho

apresentado

disciplina

de

Planejamento e Controle de Projetos, como requisito para obteno da Nota Final.

Professor: Joo Palma

So Paulo - SP 2005

2

SUMRIO

1 2

INTRODUO ........................................................................................................ 5 ESCOPO DO PROJETO......................................................................................... 5 2.1 2.2 2.3 2.4 Estrutura Analtica de Trabalho (EAT WBS) ................................................. 7 Planejamento do escopo.................................................................................. 9 Controle de Escopo........................................................................................ 11 Mudanas no Escopo..................................................................................... 12

3

CUSTO DO PROJETO ......................................................................................... 14 3.1 3.2 3.3 Composio oramentria ............................................................................. 15 A Estimativa ................................................................................................... 16 Gerncia de custo .......................................................................................... 17 Descrio do quadro de recursos ........................................................... 18 Recursos Requeridos.............................................................................. 18 Custo unitrio dos recursos .................................................................... 18 Estimativa de durao da atividade ........................................................ 19 Plano de Contas...................................................................................... 19 Estimativas por analogia ......................................................................... 19 As estimativas por analogia .................................................................... 19 Estimativa de baixo para cima (bottom-up)............................................. 20 Ferramentas computadorizadas ............................................................. 20 Estimativa de custo ................................................................................. 20 Baseline do custo.................................................................................... 21

3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.3.6 3.3.7 3.3.8 3.3.9 3.3.10 3.3.11 3.4 3.5

Controle dos Custos....................................................................................... 21 O processo de controle dos custos ................................................................ 22 Relatrios de desempenho ..................................................................... 22 Requisies de mudana........................................................................ 22 Sistema de controle de mudana do custo ............................................. 22 Planejamento adicional ........................................................................... 22 Ferramentas computadorizadas ............................................................. 23 Estimativa de custo revisadas................................................................. 23 Atualizaes do oramento..................................................................... 23 Estimativa de concluso ......................................................................... 23 Lies aprendidas ................................................................................... 24

3.5.1 3.5.2 3.5.3 3.5.4 3.5.5 3.5.6 3.5.7 3.5.8 3.5.9 3.6

Mtodos de composio oramentria .......................................................... 24 Elaborando um oramento de cima para baixo ...................................... 24 3

3.6.1

3.6.2 3.6.3 3.6.4 4

Elaborando um oramento de baixo para cima ...................................... 25 Processo de oramento iterativo A negociao em ao .................... 26 Determinando o custo de cada elemento: .............................................. 27

TEMPO DO PROJETO ......................................................................................... 28 4.1 Definio das Atividades ................................................................................ 29 Entradas para Definio das Atividades ................................................. 30 Ferramentas e Tcnicas para a Definio das Atividades...................... 31 Sadas da Definio das Atividades........................................................ 31

4.1.1 4.1.2 4.1.3 4.2

Sequenciamento das Atividades .................................................................... 31 Entradas para o Sequenciamento de Atividades .................................... 32 Ferramentas e Tcnicas para o Sequenciamento das Atividades.......... 33 Sadas do Sequenciamento das Atividades............................................ 34

4.2.1 4.2.2 4.2.3 4.3 4.4 4.5

Estimativa da Durao das Atividades........................................................... 34 Desenvolvimento do Cronograma.................................................................. 35 Gerncia e Prazos de Projetos (SLA) ............................................................ 37 Dinamismo na gesto ............................................................................. 38

4.5.1 5

CONCLUSO ....................................................................................................... 40

REFERNCIAS BIBLIOGRFICAS ............................................................................ 41

4

1

INTRODUO

Este trabalho vem demonstrar a importncia da gesto de projetos na rea de desenvolvimento de sistemas, permitindo um maior controle e maior conhecimento de cada fase do desenvolvimento de um projeto. Este pretende clarear as idias do leitor quanto gerncia de projetos e sua importncia na vida das empresas.

A gerncia de projetos tem como finalidade orientar quanto ao tempo, recursos e custos gastos desde o planejamento at implantao e posterior acompanhamento de um projeto.

Toda gerncia de projeto necessita organizao de trabalho, controle financeiro, controle de prazo, equipe motivada, contratos elaborados, recursos humanos medidos e comparados necessidade de cada projeto. Faz-se necessrio, ento, um maior aprofundamento nesta rea pelas pessoas interessadas em aumentar seus conhecimentos e assim obter maior controle dos processos em cada fase do desenvolvimento de sistemas.

2

ESCOPO DO PROJETO

A base para o planejamento de qualquer projeto a definio do escopo, indicando o que vai ser entregue ao cliente. Com base no escopo possvel planejar um prazo e um custo para execuo dos trabalhos. As chances de sucesso sero maiores se a comunicao entre os participantes do projeto for planejada, as pessoas forem administradas de forma profissional e os riscos identificados e monitorados. Do equilbrio de todos estes elementos, obtemos um projeto de qualidade, onde ao final do projeto o custo e prazo foram respeitados, o produto foi entregue conforme pedido pelo cliente e o moral da equipe continuou elevado.

Prazo

Custo

Escopo

5

A fase chamada incio marca o nascimento do projeto. neste momento que so definidos o esboo do escopo do projeto ou servio, que ser entregue no final do projeto.

O escopo o elemento que fornece a base de sustentao para se executar o projeto e tomar decises. Ele contm as seguintes informaes:

Justificativas do projeto (necessidade do negcio). Sumrio descritivo dos produtos a serem entregues. Definio dos resultados intermedirios e finais; por exemplo, a especificao de um software um resultado intermedirio, enquanto que o software propriamente dito o resultado final. Este item responde a perguntas do tipo: O que o projeto vai produzir? Um novo servio? Um produto? Vai consertar um defeito? A descrio detalhada do produto/servio a base para definio dos resultados.

Objetivos quantificveis do projeto. Quais critrios indicam o sucesso? Basta cumprir o prazo e o oramento ou existem outros objetivos a serem cumpridos? Por exemplo, num projeto de troca de um servio, alm dos prazos e do oramento, tambm poderia haver um objetivo secundrio que diz que o sistema no poder ficar fora do ar durante o horrio comercial.

Como o projeto ser gerenciado e como as mudanas sero integradas ao projeto. Quem ir controlar as solicitaes de mudanas no escopo? Como sero solicitadas? Quem deve aprovar as mudanas?

O escopo do produto no deve ser confundido com o escopo do projeto. O escopo do produto composto pela especificao tcnica que descreve o conjunto de funcionalidades e o desempenho desejado para o produto, e deve ser elaborado antes do escopo do projeto. O escopo do projeto define o conjunto dos trabalhos que sero executados para construir e entregar o produto.

Como o escopo do projeto descreve as principais atividades a serem executadas, a base para elaborao do cronograma e do oramento. Algumas vezes necessrio especificar o que o projeto no vai produzir, particularmente quando existe algo que as pessoas possam presumir como sendo parte do projeto. Por exemplo, no desenvolvimento de um sistema, pode ou no fazer parte do escopo do projeto o treinamento dos usurios.

6

Durante a execuo do projeto, o escopo deve ser controlado com muito critrio, pois qualquer mudana normalmente afeta todo o planejamento. importante que toda equipe entenda exatamente o que deve ser feito, e qual o prazo e o oramento. Para o cliente, o sucesso de um projeto normalmente medido segundo estes critrios: dentro do oramento; dentro do prazo; alta qualidade conformidade com as exigncias, que devem ser especificadas no incio do projeto; como funcionalidades dos sistemas (como recursos) e o desempenho esperado.

Na definio do escopo devem estar claras a estratgia e as tticas que sero utilizadas. A estratgia est associada abordagem que ser utilizada para realizar o projeto, como por exemplo, utilizar anlise essencial ou UML para especificao de um sistema. A ttica indica que passos sero dados para implementar a estratgia ou abordagem: elaborar modelo de dados, documentao de casos de uso e outras atividades associadas ao desenvolvimento.

2.1

Estrutura Analtica de Trabalho (EAT WBS)

No PMBOK o termo Estrutura Analtica de Trabalho chamado de Work Breakdown Structure (WBS). O EAT um check list que identifica todas as tarefas de um projeto, e como tal, ele:

Fornece uma ilustrao detalhada do escopo do projeto; D origem ao cronograma e permite monitorar o progresso; Mostra o detalhamento de custo de equipamento, mo-de-obra e materiais; Auxilia na montagem da equipe e distribuio do trabalho.

No EAT existem dois tipos de tarefas resumo e pacotes de trabalho. O pacote de trabalho corresponde a uma atividade que ser executada por algum profissional como, por exemplo criar uma tabela num banco de dados ou desenvolver uma rotina. A tarefa resumo corresponde a um agrupamento de pacotes de trabalho. Por exemplo, todos os pacotes de trabalho de criao de tabelas num banco de dados poderiam ser agrupados debaixo de uma tarefa resumo chamada criar banco de dados.

Independentemente do tipo de projeto, a construo da EAT no deve enfatizar a seqncia das tarefas. O objetivo identificar os pacotes de trabalhos, elaborando um check list de todas as atividades que sero executadas na construo do produto. 7

A EAT sempre montada com base no escopo do produto e do projeto, sem do que o primeiro nvel pode ser montado seguindo um dentre dois critrios diferentes:

Com base no escopo do produto listam-se os produtos ou sub-produtos que devero ser produzidos durante a execuo do projeto para cada produto, nos nveis seguintes da EAT, listam-se as tarefas que devero ser executadas para produzir o produto ou subproduto pertinente;

Com base nas fases do projeto (especificao, compras, construo, testes, entrega e instalao e outras) para cada fase, nos nveis seguintes da EAT, listam-se as atividades que sero executadas.

Em projetos grandes, normalmente os dois primeiros nveis da EAT so feitos por uma equipe e os restantes por equipes distintas, que vo executar partes especficas do projeto. Cada atividade includa no EAT deve contribuir para gerao do produto ou de um subproduto. Se necessrio ela pode ser decomposta em outras mais detalhadas, dando origem a novos nveis. O objetivo dividir uma tarefa complicada em vrias outras menores. Este processo pode continuar at no ser mais possvel a subdiviso, ou quando as tarefas puderem ser estimadas mais precisamente quanto a prazo e custo. O ideal que as tarefas tenham tamanhos gerenciveis, como por exemplo, entre um dia e uma semana. Quanto aos nomes das atividades, cada tarefa resumo e pacote de trabalho tm de receber o nome de uma atividade que gera um produto, ou seja, um verbo mais substantivo. Existem EAT padro para determinados tipos de projetos, que podem servir como ponto de partida para criao da EAT especfica do projeto. Por exemplo, existem metodologias de desenvolvimento de software, como o Unified Process, que prevem um conjunto padro de atividades que deveriam existir em todos os projetos. Aps a montagem da lista, para cada tarefa, ser necessrio descrever o trabalho a ser feito, definir o critrio de finalizao, listar os materiais e equipamentos que sero necessrios para a execuo da atividade e definir os tipos dos profissionais que executaro a tarefa. Para que a EAT esteja completa, tambm necessrio considerar na sua composio as atividades de gerenciamento do projeto, como reunies, elaborao de relatrios de anlise de progresso, monitoramento de riscos e outras.

8

2.2

Planejamento do escopo

O projeto autorizado por meio de um project charter. Com esse documento em mos, o gerente do projeto pode iniciar o seu planejamento. O primeiro a ser estabelecido o escopo do projeto, que o trabalho a ser realizado para que chegue ao produto final do projeto, com as suas caractersticas e funes que j foram definidas. No gerenciamento de projeto, o processo de planejamento do escopo o responsvel pela elaborao e validao do anteprojeto do escopo do projeto. O objetivo dessa validao no despender esforos, e, portanto recursos fsicos, detalhando um escopo que pode no ter sido bem entendido. Assim sendo, o gerente, antes de sair detalhando o escopo de um projeto, precisa fazer um estudo preliminar do que ser executado durante o empreendimento. Ele precisa, junto com a equipe, levantar quais so os principais subprodutos do projeto e escolher, entre as possveis alternativas de conduo do trabalho, aquela que deve ser utilizada para entrada desses subprodutos.A escolha dessa alternativa e dos principais subprodutos deve ser validada com os principais interessados (stakeholders).

O planejamento do escopo , portanto, o processo para o desenvolvimento do trabalho(escopo) que ir gerar o produto do projeto. Consiste em desenvolver uma declarao escrita, incluindo os critrios usados para gerenciar as alteraes do escopo. O quadro abaixo apresenta os dados necessrios, tcnicas e ferramentas e os resultados desse processo, de acordo com o PMBOK.

Dados necessrios -descrio do produto -project charter -restries -premissas

Tcnicas e ferramentas -anlise do produto -anlise custo/ benefcio -identificaa de alternativas - opinio especializada

Resultados -declarao do escopo -detalhes auxiliares -plano de gerenciamento do escopo

9

Dados necessrios para o processo de planejamento do escopo:

Descrio do produto do projeto: Documenta as caractersticas do produto ou do servio que o projeto est incumbido de criar, consta do project charter e foi vista em descrio do produto do projeto.

Project Charter: O plano sumrio do projeto o principal resultado do processo de iniciaa.

Restries: Para o planejamento do escopo, a equipe do projeto levar em considerao as restries impostas pelo project charter.

Premissas(hipteses, suposies): Para o planejamento do escopo, a equipe levar em considerao as premissas citadas no project charter.

Tcnicas e ferramentas para o processo de planejamento do escopo:

Anlise do produto: Para o planejamento do trabalho (escopo) importante ter um bom entendimento do produto(produto e servio) que ser entregue pelo projeto. Algumas vezes esse produto bem conhecido pela equipe e outras vezes no. A evoluo tecnololgica, do produto tem exigido das equipes um esforo constante no estudo de novas tecnologias, de forma a obter vantagens competitivas na execuo do projeto e/ ou no produto que ser gerado. Algumas vezes, esse esforo consome tantos recursos que necessrio prever no escopo do projeto uma fase especfica para essa pesquisa.

Identificao das alternativas: Quanto maior a complexidade do produto maior ser o leque de alternativas para a sua gerao ex: na rea de engenharia civil, uma ponte pode ser iniciadas simultaneamente em cada uma das margnes do rio ou ser construda a partir de uma das margens.

Anlise de custo/ benefcio: Com as alternativas identificadas, necessrio escolher aquela que deve ser executada. As alternativas possuem vantagens e desvantagens, custos e benefcios. A equipe de gerenciamento do projeto deve estabelecer critrios consistentes e lgicos de de avaliao, que iro possibilitar o processo de priorizao e seleo de alternativas. Podem ser

10

utilizadas na comparao de alternativas: menor prazo, melhor desempenho do produto, menor custo, maior taxa interna de retorno do investimento, etc..

Opinio especializada: Algumas vezes necessrio obter o suporte de especialistas durante o processo de seleo de alternativas dentro de um projeto. Estes especialistas podem ou no estar disponveis na empresa.

Resultado do processo de planejamento do escopo:

A declarao do escopo justamento o anteprojeto do escopo de um projeto. Ela fornece a documentao que servir de base para a tomada de decises e para confirmar ou desenvolver um entendimento comum do escopo entre as partes envolvidas(stakeholders).Com o progresso do projeto, a declarao do escopo pode necessitar de reviso para acomodar as mudanas aprovadas.

A declarao do escopo deve conter, tanto diretamente como por meio de referncia a outros documentos, os seguintes itens:

Justificativa do projeto requisitos do negcio que o projeto pretende atender. Produto do projeto descrio do produto do projeto. Principais subprodutos do projeto Objetivos (metas ) do projeto.

A definio de objetivos claros para o projeto fundamental, pois o xito depender do alcance ou no desses objetivos.

2.3

Controle de Escopo

O Planejamento diz como e onde a equipe deveria estar em determinado momento. O controle consiste no acompanhamento das atividades, com base no plano, com a finalidade de medir o progresso, comparar o progresso, comparar o previsto com o realizado e fazer os ajustes necessrios no projeto. O controle ocorre em paralelo com a execuo e envolve as seguintes atividades: gerenciamento de mudanas (incluindo mudanas de escopo), questionamento do trabalho executado, reunies de acompanhamento, controle da qualidade do produto, controle do tempo e do oramento. 11

As atividades associadas ao controle esto descritas no PMBOK. No quadro seguinte est representada a associao entre as atividades de controle e as outras fases do projeto-planejamento e execuo. Dentro das caixas, entre parnteses, est o nmero do captulo do PMBOK que aborda a atividade em questo.

Planejamento

Relatrios de progresso (10.3)

Controle geral das Mudanas (4.3)

Execuo

Verificao do escopo (5.4)

Mudanas de escopo (5.5)

Controle de tempo (6.5)

Controle do custo (7.4)

Controle de qualidade (8.3)

Monitorao e controle de risco (11.6)

Controle

2.4

Mudanas no Escopo

Qualquer projeto est sujeito a mudanas durante a fase de execuo. Na verdade, a primeira regra do planejamento estar preparado para replanejar. Os motivos mais comuns para mudanas so:

Eventos externos mudanas nas regras do governo, por exemplo; Erro ou emisso na definio do escopo do produto especificao tcnica incompleta ou errada; 12

Erro ou omisso na definio do escopo do projeto falha no planejamento; Mudanas adicionais ambiente e evoluo tecnolgica, por exemplo; Implementao do plano de contingncia concretizao de riscos.

Contudo, em projeto, estas mudanas so crticas e parecem ser mais freqentes, podendo levar um projeto ao fracasso. O problema maior com as mudanas de escopo quando elas forem pequenas e incrementais, o que dificulta o gerenciamento. Qualquer modificao no projeto deve ser discutida com a equipe e todos devem aprov-las, incluindo o apoiador e o cliente. Todas as solicitaes devem ser anotadas, os impactos no prazo e no oramento devem ser avaliados, e as modificaes aprovadas. Deve ser mantido um histrico de tudo que for solicitado, sendo aprovado ou no. Este histrico poder ser utilizado a qualquer momento para explicar e justificar o no cumprimento das estimativas de prazo e custo inicialmente previstas.

As mudanas de escopo podem gerar mudanas de custo, prazo, qualidade e outros objetivos do projeto. Algumas vezes, para manter o plano original do projeto, necessrio implementar uma ao, atravs de ajustes no plano inicial. O gerente de projeto deve manter os envolvidos informados dos impactos resultantes das mudanas de escopo, prevenindo todos de surpresas e protegendo a si prprio, pois o gerente de projeto poder ser avaliado com base nas metas iniciais e no nas metas revisadas.

Em algumas empresas o escopo e as prioridades mudam tanto que as pessoas alegam no valer a pena replanejar (identificar o caminho crtico, reestruturar os pacotes de trabalho, refazer estimativas, etc). As causas mais comuns para estas mudanas freqentes normalmente so duas: primeiro que no foi investido o tempo necessrio no planejamento, no incio do projeto, resultando em omisses de requisitos e estimativas incorretas; outro motivo que gerentes podem no estar atuando conjuntamente e a organizao deve estar tentando fazer mais trabalho do que pode com os recursos disponveis. Para melhor controle, as empresas deveriam implementar um procedimento que prev limites de aprovao para alteraes. Poderiam, por exemplo, ser trs:

Baixo: a equipe de projeto pode aprovar. Geralmente no afeta custo, prazo ou o produto; Mdio: pode provocar alterao no custo, prazo ou no produto. Exige uma aprovao formal do comit de alterao; 13

Alto: acima de um certo limite de custo e prazo, ser necessrio obter a aprovao da alta direo da empresa.

O comit de alterao um grupo de pessoas formado por representantes da equipe de projeto e do cliente, podendo conter tambm representantes de grupos com produtos relacionados e representantes de grupos com produtos relacionados e representantes da gerncia funcional. Em projeto de informtica o Comit de alterao normalmente composto por um representante do usurio (cliente), o lder tcnico do projeto e o gerente do projeto. A formalizao deste comit deve ocorrer na fase de incio do projeto. Cada solicitao de alterao deve ser encaminhada para esse grupo, que avalia e as classifica como indispensvel, a ser implementada numa verso futura ou desnecessria. Sempre que possvel este comit dever postergar as solicitaes de alterao para verses futuras do sistema, de modo a evitar as alteraes no projeto.

3

CUSTO DO PROJETO

Inclui os processos necessrios para assegurar que o projeto ser concludo dentro do oramento aprovado. Os custos normalmente so medidos em montantes monetrios, como reais ou dlares, que devem ser pagos para adquirir mercadorias, bens e servios. Pelo fato dos projetos custarem dinheiro e redirecionarem recursos que poderiam ser aplicados em outras reas, muito importante para os gerentes de projetos entenderem sobre gerenciamento de custos. O gerenciamento de custos de projetos de tecnologia da informao ainda mais crtico, principalmente se for baseado em estimativas de custos em que os requisitos e o escopo ainda no esto totalmente claros. Se relembrarmos das consideraes feitas no tpico sobre gerenciamento de escopo, poderemos concluir mais uma vez que custo e escopo esto fortemente relacionados, e que dependem do entendimento claro dos requisitos do usurio para serem estimados com mais preciso. Escopos mal definidos por problemas de requisitos tambm mal-entendidos geram problemas de custos nas estimativas no incio, no planejamento, na execuo e no controle do projeto; e, conseqentemente, os custos no final do projeto tendero a aumentar muito e extrapolar o oramento previsto. Uma outra razo para a variao de custos em projetos de tecnologia da informao quando estes envolvem novas tecnologias. Qualquer tecnologia nova que ainda no foi testada exaustivamente traz consigo riscos herdados. O ideal no fornecer nenhuma informao sobre o custo de projeto 14

para o cliente sem antes validar por completo o entendimento dos requisitos e do escopo com os usurios e sem antes avaliar as tecnolgias disponveis no momento. Esse processo deve envolver o gerente do projeto, os membros do time do projeto e o usurio. Falhas nas estimativas, variaes e surpresas de custos podem ser minimizadas em projetos de tecnologia da informao sem forem utilizados os processos de gerenciamento de custo, conforme estruturados no PMBOK.

3.1

Composio oramentria

A composio oramentria se constitui em um plano no qual os recursos alocados so associados aos seus respectivos custos. Portanto, o ato de elaborar um oramento significa alocar recursos escassos provenientes de vrias fontes em uma organizao. O resultado de um processo de alocao de recursos freqentemente no satisfaz os gerentes, os quais devem se adaptar a uma realidade imposta pelas restries de um oramento. Entretanto verifica-se que as restries de oramento se constituem precisamente naquilo que proporciona sustentao a uma poltica empresarial. Uma medida de importncia do resultado deste processo se reflete em como as diversas atividades de uma empresa so adequadamente desempenhadas. A maioria dos gerentes seniores de que temos conhecimento tendem a ser imparciais na conduo do processo de composio oramentria, alocando recursos para cada atividade planejada no nvel exato nem alocando recursos acima do previsto, o que acarreta e estimula uma gerncia negligente, nem alocando recursos abaixo do previsto, o que ir inibir e frustrar os planos aos quais um compromisso foi engajado. Considerando-se que um gerente ser o responsvel pela utilizao de recursos com o intuito de atingir determinado objetivo, a utilizao de recursos dever ser monitorada com bastante cuidado. Este fato permite que desvios da utilizao planejada possam ser confrontados com o progresso do projeto, sendo gerados relatrios neste sentido caso os gastos com os recursos alocados no estejam compatveis com os resultados alcanados. No nvel mais alto est o planejamento do projeto como um todo, que ento dividido diversas vezes e, talvez, ainda novamente em um ninho de planos. Planejamentos de projetos demonstraram ser equivalentes a uma EAP. Se verificarmos o custo de um EAP passo a passo, o resultado ser o desenvolvimento de um oramento para um projeto. Se verificarmos os custos do planejamento de um processo, iremos chegar exatamente ao mesmo ponto. Dentro desta viso, a composio oramentria simplesmente o planejamento de projeto visto de outra maneira. 15

3.2

A Estimativa

Para que possamos proceder a uma composio oramentria, devemos prever que tipos de recursos sero necessrios para o projeto, a quantidade necessria de cada um deles, quando os mesmos sero necessrios e qual ser o seu custo incluindo-se os efeitos de uma inflao potencial. A incerteza faz parte de qualquer previso, embora algumas previses apresentem um menor grau de incertezas do que outras. Uma pessoa experiente em uma estimativa de custos ser capaz de prever a quantidade de tijolos necessria na construo de uma parede com determinadas dimenses, dentro de uma tolerncia de 1 ou 2% (devendo simplesmente prever uma pequena quantidade adicional referente a tijolos que forem entregues quebrados ou em padro de cor diferente, alm de alguns mais que iro quebrar durante o trabalho de construo). Por outro lado, erros esto mais sujeitos a ocorrer de forma muito mais ampla com referncia quantidade de horas programadas ou linhas de cdigo que sero necessrias produo de determinado software. Apesar da cincia de computao tornar esta estimativa bastante plausvel, o nvel de incerteza consideravelmente maior, bem como a dimenso dos erros tambm muito maior. Em vrios campos, os mtodos para estimativa de custos so muito bem definidos. Cada empresa possui sua regra geral no que se refere estimativa de custos, as quais normalmente trazem a experincia prtica adquirida por vrios colaboradores envolvidos com esta atividade durante vrios anos. Um produtor de livros experiente pode, por exemplo, examinar um manuscrito e, aps fazer algumas perguntas a respeito da quantidade e tipo de ilustraes e da qualidade do papel utilizado, poder fazer uma estimativa razoavelmente precisa a respeito dos custos necessrios para se produzir um livro. interessante compreender que o desenvolvimento de uma composio oramentria para projetos muito mais difcil do que o desenvolvimento de oramentos referentes a atividades mais freqentes em uma empresa. A influncia de fatores histricos muito mais forte na composio de um oramento de uma atividade em curso. Entretanto a composio oramentria de um projeto no pode depender da tradio. No incio de um projeto, pode ser que no existam oramentos anteriores para servirem como base. Certo autor afirmou: Durante determinadas ocasies os responsveis pelo oramento podero estar diante de oramentos e relatrios de auditoria referentes a projetos similares, para servirem de referncia; entretanto tais referncias so, na melhor das hipteses, bastante elementares. Em todo caso, todo projeto especial e todo oramento se baseia em previses de utilizao de recursos e seus custos associados. Portanto a estimativa de

16

custos para qualquer projeto envolve riscos. No caso de projetos que se desenvolvem ao longo de vrios anos, existem outros problemas decorrentes. O planejamento e o cronograma so estabelecidos no incio do mesmo; entretanto, ao longo dos anos, poder haver uma alterao na previso de utilizao de recursos devido ao fato de existirem novos materiais e servios, equipamentos e recursos humanos disponveis agora a um custo diferente daquele que foi estimado. Quanto maior a durao de um projeto, menor o grau de confiana que um gerente de projeto poder ter que mtodos tradicionais e custos sero relevantes. Como se tudo isto no fosse suficiente, a viso incorreta de alguns executivos freqentemente muito mais acentuada no que se refere a projetos do que a operaes em curso.

3.3

Gerncia de custo

A gerncia do custo do projeto consiste, fundamentalmente, nos custos dos recursos necessrios implementao das atividades do projeto. Em muitas reas de aplicao, prever e analisar a perspectiva de desempenho financeiro do produto do projeto feita fora do ambiente do projeto. Quando essas previses e anlises esto includas, a gerncia do custo do projeto inclui processos adicionais e uma quantidade de tcnicas de gerncia tais como retorno do investimento, fluxo de caixa, entre outras. Quando os custos do projeto so usados como componentes de premiao e de sistemas de reconhecimento, os custos controlveis e no controlveis devem ser estimados e orados separadamente, para assegurar que os prmios reflitam o desempenho real. O PMBOK divide a gerncia de custo do projeto em quatro processos, a saber: planejamento dos recursos; estimativa dos custos; oramentao dos custos e controle dos custos. Segundo ainda o PMBOK, em projetos pequenos, os trs primeiros processos esto to unidos que podem ser vistos como um nico processo (por exemplo, pode ser realizados por um nico indivduo, durante um certo intervalo de tempo). Veremos pois, esses trs processos de forma conjunta.

Veremos aqui os trs processos j citados: planejamento dos recursos; estimativas dos custos e oramentao dos custos. O planejamento dos recursos envolve determinar quais recursos fsicos (pessoas, equipamentos e materiais) e quais quantidades de cada devem ser usadas para a realizao de atividades do projeto. A estimativa dos custos envolve desenvolver uma estimativa dos custos dos recursos necessrios a implementao das atividades do projeto. A estimativa dos custos inclui identificar e considerar vrias alternativas de custo. Por exemplo: na maioria das reas 17

de aplicao, considera-se amplamente que o trabalho adicional durante a fase de projeto (design) tem o potencial de reduo do custo na fase de produo. O processo de estimativa dos custos deve considerar se o custo do trabalho adicional na fase de projeto ir compensar a economia esperada. Por fim, a oramentao dos custos envolve alocar as estimativas dos custos globais aos itens individuais de trabalho com a finalidade de estabelecer um baseline de custo para medir o desempenho do projeto. Cabe dizer que j estudamos anteriormente nas apostilas de escopo, tempo e recursos a maior parte das ferramentas e tcnicas apresentadas pelo PMBOK para gerncia de custo. Por isso, no falaremos em todas essas ferramentas novamente, apenas citaremos as que iro acrescentar algo de relevante especificamente no que diz respeito gerncia de custo.

3.3.1 Descrio do quadro de recursos

O conhecimento de quais recursos (pessoas, equipamentos, materiais) est potencialmente disponvel necessrio para o planejamento dos recursos e tambm dos custos, j que a utilizao de cada recurso tem um custo associado.

3.3.2 Recursos Requeridos

A sada do processo de planejamento dos recursos a descrio de quais os tipos de recursos requeridos e qual a quantidade para cada elemento da EAP.

3.3.3 Custo unitrio dos recursos

O indivduo ou grupo que elabora a estimativa deve ter o conhecimento das taxas unitrias (por exemplo, custo horrio de pessoal) de cada recurso com a finalidade de calcular o custo do projeto. Se as taxas no forem conhecidas, as mesmas podem ser estimadas.

18

3.3.4 Estimativa de durao da atividade

A estimativa de durao da atividade afetar as estimativas dos custos de qualquer projeto onde o oramento do projeto inclui subsdios para os custos de financiamento (por exemplo, taxas de juros).

3.3.5 Plano de Contas

O plano de contas descreve a estrutura de codificao utilizada pela organizao para reportar as informaes financeiras para o seu sistema geral de contabilidade. As estimativas do custo do projeto devem ser alocadas na categoria contbil correta.

3.3.6 Estimativas por analogia

Nas estimativas por analogia, tambm chamadas de estimativas top-down, usam-se os custos reais de projetos anteriores similares como base para a estimativa do custo do projeto corrente. freqentemente usada na estimativa dos custos totais do projeto quando existe uma quantidade limitada de informaes detalhadas sobre o projeto (por exemplo, nas fases iniciais). As estimativas anlogas so uma forma de avaliao especializada.

3.3.7 As estimativas por analogia

So geralmente menos dispendiosas que outras tcnicas, mas, tambm freqentemente menos precisas. So mais confiveis quando (a) os projetos anteriores so semelhantes de fato e no apenas na aparncia (b) os indivduos ou grupos que esto preparando as estimativas possuem a experincia ou percia necessria.

19

3.3.8 Estimativa de baixo para cima (bottom-up)

Esta tcnica envolve estimar o custo individual dos itens de trabalho, depois sumariz-los ou agreg-los para obter a estimativa total do projeto. O custo e a preciso das estimativas de baixo para cima so direcionados pelo tamanho dos itens individuais de trabalho: itens mais detalhados de trabalho aumentam tanto o custo quanto a preciso. A equipe de gerncia do projeto deve pesar o aumento da preciso contra o custo adicional.

3.3.9 Ferramentas computadorizadas

As ferramentas computadorizadas tais como software de gerncia de projeto e planilhas amplamente utilizado no apoio estimativa dos custos. Tais produtos podem simplificar o uso das ferramentas descritas acima e, portanto, agilizar as consideraes de muitas alternativas de custo.

3.3.10 Estimativa de custo

As estimativas de custo so avaliaes quantitativas dos provveis custos dos recursos requeridos para a implementao das atividades. Podem ser apresentadas detalhadamente ou sumarizadas. Os custos devem ser estimados para todos os recursos que estaro empenhados no projeto. Isto inclui, mas no est limitado a mode-obra, materiais, suprimentos e categorias especiais tais como inflao ou reserva de custo.

As estimativas de custos so geralmente expressas em unidades monetrias (dlar, franco, yen, real etc.) com a finalidade de facilitar comparaes tanto dentro ou fora dos projetos. Outras unidades tais como horas de pessoal ou dias de pessoal podem ser utilizadas, desde que o seu uso no adultere os custos do projeto. Em alguns casos, as estimativas tero que ser fornecidas usando vrias unidades de medida com a finalidade de facilitar o apropriado controle da gerncia. As estimativas de custo podem ser beneficiadas por refinamentos ocorridos durante o curso do projeto como reflexo dos detalhes adicionais disponveis.

20

3.3.11 Baseline do custo

O baseline do custo o oramento referencial que ser utilizado para medir e monitorar o desempenho do custo do projeto. desenvolvido atravs da totalizao das estimativas de custo por perodo e, usualmente, apresentada na forma de Curva-S.

Muitos projetos, especialmente os maiores, podem ter vrios baselines de custo para medir diferentes aspectos do desempenho de custo. Por exemplo, um plano de gastos ou uma previso de fluxo de caixa so baselines para medir desembolso.

3.4

Controle dos Custos

O controle dos custos est associado a (a) influenciar os fatores que criam as mudanas na meta de custo de forma a garantir que estas mudanas sejam benficas, (b) determinar que a meta de custo foi alterada, e (c) gerenciar as mudanas reais quando e da forma que elas surgirem. O controle dos custos inclui:

Monitorar o desempenho do custo para detectar as variaes do plano. Assegurar que todas as mudanas adequadas esto registradas corretamente no baseline de custo. Impedir que mudanas incorretas, no apropriadas ou no autorizadas sejam includas no baseline de custo. Informar adequadamente as partes envolvidas das mudanas autorizadas.

O controle de custo inclui descobrir o porqu das variaes, tanto positivas quanto negativas. Deve estar fortemente integrado com os outros processos de controle (o controle de mudana de escopo, o controle do cronograma e o controle da qualidade). Por exemplo, uma resposta no apropriada para variaes do custo pode causar problemas de qualidade ou de cronograma, ou produzir, mais adiante no projeto, um nvel de risco inaceitvel.

21

3.5

O processo de controle dos custos

3.5.1 Relatrios de desempenho

Os relatrios de desempenho fornecem informaes sobre o desempenho do custo tais como quais oramentos esto sendo alcanados e quais no esto. Os relatrios de desempenho podem, tambm, alertar a equipe do projeto para questes que podem causar problemas no futuro.

3.5.2 Requisies de mudana

As requisies de mudana podem ocorrer de muitas formas oral ou escrita, direta ou indiretamente, iniciada externa ou internamente, e legalmente imposta ou opcional. As mudanas podem requerer um aumento no oramento ou permitir que ele seja reduzido.

3.5.3 Sistema de controle de mudana do custo

O sistema de controle de mudana do custo define os procedimentos pelos quais o baseline do custo pode ser alterado. Inclui manuais, sistemas de acompanhamento e os nveis de aprovao necessrios para autorizar mudanas. O sistema de controle de mudanas do custo deve estar integrado com o sistema do controle geral de mudanas.

3.5.4 Planejamento adicional

Poucos projetos se desenvolvem exatamente conforme o planejado. Mudanas em perspectiva podem exigir uma estimativa nova ou uma reviso do custo ou, ainda, exigir anlise de abordagens alternativas.

22

3.5.5 Ferramentas computadorizadas

As ferramentas computadorizadas, tais como softwares de gerenciamento de projetos e planilhas so freqentemente utilizadas para acompanhar o custo planejado versus o custo real, e para prever os efeitos das mudanas do custo.

3.5.6 Estimativa de custo revisadas

As estimativas de custo revisadas so modificaes nas informaes de custo utilizadas para gerenciar o projeto. As partes envolvidas apropriadas devem ser notificadas, se necessrio. O custo estimado revisado pode ou no requerer ajustes em outros aspectos do plano geral do projeto.

3.5.7 Atualizaes do oramento

As atualizaes do oramento so uma categoria especial das estimativas de custo revisadas. As atualizaes do oramento so mudanas no baseline aprovado. Esses nmeros so geralmente revisados apenas em resposta a mudanas no escopo. Em alguns casos, as variaes de custo podem ser to severas que um replanejamento (rebaselining) seja necessrio com a finalidade de fornecer uma avaliao realstica do desempenho.

3.5.8 Estimativa de concluso

A estimativa de concluso uma previso (EAC) do custo total do projeto baseada no desempenho do projeto. As tcnicas mais comuns de previso so algumas variaes do:

EAC = custo real at a data, mais o oramento restante do projeto modificado por um fator de desempenho, freqentemente o ndice de desempenho de custo. Essa abordagem usada com mais freqncia quando as variaes correntes so vistas como tpicas para variaes futuras.

EAC = custo real at a data, mais uma nova estimativa para todo o trabalho restante. Essa abordagem usada com mais freqncia quando o 23

desempenho passado mostra que as premissas da estimativa original estavam bastante imperfeitas, ou que no so mais to relevantes, devido a mudanas nas condies. EAC = custo real at a data, mais o oramento restante. Essa abordagem usada com mais freqncia quando as variaes correntes so vistas como atpicas e a expectativa da equipe de gerncia do projeto que variaes semelhantes no se repetiro no futuro.

Cada uma das abordagens acima pode ser a correta para um item de trabalho dado qualquer.

3.5.9 Lies aprendidas

As causas das variaes, as razes por trs das aes corretivas tomadas e outros tipos de lies aprendidas durante o controle do custo, devem ser documentadas de forma a tornarem-se parte da base de dados histricos a ser utilizada tanto no projeto corrente como em outros projetos da organizao.

3.6

Mtodos de composio oramentria

O PMBOK apenas cita, porm no detalha os mtodos de composio oramentria. Por isso, vamos agora considerar em detalhes os mtodos de composio oramentria utilizados pelas empresas. Sero abordados tambm alguns problemas referentes estimativa de custos, com ateno aos detalhes e possveis erros. Levamos em considerao algumas exigncias e preocupaes referentes composio oramentria de um projeto.

3.6.1 Elaborando um oramento de cima para baixo

Esta estratgia se baseia no julgamento e experincia de gerentes de alto e mdio escalo, assim como dados obtidos no passado a respeito de atividades similares. Tais gerentes so responsveis por estimar o custo total de um projeto, bem como o custo dos principais subprojetos que compreendem o projeto principal. Esta estimativa de custo ento encaminhada aos gerentes de mais baixo escalo, que

24

devero dar seqncia diviso do oramento em estimativas para tarefas especficas, bem como pacotes de tarefas que formam os subprojetos. Este processo vai at o escalo mais baixo. Neste processo a composio oramentria, assim como o projeto, dividido em sucessivas partes, a comear do topo, ou nvel mais agregado, seguindo a EAP. No entanto, as discusses que surgem, em vez de gerarem um debate saudvel, muitas vezes levam ao distanciamento e falta de comunicao. Quando a gerncia snior insiste em manter suas posies a respeito de um oramento com base em significativas experincias passadas os gerentes jnior se sentem forados a aceitar aquilo que eles julgam ser uma alocao insuficiente de recursos para se alcanar os objetivos que eles se comprometeram a atingir. Discusses entre os autores e um grande nmero de gerentes demonstram que os gerentes de mais baixo escalo freqentemente consideram todo um processo de composio oramentria como se eles nada representassem. A competio entre os gerentes jnior freqentemente bastante intensa. A vantagem do processo de oramento de cima para baixo que oramentos agregados podem ser freqentemente desenvolvidos de maneira bastante precisa, embora alguns elementos individuais possam ser elaborados de maneira significativamente incorreta. Outra vantagem de um processo de oramento de cima para baixo que tarefas menos significativas no necessitam ser individualmente identificadas, nem mesmo necessrio se preocupar com o fato de que um pequeno mas importante aspecto foi esquecido. A experincia e a opinio do executivo presumida automaticamente para dar forma a todos estes elementos na estimativa total de custos.

3.6.2 Elaborando um oramento de baixo para cima

Neste mtodo, tarefas comuns, seus respectivos cronogramas e seus oramentos individuais so elaborados, novamente, em observncia a EAP. Os indivduos responsveis pela realizao dos trabalhos so consultados a respeito dos tempos e oramentos para as tarefas a eles designadas, de forma a assegurar o melhor nvel de preciso. Inicialmente as estimativas so feitas em termos de recursos, tais como mo-de-obra e materiais, que so, posteriormente, convertidos para seus equivalentes em moeda corrente. As tarefas agregadas ao oramento proporcionam ento o custo total direto do projeto. O gerente de projeto classifica ento os custos indiretos como custos gerais e administrativos, chegando-se desta forma ao final da composio oramentria do projeto. Oramentos de baixo para cima deveriam ser, e normalmente o so, mais precisos do que nas tarefas detalhadas, 25

entretanto a incluso de todos os elementos um fator crtico. muito mais difcil desenvolver uma lista completa de tarefas construindo-se a mesma de baixo para cima do que de cima para baixo. Assim como o mtodo de cima para baixo poder acarretar um jogo de situaes, o mtodo de baixo para cima tambm apresenta seus jogos exclusivos. Por exemplo, as pessoas envolvidas estimam em demasia suas necessidades de recursos porque suspeitam que a alta gerncia provavelmente ir promover cortes em todos os oramentos. Sua suspeita naturalmente bastante justificvel. Gerentes com particularmente boa capacidade de persuaso algumas vezes se saem vencedores. As vantagens de um processo de baixo para cima so aquelas associadas geralmente com a gerncia participativa. Indivduos que participam dos trabalhos esto mais aptos a terem uma idia mais precisa de necessidades de recursos do que seus superiores ou outros no diretamente envolvidos. Alm disto, o envolvimento direto de gerentes de escales mais baixos na elaborao de um oramento aumenta as possibilidades do oramento ser aprovado sem contestao por parte dos mesmos. O envolvimento tambm uma tima tcnica de treinamento gerencial, proporcionando aos gerentes juniores uma valiosa experincia na preparao de oramentos, bem como o conhecimento das operaes necessrias para se gerar um oramento. Os gerentes seniores relutam em transferir o controle do oramento a seus subordinados cuja experincia pode ser questionvel e tal fato perfeitamente compreensvel. Tal atitude levada ao extremo em uma grande empresa que desenvolve dezenas de projetos simultaneamente, podendo cada um deles durar de cinco a oito anos e consumir milhes de dlares.

3.6.3 Processo de oramento iterativo A negociao em ao

Uma tcnica recomendada a elaborao de um processo de planejamento iterativo com subordinados com o desenvolvimento de planos de ao para as tarefas que eles tm responsabilidade de executar. Os superiores procedem a uma reviso destes planos, talvez sugerindo alteraes aos mesmos. O ponto forte desta tcnica est no fato de que a responsabilidade mais importante pela designao de uma tarefa delegada a uma pessoa responsvel por sua execuo, o que implica a utilizao da tcnica de gerncia participativa (ou envolvimento do empregado). Se feita corretamente, a utilizao estimada de recursos e cronogramas se torna parte integrante do processo de planejamento em todos os seus nveis. Portanto, o indivduo encarregado de elaborar um plano de ao em seu nvel mais elevado estimaria as necessidades de recursos e a durao de cada passo referente ao plano. Em uma 26

situao ideal, a quantidade de recursos e o tempo necessrio para se executar uma determinada tarefa estimada pelo superior e pelo subordinado seria a mesma. Entretanto no vivemos situaes ideais. Alis, a relao mais provvel entre as estimativas originais dentre aquelas realizadas em diferentes nveis que a quantidade de recursos estimada pelo superior seja menor que a quantidade de recursos estimada pelo subordinado, o que verdade devido a diversas razes, trs das quais so praticamente universais. Inicialmente, quanto mais longo algum puder subir em uma empresa, distanciando-se da responsabilidade de executar determinado trabalho, o referido trabalho parecer cada vez mais fcil, rpido e barato de se executar aos olhos do superior do que aos olhos daquele que tem a responsabilidade de execut-lo. Isto se deve ao fato de que ou o superior no tem conhecimento dos detalhes do trabalho a ser executado, ou, por convenincia prpria, esqueceu os detalhes do mesmo, bem como qual ser a durao do trabalho e como diversos problemas podem aparecer. Em segundo lugar, o superior ir subestimar custos (e tempo), uma vez que ele tem uma parcela de responsabilidade em apresentar o projeto junto alta gerncia como um empreendimento lucrativo. Em terceiro lugar, o subordinado tende a incluir algum nvel de proteo contra falhas, com uma previso contra a Lei de Murphy. Partindo-se da premissa de que o superior e o subordinado so honestos um com o outro (qualquer outra premissa ir comprometer uma negociao win-win, em que ambas as partes se beneficiam do resultado alcanado), os dois avaliam o plano de ao elaborado por este ltimo. Normalmente, o superior que d o passo inicial no sentido de se reduzir as diferenas na estimativa de custos, o qual foi instrudo pelo subordinado a respeito das realidades do trabalho a ser desenvolvido. O resultado o aumento da estimativa feita pelo superior. O prximo passo tipicamente de responsabilidade do subordinado. Motivado pela resposta favorvel de seu chefe para que prossiga em seu raciocnio, o subordinado descarta algumas das protees disponveis para os subprodutos do oramento e, em conseqncia a quantidade de recursos estimada pelo subordinado diminui. A estimativa de custos elaborada pelo subordinado pode ser ainda maior do que a do superior, entretanto a diferena foi consideravelmente diminuda. O processo de negociao continua at que se chegue a um oramento definitivo.

3.6.4 Determinando o custo de cada elemento:

O verdadeiro processo de se elaborar um oramento para um projeto, podendo ser de cima para baixo ou de baixo para cima, ou uma combinao de ambos, tende a 27

ser um processo direto, porm bastante tedioso. Cada elemento de trabalho no plano de ao ou EAP avaliado de acordo com suas necessidades de recursos, sendo ento estimado o custo para cada tipo de recurso. Vamos supor que determinado elemento necessita de 25 horas de trabalho de um tcnico. O tcnico designado para executar esta tarefa ser remunerado em R$17,50 por hora. O custo apropriado parece ser o seguinte:

25 horas X R$ 17,50/hora = R$ 437,50.

Custos referentes a equipamentos e maquinaria so debitados diretamente no projeto. Se for necessria a utilizao de determinada mquina no projeto e esta mquina for de propriedade de determinado departamento funcional, o projeto poder pagar por ela, atravs da transferncia de fundos do oramento do projeto para o oramento do departamento funcional. A despesa referente a tal mquina ser a de um custo operacional (R$ por hora ou R$ por ciclo operacional), acrescido de uma taxa de depreciao baseada ou em tempo ou na quantidade de ciclos operacionais. Alm desses, h tambm os encargos gerais e administrativos. Estes encargos so formados pelos custos da gerncia superior, das diversas funes do corpo de assistentes e de outras despesas. Os encargos gerais diretos ou do total de todos os custos diretos e indiretos. Portanto, elementos de custo totalmente contabilizados incluiriam os custos diretos (mo-de-obra, recursos e maquinarias especiais), alm dos custos gerais e administrativos. Aconselhamos o gerente de projetos a preparar dois oramentos, um deles incluindo os custos de gerais/administrativos e o outro sem a incluso destes custos. O oramento total ser utilizado pela contabilidade com o objetivo de se estimar o lucro a ser obtido pelo projeto. O oramento que inclui somente os custos diretos proporciona ao gerente de projetos informaes suficientes para gerenciar o projeto que no venham a se confundir com custos sobre os quais o gerente de projetos no possui nenhum tipo de controle.

4

TEMPO DO PROJETO

A gerncia do tempo do projeto inclui processos necessrios para garantir que o projeto ser implementado no prazo previsto. Os principais processos so:

Definio das Atividades: identificar as atividades especificas que devem ser realizadas para produzir os diversos subprodutos do projeto; 28

Sequenciamento das Atividades: identificar e documentar as relaes de dependncia entre as atividades; Estimativa da Durao das Atividades: estimar a quantidade de perodos de trabalho que sero necessrios para a implementao de cada atividade; Desenvolvimento do Cronograma: analisar a seqncia e as duraes das atividades e os requisitos de recursos para criar o cronograma do projeto; Controle do Cronograma: controlar as mudanas no cronograma do projeto.

Estes processos interagem uns com os outros e tambm com os processos das demais reas de conhecimento.

Cada processo pode envolver esforo de um ou mais indivduos ou grupos dependendo da necessidade do projeto, cada processo geralmente ocorre pelo menos uma vez em cada fase do projeto.

Para projetos menores o sequenciamento das atividades, a estimativa da durao das atividades e o desenvolvimento do cronograma esto to unidos que podem ser vistos como um nico processo (exemplo podem ser realizados por um nico individuo, durante um curto intervalo de tempo), estes processos so apresentados como processos distintos porque as ferramentas e tcnicas so diferentes para cada um.

At o momento no existe um consenso dentro da profisso de gerente de projetos sobre o relacionamento entre atividades e tarefas

4.1

Definio das Atividades

A definio das atividades envolve identificar e documentar as atividades especificas que devem ser realizadas com a finalidade de produzir os diversos nveis de subprodutos identificados na EAP (Estrutura Analtica do Projeto), implcito neste processo est a necessidade de definir atividades voltadas para o alcance dos objetivos do projeto.

1. Entradas Estrutura Analtica do Projeto-EAP Descrio do escopo 29

Informaes histricas Restries Premissas

2. Ferramentas e Tcnicas Decomposio Modelos

3. Sadas Lista de atividades Detalhes de suporte Atualizaes na EAP

4.1.1 Entradas para Definio das Atividades

Estrutura analtica do projeto-EAP Principal entrada para a definio da atividade, uma EAP pode ser usada como modelo em um novo projeto embora cada projeto seja nico as EAPs podem ser reutilizadas uma vez que a maioria dos projetos se assemelha a um outro em sua extenso.

Declarao de Escopo A justificativa e os objetivos do projeto contidos na declarao do escopo devem ser considerados de forma explicita durante a definio das atividades.

Informaes histricas As informaes histricas devem ser consideradas na definio das atividades do projeto.

Restries As restries so fatores que limitaro as opes da equipe de gerencia do projeto.

Premissas As premissas so fatores que para os propsitos do planejamento, sero consideradas como verdadeiros, reais ou certos.

30

4.1.2 Ferramentas e Tcnicas para a Definio das Atividades

Decomposio A decomposio envolve subdividir os elementos do projeto em componentes menores com a finalidade de fornecer melhor controle do gerenciamento do projeto.

Modelos Ressume numa lista de atividades ou parte de uma lista de atividades de projetos anteriores usada com freqncia como modelo ou referencia para um novo projeto.

4.1.3 Sadas da Definio das Atividades

Lista de Atividades A lista de atividades deve incluir todas as atividades que sero realizadas no projeto, e uma extenso da EAP deve assegurar que esta completa e no inclui qualquer atividade que no seja requerida como parte do escopo do projeto.

Detalhes de suporte Os detalhes de suporte referentes a lista de atividades devem ser documentados e organizados de forma a facilitar seu uso por outros processos da gerencia de projetos.

Atualizao na EAP Ao utilizar a EAP para identificar quais atividades so necessrias a equipe de projetos pode identificar a falta de algum subproduto ou pode determinar que a descrio dos subprodutos necessitem ser corrigidas.

4.2

Sequenciamento das Atividades

1. Entradas Lista de atividades Descrio do produto Dependncias mandatrias Dependncias arbitrarias Dependncias externas Restries Premissas 31

2. Ferramentas e Tcnicas Mtodo do diagrama de procedncia (PDM) Mtodo do diagrama de flecha (ADM) Mtodo do diagrama condicional Modelos de rede

3. Sadas Diagrama de rede do project Atualizaes da lista de atividades

4.2.1 Entradas para o Sequenciamento de Atividades

Lista de atividades A lista de atividades deve incluir todas as atividades que sero realizadas no projeto, e uma extenso da EAP deve assegurar que esta completa e no inclui qualquer atividade que no seja requerida como parte do escopo do projeto.

Descrio do produto As caractersticas do produto afetam as seqncias das atividades, embora esses efeitos so freqentemente visveis na lista de atividade, a descrio do produto deve ser geralmente revisada para assegurar a preciso.

Dependncias mandatrias As dependncias mandatorias so aquelas inerentes a natureza do trabalho que esta sendo feito, evolvem limitaes fsicas. As dependncias mandatorias so tambm chamadas de lgica rgida (hard logic).

Dependncias arbitradas So definidas pela equipe de gerencia de projeto, devem ser usadas com critrio, pois podem limitar as opes do cronograma.

Dependncias externas So aquelas que envolvem relacionamento entre atividades do projeto e atividades que no so do projeto (ex: atividade de teste de um software pode depender da entrega do hardware pelo fornecedor externo).

32

4.2.2 Ferramentas e Tcnicas para o Sequenciamento das Atividades

Mtodos do diagrama de precedncia (PDM) Este mtodo de construo de diagrama de rede utiliza ns para representar as atividades e as conecta atravs de setas que representam suas dependncias.

Esta tcnica tambm e chamada de atividade em n (AON Activity-on-node) e o mtodo utilizado pela maioria dos pacotes de programas para gerencia de projeto, pode ser feito manualmente ou no computador.

Inclui quatro tipos dependncia ou procedncia:

Trmino/Inicio: a atividade de deve terminar antes que a atividade parapossa comear. Trmino/Trmino: a atividade de deve terminar antes que a atividade para possa terminar. Inicio/Inicio: a atividade de deve iniciar antes que a atividade para possa iniciar. Inicio/Termino: a atividade d deve iniciar antes que a atividade parapossa terminar.

Mtodo do diagrama de flecha Este mtodo de construo de diagrama de rede utiliza ns para representar as atividades e as conecta atravs de setas que representam suas dependncias.

Esta tcnica tambm e chamada de atividade em n (AON Activity-on-node) e o mtodo utilizado pela maioria dos pacotes de programas para gerencia de projeto, pode ser feito manualmente ou no computador.

Mtodo de diagrama condicional As tcnicas de diagramaco tais como GERT (Avaliao Grfica e Tcnicas de Reviso) e os modelos de Sistemas dinmicos permitem atividades no sequencias como loops ou desvios condicionais. O PDM e o ADM no permitem loops ou desvios condicionais.

33

4.2.3 Sadas do Sequenciamento das Atividades

Diagrama de rede do projeto Um diagrama de rede de projeto e um esquema de apresentao das atividades do projeto e dos relacionamentos lgicos entre elas:

O diagrama de rede pode ser construdo manualmente ou no computador. O diagrama deve ser acompanhado por uma descrio sumaria. Qualquer seqncia no usual deve completamente descrita.

Atualizaes da lista de atividades Da mesma maneira que o processo de definio das atividades pode gerar atualizaes na EAP a preparao do diagrama de rede do projeto pode revelar situaes em que uma atividade deve ser divida ou mesmo redefinida com finalidade de diagramar corretamente o relacionamento lgico.

4.3

Estimativa da Durao das Atividades

A estimativa da durao da atividade envolve avaliar a quantidade de perodos de trabalho que provavelmente sero necessrios para implementar cada atividade, uma pessoa ou um grupo da equipe do projeto que estiver mais familiarizada com a atividade deve participar para aprovar a estimativa.

Estimar a quantidade ou numero de perodos de trabalho para implementar uma atividade,, requer consideraes ao tempo de espera. No processo de estimativa so geradas muitas informaes por isso importante registra-las de forma sistemtica. O cronograma estimado de uma tarefa mede o tempo do inicio ao termino, geralmente chamam essa estimativa de cronograma importante incluir todo o tempo que tarefa durar.

Estimativa de mo-de-obra Projetam a quantidade de horas trabalhadas no projeto, (ex. Se trs pessoas trabalharem 8 horas por dias durante trs dias o total de forca de trabalho estimado ser de 72 horas).

34

Nos pequenos pacotes de trabalhos a mo-de-obra estimada em horas, em projetos maiores podem ser estimadas em anos. Alem de registrar a estimativa de mo-de-obra necessrio registrar as exigncias de qualificaes.

Estimativas de equipamento As exigncias de equipamentos precisam ser identificadas no nvel de pacote de trabalho, estas estimativas se tornam com base para estimar o custo total do equipamento no projeto.

Estimativa de materiais Os materiais do projeto podem ser uma importante fonte de custos, embora um projeto de construo possa ter uma parte significativa do seu custo total representado pelas matrias primas.

Os projetos de desenvolvimento de software no tem matria-prima mas o projeto de um sistema de informtica para instalar um programa comercial que so vendidos nos estabelecimentos tero de incluir seu custo do software.

Embora os custos com materiais possam ser uma parcela grande dos custos do projeto, o custo total do material deve ser estimado a partir das especificaes do produto.

Oramentos de preo fixo Os oramentos de preo fixo significam que o representante assume a responsabilidade sobre os custos se houver estouro no oramento, o custo do projeto no mudar.

Com a contratao de servios ou a compra de material criar limitaes ao cronograma, o cronograma deve ser ajustado por conta dessas limitaes de recursos,mas antes de ajustar o cronograma preciso identificar todas as exigncias de recursos, um pacote de trabalho por vez.

4.4

Desenvolvimento do Cronograma

O clculo de um cronograma pode ser uma das tcnicas mais conhecidas, apesar de no apreciada dentre todas as tcnicas da gesto de projeto, ainda assim e o segredo para estabelecer cronogramas realistas para serem cumpridos.

35

A tcnica PERT virou sinnimo de clculos de cronogramas com base nos diagramas de rede. O calculo do cronograma fornece um conjunto de dados detalhados do cronograma de cada pacote de projeto conforme:

Inicio Antecipado A data mais cedo em que uma tarefa pode comear, dadas as tarefas que precedem.

Trmino antecipado A data mais cedo que uma tarefa pode terminar, dadas as tarefas que a precedem.

Inicio atrasado A data mais tarde em que uma tarefa pode se iniciar sem atrasar a data de termino do projeto.

Trmino atrasado A data mais tarde em que uma tarefa pode terminar sem atrasar a data de termino do projeto.

Verificao para adiante A verificao para adiante ajuda a determinar o inicio antecipado (IAN) e o termino antecipado (TAN) de cada tarefa, recebe este nome tambm porque exige o trabalho do diagrama de rede do inicio ao termino

Verificao para trs A verificao para trs determina as datas de inicio atrasado e trmino atrasado, a meta de verificao para trs literalmente trabalhar de trs para frente a partir da data d termino do projeto para determinar at quando qualquer tarefa pode comear ou terminar.

Clculo da Flutuao H algumas tarefas que tem flexibilidade e podem ser executadas em diferentes perodos do cronograma e outras no. O perodo dessa flexibilidade no cronograma e chamada de flutuao (a flutuao e calculada subtraindo-se o inicio antecipado do termino antecipado).

Caminho critico Quando tiver calculado o cronograma inicial o projeto comea a tomar forma, um dos recursos-chaves do cronograma inicial o caminho critico.

O conceito simples: O caminho prtico definido como sendo todas as tarefas com flutuao zero ou negativa, quando estruturada em um diagrama de rede o caminho critico e co caminho mais longo em toda a rede. 36

Evitar flutuao negativa Nem todo projeto tem um caminho critico, se um projeto tiver uma data de termino imposta quem permite mais que suficiente para completar o projeto todas tarefas tero flutuao.

Exemplo: Compras de Natal o dia 25 de Dezembro uma data de termino imposta externamente, no comeo do ano quando h 200 dias de compras at o Natal, no tem ningum estressado porque ainda h muita flutuao. Flutuao Negativa resulta da imposio externa das datas de termino que so impossveis de cumprir. Quando existe flutuao negativa significa que os ajustes tero de ser feitos para colocar o cronograma na linha junto com o caminho critico. Este tipo de informao necessrio quando for necessrio renegociar os equilbrios de custos, cronograma e qualidade.

4.5

Gerncia e Prazos de Projetos (SLA)

Gerenciar a rea tecnolgica, nos moldes preconizados pelo ITIL (Information Technology Infrastructure Library), identificar, ativa e dinamicamente, os servios de TI essenciais.

Gerenciar a rea tecnolgica, nos moldes preconizados pelo ITIL (Information Technology Infrastructure Library), identificar, ativa e dinamicamente, os servios de TI essenciais aos negcios e estratgia de uma organizao e entreg-los dentro dos requisitos adequados de disponibilidade, performance e segurana estipulados nos SLAs (Service Level Agreements). As melhores prticas compiladas no modelo britnico so, portanto, imprescindveis estruturao, de uma maneira orientada a processos, do delivery de servios que assegure o cumprimento dos SLAs. O entendimento de fundo de que se deve medir TI pelo valor que ela agrega. Em outros termos, mtricas de desempenho so, acima de tudo, mtricas de negcios, cabendo aos gestores monitorar cada elemento da infra-estrutura de TI levando em conta o servio e a aplicao que ele suporta.

Nesse sentido, a primeira dificuldade com os SLAs que no raro os departamentos de TI, ainda posicionados como centros de custos, no tratam a prestao de servios como um negcio. A abordagem excessivamente tcnica gera frustrao dos dois lados, tanto do profissional que faz o SLM (Service Level Management) pelo lado de TI quanto das reas de negcios. Fala-se muito em bits e 37

bytes e no a lngua do usurio. Quem faz uso dos servios precisa saber medir e avaliar o impacto deles no seu dia-a-dia. O extrato que contm a medio dos SLAs, tem de estar em uma linguagem inteligvel para quem est empregando a tecnologia. Isso imprescindvel sobretudo para que se possa aferir o retorno do investimento e os benefcios que TI est trazendo ao negcio. A partir da, se pode galgar o nvel que o Gartner classifica como de gerao de valor do servio de TI para o business, medindo-se o SLA pelo que ele agrega de valor.

Na verdade, antes de se formalizarem os SLAs e se estabelecer toda a cadeia de gerenciamentos para sustent-los, vale indagar qual o cardpio de servios que ser colocado disposio, com que qualidade eles sero prestados, quando e por que so usados. Implantando o SLM de um modo mais abrangente, o ITIL trata de cercar todos os itens de configurao de um servio, desde os skills dos funcionrios envolvidos.

4.5.1 Dinamismo na gesto

De resto, para encetar uma gesto dos nveis de servios participativa, crucial entender que o SLA no pode ser uma planilha com mtricas totalmente estveis. Essa modalidade de acordo, pelo contrrio, tem de ser dinmica, porque a vida de negcios dinmica. H que se considerar, prossegue ele, que um business reage em funo dos movimentos da demanda e da concorrncia: "TI precisa ter uma flexibilidade tal que, quando acionada pelo negcio, deve reagir, se adaptar e se reposicionar para produzir os resultados requeridos, se pretende corresponder s exigncias do mercado.

Nessa linha, a gesto dos SLAs, a ser efetuada junto com o board executivo da organizao, deve alicerar-se no s na anlise do momento atual, mas tambm antecipar-se a tendncias futuras de curto, mdio e longo prazos. " dessa forma que conseguimos alimentar com mais eficincia a dinmica dos SLAs, para eles poderem compatibilizar-se sempre com as estratgias".

O grande obstculo na hora da montagem de um SLA definir o que mensurar dentro da prestao de servios. essencial, dessa maneira, acionar mecanismos para mostrar o que est sendo concretamente agregado em termos de valor. H uma diferena entre prestar servios e cumprir nveis de servios. O modelo ITIL/ ITSM 38

garante que aquilo que est sendo fornecido tem um nvel de servio agregado. O quadro geral da gesto de SLAs ganha ainda maior complexidade quando se considera, adicionalmente, que nas implementaes o fenmeno corriqueiro um fornecedor "guarda-chuva" mobilizar um conjunto de parceiros subcontratados no atendimento a um cliente.

Impe-se, neste caso, repassar as obrigaes assumidas com esse cliente ao universo de provedores mobilizados nos projetos, o que denominado de compromisso back to back. Deve-se, por isso mesmo, na cadeia de alianas e parcerias, fomentar a cultura de integrar os distintos SLAs em estreita conformidade com os requerimentos colocados pelas implementaes. Alm do mais, cabe ao fornecedor principal ter em mos o histrico de atividades e a definio precisa das competncias dos parceiros em relao consecuo de um dado escopo. Tomamos cuidado na seleo das parcerias, procurando trabalhar com eles a melhor definio do que o projeto significa para todos, no s no contexto de perdas que podem ser infligidas ao cliente, mas tambm no tipo de exposio negativa que pode nos atingir.

Simultaneamente, cabe pr em marcha um sistema de gesto de fornecedores que auxilie no acompanhamento de todas as atividades de acordo com as mtricas formuladas com os clientes. O objetivo checar o que realmente est sendo entregue ao longo de toda a cadeia de valor. H ferramentas de gesto para automatizar o mximo possvel esse processo a fim de facilitar o trabalho do gerente de delivery, uma figura que temos internamente, encarregada de olhar mais o lado operacional e fazer uma gesto ponta a ponta. Uma preocupao crtica, nesse contexto, o pleno suporte contingncia, dentro do princpio de que, se houver falha, o cliente no pode ficar com a soluo fora do ar. Sempre que pensamos numa extenso do servio a terceiros, h que se considerar tambm o plano B. Temos, a esse respeito, um posicionamento bastante cauteloso, contemplando sempre o contingenciamento. Isso no elimina o risco, mas o minimiza bastante.

Seja como for, o especialista prev que o amadurecimento nas relaes entre cliente e fornecedor vai redundar, nos prximos anos, na celebrao de contratos de riscos entre ambas as partes, prevendo-se penalidades em caso de insucesso e bnus quando houver bons resultados.

39

5

CONCLUSO

Pode existir um projeto sem objetivos?

Acreditamos que no, um projeto deve ter objetivos bem definidos, associados a produtos claramente especificados e mais do que isso, um projeto deve possuir mecanismos que permitam se os objetivos esto sendo alcanados (escopo, custo, prazo).

No entanto surpreendente o elevado nmero de projetos que chegam metade ou mesmo ao final do prazo estabelecido sem qualquer medida quantitativa de sucesso.

Na rea de melhoria do processo, bem como na implantao do gerenciamento de projetos segundo o PMBOK, ainda comum a ocorrncia de casos desta natureza, onde a falta de definio dos objetivos e mecanismos de processos impede a quantificao do sucesso do projeto. Nestes casos, torna-se difcil justificar valores, alteraes nos prazos, etc, devido resultados obtidos. dificuldade de identificar e quantificar os

claro que tais falhas so muito mais freqentes quando os processos so conduzidos sem a presena de especialistas em gerenciamento de projetos.

40

REFERNCIAS BIBLIOGRFICAS

BRUCE, Andy e LANGDON, Ken. Como gerenciar projetos. Publifolha, 2000, 72 p.

DEMARCO, Tom. Controle de Projetos de Software, 1ed, Editora Campus, 1991.

PMBOK, A Guide to the Project Management Body of Knowledge. 1ed. USA: PMI. Project Management Institute. Four Campus Boulevard, Newton Sq, Pennsylvania USA, 2000, 216p.

POSSI, Marcus. Capacitao em Gerenciamento de Projetos. Rio de Janeiro: Brasport, c2004. 532p.

STURM, R.; W. MORRIS; M. JANDER; Foundations of Service Level Management, Indianapolis, SAMS, 2000, pp. 272.

VARGAS, Ricardo Viana. Manual prtico do plano de projeto utilizando o PMBOK 2000. Rio de Janeiro: Brasport, c2003. 210p.

VERZUH, Eric. MBA Compacto: Gesto de Projetos, 2. ed. Rio de Janeiro: Campus, c2000. (traduo Andr L. Cardoso).

XAVIER, Carlos Magno da Silva. Gerenciamento de Projetos, 1.ed, Editora Saraiva, 2005, 192p.

41