Créer des leçons

Apprenez à capturer des insights précieux de vos expériences de soumission en utilisant le formulaire structuré de création de leçons de Cothon.

Aperçu

Créer une leçon est la première étape pour bâtir la base de connaissances de votre organisation. Le formulaire de création de leçons vous guide à travers la documentation du contexte, des insights et des éléments d'action de toute expérience de soumission — qu'il s'agisse d'un gain, d'une perte ou d'un apprentissage de processus.

Accéder au formulaire de création

Méthode 1 : Du tableau de bord Leçons

Méthode 2 : D'une analyse de soumission

Quand vous consultez déjà une analyse de soumission complétée :

1. Cliquez sur le menu Actions dans le coin supérieur droit
2. Sélectionnez Créer une leçon
3. Le formulaire se pré-remplit avec le contexte de soumission

Méthode 3 : D'une opportunité

Après avoir décidé de ne pas poursuivre une opportunité :

1. Ouvrez la page de détail de l'opportunité
2. Cliquez sur Enregistrer une leçon de non-soumission
3. Documentez pourquoi vous avez passé l'opportunité

Méthode 4 : Raccourci clavier

Appuyez sur (Mac) ou (Windows) de n'importe où dans Cothon pour ouvrir le formulaire de création de leçons.

Formulaire de création de leçon

Le formulaire consiste en six sections principales :

1. Information de base

Titre de la leçon (Requis)

• Gardez-le concis (50-100 caractères)
• Rendez-le interrogeable — utilisez des mots-clés que votre équipe reconnaîtra
• Incluez le résultat si pertinent

Bons exemples :

• "Gain : Approche technique avec livraison échelonnée a gagné le contrat ISDE"
• "Perte : Calendrier sous-estimé sur appel d'offres intégration soins de santé"
• "Processus : Réunions debout quotidiennes ont réduit révisions de proposition de 40 %"
• "Technique : Stratégie de migration infonuagique pour systèmes patrimoniaux"

Mauvais exemples :

• "Leçon de la semaine dernière" (trop vague)
• "Choses apprises" (pas spécifique)
• "Important" (sans signification)

Catégorie de leçon (Requis)

Choisissez la catégorie principale :

Date de la leçon (Requis)

• Quand cet apprentissage s'est-il produit ?
• Par défaut aujourd'hui mais peut être antidaté
• Utilisé pour l'analyse de tendances et la reconnaissance de motifs temporels

Visibilité (Requis)

Contrôlez qui peut voir cette leçon :

• À l'échelle de l'organisation (défaut) - Tous les membres d'équipe
• Ministère seulement - Limité à un ministère spécifique
• Direction seulement - Cadres et réviseurs désignés
• Privé - Seulement vous et les utilisateurs explicitement partagés

2. Contexte et arrière-plan

Soumission associée (Optionnel mais recommandé)

Liez à l'analyse de soumission ou l'opportunité spécifique :

• Sélectionnez dans la liste déroulante des soumissions récentes
• Remplit automatiquement plusieurs champs à partir des métadonnées de soumission
• Permet le référencement croisé et la détection de motifs

Si aucune soumission n'est liée, fournissez le contexte manuel :

Nom du projet

• Quel était le nom de l'opportunité ou du projet ?
• Utilisez le titre officiel de l'appel d'offres si disponible

Client/Ministère

• Quel ministère ou agence gouvernementale ?
• Sélectionnez de la liste prédéfinie ou ajoutez personnalisé

Valeur du contrat (Optionnel)

• Valeur totale du contrat ou votre montant de soumission
• Aide à l'analyse de motifs par gamme de valeur
• Format : XXX XXX $ (automatiquement formaté)

Type de projet

• Services TI, construction, consultation, équipement, etc.
• Sélectionnez de la liste déroulante ou créez un type personnalisé
• Utilisé pour la correspondance de similarité

Résultat de soumission (Pour les catégories Gain/Perte)

Sélectionnez le résultat :

• Gagné - Vous avez obtenu le contrat
• Perdu - Un autre fournisseur a gagné
• Non-soumission - Décidé de ne pas soumettre
• Annulé - Opportunité annulée par le client
• En attente - Résultat pas encore connu

