Menu
Esqueceu a senha? Fazer cadastro

Cronograma Ágil

Cronograma ágil de acompanhamento de realizações e entregas

texto de Fábio Cruz, PMP PRINCE2

Os cronogramas são poderosas ferramentas de planejamento e monitoramento e controle, mas quando utilizados de forma incorreta e com objetivos distorcidos se tornam pesos pesados para um gerente de projetos carregar atrasando a vida de todo o time. Portanto, neste post vamos entender como ter cronogramas simples e objetivos, abusando de conceitos e práticas ágeis.

O Cronograma na Teoria

Em projetos grandes, pequenos, de engenharia ou software, de marketing ou criação de produtos de diversas naturezas, sempre há uma pergunta básica que permeia um projeto do seu início ao fim: “Quando tal tarefa estará pronta?”.

Esta pergunta quase sempre é respondida através de um cronograma, sendo ele formal ou informal, ou até mesmo existindo ou não existindo, sendo que quando este não existe alguém comenta que está sentindo falta ou que deveria ser feito.

Ao mesmo tempo o cronograma é uma ferramenta criticada e que apesar de muitos discursarem sobre a sua necessidade e importância não o utilizam, e quando utilizam fazem uma primeira versão no início do projeto e não o atualizam mais, ou em outros casos vivem para gerenciar cronogramas extensos, complexos e com milhares de itens, alterando-o o tempo inteiro e gastando todo o tempo para controlar dependências, relacionamentos e caminhos críticos.

Então afinal, cronograma é bom ou ruim? Como podemos utilizá-lo de maneira benéfica e útil para o nosso projeto?

Um cronograma deve dizer o essencial para quem deseja acompanhá-lo, que não é mais do que as principais datas de entregas e/ou realizações importantes de um projeto. Um cronograma não é um documento simplesmente, mas sim uma ferramenta que proporciona o monitoramento do avanço de um projeto através de datas de controle.

Com este objetivo um cronograma é bom sim e pode ser muito benéfico e útil para um projeto.

Ao tentar realizar este monitoramento muitos cometem o erro de transformar o cronograma em um monstro de sete cabeças, criando um cronograma gigantesco, cheio de itens, sub-itens, sub-itens de sub-itens com vários níveis, e ainda usam e abusam de dependências e relacionamentos, transformando a manutenção do cronograma em uma tarefa quase possível. A figura 1 exemplifica um pedaço pequeno de um grande cronograma.

1

Figura 1

Para evitar este tipo de erro pense em um cronograma ágil que traga apenas o necessário para que o calendário de realizações do projeto seja conhecido e monitorado pelos times dos projetos.

Um cronograma ágil de acompanhamento de realizações e entregas traz poucos conceitos e regras diferentes de um cronograma convencional, sendo que a primeira e mais importante delas é não conter micro atividades e não ser utilizado para micro gerenciamento do time ou do projeto.

Mas como não ter atividades em um cronograma, então para que ter um cronograma?

É justamente na resposta desta pergunta que o gerenciamento ágil aparece com força e mostra seu valor.

O Cronograma Ágil na Prática

O conceito de um cronograma ágil, é que o mesmo traga apenas realizações e entregas macros, e forneça uma visão ampla do que está sendo trabalhado no projeto.

Desta forma é possível usar e abusar de alguns artefatos ágeis para montar um cronograma ágil e ilustrar o que deve estar no cronograma e o que não deve, deixando esta ferramenta de apoio mais leve, mais simples de operar e manter, além de mais objetiva na distribuição de informação.

Um cronograma ágil deve informar mais sobre macro gestão do que a respeito da micro gestão, e para isso deve conter apenas os marcos de entrega, suas iterações (Sprints) e no último nível as estórias, ou em outras palavras os pacotes de entregas da iteração. Vejamos um exemplo a seguir:

2

Figura 2

As mudanças perceptíveis de um cronograma convencional para um cronograma ágil podem ser visualizadas na figura 2, onde temos os seguintes destaques:

1 – É apresentado o conteúdo que será produzido em cada iteração, não detalhando mais do que o nível conhecido como estória, ou seja, uma parte do produto que precisa ser construído ou o que pode ser chamado de grupo de tarefas.

2 – As pessoas específicas que irão realizar as atividades, ou grupo de tarefas (estórias) deixam de aparecer no cronograma, e apenas aparece a figura do Time que entrega a iteração inteira. Neste caso é aberta a possibilidade do time se auto organizar para entregar todas as tarefas da iteração.

3 – Não aparecem prazos e previsões para cada uma das estórias (grupo de tarefas), apenas o prazo previsto para o término da iteração é apresentado. Esta situação permite que o time trabalhe com a sua velocidade total para cumprir a meta da iteração, e não prazos curtos e micro entregas.

4 – As micro atividades, ou pequenas tarefas, que precisam ser realizadas para que a estória seja realizada não aparecem no cronograma. Esta simples ação simplifica muito o cronograma, diminuindo as interferências de manutenção e de gestão do cronograma.

As pequenas tarefas ou atividades de um cronograma ágil

No caso das pequenas atividades não estarem no cronograma, onde estão? No quadro de tarefas, também conhecido como Kanban do time.

Tudo é simplificado quando o cronograma mantém apenas o macro gerenciamento com os pacotes de entregas e pedaços do produto que será construído, permitindo que todos consigam acompanhar o que está sendo trabalhado e o que já foi entregue, e ao mesmo tempo apenas o time se preocupe com as micro atividades, ou as tarefas que precisa realizar para completar os pacotes do produto que estão no cronograma.

Desta maneira, o time tem uma data de entrega que está no cronograma, que coincide com o fim da iteração que está trabalhando, esta mesma data é compartilhada com o cliente e outros interessados no projeto. Sendo que apenas no final da iteração, ou do pacote de entrega, é que todos verão as micro atividades prontas. Porém em todo o desenvolvimento do produto, quem olhou para o cronograma viu as estórias sendo concluídas, e quem olhou para o quadro de tarefas viu as pequenas atividades serem completadas.

Veja o quadro de tarefas a seguir e observe a distribuição das pequenas tarefas.

3

Figura 3

Cada quadro já representa uma iteração, então automaticamente a iteração que está em andamento, ou a iteração corrente é a que está no Kanban. Assim, apenas as estórias referentes a iteração corrente aparecem no quadro, e como consequência as tarefas para completar as estórias completam a auto organização do time e também permitem o monitoramento e acompanhamento da gestão e de outros interessados no projetos.

Esta maneira de separar o que aparece no cronograma gerencial e o que aparece no quadro de tarefas do time, permite que os gestores foquem no gerenciamento do projeto como um todo e nas expectativas do cliente com entregas macros, e que o time se concentre na próxima entrega de valor para o cliente e nas tarefas diárias que precisam ser completadas para que o objetivo seja conquistado.

