A Importância do Detalhamento do Escopo

A definição do que deve ser feito no projeto, ou seja, a definição do escopo é crucial. Essa definição está ligada ao objetivo do projeto e seu detalhamento tem impactos na duração e no custo do projeto.

 

De modo geral, no método waterfall (queda dágua ou cachoeira), o projeto é feito em etapas sucessivas, e não passamos para a etapa seguinte sem que a etapa anterior seja completada. A definição do escopo é feita na etapa inicial. Na etapa de planejamento – que vem depois – o escopo é detalhado e decomposto em entregas. Ainda no planejamento é estabelecida a ordem que as entregas serão executadas, sendo isso registrado em um cronograma. Em seguida, o escopo é executado, entrega após entrega, na ordem definida no cronograma. Cada passo do projeto é devidamente monitorado e controlado, da primeira até a última entrega, até que todas as entregas - que representam o escopo do projeto - sejam feitas. A imagem da queda dágua (waterfall), não exatamente de água, mas de etapas “caindo”, ou melhor, se sucedendo, representa uma forma de como fazer as coisas e trabalhar, que se traduz no método mais tradicional de se gerenciar um projeto.

Todos dizem que as mudanças em um projeto são inevitáveis, não importando a metodologia de gestão que adotem. Se uma organização adota o waterfall, o escopo do projeto é, de certa forma, protegido das tentativas de mudança. As mudanças de escopo, antes de serem implementadas, precisam ser formalmente aprovadas. Geralmente, essa aprovação passa pelo “sponsor” do projeto. Em projetos de maior porte, é usual consultar um grupo de pessoas com autoridade para tomar decisões sobre o projeto e preparadas para analisar as solicitações de mudanças, chamado de comitê de controle de mudanças. O comitê de controle de mudanças analisa uma solicitação de mudança e investiga se é possível fazer a mudança, os benefícios da mudança, quais são os riscos, quanto tempo vai demorar, quanto vai custar e o que justifica a aprovação. Com base nisso, a solicitação de mudança pode ser aprovada ou rejeitada.

Vejamos abaixo alguns exemplos que mostram a necessidade de analisar uma mudança no escopo do projeto, antes de sua implementação de fato.  

·         O projeto de desenvolvimento de um novo carro, com 15 meses de duração, feito pela montadora XYZ Motors, cujo escopo especifica o uso de um motor de 1.600 cilindradas de potência. Suponha que alguém da equipe técnica, depois de 8 meses do início do projeto, e já próximo a fase de testes do primeiro protótipo, descobre que seria melhor ter usado um motor diferente, de 2.000 cilindradas de potencia. O projeto já está muito adiantado e a mudança do motor resultaria em atraso e significativo aumento de custos. Sendo assim essa mudança não é aprovada.

·         A obra da construtora XYZ, que está erguendo um edifício de 8 andares, com 26 meses de duração. Suponha que alguém do departamento comercial, após 5 meses do inicio da obra, está solicitando uma mudança no escopo do projeto que alteraria a quantidade de andares de 8 para 12, além de outras implicações como, por exemplo, alterações na área destinada as vagas de garagem. A empolgação do pessoal do departamento comercial se deve a confirmação da venda de 90% das unidades em tão pouco tempo. O projeto está progredindo conforme indicado no cronograma original, e as fundações do edifício já foram concluídos. Essas fundações não suportariam mais 4 pavimentos, isso sem contar com o atraso no cronograma e no aumento de custos que uma mudança dessa natureza representaria. Essa seria uma mudança inviável e, por isso, não aprovada.

·         O projeto de criação de uma nova linha de produção da empresa XYZ Injeção de Plásticos, com duração de 6 meses. O escopo original do projeto especificava uma máquina injetora com capacidade para injetar volumes entre 326 e 622 centímetros cúbicos. Passada a primeira metade do cronograma, um colaborador do departamento de engenharia industrial notou que a pressa em iniciar logo o projeto gerou equívocos na análise de requisitos e teve como consequência a especificação incorreta da máquina injetora. Esse funcionário propôs uma mudança de escopo do projeto e apresentou evidências que indicavam que a nova máquina injetora deveria ter capacidade para injetar volumes maiores, entre 432 e 896 centímetros cúbicos. Nessa altura do projeto, o fornecedor da máquina injetora já tinha sido escolhido e a compra concluída. Assim sendo, como o equívoco (na especificação da máquina injetora) foi descoberto somente depois da compra (da máquina originalmente especificada), essa mudança não foi aprovada.