Votre note (Optionnel)

• Note technique, note totale ou classement
• Aide à analyser les motifs de notation dans le temps

Note du gagnant (Pour les pertes)

• Quelle note le soumissionnaire gagnant a-t-il obtenue ?
• Permet l'analyse d'écart

Information sur les concurrents (Optionnel)

• Qui a gagné (si connu) ?
• Nombre de soumissionnaires
• Insights concurrentiels

3. La leçon

Que s'est-il passé ? (Requis) Décrivez la situation, l'événement ou l'expérience :

• Quel était le contexte ?
• Quelles actions avez-vous prises ?
• Quel a été le résultat ?

Visez 2-3 paragraphes (200-400 mots).

Bon exemple :

"Durant l'appel d'offres migration infonuagique ISDE, nous avons proposé une approche de livraison échelonnée avec trois jalons incrémentaux au lieu du déploiement traditionnel big-bang. Chaque phase incluait des fenêtres UAT dédiées et des capacités de retour arrière. Le panel d'évaluation a spécifiquement mis en évidence ceci comme différenciateur dans le débriefing technique, notant que cela réduisait leur risque perçu. Nous avons obtenu 48/50 sur la section approche d'implémentation comparé à une moyenne de 38/50 pour les autres soumissionnaires."

Mauvais exemple :

"Nous avons bien fait sur l'approche technique."

Pourquoi est-ce arrivé ? (Requis) Analysez la cause profonde :

• Quels facteurs ont contribué au résultat ?
• Y avait-il des raisons sous-jacentes au-delà de l'explication de surface ?
• Quelles hypothèses se sont avérées correctes ou incorrectes ?

Visez 1-2 paragraphes (150-300 mots).

Bon exemple :

"L'approche échelonnée a résonné parce que nous avons passé du temps à comprendre l'expérience passée du client avec des migrations big-bang échouées lors de la session Q&R initiale. Leurs questions ont révélé une aversion au risque concernant les temps d'arrêt et la perte de données. En abordant explicitement ces préoccupations dans notre méthodologie, nous avons démontré une pensée centrée sur le client. De plus, notre GP avait une expérience directe avec une migration échelonnée similaire à un autre ministère, nous donnant crédibilité et exemples spécifiques."

Que devrions-nous faire différemment ? (Requis) Recommandations actionnables pour futures soumissions :

• Changements spécifiques à la stratégie, processus ou approche
• Prochaines étapes concrètes
• Améliorations mesurables

Utilisez des puces pour la clarté. Visez 3-7 éléments actionnables.

Bon exemple :

• Toujours sonder les échecs de projets passés dans les sessions Q&R pour découvrir les préoccupations cachées
• Mener avec l'atténuation de risques dans le sommaire exécutif quand le client a vécu des échecs passés
• Assigner un GP avec expérience de domaine pertinente même si cela signifie retirer d'un autre projet
• Quantifier la réduction de risque - nous aurions dû calculer la réduction de temps d'arrêt (fait dans débriefing, aurait été puissant dans proposition)
• Inclure le plan de retour arrière dans la section méthodologie comme pratique standard pour intégrations complexes

Mauvais exemple :

• Faire une meilleure atténuation de risques
• Assigner des personnes expérimentées

Preuves à l'appui (Optionnel)

Ajoutez de la crédibilité avec :

• Notes de débriefing ou fiches de notation (téléversez comme pièces jointes)
• Extraits de courriels du client
• Intelligence concurrentielle
• Métriques et points de données
• Captures d'écran ou extraits de propositions

4. Étiquetage et classification

Étiquettes (Recommandé)

Ajoutez des mots-clés descriptifs pour une découverte facile :

Types d'étiquettes suggérées :

Ministère/Agence

• ISDE, SPAC, MDN, Santé-Canada, ARC

Type de projet

• services-TI, migration-infonuagique, développement-logiciel, infrastructure, consultation

Domaines techniques

• AWS, Azure, cybersécurité, analytique-données, intégration

Processus/Stratégie

• livraison-échelonnée, agile, prix-fixe, atténuation-risque, structure-équipe

Thèmes

• stratégie-tarification, contraintes-ressources, gestion-calendrier, qualité-proposition

