Interactive Project Management

Pixels, People and Process

Nancy Lyons and Meghan Wilker (CEO & COO chez Clockwork)

 

1. Introduction

This book should be called "A Client, Leader, Team, and Project Manager's Guide to Avoiding Train Wreck". But for some reasons our publisher rejected that title

C’est en allant à Manchester pour une conférence dédiée aux Digital Project Managers que je découvre le travail de Nancy et Meghan. Au-delà de leur talk qui fut mémorable, leur livre vaut  lui aussi complètement le détour.

J’ai décidé de vous en faire une synthèse (mélangeant un résumé des informations les plus utiles et citations percutantes in English please), mais je ne peux que vous conseiller d’aller vite l’acheter et le dévorer ou de passer chez nous pour bouquiner.

Ce livre s’adresse bien sûr aux chefs de projets, mais aussi clients, et plus largement à toute personne travaillant dans le web.

Interactive projects are chaotic by nature [...]. The key is a good process, and the key is a good focus on people”

Interactive Project Management

  • Project managers think, analyze, communicate and motivate

  • Interactive project management is a leadership role

  • A good project manager plans proactively, reacts appropriately, communicates actively and observes vigilantly

  • Interactive project managers should be personable, detail oriented, naturally communicative and active online

Pixels

  • The interactive industry creates living products that are used, not consumed

  • Plan for change, technology is always evolving

  • Interactive products unite creative technology and technological creativity

  • The success of a product is measured by user’s experience with it

People

  • Recognize and work with people’s emotions, not against them

  • Care about your team, your clients, your work

  • Be collaborative, open, clear, thorough

  • Effective communication is essential: think about what precisely needs to be communicated and the best way to deliver that message

Process

  • Processes enable work, they don’t obstruct it

  • The process isn’t just for project managers - it’s for everybody

  • Planning means greater freedom to find the right solutions

  • Define what you’re doing and why: establish parameters and requirements; state goals and strategies”

2. The Interactive Industry

Interactive products are both technological and creative; they’re both software and advertising; they’re both functional and fun

Dans ce chapitre est abordée la question de la compréhension de notre industrie, soit que représente-t-elle exactement?

Pour beaucoup (beaucoup) de clients, c’est une zone floue. Mais au-delà d’être floue, elle est aussi souvent inintéressante (car peu accessible ou mal comprise). Nous devons être capables de la rendre claire pour eux. Disons que c’est un préalable obligatoire à la future collaboration. Sinon on est mal barré.

L’évolution

L’industrie dite interactive est née très récemment d’un mélange de générations et de domaines d’activités. Rappelez-vous, il y a à peine 20 ans, un informaticien installait votre modem, et vous créait un “site”. On avait aussi les développeurs softwares purs et durs.

Et, à l’opposé, les agences de communication faisaient leur truc de créatifs. Dès les années 1990, ils commencent à s’intéresser aux médias digitaux, mais les résultats étaient principalement des produits orientés brand et marketing digital (un super jeu, un super site en flash, etc).

Puis… Le digital est devenu incontournable dans plein d’autres domaines et les agences web ont commencé à voir le jour. Un doux mélange d’une multitude d’expertises. À mi-chemin entre l’agence de communication et la société d’informatique. Les formations ont évolué et les compétences se sont affinées, spécifiées.

Le Produit

Une fois ceci posé, il nous reste le produit. Que ce soit un site, une app, une newsletter, un intranet, que représente ce produit? Souvent, il est le joli bébé d’un département ou d’un Directeur. Mais ce n’est pas sa vocation première, non non. Interactif n’est pas un mot choisi au hasard.

  • It’s the unique relationship between the end product and the end user.

  • The interactive industry produces digital products that advance client business goals through effective interactions.

  • The rush to do anything as long as it’s online should be over. Now we need to reflect on what we learned from the boom and bust of the last decade, and focus on defining how we, as an industry, can deliver work that brings value to clients and end users alike.

Ces dernières lignes nous rappellent (ou nous apprennent, c’est selon), que nous - travailleurs de l’industrie interactive - avons à présent une responsabilité envers l'utilisateur. C’est à nous de définir ce que sera un bon travail digital et comment les projets devraient être produits. Une dette technique en somme.

Le Process

Du côté process, cette évolution rapide et riche n’a pas été simple à gérer et a empêché la création de réels standards.

