Planejamento Estratégico sem Gestão de Projetos. Esqueça.

Alterar o desempenho de uma organização quase sempre implica em formular e implementar estratégias.

Formular a estratégia é o processo de planejamento que visa definir os caminhos que a organização deve trilhar para tornar real sua visão de futuro, a partir da identificação de forças restritivas e impulsionadoras, externas e internas, decorrentes de uma análise ambiental. Estes caminhos devem ser traduzidos em objetivos estratégicos. O processo de formulação da estratégia, geralmente, inicia com a análise ambiental e termina com as estratégias definidas. Convenciona-se chamar esta etapa de planejamento estratégico.

Implementar a estratégia inclui a definição das ações, indicadores e metas necessárias, utilizando-se de informações, requisitos de partes interessadas, alocação de recursos, assim como os processos para a comunicação e o monitoramento dos resultados. Boa parte das vezes, a implementação utiliza como instrumento o Balanced Scorecard (BSC), um sistema para gerenciamento da estratégia surgido na década de 1990.

O BSC foi desenvolvido por Robert Kaplan e David Norton, nos Estados Unidos. Reconhecendo algumas fraquezas e incertezas da abordagem comum de gestão da época, focada só nos resultados financeiros, mas muito longe da execução e de outras perspectivas além da financeira, a abordagem do BSC corrige essa distorção e propõe uma nova forma de “medir” a organização.

O BSC tem como premissa que a estratégia de uma organização é uma hipótese. Ele revela o movimento de uma organização que está em uma posição atual e pretende estar em uma posição futura desejável, mas incerta. Os autores do BSC, reforçam que, como a organização nunca esteve nessa posição futura, a trajetória almejada envolve uma série de hipóteses interligadas. Ele permite a descrição das hipóteses como um conjunto de relações de causa e efeito explícitas (mapa estratégico) e sujeitas a testes que ganham vida com a proposta de ações bem definidas.

E daí?

Não acontece nada, quase sempre. Na prática as ações propostas pelo BSC se tornam figurativas. É como se o planejamento estratégico acabasse com a proposta das ações e dos projetos estratégicos. Fica todo mundo esperando a mágica. O mágico falta. Os projetos deveriam por si só acontecer e permitir a virada da organização. Inúmeros casos, conhecidos no Brasil e no exterior, ilustram o planejamento estratégico como um esforço, caro, que não consegue dar os resultados esperados e que acaba ficando só no papel.

Onde está o problema?

As consultorias que elaboram o planejamento estratégico, geralmente, atuam só até a fase que propõe as ações ou em outros casos, não sabem ou não acham importante gerenciar as ações propostas como projetos. Parece que o planejamento estratégico acaba com a proposta das ações. Não acontece. As técnicas de gerenciamento de projetos é que permitem dar vida ao planejamento estratégico. Projetos possuem início, meio e fim e podem ser alterados em função das mudanças do ambiente e dos objetivos estratégicos. Indicadores de projetos devem ser alinhados dinamicamente com indicadores estratégicos. Esta é a saída para o planejamento estratégico deixar de ser uma utopia.

Uma saída

 O Life Cycle Canvas (LCC) , um canvas que permite a gestão de projetos ao longo do ciclo de vida é o instrumento natural para gerenciar os projetos estratégicos. Sua estrutura baseada em uma tela, canvas, e pelo fato de permitir o gerenciamento ao longo de todo o ciclo de vida, incorporando a mudança, como uma situação normal, torna a tarefa de gerenciar as ações oriundas do planejamento estratégico uma realidade. O LCC permite gerenciar projetos do portfólio estratégico de uma mesma forma. A empresa agora pode comparar projetos e saber exatamente em que fase está cada um deles. Melhor, indicadores de projetos que servem ao controle são automaticamente registrados e permitem a alteração do projeto a qualquer momento, dando vida ao planejamento estratégico.

 AAEAAQAAAAAAAAfiAAAAJDgwYjlmMTQ4LTlmMjYtNDYwOC1iNDBjLThmYWMxNTM5MWU2Nw

 

cropped-lifecyclecanvas.jpg

Organização da Operação de Serviço de TI

A organização da operação  de serviço de TI deve considerar algumas  funções importantes:

  • Uma central de serviços que é o ponto único de contato (SPOC) para os usuários, a fim de lidar com incidentes, requisições de mudanças e requisições de serviço.
  • O gerenciamento técnico que permite o gerenciamento da infraestrutura de TI.
  • O gerenciamento operacional que executa atividades diárias necessárias para gerenciar a infraestrutura de TI
  • O gerenciamento de aplicativos que é responsável por gerenciar aplicativos em seu ciclo de vida.