Conclusão

Desta forma é possível observar que as boas práticas tradicionais como um cronograma eficiente é muito bem vindo e pode ser muito utilizado quando o projeto exige e quando há uma gestão interessada em fazer um acompanhamento formal e macro das realizações de um projeto. Especialmente para confrontar com cronogramas financeiros de entregas versus faturamentos do projeto.

Em contrapartida fica evidente o valor e os ganhos ao se utilizar ferramentas e técnicas ágeis para melhorar a produtividade de um time todo, incluindo gestores, além de mostrar os benefícios de combinar abordagens mais tradicionais de gerenciamento de projetos com as mais ágeis e dinâmicas.

Este tipo de combinação eficiente e abordagem mista do uso de boas práticas tradicionais com ferramentas e técnicas ágeis é abordada no livro “Scrum e PMBOK unidos no gerenciamento de projetos“, e também vista na prática e no Workshop PM4Plane Scrum + PMBOK.

Untitled

Contatos:

Caminho Crítico Completo

por Peter Mello

Em gestão de cronogramas, muito já ouvimos falar de um tal de Caminho Crítico que é determinado pela Folga Zero. Em geral, constitui-se de um conjunto de tarefas sinalizadas nas ferramentas com uma coloração avermelhada.

Esta definição, contudo, é fruto da aplicação de um método (o Método do Caminho Crítico ou CPM) cuja prática não é suficiente para definir o que é o Caminho Crítico em diversas outras situações encontradas em projetos.

Há muito mais sobre o Caminho Crítico que precisamos ver e este é um tema que já venho revisitando há mais de 10 anos, sempre em calorosas discussões!

Nos exemplos a seguir vamos reforçar o que há pouco se começou a chamar de “Caminho Crítico Completo” (CCC) e que atende a uma frase que há muito assopro pelos ventos: “O Caminho Crítico pode ter folga!

Vamos começar com um projeto básico:004_01

E estabelecer as primeiras convenções:

004_002

Em cada atividade, utilizando os parênteses, vamos também estabelecer a Duração e o Recurso Necessário (Duração, Recurso), conforme o exemplo.

004_03
Examinando assim nossa rede (Início – A – B – Fim), podemos dizer que este projeto, será realizado entre os dias 1 ao 20, com uma duração total de 20 dias.

Segundo o PMBOK®, “O caminho crítico é a sequência de atividades que representa o caminho mais longo de um projeto, que determina a menor duração possível de um projeto.”  [PMBOK 5a Edição, pag. 176]. Aplicando este conceito em nosso Projeto, temos então:

004_04

Em outras palavras, podemos dizer que o Caminho Crítico com base ao conceito do Método do Caminho Crítico e o Caminho Crítico Completo são – neste caso –  idênticos.

No entanto, a aplicação de uma diagramação em redes das atividades não leva em consideração a influência de múltiplas dependências, restrições externas, nivelamento de recursos e outros fenômenos que podem alterar a localização de atividades “com Folga Zero”.

Se o projeto atual começa no dia 01 de Abril, com dias corridos, mas o Recurso (Y) estiver de férias até o dia 20 de Abril, já temos uma alteração significativa do Caminho Crítico Completo.

004_05

O projeto agora inicia no dia 1 e é concluído no dia 30, ficando sem atividades previstas entre os dias 11 e 20, que pode ou não ser utilizado por x sem gerar novos atrasos ao projeto.

Considerando o método de identificação do Caminho Crítico em CPM, somente o marco final de projeto e a atividade B (que tem Folga Total igual a Zero) serão identificados como Caminho Crítico (técnica do passo-para-frente e passo-para-atrás).  Por não determinar toda a sequência entre o primeiro e último dia de projeto, muitos denominam este caso de “Caminho Crítico Partido”.

Ainda mantendo o que foi estabelecido no PMBOK® – existindo ou não um “tempo morto” ou uma “folga livre” entre a Atividade A e a Atividade B – precisamos definir o Caminho Crítico.  Neste caso, estamos então caracterizando o “Caminho Crítico Completo”.

004_06

  • Caminho Crítico (CPM/Partido)    : 10 dias (do dia 21 ao dia 30);
  • Caminho Crítico Completo            : 30 dias (do dia 01 ao dia 30; com uma folga em A = 10 dias).

 

Corrente Crítica

Sem entrarmos em detalhes em relação ao “Método da Corrente Crítica”, podemos também destacar a diferença entre o Caminho Crítico (CPM) e o Caminho Crítico por Recursos (Caminho Crítico dos Recursos ou Corrente Crítica).

Um diagrama de redes devidamente distribuído no tempo e também alterado em função de restrições de recursos poderá gerar uma sequência distinta de atividades que compõem o Caminho Crítico Completo.

Aqui vale ressaltar que a identificação da “Corrente Crítica” é apenas uma de várias etapas do método de mesmo nome e que não precisamos necessariamente adotar o método de E. Goldratt para identificarmos a corrente crítica.

Por sinal, vale destacar que em vários países – desde a década de 60 – se buscavam alternativas para identificar a sequência de tarefas que levariam ao entendimento do menor tempo de um projeto mesmo quando fosse realizado um nivelamento de recursos. Décadas depois se concluiu que não há uma alternativa “matemática” como a encontrada no CPM para a rede em que os recursos são abundantes.

Esta rede “alterada por recursos” era conhecida – antes da publicação do método de Goldratt, como Resource Critical Path (Caminho Crítico por Recursos) e tem como uma das características de que também é identificado por aquelas atividades de “folga igual a zero”.

No entanto, “a folga zero” na Corrente Crítica é calculada não só para itens da rede lógica, mas também em função dos recursos. Assim, é a folga zero na “entidade recurso” que permite a identificação das atividades “vermelhas”, conforme veremos a partir do projeto seguinte:

Situação Original

 004_07

Ou ainda

004_08

 Em qualquer uma das alternativas acima, existe uma “rede lógica” entre o Marco de Início e de Término que corresponde ao Caminho Crítico (A + B = 20 dias) e também um caminho “não-crítico” ou “com folga”.

Na definição padrão, se uma folga está disposta em um local onde um atraso não afeta a próxima atividade na rede, temos a “folga livre”. Se esta folga não atrasar a última data do projeto, temos a “folga total”.  Nas duas ilustrações acima, a folga total é sempre 3 dias (a ser compartilhada entre C e D) e a folga livre dependerá de como estiverem agendadas estas atividades entre si.

Cronograma nivelado por Recursos (Corrente Crítica)

No exemplo anterior há uma superalocação do Recurso X entre os dias 1 e 7 e uma superalocação  do recurso (Y) entre os dias 11 e 20.  É necessário então estabelecermos o retardo de algumas atividades até que os recursos estejam disponíveis.

 004_09