Champs personnalisés (Si configurés)

Votre organisation peut avoir des champs de métadonnées personnalisés :

• Région géographique
• Unité d'affaires
• Niveau de priorité stratégique
• Segment de clientèle

5. Équipe et attribution

Contributeurs (Recommandé)

Étiquetez les membres d'équipe impliqués :

• Gestionnaire de soumission
• Rédacteurs de proposition
• Responsables techniques
• Experts en la matière
• Réviseurs

Avantages :

• Donne crédit aux membres d'équipe
• Permet les recherches "qui sait quoi"
• Identifie les détenteurs de connaissances pour futures questions
• Reconnaît les contributions

Notes de l'auteur (Optionnel)

Ajoutez contexte sur qui a créé la leçon :

• "Documenté par la responsable d'équipe de proposition Sarah Chen basé sur réunion de débriefing avec équipe complète"
• "Créé à partir de la rétrospective post-projet du responsable technique"

6. Éléments d'action

Transformez les insights en prochaines étapes concrètes :

Exemples d'éléments d'action :

En savoir plus : Gestion des éléments d'action

Fonctionnalités du formulaire

Sauvegarde automatique

Le formulaire sauvegarde automatiquement votre progression toutes les 30 secondes :

• Les brouillons de leçons sont sauvegardés sur votre compte
• Reprenez l'édition de n'importe quel appareil
• Indicateur de changements non sauvegardés montre quand le contenu est en attente de sauvegarde

Modèles

Accélérez la création avec des modèles :

Utiliser les modèles :

1. Cliquez sur Charger un modèle au haut du formulaire
2. Sélectionnez parmi les modèles pré-construits (Analyse de gain, Analyse de perte, Amélioration de processus, Apprentissage technique)
3. Remplissez les espaces réservés avec vos détails spécifiques

Créer des modèles :

1. Complétez une leçon qui représente une bonne structure
2. Cliquez sur Sauvegarder comme modèle
3. Nommez le modèle et marquez quels champs devraient être des espaces réservés
4. Le modèle est maintenant disponible pour futures leçons

Modèles par défaut :

Modèle d'analyse de gain

• Structuré pour capturer les différenciateurs concurrentiels
• Inclut des sections pour l'analyse de notation
• Invite pour les stratégies réplicables

Modèle d'analyse de perte

• Cadre d'analyse de cause profonde
• Évaluation de forces concurrentes
• Identification d'écart et remédiation

Modèle d'amélioration de processus

• Comparaison avant/après
• Métriques d'efficacité
• Étapes d'implémentation

Modèle d'apprentissage technique

• Description du défi technique
• Approche de solution
• Leçons pour futures propositions techniques

Éditeur de texte enrichi

Le formulaire de leçon inclut un éditeur complet :

Formatage :

• Gras, italique, souligné
• Titres (H1-H4)
• Listes à puces et numérotées
• Citations bloc
• Blocs de code

Intégration :

• Liens vers ressources externes
• Images (glisser-déposer)
• Tableaux pour comparaison de données
• Encadrés pour notes importantes

Raccourcis clavier :

• - Gras
• - Italique
• - Insérer lien
• - Liste numérotée
• - Liste à puces

Pièces jointes

Téléversez des documents de soutien :

Types de fichiers supportés :

• Documents : PDF, DOCX, XLSX, PPT
• Images : PNG, JPG, GIF
• Archives : ZIP (pour fichiers multiples)

Tailles maximales :

• Fichier individuel : 25 Mo
• Total des pièces jointes par leçon : 100 Mo

Meilleures pratiques :

• Caviardez les informations confidentielles avant téléversement
• Utilisez des noms de fichiers descriptifs
• Compressez les PDF volumineux pour réduire la taille
• Organisez les fichiers connexes dans un dossier ZIP

Validation

Le formulaire valide votre saisie pour assurer la qualité :

Vérifications de champs requis :

• Le titre doit avoir au moins 10 caractères
• La catégorie doit être sélectionnée
• Au moins un parmi : Que s'est-il passé, Pourquoi est-ce arrivé, ou Que devrions-nous faire différemment

Conseils de qualité de données :