Beaucoup de méthodologies de travail existent. Certaines très proches du côté développement logiciel pur (Agile, Scrum, Kanban), d’autres plus proches des agences de communication (Waterfall). Que choisir dans notre domaine?

Le livre propose sa solution. Nous ne la suivons pas telle quelle chez Antistatique mais certains de ses aspects nous parlent bien évidemment.

Conclusion du chapitre

Aujourd’hui nous devons changer notre façon de voir ce qu’est un projet digital. Ce ne sont pas des produits que l’on consomme passivement, mais il s’agit bien d’utilisation active.

Nous devons apprendre à expliquer ce que l’on fait et les process mis en place pour y arriver. D’autant plus qu’un projet digital - à l’inverse d’un projet print par exemple - ne finit, lui, jamais. Il y aura toujours des mises à jour à faire, du contenu à changer, une technologie qui aura évoluée.

Apprenons donc à travailler ensemble.

3. Interactive Project Management & Emotional Intelligence

Technology doesn’t drive projects, people do.

Ces chapitres nous expliquent le rôle d’un(e) Chef(fe) de projet et les qualités supposées qu’il(elle) doit posséder pour remplir ce poste.

Un chef de projet a un rôle évident de chef d’orchestre. Souvent, il a plus de 5 corps de métier différents à gérer parallèlement; ceci en plus de la relation client. Il doit analyser, communiquer, motiver. Il doit penser aux moindres détails, planifier et déjà imaginer le pire s’il devait arriver.

Une chose spécifique a attiré mon attention et il s’agit de l’intelligence émotionnelle. En effet, on a tellement la tête dans le guidon que l’on oublie qu’au-delà de la technologie, il y a des gens.

Le web est fait par des gens pour des gens. Et c’est bien ce côté social que l’on néglige parfois.

Avoir une intelligence émotionnelle est un must si vous voulez être un bon manager, que ce soit en meetings, pour demander à quelqu’un de faire quelque chose, pour donner un feedback pour communiquer avec le client, comprendre ce qu’il a derrière la tête ou pour simplement remarquer que quelqu’un ne va pas bien aujourd’hui.

It used to be that a lot of the things that make us human - like feelings and personalities - were left at the door when we came to work [...]. We - the collective we - were focused on “professionalism”. This meant not talking about our personal lives, not expressing our moods, and avoiding discussions about feelings or conflicts. [...]. But here’s the truth: Personal issues do affect work. Acknowledging that and reacting with basic human understanding goes a long way in making the team more productive. That’s the new professionalism.

4. Communication

Technology creates tension.

Ces phrases représentent merveilleusement bien les problématiques de communication que le digital génère. Qu’en dites-vous?

Et donc, la communication à avoir avec le client se doit d’être encore plus soignée.

Si un problème survient, on ne pourra pas lui dire que ses flyers sont coincés en Ukraine à la douane. Non, on devra lui expliquer ce que notre développeur nous a dit (“ksehféawekhféaeigàoiewhgjàeiwgà”), à retranscrire en langage humain, toujours non compréhensible.

Ce chapitre pose donc quelques règles élémentaires du type:

  • Pas de longs emails. “Don’t make people work hard for information” :) Et si votre email doit être long, on fait des paragraphes, on met des bullet points, on highlight les informations importantes avec du gras.

  • Pas de mail compliqué! On appelle pour expliquer

  • Pas de mail type grenade :)

  • Pas de *NON*

La communication requière aussi des …. outils de communication. Prenez le temps de leur expliquer ce que vous attendez d’eux (du client et/ou de ses équipes donc) et l’utilisation souhaitée pour chacun des outils.

Bien évidemment les minimas de la communication sont ici aussi rappelés (PV, Follow-up, comment résoudre un conflit, comment annoncer une mauvaise nouvelle, trouver la racine du problème…), mais je ne vais pas m’étendre sur ces règles élémentaires.

5. The process

The process isn’t for the Project Manager, it’s for everybody

Nous y voilà, nous y voilà, nous y voilà!

Des méthodologies, il y en a plein, on le sait malheureusement souvent inadaptées (trop “dev” ou trop “com”).  Qui plus est notre industrie très neuve et bougeant vite n’a pas forcément éprouvé de méthodologie propre. Du coup on a bricolé un peu… et construit des process hybrides.

Cela ne veut pas dire que cela ne marche pas… La preuve: Clockwork a élaboré sa propre méthodologie (inspirée des méthodolgies citées plus haut) et qui leur convient à merveille.  