Neste caso, pelo cálculo de “Folga do Recurso”, as Atividades A, B e D representam a Corrente Crítica deste Projeto.  Pela mesma contagem, também temos o Caminho Crítico Completo.

  • Caminho Crítico (CPM/Partido)        : 10 dias (somente a Atividade D)
  • Corrente Crítica                               : 30 dias (Atividades A, B, D)
  • Caminho Crítico Completo               : 30 dias (idêntico a Corrente Crítica)

Pelo o que foi visto até agora, poderíamos inferir neste caso de que o “Caminho Crítico Completo” é a rede lógica composta pelas atividades do Caminho Crítico, somado as atividades da Corrente Crítica.

No entanto, nenhuma das duas técnicas irá resistir às situações em que
dependências externas ou certas limitações de aplicação de recurso sejam aplicadas!

Se repetirmos a mesma restrição do primeiro exemplo, onde o recurso (Y) está de férias até o dia 20, a solução deste pequeno cronograma então seria:

 004_10

Com este deslocamento,  tanto o Caminho Crítico CPM como também a Corrente Crítica ficam “partidas”, e o verdadeiro Caminho Crítico Completo tem agora 40 dias, como na ilustração a seguir.

 004_11

Resultados

  • Caminho Crítico (CPM/Partido)    : 10 dias (somente a Atividade D)
  • Corrente Crítica (Partida)             : 20 dias (Atividades B e D)
  • Caminho Crítico Completo      : 40 dias (Atividades A, C, B e D, com Folga Total de 3 dias em A e de 13 dias em C)

Em palestras que apresentei entre 2003 e 2013, eu sempre busquei diferenciar o Caminho Crítico de origem “CPM” do Caminho Crítico de Recursos e o Caminho Crítico do Projeto.

Agora que o termo “Complete Critical Path” está disponível em uma crescente literatura, a partir desta data estarei  substituindo a definição “Caminho Crítico do Projeto” pela promoção do termo  “Caminho Crítico Completo”, com a aplicação do acrônimo CCC que espero que comece a ser utilizado pela comunidade de planejadores para destacar o registro deste conceito sem a sua amarração histórica ao Método do Caminho Crítico e a famosa “folga zero”, que hoje reconhecemos que nem sempre é verdade.

Alguém não concorda que o CCC neste projeto não é de 40 dias?

Repita os exercícios!

  • Se desejar conferir a realização destas análises sobre o Caminho Crítico Completo, você poderá verificar o “Caminho Crítico por Recursos” no software Primavera ou Spider, mas no MS-Project só poderá identificar o “Caminho Crítico por Recurso”, caso tenha colocado um plug-in como este (link).
  • Tarefas:
    • ID 1 = Marco de Projeto, Início;
    • ID 2 = Atividade A, Recurso X, 10 dias, tendo 1 como predecessora;
    • ID 3 = Atividade B, Recurso Y, 10 dias, tendo 2 como predecessora;
    • ID 4 = Atividade C, Recurso X, 7 dias, tendo 1 como predecessora;
    • ID 5 = Atividade D, Recurso Y, 10 dias, tendo 4 como predecessora;
    • ID 6 = Marco de Projeto, Término.
  • Após a colocação dos recursos, utilize a funcionalidade de “Nivelamento de Cronograma com o uso de Recursos”

Referências:

  1. – PMBOK®, 5ª edição, em http://www.pmi.org
  2. http://www.pmknowledgecenter.com/dynamic_scheduling/baseline/critical-path-or-critical-chain-difference-caused-resources
  3. http://www.planningplanet.com/forums/planning-scheduling-programming-discussion/422099/cpm-critical-path-method
  4. http://www.br10.net/tag/rcp/
  5. – http://www.steelray.com/critical_path_features.php

 

Escreva para petersmello@gmail.com


A gestão de benefícios e a definição de sucesso em projetos

Em linhas gerais, um projeto não é realizado em função de suas entregas, mas em função dos benefícios esperados com estas entregas.

Ao impulsionarmos um trabalho em função da gestão de benefícios, poderíamos então responder questões como:

  • Por que estamos realizando este projeto?
  • Como iremos medir os benefícios?
  • Este projeto é ainda válido?
  • Os benefícios ainda são relevantes?
  • Já definimos todos os benefícios que estávamos esperando?
  • Quais os objetivos de negócio que este projeto nos ajudará conquistar?

Em uma visão simplista, precisamos definir o que é o sucesso em um projeto ainda durante sua concepção ou planejamento para podermos tomarmos decisões na evolução do projeto em função desta definição.

Este sucesso, é no mínimo, definido em relação a uma proporção pré-estabelecida entre os custos, o prazo e a entrega prevista de um projeto. Examinamos assim a tradicional tripla-restrição, mas introduzimos um elemento de correlação entre cada vértice.

003_01

Na comemoração dos 500 anos do Brasil, uma réplica da Caravela de Cabral custou aos cofres públicos mais de R$ 4.000.000,00 e não ficou pronta para o momento da festa. A entrega ocorreu com 5 meses de atraso e o benefício esperado foi nulo. Embora já considerada um exemplo de superfaturamento, para um projeto tão específico os seus realizadores deveriam manipular duas variáveis: alteração do escopo ou custo, sem no entanto modificar jamais a data de entrega.

003_02

No caso do lançamento de um ônibus espacial, devemos entender que o elemento característico do seu sucesso é a realização do produto em si; as variáveis de custo e prazo é que são flexíveis. Podemos facilmente desculpar um atraso no lançamento de um foguete em cinco meses, mas não podemos jamais aceitar a falha no seu lançamento e retorno à terra.

Se, por outro lado, estivermos considerando a construção de uma residência para permitir que uma família deixe o seu aluguel, podemos insistir que a manutenção do escopo contratado e o prazo são muito importantes, mas para muitas famílias o elemento fundamental será a manutenção do custo final da obra, amarrada ao orçamento doméstico.

Definição do elemento-chave de sucesso

003_03

Na representação dos triângulos acima não faz realmente diferença qual elemento está em cada lado das figuras.  No lado inferior da ilustração, fixamos o “elemento-chave” (a data de entrega para a Caravela, a qualidade operacional do ônibus espacial ou o orçamento familiar para a casa).

Os outros dois elementos poderão flutuar durante a evolução do projeto com distintas proporções; podemos encontrar situações em que a antecipação de um projeto pode representar economia ou gasto extra, por exemplo.

O importante é que na menor sinalização de que o “elemento-chave” está por variar em relação ao seu planejamento original, o esforço da gestão deve ser concentrado nos demais elementos. Quanto mais clara for a proporção de “ajuste permitido”, maior será a capacidade de tomada de decisão adequada para preservar o benefício principal que se espera para um dado projeto.

Este é um assunto que será revisitado, mas gostaria de aproveitar a oportunidade desta postagem para elogiar a organização do evento do Banco Central realizado entre os dias 9 e 10 de abril:

Encontro Internacional de PMO´s

O evento contou com participações importantes como Patrick Mayfield que discutiu o Modelo Britânico de Gestão de Programas e nos brindou com os 7 problemas capitais em gestão de projetos, trazendo a ilustração a seguir que fortalece um entendimento amplo que se vem considerando no mercado em relação a uma mudança do foco na entrega para o foco no benefício.

003_04

Alonso Soler falou sobre “O PMO e a aferição de benefícios e valor dos projetos” em uma palestra muito interessante das quais observo (para manter o texto pequeno) os pontos a seguir:

  • Benefícios são resultados mensuráveis
  • Benefícios contribuem para o alcance dos objetivos estratégicos
  • O Gerenciamento de Benefícios diz respeito ao respaldo às decisões de investimento e à otimização de sua realização

Tivemos ainda apresentações de Darci Prado, de representantes de Escritórios de Projeto de outros países (Canadá e Filipinas), o Case do Banco Central com Bruno Péres e equipe,  o Case do Espírito Santo com Joseane, o Case da Embraer e um painel de debate com as participações de Marcelo Cota, Paul Dinsmore, Alonso e Darci Prado.

Vale a pena ficar ligado à programação do Banco Central do Brasil para outros eventos relacionados à gestão de projetos!

003_05
http://www.bcb.gov.br/pre/evnweb/evento.asp?evento=7150

Outras referências:

Nau Capitânia (Caravela de Cabral):

Ônibus Espacial Columbia

peter

Soft Skills e Comunicação Não-Verbal

No post anterior, discutirmos alguns aspectos que podem ser utilizados pelos gerentes de projeto quando eles não possuem autoridade formal sobre o projeto, sua equipe ou seus recursos. Considerando o ambiente matricial predominante nas organizações, a grande maioria dos gerentes de projetos se encontram nessa situação. O que fazer?

Tom Kendrick sugere utilizar processosinfluênciamedições. Aproveitando os processos da própria organizações e melhores práticas em gerenciamento de projetos, é possível ao gerente influenciar os demais stakeholders do projeto.

1º-postImagine que estamos no início do projeto. O gerente do projeto pede ao patrocinador que preencha um Termo de Abertura doProjeto. Será que o patrocinador vai “obedecer”? Ou então, o GP solicita que a área de Engenharia encaminhe os requisitos e especificações do produto… Agora imagine que o gerente do projeto está utilizando os processos organizacionais adequadamente. Ele não precisa ter autoridade, os processos tem autoridade! Encaminhe um pedido ao patrocinador indicando que existe um procedimento de abertura do projeto definido na organização. Solicite ao gerente de engenharia que observe as responsabilidades de cada área descritas no plano de projeto.

E assim por diante. Os processos passam a ser o racional. “Estou solicitando algo porque é mandatório em um processo organizacional.”

É imprescindível identificar os processos de

gerenciamento de projetos a serem seguidos.

Outro aspecto que o gerente de projetos eficaz pode utilizar é a sua influência. Construir relações de confiança é extremamente importante para o sucesso dos projetos. Envolver as partes interessadas e conduzi-las na tomada de decisão também.

Screen Shot 2014-04-26 at 15.31.47

Figura 1 – Quem determinada a direção do projeto (Kendrick, 2012)

Envolver a equipe do projeto desde as fases inicias de planejamento assegura maior comprometimento. Obviamente, conforme vemos na figura anterior, as decisões autocráticas (líder sozinho) são mais rápidas. Entretanto, o envolvimento do time em doses certas e nos momentos adequados permite maior criatividade, envolvimento e apoio.

O gerente do projeto pode influenciar seus stakeholders de diversas maneiras (veja o post sobre Fontes de Poder). Uma excelente maneira de influenciar é saber fazer perguntas. A arte de fazer as perguntas certas e conduzir a outra pessoa às conclusões que você deseja. É mais ou menos o papel de um professor ou coach. Levar o “aprendiz” a se apropriar do conhecimento digirindo seu aprendizado e conclusões.

Vocês já devem ter ouvido falar em Escuta Ativa. A escuta ativa vai além de simplesmente ouvir. A comunicação não verbal é julgada mais importante do que a comunicação verbal em muitos estudos. Quando não existe coerência entre a comunicação verbal e não verbal, a mensagem fica truncada. Na dúvida, intuitivamente, confiamos mais nas pistas não verbais.

Assistam esses dois videos fantásticos abaixo!

Existem muitas referências em torno da linguagem do corpo (Livro O Corpo Fala .pdf), inteligência emocional (Daniel Goleman .pdf) e inteligência social (Daniel Goleman – Youtube), entre outras áreas afins. Desenvolver soft skills deve ser um objetivo de todo gerente de projetos.

Screen Shot 2014-04-26 at 17.04.19

Figura 2 – Princípios da Escuta Ativa

Finalmente, as medições. Por meio das métricas, períodos de medição e processos para coletar, analisar e comunicar informações do projeto, o gerente pode adquirir maior poder e influência.

Screen Shot 2014-04-26 at 16.55.00

Figura 3 – Métricas e comportamentos (Kendrick, 2012)

Sabemos que o comportamento das pessoas é bastante orientado pelas métricas ou indicadores ao qual estão submetidos. Isto é, se você estabelecer que uma métrica de produtividade é a quantidade de horas que as pessoas trabalham no projeto, elas podem ficar inclinadas a trabalhar mais horas, com um rendimento menor. Esse é o lado perverso dos indicadores, quando mal escolhidos.

Imagine a sua equipe trabalhando 16h por dia sem entregar os produtos esperados!

Pois bem, como gerente do projeto, temos o papel de definir processos de controle, incluindo o que será medido (indicadores), como e quando serão medidos (medições). Kendrick apresenta uma gama de indicadores e processos de medição que permitem ao gerente do projeto melhor controlar seu projeto, mesmo sem autoridade.

Screen Shot 2014-04-26 at 17.10.24

Figura 4 – Como definir medições no projeto (Kendrick, 2012)

 

Agora vocês tem poderosas ferramentas para gerenciar seus projetos, mesmo sem autoridade! Recomendo a leitura do post anterior e suas referências. Também vale muito a pena ler os livros de Tom Kendrick. Na próxima semana, vamos falar sobre tipos de contratos e problemas nas contratações. Até lá!

 

SCRUM e sua aplicação para o Planejamento Estratégico da Organização

Por Peter Mello

Em 2003 eu já trabalhava com RUP, um framework de trabalho iterativo e com objetivos claros de entregas por etapas, mas com um grande nível de documentação e controle atrelados.  O XP surgiu como uma iniciativa de uma pequena equipe em um grande projeto e começamos a discutir métodos ágeis e sua aplicação. Por esta época começamos a falar também de SCRUM, mas o contexto era todo alinhado a um ambiente de Tecnologia da Informação.