• Avertit si le corps de leçon est très court (< 100 mots)
• Suggère d'ajouter des étiquettes si aucune n'est fournie
• Recommande de lier à une soumission si le contexte est vague
• Signale les éléments d'action manquants pour les leçons de catégorie Processus

Prévention d'erreurs :

• Avertissement de titre dupliqué (si leçon similaire existe)
• Détection de date invalide (dates futures, trop loin dans le passé)
• Balayage antivirus des pièces jointes avant téléversement

Options de soumission

Quand vous êtes prêt à sauvegarder :

Sauvegarder comme brouillon

• La leçon est sauvegardée mais pas visible aux autres
• Apparaît dans votre section "Mes brouillons"
• Peut être éditée et publiée plus tard
• Aucune notification envoyée

Quand utiliser :

• Besoin de recueillir plus d'information
• En attente des notes de réunion de débriefing
• Vouloir révision du gestionnaire avant publication

Soumettre pour révision

Si les portes de révision sont activées :

• La leçon est envoyée aux réviseurs désignés
• Vous recevez une notification quand révisée
• Les réviseurs peuvent demander des changements ou approuver
• Publication automatique après approbation (si configuré)

Quand utiliser :

• Votre organisation exige l'approbation de leçons
• Traitement d'information de contrat sensible
• Vouloir validation d'expert avant partage large

En savoir plus : Portes de révision

Publier

• La leçon est immédiatement visible selon vos paramètres de visibilité
• Notifications envoyées aux membres d'équipe pertinents
• Apparaît dans les résultats de recherche et flux
• Contribue aux données d'entraînement IA

Quand utiliser :

• Confiant en la qualité du contenu
• Aucun processus d'approbation requis
• Information urgente à partager

Après soumission

Une fois votre leçon publiée :

Notifications

Les membres d'équipe reçoivent des alertes selon leurs préférences :

• Immédiat - Notification en temps réel quand la leçon est publiée
• Résumé quotidien - Sommaire de nouvelles leçons chaque matin
• Résumé hebdomadaire - Récapitulatif de leçons par catégorie
• Pertinentes seulement - Seulement les leçons correspondant à leurs étiquettes ou ministères

Édition

Vous pouvez éditer les leçons publiées :

• Cliquez sur Éditer sur la page de détail de la leçon
• Les changements créent une nouvelle version avec horodatage
• L'historique d'édition est préservé
• Notifications optionnellement envoyées sur éditions significatives

Versionnage :

• Toutes les éditions sont suivies
• Consultez l'historique de changements sur la page de leçon
• Revenez à la version précédente si nécessaire

Analytique

Suivez l'engagement avec votre leçon :

• Compteur de vues - Combien de personnes l'ont lue
• Endossements - Combien de coéquipiers l'ont trouvée précieuse
• Commentaires - Discussion et insights additionnels
• Citations - Combien de fois elle a été référencée dans les soumissions
• Complétion d'action - Statut des éléments d'action liés

Meilleures pratiques

Structurer pour la recherchabilité

Utilisez des titres spécifiques et riches en mots-clés :

• Incluez le ministère, type de projet ou technologie clé
• Priorisez les mots importants en début (les algorithmes de recherche priorisent les termes précoces)
• Évitez le jargon que seule votre équipe connaît

Bon : "Gain : Méthodologie agile avec réunions debout quotidiennes a sécurisé contrat SPAC" Mauvais : "Comment nous avons gagné le gros"

Soyez spécifique et mesurable

Quantifiez les résultats quand possible :

• "Réduit le temps de préparation de proposition de 6 semaines à 4 semaines"
• "Augmenté la note technique de 12 points comparé à notre moyenne habituelle"
• "Économisé 15 000 $ en réutilisant les sections de proposition modulaires"

Fournissez des exemples concrets :

• Citez les sections spécifiques de l'appel d'offres qui étaient difficiles
• Nommez les outils ou techniques qui ont fonctionné
• Référencez les pages ou sections spécifiques de proposition

Équilibrez positif et négatif

Même dans les gains, identifiez des améliorations :

• Qu'aurait pu être mieux ?
• Qu'est-ce qui a été chanceux qui pourrait ne pas fonctionner la prochaine fois ?
• Qu'avez-vous à peine fini à temps ?