Posons donc cette base: un processus de travail n’est pas juste un truc qui embête toute l’agence. C’est quelque chose qui est sensé bien évidemment aider l’équipe, mais également le client.

Following a process - any process - shouldn’t be confused with project management. A process is just a guide; project management is thinking and taking action. Remember when we compared the project manager to the conductor of an orchestra? Well, the process is like the sheet music. You need it, but more importantly you need to inspire a group of talented musicians to play it.

Je vous propose donc de d’abord jeter un oeil au tableau qui illustre leur méthodologie. Appréhendez-le comme un “you are here” map.


Frontend versus backend: Dans le cas du présent tableau, le frontend définit tout ce que l’utilisateur voit ou ce avec quoi il intéragit (design, contenu,...). Le backend quant à lui représente les coulisses du projet digital, soit le code.

Les caractéristiques de ce process sont définies ainsi:

  • “Organized simultaneity”: plein de corps de métiers travaillent en même temps sur un même projet. Il faut donc une base collaborative et organisationnelle.

  • Goals first”: la phase de Research and Planning sert à déterminer ce qu’il y a à faire, mais surtout pourquoi le faire. Les clients arrivent bien trop souvent avec la solution (un site, une app…), mais oublient de se demander quel est le problème. Ainsi ce process a aussi une influence sur le budget. Chez Clockwork, ils ont opté pour 2 estimations. Une pour la phase de recherche, lors de laquelle le périmètre du projet sera défini. C’est seulement lorsque le scope est posé qu’une deuxième estimation est livrée. Celle pour la production et le déploiement dudit projet.

  • “Efficient and verifiable”: les livrables sont des checkpoints obligatoires. Ils doivent être documentés et validés. Le client doit et a le droit de savoir et comprendre ce qu’il va recevoir. Oui oui. “Surprises are only good at birthday parties”. Chaque étape de leur process a pour vocation de clarifier le projet un peu plus et ainsi avoir - à la fin - une vue globale de ce qui a été pensé, défini et produit. Il est aussi important de préciser que ces livrables sont une base également pour tous les futurs “change requests” qu’il pourrait y avoir tout au long du projet.

  • “Intentional simplicity”: le process contient uniquement ce qui est requis. Ni plus ni moins. Il faut “assez” de procédures, il n’en faut pas trop.

  • Make a plan, Watch it burn.

  • We built accommodations for change into our process. We did this by keeping our overhead low: changes are easy to document, verify, and track. We don’t want our internal team members spending four hours updating complicated software whenever a change comes up (Sorry, Microsoft ProjectTM, we’re looking at you).

  • Our process makes us more flexible, not less so.

Je vous propose de passer à présent aux chapitres propres aux diverses phases du projet telles que représentées ci-dessus.

6. Project Prep

Thinking through - and documenting - how everything is going to get done is as important as getting it done

Bon, cela semble très logique comme phase, on y choisit les membres de l’équipe qui vont travailler sur le projet, on fait en sorte que les personnalités qui vont travailler ensemble matchent, on se pose beaucoup, beaucoup de questions (que l’on va bien sûr aller poser ensuite au client), on kickoff en interne, on kickoff avec le client.

Ce qui peut sembler moins logique c’est l’importance qu’a cette phase. On oublie trop souvent que ce début va influencer tout le projet par la suite. Et ce début est la phase la plus floue du projet, donc il est crucial de ne rien oublier, de ne pas travailler dans le stress, de se poser les bonnes et les mauvaises questions ( “errors of omission are the hardest errors to catch”), de lister toutes les hypothèses que l’on devra confirmer avec le client, de poser les livrables, de développer un plan de communication agence-client et de définir un process de review.

Il manque quelque chose? Oui, bien vu. Il manque aussi les risques. Ceux que l’on oublie trop souvent bien qu’en les ayant toujours en tête. Et bien c’est le moment. À cette étape il est tout indiqué de les mettre en avant, pas juste pour avoir l’air sympa et être transparent envers le client ou pour - à l’inverse - ne pas lui faire peur, mais simplement pour élaborer un plan si ces risques venaient à devenir une réalité. Les plus connus sont: les retards de livraison de contenu, de feedbacks et aussi des pré-requis au projet incomplets ou inadaptés.

Et voici à quoi ressemble le premier document, soit le “Management Plan”/ Cheat sheet #1" (télécharger tous les visuels présents dans le livre). Cette structure de document est la même pour toutes les “Cheat sheet” présentées.

