Falhas que impactam no sucesso em uma gestão de projeto (página 2)

Risco não é problema, mas, como irá ser tratado;

Contratação de um gerente de projeto que tenha alguns requisitos mínimos para ser o responsável na execução do projeto;

Criar um template que possa ser analisado com rigor em condições macros e se for o caso em alguma parte mais detalhada em uma reunião semanal com alguns critérios de importância no projeto como: Folga positiva e negativa, caminho crítico, atividades em atraso, histograma, descrição do motivo referente ao não início da atividade;

Elaborar uma lista de pendência que possa envolver todas as pessoas que tem como resolvê-las de imediato;

Gerência competente: o principal fator para o sucesso de um projeto é possuir um único gerente que seja experiente, treinado, respeitado e com disponibilidade de tempo para que possa dedicar o tempo integral no projeto;

Equipe competente, ou seja, pessoas experientes. Sem uma equipe realmente competente é impossível executar um projeto com sucesso.[3]

Os gerentes de projetos ou planejadores têm como um grande auxílio os softwares existentes no mercado como o Primavera Project Management (conforme figuras 1.1 e 1.2), mas como qualquer outro software necessitará de uma base de dados que serão inseridas com uma informações fidedigna dos projetos, que sejam feitas por uma pessoa conhecedora de todo o projeto para que na atualização do software não ocorra nenhum deslize quanto as atividades, duração, predecessora, sucessora, Lag (atrasos) e Lead (antecipação) para refletir a realidade de execução ou folga, tipo de relacionamento das atividades, restrições, recursos, etc., não ocorra falha que possa acarretará em um grande conflito na entrega do projeto e que os softwares de gerenciamento ou aplicativos não sejam apenas p/elaboração de cronogramas e relatórios, coloridos, quando poderiam aportar muito mais, como:

Planejar, acompanhar, rastrear, programar, criar interdependências entre tarefas mantendo a lógica da execução da obra e estipular prazos.

Calculando de maneira rápida e precisa as datas mais cedo e mais tarde de cada evento, e as folgas de cada atividade, o programa nos permite identificar o caminho crítico e toda vez que, por força de mudanças na execução de atividades este caminho crítico mudar, ajuda a entender o que é importante no projeto em qualquer momento da execução, isto nos será claramente indicado.

Conhecido o prazo requerido de nossa obra, podemos adequar atividades no sentido de conseguirmos atingir o prazo estipulado, ou, havendo folga, alocar da melhor forma as tarefas ao longo desta.

Ao atribuirmos às atividades os recursos e custos correspondentes, podemos gerar um histograma de recursos associado ao cronograma, e a partir deste, nivelar os recursos. [4]

FIGURA 1.1[5]

FIGURA 1.2[6]

Existem alguns critérios básicos que devem ser seguidos para a elaboração do planejamento de um projeto (EAP) independente de qual seja o software utilizado, essas regras são muito importante para que a atualização do programa apresente o verdadeiro espelho do que está acontecendo com o projeto.

1– Desenvolvimento das entradas:

São as atividades principais, escritos no substantivo, que estará até ao 3ª nível da EAP (Estrutura Analítica do Projeto), do Inglês, Work breakdown structure (WBS). Esta 1ª etapa que vai até os 03 primeiros níveis da EAP carece de uma melhor apreciação para que a 2ª etapa seja elaborada por várias tarefas de referência que são os pacotes de trabalhos e por final as listas das atividades/ações que os verbos sejam escrito no infinitivo.

2– Estimar os recursos das atividades a serem utilizados pelas tarefas:

A tarefa deve ser acompanhada com os recursos previstos para sua execução de acordo com os índices de produtividades de referência conforme a aplicação de cada contratada, para que seja feito um histograma fiel ao cronograma de execução e não seja subestimados ou superestimados.

3– Definição máxima de dias a serem utilizados por atividades:

Como o prazo é uma das referências mais importantes para o acompanhamento do marco de entrega de um projeto, e as atividades devem ser estáticas conforme suas amarrações definidas em um software de planejamento que posteriormente poderá se tornar dinâmica no momento que acontecer algum imprevisto (risco) que por consequência deverá ser feita uma mudança em suas precedências, podendo aumentar o cronograma por conta de um gerenciamento deficiente. Como na maioria das vezes dos projetos as reuniões e atualizações do planejamento são feitas semanalmente, o período máximo ideal para servir de parâmetros a ser utilizado por cada atividade deveriam ser no máximo até 07 dias para que as pendências sejam retratadas o mais rápido possível. Caso grandes projetos tenham atividades superiores a esse período ou seja difícil de ser detalhada, essa mesma deverá ter seu prazo acordado entre os stakeholders e quando acontecer desta atividade estiver no caminho crítico do projeto necessitaremos de uma análise mais criteriosa e separada quanto ao seu impacto no projeto.

4- Sequenciamentos e dependências das atividades:

Para uma perfeita ordenação contínua na elaboração e execução do planejamento em um projeto será necessário que o planejador tenha o conhecimento de alguns itens primordiais como:

Sequenciamento das dependências das atividades a serem executadas:

• Término/Início= A atividade terminará antes do início da outra;

• Início/Término= É quando uma atividade só irá iniciar após o término da outra;

• Início/Início= Faz referência quando atividades podem iniciar juntas sem interferir no andamento de uma com a outra;

• Término/Término= São quando atividades irão terminar juntas.

Para uma definição eficaz da ordem lógica de execução das tarefas devemos sequenciar as atividades e criar o objetivo de identificar as dependências como:

• Obrigatória (mandatória). Relacionada a natureza das atividades. Não podem ser alteradas, podem ser restrições físicas, lógicas, contratuais ou da natureza do trabalho, ex.: não conseguimos chapiscar sem a parede está pronta;

• Arbitradas. São dependências definidas de acordo com a preferência da equipe do projeto. Estão baseadas nas melhores práticas, ex.: pintar as paredes da sala junto com as do quarto;

• Externas. Fatores fora do projeto, ex.: leis, regras, critério fora do escopo do que você foi previsto.