Dez anos depois, estou envolvido com projetos de Engenharia sob encomenda e Manufatura de equipamentos pesados (tão pesados que a venda não é feita por “casos de uso” ou “sprints” ou “lista de equipamentos”, mas por toneladas mesmo!). Em um primeiro momento parece que não há espaço para uma “metodologia ágil” e estamos envolvidos em projetos com cronogramas gigantescos e informações ainda mais complexas quando tratamos das Ordens de Produção na fábrica.

Mas na indústria há muito se fala do Kanban, desenvolvido na década de 40 e implementado na Toyota em 1953. Hoje Kanban é classificado por muitos como um método ágil e como uma demonstração de que os diversos métodos ágeis – entre eles o Scrum – podem ser aplicados fora do contexto da Tecnologia da Informação.

Versões eletrônicas para o Scrum normalmente permitem ser configurados para uma aplicação do Kanban e vice-versa, como é o caso do Kanbanize.Com, que pode ser utilizado como uma versão on-line para os post-its.

image002
(fig.1 – uma interface eletrônica com aplicação no Planejamento Estratégico – Kanbanize)

 

No final das contas, não importa qual “Sabor” do método ágil escolhido, mas existe aqui uma oportunidade para a sua aplicação no desenvolvimento de ações para um Planejamento Estratégico.

image004
(fig.2 – Consulta no Google demonstra uma gama enorme de informações sobre métodos ágeis)

Desafio na execução de Ações de um Planejamento Estratégico

 

Em diversas organizações onde já estive envolvido com consultorias ou projetos, o Planejamento Estratégico é elaborado com uma massa enorme de horas “nobres”, com o envolvimento de Diretores e Alta Gerência, até que uma lista de subprojetos e ações estratégicas são publicados tendo como essência a “transformação da empresa para seus novos objetivos estratégicos” ou “recuperação do foco para realizar os seus objetivos históricos”.

Encontramos aí a aplicação das duas ferramentas mais populares para a gestão de projetos: O Excel e o correio-eletrônico.

Após a reunião do planejamento, o Excel vira anexo obrigatório e membros da alta, média e baixa gerência são convidados a tomar parte das ações necessárias à realização do Planejamento Estratégico.  Em muitos casos, certos profissionais recebem apenas um substrato das ações e não têm a noção clara do vínculo de suas atividades com outras que irão ser necessárias para o atingimento das metas, que serão revisitadas pela Diretoria e Alta Gerência meses depois.

Organizando tarefas em um Planejamento Estratégico

 

Seguramente há boas opções no mercado de softwares que podem contribuir para o detalhamento e acompanhamento de um Planejamento Estratégico.  Um portal que naveguei recentemente e que oferece uma interface específica para o Planejamento Estratégico é o Project Builder (fig.3).

image005

(fig.3 – área do Project Builder específica para a criação de Planejamento Estratégico,  Metas e Tarefas)

 

Para o acompanhamento de múltiplos indicadores, com uma metodologia para o acompanhamento de painéis detalhados e “faróis”, outra ferramenta que utilizei é o Stratws (fig.4), embora este segundo eu tenha me encontrado com algumas dificuldades operacionais que não sei ainda como atribuir a falhas em usabilidade, no meu desconhecimento de macetes para sua operação ou alguma questão de sua implementação (que me parece não ser a última versão).

image007

(fig.4 –visão parcial de painel de acompanhamento de indicadores de Planejamento Estratégico – Stratws)

 

No entanto –  e aqui começamos a tratar o tema desta postagem – o que precisamos entender é que independente da ferramenta (Excel, E-mail, Project Builder, Stratws, etc), poderemos nos encontrar em uma próxima reunião com a Alta Diretoria para descobrir que a grande parte das Ações Estratégicas não aconteceram em função de urgências, rotinas de trabalho, reuniões, compromissos com clientes, entre outros.

Em uma abordagem tradicional para o Planejamento Estratégico, os envolvidos irão realizar um detalhamento das atividades através de um formulário 5W2H, onde descrevem o que será feito (What), quando será feito (When), como será feito (How), por quanto será feito (How Much), porque será feito (Why), onde será feito (Where) e por quem será feito (Who).

A listagem dos WHAT/WHEN/WHO poderá dar origem a um cronograma onde cada item tem uma data final, não necessariamente coordenada em entregas específicas para a empresa.  Ou seja: Um conjunto de “trabalho” irá definir o “prazo” final.

Em uma abordagem com princípios ágeis e que no SCRUM vamos chamar de SPRINTs , nós temos a criação de “time-boxes” ou períodos pré-definidos de tempo onde os participantes terão objetivos claros para um conjunto de entregas.

Em outras palavras, a partir de prazos pré-estipulados (datas de entregas de pacotes/Sprints) os participantes irão definir o trabalho que será encaixado.

 

 

O que muda com Sprints?

 

A palavra de ordem é: ENTREGAS.

Para cada período pré-definido, o cliente (o representante da empresa responsável pelo Plano Estratégico) receberá um subconjunto claro dos itens que compõem os objetivos/metas/tarefas relacionadas a este planejamento estratégico.

O trabalho a ser realizado deve então ser distribuído entre Sprints, mas – assim como no Kanban – temos três grandes grupos de items:

  • O que temos que fazer, ou “backlog”;
  • O que estamos fazendo, ou “WIP/SPRINT”;
  • O que já está pronto.

Um resumo conceitual das abordagens Scrum e Kanban interessante pode ser encontrada no site da Atlassian (fig.5)

 

