Tag Archives: requirements

Pourquoi un Sprint Zéro avec Scrum et Agile ?

10 Oct

Le concept de Sprint Zéro est controversé !

Why Have Sprint Zero? par Sujatha Tokala

Sprint Zéro

Sprint Zéro

Je me rends compte que le concept de Sprint Zéro est controversé. Et dans mes premiers temps en Agile, j’ai été étonné par l’importance accordée à ce sujet. Je pensais que nous aurions des sessions de transfert de connaissances au fil du travail, alors, pourquoi avoir un sprint séparé ? Mais plus tard j’ai compris l’importance du Sprint Zéro dans l’organisation où je travaille. Je ne prétendrai pas que toutes les équipes en ont besoin, mais voici pourquoi c’est utile pour nous.

Les questions abordées au Sprint Zéro s’appliquent à la release toute entière.

Nous pourrions l’appeler Sprint Initial, Itération Zéro, ou Sprint de démarrage.

Selon mon expérience, le Sprint Zéro est limité dans le temps à seulement une semaine.

Notre équipe passe en revue l’ensemble des items de la release et quel travail devrait être achevé dans chaque sprint. En passant en revue chaque article de sprint, l’équipe identifie les endroits pour lesquels nous ne connaissons pas suffisamment bien les exigences qu’elles soient matérielles, d’architecture, logicielles, ou techniques.

Après que l’équipe ait revu les épics (ndlt. groupe de User Stories pour fournir une valeur métier) et fonctions priorisés de l’arriéré de produit, nous devons les annoter et préparer les sessions de revue avec le product owner, le propriétaire de produit. Nous devons comprendre l’environnement et le code exigé pour les items de l’arriéré de produit, indépendamment de si le code sera simple ou complexe.

Comment décomposer les niveaux d'exigence Agile (précédent billet à relire)

Comment décomposer les niveaux d’exigence Agile (précédent billet à relire)

La raison principale d’introduire un Sprint Zéro est que nous ne voulons pas inutilement prolonger le temps nécessaire aux sessions de revue ou de transfert de connaissance depuis le Sprint 1 jusqu’à la fin. Donc, nous prenons une semaine pour préparer notre équipe avant de démarrer sur des arriérés de sprint.

Grâce à Agile, on nous donne l’opportunité d’en apprendre beaucoup en peu de temps.

L’équipe avancera de façon calme, sans pression excessive.

CertYou est partenaire de DantotsuPM

CertYou est partenaire de DantotsuPM

Utilisez-vous un sprint 0 en début de release sur votre projet Agile? Pourquoi? Quels en sont pour vous les bénéfices et inconvénients ?

Enregistrer

Enregistrer

Enregistrer

Enregistrer

comment découper vos « User Stories » #Agile (Histoires Utilisateur) avec la méthode INVEST

1 Sep

Splitting User Stories

http://www.agileadvice.com/2016/06/03/scrumxplean/splitting-user-stories/ par Faisal Ansari

Un défi usuel auquel sont confronté les équipes Scrum inexpérimentées est lié au découpage des « User Stories » (dans Scrum, les articles du Product Backlog) pour qu’elles soient suffisamment granulaires pour le développement. Le modèle INVEST est une bonne façon de tester si les « User Stories » sont bien écrites.

Microsoft est partenaire de DantotsuPM

Microsoft est partenaire de DantotsuPM

I.N.V.E.S.T.

  • IIndépendante
  • N– Négociable
  • V– de Valeur
  • EEstimable
  • SSuffisamment petite
  • TTestable

Indépendante

Chaque « User Stories » doit être indépendante l’une de l’autre. Ceci empêche les chevauchements entre les items; de plus, cela permet à l’équipe de les implémenter dans n’importe quel ordre.

Négociable

Les détails du travail doivent être négociables, tant parmi les parties prenantes que l’équipe. Les besoins spécifiques et décisions de conception seront étoffés pendant le développement. Beaucoup de praticiens agiles recommandent d’écrire les « User Stories » sur une petite fiche – ceci est intentionnel pour qu’une quantité limitée de détails puisse être prescrite.

de Valeur

Chaque « User Stories »doit ajouter un valeur métier/business au produit, au client et/ou à l’expérience des utilisateurs.

Estimable

Une bonne « User Stories » peut être suffisamment bien comprise par l’équipe pour qu’ils puissent l’évaluer – pas précisément – mais qu’à un haut niveau ils en perçoivent la taille. Il est utile de comprendre l’effort relatif en comparaison d’autres « User Stories ».