·         Um projeto de abertura de uma nova filial da rede de lojas XYZ, com duração de 8 meses, incluindo várias entregas como, por exemplo, autorização do município, obtenção de financiamento, compra de um prédio antigo, reforma desse prédio, instalação de móveis, contratação de pessoal, treinamento de pessoal, dentre outras entregas. O prédio antigo foi escolhido em função de seu tamanho e localização, sendo considerado apropriado pela área de marketing e capaz de receber todos os departamentos da loja, gerando o volume de vendas previsto. Depois de alguns meses de iniciado o projeto, com base em uma novíssima pesquisa de mercado, a área de marketing decidiu solicitar uma mudança no escopo do projeto que tinha como principal implicação a necessidade de um prédio bem maior do que o originalmente adquirido. Acontece que o prédio antigo já tinha sido comprado e a reforma iniciada. Por isso, a mudança solicitada foi rejeitada.

·         Um projeto de desenvolvimento de software para gerenciamento de bancos de dados, com duração de 3 meses. Estando o projeto no seu terço final, um dos programadores sugeriu o uso de novos “plug-ins XYZ”, pois isso tornaria o trabalho de programar mais ágil.  Um “plug-in” de software é um programa usado para adicionar funções a outros programas maiores. Todavia, seria obrigatório verificar como resolver algumas incompatibilidades presentes nesses “plug-ins” (gerando a necessidade de tempo extra e custos adicionais). Além disso, mais da metade das funcionalidades já tinha sido desenvolvida naquele momento. Por conta disso, a solicitação de mudança não foi aprovada.

Os projetos não são compostos por atividades totalmente independentes. Ao contrário disso, na maioria das vezes, vemos que existe algum tipo de dependência entre as atividades do projeto. Então, o timing é crucial em muitos tipos de projetos, em que vencidas certas etapas torna-se muito difícil voltar atrás com as escolhas e decisões já tomadas e refazer o que já está feito. Por isso, a definição do escopo do projeto é vital e, consequentemente, é recomendada a adoção de um processo que trate do controle integrado de mudanças.

 

As mudanças de escopo no método SCRUM são tratadas, digamos, de uma forma um pouco diferente.  As mudanças são consideradas como inevitáveis (isso não é diferente) e a equipe do projeto deverá estar preparada para lidar com elas de forma adequada (saber como lidar com as mudanças, aceitando-as na maior parte das vezes, é que faz toda a diferença). Mas, será que é mesmo assim? Bem, o SCRUM é um método ágil de gerenciamento de projetos, no qual o projeto é feito em “rodadas” mais curtas, que são chamados de sprints. Os sprints duram de 2 a 4 semanas! Uma atividade importante no SCRUM é o planejamento desses sprints, no qual são definidas as tarefas que deverão ser executadas naquele período de 2 ou 4 semanas. No SCRUM o produto a ser criado pelo projeto é representado no product backlog. Na terminologia do SCRUM, o product backlog é uma lista detalhada de tudo o que precisa ser realizado para transformar a visão do produto em realidade. O product backlog (tudo que precisa ser feito) é subdividido em pedaços que são executados nos sprints. Portanto, nesses sprints serão executadas partes do produto que o projeto está criando. Desse modo, sprint após sprint, do primeiro ao último, cada parte do produto vai sendo executada, até que todo o produto tenha sido criado. Se, após um determinado sprint, alguém decide que não ficou bom, o trabalho poderá ser refeito. Serão apenas 2 ou 4 semanas, certo? Sim, desde que isso não se repita com frequência. Afinal, se isso começar a ocorrer com frequência, teremos muito trabalho desperdiçado, e ninguém quer que isso aconteça!

Alguns autores acreditam que os métodos ágeis de gerenciamento de projetos, como o SCRUM, são mais apropriados em projetos urgentes e complexos, como o desenvolvimento de software. Outros entendem, e defendem, que o SCRUM pode ser usado em qualquer tipo de projeto. Já vi em alguns dos sites de empresas que vendem programas de software de gerenciamento de projetos baseados em SCRUM que esse método está sendo aplicado em diferentes tipos de indústrias, embora não seja dito claramente que tipos de projetos foram desenvolvidos nessas indústrias. Me parece óbvio que se uma montadora de automóveis, um laboratório farmacêutico, uma indústria de alimentos ou qualquer outra indústria manufatureira usa o SCRUM para desenvolver ou implantar um software, esse é um projeto de software. Ponto!

