GESTÃO DE PROJETOS- UNIDADE 2

Prévia do material em texto

GESTÃO DE PROJETOS
PLANEJAMENTO DE PROJETOS 
UNIDADE 2
Professora: Debora Barbosa Fernandes de Carli
COMO DEFINIR O ESCOPO DO PROJETO? 
O desenvolvimento do TAP – termo de abertura do projeto – é o primeiro processo do ciclo de vida do projeto, é considerado o pontapé oficial, confirmando que o projeto deve iniciar.
O termo de abertura do projeto, ao formalizar o início do projeto, concede ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas atividades de desenvolvimento, quando falamos de escopo estamos falando que  são os recursos e funções definidos de um produto ou o escopo do trabalho necessário para concluir um projeto.
Deste modo, o PMI (2013) elenca alguns pontos que devem estar exemplificados no TAP:
a) Propósito e justificativa do projeto.
b) Objetivos mensuráveis do projeto.
c) Lista geral dos requisitos.
d) Descrição geral do projeto.
e) Lista geral do nível de riscos.
f) Resumo do cronograma de marcos.
g) Resumo do orçamento.
Planejamento de Projetos: O planejamento de projetos é um conjunto de práticas que têm o objetivo de detalhar o que é necessário para tirar o projeto do papel. Um projeto pode ser planejado do início ao fim, de uma única vez, ou de forma iterativa, a cada ciclo (também chamado de sprint).
INTERPRETANDO UM TERMO DE ABERTURA DE PROJETOS 
O que é o TAP, Termo de abertura do Projeto?
Para que serve o TAP? Dúvida comum de quem começa a navegar pelo mundo da Gestão de Projetos, mundo recheado de siglas e terminologia bem peculiar.
O TAP, ou Termo de Abertura de Projeto é um documento importante para o registro do começo do projeto, além de determinar este pontapé inicial, o TAP também define quem será o responsável pela Gestão de Projetos, bem como seus poderes, limites, recursos disponíveis e restrições no que tange ao planejamento e execução do projeto.
Características do TAP
Formalmente reconhece (autoriza) a existência do projeto.
Dá ao gerente do projeto a autoridade necessária (para gastar dinheiro e alocar recursos corporativos).
Define o escopo do projeto de maneira geral.
Necessita participação efetiva do sponsor (patrocinador), para legitimar os poderes atribuídos ao Gerente de Projeto
Genérico o suficiente para não ser modificado a qualquer pequena mudança no projeto, mas capaz de fornecer uma boa visão do projeto.
Como regra prática, uma mudança no Project Charter gera a necessidade de se reavaliar a viabilidade do projeto.
Pode, em determinados casos, ser substituído por outro documento (contrato).
O que deve conter o TAP?
A lista abaixo é uma sugestão de campos a serem inseridos no TAP. Faça as devidas avaliações e adaptações para o contexto de sua organização.
Justificativa para o projeto
Objetivos mensuráveis e critérios de sucesso associados
Requisitos em alto nível (genéricos)
Descrição do projeto em alto nível
Riscos de alto nível
Cronograma de marcos sumarizado
Orçamento sumarizado
Requisitos de aprovação do projeto (o que significa sucesso para o projeto, quem decide se projeto foi bem sucedido)
Percebe-se que, apesar do bom trabalho executado em alto nível estratégico, o TAP apresentado precisa ainda de uma análise do ponto de vista de gerenciamento de projetos.
O primeiro ponto é a análise de stakeholders. Há uma lista de stakeholders, mas não uma hierarquização de quais que devem ser levados em conta e em qual nível de autoridade. Assim, o gerente de projeto pode usar um quadro, conforme exemplo apresentado a seguir, e assim, esclarecer o nível de influência e interesse de cada stakeholder. 
Pontos de ambiguidades podem ser anotados como premissas de projeto para posterior averiguação. Sempre que houver dúvidas, o gerente de projeto deve anotar e formalizar. Seguem alguns exemplos:
1. Premissas:
• P1- Diretor comercial irá participar de reuniões de estruturação do plano de projeto ao menos 2h por semana de reunião presencial ou videoconferência.
• P2- Apenas UMA loja será escopo desse projeto e as demais lojas terão projetos específicos, dado que a meta é 20 lojas.
• P3- O recrutamento e seleção de pessoas não será escopo desse projeto, sendo responsabilidade do diretor de pessoas.
• P4- O orçamento estará à disposição do gerente de projeto de forma integral no início do projeto. P5- Existe um manual de padronização de lojas e o projeto não precisará criar ou discutir essas normas.
• P6- A empresa está sem qualquer pendência jurídica e tributária para a emissão do alvará na prefeitura.
• P7- O projeto não incluirá gerenciamento dos primeiros dias de vendas e inauguração. A loja será entregue para a equipe comercial que imediatamente gerenciará a inauguração e operação da loja.
O planejamento do projeto se inicia a partir da decomposição do seu escopo em partes menores, que chamamos de pacote de trabalho. Estas partes menores são ordenadas, quando possível, a fim de paralelizar estas atividades para que seja possível estimar suas durações e custos .
Apesar da aparente simplicidade dessa questão, muitos detalhes e variáveis impactam positiva e negativamente na qualidade do planejamento.
Um ponto importante antes de esclarecer os procedimentos para realizar um planejamento de projeto é ter em mente que um plano está sempre suscetível a mudanças e a oportunidades de melhoria, uma vez que o plano é elaborado e está proporcionalmente relacionado ao conhecimento que o gerente de projetos tem naquele momento do projeto.
Costuma-se dizer, que o plano representa apenas um retrato momentâneo das ações que serão realizadas, e que o ato de planejar é contínuo e não somente em um determinado ponto do projeto.
O planejamento do projeto então, tipicamente, se inicia com a elaboração da estrutura analítica de projeto, denominada EAP. 
Essa decomposição em partes menores pode ser obtida de várias maneiras, geralmente, é decomposta com profissionais especialistas no domínio do problema neste ponto, destaca-se que o gerente de projetos tem a função de facilitador do projeto na decomposição e não necessariamente é dele a responsabilidade de liderar o movimento.
A estruturação da EAP poderá durar muitas horas de esforço, ou até mesmo meses, para sua conclusão, dependendo da complexidade do projeto. As reuniões então são frequentes na vida do gerente de projeto para que ele consiga apoiar os especialistas e chegar a uma estrutura analítica de projeto condizente com os objetivos definidos, uma vez que a EAP serve de insumo para a elaboração dos cronogramas, orçamentos e demais artefatos que compõe um planejamento de projeto.
O mais importante na escolha das técnicas de construção da EAP é justamente a sua associação aos objetivos de projeto, muitas vezes, a equipe de projeto decompõe a entrega em partes menores e tecnicamente adequadas, porém estas não estão associadas, suficientemente detalhadas ou não consideram as características do projeto que interessaram os objetivos pelos quais o projeto foi financiado. 
A etapa de divulgação do projeto pode ser também decomposta em partes menores, sendo uma operação mais complexa com várias horas de esforço, envolver várias pessoas e sistemas de informações, nesse momento, existe a necessidade de desdobrar essa atividade em partes menores, porém a equipe do projeto alfabetização (pedagogos) que participaram do primeiro nível de decomposição da EAP talvez, nesse quesito de divulgação do projeto, não
tenham conhecimentos e habilidades suficientes para detalhar o projeto de uma forma precisa. 
Não existe uma maneira objetiva de determinar a granularidade quando um pacote de trabalho irá ser desdobrado, pois este depende da percepção do gerente do projeto e principalmente do conhecimento adquirido para que ele
consiga elaborar os seus planos de trabalho em conjunto com a equipe, existe uma premissa de mercado em que os pacotes de trabalho não podem ser inferiores a quatro horas e superiores a quarente horas. 
Se o pacote de trabalho foi desdobrado em partes menores do que quatro horas, existirão muitas atividades de projetos a serem controladas e gerenciadas, o que tornao trabalho do gerente de projeto bastante desgastante e árduo. Outro ponto importante é referente a pessoa que está executando o pacote de trabalho, talvez ela levará muito mais tempo reportando quanto custou cada atividade, qual a duração e quais são as próximas atividades a serem realizadas, perdendo assim autonomia profissional, ou seja, pacotes de trabalho menores do que quatro horas geram um desgaste gerencial desnecessário e não trazem benefícios para o projeto.
Já pacotes de trabalho acima de quarente horas dão autonomia para a equipe, porém, o gerente de projeto pode levar muito tempo para detectar que um determinado profissional ou a equipe está com problemas ou com falta de entendimento sobre a atividade que está sendo executada. 
Uma vez estabelecidos os componentes que formarão o escopo do projeto, passa-se então à atividade de organização desses componentes de uma forma lógica, o próximo passo é a ordenação dos pacotes de trabalho, em que se procura identificar as atividades que serão realizadas primeiro e aquelas que serão deixadas mais para o final do projeto, o que chamamos de sequenciamento de atividades.
Logo depois são realizadas as estimativas de projeto, que na verdade, são estimativas do conjunto de atividades identificadas como pacotes de trabalho dentro da etapa de estrutura analítica de projeto. 
Existem muitas maneiras de realizar o sequenciamento de atividades, mas essa ordenação dependerá do ciclo de vida adotado no projeto.
As atividades podem ser organizadas pelas atividades que têm uma dependência entre si, por exemplo, para se contratar professores para o projeto educacional é necessário, como atividade anterior, descrever o perfil desse profissional, as habilidades, competências e atitudes desejadas.
Desse modo existem quatro formas de identificar dependência de atividades (CUKIERMAN, 1977), porém a maioria dos casos recai sobre a dependência do tipo “terminar para iniciar” (FTS – Finish to Start), que se baseia
no sentido de que uma atividade tem que ser encerrada para que a subsequente possa ser iniciada. 
 Essa é a dependência mais clássica e mais utilizada no gerenciamento de projetos. Pode-se dizer até que, para projetos de baixa e média complexidade, somente esse tipo de dependência é suficiente. 