7. Project Definition

If you were building a house, would you start nailing two-by-four together without a blueprint? Let’s hope not

Vous l’aurez compris, il faut des étapes ;)

  1. Définir le pourquoi du projet, ses objectifs et comment les atteindre → Place au brief de stratégie et d’expérience utilisateur → “Cheat sheet #2

    Ici deux phases sont déterminantes pour accomplir un travail de qualité:

    1. Auditer le paysage actuel (contenu, fonctionnel, technologique, ainsi que procéder à des interviews, tests utilisateurs ou questionnaires).
    2. Déterminer où le projet va aller. Et ceci ne peut être déterminé qu’à la suite du point 1 ci-dessus. C’est ici que les buts, les stratégies et les tactiques vont êtres posés.

    Fuzzy metrics ARE OK. Sometime goals will not have quantifiable metrics. Take this goal as an example: “We want our employees to feel good about using the new website”. That’s a valid goal, but it has to be measured qualitatively.

  2. Bouger du brief pour arriver au PLAN.

    Ici, 3 phases (toujours déterminantes n’est-ce pas, tout est toujours déterminant)

  1. Coordonner et modérer les membres de l’équipe.

  2. Compléter le document “Cheat sheet #3 - High-level Content strategy & Information architecture”. Ce document parlera du sitemap, des user flows et bien sûr des wireframes.  

  3. Compléter le document “Cheat sheet #4 - Requirements Definition ("RD")”. Celui-ci traitera quant à lui de la production, des technologies et de la sécurité. Sans oublier… les features.

    Beware: It’s easy to lose your client at this point in the project. Make sure they understand why the RD is important. Encourage your technical team to write the RD in a way that’s accessible, and present it in an engaging way.

  4. Recommander une solution et l’estimer. Puis préparer l’accord et le présenter → “Cheat sheet #5 - The Development approach, aka The Agreement”.

8. Project Production

This is when we start making stuff. Content! Design! Code! Whee!

Dans cette phase du projet tout devient plus critique. Il est rappelé à juste titre que les détails peuvent potentiellement et facilement se chevaucher, se heurter où on peut juste totalement passer à côté.

Donc attention! Exécuter un plan est bien moins facile que le monter.

Il va donc être ici discuté des points suivants:

  1. Le parfait project manager. C’est bien sûr cette phase qui est la plus challenging pour le PM. Beaucoup d’activités et de corps de métier se mélangent et les livrables doivent s’aligner exactement pour les uns et pour les autres. “No pressure, though. It just has to align exactly”. Être partout et tout savoir.

    RE-tasks: reviewing, recapping and re-meeting ensure that the team is on track. And refamiliarizing the team with the documents and scope directly affects the accuracy of the proceeding work. The cost of doing this early on pays off in having fewer “re”s later - like reworking, revising or regretting.

    On nous parle de re-kickoff interne aussi, de planning (attention les dates les plus importantes à poser envers le client sont celles de sa revue et de ses validations), de coordination entre les équipes et bien sûr de review internes. Ah et n’oubliez pas de tenir vos documents, tous les documents, à jour!

  2. Le frontend. C’est maintenant que l’on fait évoluer les plans élaborés vers un produit utilisable. Mais d’abord parlons du contenu. Le contenu ne s’arrête jamais, il est donc primordial de définir une stratégie de contenu → Cheat sheet #6. Parlons aussi de l’IA (Information Architecture) et du RD (Requirements Definition). Il est ici aussi primordial (tout est primordial) de ne pas oublier de les comparer, et de ne pas laisser une feature s’infiltrer dans l’IA qui n’aurait pas été définie dans la phase de RD. Et parlons évidemment de design. Le livre n’a pas pour but de nous apprendre à en faire, mais nous rappelle les bonnes pratiques, que vous, web designers, connaissez bien (sites d’inspiration, moodboards, styleguide) → Design concepts - Cheat sheet #7.

    In interactive projects, design implies functionality. In other words, the design must indicate which elements are interactive properties, suggest the outcome of interacting with those elements, and deliver on that promise to the end user.

    Attention chers PM, le design est quelque chose de très émotionnel, donc on peut vite se perdre et faire plus de rounds que prévus, faites gaffe à votre budget :) Mais pensez aussi à définir le nombre de rounds dans le scope de départ.

  3. Le développement. Et c’est parti pour le code. Et c’est aussi parti pour le plan de production et de développement → Cheat sheet #8 (+ Cheat sheet #9 et #10) Vous le savez certainement, il existe du frontend development. et du backend development. Le frontend est le point de convergence du contenu, du design et du backend dev. Voir aussi la Cheat sheet #11 et #12. N’oubliez pas ici de tester, tester, tester. Tout en gardant à l’esprit que “no code is bugfree. Schedule and plan for bugs”. Aussi faites des points réguliers, pas seulement entre développeurs et PM (Project Manager) mais aussi avec le reste de l’équipe ayant travaillé sur le projet. Il est facile de se perdre, d’aller dans tous les sens et d’arriver vite à ce stade.

