O Paradoxo do Projeto (Governo)

Posted on março 7, 2018 em Crescimento Econômico e Desenvolvimento

Os governos têm estado na vanguarda da inovação na gestão de projetos, como mostra este infográfico do Dia D de Estrelas e Listras. E, no entanto, há muitas falhas na implementação de software empresarial no governo.

Falhas em projetos governamentais

A maioria dos governos exige que os fornecedores utilizem as melhores práticas de gerenciamento de projetos, consistentes com a Corpo de conhecimento do gerenciamento de projetos (PMBOK) do Instituto de Gerenciamento de Projetos. As empresas de integração de sistemas têm práticas rigorosas de gerenciamento de projetos. Os governos freqüentemente empregam gerentes de projeto certificados.

Pensei que tínhamos visto o zênite das falhas de software empresarial do governo e ERP do Departamento de Defesa dos EUA com 4 dos 13 projetos que custaram entre 200% e 1050% de orçamentos originais. Isso é até o "Sistema de pagamento Phoenix" no Governo do CanadáUma versão personalizada da Oracle PeopleSoft, implementada pela IBM. Macleans explica o estado atual no vídeo abaixo:

O paradoxo da gestão de projetos

Por que as "melhores práticas" de gerenciamento de projetos funcionam em alguns contextos, e não em outros? Por que os gigantes da Internet estão usando metodologias ágeis?
A gestão tradicional de projetos assume que os projetos são complicados, mas previsíveis. A construção de uma ponte, por exemplo, pode ser complicada, exigindo conhecimentos técnicos de engenharia. Os engenheiros entendem a resistência dos materiais, como construir em diferentes condições de solo e lidar com as mudanças de temperatura. O progresso do projeto pode ser previsto com base em projetos similares. É claro que o progresso real é muito fácil de se ver.
As implementações de software empresarial são complexas. Os projetos de Planejamento de Recursos Governamentais (GRP) são transformacionais. São necessários especialistas em finanças, recursos humanos ou aquisições governamentais. Assim como os especialistas em TI. Os usuários precisam de treinamento especial. (Os usuários de ponte não precisam de treinamento novo). Mais importante ainda, os projetos de GRP transformar e automatizar processos causando uma resistência significativa às mudanças.
O que podemos prever a partir de projetos de software empresarial do governo é que eles são altamente imprevisíveis. Os fornecedores são freqüentemente 100% em conformidade com as exigências documentadas do governo, como a IBM tem sido com o sistema de pagamento Phoenix. No entanto, os sistemas não atendem aos requisitos originais. Isso se deve um pouco ao fato de que a gestão tradicional de projetos no governo se concentra na documentação como um substituto para as exigências reais. E os contratos, ao invés de requisitos do usuário, são primordiais.

Padrões Paradoxos

Muitos clientes do governo insistem em seguir processos de cascata altamente estruturados. A FreeBalance, um dos poucos fabricantes de software empresarial que realmente implementam software para clientes, descobriu muitos padrões que levam ao risco:

• Ancoragem: As implementações de software estão muitas vezes ancoradas na solução existente em vigor. Os usuários querem algo familiar. Entretanto, os sistemas existentes estão muitas vezes repletos de ineficiências e erros. O software é muitas vezes personalizado para seguir processos antiquados. Os tomadores de decisão do projeto ancoram-se aos processos "As-Is". Relatórios desnecessários são criados. A qualidade da informação muitas vezes não melhora. As customizações levam a mais erros. É claro, é tudo um pouco estranho quando se considera que o objetivo de obter um novo sistema é devido a deficiências com o antigo.
• Documentação: Páginas e páginas de documentação detalhada são criadas no gerenciamento tradicional de projetos. Cada etapa requer documentação para a assinatura pelos tomadores de decisão. Quanto mais documentação, mais difícil é para os tomadores de decisão visualizarem como será o sistema eventual. Por exemplo, a maioria dos métodos para articular especificações é muito difícil para a maioria das pessoas compreenderem. Fácil para os engenheiros de software. Isto leva a atrasos. Muitos atrasos.
• Contratos: O resultado desejado para as empresas de integração de sistemas é entregar com base em obrigações contratuais. Os custos excedentes e as mudanças de cronograma são multa, desde que o governo pague. Documentação, contratos e emendas contratuais redefinem o sucesso dos objetivos originais do governo para a conformidade contratual. É por isso que as empresas de integração de sistemas são pagas, mesmo quando os usuários estão insatisfeitos.
• Resistência à mudança: As pessoas vêem a construção de pontes em andamento. O software é uma história diferente. Muitos projetos aguardam a assinatura da documentação completa antes da customização e configuração. Isto leva a uma maior resistência a mudanças. Os usuários, os membros da equipe de projeto do governo e os tomadores de decisão ficam desconectados da implementação. A suposição é que o projeto não está indo bem porque não há nada a mostrar para ele.
• Equipe Bloat: A necessidade de negociadores de contratos, redatores de documentação e explicadores, leva a equipes de maior tamanho. Isto pode parecer uma coisa boa para aqueles que ainda não leram o Mês do Homem Mítico, publicado pela primeira vez na década de 1970. Os problemas de coordenação e comunicação tornam-se exponenciais.