Não existe um prazo exato para determinação das iterações, recomenda- se algo em torno de duas semanas, ou seja, a cada duas semanas a equipe irá apresentar aos usuários uma entrega parcial do projeto, que representa um avanço contínuo rumo ao final bem-sucedido. Essa organização pode ser obtida pelo uso de uma linha do tempo em que se dispõe os marcos do projeto, as iterações e as entregas das atividades. Ressalta-se que o mais importante são os marcos. Após esses marcos as iterações e somente com a determinação desses elementos de progresso é que se buscam as atividades que farão que essa entrega seja positiva, neste sentido, busca-se primeiro o que precisa ser feito e depois, como esse objetivo será alcançado. 
Os objetivos são representados por perguntas ou indicadores, e os meios indicados pelas atividades de projeto. 
Como dica geral, recomendam-se primeiro as atividades de maior risco, depois as de alto valor agregado e por fim, adequar as dependências lógicas, mas cada projeto, é um projeto diferente e essa ordem pode ser alterada. 
ESTIMATIVAS DE PROJETO 
As estimativas de projeto são, na verdade, as estimativas do conjunto de atividades identificadas como pacotes de trabalho dentro da etapa de estrutura analítica de projeto.
Existem muitas técnicas para estimar o esforço e o tempo de projetos, porém é importante mencionar que nenhuma técnica é definitiva, ou seja, as estimativas de projeto são suposições que o gerente de projeto realiza para que consiga elaborar um plano e acompanhar a execução. 
Um erro comum de gerentes de projetos iniciantes é o esquecimento de que essa estimativa é uma suposição, após as estimativas, elaborados planos de trabalho, cronograma e atualizados os softwares de apoio à decisão, as estimativas são tidas pelos stakeholders, e pelo próprio gerente de projeto, como verdades absolutas, caso haja um desvio dessas estimativas durante a execução, logo se deduz que o problema está na execução, porém essa premissa é um erro clássico em gerenciamento de projetos.
Muitas vezes, o gerente e a equipe de projeto precisam estimar os projetos sem todas as informações possíveis. Na verdade, essa situação de trabalhar com informações incompletas é quase regra em projetos, pois os stakeholders querem o mais brevemente possível um plano fechado para conseguir tomar a decisão do seu financiamento ou não. 
É importante no início do planejamento, durante as estimativas e principalmente na formalização de cronograma, orçamento e demais planos de trabalho, que os stakeholders sejam ostensivamente comunicados que as estimativas são baseadas em pressupostos, é importante destacar que o planejamento é um contínuo exercício de expansão de conhecimento no gerente de projeto e na sua equipe sobre os objetivos e alternativas possíveis para sua execução. 
Na execução de projetos com ampla base histórica, o gerente de projeto obviamente pode fazer uma estimativa baseada no passado, ou seja, identificar quanto levou cada um desses projetos já realizados em termos de prazo e custo.
Essas estimativas são confiáveis e terão desvios baixos devido à eventos pouco prováveis.
Esse tipo de estimativa é chamado de estimativa paramétrica, que são esforços estimados pela sua relação de uma entrega física, como o metro quadrado numa construção civil, o metro linear na construção de um muro, deste modo, ressalta-se que estimativas paramétricas são confiáveis desde que exista um conjunto de eventos passados em que se possa tomar uma decisão. 
CRONOGRAMA E ORÇAMENTO 
Uma vez que identificamos os objetivos do projeto, construímos a estrutura analítica de projeto, identificando assim os pacotes de trabalho e posteriormente realizando uma estimativa de nível de esforço e equipe envolvidos com o projeto, é possível a construção de cenários de cronogramas e orçamentos para o projeto.
Um primeiro ponto importante a ser destacado é a questão de cenários que devem ser legitimados junto ao stakeholder e também o entendimento de que o cronograma e o orçamento na verdade são resultantes de vários fatores do projeto. 
Em projetos inovadores, nos quais exista uma grande incerteza não possa ser especificados e estimados, muitas vezes, o patrocinador e o gerente de projetos podem tomar a decisão de somente aprovar um cronograma inicial dos primeiros marcos do projeto para depois, com mais informações e conhecimento, poder elaborar o cronograma completo do projeto.
O gerente de projetos apesar de apresentar múltiplos cenários deve sempre emitir a sua opinião sobre qual a proposta que ele e sua equipe entendem como a melhor para o projeto, isso é um compromisso ético e profissional do gerente de projetos uma vez que premissas estão por trás daqueles valores de esforço, prazos e custos do projeto, outro ponto a se destacar é, cronogramas e orçamentos são resultantes de uma combinação de fatores e decisões dentro do projeto, essas decisões podem ser melhor entendidas pelas áreas de conhecimento da gestão de projetos, o cronograma e o orçamento na verdade são resultantes das decisões da composição da equipe de projeto. 
Lembramos que todas as atividades de planejamento são direcionadas para o alcance de objetivos de um grupo de pessoas, caso haja uma alteração, tanto de pessoas e patrocinadores intervenientes, bem como os seus interesses, estas alterações podem afetar o cronograma e o orçamento.
Existem muitas formas de apresentação de cronograma, a mais clássica em gestão de projetos é por meio de gráficos de Gantt, onde visualmente cada atividade do projeto é apresentada por meio de quadrados e, cada quadrado, representa um período de tempo (PRADO, 1998). 
Estes períodos de tempo geralmente são representados por dia, então uma atividade planejada para execuçãoem três dias será representada em três quadrados, um ao lado do outro, e assim sucessivamente para cada atividade, é valido lembrar que que a simplicidade na apresentação ao stakeholder deve ser sempre um vetor importante, pois um cronograma e toda sua complexidade precisam ser explicados pelo gerente de projetos. 
A linha de base de projeto é um termo usado em gestão de projetos para representar uma versão de um conjunto de artefatos gerenciais que compõe o plano, geralmente, a linha de base representa o cronograma e o orçamento,
mas também todos os documentos em sua última versão que originaram esses orçamentos e cronogramas, a citar termo de abertura de projeto, estrutura analítica de projeto, estimativas, premissas e sequenciamento das atividades, entre outros que possam surgir a cada caso de uma maneira particular, então, a linha de base é na verdade uma fotografia de todos os documentos gerenciais que foram escolhidos para tomada de decisão e assim, caminha-se para a execução do projeto. Essa fotografia é importante para que, durante a execução do projeto, desvios possam ser identificados e uma decisão possa ser tomada para uma ação corretiva a fim de recompor a execução mais perto do plano ou apresentar solicitações de mudanças para que consiga ter uma nova linha de base. 
PREPARANDO PARA A EXECUÇÃO 
Uma vez determinada a versão dos documentos que irão compor a linha de base, passa-se a pensar na parte da execução do projeto, o primeiro fator de importância na execução é que a equipe esteja comprometida com o planejamento do projeto, essa questão é importante pois, muitas vezes, o gerente de projeto isola a equipe de determinadas decisões e compõe um planejamento que não é parte integrante do pensamento da equipe, esse é um dos principais fatores que podem complicar a execução de um projeto, um conjunto de planejamentos em que a equipe não acredita na viabilidade daquele cenário, uma vez que essa aceitação formal é sugerida, que seja realizada por meio de uma reunião e depois um envio de e-mail para que todos consigam responder ao seu “de acordo”, caso haja alguma divergência de opinião, o gerente de projeto precisa iniciar uma negociação e saber se a objeção de um integrante da equipe, ocorre por alguma fragilidade no planejamento ou se trata de um receio de que o planejamento não esteja ideal. 
O gerente de projeto não deve fazer o uso da sua autoridade para impor um planejamento, pois, na melhor das hipóteses, criará um conflito no momento do uso da sua autoridade, mas o pior cenário é que o gerente de projeto faça uso da autoridade e a equipe apenas finja que está aceitando o planejamento, mas no fundo do seu entendimento, a equipe não acredita naquele plano, esse é o pior cenário, pois durante a execução, caso haja qualquer desvio, seja de execução ou de planejamento, a equipe não irá se comprometer a trabalhar com contingências que necessitam algum tipo de dedicação e esforço a mais do que o planejado, uma vez que aquele plano não foi aceito de uma maneira explícita, mas sim o plano foi imposto pelos stakeholders e pelo gerente de projeto. 
 