Eu tenho procurado projetos diferentes daqueles relacionados ao desenvolvimento de software feitos com o SCRUM, mas ainda não encontrei. Se você leitor desse blog identificar algum projeto feito com SCRUM que seja diferente do desenvolvimento de software, por favor, compartilhe conosco, enviando um comentário. Não faço isso por ser contra ou a favor dos métodos ágeis de gerenciamento de projetos, mas porque entendo que o SCRUM é um método interessante e que deve ser estudado e aprofundado. O gerente de projetos não deve ter um comportamento de torcedor de time de futebol (a favor do Waterfall e contra o SCRUM, ou vice-versa). Deve buscar o conhecimento para usá-lo da melhor forma possível, em favor do projeto e da organização que implementa e patrocina o projeto.    

A minha conclusão é que se estamos trabalhando com partes ou blocos independentes de um projeto ou, em outras palavras, quando a mudança em um bloco não afeta outros blocos, será possível refazer tarefas ou modificá-las com mais facilidade. Mesmo assim, as mudanças custam dinheiro e precisam ser gerenciadas. Por outro lado, em projetos com blocos dependentes, se um pedido de mudança é feito agora, que pode afetar algo feito antes, isso tem impacto no trabalho como um todo e, por conta disso, será muito mais difícil implementar tal mudança.

Lição de Casa (Parte 6)

Tente resolver os exercícios de fixação sobre gerenciamento de projeto. Isso o ajudará a sistematizar seu aprendizado e aprofundar seus conhecimentos. Em breve serão postadas as respostas das questões aqui propostas. Boa sorte!

Questão 8 - O profissional que gerenciava o projeto Alpha saiu da empresa e você foi indicado para assumir esse projeto como o novo gerente de projetos. Você está examinando várias solicitações de mudança e precisa entender como essas mudanças irão afetar o escopo do projeto. Para isso você precisa comparar cada mudança solicitada com que documento?

A) Declaração preliminar de escopo

B) Plano de gerenciamento de escopo

C) Plano de gerenciamento de mudanças

D) EAP

E) Plano de gerenciamento de riscos 

Questão 9 - Qualquer passo recomendado para alinhar o desempenho futuro esperado com o desempenho estabelecido no plano de gerenciamento do projeto é um (uma):

A) Avaliação de desempenho

B) Ação corretiva

C) Ação preventiva

D) Reparo de defeito

E) Garantia de qualidade 

Questão 10 - O coordenador técnico do projeto estima que a duração mais provável do próximo pacote de trabalho será de 50 semanas. Se tudo corresse bem, esse pacote de trabalho poderia ser completado em apenas 40 semanas. Por outro lado, no pior caso a duração desse pacote de trabalho seria de 180 semanas. Qual é a estimativa PERT para esse pacote de trabalho?

A) 48

B) 56

C) 70

D) 92

E) 110 

Questão 11 - Analisando um determinado pacote de trabalho que está sendo executado, o gerente de projetos verificou que foi orçado um custo de $1.500, considerando que o pacote de trabalho fosse concluído hoje. Ao invés disso, a análise mostrou que esse pacote de trabalho foi completado em apenas dois terços do total, a um custo de $1.350. Para essa situação, qual é a variação de custo (ou “cost variance”)?

A) - 350

B) 350

C) 1.000

D) -1.000

E) -1.500

................................

Inclua suas respostas na área de comentários e envie!

Process Driven x Project Driven

Uma das formas de analisar as organizações é descobrir se são orientadas aos processos ou se são orientadas aos projetos.

As organizações do tipo process driven (orientadas aos processos) trabalham seguindo os seus processos de trabalho, com operações rotineiras necessárias para garantir o fluxo produtivo. As empresas multinacionais, por exemplo, são organizações típicas do tipo process driven, que operam sem limitações de tempo (24 horas por dia) ou de espaço (em vários países de diferentes continentes do planeta). Essas organizações crescem em termos de conhecimento e da escala de suas operações. O conhecimento é criado e transferido. O conhecimento deve se transformar em procedimentos e melhores práticas explicitamente documentadas. Este conhecimento é dirigido para o sistema da organização e não para as pessoas. Nesse modelo, a organização “não precisa” das pessoas, confirmando o ditado que diz que ninguém é indispensável ou insubstituível. Isso significa que, se um funcionário que fazia alguma tarefa ou atividade deixa a organização, um novo funcionário – que será contratado com a necessária experiência e formação adequada - poderá assumir e seguir os passos descritos na documentação e, com algum treinamento e em algum tempo, poderá realizar o trabalho que era feito pelo funcionário que deixou a organização. Tudo isso carrega a ideia da organização como uma entidade independente das pessoas, cujo comportamento é governado por um conjunto de regras pré-definidas e de políticas. Alguns exemplos de grandes empresas que são dirigidas por processos e, portanto, são do tipo process driven: A Ford Motors, que inventou a linha de montagem para ganhar eficiência, a Wal-Mart com seus esforços para automação em seus processos, e a Dell que decidiu adotar o modelo de negócio de só iniciar a produção após receber o pedido de compra. Além das montadoras de automóveis, grandes redes de supermercados e fabricantes de computadores, muitas empresas – notadamente no segmento de manufatura - são tipicamente process driven.