Suffisamment petite

Une « User Story » n’est pas assez petite si l’équipe ne peut pas la faire faire dans un seul Sprint. Comme des grandes « User Stories » sont divisées en items plus petits, la clarté sur la taille et la mise en œuvre est plus grande, ce qui améliore la probabilité que l’équipe le réalisera en un Sprint.

Testable

Chaque « User Story » devrait être testable; ceci est une caractéristique commune de tout besoin bien écrit. Si l’équipe ne peut pas déterminer comment la « User Story » peut être testée, c’est une indication que la fonction désirée ou la valeur business désirée ne sont pas assez claires.

Découpage vertical ou horizontal

Il y a deux manières communes de découper des « User Stories » : verticalement ou horizontalement. La découpe horizontale divise l’article au niveau d’un composant architectural. Exemple : Interface Utilisateur, bases de données ou services back-end. Tandis que, une découpe verticale aboutit à un résultat logiciel démontrable qui ajoute de la valeur au business. Donc, on recommande de découper verticalement les « User Stories » afin de réduire les dépendances et améliorer la capacité de l’équipe à livrer un incrémentent de produit potentiellement utilisable à chaque sprint.

Des exemples de découpe de « User Stories »

Trop grosse User Story:

Trop grosse User Story: « En tant que client, je peux payer ma commande pour recevoir les produits »

En tant que client, je peux payer ma commande pour recevoir les produits

Si la susdite histoire devait être divisée de façon verticale, elle pourrait se décomposer en fonction des façons de payer pour un client comme suit…

  • En tant que client, je peux faire un paiement par carte pour ma commande et collecter des points de récompense sur ma carte de crédit.

Et/ou

  • En tant que client, je peux faire un paiement PayPal pour ma commande pour que achever mon achat en toute sécurité sans partager les détails de ma carte de crédit avec un autre détaillant.

Le point clé de noter dans les « User Stories » verticalement décomposées comme ci-dessus consiste en ce que chaque « User Story »passe les tests INVEST mentionnés plus tôt et donc un Propriétaire de Produit (Product Owner) peut prioriser ces « User Stories » en fonction des besoins clients. Cependant, si une approche horizontale a été utilisée pour diviser la « User Story » (c’est-à-dire décomposition selon les couches et composants architecturaux) alors la mise en œuvre de tels besoins aboutira à une fonctionnalité utilisable Seulement quand tous les composants horizontaux seront finalement livrés et intégrés.

Découpage par flux de travail

revoir mon panier de courses

revoir mon panier de courses

Une autre approche souvent utilisée sur les « User Stories » est de se concentrer sur les étapes individuelles qu’un utilisateur peut entreprendre pour atteindre son objectif final. C’est-à-dire une « User Story » qui décrit un long parcours ou « flux utilisateur » dans un système peut être décomposé selon les étapes qui en représentent les parties. En reprenant l’exemple précédent d’un client faisant un achat en ligne, la « User Story » peut être décomposée de la manière suivante :

  • Fournir mes informations bancaires

    Fournir mes informations bancaires

    En tant que client, je peux passer en revue les articles que je veux mettre dans ma commande pour être confiant que je paye pour les bons articles.

  • En tant que client, je peux fournir mes informations bancaires pour ma commande pour recevoir les produits que j’ai achetés.
  • Recevoir une notification par SMS

    Recevoir une notification par SMS

    En tant que client, je peux recevoir un avis de confirmation pour mon achat pour suivre et garder une trace de mon achat.

D’autres méthodes

Il y a de nombreuses autres méthodes qui peuvent être utilisées dans le découpage des grandes « User Stories » comme :

Visitez le blog Agilistic

Visitez le blog Agilistic

  • par déroulement heureux / malheureux (ce qui se passe quand tout va bien versus quand il y a des exceptions, déviations ou autres problèmes)
  • par options d’interaction / par plate-forme
  • par types de données ou paramètres
  • par scénarios de test
  • par rôles
  • par ‘j’optimise maintenant ‘ contre ‘ j’optimise plus tard
  • par compatibilité de navigateur

la liste ci-dessus est détaillée (en anglais) dans ce billet: Blog.agilistic.nl.

Autres Ressources Utiles

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

Enregistrer

July 12 – Webinar (PMI®) – Rethink Requirements – The Natural Language Processing Approach

5 Juil

According to PMI’s Pulse of the Profession, “When projects do not meet their original goals and project objectives, inaccurate business analysis/requirements management is cited as the primary cause 47% of the time.”