image009
(fig.5 –https://www.atlassian.com/agile/scrum)

 

Deixaremos para uma futura postagem uma abordagem mais ampla do Scrum, mas existem dois elementos fundamentais para a boa distribuição de trabalho entre o “backlog” e “cada Sprint” que merecem destaque:

– Cada objetivo/meta/tarefa é calculado com base a uma estimativa de “trabalho”; o trabalho representa a carga de horas que cada recurso deverá investir na atividade e não a duração da tarefa.

– Cada objetivo/meta/tarefa tem um valor de negócio, definido pelo cliente; o “business value” de cada item irá auxiliar na definição de quais itens devem ser priorizados em cada Sprint.

 

Definindo Sprints

 

  • Vamos supor 10 objetivos estratégicos (obj1…N);
  • Vamos supor que cada objetivo estratégico tem 3 metas (objNa,objNb,objNc)
  • Vamos supor que cada meta tem 3 atividades (01,02,03)

O “backlog” antes da criação da primeira Sprint terá então 10 x 3 x 3 = 90 tarefas; podemos imaginar que em certos momentos, não temos ainda as metas claras ou o detalhamento das tarefas. Por isso, vamos imaginar que o “business value” de um objetivo poderá ser distribuído nas tarefas na medida em que vão sendo identificadas.

1º Passo: estabelecer um valor de negócio para cada objetivo estratégico. Podemos usar desde uma classificação simples (baixo, médio, alto) até uma composição de parâmetros diversos.

2º Passo: organizar a lista do maior valor ao menor valor; os objetivos de maior valor terão preferência na composição do primeiro Sprint.

3º Passo: detalhamento dos objetivos em metas;

4º Passo: validação das metas para o Sprint: caso se identifique que a carga de trabalho esperada para uma meta poderá indicar que a mesma levará mais tempo para ser realizada do que o período definido para o Sprint (em geral 30 dias), a meta deverá ser detalhada em tarefas para que estas sejam distribuídas em duas ou mais Sprints.

5º Passo: Decomposição – sempre que possível – das metas nas respectivas tarefas que a compõem.

6º Passo: Estimativas de carga de trabalho: caso a carga de trabalho seja atribuída a uma meta e não em suas tarefas, deve-se buscar em iterações futuras acomodar a carga prevista da meta ao conjunto de tarefas (20 horas de uma meta são distribuídas em 4 tarefas de 5h, por exemplo).

7º Passo: Definição dos recursos prováveis para cada meta e/ou tarefa;

8º Passo: Definição da carga de trabalho em uma SPRINT a ser dedicado por cada recurso (Pode-se definir por exemplo que a Alta Gerência irá dedicar no máximo 2 horas por semana ao Planejamento Estratégico; a Gerência irá dedicar 4 horas e outros participantes até 8 horas por semana)

Em outras palavras: Se uma atividade de 8 horas estiver alocada a um Diretor, a duração prevista será de 4 semanas; se for alocada a um gerente, a duração para a realização da tarefa será de 2 semanas; e outros membros de equipe poderão fazer 1 atividade de 8h em cada semana).

9º Passo: Verifica-se alguma dependência entre tarefas: Embora isso possa ser detalhado posteriormente, 2 tarefas que possuem uma dependência entre uma e outra e que tem uma carga prevista de 8h não “cabem” em uma mesma Sprint se estiverem atribuídas a um Diretor.

10º Passo: Examinando os itens de maior valor de negócio e eventuais dependências, bem como a carga de hora total de “capacidade da equipe”, uma SPRINT é montada com a passagem destas atividades de “backlog” para “A realizar”.

Em outras palavras: Se a equipe tem 2 membros da alta gerência (2 x 8 horas/mês), 4 gerentes (4 x 16 horas/mês) e 5 membros de equipe (5 x 32 horas/mês) então a “capacidade da equipe” é de realizar 800 horas de trabalho.

Continuidade do Fluxo de Trabalho e Entregas

 

Para levantarmos dúvidas dos leitores e criarmos um detalhamento desta postagem que tenha ampla aplicação, iremos retornar a este assunto em uma nova postagem.

Aguardo seus comentários! Traga as suas experiências, suas dúvidas ou correções ao conteúdo aqui elaborado!

peter

Gerenciando Projetos sem Autoridade

No início do Blog MundoPM, escrevemos uma série de posts sobre a carreira em gerenciamento de projetos (Parte 1, Parte 2 e Parte 3) com o intuito de tentar ajudar aqueles que estão iniciando nesta área. Gerenciar projetos envolve diferentes áreas de conhecimento, incluindo habilidades técnicas, gerenciais e interpessoais.

Neste post, vamos discutir “como gerenciar projetos quando o gerente não tem autoridade / poder suficiente?“. Será que é possível?

Figura26

Figura 1 – Gerente de Projetos vs Gerente Funcional (Fonte: Guia PMBOK®) Existem basicamente três tipos de estruturas organizacionais:

  • Funcional: hierarquizada e organizada por especialidade (Comercial, Financeiro, Operações, Engenharia etc)
  • Projetizada: organizadas em torno de projetos, demais áreas proveem infraestrutura de apoio
  • Matricial: combinação das estruturas funcional e projetizada em que as funções / operações e os projetos podem ter diferentes graus de importância e prioridade

Na estrutura funcional, os gerentes de projetos tem o mínimo de poder, devendo responder a gerentes funcionais. Já no outro extremo, temos a estrutura projetizada em que o gerente de projetos tem o máximo de poder. Usualmente, as organizações estão em um meio termo na escala de organizações matriciais. Neste caso, temos um problema adicional: mais de um chefe. Em estruturas matriciais, os membros da equipe do projeto respondem tanto para o gerente do projeto quanto para o gerente funcional, o que pode trazer conflits. Como podemos ser mais efetivos no gerenciamento de nossos projetos quando não temos poder / autoridade? Precisamos desenvolver habilidades de negociação, liderança, resolução de conflitos. Além disso, adquirir influência organizacional, fazer networking e conhecer métodos de tomada de decisão. O gerente de projetos deve ser capaz de:

  • Conhecer e influenciar os principais stakeholders
  • Desenvolver a equipe do projeto
  • Delegar tarefas e atribuições adequadamente
  • Agir proativamente e preventivamente
  • Diagnosticar causas de problemas e planejar ações corretivas imediatamente
  • Obter compromisso e comprometimento dos stakeholders e, principalmente, da equipe do projeto
  • Balancear requisitos, restrições e premissas do projeto
  • Motivar, promovendo eficiência e desempenho

Exercer influência sem ter autoridade é o fator que diferencia gerentes de projetos bom e medianos de excelentes gerentes de projetos. Há inclusive cursos sobre esse tema, como Managing Without Authority, em Stanford. Além disso, recomendo a leitura do artigo Exerting Influence without Power, Harvard Business Review.

Uma terceira referência bastante útil é o livro “Results Without Authority: Controlling a Project When the Team Doesn’t Report to You“, Tom Kendrick. Trata-se de uma referência muito bacana. downloadEste livro é estruturado em duas partes. A primeira descreve os três elementos de controle do projeto: processo, influência e medição. A segunda parte mostra quando usar esses três elementos de controle ao longo da vida de um projeto típico, seguindo os cinco grupos de processos do Guia PMBOK®. O controle do projeto por meio de processos envolve o uso de processos já definidos e em uso pela organização, bem como abordar questões-chave relacionadas estruturação do projeto antes de mobilizar os membros da equipe do projeto. O Apêndice A do livro fornece uma longa lista de perguntas divididos em planejamento, execução e controle. Kendrick aponta repetidamente que obter compromisso dos stakeholders-chave do projeto o mais cedo possível é vital o sucesso do projeto. Neste ponto, vale a pena conferir o papel do patrocinador no projeto. Em “Controle através de Influência “, Kendrick primeiro caminha através de métodos e estruturas bem conhecidas, tais como a fonte do poder organizacional, a comunicação como a fundação de uma gestão eficaz do projeto e a teoria de fatores de motivação e higiene de Hertzberg. O terceiro elemento-chave de controle em projetos é Medições. Isto é, o gerente pode influenciar o projeto por meio das métricas que ele estabelece para o controlar, definindo a periodicidade e modo de medição. Kendrick apresenta o quadro comportamentos / medidas / objetivos e afirma que a introdução de medidas em um projeto deve contribuir para alinhar comportamentos com os objetivos estabelecidos. As métricas podem ser de três tipos: previsão, diagnóstico e retrospectivas . Toda boa métrica deve ter três características:

  • Apoiar os objetivos do projeto
  • Influenciar o comportamento dos envolvidos
  • Auxiliar na tomada de decisão