A forma de organizar as funções da operação de TI deve ser feita de acordo com a realidade de cada empresa e envolve tamanho, geografia e cultura.

Boas práticas

Boas práticas é uma expressão derivada do inglês best practice, a qual denomina técnicas identificadas como as melhores para realizar determinada tarefa. Por exemplo, as boas práticas para se calcular uma equação são as melhores formas para se atingir um melhor resultado, e por isso, é sempre recomendável seguir as boas práticas. Em diversas profissões têm sido criadas normas de boas práticas que definem a forma correta de atuar dos respectivos profissionais (wikipédia)

Em TI, o ITIL é um exemplo de boa prática. O ITIL é o modelo de referência para Gestão de Serviços de TI mais aceito em todo o mundo, o ITIL (Information Technology Infrastructure Library) é um conjunto de boas práticas para infraestrutura, operação e manutenção de serviços de TI criada na década de 1980, a partir de pesquisas com consultores, especialistas e doutores da área.

Life Cycle Canvas (LCC) : Gerente de Projeto ou Operador de Tarefas ?

por Manoel Veras.

Historicamente, a gestão de projetos passou por diversas mudanças em relação às boas práticas desde que se tem registro. Dentro das empresas, o uso dessas práticas se tornou mais efetivo entre os anos de 1950 e 1960, em meio a projetos de grande complexidade nas áreas militar e espacial. Até a década de 1980, boa parte destes projetos era gerenciada considerando os processos e técnicas de gerenciamento tradicionais ligados a custos, escopo, tempo e qualidade. Gerentes de projetos se confundiam com operadores de tarefa.

Agora a coisa mudou. Kerzner reforça que as restrições em projetos foram alteradas (não só tempo, custo e escopo) para definir o sucesso ou o fracasso do projeto. Fazer compensações entre tempo, custo e escopo era natural. Hoje existem muitas outras restrições concorrentes, como, por exemplo, aceitação de riscos, manter reputação, satisfação do cliente, etc. O mais complicado é que a importância de cada restrição pode ser alterada durante o projeto, pois o ambiente de projetos é cada vez mais dinâmico. Assim, tais restrições precisam ser monitoradas e até controladas. Precisa-se pensar o tempo todo em restrições estratégicas. Nesse nível, constata-se que boa parte delas são restrições de negócio – e, portanto, os gerentes de projetos devem virar gerentes de negócio. Como ser gerente de projeto de negócio estando focando só em tarefas? Impossível.

Operadores de tarefa, de uma forma geral, ficam surpresos quando observam as novas atribuições de um gerente de projetos. Eles, em geral, não gostam de gerenciar equipes e muito menos partes interessadas. Pensar no negócio, então, nem se fala. Considerar riscos e atuar para mitiga-los é outra atribuição que incomoda. Comunicação é outro aspecto considerado difícil e falar com partes interessadas é considerada uma tarefa chata. Baixar a cabeça e continuar operando tarefas utilizando ferramentas diversas, por sinal muitas de excelente qualidade, não é a melhor maneira de resolver isto.

 Se observarmos a evolução do próprio guia PMBOK, podemos notar que as mudanças nas últimas versões se dão em aspectos até então não considerados como importantes para o operador de tarefas. A introdução da área de conhecimento “stakeholders” na quinta versão sintetiza este aspecto. Metodologias como PRINCE2 calibram as atribuições do gestor de projeto de forma inteligente entre o gerente especialista e o diretor executivo de projetos, facilitando e definindo claramente as atribuições de cada um. O PRINCE2 facilita entender o papel atual do gerente de projetos. Mesmo assim, muita gente na área trabalha na camada de baixo, sendo uma espécie de gerente da equipe especialista e suporte do projeto, mesmo sabendo que existem outras demandas importantes para o gerente de projetos.

O que fazer?

A utilização de ferramentas visuais como o Life Cycle Canvas  (LCC) seriam uma saída natural para operadores de tarefa que desejam se tornar gerentes de projeto. Pois são excelentes para comunicar e integrar o projeto, considerando os diversos aspectos subjetivos do gerenciamento, mas não abrem mão dos aspectos técnicos e do controle das tarefas envolvidas. A comunicação é facilitada considerando que os principais aspectos do projeto a serem comunicados às partes interessadas, podem ser resumidos em uma única tela. Além disso, permitem a gestão dinâmica do projeto em todo o seu ciclo de vida. A integração é outro aspecto facilitado, pois as áreas envolvidas e suas relações no gerenciamento com o uso de uma única tela tornam-se mais simples. Ferramentas e técnicas podem ser facilmente agregadas a tela principal do LCC, permitindo a operação das tarefas vinculadas ao verdadeiro gerenciamento do projeto.

 cropped-lifecyclecanvas.jpg