As organizações do tipo project driven tem estruturas com departamentos e pessoal organizadas em torno de cada projeto particular. Em outras palavras, os funcionários podem pertencer a departamentos diferentes, mas todos precisam estar alocados a algum projeto específico. As empresas de construção, aeroespacial e de pesquisa, são exemplos típicos de organizações do tipo project driven.

De acordo com Menezes (2009), é possível observar que grande parcela das organizações encontra-se em um estágio intermediário: existem operações rotineiras para garantir o fluxo produtivo e existem também atividades inovadoras (implementadas através de projetos) para garantir a melhoria dos processos e de toda organização. Por exemplo, as empresas de TI (Tecnologia da Informação), que se incluem na indústria de serviços, são consideradas como híbridas, uma vez que uma parte dessas organizações opera como project driven (quando está desenvolvendo um novo aplicativo de software), e outra parte opera como process driven (quando está fornecendo serviços de suporte para suas aplicações de software).

Uma organização matricial é um tipo híbrido de organização (como as empresas de TI acima citadas) em que estão presentes os departamentos especializados (vendas, marketing, suprimentos, recursos humanos, jurídico, financeiro, produção, etc). O fluxo produtivo da empresa será garantido pela execução dos processos (process driven). Todavia, para realizar um projeto, a empresa opera com equipes compostas por funcionários de diversas especialidades e departamentos (project driven). Nessa situação, um funcionário tem um superior hierárquico no seu departamento (que é o gerente de linha ou gerente funcional) e também precisa se reportar ao superior no projeto, que é o gerente de projetos. Aliás, esse é um dos fatores que torna a coexistência das operações rotineiras e dos projetos muitas vezes difícil, para dizer o mínimo.

E o que isso tem a ver com a ideia de maturidade em gerenciamento de projetos?

Sim, exatamente, tem tudo a ver! É óbvio que diferentes organizações poderão estar em diferentes níveis de maturidade em relação ao gerenciamento de projetos. Ser maduro em relação ao gerenciamento de projetos significa, para começo de conversa, compreender que para gerenciar um projeto é necessário usar métodos, técnicas e ferramentas diferentes daquelas usadas na gestão dos processos e rotinas do dia a dia da empresa. Significa também compreender as características próprias do trabalho de um gerente de projetos.

No Brasil existe o Modelo de Maturidade em Gerenciamento de Projetos (MMGP) do prof. Darci Prado. Esse modelo considera que as organizações poderão se encontrar em cinco níveis diferentes de maturidade; a saber:

Nível 1 – é o nível embrionário ou ad hoc, que representa um cenário em que a organização não efetuou nenhum esforço para a implantação de um modelo de gestão de projetos. Os projetos são executados de forma isolada, em que cada um adota uma forma de gerenciar, sendo, portanto, executados na base da intuição, boa vontade ou do melhor esforço individual. O resultado positivo é fruto do esforço individual ou da sorte.

Nível 2- é chamado de nível conhecido, que representa o cenário onde a organização desenvolveu algum esforço em gestão de projetos, no sentido de criar uma linguagem comum, ou seja, uma linguagem única para o assunto. A organização faz investimentos regulares em treinamento e adota softwares de gerenciamento de projetos. Nesse nível ainda falta um modelo padronizado de gestão de projetos. Isso deixa a organização exposta a vários problemas como, por exemplo, atrasos nos prazos, erros nos custos, mudanças de escopo no decorrer do projeto, não atendimento a indicadores de eficiência e insatisfação dos clientes.

Nível 3 – é chamado de nível padronizado, que representa o cenário no qual a organização implanta e utiliza um modelo padronizado para gerenciamento de projetos, com base em uma metodologia, usando recursos computacionais e uma estrutura organizacional adequada. É feita a padronização de procedimentos a ser difundida e utilizada em todos os projetos, sob a liderança de um PMO (Project Management Office, ou Escritório de Projetos), visando alcançar um alto grau de comprometimento das partes interessadas no projeto.

