Comment gérez vous vos projets ?

1

Bonjour,

Après avoir lu plusieurs fils ici, je m’interroge sur la façon dont vous gérez vos projets (sans forcément entrer dans les détails) et si vous le faites de manière structurée et organisée (bien au delà de ce qu’impose des outils comme trello ou basecamp… qui ne sont finalement que des gestionnaires de tâches).
D’avance merci

PS: pour ma part, et suivant les contextes, j’utilise les approches prédictives/agiles de manière complémentaire (suivant la norme iso21500 avec de l’agile quand le Rolling Waves ne s’adapte pas) et je commence depuis 2/3 ans l’approche systémique pour les projets complexes (sur les parties risques et parties prenantes)

Pour de petits/moyens projets (<100ke) j’ai ma popote qui est une version simplifiée de iso/scrum.
Quant aux outils, je suis presque 100% management visuel (je tends à supprimer les logiciels): mindmapping, scrumboard, cartes conceptuelles, post-it, tableau venilia

2

Je fonctionne en Design sprint, qui mélange Design thinking et méthodes lean et agiles.
Pour le suivis et travail à distance, j’ai pas mal d’outils également > http://liut.design/workflow-designer/

Si tu veux en discuter plus en détail, n’hésites pas !

3

Merci pour te réponse, j’ai cependant quelques questions pour mieux comprendre:
Le Design sprint concerne l’émergence du besoin et le choix de solution.

Une fois que la maquette (souvent du ppt) est validée, il faut produire, mobiliser ressources financières et humaines, gérer les problèmes, contraintes et demandes de Modifs en cour de route il faut communiquer l’état d’avancement, se projeter a terminaison, etc etc.

Le design sprint n’encadre pas la partie delivery (entre autres)… par quelles méthodes passes tu?

4

Le Design Sprint peut également être intégré au milieu de sprints agiles, de manière à recentrer les priorités, recadrer ou pousser des phases de tests intermédiaires.

Un DS initial permet de remplacer un cahier des charges, de définir un planning agile précis, ensuite le déroulé se faire basé sur tout ce travail initial bien testé et construit avec un groupe, des conditions idéales !

Concernant les ressources humaines, elles sont réfléchis pendant le DS, ainsi que la dimensions financière. Pour ce qui est des problèmes, de l’humain, la communication prime et une dimension d’agilité est conseillée.

Pour les demandes de modifications, si elles arrivent durant un sprint agile alors que tout a été préparé en DS au départ, c’est que quelque chose à raté dans la collaboration, tests ou analyse. Alors repartir sur un DS pour un nouveau proto à valider lui de manière plus précise.

Voilà un peu ma vision de la collaboration, qui doit rester très agile et proche, vraiment en « partenaire » projet.

Si tu as d’autres questions, n’hésites pas.

1 « J'aime »
5

J’ai encore des questions… Je taquine, mais rien de méchant :slight_smile:

Un sprint agile c’est du delivery, un Design sprint c’est de business case.
Revenir au business case pendant le delivery est un symptoms très grave en projet qui plus est en plein milieu d’un sprint agile.
Normalement le sprint (agile) va jusqu’à son terme (quoiqu’il se passe) et on redéfini de nouveaux backlogs à son issue.
Mais normalement le business case lui est déjà conclus, ce qui n’empêche de nouvelles modifs, sinon le projet doit être abandonné et on recommence un nouveau business case, un nouveau projet.

ça ressemble un peu à de la gestion à la one again
Je crois que je n’ai pas bien compris là,

Pour le 1er sprint (agile) tu veux dire?
Parce qu’il est impossible de planifier tous les sprints… c’est de l’agile, on planifie apres chaque sprint en fonction des backlogs et de la vélocité de l’équipe.

Pas bien compris là non plus

Sur 5 jours, avec la masse de travail à produire sur un DS, il est possible d’étudier les parties prenantes et la partie financière d’un projet?
Rien que la partie financière, en ayant décomposé correctement, demande un sacré travail de recherche ou de calcul si aucun projet similaire n’existe… Quels outils magiques utilises-tu?
Quant à l’etude des parties prenantes (il n’y a pas que l’équipe), mis a part connaitre parfaitement chaque individu impacté par le projet (directement ou pas)… pareil c’est un sacré boulot… Quelle technique permet d’aller plus vite?

