Menu
Esqueceu a senha? Fazer cadastro

Skunk Works – Projetos de Desenvolvimento Avançados

Amigos leitores, enquanto termino de preparar nosso videocast prometido sobre o Guia PMBOK 5ª edição, gostaria de compartilhar com vocês as 14 Regras e Práticas de Kelly Johnson para o gerenciamento de projetos de desenvolvimento avançados (Skunk Works).

220px-Kelly-Johnson_Electra

Johnson foi um lendário engenheiro que esteve à frente de grandes projetos de desenvolvimento da Lockheed e, certamente, foi um homem à frente de seu tempo. Muitas das suas sugestões nos remetem ao que hoje temos em gerenciamento ágil de projetos, abordagens lean e até mesmo aos princípios do PRINCE2 e melhroes práticas do Guia PMBOK. A seguir, fiz uma tradução livre e inseri alguns comentários em itálico.

1. O gerenciamento e controle deve ser delegado completamente ao gerente do projeto ou programa. Ele deve reportar a um presidente de divisão ou superior.

Johnson refoça a importância da autoridade do gerente do projeto ou programa, incluindo a necessidade de haver apoio da gerência sênior e um patrocinador dedicado ao projeto. Trata-se de um fator crítico de sucesso que é neglicendiado por muitas organizações até hoje.

2. Escritórios de projeto capacitados e eficientes, mas de pequeno porte, devem ser criados tanto pelos militares e quanto pela indústria.

Outra proposta de Johnson é a criação de Project Support Offices ou Escritório de Suporte de Projetos para apoiar esses projetos de desenvolvimento avançados. Obviamente, são mega-projetos e programas, necessitando de apoio administrativo, além de capacidade de planejamento e controle. PMOs dedicados oferecem ganhos enormes nestes casos. É interessante observar que ele propôs Escritórios de Projetos tanto do lado cliente (militares / Governo) quanto do lado fornecedores (indústria), favorecendo a coordenação, integração e o próprio gerenciamento de stakeholders

3. O número de pessoas que têm alguma ligação com o projeto deve ser restringido ao máximo. Usar um pequeno número de boas pessoas é melhor do que muitas pessoas.

Uma preocupação de Johnson era utilizar um número reduzido de pessoas extremamente qualificadas. Quanto maior a equipe e demais envolvidos, maiores serão os desafios de comunicação, coordenação e integração. É melhor uma equipe pequena de alta performance do que uma grande equipe muito heterogenea.

4. Inicialmente, devem ser utilizados desenhos simples. E um sistema de controle de documentação do projeto com grande flexibilidade para fazer mudanças deve ser disponibilizado.

Desenvolvimento incremental, agilidade, prototipagem rápida e outras abordagens propostas por Johnson são muito atuais. A preocupação é em aprender sobre o projeto e sobre o produto nas fases iniciais, utilizando desenhos simples e um sistema flexível de controle de mudanças. Posteriormente, trilhando o caminho da engenharia de sistemas, o escopo do produto e suas especificações vão se tornando claras e precisas. (Veja Processos de Engenharia de Sistemas no Blog)300px-SR71_factoryfloor_SkunkWorks

5. Tem de haver um número mínimo de relatórios exigidos, porém todo trabalho   importante  deve ser    registrado e reportado adequadamente.

Não devemos burocratizar o projeto, sob pena de perder os benefícios de agilidade e   desenvolvimento    incremental, ainda mais em se tratando de projetos de desenvolvimento   avançado. Todavia, também não    podemos trabalhar no caos da informalidade e   descontrole. Essa regra número 5 está bastante relacionado  com o princípio   “Gerenciamento por Exceção” do PRINCE2. Esse princípio, aliado ao “Foco no Produto” e   “Gerenciamento por Estágios”, parece permear as 14 Regras e Práticas do Skunk Works.

6. Deve haver uma revisão mensal dos custos, incluindo não apenas o que foi gasto mas   também as projeções de custos para a conclusão do programa.

Não apenas os custos passados devem ser analisados, mas também as projeções. Além disso, a justificativa do projeto, seus benefícios e valor de negócio devem ser revisados periodicamente no Business Case e / ou outros documentos.

7. O empreiteiro deve ter autoridade e responsabilidade para subcontratar partes do projeto e fornecedores. Procedimentos de licitação comerciais são muitas vezes melhor do que os governamentais.

Johnson chama a atenção para a dificuldade nas aquisições governamentais e sugere que os empreiteiros ou grandes contratados tenham a autoridade para realizar aquisições e subcontratações de fornecedores menores. Aquisições, em geral, é um grande problema nesse tipo de projeto. Isso ocorre por vários motivos, dentre eles a dificuldade de especificar componentes em projetos de desenvolvimento e a dificuldade em selecionar bons fornecedores. A forma dos contratos também é bastante impactante (fixed cost, time & material, cost plus fee…)