And the increasing scale and complexity of projects is making it extremely difficult to assess and verify the project requirements. As a result – a huge amount of critical errors in project and systems development arise in the initial concept & design stages.

MPM est Partenaire de DantotsuPM

MPM est Partenaire de DantotsuPM

In this presentation and workshop, we will focus on how harnessing automated computational tools utilizing Natural Language Processing can help project managers ensure their requirements are consistently clear & are a joy to work with.

These project managers, business analysts, engineers and by extension their clients, will benefit in the earliest stages of a project to ensure poorly written requirements do not infiltrate later project stages leading to reduced stress, increased confidence and higher project success.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Registration

PMI is a registered mark of Project Management Institute, Inc.

Enregistrer

June 7 – Webinar (PMI®) – Slashing Risks with User Experience Engineering (UX) Second Edition

24 Mai

Recent PMI Study calls Requirements Management a core competency for project and program success – and does so for a good reason.

User Experience47% of projects run into trouble due to incomplete or changing requirements & specifications, lack of user input or unrealistic expectations.

UX methods brought wild success to Apple, Google and other top players and it has been increasingly popular ever since.

But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective!

This is an expanded and updated version of popular session that ran on February 23, incorporating additional information based on your feedback.

Requirements Management is the single biggest risk for a majority of projects. According to PMI, 47% of initiatives that missed the mark did so because of requirements management. It’s truly is a core competency for project and program success.

Imagine your life without these risks. Little or no stakeholder management… Clarity around scope and direction… Stable, measurable requirements, completely aligned with business needs…

Design Thinking and UX brought wild success to Apple, Google and other top players and it has been increasingly popular ever since. But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective, it’s the new tools for Business Analysis.

Attend this webinar to learn about these extremely effective new Design Thinking tools and processes – for gaining accurate insights, discovering ‘missing’ requirements and hidden underlying problems.

Details and registration

Partenaire de DantotsuPM

Partenaire de DantotsuPM

Pourquoi je vais passer la certification PMI-PBA® ? Par Marc Burlereaux

4 Avr
Marc Burlereaux

Marc Burlereaux

Pourquoi le responsable de programme, chef de projet que je suis va passer une certification sur l’Analyse Métier et en l’occurrence PMI-PBA® : Professional in Business Analysis de PMI (Project Management Institute) ?

1. Mon parcours

Si j’ai fait de l’Analyse métier au début de ma carrière (à l’époque nous utilisions MERISE !), que ce soit en ayant le titre de chef de projet ou consultant et si mon poste actuel au sein de HSBC Private Bank Swiss SA est « Senior Business Analyste », la plupart de ma carrière dans la banque privée suisse se déroule à des postes de Responsable de Programmes, Chef de Projets, Responsable de Département IT…

Et, enfin et surtout, en tant que Responsable Européen des Releases : je précise « surtout » car ce poste occupé pendant deux ans m’a permis de constater de nombreux errements quant à la gestion des exigences, qu’elles soient fonctionnelles ou non fonctionnelles. Et cela coûte cher et ajoute des risques quand nous devons « sortir à la dernière minute » des livrables non acceptables par le client car mal ou pas complètement analysés.

user requirementsTout le monde connait cette illustration sarcastique du produit livré ne correspondant ni aux attentes du client ni à la réalité de ces besoins. Mais c’est si vrai ! Ce serait une des raisons pour laquelle l’Analyse Métier s’est professionnalisée.

C’est aussi une des raisons de l’émergence de l’agilité.

A ce propos, je me rappelle une anecdote de mon début de carrière, en 1988. Je travaillais sur la conception d’une nouvelle plateforme bancaire à Genève en utilisant MERISE au sein d’un gros projet : jeune analyste métier, je rédigeais des Spécifications Fonctionnelles Détaillées en étant contraint par les Spécifications Fonctionnelles Générales analysées précédemment par d’autres.

En discutant avec le métier je me suis aperçu que l’étape précédente avait été mal analysée et j’ai donc adapté mon analyse détaillée au besoin du métier. Je fus recadré par la Direction du Projet qui me demanda de respecter les contraintes de l’étape précédente même si cela allait à l’encontre de la satisfaction des besoins du métier ! Ma frustration est encore vivace !

2. Mon expérience de Release Manager Européen

europeLors de ces deux années mon rôle fut de manager les livraisons coordonnées des différents projets livrés par les différents domaines du développement d’une banque privée genevoise dans un contexte européen.