Même dans les pertes, identifiez des succès :

• Quelles parties de la proposition étaient fortes ?
• Quels processus ont bien fonctionné malgré le résultat ?
• Qu'avez-vous appris qui aidera la prochaine fois ?

Liez au contexte

Liez toujours à la soumission associée quand possible :

• Permet la correspondance automatique de motifs
• Fournit le contexte complet aux lecteurs
• Alimente la détection de similarité IA

Téléversez des documents de soutien :

• Notes de débriefing
• Évaluations de notation
• Rétroaction client
• Extraits de proposition pertinents (caviardés au besoin)

Créez des recommandations actionnables

Mauvais : "Nous avons besoin d'une meilleure gestion de projet."

Bon : "Implémenter des réunions debout quotidiennes de 15 minutes durant la semaine de proposition (jours -7 à -1). Assigner un rôle de scrum master pour suivre les bloqueurs. Utiliser un tableau Kanban partagé visible à tous les contributeurs."

Chaque recommandation devrait répondre :

• Quoi exactement devrait être fait ?
• Qui devrait le faire ?
• Quand devrait-ce arriver ?
• Pourquoi cela résoudra-t-il le problème ?
• Comment peut-on mesurer le succès ?

Utilisez les étiquettes stratégiquement

Créez une taxonomie d'étiquetage :

Travaillez avec votre équipe pour établir des étiquettes standard :

• Codes de ministère (abréviations cohérentes)
• Piles technologiques (noms de technologies standard)
• Approches méthodologiques (termes convenus)
• Caractéristiques de soumission (gammes de valeur, niveaux de complexité)

Ne sur-étiquetez pas :

• 5 à 10 étiquettes est idéal
• Plus d'étiquettes ne signifie pas plus trouvable
• Concentrez-vous sur les caractéristiques les plus distinctives

Ne sous-étiquetez pas :

• Minimum 3 étiquettes pour toute leçon
• Incluez au moins une étiquette de chaque catégorie (ministère, type, thème)

Impliquez l'équipe

Capturez les leçons collaborativement :

• Tenez une réunion de débriefing avec tous les contributeurs clés
• Assignez une personne pour documenter, mais recueillez l'input de tous
• Utilisez le tour de table pour assurer que toutes les voix sont entendues

Reconnaissez les contributeurs :

• Étiquetez tous ceux qui ont participé
• Citez les insights spécifiques et attribuez-les
• Remerciez les gens dans les notes de leçon

Gardez-le à jour

Documentez pendant que c'est frais :

• Planifiez le débriefing dans les 48 heures du résultat
• Les souvenirs s'estompent rapidement — les détails importent
• Les émotions fournissent un contexte précieux (de quoi étions-nous inquiets ?)

Mais ne vous précipitez pas :

• C'est acceptable de sauvegarder comme brouillon et ajouter des détails plus tard
• Parfois les insights émergent des jours après l'événement
• Mettez à jour la leçon quand vous en apprenez plus

Pièges courants à éviter

Généralités vagues

Problème : "La communication était mauvaise et a causé des délais."

Mieux : "Les réunions debout quotidiennes ont été annulées durant la semaine finale en raison de priorités concurrentes. Ceci a mené à trois instances où les membres d'équipe ont dupliqué le travail sur la même section, gaspillant environ 12 heures. Reprendre les réunions debout quotidiennes dans la semaine finale, les rendant non-optionnelles."

Culture de blâme

Problème : "Jean n'a pas livré sa section à temps, ce qui nous a fait perdre."

Mieux : "Les livrables de l'expert technique ont été retardés de 3 jours en raison d'exigences peu claires du gestionnaire de soumissions. Implémenter une liste de vérification d'exigences que les experts signent au lancement pour assurer l'alignement sur les attentes et échéances."

Concentrez-vous sur les échecs de processus, pas les échecs personnels.

Aucun apprentissage clair

Problème : Longue description de ce qui s'est passé sans recommandations actionnables.

Mieux : Terminez toujours avec la section "Que devrions-nous faire différemment ?" contenant des actions spécifiques et assignables.

Trop de détails

Problème : Essai de 3000 mots racontant chaque réunion et décision.

