Certes il faut apprendre à dire NON, mais ce n’est pas toujours la meilleure approche dans le management de projet.

Négocier sur le séquencement des livrables est souvent préférable à dire non d’emblée à une nouvelle demande de changement.

Idem au niveau du portefeuille de projets

Est-ce le bon moment pour lancer un nouveau projet ? Devrions-nous renoncer à un projet ? Ou devrions-nous temporiser un peu et positionner ce projet dans le portefeuille de projets à venir ?

Hexagon est partenaire de DantotsuPM

Commençons bien l’année, faisons un peu de ménage dans notre « product backlog » !

Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…

Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.

Qu’en pensez-vous et comment traitez-vous ce problème ?

Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?

Est-ce périodiquement lors de grands « ménages » saisonniers ?

Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?

CertYou est partenaire de DantotsuPM

pour identifier les besoins de vos clients, une pile de documentation n’est jamais aussi efficace qu’une bonne discussion collaborative.

Envoyer par email un jeu de documents pour exprimer un besoin ou une histoire utilisateur est rarement efficace.

En effet, de nombreux échanges seront nécessaires par ce média pour parvenir le plus souvent à une compréhension fragmentaire et incomplète du besoin. Les histoires d’utilisateurs Agile comme la description des besoins en méthode Waterfall sont plus efficaces en face à face. Le non verbal est très important et le cycle rapide de questions/réponses que permet l’interaction directe ne saurait être remplacé par l’écrit.

CSP est partenaire de DantotsuPM

Il s’agit donc de collaborer pour bien comprendre quel est le besoin, i.e. quel problème est à résoudre, plutôt que de se préoccuper du format de l’histoire utilisateur ou du document.

Idéalement, vous devez tous sortir de la séance de travail avec une représentation très claire de ce à quoi ressemblera le produit ou résultat du changement.

Si vous parvenez à identifier des éléments de mesure simples et fiables et à utiliser pour capturer la situation actuelle et la future souhaitée, vous aurez déjà franchi une étape clé.