Os governos têm estado na vanguarda da inovação da gestão de projectos, como mostra esta infografia do Dia D da Estrelas e riscas. E, no entanto, há muitos fracassos na implementação de software empresarial na administração pública.
Fracassos de projectos governamentais
A maioria dos governos exige que os fornecedores utilizem as melhores práticas de gestão de projectos, em conformidade com as Conjunto de conhecimentos em gestão de projectos (PMBOK) do Instituto de Gestão de Projectos. As empresas de integração de sistemas têm práticas rigorosas de gestão de projectos. Os governos empregam frequentemente gestores de projectos certificados.
Pensava que tínhamos visto o zénite dos fracassos do software empresarial e do ERP do governo do Departamento de Defesa dos EUA, com 4 de 13 projectos a custarem entre 200% e 1050% dos orçamentos originais. Isso até o "Sistema de remuneração Phoenix" no Governo do Canadá, uma versão personalizada do Oracle PeopleSoft, implementada pela IBM. Macleans explica a situação actual no vídeo abaixo:
O paradoxo da gestão de projectos
Porque é que as "melhores práticas" de gestão de projectos funcionam nalguns contextos e noutros não? Porque é que os gigantes da Internet estão a utilizar metodologias ágeis?
A gestão tradicional de projectos assume que os projectos 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 compreendem a resistência dos materiais, como construir em diferentes condições de solo, e como lidar com as mudanças de temperatura. O progresso do projecto pode ser previsto com base em projectos semelhantes. É claro que o progresso real é muito fácil de ver.
As implementações de software empresarial são complexas. Os projectos de Planeamento de Recursos Governamentais (GRP) são transformacionais. São necessários peritos em finanças, recursos humanos ou aquisições públicas. Tal como os peritos em TI. Os utilizadores necessitam de formação especial. (Os utilizadores do Bridge não necessitam de nova formação). Mais importante ainda, os projectos GRP transformar e automatizar processos causando uma resistência significativa à mudança.
O que podemos prever dos projectos de software para empresas governamentais é que são altamente imprevisíveis. Os fornecedores estão muitas vezes em conformidade com os requisitos documentados do governo, como a IBM tem feito com o sistema de pagamento Phoenix. No entanto, os sistemas não cumprem os requisitos originais. Isto deve-se, de certa forma, ao facto de a gestão tradicional de projectos na administração pública se centrar na documentação como um substituto dos requisitos reais. E os contratos, mais do que os requisitos do utilizador, são fundamentais.
Padrões de Paradoxo
Muitos clientes governamentais insistem em seguir processos em cascata altamente estruturados. A FreeBalance, um dos poucos fabricantes de software empresarial que efectivamente implementa software para clientes, descobriu muitos padrões que conduzem ao risco:
- Ancoragem: As implementações de software são frequentemente ancoradas na solução existente. Os utilizadores querem algo familiar. No entanto, os sistemas existentes estão muitas vezes repletos de ineficiências e erros. O software é muitas vezes personalizado para seguir processos antiquados. Os decisores do projecto ancoram-se nos processos "como estão". São criados relatórios desnecessários. A qualidade da informação muitas vezes não melhora. As personalizações conduzem a mais erros. É claro que tudo isto é um pouco estranho quando se considera que o objectivo de obter um novo sistema é devido às deficiências do antigo.
- Documentação: Na gestão tradicional de projectos, são criadas páginas e páginas de documentação detalhada. Cada fase requer documentação para ser aprovada pelos decisores. Quanto mais documentação, mais difícil é para os decisores visualizarem o aspecto do sistema final. Por exemplo, a maioria dos métodos para articular especificações são muito difíceis de entender para a maioria das pessoas. 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 é a entrega com base em obrigações contratuais. As derrapagens de custos e as alterações de calendário são aceitáveis, desde que o governo pague. A documentação, os contratos e as alterações contratuais redefinem o sucesso dos objectivos governamentais originais para o cumprimento do contrato. É por isso que as empresas de integração de sistemas são pagas mesmo quando os utilizadores não estão satisfeitos.
- Resistência à mudança: As pessoas vêem a construção de pontes em curso. O software é uma história diferente. Muitos projectos aguardam a assinatura da documentação completa antes da personalização e configuração. Isto leva a uma maior resistência à mudança. Os utilizadores, os membros da equipa de projecto do governo e os decisores ficam desligados da implementação. Parte-se do princípio de que o projecto não está a correr bem porque não há nada para mostrar.
- Equipa Bloat: A necessidade de negociadores de contratos, de redactores de documentação e de explicadores conduz a equipas maiores. Isto 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 de comunicação tornam-se exponenciais.
Concluímos uma avaliação dos projectos de implementação do FreeBalance, dos projectos de ERP na administração pública e das boas práticas ágeis. A nossa metodologia foi actualizada para A-i3+qM (acelerado, integrado, iterativo, orientado para a implementação, gestão da qualidade):
- Acelerado eliminando tantos processos de cascata legados que levam a problemas no projecto. Isto inclui documentação desnecessária e planos de projecto detalhados, a favor de workshops e passos curtos do processo. As dimensões das equipas são mantidas pequenas para permitir as comunicações do 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 com os requisitos do cliente através dos processos centrados no cliente. Isto proporciona transparência entre o pessoal do cliente, os implementadores, e a equipa de desenvolvimento. As equipas de implementação e desenvolvimento de produtos são integradas seguindo as práticas DevOps.
- Iterativo ser responsiva às mudanças dos clientes e de implementação utilizando fases. A metodologia aproveita o melhor do desenvolvimento de software e metodologias de serviços "lean" comprovadas com workshops, pequenas iterações, histórias de utilizadores, marcos miliários e a capacidade de mostrar progressos. Estas técnicas são alargadas para além da organização de desenvolvimento para serviços de implementação, alavancando ganhos de produtividade e capacidade de reagir às exigências do cliente.
- Foco na implementação com modelos de boas práticas e processos comprovados de gestão de programas. Esta metodologia está centrada no sucesso da implementação do cliente, em vez de um lançamento de software que atinge objectivos internos ou arbitrários. A implementação e o desenvolvimento de produtos são geridos através de um Gabinete de Gestão de Programas.
- Qualidade assegura que o software é lançado e apoiado em reuniões de boas práticas de Commercial Off-the-Shelf (COTS) com testes de unidade, sistema, stress e regressão. A qualidade é integrada com a implementação onde os testes FreeBalance são baseados nos ambientes do cliente.
A-i3+qM reconhece as deficiências dos processos tradicionais de gestão de projectos nas implementações de GRP. E os padrões de fracasso.
- Ancoragem: As aspirações tornam-se a âncora. São realizados workshops após o início do projecto. As equipas de projecto governamentais recebem formação sobre o software FreeBalance para mostrar o que poderia ser. Os nossos colaboradores são especialistas em gestão das finanças públicas, gestão da função pública, planeamento orçamental, contratos públicos, etc. Sabemos tudo sobre como funcionam e devem funcionar as finanças públicas. Concentramo-nos na forma como o nosso software pode ser configurado para responder aos problemas que precisam de ser resolvidos.
- Documentação: O FreeBalance Accountability Suite é extremamente configurável. Isto significa que podemos alterar rapidamente as regras comerciais, o fluxo de trabalho, a linguagem e os dados sem codificação. É uma abordagem massivamente sem código. Os utilizadores podem ver se os requisitos são satisfeitos. Não há necessidade de grandes quantidades de documentação.
- Contratos: Os contratos são importantes para a FreeBalance. Como empresa social, concentramo-nos em tornar as implementações financeiramente sustentáveis para os 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 à mudança começa a derreter-se através da demonstração de progressos na melhoria das configurações de software. Isto não quer dizer que os workshops e as demonstrações eliminem toda a resistência à mudança. A metodologia tem um enfoque mais profundo na gestão da mudança do que na gestão genérica de projectos.
- Equipa Bloat: A nossa abordagem mantém a dimensão ideal das equipas. Encontramos frequentemente profissionais do governo ou de integração de sistemas familiarizados com o tamanho das equipas de ERP ou de projectos desenvolvidos à medida. A pegada de personalização é muito menor para os projectos FreeBalance.