8. O sistema de inspeção atualmente utilizado por Skunk Works foi aprovado tanto pela Força Aérea e da Marinha para atender aos requisitos de novos projetos. Deve-se atribuir responsabilidade pela inspeção mais básica aos subempreiteiros e fornecedores de modo a não duplicar os esforços de inspeção.

Projetos de desenvolvimento militares, especialmente envolvendo setores aeronáutico e espaciais, possuem normas e requisitos de qualidade bastante elevados. É importante estabelecer processos e procedimentos adequados de garantia e de controle da qualidade permeando todos os envolvidos no projeto. Assim, evita-se não apenas o retrabalho, mas também defeitos e falhas.

9. O contratante deve ser delegada a autoridade para testar o seu produto final em vôo. Ele pode e deve testá-lo em estágios iniciais. Se ele não faz, ele rapidamente perde a sua competência para projetar outros veículos.

Uma outra preocupação de Johnson era quanto ao domínio do produto. Embora fossem projetos de desenvolvimento contratados pelos militares e desenvolvidos em parceria, a visão de Johnson era não apenas na entrega no produto mas principalmente no valor estratégico do desenvolvimento de competências através dos projetos.

10. As especificações aplicáveis ao hardware deve ser acordada com antecedência de contratação.

Sobre a importância do escopo, requisitos e especificações, já comentamos em outros posts: Escopo e Críticas ao Escopo.

11. O financiamento de um programa deve ser oportuno para que o empreiteiro não necessita de apoio de bancos para apoiar projetos do Governo.

Os projetos da Lockheed tinham, entre outros, objetivos comerciais e de negócio. O financiamento desses projetos era essencial para garantir sua viabilidade. Em praticamente todos os projetos que enfrentamos hoje, o fluxo de recursos deve merece r especial atenção.

12. Deve haver confiança mútua entre a organização do projeto militar e do contratante, cooperação estreita e cotidiana.

Isso reduz mal-entendidos e aumenta a agilidade na comunicação, gestão de mudanças e de stakeholders. Não existe contrato que possa nos proteger completamente de uma contraparte desonesta.

13. Acesso por pessoas de fora para o projeto e seu pessoal deve ser rigorosamente controlado por medidas de segurança adequadas.

O sigilo deve ser um aspecto importante nos projetos de desenvolvimento avançado. Essa   recomendação pode ser feita a diversos outros empreendimentos, visto que o tratamento   das informações e documentação deve ser feito com cuidado.

14. Devem ser criadas novas manerias para recompensar o bom desempenho dos   envolvidos no projeto.

A preocupação com a motivação da equipe era um dos pilares do gerenciamento de   projetos de desenvolvimento avançado, na visão de Johnson. Afinal, o projeto é feito de   pessoas. São seus esforços que levam ao sucesso do projeto.

Capa+do+Livro+Desafios+do+Programa+Espacial+Brasileiro+-+2011

 

Enquanto aguardam o videocast sobre o Guia PMBOK 5ª edição, aproveitem para dar uma olhada nas 100 Regras para Gerentes de Projetos da NASA. E também pode fazer o download do .pdf sobre os Desafios do Programa Espacial Brasileiro neste link. Boa leitura e até a próxima!

Por que os projetos se tornam problemáticos?

É uma pergunta retórica. Existe uma infinidade de fatores, contingências e peculiaridades de cada projeto e seu contexto.

Projetos são desafios por natureza. Basta não fazer nada para que eles fracassem em meio a incertezas, riscos, stakeholders etc. Para que eles tenham sucesso, aí sim é necessário bastante esforço, organização e planejamento.

Nos posts anteriores, comentamos sobre os sintomas de projetos problemáticos e discutimos um pouco sobre os aspectos a serem abordados para sua recuperação. Conforme prometido, neste post conversaremos sobre algumas experiências em projetos desse tipo.

Vale mencionar que não sou um profissional em recuperar projetos. Especialistas como Ricardo Vargas (@rvvargas) e Farhad Abdollahyan (@farhadak) fazem isso. Eu gerencio projetos que eventualmente podem entrar em crise… Por esse motivo, busquei me aprofundar um pouco nessa área. Imagino que muitos leitores estejam na mesma situação que eu.

Há alguns anos, gerenciei um projeto de desenvolvimento de software, uma área afastada das minhas hard skills. Como engenheiro eletrônico, senti dificuldade nas questões técnicas do projeto, o que me causou alguns transtornos. Além disso, já era um projeto problemático. Eu fui o terceiro GP, era esperado que eu o recuperasse. Fizemos basicamente o que propõe Ricardo Vargas nesta apresentação, embora inconscientemente. Foi necessário reavaliar o projeto, decidimos que ele continuava sendo necessário (valor e benefícios) mas que seria necessário rever sua tripla restrição de escopo-tempo-custo. O tempo era a única variável restritiva, havia uma data limite. Escopo e custo foram bastante alterados para permitir a recuperação do projeto.