PLANEJAMENTO DE COMUNICAÇÃO 
Um fator importante ao se planejar a execução é a questão da gestão da comunicação. 
A gestão da comunicação passa pelo planejamento das informações que precisam ser trafegadas entre a equipe, entre os stakeholders e, em alguns casos, com atores externos como clientes sociedade e mídia.
A gestão da comunicação precisa ser planejada e se inicia pela definição dos elementos que devem ser comunicados e quais os atores participantes. Toda comunicação também tem um meio e um veículo pelo qual as informações serão trafegadas, algumas vezes de uma forma unidirecional.
Os elementos de comunicação devem ser identificados para saber quais são aqueles que irão ter uma comunicação planejada, de uma forma atípica, os projetos precisam de um repositório de documentos, onde o gerente de projeto
irá dispor os documentos oficiais dos projetos aprovados e aqueles que estão constantemente sendo digitados e editados.
É importante saber e configurar regras na ferramenta utilizada para que alguns documentos sejam somente leitura da equipe e algumas outras pastas e documentos possam ser editados por qualquer membro da equipe, outra funcionalidade importante na questão de gestão dos pacotes de trabalho é ter um status de progresso da atividade. Recomenda-se que use o sistema Kanban, ou seja, quais atividades que estão esperando a pessoa liberar
para iniciar a execução, quais são as atividades e pacotes de trabalhos que estão em execução, quais estão aguardando validação e quais estão concluídos, esses são os estados típicos de gestão de projetos, mas podem ser customizados para cada situação. 
PLANEJANDO A QUALIDADE 
A gestão da qualidade em projetos é de suma importância para o alcance dos objetivos pelos quais o projeto existe, porém, a qualidade é uma das áreas de conhecimento do PMI que deve ser criteriosamente pensada e analisada para que o nível de formalismo esteja compatível com as necessidades de projeto e com a maturidade da organização. Nos tópicos anteriores, nós observamos as práticas em gestão de projetos que dificilmente um projeto, de qualquer natureza, não realize. Ou seja, a necessidade do termo de abertura de projeto, estrutura analítica, estimativas, premissas que suportam aquelas estimativas e elaboração de um cronograma e orçamento são praticamente fundamentais para qualquer tipo de projeto, salvo raras exceções.
 Entretanto, em alguns projetos há uma necessidade de formalizar as práticas de qualidade e essa sessão destaca esses pontos. 