Fred Brooks (http://www.heptagon.com.br/5dgp-4) diz que "[...] Em projetos, todas as tarefas dependem de outras. Em seu livro "The Mythical Man Month" ("O Mito do Homem-Mês"), respondeu à pergunta sobre como os projetos atrasam: "Um dia por vez". Você já notou que se a data final do seu projeto desliza, é quase impossível recuperá-la? Você também já notou o quão fácil é atrasar, mas o quanto é difícil adiantar? Se já, então você entende os problemas criados pela dependência entre tarefas. Um efeito negativo causado pela dependência entre tarefas é explicado no seguinte exemplo. Você tem uma tarefa que foi estimada em 5 dias, incluindo a segurança, a inicia imediatamente e a completa "mais cedo". A pessoa que recebe sua saída está pronta para usá-la imediatamente? Geralmente não. Portanto, se você entregar os resultados em 3 dias, a próxima pessoa não vai tocá-los por 2 dias adicionais, porque ela não está agendada para começar a tarefa dela até aquele dia. Assim, a segurança embutida é perdida, mesmo com a tarefa sendo terminada antes. Para superar esse problema você precisa ter um sistema de projetos que garanta que todas as tarefas comecem, não quando elas estão agendadas para começar, mas quando as entradas necessárias estiverem disponíveis. Isso é especialmente vital com as tarefas no caminho crítico (ou na corrente crítica).

Outro efeito negativo causado pela dependência entre tarefas é bem conhecido na teoria da probabilidade, chamado de "probabilidade de eventos dependentes" (também conhecido por outros nomes). Essa teoria afirma que o tempo total requerido para eventos dependentes, em termos de probabilidade, é o produto da probabilidade de todos os eventos dependentes. Veja como isso impacta você (Figura 7). Se você tem três tarefas que são dependentes uma da outra, e cada uma tem uma chance de 90% de ser terminada no prazo, qual é a probabilidade de todas as três serem completadas no prazo? Cerca de 73%! Devemos calcular a probabilidade de terminar a Tarefa-1 (90%) e depois calcular a probabilidade de terminar a Tarefa-2, dada sua dependência com a Tarefa-1 (90% x 90% = 81%). Como pode ver, a probabilidade de terminar a Tarefa-1 e a Tarefa-2 no prazo é de apenas 81%. Podemos então calcular a probabilidade de completar a Tarefa-3, dada sua dependência com a Tarefa-1 e a Tarefa-2 serem completadas no prazo (90% x 90% x 90% ? 73%). Com apenas três tarefas, cada uma com 90% de chance de terminar como prometido, há apenas uma chance de 73% de terminarmos, de fato, todas as três como prometido. Não precisamos de muitas tarefas para alcançar uma probabilidade zero de terminar o projeto no prazo.

Você pode estar pensando: "Eu não tenho esse problema, porque eu realizo as tarefas em paralelo, em vez de em série." Vamos examinar esta solução (Figura 8). Se cada tarefa possui uma chance de 90% de ser feita como planejado, qual é a chance do projeto todo terminar no prazo? Sua primeira reação pode ser 90%. Porém, já que o término do projeto depende do término de todas as tarefas, devemos usar o produto de cada evento dependente para determinar o tempo provável de término. Neste caso, vamos multiplicar 90% de cada tarefa em paralelo, obtendo a mesma chance de 73% de término no prazo. Agora você pode ver porque tentar fazer com que cada tarefa termine no prazo não significa que o projeto terminará no prazo. Será exigido que toda tarefa dependente termine como planejado, para que o projeto termine no prazo. Esse efeito fez com que os gerentes de projetos concluíssem que a única forma de terminar um projeto no prazo é garantir que todas as tarefas, realmente, terminem no prazo. Tal solução exigiria que todas as tarefas sejam estimadas com 100% de precisão. Mesmo se isso fosse possível, faria com que os tempos das tarefas tivessem uma duração inimaginável.

Para entender melhor como os atrasos são passados adiante, mas os adiantamentos não, examine a Figura 9. Este projeto foi planejado para durar 17 dias. O quanto adiantado ele poderia terminar se a primeira tarefa estivesse cinco dias adiantada? Os mesmos 17 dias. A razão é que nós somos dependentes do término de todas as cinco tarefas. Portanto, mesmo se uma tarefa estiver adiantada, o projeto não terminará adiantado em nada. E se as primeiras quatro tarefas terminassem 5 dias antes? A duração do projeto ainda seria de 17 dias. Agora pense na duração do projeto se apenas uma tarefa atrasar 5 dias. O projeto levaria 22 dias. Como podemos ver, adiantamentos não são passados adiante, atrasos sempre são [...]".

• PROBLEMA

Vargas (2006, p.3) diz que "[...] É importante ressaltar que projetos problemáticos não são projetos fracassados. Projetos fracassados são irrecuperáveis, uma vez que foi atingido o maior nível de perda possível. De outro lado, o projeto problemático é passível de uma possível recuperação, apesar de apresentar uma forte indicação de que se eles não forem gerenciados de um modo peculiar, eles podem se degenerar rapidamente e se tornarem inviáveis.

Quando se aborda o termo "recuperar", o que se quer dizer é que existe uma possível recuperação e não que a recuperação é simples e fácil. Na figura 2 são apresentadas algumas percepções equivocadas sobre projetos problemáticos [...]".

"Todos os projetos têm um componente de incerteza. A incerteza é uma escala. Incerteza significa desconhecimento do resultado ou do caminho para chegar até ele, ou ambos. Quanto maior o desconhecimento, maiores a incerteza e o risco. A principal consequência da incerteza é a dificuldade de fazer previsões. Devido à incerteza, um projeto pode começar com definições imprecisas a respeito das três variáveis críticas do desempenho.

Certos projetos são feitos para lidar com a incerteza. É o caso dos projetos de pesquisa de medicamentos ou da cura de doenças, como câncer e AIDS. De forma geral, é o caso de qualquer projeto que seja realizado para resolver um problema. A solução é desconhecida no início. Esses projetos sabem se algum tipo de resultado vai ser conseguido. Tão grande é a incerteza, que a incapacidade de alcançar um resultado prático não é considerada fracasso, nem justificativa para interromper a pesquisa, mas uma forma de aprendizagem. Além disso, eventos imprevistos (como acidentes e interferências do poder público) podem retardar a conclusão do projeto. Por exemplo, muitos parques de diversões temáticos no Brasil desapontaram seus investidores, porque o custo final ficou muito acima do orçamento inicial, o poder público exigiu estudos de impacto ambiental, que retardaram a inauguração, ou, pior de tudo, o público esperado simplesmente não apareceu na quantidade prevista.

A incerteza inerente a todos os tipos de projetos é responsável pelo descumprimento de prazos e orçamentos. Um dos casos em que isso aconteceu em grande escala é o túnel do Canal da Mancha, que começou com um orçamento de 7 bilhões de dólares e terminou custando 14 bilhões de dólares. Outro exemplo é a barragem de Três Gargantas, na China, para a construção de uma hidrelétrica, que orçada em 8 bilhões de dólares e chegou a 30 bilhões. [...] (MAXIMIANO, 2002, P. 30).

1.3 HIPÓTESES

Certo momento de cada ano, dependendo da estratégica de cada empresa, são realizados um ritual periódico de planejamento em que os stakeholders reúnem-se para revisar o planejamento em curso e estabelecer objetivos e metas para o próximo período.

Cada stakeholders, naturalmente, conhece relativamente bem os detalhes da operação de sua área, mas, devido às pressões do dia-a-dia e às inevitáveis dificuldades de comunicação, seu conhecimento a respeito das demais áreas é quase sempre bastante fragmentário. Mesmo no que se refere a sua própria área, às vezes o executivo dispõe apenas de alguns indicadores mais ou menos confiáveis. Sobre a empresa como um todo, pode acontecer de ele ter que se dirigir à reunião com pouco mais do que os últimos balancetes. Assim, não é incomum que esses stakeholders vão para as reuniões de planejamento estratégico com a desconfortável sensação de que serão chamados a tomar decisões estratégicas com base em informações em quantidade insuficiente e de qualidade duvidosa.

O processo de planejamento utiliza diversas ferramentas para ordenar e guiar o pensamento e as discussões. Aqui ocorre o segundo mal-estar. Muitas dessas técnicas e ferramentas produzem resultados tão bons quanto os dados de entrada disponíveis. Ou seja, se a informação de entrada é incompleta ou inadequada, o resultado da aplicação das técnicas pode deixar a desejar.

Tomemos, por exemplo, a análise de forças e fraquezas internas da organização. Pode haver pouca informação confiável a este respeito. Durante as reuniões de planejamento estratégico, ideias são colocadas na mesa, hipóteses são levantadas e opções são discutidas. Infelizmente, a discussão sobre as opções muitas vezes é feita com base em hipóteses e pressupostos não verificáveis no momento das reuniões, sendo que, o que é pior, trata-se de informação disponível na empresa, mas não se sabe onde nem com quem!

É costume referir-se à Estratégia como "olhar a floresta em vez de olhar as árvores". O problema é que, no mundo real, não dá para entender a floresta sem conhecer bem as árvores também. Grandes decisões estratégicas podem ser técnica ou economicamente inviáveis quando sua implementação é desdobrada em detalhes.

Ao final do processo de planejamento estratégico, o gerente de projeto sai com um conjunto de metas que precisa alcançar em sua área. Neste momento, ocorre o terceiro mal-estar, pois é frequente que não saiba por onde começar. Afinal, é sabido que comunicar a estratégia e transforma-la em operação no dia-a-dia é um dos maiores desafios das organizações. Na falta de melhores instrumentos, acaba se restringindo a cobrar "mais empenho". Mas a implementação da estratégia tem que ser mais do que "vamos trabalhar mais duro".

Um exemplo concreto:

Suponhamos que a empresa esteja enfrentando um ambiente competitivo que se acirrou no último período e se vê sendo atacada com a perda do contrato e novos concorrentes tradicionais surgiram, e responderam de forma agressiva nos preços apresentado na licitação sabendo a existência do preço aplicado anteriormente e a não condição de pratica-lo, neste momento a nossa empresa deverá manter uma estratégica sabendo que levará uma guerra de preços.

Vamos supor que, no momento do planejamento estratégico, a nossa empresa disponha de informações razoáveis sobre o mercado. Ela precisa decidir o que fazer. Ao longo das discussões, surgem três opções estratégicas preferidas: 1.  Sondar os preços praticados no mercado e avaliar se os mesmos poderão ser aplicados e ao mesmo tempo preservar a rentabilidade.

2. Resguardar o contrato vigente de forma de não apresentar valores de alguns itens existentes para os concorrentes, Investir na redução de alguns gastos para manter uma estratégia de manter o mesmo preço, com foco em fidelização do cliente atual e manter o market-share;

3.  Apresentar um preço com os reajustes correto do mercado no período do segmento do mercado que serão explorados pelos concorrentes.

Como decidir entre estas opções? Na falta de informação completa e confiável sobre as forças e fraquezas internas da organização, é muito difícil.

Seria necessário responder a perguntas como:

. Quanto custa nossos processos de negócio? Quanto vai custar para reduzirmos os custos de nossos processos? Isso pode ser feito em um horizonte de tempo viável?

. Se optarmos pela estratégia de diferenciação, Eles podem ser racionalizados de modo a gerar reduções significativas de custo? Os processos, como são hoje, dão conta de sustentar esta estratégia? Se tivermos que mudar esses processos, quais os impactos? Que processos relacionados precisariam ser revistos? Quanto tempo vai levar e quanto vai custar? Nosso time de colaboradores possui as competências necessárias para sustentar esta nova estratégia? Podem ser capacitados? Quanto tempo vai levar e quanto vai custar?

. Da mesma forma, se optarmos por apresentar novos reajustes de mercado, poderemos perder o contrato.

Esses são apenas alguns exemplos de perguntas cujas respostas são essenciais para a tomada de decisão informada em um processo de planejamento estratégico. Mas essas respostas, muitas vezes, estão escondidas em lugares que os executivos planejadores não sabem nem mesmo por onde começar a procurar.[7]

1.4 JUSTIFICATIVA

Existem três dimensões, a saber, que são de grande valia com um comprometimento de um planejamento estratégico bem elaborado e consistente em suas informações, que são:

• 1. Social: Um projeto, por menor que seja, sempre será de grande importância nos fatores de atração e motivação de uma comunidade e para as pessoas envolvidas diretamente e indiretamente no projeto no sentido de alcançar algumas necessidades básicas em sua auto realização como fazer uma programação financeira contando com o prazo previsto e o crescimento financeiro, evolutivo e melhoria de qualidade de vida para a região, arrecadação de impostos e etc., mas em contrapartida se o projeto atrasa o seu marco contratual de conclusão, que seja por uma falha no planejamento, este fato irá ocasionar prejuízos financeiros a organização;

• 2. Acadêmico: Será um modo de contribuir para o aprimoramento pessoal, profissional e para tentar entender alguns motivos que possamos identificar no desenvolvimento de um planejamento.

• 3. Pessoal: Existe um prazer muito grande em dizer que foi um dos integrantes que participou da conclusão de um projeto em que o cliente ficou muito satisfeito quanto às condições em que o projeto entregue foi conforme previsto.

1.5 OBJETIVO

O enxugamento dos quadros de pessoal e o aumento da necessidade de especialização técnica têm levado muitas empresas a recrutar no mercado, profissionais por período determinado apenas para a execução de projetos específicos. Neste contexto, entender o processo de gerenciamento de projeto tem se tornado vital para organizações na medida em que mais e mais novos negócios vão se revestindo da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem sempre estão disponíveis nas empresas.

Um projeto é um empreendimento temporário, com data de início e fim, cujo objetivo

é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de forma

a atingir os objetivos propostos dentro de parâmetros de qualidade determinados,

obedecendo a um planejamento prévio de prazos (cronograma) e custos (orçamento). Ou seja, dadas às metas e as restrições de recursos e tempo, cabe ao

gerente de projetos garantir que ele atinja os objetivos propostos [...].

1.5.1 Escolha e adote uma metodologia

Uma metodologia é um processo a seguir que dá maior controle sobre os recursos

que serão utilizados no projeto. Controlando melhor o processo a equipe será mais

eficiente pois entregará o projeto com maior grau de acerto em termos de prazos e

custos. O bom uso de uma metodologia é importante porque permite evitar práticas

que levam ao insucesso e com isso reproduzir o sucesso [...].

1.5.2 Comunique-se: não é só o peixe que morre pela boca!

Quando falta comunicação, os boatos e outras formas de ruídos tomam seu lugar. Na falta de versão oficial, ficam circulando informações que podem minar a moral da

equipe e levantar suspeitas sem fundamento. O gerente de projeto deve evitar esse

tipo de prática, conhecida por "rádio-peão", dando informações claras e confiáveis

sobre o status do projeto. Certamente esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente de projetos pode e deve não só falar sobre

ele, mas também informar que está trabalhando na solução, e não apenas comunicar que o problema existe. Problemas sem uma perspectiva de solução são angustiantes e causam um desconforto na equipe que muitas vezes é desnecessário.

A criação de relatórios de progresso do projeto ajuda no processo de comunicação,

sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de

um e-mail onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do e-mail a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.

1.5.3 Defina o escopo do projeto e detalhe as atividades

O "escopo do projeto" é o trabalho que deve ser realizado para se obter um produto

ou serviço com determinadas características e recursos. Comece por definir o que

deve ser feito e o que não deve. Esse processo nos permite entender os contornos

do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve

ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam "perfeito". Sempre me

lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os

detalhes logo de cara, me dizia que "o ótimo é inimigo do bom", ou seja: enquanto

perseguimos o "ótimo" nos distanciamos de algo que está bem mais próximo, o "bom", é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc... mas não cabe na versão 1, que é o que estamos tentando

desenvolver neste momento ! Afaste o fantasma da perfeição.

Para você não se perder numa lista interminável de características da versão 1, uma

boa ideia é pedir ao cliente que liste só que o que é "absolutamente essencial". Claro

que se você der a ele 30 minutos para responder, tudo será "absolutamente essencial". Não adianta, temos de ser realistas, o tempo é curto é temos de escolher

só o que realmente é importante. Se "escrever é cortar" como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar

e o que reter do universo de necessidades do cliente.

Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as "unidades de trabalho" com tempo medido em dias ou horas de trabalho. Como

regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.

Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de

cada profissional serão necessárias. Veja um modelo simples:

Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase

do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando

ao projeto A quando for para entregar ao cliente e obter a sua aprovação[...].

Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo.

Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades

em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se

chama de "scope creep", quando o escopo vai crescendo a medida que o cliente vai

entendendo suas necessidades e reformulando seus objetivos. Há quem chame este

problema de "Jacques". Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: "já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto." O gerente do projeto deve ter calma e analisar com cuidado cada demanda:

ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode

estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão "elásticos" quanto as exigências. Devemos sempre contar com uma certa "margem

de manobra", mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita "gordura para queimar" e os compromissos assumidos

pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para

toda a equipe.

Em projetos de software, o "scope creep" é uma situação tão comum que não dá para começá-los sem tomar algumas precauções.

O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.

O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um "quase contrato", mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai

tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou "não é bem aquilo" e podem começar as decepções.

A satisfação do cliente depende em muito do que será dito e prometido no que se chama de "pré-venda". É neste momento que o gerente de projetos deve entrar em

cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema

deve ter e fazer. Este processo é o "planejamento de escopo" e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista,

mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar

toda a interface dos usuários com o sistema: telas e relatórios. Depois de "colocar

tudo no papel", o gerente deve obter do cliente um "de acordo", de preferência assinado no final do documento em que todas as páginas serão rubricadas com um

"visto" para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.

O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada

um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante

no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente

para definir o que ele considera "sucesso" do projeto. Por exemplo, num sistema em

que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios

suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se

de que: "o ótimo é inimigo do bom".

Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a

necessidade do cliente.

1.5.4 Conheça os envolvidos e monte seu time

Todos os envolvidos no projeto são os "stakeholders". Nesse grupo estão não apenas os membros da equipe, mas também os clientes e fornecedores envolvidos. Dentro da empresa do cliente, há uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela é que cria as condições para a contratação do projeto, mesmo que não seja ela que vá usar o produto final.

É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um "profissional" com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as "coisas têm de ser feitas do jeito dele".

No processo de definição do escopo, as habilidades necessárias vão ficando mais

claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do "líder de projeto",

um profissional com grande conhecimento técnico e com capacidade de liderança

entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights

que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado,

mesmo quando você errar.

1.5.5 Desenvolva o cronograma junto com quem põe a mão na massa

Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se comprometendo com um prazo para a sua execução. Por outro lado, quando se trabalha com consultores externos, o custo será função direta do tempo estimado para a execução do projeto. Ao fixar o cronograma, o profissional está dando por

tabela um orçamento da sua parte.

Se no planejamento da semana há tarefas que não foram realizadas, na reunião de

avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso

impacta na data final de entrega. Procure estabelecer pontos de controle, "checkpoints", que são datas onde se medirá o andamento do projeto em face do

cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades ("milestones") ou pode

haver entrega de produtos ou subprodutos ("deliverables") tais como desenhos, especificações, protótipos, modelos, etc..

1.5.6 Monitore os riscos e seja pró-ativo

Agora que todos sabem o que devem fazer, é importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são duas coisas: A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de

ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A

monitoração também se preocupa em avaliar a probabilidade de ocorrência de um

risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo,

numa determinada tarefa crítica a contratação de dois profissionais pode parecer um

exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto

o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que "quem tem um, não tem nenhum".

1.5.7 Formalize o início e o encerramento do projeto

O início do projeto é um momento solene. O patrocinador deve formalizar a todos os

envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se preocupar com isso, mas imagine que haja resistência de setores da empresa que se opõem ao projeto. Sem um documento que atesta que o projeto

começou, o gerente pode não conseguir apoio algum. Além disso, este documento

funciona como um "cumpra-se" de uma autoridade da empresa: não cabe discutir a

ordem, o projeto começou e todos os "arrolados" devem participar.

Outro momento importante é o do encerramento do projeto. É preciso formalizar o

final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos ("aviônicos") de um avião para auxílio ao voo é um projeto que se distingue da sua manutenção rotineira.

Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe.

Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista de "melhores práticas" contribuindo para a formação de uma base de conhecimento que

poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.[8]

2 DESENVOLVIMENTO:

2.1 Processos

Como não podemos considerar o PMBOK como uma metodologia, sendo assim, podemos utilizar como um manual que descreve o universo e as boas práticas de conhecimentos para o gerenciamento de projetos e podem ser aplicadas em todos os tipos de projetos, independentemente do segmento, área, dimensões, pessoas envolvidas, prazos e orçamentos.

2.2 Planejamento

"Falhando no planejamento, estamos planejando para falhar" (Kerzner)

Planejamento é um processo contínuo e dinâmico que consiste em um conjunto de ações intencionais, integradas, coordenadas e orientadas para tornar realidade um objetivo futuro, de forma a possibilitar a tomada de decisões antecipadamente. Essas ações devem ser identificadas de moda a permitir que elas sejam executadas de forma adequada e considerando aspectos como o prazo, custos, qualidade, segurança, desempenho e outras condicionantes. Um planejamento bem realizado oferece inúmeras vantagens à equipe de projetos. Tais como:

• Permite controle apropriado;

• Produtos e serviços entregues conforme requisitos exigidos pelo cliente;

• Melhor coordenação das interfaces do projeto;

• Possibilita resolução antecipada de problemas e conflitos;

• Propicia um grau mais elevado de acertividade nas tomadas de decisão.

"Preparar-se para o inevitável, prevenindo o indesejável e controlando o que for controlável" (Peter Drucker).

Em resumo, o tempo dedicado ao planejamento é vital para evitar problemas na fase de execução. O objetivo central do planejamento é minimizar a necessidade de revisões durante a execução.[9]

Existem três níveis de planejamento: estratégico, tático e operacional. Em uma empresa de sucesso, estes três níveis funcionam em conjunto e ocorrem na seguinte ordem: estratégia, tática e operação.

O planejamento estratégico tem um longo alcance e é executado pelos responsáveis máximos da empresa, que determinam os objetivos dentro de um prazo temporal (curto, médio ou longo prazo).

O planejamento tático tem um escopo médio na empresa e consiste no pensamento de como os meios ou recursos disponíveis podem ser utilizados para alcançar um resultado favorável. Normalmente este planejamento é uma tarefa de gestão, muitas vezes executada por administradores.

O planejamento operacional de alcance curto está diretamente ligado com a área técnica de execução de um determinado plano de ação.[10]

Podemos inferir que os três níveis de planejamento tem o seu método a ser elaborado e quem irá executá-lo e devem ter seu acompanhamento conforme cada área, o operacional é o mais importante quanto a sua aplicação, pois, será neste período que teremos o confronto do previsto com o realizado será onde iremos detectar a necessidade de qual plano de ação a ser executado, como: inserção de recursos, identificação de qual frente de serviço poderemos antecipar ou adiar, indagar se os índices aplicados estão conforme o executado, qual será a folga (negativa ou positiva) ocorrida no projeto, qual atividade impactará no término do projeto e outros detalhes que são de grande valia para resolvê-lo antes de uma tragédia maior.

2.3 Riscos

O entendimento de risco é como o próprio nome já é definido: são condições, fatos, ocorrências, ações, etc. que surgem em certo momento de um projeto que dependendo de sua qualificação, Prado (1998, p. 72) diz que "[...]:

• Risco Baixo: Expectativa de atrasos e excesso de gastos normais. Prejuízo baixo ou insignificante. Nenhum risco para a carreira/imagem do gerente de projeto.

• Risco Médio: Expectativa de atraso ou excesso de gastos fora dos planos. Prejuízo considerável para a empresa e para a carreira/imagem do gerente de projeto. Risco de o gerente do projeto ser destituído do cargo.

• Risco Alto: Expectativa de atrasos e excessos de gastos inaceitáveis. Chance de o projeto ser abortado. Carreira/imagem do gerente de projeto seriamente afetada [...].

Por motivo da existência do risco, devemos quantificar e neutralizar para criarmos uma oportunidade de reduzir as ameaças que afetam o projeto até mesmo que ela esteja intrínseca, mas, se tomarmos atitudes eficazes no momento do acontecido ou descoberta, caso contrário só tende a compreender em quase, leve ou total fracasso.

Existem alguns riscos rotineiros que ocorrem no decorrer do andamento do projeto que se fizermos uma análise prévia de qual será o grau de impacto, poderemos criar condições que faça diminuir ou até mesmo neutralizá-lo e são os que seguem abaixo:

• 1. Cronograma apertado:

Na maioria das vezes são impostos pela empresa contratante, por um setor da empresa ou por uma necessidade referencial.

• 2. Fornecedores:

Fazer um estudo quanto ao compromisso dos prazos prestados pela empresa contratada.

• 3. Disponibilidade de recursos:

Existem vários tipos de recursos causadores de problemas no projeto, que são os mobiliários, computadores, local de trabalho com condições de concentração, mão de obra direta e indireta, falta de capital, etc.

• 4. Interfaces com outros projetos:

Mesmo colocando uma folga entre um projeto que depende do término do outro, não será suficiente, caso não tenha um acompanhamento rígido quanto ao acompanhamento do planejamento no prazo mínimo de tolerância entre o término e início do outro.

• 5. Falta de poder ou competência do gerente do projeto:

A contratante em vez de contratar um gerente de projeto com as qualificações mínimas necessárias, recoloca um excelente coordenador ou gerente de setor da empresa para o projeto e acha que o mesmo desempenhará uma boa função como nas outras condições anteriormente executadas e é neste momento que o projeto corre o risco de fracassar.

2.4 Partes interessadas

"Os clientes de um projeto integram uma constelação de partes interessadas (ou stakeholders). Partes interessadas são todas as pessoas, organizações ou grupos que participam direta ou indiretamente de um projeto ou são por ele envolvidos ou afetados de alguma forma. Por exemplo:

• Equipe do projeto.

• Fornecedores de equipamentos e serviços para o projeto.

• Usuários do produto do projeto.

• Administrações superiores e acionistas da empresa em que se desenvolve um novo produto.

• Gerentes de unidades permanentes de uma organização, que emprestam pessoas para fazer parte da equipe do projeto.

• Habitantes de regiões próximas as obras ou onde são realizados eventos, como os jogos Olímpicos.

• Clientes que comprarão o produto do projeto.

• Contribuintes que fornecerão fundos para a realização do projeto.

• Organismos regulamentadores que interferem no andamento do projeto ou do produto.

• Embora o cliente tenha prioridade na definição de objetivos, certos projetos podem exigir e normalmente exigem a participação de todas as partes interessadas relevantes. Em certos tipos de projetos, a consulta dos stakeholders é obrigatória. É o caso das grandes obras de infraestrutura, que precisam da aprovação do poder público e das comunidades em que são instaladas [...]" (MAXIMIANO, 2002, P. 61)

2.5 Escopo

"O escopo congelado em um projeto e o abominável homem das neves tem algo em comum: ambos são mitos e desaparecem quando suficiente calor é aplicado" (Autor desconhecido).

Escopo é um termo utilizado para descrever em maiores detalhes o que uma contratada irá necessitar que fosse feito em um projeto e existe um modo que possa fazer para uma melhor visualização é a WBS (Work Breakdown Structure) ou EAP (Estrutura Analítica do Projeto).

A mudança do escopo não gera nenhum problema para o projeto, na maioria das vezes são utilizado para adequar o fato de execução com o planejamento e aplicando uma condição de melhoria como a postergação do prazo final de entrega, mais itens a serem executados e o aumento do valor do contrato.

2.6 Metodologia/Análises

Se há uma coisa em que bons gerentes de projeto estão se destacando – e eu quero dizer Gerentes de Projeto realmente bons – é resgatar projetos. De fato, quando as empresas se encontram com projetos saindo do controle, é hora de chamar a cavalaria. Se fôssemos comparar projetos mal executados a uma zona de combate, onde as tropas foram encurraladas pelo inimigo, então a única maneira de melhorar as coisas é enviar alguém com know-how no campo de batalha. Essa pessoa que tem a complexa missão de trazer todos de volta à segurança e replanejar tudo, para que as tropas possam voltar e colocar a sua bandeira no topo da colina que eles estão visando desde o início.

Essa introdução toda pode soar um pouco exagerada, mas para aqueles de vocês que participaram de reuniões em que as pessoas gritavam umas para as outras ou distribuíam a culpa para todos os demais, pois as coisas correram muito mal, você desejaria que todo o projeto tivesse sido abordado com disciplina militar desde o início. Então, vamos analisar os motivos pelos quais os projetos dão errados e como um bom gerenciamento de projetos pode salvar o dia.

Existem algumas perguntas que são utilizadas em momentos estratégicos de um projeto que ajudam muito em seu desenvolvimento e execução, mas, possui uma que quanto é dita é um sinal que existe ou existiu uma falha no projeto, esta pergunta é por que o projeto deu errado?

Bem, eles podem ir mal por uma variedade de razões, mas eles normalmente e universalmente falham por três razões principais.

Em primeiro lugar, eles falham porque não há um gerente de projeto profissional no comando. Em segundo lugar, eles também podem falhar quando existe um gerente de projeto profissional no comando, mas ele não é realmente o tipo de gerente que pode lidar com projetos do início ao fim. Em terceiro lugar, eles também falham quando há um gerente de projeto profissional no comando, mas ele não tem as habilidades ou experiência necessárias para lidar com as mudanças imprevistas, riscos ou problemas, como o gerente de projeto é uma peça principal e mesmo sendo um indivíduo que tem um grande conhecimento ou habilidade graças à experiência, digo, mesmo assim não é a única causa da falha no projeto, existem outros motivos que já foram retratados anteriormente como: riscos não identificados, comunicação ruim, falta de gestão dos stakeholders, falta de orçamento, prazo muito apertado, definição de qualidade ruim, etc.

Note-se que parar projetos ou revalidar seu escopo depois de uma grande mudança significa que os projetos tenham sido tratados de uma forma controlada, não que eles tenham falhado. Eles falham quando as coisas saem do controle por um período razoável de tempo

O que pode ser feito sobre isso?

Muito bem, você diz, mas em termos práticos, o que devemos fazer então? Se o seu projeto já está sendo executado e começa a fracassar, uma das alternativas que poderia fazer seria identificar imediatamente em sua rede (interna ou externamente), um gerente de projeto com um histórico de sucesso de entrega de todos os tipos de projetos ou se conseguir descobrir a falha é tentar diminuir o impacto ou elimina-lá, e logo em seguida, faça tudo o que puder para, pelo menos, ter essa pessoa verificando o seu projeto em poucos dias, para obter um feedback honesto e especializado. Se ele puder ter acesso a todos os stakeholders??, vai demorar apenas alguns dias para identificar as causas do problema e recomendar ações corretivas.

Geralmente, se não havia um gerente de projeto profissional envolvido, é mais provável que os problemas tenham sido causados por falhas no escopo do projeto, planejamento e/ou gestão. Na verdade, é frequente o caso em que a pessoa encarregada de gerenciar o projeto conhece mais sobre sua área específica do que sobre boas práticas e metodologias de projetos. Isso vai levar essa pessoa a assumir que qualquer coisa ele entregar para outra equipe está já não é sua responsabilidade. E é aí que tudo dá errado. Um bom gerente de projeto tem a responsabilidade global por todas as áreas do projeto. Portanto, se você está entregando um projeto de TI, e Sam, um engenheiro de TI foi convidado para gerenciar o projeto, ele também precisa estar preocupados com os usuários finais, com o contrato, os custos, sistemas e interfaces com outros departamentos. Assim, ele terá que trabalhar com seus colegas da área jurídica, de compras, pessoal de RH, etc., além das equipes de fornecedores.

E o que muitas vezes você vai notar é que Sam faz um ótimo trabalho no planejamento de sua parte de TI, mas apenas colabora superficialmente para as tarefas de outras equipes. Além disso, Sam, provavelmente, não está tendo contatos regulares com representantes de todas as equipes, consequentemente não tendo visibilidade em tempo real das tarefas em uma base frequente, e só irá descobrir tarde demais quando algo não está pronto ou funcionando.

Por isso, é altamente recomendável designar sempre um gerente de projeto profissional e treinado, para liderar projetos que envolvem a coordenação das atividades entre os vários departamentos e equipes. Muitas vezes, você vai ouvir as pessoas dizendo que não têm dinheiro para pagar por um gerente de projeto, pois seu orçamento do projeto já está apertado. Mas eles também não poderão pagar quando seu orçamento inicial e o tempo do projeto forem multiplicados por 2, 5, 10, ou até mais em alguns casos, na medida em que as coisas ficam fora de controle. Se tivessem investido em um gerente profissional desde o primeiro dia, eles teriam um plano realista e orçamento desde o início.

Mas o mais importante, independentemente de seu gerente de projeto ser um profissional ou um indicado pelas habilidades técnicas, o que realmente importa é que ele seja capaz de gerenciar o projeto do início ao fim. De fato, em companhias de grande porte ou em grandes programas de mudança, os gerentes de projetos são responsáveis ??por apenas uma ou algumas áreas, pois todas as outras áreas são cobertas por outros gerentes de projeto. Portanto, eles realmente só têm a responsabilização por uma parte do projeto, e não do todo. Daí porque, quanto mais o gerente de projeto tem exposição e responsabilidade pelo todo, melhor ele fica, e é mais provável que ele cresça na carreira e seja capaz de um dia dominar a disciplina complexa de "resgate de projeto".

 Soluções de gerenciamento de projetos para a construção civil

Os projetos de construção civil são, por vezes, gerenciados através do uso de documentos do Excel e Word e, embora essas organizações se sintam confortáveis com este sistema, eles podem estar escondendo alguns problemas dos gerentes de projeto. Com grandes volumes de detalhes do projeto que precisam ser monitorados, um sistema antiquado não é satisfatório no ambiente desafiador da construção civil. As soluções de gerenciamento de projetos específicos do setor têm sido implementadas em organizações para ajudar a gerenciar todos os elementos dos projetos de construção a partir de uma plataforma única.

Um projeto de construção civil não é uma tarefa fácil e requer uma gestão rigorosa e controle do início ao fim. Antes das soluções de gerenciamento de projeto serem utilizadas, uma grande quantidade de tempo e energia era necessária e, em alguns casos, um projeto podia fracassar se um processo não funcionava bem.

As soluções de gerenciamento de projetos tem a capacidade de lidar com todos os atributos complexos associados a um ciclo de vida do projeto de construção civil, incluindo custos, recursos e riscos através de fluxos de trabalho e gestão impecáveis.

O que um software de gerenciamento de projeto pode trazer para uma organização de construção civil e estendida para qualquer área de conhecimento?

1 - Eliminação de tarefas excessivamente longas: A tarefa de distribuir e receber dados em tempo real agora pode ser realizado instantaneamente, sem a necessidade de envio de vários e-mails para os membros da equipe do projeto solicitando atualizações. O gerente de projeto pode obter informações em tempo real com o clique de um botão. Se o software é baseado na web, esta informação pode ser captada a partir de qualquer computador portátil em qualquer local.

2 – Padronização de processos: Uma vez que uma ferramenta de gerenciamento de projetos é colocada em prática, um processo padrão pode ser definido e seguido facilmente por toda a equipe do projeto. Esta padronização irá documentar as tarefas que precisam ser completadas desde o início do projeto até a execução, e permitirá que novos usuários do sistema compreendam o sistema facilmente.

3 – Maior precisão: Uma data de previsão da conclusão de cada tarefa e do projeto como um todo pode ser mais precisamente elaborada uma vez que todos os elementos do projeto são inseridos na ferramenta de gerenciamento de projetos. Ao manter o projeto o mais próximo possível da data de conclusão planejada, o gerente do projeto irá contribuir para o sucesso do projeto e também evitar um efeito negativo sobre os projetos posteriores. Desta forma, o controle mais rigoroso dos prazos pode ser alcançado.

4 - Agendamento de recursos: O agendamento de recursos vinculados a um projeto pode ser uma tarefa difícil, pois muitos projetos podem ter 100 ou mesmo 1000 recursos. Coordená-los com uma ferramenta de gerenciamento de projetos pode garantir que apenas os recursos que são necessários sejam utilizados e também que os recursos não estejam sobre ou subalocados. Isto irá resultar em recursos sendo totalmente aproveitados e reduzirá os níveis de desperdício.

5 – Controle de documentos do projeto: Guardar os documentos do projeto em seu disco rígido local, e ter que enviar esses documentos para numerosos indivíduos ao longo do ciclo de vida do projeto não é o ideal e oportuno. Através de uma ferramenta de software de projetos, você pode localizar centralmente todos esses documentos relacionados ao projeto e fornecer aos membros da equipe do projeto as informações necessárias facilmente. O armazenamento de documentos desta forma garante que nenhum documento será extraviado ou perdido.

6 – Gestão de riscos: Em qualquer projeto, o risco pode se aproximar a qualquer momento, e os projetos de construção civil não são diferentes. Ao ter uma ferramenta de gerenciamento de projetos, a organização da construção civil pode gerenciar os riscos que surgem, por ter um processo passo a passo implementado para evitá-los e gerenciá-los.

Em geral, o software de gerenciamento de projetos para a construção civil fornece aos participantes da indústria uma série de benefícios, que eles dificilmente conseguiriam com os métodos tradicionais de gerenciamento. Ter esse local centralizado para gerenciar todos os aspectos de um projeto permite que as organizações melhorem a forma como fazem seu trabalho por meio de processos definidos, alocação de recursos, gestão de riscos, controle de documentos e muito mais.[11]

3 CONCLUSAO:

Quando os gerentes de projeto planejam implementações, eles muitas vezes não antecipam adequadamente o fracasso, apesar dos riscos associados a qualquer projeto. Em vez disso, eles planejam para os melhores cenários, impulsionado pelo orçamento, resultados, expectativas do patrocinador e prazos. E, apesar de seus melhores esforços no gerenciamento de projetos, as taxas de fracasso permanecem elevadas.

A implementação de projetos pode fracassar por uma série de razões – desde expectativas irrealistas, metodologia ruim, requisitos ruins, recursos inadequados, más práticas de gestão de projetos, equipes inexperientes, orçamentos irrealistas, falta de comunicação e muito mais. Com uma longa lista de fatores que podem levar ao fracasso, as chances de sucesso na implementação do projeto parecem baixas. Essas chances podem ser melhoradas com a adoção destas cinco melhores práticas. Elas irão ajudar a estabelecer um entendimento claro das expectativas entre todas as partes – sejam elas de negócios, patrocinador, equipe do projeto, aos parceiros fornecedores e usuários finais.

1 - Problemas organizacionais e de negócios precisam ser identificados e analisados ??com clareza e sem emoção. Este processo deve ser contínuo durante todo o processo de implementação. Não deve haver barreiras, seja entre a equipe de negócios e de desenvolvimento ou com fornecedores terceirizados. Todos os interesses dos stakeholders devem estar alinhados com o objetivo comum de sucesso do projeto.

2 – Não defina cronogramas excessivamente agressivos ou otimistas. Gerentes de Projeto, frequentemente definem datas de implementação excessivamente otimistas, apesar das limitações reais do projeto. Por exemplo, mesmo quando a fase de concepção do projeto se infiltra na fase de desenvolvimento e execução, o cronograma não acompanha esta realidade. O andamento do projeto deve ser monitorado ao longo da implementação. Discussões sobre datas importantes do projeto devem começar no início do ciclo de vida do projeto para evitar impactos a jusante.

3 – Se o monitoramento e controle contínuo não forem feitos, o que parece "sinal verde" pode vir a ser "sinal vermelho". Monitoramento em tempo real e análise do progresso da implementação do projeto podem ajudar a identificar gatilhos de risco no início e indicar os pacotes de trabalho ameaçados. Os indicadores devem mostrar não apenas o desempenho da fase anterior, mas também devem indicar a prontidão para as tarefas do projeto e atividades futuras. Indicadores e métricas de um projeto não devem ser apenas marcadores do passado, mas também indicadores do futuro.

4 – Fundamental para manter o controle do projeto, um gerente de projeto precisa definir e gerenciar as expectativas do projeto. Datas de implementação muito otimistas, menos recursos do que necessário, e uma quantidade impossível de produtos a entregar devem receber um estrito "não". Da mesma forma, não deve haver margem para qualquer "gold-plating" (adicionar itens que não estão no escopo). Os gerentes de projeto devem estabelecer expectativas realistas desde o início e manter as expectativas atuais claras nas mentes de todos os stakeholders para que eles não percam de vista o produto final ao atravessar o ciclo de vida do projeto.

5 – As auditorias e avaliações realizadas por um auditor externo agregam valor à implementação do projeto e o protege contra o fracasso. Estas auditorias fornecem supervisão objetiva e as soluções necessárias para superar obstáculos inerentes. Ela também ajuda a aliviar as suas dúvidas e receios. Essas auditorias devem ser conduzidas por um especialista em implementação que gerenciou projetos semelhantes com sucesso e pode facilmente identificar os indicadores que podem apontar para os erros e ajudar a desenvolver possíveis soluções.

Empregar essas melhores práticas irá capacitar um Gerente de Projeto a ir além das barreiras regulares de gerenciamento de projetos e lhe fornece os processos que precisa para garantir o sucesso do projeto. Isso o ajuda a identificar e resolver as questões estratégicas, táticas e intangíveis, e gerenciar os recursos humanos antes que se tornem problemas insuperáveis. E o melhor de tudo, proporciona clareza e certeza de que o projeto está no caminho certo.[12]

4 REFERÊNCIAS

DAVID, P. N.; KAPLAN, R. S.; A estratégia em ação – Balance scorecard, 18ª edição, Rio de Janeiro, Editora Elsevier, 1997.

KERZNER, Harold. Project management: a systems approach to planning, scheduling, and controlling. 6th ed. New York: john Wiley & Sons, 1998. 1180p.

MAXIMIANO, A. C. A.; Administração de projetos – Como Transformar Idéias em Resultados, 2ª edição, São Paulo, Editora Atlas, 2002.

OLIVEIRA, D. P. R.; Administração estratégica na prática – A competitividade para administrar o futuro das empresas, 6ª edição, São Paulo, Editora Atlas, 2009.

OLIVEIRA, D. P. R.; Planejamento estratégico – Conceitos metodologia práticas, 27ª edição, São Paulo, Editora Atlas, 2010.

PRADO, D.; Planejamento e controle de projeto, Vol. 2, Belo Horizonte, MG, editora de desenvolvimento gerencial, 1998.

THOMPSON JR, A. A.; STRICKLAND III, A. J.; Planejamento estratégico – Elaboração, implementação e execução, 1ª edição, São Paulo, Editora Pioneira, 2002.

VARGAS, R. V.; Identificando e recuperando projetos problemáticos: como resgatar seu projeto do fracasso, Revista Mundo PM, Curitiba, 2006.

WOILER, S.; MATHIAS, W. F.; Projetos – Planejamento, elaboração e análise, 1ª edição, São Paulo, Editora Atlas, 1996.

 

Autor:

Waldir Moreira da Silva

waldirbh[arroba]hotmail.com

(Discente)

Gerenciamento de projeto

Prof. Orientador Ãngelo José Albino Braga

MBA em Gerência de Projetos pela FGV. Especialista em Desenvolvimento de Negócios e Soluções de TI, Identificação de Oportunidades e Gestão da Tecnologia da Informação. Professor de pós-graduação da instituição FGV-RJ

---