Concluímos uma avaliação dos projetos de implementação do FreeBalance, ERP em projetos governamentais e boas práticas ágeis. Nossa metodologia foi atualizada para o A-i³+qM (acelerado, integrado, iterativo, orientado para a implementação, gestão da qualidade):

• Acelerado eliminando tantos processos legados de cascata que levam a problemas no projeto. Isto inclui documentação desnecessária e planos detalhados do projeto, em favor de oficinas e etapas curtas do processo. Os tamanhos das equipes são mantidos pequenos para permitir a comunicação com o cliente e reduzir as despesas gerais de coordenação.
• Integrado através de uma metodologia única para apoiar o desenvolvimento e a implementação de serviços. Isto é integrado às exigências do cliente através dos processos centrados no cliente. Isto proporciona transparência entre o pessoal do cliente, os implementadores e a equipe de desenvolvimento. As equipes de implementação e desenvolvimento de produtos são integradas seguindo as práticas DevOps.
• Iterativo ser responsiva às mudanças do cliente e de implementação utilizando fases. A metodologia alavanca o melhor das metodologias comprovadas de desenvolvimento de software e serviços "lean" com workshops, pequenas iterações, histórias de usuários, marcos miliários e a capacidade de mostrar progresso. Estas técnicas são estendidas além da organização de desenvolvimento para serviços de implementação alavancando ganhos de produtividade e a capacidade de reagir às exigências do cliente.
• Foco na implementação com modelos de boas práticas e processos comprovados de gerenciamento de programas. Esta metodologia está focada no sucesso da implementação do cliente, em vez de um lançamento de software que atinge objetivos internos ou arbitrários. A implementação e o desenvolvimento de produtos são gerenciados através de um Escritório de Gerenciamento de Programas.
• Qualidade assegura que o software seja liberado e suportado atendendo às boas práticas do Commercial Off-the-Shelf (COTS) com testes de unidade, sistema, estresse e regressão. A qualidade é integrada com a implementação onde os testes FreeBalance são baseados nos ambientes do cliente.

A-i³+qM reconhece as deficiências dos processos tradicionais de gerenciamento de projetos nas implementações de GRP. E, os padrões de falha.

• Ancoragem: As aspirações se tornam a âncora. As oficinas são realizadas após o início do projeto. Equipes de projetos governamentais são treinadas no software FreeBalance para mostrar o que poderia ser. Nosso pessoal é especialista em gestão financeira pública, gestão da função pública, planejamento orçamentário do governo, aquisições, etc. Sabemos tudo sobre como as finanças públicas funcionam, e devemos trabalhar. Nos concentramos em como nosso software pode ser configurado para atender a problemas que precisam ser resolvidos.
• Documentação: O FreeBalance Accountability Suite é massivamente configurável. Isto significa que podemos fazer rapidamente as regras comerciais, o fluxo de trabalho, a linguagem e as mudanças de dados sem codificação. É uma abordagem massivamente sem código. Os usuários podem ver se os requisitos são atendidos. Não há necessidade de grandes quantidades de documentação.
• Contratos: Os contratos são importantes para a FreeBalance. Como empresa social, nós nos concentramos em tornar as implementações financeiramente sustentáveis pelos governos. E, temos um incentivo para entregar o que é necessário, o mais rápido possível, para que sejamos pagos o mais rápido possível.
• Resistência à mudança: A resistência a mudanças começa a derreter através da demonstração do progresso na melhoria das configurações de software. Isso não quer dizer que as oficinas e demonstrações eliminam toda a resistência à mudança. A metodologia tem um foco mais profundo no gerenciamento de mudanças que no gerenciamento genérico de projetos.
• Equipe Bloat: Nossa abordagem mantém o tamanho ideal das equipes. Freqüentemente encontramos profissionais do governo ou de integração de sistemas familiarizados com tamanhos de equipes para ERP ou projetos desenvolvidos sob medida. A pegada de personalização é muito menor para projetos FreeBalance.