Se tiver interesse em se aprofundar neste assunto, mande um email para mim (trentim@mundopm.com.br). Tenho alguns materiais que posso compartilhar. Na próxima semana, vamos introduzir outros aspectos para auxiliar gerentes de projetos em gerenciar sem autoridade. Até lá!

MS-Project Professional ONLINE sem o Project Server

Soluções de baixo custo com o Sharepoint Foundation

Existe um entendimento generalizado de que o MS-Project só se torna uma ferramenta colaborativa na WEB através da aplicação do Project Server (ou sua versão na nuvem da Microsoft: O Project Online); alguns usuários já descobriram que é possível interagir com o MS-Project Professional e o Sharepoint, mas há um potencial inexplorado na aplicação do MS-Project Professional com a versão gratuita do Sharepoint – o Sharepoint Foundation.

O Sharepoint Foundation pode ser instalado com o SQL Express, ambos gratuitos, mas irá exigir a aplicação de um Windows Server. Outra opção é a contratação do Sharepoint como serviço e há empresas especializadas nos EUA que oferecem o Sharepoint Foundation para um número ilimitado de participantes em projetos por não mais do que USD 10,00 dólares!

Uma opção com um maior controle sobre acesso de usuários e distribuição de dados se pode obter com versões pagas do Sharepoint (inclusive o Sharepoint Online junto com o Office 365) e somente em estágios avançados de aplicação do MS-Project em um ambiente multi-projetos ou para relatórios sobre todo o Portfolio é que um investimento em um Project Server começa a valer a pena.

Em outras palavras, qualquer projeto de pequeno ou grande porte que atualmente esteja dependente de cronogramas encaminhados como documentos e troca de e-mails podem se beneficiar de uma implementação colaborativa do MS-Project com um custo baixo. Além disso, boa parte dos usuários poderá interagir com o cronograma diretamente na versão online sem precisar pagar novas licenças da versão Desktop.

Utilizando o Sharepoint

A forma mais rápida de iniciar o uso do Sharepoint é com a contratação do serviço online (Sharepoint Online) diretamente com a Microsoft ou buscar uma empresa que ofereça o Sharepoint Foundation como serviço.

O primeiro acesso via MS-Project Professional pode ser feito pelo próprio aplicativo, utilizando-se a opção disponível entre os modelos: Novo da Lista de Tarefas.

image001
(fig.1 – opção do menu para novos documentos)

É importante destacar que múltiplas listas podem ser criadas e que cada uma pode ter o seu “Portal do Projeto”, onde usuários irão colaborar com documentos, notícias e até mesmo o One Note online.

Exemplo de aplicação

Na figura a seguir (fig.2) temos um pequeno conjunto de tarefas criadas no MS-Project após a abertura do modelo de tarefas (fig.1)

image002

(fig.2 – Tarefas em uma versão MS-Project Professional)

 

Para salvar o documento, basta optar pela opção “Salvar e Sincronizar” (fig.3)

image004

(fig.3 – detalhe da página de informações no aplicativo MSP)

Uma vez configurada a lista de tarefas no Sharepoint, sempre que o MS-Project for aberto ele irá buscar a sincronização de documentos locais com o site Sharepoint (fig.4).

image006
(fig. 4 – janela de conexão com o Sharepoint)

Cronograma online

Muitos usuários já viram as listas de tarefa no Sharepoint e não identificaram uma opção para enxergar o cronograma como criado no MS-Project. Como padrão, a visão de tarefas é uma lista com três ou quatro informações oriundas do cronograma em questão (fig.5)

image007
(fig.5 – Visão padrão de tarefas no Sharepoint)

 

No entanto, os usuários podem optar por habilitar a visão em Diagrama Gantt e o efeito será similar ao de se abrir o MS-Project em sua versão On-line como hoje se conhece o Project Server (fig.6 e 7).

image009

(fig.6 – seleção da opção de visualização no modo Gantt)

image010
(fig. 7 – visão das atividades do MS-Project em sua versão ONLINE no Sharepoint)

Sincronismo entre tarefas online e no MS-Project

Mesmo utilizando o Sharepoint Online, usuários podem trabalhar nas tarefas remotas e locais com opções de sincronismo entre usuários. No exemplo a seguir, a atividade “Examinar Relação MS-Project/Sharepoint” foi apontada com um progresso na versão online de 25% (fig. 8)

image012
(fig.8 – apontamento online de avanços em projeto)

 

Ainda em nosso exemplo, na versão MS-Project a mesma atividade foi apontada com um avanço de 20% (fig.9).

image014

(fig.9 – apontamento no MS-Project de avanços em projeto)

 

Ao salvar ou verificar o sincronismo com o Sharepoint, o MS-Project irá abrir uma tela de resolução de conflitos (somente para alterações concorrentes em um mesmo registro), conforme ilustrado na fig. 10.

image016
(fig.10 – Janela de resolução e conflitos)

 

Basta ao planejador escolher entre a versão on-line ou local para resolver o conflito. Por assim dizer, embora as atividades sejam compartilhadas, espera-se que cada usuário realize alterações somente em tarefas de sua responsabilidade e quando isso não ocorrer é o usuário que estiver com o documento no MS-Project que terá a opção de decidir qual é a alteração válida para o projeto, conforme fig.11.

image018

(fig.11 – janela de resolução de conflito com item escolhido em verde)

 

Uso de Fases (Tarefas-Resumo)

Outra interpretação incompleta da capacidade de utilização do Sharepoint de certos usuários é o entendimento (equivocado) de que as tarefas no Sharepoint não podem ser agrupadas.

No exemplo a seguir (fig.12), uma fase “Testes” foi criada no MS-Project para agrupar as atividades correspondentes, permitindo assim o desenvolvimento de uma EAP (Estrutura Analítica de Projeto).

image020

(fig.12 – Tarefas resumo no MS-Project)

O resultado pode ser rapidamente examinado na versão online (fig.13), bastando apenas recarregar a página de Internet.

 

image022

(fig.13 – Tarefas resumo no Sharepoint)

 

Portal de Projeto

Outro recurso importante disponível no Sharepoint, mesmo na versão Foundation, é a opção para a criação de sites individuais para cada projeto. Os Portais de Projeto permitem a construção de áreas customizáveis pelos usuários onde a equipe de projeto irá ter um resumo das tarefas por vir e em atraso, trocar notícias e apontamentos, atualizar documentos e consultar o cronograma (fig.14).

 

