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 do gerenciamento de projetos, como mostra este infográfico do Dia D da Estrelas e listras. E, no entanto, há muitos fracassos na implementação de software empresarial no governo.

Falhas em projetos governamentais

A maioria dos governos exige que os provedores usem as práticas recomendadas de gerenciamento de projetos, de acordo com as Conjunto de conhecimentos em 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 geralmente empregam gerentes de projeto certificados.

Eu achava que tínhamos visto o auge dos fracassos do software empresarial e do ERP do governo do Departamento de Defesa dos EUA, com 4 de 13 projetos custando entre 200% e 1050% dos orçamentos originais. Isso até o "Sistema de pagamento Phoenix" no Governo do CanadáA IBM implementou o Oracle PeopleSoft, uma versão personalizada do Oracle PeopleSoft. Macleans explica o estado atual no vídeo abaixo:

O paradoxo do gerenciamento de projetos

Por que as "práticas recomendadas" 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 corporativo 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 do governo. Assim como especialistas em TI. Os usuários precisam de treinamento especial. (Os usuários do Bridge não precisam de novos treinamentos). O mais importante é que os projetos de GRP transformar e automatizar processos causando uma resistência significativa à mudança.
O que podemos prever dos projetos de software empresarial do governo é que eles são altamente imprevisíveis. Os fornecedores geralmente estão em conformidade com os requisitos documentados do governo, como a IBM fez com o sistema de pagamento Phoenix. Mesmo assim, os sistemas não atendem aos requisitos originais. Isso se deve, de certa forma, ao fato de que o gerenciamento tradicional de projetos no governo se concentra na documentação como um substituto para os requisitos reais. E os contratos, em vez dos requisitos do usuário, são fundamentais.

Padrões de Paradoxo

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

• Ancoragem: As implementações de software geralmente são ancoradas na solução existente. Os usuários querem algo familiar. No entanto, os sistemas existentes geralmente estão repletos de ineficiências e erros. O software geralmente é personalizado para seguir processos antiquados. Os tomadores de decisão do projeto se prendem aos processos "como estão". São criados relatórios desnecessários. A qualidade das informações geralmente não melhora. As personalizações levam a mais erros. É claro que tudo isso é um pouco estranho quando você considera que o objetivo de obter um novo sistema é devido às deficiências do antigo.
• Documentação: Páginas e páginas de documentação detalhada são criadas no gerenciamento de projetos tradicional. Cada estágio requer documentação para ser aprovada pelos tomadores de decisão. Quanto mais documentação, mais difícil é para os tomadores de decisão visualizarem como será o sistema final. Por exemplo, a maioria dos métodos de articulação de especificações é muito difícil de ser compreendida pela maioria das pessoas. Fácil para os engenheiros de software. Isso leva a atrasos. Muitos atrasos.
• Contratos: O resultado desejado pelas empresas de integração de sistemas é a entrega com base nas obrigações contratuais. Os custos excedentes e as alterações no cronograma são aceitáveis, desde que o governo pague. A documentação, os contratos e as alterações contratuais redefinem o sucesso dos objetivos originais do governo para o cumprimento do contrato. É 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 veem a construção de pontes em andamento. O software é uma história diferente. Muitos projetos aguardam a assinatura da documentação completa antes da personalização e da configuração. Isso leva a uma maior resistência à mudança. 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 para mostrar.
• Equipe Bloat: A necessidade de negociadores de contratos, redatores de documentação e explicadores leva a equipes maiores. Isso pode parecer uma coisa boa para aqueles que não leram o Mês do Homem Míticopublicado 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, do ERP em projetos governamentais e das boas práticas ágeis. Nossa metodologia foi atualizada para 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 fracasso.

• Ancoragem: As aspirações se tornam a âncora. Os workshops são realizados após o início do projeto. As equipes de projeto do governo são treinadas no software FreeBalance para mostrar o que poderia ser. Nossos funcionários são especialistas em gestão financeira pública, gestão de serviços públicos, planejamento orçamentário do governo, aquisições etc. Sabemos tudo sobre como as finanças públicas funcionam e devem funcionar. Concentramo-nos em como nosso software pode ser configurado para atender aos problemas que precisam ser resolvidos.
• Documentação: O FreeBalance Accountability Suite é extremamente configurável. Isso significa que podemos fazer alterações nas regras de negócios, no fluxo de trabalho, na linguagem e nos dados rapidamente, sem codificação. É uma abordagem extremamente sem código. Os usuários podem ver se os requisitos foram atendidos. Não há necessidade de grandes quantidades de documentação.
• Contratos: Os contratos são importantes para a FreeBalance. Como uma empresa social, nosso foco é tornar as implementações financeiramente sustentáveis para os governos. Além disso, 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 à mudança começa a se dissipar com a demonstração do progresso na melhoria das configurações do software. Isso não quer dizer que os workshops e as demonstrações eliminem toda a resistência à mudança. A metodologia tem um foco mais profundo no gerenciamento de mudanças do que no gerenciamento genérico de projetos.
• Equipe Bloat: Nossa abordagem mantém o tamanho ideal das equipes. Frequentemente, encontramos profissionais do governo ou de integração de sistemas familiarizados com o tamanho das equipes de ERP ou de projetos desenvolvidos sob medida. A pegada de personalização é muito menor nos projetos FreeBalance.