Pour conclure ce chapitre:

  • The production stage is about maintaining a delicate balance of all the project factors: individuals and expertise areas, planning and executing, and initial ideas and new developments.

  • The Project Manager manages like a maniac during this stage. She reviews, assesses, analyzes, thinks, communicate, and she has countless - but well-managed - meetings. She keeps everyone on the same page, monitors the project’s progress, aligns teams and deliverables, and does this all with the smile.

9. Project Staging

The dress rehearsal

Il est venu le temps d’avoir un produit “prêt” avant publication ou en tous cas prêt pour le dernier fine-tuning avant publication.

  1. Le contenu. Le client devra bien sûr et enfin livrer le contenu “définitif”, tout au moins le contenu définitif pour publication (→ Cheat sheet # 13)

  2. Je teste, tu testes, ils testent… → Cheat sheet #14. La phase de test n’est pas à considérer comme une garantie, attention. Son besoin et son but dans les projets digitaux sont totalement différents des autres médias. Si l’on prend l’exemple d'un spot TV ou d'une annonce print, cela ne changera pas une fois validé. Ceci n’est pas du tout vrai pour les médias digitaux. La vitesse de connection, le browser, les plugins, etc sont autant de facteurs qui influencent un produit digital. La phase de test est donc importante afin d’établir que le produit va fonctionner dans la plupart des cas et non dans tous les cas. La phase de test n’est pas une grande et belle phase qui se produit en une fois. Elle vit tout au long du projet. Le livre nous parle des testeurs à avoir en interne. Pour pas mal d’agences, cela relève encore du luxe et n’importe quel autre dév n’ayant pas travaillé sur le projet pourra faire l’affaire. La comparaison du testeur au relecteur (pour un écrivain) me paraît être une bonne solution. Qui enverrait son manuscrit sans l’avoir fait relire? Personne, voilà.

    On testera pour l’expérience utilisateur, pour la durabilité du produit ainsi que pour la sécurité.

    Voir aussi: → Cheat sheet #15. 

    Le client va devoir être impliqué et tester lui aussi (n’oubliez pas de lui présenter le staging comme un petit bijou  (le site en “staging” étant le site prêt avant publication, celui que l’on ne voit pas encore). Qui dit tester dit aussi savoir donner un bon feedback (subjectif et/ou fonctionnel), n’oubliez pas de le guider.

    Don’t let perfect be the enemy of launch

10 . Project Launch

Launch isn’t the end, it’s the beginning

Cheat sheet #16 et #17

Formation de client, un plan de support si besoin, un dernier check, et c’est dans la poche! (enfin, c’est pas si simple… :))  

N’oubliez pas de créer un “launch day plan” et si votre projet est un gros projet, de prévoir une personne responsable des réseaux sociaux qui escaladerait tout problème reporté sur ces canaux.

Et ensuite… fêtez!

11. Project Closure

That’s a wrap

Le but est de passer du mode “livrable” en mode relation longue durée avec le client.

N’oubliez pas d’organiser un post-mortem en interne ainsi qu’avec le client. Les points négatifs (sans finger pointing bien entendu) devront y être relevés, mais les points positifs aussi. On néglige souvent de les relever et il est finalement tout aussi important de savoir ce qui s’est bien passé afin de le reproduire encore et encore.

Nous sommes donc arrivés au bout de ce résumé (vous me direz 34’675 scrolls, c’est plus trop un résumé, mais bon, disons que moins long c’était un peu dur).

Je ne peux que vous conseiller d’aller voir un talk de ces 2 super nanas qui vous donneront énergie, estime personnelle et empowerment. Désolée pour les anglicismes, c’est pas toujours évident de les éviter.