6

Le design sprint a comme essence de « Delivrer » un prototype, transformer l’abstrait en concret en le validant tout du long du process.

Il peut donc être utiliser pour recentrer des hypothèse de fonctionnalités d’app par exemple, au milieu de phases de développement qui ne partaient plus dans le bon sens. En gros, apporter un point de respiration pour réorienter au mieux. Au lieu de Dev, proto, test validation, et continuer ou réorienter le dev. Très utile du coup pour gagner du temps et limiter les mauvaises directions !

Oui en effet, permet de planifier le start sprint agile, en proposant une vision plus large qui donne une cohérence globale également. C’est vraiment un partenaire parfait à l’agilité, d’ailleurs dans le livre tu verra beaucoup d’utilisation de méthodes agiles :slight_smile:

Durant la première journée du sprint, comprendre, il y a interview d’experts, souvent besoin, pour comprendre le business model, de l’intervention d’un expert business sur le secteur, cible, etc… Il apporte ainsi un cadre concret autour de déroulé du sprint, pour orienter au plus réaliste les hypothèses à développer.
En plus des experts, il y a les benchmarks + La présence du décideur qui a en tête beaucoup d’informations sur le secteur.
A la manière de la pyramide des risques, l’objectif d’un DS est de réduire au max les risques d’echec d’entrée, pour limiter dans des phases plus critiques de la suite des risques aussi. C’est bien entendu pas une méthode miracle, mais l’intervention d’expert + tests + décideur + benchmark + infos en amont du Ds, cela donne déjà un cadre propre, que se soit sur le business d’ailleurs, mais aussi sur tout le reste !

Le simple fait de travailler ensemble en groupe, avec une équipe sélectionnée diversifiée et complémentaire par rapport au sujet de la problématique, pendant 5 jours, permet d’amener la dimensions humaine et équipe à un haut niveau de test aussi. Déjà, après la première matinée, on peut voir si les parties prenants arrivent à fonctionner ensemble. Ensuite pareil, s’il y a interventions d’éléments extérieurs, le groupe étudie ça par rapport à des expertises, tests, bench… En gros se servir de tout ce qu’on a autour ainsi que des 7 cerveaux présents :slight_smile:

J’espère avoir donné un peu de lumières :slight_smile: Bien entendu, tout cela est suivant mon expérience et point de vue, humblement et ouvert à toutes remises en question :slight_smile:

7

Le design thinking ne couvre que 2 champs d’application, et un peu du delivery (pour l’aspect feuille de route). Ca ne couvre pas tout le champs gestion de projet (cf. schéma… 2eme ligne rouge).

fR6Ynq9.gif1280×720 1.98 MB

Néanmoins, cette approche est intéressante dans sa vision sprint sur la partie business case… a l’occasion, je testerai si possibilité il y a de mobiliser durant une semaine des opérationnels.
Merci

8

Je parlais bien surtout du process Design Sprint, et pas Design thinking, je suis d’accord sur ce que tu dis le concernant :slight_smile:

Et comme dit avant le Design Sprint rentre dans des autres phases de gestion de projet, c’est un complément :slight_smile:

n’hésite pas en tous les cas si tu veux tester :slight_smile: se sera un plaisir de continuer les échanges.

9

Après pas mal de recherche sur le sujet, je me suis rendu compte que le sprint design est un résumé et une approche concentrée de l’équivalent de la phase avant projet et initialisation dans le but d’un maquettage.

Bien que rien ne soit nouveau dans cette approche (toutes celles traitant un projet de À à Z on le même contenu) elle est intéressante parce que structurée sur une période limitée dans le temps (bien que ce temps limité soit un frein à la maturation de la demande et à l’engagement d’une part des parties prenantes suivant le type de projet).

Donc, à mon avis, intéressante En phase étude pour rechercher et valider une solution SI le projet n’est pas stratégique pour l’entreprise. Mais pas pour son implementation