Les livraisons étaient d’abord effectuées avec une fréquence trimestrielle, donc avec de nombreux livrables provenant de différentes équipes mais ayant des interdépendances.

Nous avons travaillé avec les acteurs de la gestion du changement, à savoir le métier, les architectes, la sécurité, le test et la production afin que l’entrée en release soit validée par ces acteurs pour éviter de découvrir quelques semaines avant la livraison des dysfonctionnements tels que :
  • le périmètre de la livraison est bien déterminé : fonctionnellement mais aussi géographiquement. Cela semble couler de source, mais pour des projets de petite taille (moins de 200 jours homme), j’ai constaté un manque de rigueur fatal à toute mise en production.
  • les architectes ont bien validé la solution.
  • la sécurité a été impliquée et que ses recommandations ont bien été mises en œuvre.
  • le support et la production ait pu donner leurs exigences non fonctionnelles à respecter avant toute mise en place.
Mais cela ne nous a pas empêché d’avoir à gérer des « sorties de release » suite à des analyses métier déficientes avec diverses origines :
  • Difficultés de l’analyse métier « à distance » par nos équipes offshores
  • Oubli d’interdépendances fonctionnelles ou géographiques
  • Normes de sécurité non respectées
  • Rejet par des utilisateurs non préparés (en termes de ressources et de formation)
  • Manque de stratégie globale de test sur des livrables différents mais interdépendants

3. L’Analyse Métier réussie, facteur clé de la réussite des projets

Une des raisons majeures des échecs dans les projets est la mauvaise définition des besoins :
  • succès ou échecSelon Carnegie, 25%-40% du budget des projets est utilisé par refaire à nouveau ce qui a déjà été fait … et que 70% – 85% de ces coûts de « re travail » sont dus à des erreurs dans la collecte des exigences métiers.
  • Selon le Gartner, 60 à 80% des échecs de projets peuvent être directement attribué à une mauvaise analyse des besoins ou exigences.

Il est donc important que le Responsable de Programmes, Chef de Projets, comprenne et maîtrise ce domaine, même s’il est sous-traité à des équipes d’Analystes Métier, afin de diriger au mieux cette activité primordiale de la gestion de projet et d’en gérer les risques.

4. Pourquoi je vais passer cette certification PMI-PBA®

Tout d’abord pour les mêmes motivations qui m’ont fait passer d’autres certifications :
  • PMI PBATravailler sur des supports de cours en anglais et donc progresser dans ce domaine,
  • Réfléchir sur des concepts et outils que j’utilise au quotidien mais dont je peux utiliser l’amélioration,
  • Acquérir de nouveaux outils,
  • Rencontrer des personnes ayant les mêmes centre d’intérêts toutefois dans des domaines différents afin d’enrichir ma créativité.
Mais aussi :
  • Assurer une meilleure initiation des projets / programmes
  • Éviter d’avoir à retravailler des livrables du projet
  • Savoir déjouer les pièges de l’Analyse Métier à distance lorsqu’elle est déléguée à des partenaires éloignés comme en Inde, Chine ou Pologne, mais aussi quand une équipe centrale collecte des besoins pour différentes entités locales. Mon expérience m’a montré que les « Analyses Métier à distance » sont pleines de pièges à déjouer : autant anticiper !
  • Posséder une double compétence de plus en plus prisée pour des projets petits à moyens ou la réduction des coûts implique de savoir tout faire
  • S’assurer dès le début du projet que la collecte des exigences métier est intégrée dans un mécanisme de documentation des tests d’acceptation
  • Pour introduire de l’agilité, car le client a désormais le droit de changer d’avis … mais aussi car l’environnement incertain et instable requiert cette flexibilité accrue
Détails sur la certification PMI-PBA du PMI

Détails sur la certification PMI-PBA du PMI

Et enfin parce que l’analyse métier réussie est un facteur clé de succès du projet !

Je vous donne rendez-vous dans quelques semaines une fois la certification passée pour vous faire part de la rétrospective de mon expérience !

Partenaire de DantotsuPM

Partenaire de DantotsuPM

22 Mars – Montréal – Gestion de requis des clients dans le développement d’un nouvel avion

3 Mar

Un nouvel événement du PMI Montréal avec André Blanchet, plus de 25 ans d’expérience dans l’industrie aéronautique.

airbus en constructionOutre des compagnies telles Boeing, Airbus, Bombardier et Embraer, peu de compagnies sont capables d’entreprendre le développement d’un nouvel avion.