Nível 4 – é chamado de nível gerenciado, e inclui a consolidação das ações iniciadas no nível 3 (metodologia, informatização, estrutura organizacional e alinhamento estratégico). No nível 4, o modelo de gerenciamento de projetos implantado no nível 3 está sendo praticado de forma eficiente e eficaz. É feita a avaliação permanente de quanto o modelo está funcionando bem, e os resultados são armazenados em um banco de dados que contém as informações sobre cada projeto encerrado, possibilitando o acesso às melhores práticas executadas. Neste nível se investe na evolução do gerenciamento, com ênfase no alcance de relacionamentos humanos eficientes, principalmente por meio de treinamento nas seguintes áreas: gestão de pessoas, técnicas de negociação, gerenciamento de conflitos, motivação e liderança.

Nível 5 – é conhecido como nível otimizado, que representa um cenário em que a organização alcança a sabedoria em gerenciamento de projetos. Nesse nível, todas as iniciativas implantadas nos níveis 2, 3 e 4 alcançaram um patamar de excelência. A experiência e o conhecimento adquiridos na execução dos projetos transformam-se em melhores práticas para projetos futuros, que serão executados de forma otimizada. A organização conquista a confiança de seus profissionais e passa a aceitar novos desafios.

Ainda no MMGP, a análise do nível de maturidade em gerenciamento de projetos para uma organização leva em conta seis dimensões; a saber: conhecimento (que é a competência técnica em gerenciamento de projetos), uso de metodologia, uso de informatização, uso de adequada estrutura organizacional, competência comportamental (ligada aos relacionamentos humanos) e alinhamento com os negócios da organização (e estratégias).

Conhecimento (competência técnica em gerenciamento de projetos) - envolve o conhecimento adquirido com práticas de gestão de projetos existentes, contidas em diferentes modelos.

Uso de metodologia – envolve a estruturação e utilização de uma metodologia de gestão de projetos com uma série de passos a serem seguidos para garantir a aplicação correta dos métodos, técnicas e ferramentas.

Uso da informatização – representa a elaboração (ou a compra) de um sistema informatizado em que os dados de todos projetos da organização podem ser visualizados (e atualizados). O sistema deve permitir o acompanhamento dos indicadores de desempenho dos projetos.

Uso de adequada estrutura organizacional – envolve a formação dessa estrutura de forma a diminuir os conflitos e aumentar os resultados.

Competência comportamental (relacionamentos humanos) – envolve o conhecimento do relacionamento humano, visando a motivar os membros da equipe e minimizar possíveis conflitos. Os aspectos de relacionamento humano afetam todos os envolvidos no projeto.

Alinhamento com os negócios da organização – também chamado de alinhamento estratégico, envolve o alinhamento dos produtos atuais e futuros projetos com os objetivos estratégicos da organização. A tabela abaixo apresenta o relacionamento entre as dimensões e os níveis de maturidade do MMGP.

Tabela 1: Relacionamento entre as Dimensões e os Níveis de Maturidade do Modelo MMGP (Adaptado de Prado, 2008)

 

Para saber mais sobre o modelo de maturidade em gerenciamento de projetos do prof. Darci Prado acesse o seguinte link:  http://www.maturityresearch.com/novosite/index.html

Referência: MENEZES, L. C. de M. “Gestão de Projetos”. 3ª. edição. São Paulo: Atlas, 2009.

PRADO, D. “Maturidade em Gerenciamento de Projetos”. Minas Gerais: INDG-Tecs, 2008.

Ferramentas e Técnicas do Gerenciamento de Custos

O gerenciamento de custos do projeto utiliza vários conceitos interessantes em destaque nos processos do PMBOK. A pergunta que muitos estudantes de gestão de projetos costuma fazer é a seguinte: Sim, professor, eu li tudo, mas ainda tenho dúvidas sobre o que usar disso tudo e quando devo usar cada coisa??? 

Uma forma mais direta de pensar na gestão de custos do projeto – e que responde boa parte da pergunta anterior - é verificar o que usamos e fazemos em cada fase do ciclo de vida do projeto. Pensando assim, podemos consolidar os conceitos estudados no gerenciamento de custos com as ações, ferramentas e técnicas destacadas abaixo:

Fase de pré-iniciação – é quando se está decidindo se vamos em frente ou não com o projeto. É necessário usar ferramentas como o ROI, o payback, o VPL e o TIR, para tomar essa decisão. Essas ferramentas de matemática financeira são usadas na preparação do business case do projeto. O projeto nem começou e o business case é feito com base em premissas e restrições.  Recomenda-se convidar profissionais especialistas, que trabalham com dados e informações de casos semelhantes, além dos dados e informações específicas do projeto que está sendo analisado. Os especialistas fazem a análise de mercado e da empresa. O resultado é um relatório sobre a análise de viabilidade do projeto e o business case.