Reitera-se que as práticas a seguir devem ser criteriosamente adequadas a cada contexto do projeto e da organização, ou seja, praticar todas as técnicas de qualidade em uma empresa que está iniciando a sua trajetória em gestão de projetos pode provocar efeitos colaterais indesejáveis, como lentidão e o excesso de preciosismo acadêmico e teórico, sem os resultados práticos as quais ela se destina (ANTÓNIO; TEIXEIRA, 2007). A gestão da qualidade iniciou-se nos estudos organizacionais sendo basicamente a redução de defeitos, e em um aspecto contemporâneo, a qualidade passou a significar o mais próximo do desejável pelo usuário final (JURAN, 1997). Dessa forma, a qualidade deixou de ser uma dimensão objetiva, como simplesmente um indicador de falhas e erros de projeto, para ser um conceito relacionado à percepção de uma pessoa, com isso existe uma grande carga subjetiva do que vem a ser qualidade (CARVALHO; PALADINI, 2013). 
Além desse aspecto, existe não só a questão da subjetividade, mas a percepção dos stakeholders específicos de cada projeto, tornando assim a qualidade um conceito que dificilmente conseguirá ser definido de uma maneira detalhada de forma universal. A qualidade, então, significa as formas de organização dos recursos para o alcance dos objetivos estratégicos. Para ilustrar, de uma maneira simples, essa conceituação da qualidade, pode-se imaginar uma situação na qual existe um produto de baixo nível de erros, um produto quase perfeito, porém, o custo dele é muito alto, impossível até de uma pessoa de classe média alta adquiri-lo. Imagina-se então um outro produto, que tenha algumas falhas contornáveis em seu uso e com um custo bastante acessível ao usuário final, podendo assim ser comprado.
A reflexão que fazemos é: Qual é o melhor produto? Qual é o produto de melhor qualidade? Essa simples exemplificação coloca dentro do conceito da qualidade múltiplas dimensões, como o preço final. Iniciantes poderiam dizer que são duas dimensões distintas, que a qualidade se remete a apenas produzir o produto mais próximo do ideal em termos de funcionalidades e erros, mas profissionais mais experientes entendem que um produto de qualidade é um produto melhor avaliado por muitas dimensões, ou seja, não adianta termos um produto com baixíssimo nível de erros se o seu custo se torna impeditivo para seu usufruto e que o prazo para sua execução seja inviável para se colocarno mercado. Essa definição de qualidade no seu aspecto multicritério é fundamental, pois a qualidade não se trata apenas dos objetivos a que se propõem o projeto, mas sim de como os recursos serão dispostos. 
Não adianta estruturar um planejamento no qual haja uma busca incessante de testes e correções em busca do produto perfeito, isso poderia tornar o orçamento e cronograma inviáveis. Por isso, muitas vezes, a qualidade é deixada de lado, no seu aspecto formal, pois algumas organizações e gerentes entendem que a qualidade deve estar desassociada de outras dimensões e que são conflituosos entre si. 
Assim, o primeiro passo do planejamento da qualidade é analisar os objetivos do projeto. Esses objetivos devem ser desdobrados em partes menores, como se fosse uma estrutura analítica de projeto, mas em busca não dos pacotes de trabalho, mas sim de pontos de vistas menores que possam ser avaliados por indicadores de desempenho. Esses indicadores de desempenho são escalas ordinais que ilustram a preferência de um decisor em relação ao projeto. Por exemplo, é preferível que o projeto atrase 5% do que 20%, tendo então uma escala de preferência decrescente, ou seja, quanto menor, melhor