C’est une industrie caractérisée par la sécurité du produit où des requis de certification sévères exigent des fabricants des processus d’ingénierie, de qualité et de production approuvés depuis fort longtemps, par les autorités aéronautiques. Le développement d’un nouvel avion prend plusieurs années et requiert des efforts de gestion de projet qui sont contraints par des processus existants. Les requis des clients qui sont établis au début du programme sont souvent remis en question par les acheteurs et par des changements de conditions de marché.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Dans cette conférence, André Blanchet explique les enjeux de la gestion de requis des clients vis-à-vis la gestion de projet d’un nouvel avion.

MPM est Partenaire de DantotsuPM

MPM est Partenaire de DantotsuPM

February 23 – Webinar (PMI) – Slashing Risks with User Experience Engineering (UX)

9 Fév

Recent PMI Study calls Requirements Management a core competency for project and program success – and does so for a good reason.

User Experience47% of projects run into trouble due to incomplete or changing requirements & specifications, lack of user input or unrealistic expectations.

UX methods brought wild success to Apple, Google and other top players and it has been increasingly popular ever since.

But what most magazines don’t tell you is that it’s not just the Design part of UX that makes it so effective!

Attend this webinar to learn abut the not-so-glamourous, but extremely effective new UX tools and processes – for gaining accurate user insights, discovering ‘missing’ requirements and hidden underlying problems – the ones that business users would really like to see resolved first – even when they are not be clearly articulated.

Details and registration

Partenaire de DantotsuPM

Partenaire de DantotsuPM

PMI Requirements Management Practice guide available for free download

16 Jan

Requirements Management Practice Guide Launched

requirements managementPMI recently launched a new practice guide on requirements management, which is available for free download for a limited time.

Requirements Management: A Practice Guide is a complementary document to the Project Management
Institute’s (PMI’s) foundational standards. This practice guide provides guidance for project and program managers
who are looking to further understand the components and importance of requirements management.

A Practice Guide is for your individual use only. It may not be shared, copied or otherwise distributed further without written permission from Project Management Institute. All rights reserved.

Auriez-vous mis la charrue avant les bœufs ?

30 Nov

Project Management: Is Your Cart Ahead of the Horse?

http://www.pmhut.com/project-management-is-your-cart-ahead-of-the-horse par Chris Thompson

Cart-before-horseDites-moi si vous avez jamais vécu ce scénario :

Un client vient vous voir avec un besoin. Ceci crée un projet pour compléter la tâche et peut typiquement prendre la forme d’un projet de conception-construction. Quelqu’un peut entendre « conception-construction » et penser à la conclusion d’un contrat, mais je soutiendrais que le scénario conception-construction n’est pas uniquement lié à la conclusion d’un contrat.

La conception-construction considère les besoins du client, avec la connaissance du vendeur, pour en bout de ligne créer le résultat final après que les termes sont acceptés par les deux parties. Les processus de conception ou développement peuvent être itératifs ou être achevés avant que le projet ne commence. Pendant cette période de collecte des besoins et pendant le développement du périmètre, une relation unique commence à se former entre les deux partenaires. On espère que ce processus sera positif et qu’un certain niveau de confiance est mutuellement acquis.

Campana & Schott est partenaire de DantotsuPM

Campana & Schott est partenaire de DantotsuPM

Ceci est le moment où la charrue commence à passer devant les bœufs.

stop siffletLes deux parties prenantes sont enthousiasmées par le projet et les deux tiennent beaucoup à commencer à travailler. La question principale à vous poser à vous-même est, avez-vous tous les deux convenu de vraiment tout à l’avance ? Vous avez probablement collecté les besoins nécessaires pour concevoir la partie qui sera complétée en premier. Vous avez probablement convenu d’un devis tarifaire et avez développé un accord contractuel pour protéger légalement les deux parties. Vous avez probablement même développé une sorte d’échéancier car ceci peut être un facteur déterminant pour vérifier si vraiment le client veut lancer le projet ou si vous avez la capacité de le faire ainsi dans les délais demandés.

Semble-t-il que tout soit prêt pour que le projet commence ? Typiquement, en dehors de la construction proprement dite, il n’y a pas de vrai événement significatif du début d’un projet. On commence lentement par de petits morceaux, des appels téléphoniques, des courriers électroniques, un petit travail de fond sur quelques items et, avant que vous ne le sachiez, vous êtes entièrement plongés dans le projet.

À ce point, si ceci est arrivé, votre charrue a largement dépassé vos bœufs.