Fase de Iniciação – é preparado o termo de abertura do projeto com o uso de dados e informações contidas no relatório sobre a análise de viabilidade do projeto. São feitas estimativas de custo do projeto (estimativas top-down / button-up).

Fase de planejamento – é elaborado o orçamento do projeto, com o detalhamento das estimativas (top-down / button-up / PERT), e a agregação de custos. Depois da elaboração do plano de riscos, são definidas as reservas de contingência e reservas gerenciais.

Fase de execução / monitoramento e controle – é feito o acompanhamento do orçamento e a comparação entre o real versus planejado (curva S, análise de valor agregado). Com base nisso decisões são tomadas para corrigir o andamento do projeto, se necessário. É feito o controle integrado de mudanças (análise de impactos, com aprovação ou rejeição de mudanças). Dependendo do que aconteça, o projeto pode ser até encerrado antes da hora.

Fase de encerramento – é o momento de preparar o relatório de custos do projeto, com todas as mudanças e a explicação do motivo de cada mudança. Se o projeto segue em frente até o seu final, mas gastou mais do que o planejado, isso pode afetar o ROI inicialmente estimado. Depende, é claro, se gastou só um pouco mais, ou se gastou bem mais do que o valor previsto inicialmente. Portanto, o controle de custos tem implicações diretas sobre o business case. Quanto mais longo é um projeto, maior será esse risco.

 

Glossário:

Agregação de custos – é a técnica que agrega os custos estimados das atividades em função do cronograma para obter a linha de base de custos do projeto. Para saber mais sobre a agregação de custos e outras técnicas e ferramentas do gerenciamento de custos do projeto clique aqui!

Análise de valor agregado – é um método de medição do desempenho sobre uma atividade ou um pacote de trabalho, que considera três parâmetros; a saber: o valor planejado (PV ou “planned value”, que é o custo orçado ou planejado), o valor real (AC ou “actual cost”, que é o custo real efetivamente gasto) e o valor agregado (EV ou “earned value”, que é o custo planejado para o trabalho realizado). Para saber mais sobre a análise de valor agregado clique aqui! 

Business case – é um documento que explica o caso específico de um negócio, apresentando formalmente as motivações para sua implementação, as necessidades de recursos humanos, materiais e financeiros, e os benefícios e vantagens que o justifiquem, incluindo, geralmente, textos descritivos e planilhas financeiras. Para saber mais sobre business cases clique aqui!

Curva S – é um instrumento de acompanhamento gerencial com o qual é possível identificar desvios entre valores planejados e realizados. Muito usada na análise de valor agregado. Para ver mais exemplos sobre o uso da curva S clique aqui! 

Estimativa botton-up – é uma técnica de fazer estimativas “de baixo para cima”. Uma atividade é decomposta em várias sub atividades. São feitas, por sua vez, estimativas de cada sub atividade. A soma das estimativas das sub atividades que formam uma atividade é a estimativa dessa atividade. A estimativa botton-up é, portanto, mais detalhada. 

Estimativa top-down – é uma técnica de fazer estimativas “de cima para baixo”, ou por analogia. Essas estimativas são feitas por especialistas (estimando o valor total da atividade com base em seu conhecimento) ou com base em projetos similares. A estimativa top-down é, portanto, menos detalhada. 

Payback – é um indicador financeiro usado na análise de retorno financeiro de projetos que indica o tempo necessário para as receitas geradas e acumuladas igualarem o investimento inicial. É calculado em unidades de tempo (semanas, meses, anos).  

PERT – ou “Program Evaluation and Review Technique”, é uma técnica que consiste em estimar a duração de uma atividade baseando-se em três estimativas possíveis para essa atividade: estimativa Otimista (O), Pessimista (P) e Mais Provável (MP). A estimativa PERT é dada pela fórmula PERT = (O + 4xMP + P) / 6. 

Reservas de contingência – é um adicional relacionado aos riscos identificados no projeto e para os quais são desenvolvidas respostas de contingência. Esse adicional pode ser um tempo a mais (chamado de buffer ou pulmão) ou um custo extra, definido para cada atividade ou pacote de trabalho. O gerente de projetos poderá usar as reservas de contingência sem a necessidade de pedido de autorização, a menos que as políticas da empresa digam o contrário. 