Essa experiência pessoal fez com que eu buscasse desenvolver mais as minhas competências em gerenciamentos de projetos e mudou a minha opinião em relação à velha discussão entre GP Especialista versus GP Generalista. Hoje, acredito que não é possível gerenciar qualquer tipo de projeto. Algum conhecimento técnico sobre o produto e sua indústria é essencial. Para mim, um dos motivos de termos tantos projetos problemáticos por aí é exatamente a falta de capacitação técnica (hard skills) de alguns gerentes. Existe a percepção de que conhecimentos de administração, gestão de projetos, soft skills, comunicação e liderança levam ao sucesso qualquer projeto. Eu discordo.

Neste sentido, obtivemos bastante feedback dos leitores nos dois últimos posts. Alguns disseram que o maior problema é a comunicação. Eu diria que concordo, em partes. É fato que a comunicação e o gerenciamento de stakeholders é bastante negligenciado e mal feito na grande maioria dos projetos. Entretanto, eu elencaria os fatores que levam ao fracasso de um projeto como na figura a seguir.

123

Figura 1 – Fatores críticos de sucesso (ou fracasso)

Não pretendemos esgotar o assunto. A figura é apenas um ponto de partida. A minha experiência mostra que um dos grandes motivos de fracasso nos projetos, se não o maior, é a falta de clareza, formalidade e controle de mudanças. É impressionante como somos enganados pela viabilidade. Desenvolver um plano de projeto observando a recomendação SMART é uma prática bastante negligenciada.

Além disso, frequentemente, os projetos não estão diretamente associados a benefícios e valor. Também não existe clareza no seu alinhamento estratégico. Esses são fatores essenciais para o sucesso de um projeto. Finalmente, há que se observar o gerenciamento de riscos, que também não costuma ser adequadamente realizado.

Stakeholders, comunicação e disponibilidade de recursos adequados completam nossos fatores críticos que contribuem sobremaneira para o sucesso ou fracasso dos projetos.

Pensando em projetos problemáticos, é engraçado verificar que, embora já sejam vistos como problemáticos há muito tempo (às vezes desde o seu início), o diagnóstico é demorado ou tardio. Para mim, isso tem dois motivos. O primeiro motivo é que ninguém quer apontar um projeto problemático. O segundo motivo, talvez o principal, é que o monitoramento e controle dos projetos é extremamente inadequado na maioria das organizações. Tanto a estrutura de comunicação quanto o conteúdo e os próprios reports são ruins.

Meu contato com a metodologia PRINCE2 trouxe novos insights para resolver algumas dessas questões levantadas acima. Por isso, conversaremos sobre PRINCE2 em outros posts futuramente, apresentando sua estrutura e funcionamento.

Na próxima semana, discutiremos sobre planejamento estratégico pessoal. Não percam!

Recuperando Projetos Problemáticos

A primeira pergunta, na verdade, seria: “Queremos realmente recuperar esse projeto?”.

No post anterior, vimos alguns sinais que podem caracterizar um projeto problemático. Neste post, incluímos novas referências e fontes de pesquisa sobre o assunto, buscando aprofundar a identificação e a recuperação de projetos problemáticos, bem como oferecer dicas de prevenção para o post seguinte.

Todo projeto é um desafio. São empreendimentos temporários sujeitos a grandes variações devido a fatores internos e externos, tais como:

  • Requisitos incompletos
  • Escopo mal definido
  • Expectativas não realistas
  • Conflito entre stakeholders
  • Condições de mercado
  • Capacidade técnica
  • Disponibilidade de recursos

O contexto de complexidade, incerteza e velocidade que permeia os projetos faz com que gerenciar um projeto seja sempre um desafio. Na figura a seguir, observamos que é natural haver algum desvio entre os objetivos traçados originalmente (challenged). Entretanto, quando esses desvios são maiores que as tolerâncias estabelecidas nos planos, termo de abertura ou business case, o projeto passa a ser problemático (troubled).

Figura 1 – Variância entre objetivos nos projetos (ESI, 2007)

O monitoramento e controle do projeto, não apenas nos seus aspectos técnicos (escopo-tempo-custo, valor agregado etc) mas também sob a ótica de negócios (valor, benefícios) e de stakeholders (satisfação, expectativas) é essencial. A identificação precoce de um projeto problemático permite sua recuperação com maior índice de sucesso. À medida que o projeto se torna crítico e fracassado, ele entra na zona de terminação. Isto é, é mais saudável finalizar o projeto, pois o custo-benefício de recuperá-lo não vale a pena.