Qui le projet va-t-il impacter ? Pensez-vous juste au propriétaire ou au représentant du propriétaire, ou considérez-vous aussi d’autres parties prenantes à l’intérieur ou à l’extérieur des deux organisations ? Que veulent-elles gagner ou obtenir avec ce projet ?

Quelles communications sont importantes pour elles? Comment veulent-elles ces communications, combien de fois et dans quel format ? D’autres projets dépendent-ils de ce projet ?

Voici quelques questions simples (liste non exhaustive…) pour vous aider à vous rendre compte qu’il vous manque deux ingrédients clés et, détail le plus important, un plan de management de projet agréé tant par vous que par le client.

Définir qui le projet touchera et en quoi il les affectera produit deux choses.

D’abord, cela produit une liste de parties prenantes, mais plus important encore une analyse des parties prenantes qui permettra d’identifier les besoins que vous devrez considérer pendant la réalisation du projet. La production d’un résultat final ou d’un livrable satisfera l’élément le plus basique de l’engagement. Ce qu’il pourrait vous manquer sont les besoins des parties prenantes supplémentaires qui n’ont pas été satisfaits. Le développement de cette analyse aidera aussi à développer un autre composant clé, le plan de communication.

Partenaire de DantotsuPM

Partenaire de DantotsuPM

« Le Savoir est le Pouvoir ».

knowledge is powerCeci vous semble-t-il familier ? Rappelez-vous que chaque personne affectée par ce projet a des intérêts spécifiques qui devront être adressés. Peut-être que l’un des investisseurs aura besoin de délais ou informations spécifiques à intervalles réguliers pour informer l’entité avec des détails précis. Ceci pourrait affecter le financement du reste du projet. Le Directeur de Programmes dans votre organisation devra-t-il agréger des informations de projet par lui-même pour le comité de direction ?

Ces deux cas nécessitent que des informations différentes soient vérifiées non seulement par des méthodes différentes, mais peut-être aussi des moyens différents et à des fréquences différentes. Avez-vous 100 à 200 parties prenantes ? Est-il réaliste de communiquer des informations par courrier électronique, ou le développement d’un site web serait-il plus pertinent ?

En supposant que nous avons répondu à toutes les questions ci-dessus et fourni un plan pour les adresser, regardons maintenant ce que nous avons développé. Nous avons un registre et une analyse des parties prenantes, des besoins définis, un contenu bien borné, un plan d’approvisionnement, un échéancier de projet, un contrat et un plan de communication. Tels sont les ingrédients clés du plan global de projet (sans parler de l’analyse de risque réalisée à ce stade). Chacun de ces éléments devrait alors être formalisé, assemblé selon un ordre logique et présenté comme tel. Ceci sera le plan utilisé pour compléter le PROJET qui produira le LIVRABLE.

Remarquez la dernière phrase…car ceci est une considération importante.

House and Keys in Female HandsUn projet crée ou produit un livrable. Un projet est composé d’étapes pour produire un résultat final. Le plan de projet est le document détaillé qui décrit noir sur blanc comment ce sera fait. Une fois complété, il est présenté au client et chaque côté doit alors le signer. Cela ressemble beaucoup à un contrat et peut avoir la même signification légale. Cependant, la plupart du temps c’est un plan modifiable qui expose des critères pour les futurs problèmes qui pourraient surgir et les obligations contractuelles se centrent typiquement sur des items plus classiques comme le coût des articles, l’échéancier et la date d’achèvement, des questions de propriété et des considérations gouvernementales.

J’espère que cette description de scénario aura provoqué chez vous une réflexion autour de vos standards de mise en œuvre de projet. Rappelez-vous que maintenir les bœufs devant la charrue rendra beaucoup plus facile de la diriger quand vous prendrez de la vitesse.

October 15 – Basel (CH) – Add value to your project and reduce cost through Usability and User Experience (UX)

2 Oct

This presentation will introduce you to the basic concepts of user-centered design – an approach that not only provides more value to the customer organisation and users, but also addresses some common project challenges.

With Andreas Bleiker, learn about how caring systematically for usability and UX helps your project through

  • Andreas Bleiker

    Andreas Bleiker

    better defining and understanding requirements

  • preventing scope creep and development of unnecessary functionality
  • reducing number of issues during testing
  • increasing adoption
  • reducing training and support cost
  • reducing the number of change requests in operations
  • increasing productivity of users
  • increasing your reputation as a PM

%d blogueurs aiment cette page :