Reservas gerenciais - é uma margem de segurança, materializado por um tempo a mais ou um custo extra, para garantir que riscos que ainda não foram identificados inviabilizem o projeto. Para usar essa reserva o gerente de projetos deve pedir autorização para o “sponsor” do projeto. 

ROE – ou “Return on Equity”, é conhecido como Retorno sobre o Patrimônio Líquido. O ROE é calculado pela fórmula: ROE = (Lucro Líquido / Patrimônio Líquido). Exemplo: Calcule o ROE de uma empresa que teve um lucro líquido de R$65.000, conforme consta no DRE (Demonstração de Resultados do Exercício). O patrimônio líquido dessa empresa é de R$250.000. O ROE deve ser calculado pela formula ROE = (65.000 / 250.000) = 0,26 (ou 26%). Para mais informações sobre o DRE clique aqui!  

ROI – ou “Return on Investment”, é o retorno sobre o investimento. O ROI é calculado pela fórmula: ROI = (Retorno / Investimento). Exemplo: Calcule o ROI de uma aplicação financeira em foram aplicados R$20.000 por 30 dias, com rendimentos R$240 ao final do período. O ROI deve ser calculado pela fórmula ROI = (240 / 20.000) = 0,012 (ou 1,2%). Portanto, o ROI desse investimento foi 1,2% ao mês.  

TIR – ou Taxa Interna de Retorno, é a taxa necessária para igualar o valor de um investimento (valor presente) com os seus respectivos retornos futuros ou saldos de caixa. Para mais detalhes sobre o calculo da TIR clique aqui.  

VPL – ou Valor Presente Líquido, é a soma dos valores presentes dos fluxos estimados de uma aplicação, calculados a partir de uma taxa definida e de seu período de duração. Para mais detalhes sobre o calculo do VPL clique aqui.  

A roupa certa no ambiente de trabalho!

A roupa certa no ambiente de trabalho não deveria ser algo assim tão difícil de encontrar.

 

Sobre esse tema, vamos começar mencionando os esforços da consagrada fotógrafa alemã Herlinde Koelbl, que realizou um interessante trabalho sobre a relação entre roupa e personalidade, comparando o lado profissional com o pessoal. A fotógrafa mostrou em seu trabalho pessoas de diferentes grupos sociais e áreas, obviamente através de suas fotografias. As fotos mostravam a imagem de uma pessoa vestindo uniformes e roupas de trabalho, ao lado da imagem dessa mesma pessoa vestindo roupas em momentos casuais. Em depoimentos, os próprios indivíduos fotografados afirmaram que ao colocarem os uniformes e fardas sentiam-se diferentes. O trabalho de Herlinde Koelbl, registrado no livro “Clothes Make the Man” (As Roupas fazem o Homem), de 2012, confirmou a hipótese que considera que existe um olhar seletivo - com admiração, respeito ou preconceito – para as pessoas, dependendo de como estejam vestidas.

Muitas empresas adotam determinados códigos de vestimenta, que definem que, por exemplo, seu pessoal de vendas deve usar terno e gravata.  Com isso elas esperam que os vendedores consigam passar uma boa primeira impressão, tenham confiança e sejam respeitados. É amplamente aceito que uma grande primeira impressão é muito importante para a construção de uma imagem de liderança capaz de influenciar. Alguns acreditam que a roupa correta é responsável por 95% dessa boa primeira impressão, pois, afinal, no ambiente de negócios, a roupa cobre aproximadamente 95% do corpo de uma pessoa.

Será que existe algum segredo? Eu creio que não. Se o ambiente é formal, recomenda-se vestir algo também bem formal. Os homens devem vestir terno, gravata e um sapato que combine. Para as mulheres recomenda-se o terninho, a calça ou saia social e, obviamente, um sapato adequado e que combine. Se o ambiente for um pouco mais casual, será possível adotar o esporte fino, com o jeans e a camisa social. Homens e mulheres devem sempre evitar visuais exagerados!

A aparência é igualmente importante. O corte de cabelo, a barba bem feita, a escolha dos acessórios e outros detalhes que acompanham a boa aparência, devem estar todos muito bem equilibrados.

Se você entrar no Google e digitar “importância da roupa no trabalho” ou “vestimenta profissional” encontrará dezenas de websites com sugestões e conselhos úteis sobre o assunto. Para se aprofundar no assunto faça uma pesquisa e aprenda a montar os “looks” que melhor se encaixam no seu tipo físico.

 