image024

(fig.14 – Portais individuais para cada projeto no Sharepoint)

 

Dicas:

Caso o usuário decida contratar o serviço PROJECT ONLINE, a documentação de oferta deste serviço dá a entender que o usuário também deve adquirir o MS-Project como parte de uma assinatura (Office 365), mas isso não é necessário caso o usuário já tenha uma licença local instalada do MS-Project Professional (não é possível usar a versão MS-Project Standard).

Empresas podem começar a explorar a colaboração online utilizando serviços do Sharepoint Foundation e depois evoluir para o site Sharepoint pago, tanto em instalações “in-company” como através da contratação de serviços remotos “em nuvem”, como é o caso dos serviços do Microsoft Azure.

 

Autor:

Peter Berndt de Souza Mello
Consultor/gestor de projetos pela TMSA

peter

Teorias da Motivação e Influência do GP

Gerenciamento de Recursos Humanos é uma área extremamente importante para o sucesso dos projetos. Entretanto, os processos do Guia PMBOK®, apresentados no post anterior, não compreendem todos os aspectos da gestão de pessoas. Portanto, neste post vamos avançar um pouco mais em teorias da motivação e influência do gerente de projetos sobre a equipe.

 

Teorias da Motivação

Abraham MASLOW – Hierarquia das Necessidades

A teoria de Maslow é clássica e talvez a mais conhecida. A ideia é que existe uma hierarquia de necessidades e que as pessoas buscam satisfazer os níveis mais baixos para depois se preocuparem com os níveis mais altos. Uma vez satisfeito o nível inferior, ele deixa de servir como motivador.

450px-Hierarquia_das_necessidades_de_Maslow.svg

Figura 1 – Hierarquia de Maslow (Fonte: Wikipedia)

 

Frederick HERZBERG – Teoria da Higiene

A teoria de Herzberg está dividida entre fatores higiênicos e motivadores, ambos relacionados ao ambiente e condições de trabalho. Os fatores higiênicos previnem a insatisfação, enquanto os motivadores impulsionam a satisfação.

piramide2

Figura 2 – Teoria de Maslow versus Teoria de Herzberg (Fonte: Isadora Costa)

 

Victor VROOM – Teoria das Expectativas

A teoria de Vroom diz que a motivação é criada a partir das expectativas. Isto é: a expectativa de receber algo positivo é o que motiva as pessoas. Dessa forma, a recompensa deve ser adequada e compatível, além de ser possível e razoável. Outro aspecto importante da teoria é que segundo Vroom, as pessoas se transformam ou passam a se comportar da maneira que se espera delas (Trentim, 2011).

 

David MCCLELLAND – Teoria da Realização

Para McClelland, as pessoas são motivadas por três fatores: realização (ou sucesso), poder e afiliação (ou associação):

Sucesso Procura alcançar sucesso perante uma norma de excelência pessoal.
Afiliação Procura relações interpessoais fortes.
Poder Procura controlar ou influenciar outras pessoas e dominar os meios que lhe permitem exercer essa influência.

 

Douglas MCGREGOR – Teoria X e Y 

McGregor desenvolveu a Teoria XY, representando duas vertentes opostas da administração.

A primeira, chamada Teoria X, baseia-se no pensamento tradicional-clássico da administração e considera que as pessoas são preguiçosas e indolentes, devendo ser dirigidas e supervisionadas continuamente. Em contrapartida, a Teoria Y defende que as pessoas são esforçadas, procuram e assumem responsabilidades. Segundo esse pensamento, as pessoas são competentes, automotivadas e têm capacidade de trabalhar em equipes autodirigidas (Trentim, 2011).

Pressuposições da Teoria X

Pressuposições da Teoria Y

As pessoas são preguiçosas e indolentes.As pessoas evitam o trabalho.As pessoas evitam a responsabilidade, a fim de se sentirem mais seguras.As pessoas precisam ser controladas e dirigidas.As pessoas são ingênuas e sem iniciativa As pessoas são esforçadas e gostam de ter o que fazer.O trabalho é uma atividade tão natural como brincar ou descansar.As pessoas procuram e aceitam responsabilidades e desafios.As pessoas podem ser automotivas e autodirigidas.As pessoas são criativas e competentes.

 

Agora que vimos algumas teorias da motivação, como o gerente de projetos pode influenciar, motivar e gerenciar as pessoas da sua equipe? Basicamente, existem cinco fontes de poder, descritas a seguir. É importante que o gerente domine mais de uma e que saiba como e quando utilizar cada uma delas.

  • Formal (Legítimo) – baseado na posição do líder na estrutura hierárquica da empresa.
  • Recompensa – baseado na capacidade que o líder tem de oferecer recompensa financeira, psicológica, política ou social.
  • Punição – baseado na aptidão do líder em penalizar o liderado.
  • Especialista – baseado nas habilidades e conhecimentos especiais do líder.
  • Referência – baseado na influência do líder para com os subordinados, acesso a informações, ou relações com pessoas importantes ou influentes.

 

Uma das grandes dificuldades em gestão de pessoas e equipes é atribuir responsabilidades. Para isso, vale a pena revisitar os conceitos de Liderança Situacional.

comportamento-do-lider

Figura 3 – Liderança Situacional (Modelo de Hersey & Blanchard, 1986)

Portanto, a atribuição de responsabilidades depende do nível de maturidade dos membros da equipe.

Nível de Maturidade

Atuação

Baixa: pessoas sem capacidade ou disposição. Inseguras. Determinar: o que, como, onde e quando fazer. Modelo autoritário de liderança.
Baixa Moderação: pessoa sem capacidade, mas com confiança e disposição. Persuadir: apoiador, explica como desenvolver e executar as tarefas. Dialoga, para orientar e auxiliar o colaborador. Essa liderança é uma transição do Modelo autoritário para o democrático.
Alta Moderação: pessoa com capacidade, mas sem disposição ou é insegura, Compartilhar: apoiador, o líder ouve, encoraja, valoriza a equipe e compartilha a autoridade para gerar segurança à equipe. Modelo democrático de liderança.
Alta: pessoas capazes e dispostas. Delegar: permite autonomia à equipe em seu modo de agir. O líder fica à disposição para quando for solicitado e apenas observa, monitora e acompanha os resultados.

 

Para finalizar, cumpre ressaltarmos que gestão de pessoas é uma área de conhecimento bastante vasta. Algumas referências:

Para se manter atualizado nas práticas de gerenciamento de projetos, vale a pena também visitar Voices on Project ManagementNa próxima semana, apresentaremos alguns exemplos de ferramentas e técnicas para gestão de pessoas em projetos, tais como matriz de responsabilidades, organograma do projeto e o plano de gerenciamento de recursos humanos. Até lá!