Gestão Ágil de Projetos com Life Cycle Canvas (LCC)

 por Manoel Veras.

Os métodos ágeis são recomendados para cenários complexos onde existem incertezas diversas relacionadas aos projetos. Eles reforçam que a utilização de ciclos adaptativos que permitem mudanças no plano de gerenciamento (linha de base) combinado com entregas iterativas e incrementais ajudam a reduzir os riscos envolvidos em certos tipos de projetos. A ideia de utilizar o ciclo de vida iterativo e incremental já foi mencionada na última versão do guia PMBOK e é contemplada pelo Life Cycle Canvas (LCC).

A gestão ágil é baseada no manifesto ágil lançado no início da década passada. O manifesto ágil prega os quatro valores relacionados abaixo:

  • Indivíduos e interação entre eles mais que processos e ferramentas;
  • Software em funcionamento mais que documentação abrangente;
  • Colaboração com o cliente mais que negociação de contratos;
  • Responder a mudanças mais que seguir um plano.

O LCC é uma ferramenta para gestão de projetos baseada no canvas e no ciclo de vida do projeto. O LCC é um canvas dinâmico que essencialmente acompanha o projeto em cada uma das suas fases, desde a iniciação até o encerramento. Ele cria um padrão de gerenciamento que possibilita gerenciar todas as fases, processos e áreas de conhecimento sugeridas pelo guia PMBOK de forma simples.

O LCC é aderente ao manifesto ágil pois essencialmente privilegia a interação entre indivíduos, permite focar na essência do projeto, colaborar com o cliente e responde a mudanças de forma fácil. Aspectos de comunicação, integração e gestão da mudança, essenciais aos projetos ágeis, são características essências da ferramenta. Quase que naturalmente o LCC permite a gestão ágil de forma simples, além de permitir, com a documentação gerada, contar toda a história do projeto.

Para explicar como o LCC é aderente a gestão ágil de projetos imaginemos o projeto de um produto que é gerenciado utilizando o método ágil. O seu gerenciamento, mesmo que ágil, deve ser  feito em cinco fases do ciclo de vida ( iniciação (IN), planejamento (PL), execução (EX) e monitoramento e controle (M&C), encerramento (EN)) conforme sugere o LCC.

 O roadmap do produto, uma espécie de panorama visual dos lançamentos (releases) do produto e suas funcionalidades ao longo do tempo. Ele define o backlog do produto que por sua vez é composto pelos requisitos. No LCC o backlog do produto pode ser representado no campo requisitos.

Os requisitos previstos no  backlog podem ser escritos em post-its na forma de user stories (textos simples que descrevem uma funcionalidade). Os requisitos devem orientar as releases (lançamentos ou entregas) do produto.

É necessário então pensar como os requisitos do produto serão atendidos por cada uma das releases. Por sua vez as releases devem ser construídas baseadas em iterações. As iterações são os incrementos do produto em cada uma das releases. Uma iteração envolve as atividades de desenvolvimento que levam ao release de um produto. No LCC as iterações podem ser representadas por versões com ciclos de planejamento e execução específicos. Cada iteração deve atender determinadas funcionalidades e é composta por tarefas. O produto final será formado pelas releases (entregas) baseadas em iterações que por sua vez são baseadas em tarefas. Retrospectivas são registradas como Lições Aprendidas no LCC.

A figura a seguir mostra a release 1 (iteração 1 + iteração 2 + iteração 3) do produto baseada em três iterações. Cada iteração dá origem a uma versão do LCC.

 A figura a seguir mostra a release 2 (iteração 1 + iteração 2) do produto baseada em duas iterações.

O produto, neste caso, é formado pelos duas releases cada uma com seu respectivo LCC aderentes ao LCC do produto. O produto final é  baseado em duas releases cada uma delas baseadas em iterações e documentadas no formato canvas do LCC.

O LCC para o exemplo citado seria utilizado nos três casos (produto – release 1 – release 2). Ele facilita o gerenciamento do projeto agregando o gerenciamento de outras áreas de conhecimento também necessárias nos projetos ágeis para o projeto do produto e de cada uma das releases e traz a interface gráfica para o centro do gerenciamento o que facilita a integração e a comunicação do projeto.

Referência.

Gerenciamento Ágil de Projetos, Vitor L. Massari, Brasport, 2014.

cropped-lifecyclecanvas.jpg