O ponto aqui, que não devemos perder de vista, é que a roupa comunica! Tudo que fazemos reflete aquilo que somos, que gostamos, e diversas outras coisas relacionadas ao nosso eu. A roupa, mesmo que muitos neguem, é uma dessas formas de traduzir o que o homem é, ou não é! A roupa é um instrumento de comunicação! Quando você se veste e aparece no seu lugar de trabalho, está comunicando alguma coisa para as outras pessoas. Por isso, a roupa deve ser compatível com o ambiente profissional. Lembre-se, você está no lugar do seu ganha-pão. Você precisa ter a aceitação de seus colegas. Em outras palavras, seus colegas precisam olhar para você e identificar que você é um deles. Talvez você ache tudo isso uma bobagem e seja aquele tipo de pessoa que não está preocupada em agradar ninguém! Talvez você seja um desses rebeldes que não aceitam regras e não dão a mínima para essa conversa fiada de roupas e aparência. Bem, mas isso é tema para outro post!

Sobre o Trabalho em Equipe

A maioria das empresas atualmente incentiva o trabalho em equipe. O sucesso do trabalho em equipe, que necessita de múltiplas habilidades, julgamentos e experiências para ser feito, vem da constatação que as equipes são capazes de melhorar o desempenho dos indivíduos. Tendo isso em mente, trabalhar em equipe é uma forma que as organizações encontraram para usar melhor o conhecimento e as habilidades de seus colaboradores.

 

Nas equipes, as habilidades complementares ajudam a vencer os desafios. A responsabilidade pelos resultados é da equipe. Apesar disso, continua existindo a responsabilidade individual pela parte que cada membro é responsável. Então, eu quero que o meu companheiro de equipe receba o que precisa para fazer bem a sua parte. Eu quero que ele (ou ela) tenha os elementos necessários para fazer um bom trabalho, uma vez que o resultado final depende do trabalho de cada um na equipe e da equipe funcionando como um todo.

De acordo com Robbins (2005), os quatro fatores mais importantes que parecem estar relacionados ao desempenho das equipes são os seguintes: recursos adequados, liderança eficaz, clima de confiança e sistema de avaliação de desempenho e de recompensas.

Recursos adequados – as pessoas alocadas na equipe precisam ter o conhecimento e as habilidades necessárias para a correta execução de suas atividades e assim poder cumprir com suas responsabilidades.

Liderança eficaz – os membros da equipe precisam de correta orientação com relação à divisão das tarefas. O líder da equipe - um gerente formalmente nomeado - precisa assegurar que todos contribuam para que o trabalho seja planejado, executado e concluído com sucesso. O líder também precisa atuar na resolução de conflitos, situações que demandem mudanças e na condução da tomada de decisões. Robbins (2005) argumenta que nem sempre a liderança é necessária, quando a equipe é do tipo autogerenciada. Nas equipes autogerenciadas os membros assumem muitas das funções que geralmente ficam a cargo de gerentes com a função de liderança.

Clima de confiança – a confiança interpessoal entre os membros da equipe facilita a cooperação, reduz a necessidade de monitoramento dos comportamentos individuais e une as pessoas em torno da crença de que nenhuma delas tentará tirar proveito da outra. Como resultado, os membros das equipes eficazes confiam uns nos outros, e demonstram confiança em seus líderes. A confiança é importante para a liderança (o gerente líder) uma vez que facilita a disposição da equipe em aceitar e se comprometer com as metas e decisões do líder.

Sistema de avaliação de desempenho e recompensas – recomenda-se que seja colocado em prática um sistema de avaliação de desempenho e recompensas que reflita o desempenho da equipe, não apenas de cada um dos indivíduos. As empresas devem incluir nos seus sistemas de avaliação de desempenho as avaliações em grupo, que incluam a participação nos lucros e nos resultados, além de outras formas de incentivo que reflitam o esforço, o empenho, o comprometimento e os resultados das equipes. Robbins (2005) ainda reforça que as avaliações individuais de desempenho (incluindo a remuneração fixa, os incentivos individuais, e outras práticas semelhantes) não são consistentes com o desempenho de equipes de alto desempenho.

O leitor atento, que nos seguiu até aqui, já deve ter percebido que todos esses conceitos se aplicam ao gerenciamento de projetos. Embora o livro “Comportamento Organizacional” não tenha um carimbo ou etiqueta que diga que é um livro específico sobre gestão de projetos, na verdade, é um trabalho de grande relevância e também aplicável nesse campo do conhecimento. 

Referência: ROBBINS, S. P. “Comportamento Organizacional”. 11ª. edição. São Paulo: Pearson Prentice Hall, 2005.