Mieux : 400-600 mots couvrant le contexte critique, la cause profonde et les recommandations. Liez aux documents détaillés comme pièces jointes.

Trop peu de détails

Problème : "Nous avons gagné parce que nous avions une bonne approche technique."

Mieux : "Nous avons gagné en proposant un modèle de livraison échelonnée avec fenêtres UAT incrémentales et capacités de retour arrière, ce qui a abordé l'expérience passée du client avec des migrations big-bang échouées. Cela a obtenu 48/50 vs moyenne de 38/50."

Éléments d'action manquants

Problème : Belle analyse mais aucun suivi sur les améliorations.

Mieux : Créez 2-4 éléments d'action concrets avec assignés et échéances. Suivez la complétion.

Ne pas lier aux soumissions

Problème : Leçon autonome sans connexion à la soumission réelle.

Mieux : Liez toujours à l'analyse de soumission ou opportunité associée. Si elle n'existe pas dans Cothon, incluez au minimum le numéro d'appel d'offres et le nom du client pour la traçabilité.

Exemples

Exemple 1 : Leçon de gain

Titre : "Gain : Approche migration infonuagique échelonnée a sécurisé contrat ISDE de 2,4 M$"

Catégorie : Gain

Étiquettes : ISDE, migration-infonuagique, AWS, livraison-échelonnée, atténuation-risque, approche-technique

Que s'est-il passé : Nous avons gagné un contrat de migration infonuagique de 2,4 M$ avec Innovation, Sciences et Développement économique (ISDE) en proposant un modèle de livraison échelonnée avec trois jalons incrémentaux au lieu de l'approche de déploiement big-bang traditionnelle. Notre note technique était de 48/50 comparé à une moyenne de l'industrie de 38/50. Le comité d'évaluation a spécifiquement mis en évidence notre stratégie d'atténuation de risque dans le débriefing.

L'appel d'offres exigeait la migration de 45 applications patrimoniales des centres de données sur site vers AWS. La plupart des soumissionnaires ont proposé un calendrier de 6 mois avec un événement de basculement unique. Nous avons proposé un calendrier de 9 mois avec trois phases :

• Phase 1 (mois 1-3) : Applications à faible risque avec intégration minimale
• Phase 2 (mois 4-6) : Applications de complexité moyenne
• Phase 3 (mois 7-9) : Applications mission-critique avec intégration extensive

Chaque phase incluait des fenêtres UAT dédiées, des procédures de retour arrière et des portes de décision go/no-go.

Pourquoi est-ce arrivé : Durant la session Q&R, les questions de l'agent d'approvisionnement ont révélé qu'ISDE avait vécu une migration big-bang échouée 18 mois auparavant, résultant en 3 jours de temps d'arrêt et des retombées politiques significatives. En sondant ces questions, nous avons identifié l'aversion au risque comme critère d'évaluation caché.

Notre GP avait une expérience directe avec une migration échelonnée similaire à Services publics et Approvisionnement Canada (SPAC), nous donnant des exemples spécifiques et de la crédibilité. Nous avons quantifié la réduction de risque : notre approche limiterait le temps d'arrêt maximum à 4 heures pour toute phase unique versus 72+ heures dans une approche big-bang.

Que devrions-nous faire différemment :

• Toujours sonder les échecs de projets passés dans les sessions Q&R - des questions spécifiques sur "expériences de migration précédentes" peuvent découvrir des préoccupations cachées
• Mener avec l'atténuation de risque dans le sommaire exécutif quand le client a vécu des échecs passés - en faire la première chose que les évaluateurs lisent
• Assigner un GP avec expérience de domaine pertinente même si cela signifie retirer d'un autre projet actif - la crédibilité importe plus que la disponibilité
• Quantifier la réduction de risque - nous avons calculé la réduction de temps d'arrêt dans notre analyse interne mais aurions dû la mettre en évidence dans la Section 3
• Inclure les détails du plan de retour arrière dans la section méthodologie - nous avons mentionné le retour arrière mais n'avons pas fourni les procédures détaillées jusqu'à l'annexe (les évaluateurs peuvent ne pas avoir lu jusque-là)

Éléments d'action :

