Ma femme et moi vivons sur une île à une balade en ferry de 30 milles du centre-ville de Seattle pendant plusieurs années… loin de nos 20 années dans le D.C.Région.Ce qui veut dire qu'il n'y a pas eu beaucoup de motivation pour moi d'écrire sur les projets informatiques du gouvernement… un sujet qui me tient à cœur (et portefeuille) depuis plusieurs décennies.Écrivain de tempérament, dont de nombreux articles pour la technologie de Washington et la FCW, j'ai continué à explorer le côté plus doux de la vie dans les perspectives et les livres personnels.Ce faisant, j'ai essayé d'incarner un dicton familier: «Vous pouvez prendre votre retraite du travail, mais vous ne pouvez pas vous retirer de la vie.«Pourtant, un contre-nature par nature, j'ai décidé d'explorer la gestion de projet une dernière fois pour éclairer où les chefs de projet (PM) se trompent.
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.Et bien que les développeurs d'entreprises et les gestionnaires de propositions promettant que l'impossible puisse être un coupable, j'ai été mon expérience qu'un facteur contribuant majeur est que le gouvernement et le PMS de l'industrie continuent de commettre les mêmes erreurs.Et, bien que la formation officielle de l'institut de gestion de projet soit inestimable, une fois que les PM sont jetés dans leur premier projet ou avance dans leur carrière, la plupart de ces connaissances tombent au bord du chemin.De plus, certains des fondamentaux ne se traduisent pas directement dans l'arène du gouvernement.Ce qui semble manquer, c'est un partage institutionnel de l'expérience pratique… «que faire et quoi ne pas faire» en fonction des succès et des échecs du projet précédent.Donc, je voudrais partager quelques-unes de ces leçons de mon dernier livre, The Essential Guide to Georing un projet gouvernemental publié par le gouvernement Freelance Exchange (Govflex.com).
Tous les projets informatiques devraient, mais ne commencez pas toujours par un ensemble solide d'exigences techniques et opérationnelles bien écrites qui définissent clairement ce que veut l'utilisateur final.Pour citer Lily Tomlin, «J'ai toujours voulu être quelqu'un que je vois maintenant j'aurais dû être plus précis."Ma norme, après quelques erreurs coûteuses dans les années 1970 et 80, est devenue:" S'il ne peut pas être vérifié par test ou inspection, alors il n'est pas suffisamment spécifique."Par exemple," le système doit être convivial ", (une exigence de spécification réelle d'une agence« Ils-qui-ne pas être nommé ») est inutile.Si le PMS accepte ce type d'exigence ambiguë, ils se laissent ouverts à des arguments douloureux avec leurs homologues du gouvernement sur l'acceptation du projet et la responsabilité financière.
Vous pourriez être surpris du nombre de PM que j'ai entraînés n'ont pas réellement lu leur contrat, y compris les pièces jointes et les clauses spéciales.Parlez d'une recette pour une catastrophe!Et, leur poser des questions sur le risque associé à différents types de contrats ou pour leur compréhension de la terminologie des prix standard est un glaçage oculaire garanti.
Une incapacité à prendre de bonnes décisions est souvent une autre source d'échec du projet.Trop de PM (et de dirigeants) prennent des décisions importantes dans le couloir sans analyse et discussion approfondies avec toutes les parties intéressées.J'ai vu 100 millions de dollars de décisions prises de cette façon.Évitez de le faire!Au lieu de cela, adoptez une approche de prise de décision disciplinée qui identifie les facteurs de réussite et évalue les alternatives contre ces facteurs.Puis communiquez la décision à toutes les personnes impliquées.Bien que le retard d'une décision puisse être démotivant, coûteux et improductif, il peut également permettre à une équipe de projet de recueillir plus d'informations et d'envisager de meilleures alternatives.
Il est difficile de surestimer l'importance des relations avec la gestion réussie d'un projet.Le PMS doit identifier les personnes clés qui sont des décideurs ou des influenceurs de projet.Ces gens ne sont pas toujours évidents.Par exemple, de nombreux projets informatiques sont en fait financés par l'unité opérationnelle d'une agence dont l'adhésion est nécessaire à la fois pendant la phase des exigences et pour obtenir l'acceptation de la livraison.N'attendez pas les tests d'acceptation du projet pour s'engager avec ces gens.
Ayant participé à plus d'une centaine d'examens de projets gouvernementaux de toutes tailles et complexité, je peux malheureusement signaler que seule une poignée a mis en évidence un degré satisfaisant de gestion des risques, de rapports et de contrôle.La plupart des PM et, malheureusement, leur gestion, n’ont même pas donné un service à lèvres à risque!Et trop peu de RFP l'exigent.Le PMS doit prendre le risque à cœur et essayer d'atténuer les principaux risques de leurs projets avant qu'ils ne se produisent, ils ont donc moins de problèmes majeurs à gérer pendant le cycle de vie de leurs projets.
Malheureusement, jusqu'à ce que le gouvernement et l'industrie trouvent des moyens plus innovants de combler ce fossé de connaissances PM, certains bons projets, comme les vins fins, iront inévitablement encore.J'espère que mes efforts pourront mettre au moins une brèche très mineure dans cette sombre prévision!
Écrivain (généralement) à la retraite et musicien de blues, Mike Lisagor est le fondateur de Celerity Works et co-fondateur de Government Freelance Exchange.Ses autres livres incluent Comment développer une proposition SBIR gagnante (avec Eric Adolphe), comment gagner sur le marché du gouvernement (avec Mark Amtower - à venir en février) et une croissance personnelle pendant la période de Covid.Il peut être joint à Mike @ Celerityworks.com.