Neste post, nossa atenção é para a zona de identificação (asssessment & recovery). A seguir, temos uma figura com alguns indicadores de que o projeto está se tornando problemático.

Figura 2 – Indicators of troubled projects (VARGAS, 2007)

Recuperar um projeto não significa necessariamente conseguir trazê-lo para seu plano original, muitas vezes isso não é possível. Precisamos compreender que a recuperação de projetos está preocupada em salvar o que restou de benefícios / valor no projeto, dada sua situação atual. Muitas vezes, o plano de recuperação necessita de cortes ou ampliações na tripla restrição inicial (escopo-tempo-custo).

Figura 3 – Rapid assessment and recovery process (ESI, 2007)

O processo de avaliação e recuperação de projetos problemáticos proposto pela ESI (2005, 2007) envolve duas fases, que devem ser planejadas adequadamente. O primeiro passo, na fase de avaliação é Definir Charter (Termo de Abertura):

  • Definir objetivos juntamente com o patrocinador e outros stakeholders-chave, se houver
  • Analisar e compreender o histórico do projeto
  • Mobilizar a equipe de avaliação (assessment)
  • Definir a abordagem de avaliação

Posteriormente, é feita a avaliação da situação atual do projeto, com base no plano de assessment e abordagem escolhida, para que seja possível propor um plano de recuperação ou então propor o encerramento do projeto, como resumido na figura seguinte.

Figura 4 – Troubled project assessment model (ESI, 2005 apud VARGAS, 2007)

Antes de propor o plano de recuperação, é preciso tomar uma decisão GO-NO GO. Será que é interessante recuperar o projeto problemático? Devemos sempre lembrar que não se trata de diversão nem de honra. Trata-se de negócios, valor e benefícios. Algumas questões:

  • Quão importante é o projeto?
  • Quais são os benefícios prometidos pelo projeto? Quais as chances de entrega desses benefícios?
  • É possível prosseguir com pequenas mudanças ou devemos redefinir todos os objetivos e planos do projeto?
  • Quais são os impactos do projeto em outras áreas organizacionais ou outros projetos? Quais suas interfaces e dependências?
  • Qual é o montante de recursos necessários para recuperar o projeto? O custo-benefício da recuperação se justifica?
  • Os stakeholders apóiam a recuperação do projeto?
  • O gerente e a equipe estão motivados para recuperá-lo?
  • Existe um patrocinador com autoridade e vontade para recuperar o projeto?
  • O contexto do projeto, condições de negócio e mercado são favoráveis à recuperação?
  • Existe algum obstáculo instransponível para a recuperação?

Após responder essas e outras perguntas, com base nos resultados do assessment, se a decisão for favorável à recuperação do projeto, é preciso planejar sua recuperação. O plano de recuperação pode ser desde uma simples redefinição / remodelagem do plano inicial, ajustando escopo-tempo-custo, por exemplo, ou pode envolver novos estudos de viabilidade e um plano de projeto bastante diferente do original.

Figura 5 – Conducting the recovery process (ESI, 2007)

Em se tratanto de um projeto problemático, sua recuperação merece grande atenção e controles. O gerente do projeto e o patrocinador, particularmente, precisam ser proativos na solução de problemas e na resolução de conflitos. Estabelecer responsabilidades de maneira clara e objetiva é essencial. Além disso, deve existir um sólido plano de comunicação para garantir o apoio dos stakeholders principais à recuperação do projeto. Agilidade nas decisões também é um fator preponderante para o sucesso.

Finalmente, eu diria que podemos caracterizar a recuperação de projetos como um wicked-mess problem (HANCOCK, 2010). Isto é, trata-se de um problema dinâmico e divergente. Dinâmico porque os fatores comportamentais dos stakeholders demandam alto nível de habilidades em relacionamento, facilitação e negociação. Divergente porque a complexidade técnica é alta, exigindo grande habilidade em pensamento conceitual e sistêmico.

Neste tipo de problema (wicked-mess), quanto mais estudamos o problema, maior o número de soluções que encontramos. Ou seja, não há convergência nem linearidade devido às incertezas e complexidades. Por isso, é preciso ter foco nos key success factor, definir e delimitar muito bem os objetivos da recuperação e nos atermos a eles. Por outro lado, devemos ter grande cuidado no gerenciamento dos stakeholders, cujo apoio e suporte é um fator extremamente crítico para o sucesso da recuperação.

No próximo post, relataremos um pouco da nossa experiência pessoal em participar de projetos problemáticos e em trabalhar na sua recuperação. Na próxima semana, retomaremos o assunto, incluindo dicas de prevenção que podem diminuir as chances do seu projeto se tornar problemático. Até lá!