1. Mettre à jour le modèle de proposition migration infonuagique pour inclure livraison échelonnée comme approche par défaut (assigné au Gestionnaire de propositions, échéance dans 2 semaines, priorité haute)
2. Créer bibliothèque d'atténuation de risques avec 10 scénarios d'échec courants et stratégies d'atténuation quantifiées (assigné à l'Architecte de solutions, échéance dans 1 mois, priorité haute)
3. Planifier session de formation : "Sonder les points douloureux client en Q&R" (assigné au Gestionnaire de soumissions, échéance prochaine réunion d'équipe, priorité moyenne)

Exemple 2 : Leçon de perte

Titre : "Perte : Sous-estimation de complexité d'intégration sur appel d'offres soins de santé"

Catégorie : Perte

Étiquettes : Santé-Canada, intégration-système, estimation-calendrier, approche-technique, tarification

Que s'est-il passé : Nous avons perdu un appel d'offres d'intégration soins de santé de 1,8 M$ à un concurrent qui a soumis 2,2 M$ et un calendrier de 12 mois. Nous avons proposé 1,6 M$ et 8 mois. Le débriefing a révélé que nous avons obtenu 32/50 sur l'approche technique versus 46/50 du gagnant. Les évaluateurs ont noté que notre calendrier était "irréaliste" et notre approche d'intégration "sous-estimait la complexité."

Notre proposition supposait que les systèmes existants du client auraient des API et modèles de données bien documentés. L'EDC mentionnait "systèmes patrimoniaux" mais nous avons interprété ceci comme systèmes des années 2000 (qui ont souvent une documentation décente). En réalité, ils avaient des systèmes mainframe des années 1980 avec documentation minimale et logique d'affaires non documentée.

Pourquoi est-ce arrivé : Nous n'avons pas posé les bonnes questions durant la visite de site. Notre Architecte de solutions a demandé sur "disponibilité de documentation API" mais n'a pas explicitement demandé à voir la documentation ou s'enquérir de l'âge des systèmes. Le client a dit "la documentation existe" ce que nous avons pris au pied de la lettre.

Nous avons aussi tarifé basé sur notre projet d'intégration le plus récent, qui impliquait des microservices modernes. Nous avons appliqué un multiplicateur de complexité de 1,5x pour "systèmes patrimoniaux" mais aurions dû appliquer 2,5-3x basé sur la complexité d'intégration mainframe.

Notre pression de tarification venait d'essayer d'être compétitifs. Nous avons coupé le calendrier à 8 mois (de notre estimation interne initiale de 11 mois) pour correspondre à un calendrier concurrent rumeur. Ceci a rendu notre soumission plus attrayante sur le prix mais a miné notre crédibilité sur l'approche technique.

Que devrions-nous faire différemment :

• Demander à réviser la documentation API réelle durant les visites de site - ne pas prendre "la documentation existe" au pied de la lettre
• Demander explicitement sur l'âge du système et la pile technologique - "patrimonial" peut signifier n'importe quoi de 5 à 40 ans
• Utiliser multiplicateur de complexité 3x pour intégrations mainframe - mettre à jour nos directives d'estimation
• Ne jamais couper le calendrier pour être compétitif si cela mine la crédibilité technique - les évaluateurs voient à travers ceci
• Construire contingence de 20 % dans les projets d'intégration avec inconnues - nous étions trop confiants dans notre estimation
• Proposer phase de découverte pour projets avec inconnues patrimoniales - 2 mois de découverte avant engagement d'implémentation complète

Éléments d'action :

1. Mettre à jour directives d'estimation projet intégration avec multiplicateurs de complexité mainframe (assigné au Responsable d'estimation, échéance dans 1 semaine, priorité haute)
2. Créer liste de vérification visite de site avec questions spécifiques sur âge système, documentation et points d'intégration (assigné à l'Architecte de solutions, échéance dans 2 semaines, priorité haute)
3. Développer modèle de proposition phase de découverte pour projets d'intégration à haute incertitude (assigné au Gestionnaire de propositions, échéance dans 3 semaines, priorité moyenne)
4. Présentation post-mortem à l'équipe complète sur biais d'estimation (assigné au Gestionnaire de soumissions, échéance prochaine réunion d'équipe, priorité moyenne)

Exemple 3 : Leçon de processus

Titre : "Processus : Réunions debout quotidiennes ont réduit révisions de proposition de 40 %"

Catégorie : Processus

Étiquettes : développement-proposition, collaboration-équipe, agile, efficacité

Que s'est-il passé : Sur l'appel d'offres cybersécurité Défense nationale (MDN), nous avons expérimenté avec des réunions debout quotidiennes de 15 minutes durant les 2 dernières semaines de développement de proposition. Ceci a réduit nos cycles de révision d'une moyenne de 5 par proposition à 3, économisant approximativement 32 heures de retravail.

Les propositions précédentes souffraient de désalignement entre sections, contenu dupliqué et messagerie incohérente. Les rédacteurs travaillaient en isolation pendant plusieurs jours, puis découvraient des conflits durant la révision finale. Ceci menait à de la réécriture extensive dans les 48 dernières heures avant soumission.

Avec les réunions debout quotidiennes, chaque membre d'équipe partageait :

• Quelle section ils ont complétée hier
• Quelle section ils travaillent aujourd'hui
• Tout bloqueur ou question

Nous avons utilisé un tableau Kanban partagé pour visualiser le progrès. Le GP agissait comme scrum master, suivant les bloqueurs et facilitant les décisions rapides.

Pourquoi est-ce arrivé : La proposition avait 6 contributeurs travaillant sur différentes sections simultanément. Sans vérifications quotidiennes, les gens faisaient des suppositions sur ce que les autres écrivaient. Par exemple, les deux sections approche technique et gestion de projet décrivaient notre processus de gestion de risque, mais avec des cadres différents. Cette confusion n'a émergé que durant la révision finale.

Les réunions debout quotidiennes ont créé une conscience de ce que chacun faisait. Quand le rédacteur technique a mentionné "décrire notre processus de gestion de risque agile," le rédacteur GP a immédiatement dit "je fais ça dans ma section aussi" et ils se sont alignés en temps réel.

La visualisation tableau Kanban a aidé à identifier les goulots. Quand la section tarification a montré "bloqué" pendant 2 jours, le GP est immédiatement intervenu et a découvert que le responsable d'estimation attendait une clarification que personne n'avait demandée.

Que devrions-nous faire différemment :

• Rendre les réunions debout quotidiennes obligatoires pour toutes propositions > 50 pages - la valeur de coordination l'emporte sur le coût de temps de 15 minutes
• Assigner un rôle de scrum master dédié (habituellement le GP ou gestionnaire de soumissions) pour suivre les bloqueurs et faciliter
• Utiliser un tableau Kanban numérique partagé - nous avons utilisé Trello, mais n'importe quel outil visuel fonctionne
• Commencer les réunions debout au jour -14 (14 jours avant soumission), pas seulement la semaine finale
• Inclure les réviseurs dans les réunions debout pour qu'ils sachent ce qui arrive et puissent fournir rétroaction précoce
• Documenter les décisions prises dans les réunions debout - nous avons perdu la trace de quelques accords verbaux

Éléments d'action :

1. Ajouter "réunions debout quotidiennes" comme étape obligatoire dans le guide de développement de propositions pour propositions > 50 pages (assigné au Gestionnaire de propositions, échéance dans 1 semaine, priorité haute)
2. Créer guide d'animateur réunion debout avec agendas d'exemple et conseils de résolution de bloqueurs (assigné au Gestionnaire de soumissions, échéance dans 2 semaines, priorité moyenne)
3. Acheter licence outil tableau Kanban pour équipe de proposition (assigné au Gestionnaire d'opérations, échéance dans 3 semaines, priorité basse)
4. Former tous les contributeurs de proposition sur techniques de collaboration agile (assigné au Gestionnaire de propositions, échéance dans 1 mois, priorité moyenne)

Foire aux questions

Prochaines étapes

Maintenant que vous savez comment créer des leçons :

• Navigation et filtrage de leçons - Trouvez et apprenez des leçons existantes
• Gérer les éléments d'action - Transformez les insights en suivi concret
• Explorer l'analytique - Découvrez les motifs dans vos leçons
• Configurer les portes de révision - Établissez des flux d'approbation