Minha esposa e eu moramos em uma ilha a uma viagem de 30 quilômetros do centro de Seattle por alguns anos ... muito longe dos nossos 20 anos no D D.C.área.Ou seja, não houve muita motivação para eu escrever sobre projetos de TI do governo ... um tópico que estava próximo do meu coração (e da carteira) por várias décadas.Um escritor de temperamento, incluindo muitos artigos para a tecnologia Washington e a FCW, continuei explorando o lado mais suave da vida em perspectivas e livros pessoais.Ao fazer isso, tentei incorporar um ditado familiar: "Você pode se aposentar do trabalho, mas não pode se aposentar da vida.”Ainda assim, um contrário por natureza, decidi explorar o gerenciamento de projetos apenas uma última vez para lançar alguma luz sobre onde os gerentes de projeto (PM) dão errado.
I’m sure most Washington Technology readers are aware that federal as well as state & local government IT projects are too often plagued by cost overruns, schedule delays and technical deficiencies.E embora desenvolvedores de negócios e gerentes de proposta prometendo que o impossível possa ser um culpado, foi minha experiência que um grande fator contribuinte é que o governo e a PMS da indústria continuam cometendo os mesmos erros.E, embora o treinamento formal do Instituto de Gerenciamento de Projetos seja inestimável, uma vez que os PMs são jogados em seu primeiro projeto ou avançando em suas carreiras, a maior parte desse conhecimento cai no caminho à beira do caminho.Além disso, alguns dos fundamentos não se traduzem diretamente na arena do governo.O que parece estar faltando é um compartilhamento institucional da experiência prática ... o "o que fazer e o que não fazer" com base nos sucessos e fracassos do projeto anteriores.Então, eu gostaria de compartilhar apenas algumas dessas lições do meu último livro, The Essential Guide to Managing A Government Project Publicado pelo Government Freelance Exchange (Govflex.com).
Tudo o que ela projeta deve, mas nem sempre, começar com um sólido conjunto de requisitos técnicos e operacionais bem escritos que definem claramente o que o usuário final deseja.Para citar Lily Tomlin: “Eu sempre quis ser alguém, mas agora eu deveria ter sido mais específico."Meu padrão, depois de alguns erros caros nas décadas de 1970 e 80, tornou -se:" Se não pode ser verificado por testes ou inspeção, não é específico o suficiente."Por exemplo," o sistema deve ser fácil de usar "(um requisito de especificação real de uma agência 'eles que não é nomeada'), é inútil.Se a PMS aceitar esse tipo de requisito ambíguo, eles se deixam abertos a argumentos dolorosos com seus colegas do governo sobre aceitação do projeto e responsabilidade financeira.
Você pode se surpreender com quantos PMs eu treinei ainda não leu o contrato inteiro, incluindo os anexos e cláusulas especiais.Fale sobre uma receita para um desastre!E, perguntar a eles sobre o risco associado a diferentes tipos de contrato ou para sua compreensão da terminologia de preços padrão é um esmalte para os olhos garantido.
Uma incapacidade de tomar decisões de som geralmente é outra fonte de falha do projeto.Muitas PMs (e executivos) tomam decisões significativas no corredor sem uma análise e discussão completas com todas as partes interessadas.Eu testemunhei decisões de US $ 100 milhões sendo tomadas dessa maneira.Evite fazer isso!Em vez disso, adote uma abordagem disciplinada de tomada de decisão que identifique fatores de sucesso e taxas alternativas contra esses fatores.Em seguida, comunique a decisão a todos os envolvidos.Embora adiar uma decisão pode ser desmotivadora, dispendiosa e improdutiva, também pode permitir que uma equipe do projeto colete mais informações e considere melhores alternativas.
É difícil exagerar a importância dos relacionamentos para o gerenciamento bem -sucedido de um projeto.A PMS precisa identificar os principais indivíduos que são tomadores de decisão do projeto ou influenciadores.Essas pessoas nem sempre são prontamente aparentes.Por exemplo, muitos projetos de TI são realmente financiados pela unidade operacional de uma agência cuja adesão é necessária tanto durante a fase de requisitos quanto para obter a aceitação da entrega.Não espere até que os testes de aceitação do projeto se envolvam com essas pessoas.
Tendo participado de mais de cem revisões de projetos governamentais de todos os tamanhos e complexidade, infelizmente posso relatar que apenas um punhado evidenciou um grau satisfatório de gerenciamento, relatório e controle de riscos satisfatórios.A maioria das PMs e, infelizmente, sua administração, nem deu um serviço de lábios de risco!E poucos RFPs exigiram.A PMS precisa correr riscos a sério e tentar mitigar os principais riscos em seus projetos antes que eles ocorram, para que tenham menos grandes problemas para lidar durante o ciclo de vida de seus projetos.
Infelizmente, até que o governo e a indústria encontrem maneiras mais inovadoras de preencher essa lacuna de conhecimento, alguns bons projetos, como vinhos finos, inevitavelmente ainda ficarão ruins.Espero que meus esforços possam colocar pelo menos um grande amargo nesta previsão sombria!
Um escritor e músico (geralmente) aposentado e blues, Mike Lisagor é o fundador da Celerity Works e co-fundador da troca freelancer do governo.Seus outros livros incluem como desenvolver uma proposta vencedora do SBIR (com Eric Adolphe), como vencer no mercado do governo (com Mark Amtower - chegando em fevereiro) e crescimento pessoal durante o tempo de Covid..Ele pode ser contatado em Mike@Celerrityworks.com.
