What we’ve learned so far // leçons apprises jusqu’à maintenant

[RachelMuston]

The use of lean methodology throughout the development of this micro-procurement platform means we are constantly learning. With our first procurement opportunity now closed, we want to openly reflect on our learnings so far:

• Provide lots of context. Don't just explain what you want done. Include the 'why' as well so that developers have all the information required to analyze the problem.

• Problem scoping is done collaboratively. Developers ask excellent questions which provide clarity to requirements. As we participated in the discussion the scope became clearer for everyone.

• Set time aside for participating in discussions with developers . These discussion are invaluable and we underestimated the time required for this task.

• Don’t schedule deadlines for a Friday. Having mid-week deadlines for Proposal submission and Acceptance criteria helps make adjustments and address issues.

• Reach out to your network. We didn’t understand the full scope and scale of the problem when we posted it. We had colleagues reach out who are willing to help with project scoping for future GC Developers Exchange opportunities.
  If you’re planning to post an opportunity send us an email and we can put you in touch.

• Remember the 90-9-1 rule when making decisions. Our reach into the developer community was broader than we expected. The developers commenting on the Issues represented only some of the developers following along.

• Don’t underestimate people's desire to solve problems! Don’t hold back posting an opportunity because it seems unsolvable. Stick with it. People are tenacious and will keep thinking about it and trying to find a solution.

• Document a protocol for cancelling an opportunity. The documentation should include:
  When: Only as a last resort. There is very little risk in letting an opportunity run its course. The terms and conditions include the option to select none of the proposals.
  How: Communicate the cancellation in a way that ensures developers are immediately aware.

Have you been watching the evolution of the GC Developers Exchange? If you have any comments, please add them below. We want to hear from you.

Thanks to everyone here for participating in this procurement experiment!

—

L’utilisation de la méthodologie lean (Anglais seulement) tout au long de l’élaboration de cette plateforme de micro-approvisionnement fait en sorte que nous sommes en constant apprentissage. Maintenant que notre première possibilité de travail contractuel est terminée, nous voulons réfléchir de manière ouverte à ce que nous avons appris jusqu’à maintenant :

• Fournir beaucoup d'informations contextuelles. Ne pas simplement expliquer ce que vous voulez faire. Incluez le «pourquoi» afin que les développeurs disposent de toutes les informations nécessaires pour analyser le problème.

• La délimitation de la portée du problème se fait en collaboration. Les développeurs posent d’excellentes questions qui permettent de préciser les exigences. En participant aux discussions, on se fait une meilleure idée du problème.

• Réservez-vous du temps pour participer aux discussions avec les développeurs. Ces discussions sont précieuses, et nous sous-estimons le temps requis pour cette tâche.

• Éviter les échéances qui se terminent le vendredi. Le fait de fixer au milieu de la semaine les échéances pour la présentation de propositions et les critères d’acceptation nous aide à apporter des ajustements et à régler les problèmes.

• Tournez-vous vers votre réseau. Nous n’avons pas complètement saisi la portée ni l’étendue du problème au moment de le publier. Des collègues nous ont dit qu’ils étaient prêts à nous aider à délimiter les prochaines possibilités sur le Carrefour des développeurs du gouvernement du Canada.
  Si vous prévoyez publier une possibilité de travail contractuel, envoyez-nous un courriel et nous pourrons vous mettre en contact.

• N’oubliez pas la règle 90-9-1 (Anglais seulement) au moment de prendre des décisions. Nous avons joint plus de développeurs que ce que nous avions prévu au départ. Seule une partie des développeurs ayant suivi la possibilité ont commenté les problèmes (Anglais seulement).

• Ne sous-estimez pas la volonté des gens à régler les problèmes! Ne vous retenez pas de publier une possibilité parce que le problème semble insurmontable. Allez de l’avant. Les gens sont persévérants et ils continueront à réfléchir au problème et à tenter de trouver une solution.

• Établissez un protocole concernant l’annulation d’une possibilité. Le document devrait inclure ceci :
  Quand : en dernier ressort uniquement. Il y a très peu de risque associé au fait de laisser une possibilité suivre son cours. Les modalités comprennent la possibilité de ne sélectionner aucune proposition.
  Comment : communiquez l’annulation de façon à ce que les développeurs soient immédiatement au courant.

Avez-vous suivi l’évolution du Carrefour des développeurs du gouvernement du Canada? Si vous avez des commentaires, ajoutez-les ci-dessous. Nous voulons connaître votre opinion.

Nous vous remercions d’avoir participé à cette expérience d’approvisionnement!

[lisafast]

This is terrific @RachelMuston. The context, the WHY for the procurement opportunity is so essential.

One additional thought is that a true LEAN process would allow you to change the opportunity as "The problem scoping is done collaboratively". In a sense, the first posting of the opportunity is a specification - what you document here is the inherent problem with specs. They're rarely right the first time, need collaboration, prototyping and iteration to get them to a more accurate description.

So rather than cancelling the opportunity, there needs to be some process to change it, to adapt to the learning, while still honouring the competitive nature of the bidding process. Not easy - maybe there should be a price range that gradually gets narrowed? Or it does get cancelled (quickly!) and reissued?

[RachelMuston]

Thanks @lisafast! Excellent point.
To make this clear for anyone thinking of submitting a proposal, I'm thinking that the refining work could be built into the official devex timelines and described in the 'Background' or 'Acceptance Criteria' sections.

E.g.
Week 1 - opportunity posted
Week 1-end of Week 2 - opportunity is refined collaboratively on GitHub
End of week 2 - announcement that the opportunity is finalized
End of Week 3 - proposals submitted
etc.

(above timeline is illustrative only and would change depending on the opportunity)

Does that make sense? I'm wanting to avoid a situation where someone submits a proposal before the refining work is finished.

[lisafast]

Yes, great idea. This makes it clear that refining IS expected, that input is welcome in that process, and that they should wait before diving into too much scoping work.

[laurawesley]

That makes total sense to me! A benefit we expect from GC Dev Ex is to get better at scoping potential projects. The approach you've landed on allows that wisdom to emerge from both the demand and supply sides. Very cool!