 Je pense qu'on peut commencer, donc merci d'être ici. Mon nom est Mathieu Groh, je suis le CEO de Actancy, mais nous allons l'introduire en plus tard. Tout d'abord, l'objectif de cette présentation est de vous donner les clés de notre méthodologie que nous avons créé durant les 7 dernières années et qui sont dédiés aux accounts key. Et surtout, nous allons répondre à la question de comment s'assurer que l'on fasse de l'argent dans notre organisation. Donc, comme vous pouvez le voir, j'ai un accent frère, donc c'est pour ça que Yolaine parle beaucoup et je vais m'aider. Mais vous devez le voir, c'est mon bon accent plus tard. Yolaine. Merci. Bonjour tout le monde. Mon voix est un peu brûlée, j'espère qu'on va pouvoir le faire jusqu'à la fin. Nous allons d'abord parler des misconceptions les plus commones que vous pouvez trouver par rapport à tout ce qu'il y a à faire avec le projet de management. En général, c'est important que vous soyez habitués à ça. Comme Mathieu a dit, nous allons l'introduire rapidement. Et puis, nous allons entrer dans le détail de l'organisation que nous avons trouvé qui a pu travailler dans nos projets pour des grands accounts de key, donc le focus sera sur ce genre de projet plus spécifiquement. Et puis, nous allons aller à la stratégie planée que nous avons implementée avant de concluter cette session. Bonne journée. Ok, je commence. J'ai voulu commencer avec cette étude publiée trois mois plus tard par le groupe de standard et nous avons découvert que la grande partie des projets n'est jamais accomplie. Et cette charte montre la vraie probabilité de succès au projet IT. 52 % sont complétés, mais avec un grand accès au budget et au délai. Finalement, seulement 16 % sont correctement achievés si on s'occupe d'une grande compagnie, seulement 9 %. Donc, il y a un problème dans notre profession, spécialement pour le management des accounts de key. Dans ma opinion, l'agency est trop concentré sur les skills, c'est important, mais il ne garantit pas d'avoir une meilleure probabilité. Et nous devons être conscients que l'accès de key à l'accès connaît cette probabilité. Donc, ils doivent entendre que vous êtes habitués à manager une méthodologie forte. C'est pourquoi nous avons créé cette présentation. Donc, pour commencer avec les misconceptions que vous entendez le plus souvent, cette diagramme vous montre que un projet de vie est généralement divisé dans deux sites. C'est un peu comme le monde et les gens. C'est le plus bas, et le plus bas. Comme nous le savons, pour ceux qui ont travaillé sur les projets, ou même pour vous, les clients, si il y a certains de vous, tout commence bien quand vous commencez un projet. Les gens sont peut-être sceptiques au début, mais ils sont plus égaux et plus égaux et fantastiques pour commencer le projet. Mais le projet fait du temps. Les gens ne voient pas les résultats immédiatement. Il y a beaucoup d'involvements. Et parfois, les gens font des questions sur ce qu'ils font et ce qu'ils font. S'il vous arrive un point dans votre projet quand vous commencez un tract de votre timeline. Et c'est quand votre organisation commence à souffrir, parce que la solution que la plupart des organisations ont fait, c'est généralement d'asker les gens à travailler les jours et les nights et les week-ends, à manger les pizzas devant leurs compétences, pour faire le travail au final de leur projet. Mais, après beaucoup de travail, beaucoup de hard work, quand les gens ont parfois été combattus, vous pouvez voir les résultats de votre projet. Le temps de beer n'est pas si loin, donc les gens sont plus heureux. Mais, vous n'avez pas que 1 beer, parce que vous avez réveillé et que vous avez reçu de l'argent. Donc, nous avons demandé comment évoquer cela. Finalement, c'est notre probabilité de succès d'aujourd'hui. Donc, notre goal est d'augmenter votre propre probabilité de succès. Et, s'il vous plaît, nous continuons à tourner nos méthodologies depuis 7 ans. Donc, ce n'est jamais fini et nous pouvons continuer à discuter d'aujourd'hui. Nous allons faire des promesses qui vont vous sembler une grande promesse, mais c'est en fait ce que nous sentons en parlant et en partagant aujourd'hui. C'est que, sur un grand quiocan et de n'importe quel projet en général, avec Drupal, vous pouvez avoir plaisir en travaillant. Vous pouvez continuer à délivrer une qualité dans les lois tight, afin de éviter la bankruptcy, parce que c'est ce qu'on est tous en train de regarder. Donc, comment nous allons faire ça ? Tout d'abord, nous allons introduire nous-mêmes rapidement. C'est vrai ? Oui, donc, comme je l'ai dit, je suis le fondateur et le CEO d'Actancy, donc je suis Young, enthousiastome Drupal, et mon rôle opérationnel est d'être le direct direct de Drupal. Et c'est pourquoi c'est une bonne chose qu'on présente ensemble cette méthodologie. Bien sûr. Je suis Violène et je suis ce qu'on appelle le project fonctionnel. Je vais revenir à ça plus tard, parce que nous faisons une différence entre un techniciel PM et un fonctionnel qui je suis. 28, même plus jeune. Et je peux maintenant dire que comme project manager, Drupal a sauvé ma vie. J'ai été management des projets pour les derniers 7 ans maintenant et plus spécifiquement sur Drupal depuis deux ans maintenant. Le moyen de travailler avec Drupal est vraiment différent et il fait les choses plus facile pour le project manager que je vais vous montrer aujourd'hui. Ce que j'ai écrit ici me semble important que je suis un grand projet spécialiste. C'est juste que j'ai commencé 7 ans auparavant avec des projets plus spécifiques que les projets que je ménage maintenant, ce qui ne veut pas que c'est plus facile de ménager. Ce n'est pas le cas que le projet soit plus facile ou plus difficile. C'est la picture de notre organisation. Ce n'est pas... Le but ici n'est pas de vous montrer comment on s'est organisé ou qui nous sommes exactement. Mais vous pouvez prendre votre propre picture et c'est un autre misconception que nous avons généralement quand nous parlons de projet management, c'est que nous pouvons trouver un client avec une petite précision qui est en termes de workload un projet qui est estimé à plus d'un millon d'euros. Donc ça commence à être un projet important. Et dans ce monde pour nos clients internet c'est facile et facile et c'est even fun. Le projet de management c'est une pièce de cake. Mais ils ont toujours des lignes très courtes. Ils ont toujours des choses très demandées. Donc la première chose à prendre la pression est mon bus N plus 1 qui est près de moi. Ce que nous pouvons avoir dans les organisations classiques c'est que normalement quand la pression vient du client c'est qu'il s'agit d'un projet de management. Je suis devenu une sorte de malin et je spreading la pression par l'organisation. Et c'est vraiment ce que nous voulons évoquer. Donc nous avons travaillé pour les dernières années sur une méthodologie pour trouver des solutions pour que nous pouvons évoquer la majorité du projet pour être la seule à prendre la pression et à la spreading pour que nous puissions avoir des ennemis. Donc après ces dernières années c'est ce que nous avons un peu de l'amour et de la magie. C'est pas si merveilleux. Plus sérieusement nous avons pensé d'une organisation parce que vous ne pouvez pas établir une bonne méthodologie sans penser sur comment réunir vos gens tous ensemble. Dans un groupe vous devez savoir on peut déjà savoir que nous l'avons identifié plus que ça. Mais nous l'avons compté de 18 à 20 différents profils qui peuvent être réalisés par une équipe du Drupal. Vous avez probablement déjà entendu d'un projet technique un développeur un architecte du Drupal un administrateur système des constructeurs etc. Comment choisissez-vous qui sont-ils ? Nous avons travaillé ensemble et vous ne devriez pas oublier que sur ces types de projets en front de ces 18 à 20 profils vous avez pas seulement une personne vous trouvez une personne qui est le project manager sur votre client-side mais il est entouré avec parfois 10 à 12 différents équipes vous pouvez entendre parfois des équipes de business, de hosting d'organisation, du client-side du client-side etc. Donc, souvenez-vous 18 à 20 différents profils en face de 10 à 12 différents équipes Comment vous faites ces personnes travailler ensemble qui devraient en parler avec qui ? Et sans avoir un grand malade. Donc, c'est pourquoi nous avons commencé à penser comment vous synchronisez ces personnes-là ensemble pour que vous puissiez atteindre un objectif qui est votre timeline du budget et du scope parce que les plus de gens, les plus de l'argent d'habitude, et c'est faux, nous allons vous présenter. Vous commencez d'organiser votre équipe de client-side donc ça commence avec une équipe de purchasing de hosting, de hosting, de marketing, de content owner, de business team, sur les autres côtés, sur lesquels ils sont allés par leur directeur de sales. Là, vous voulez mettre bien sûr, le comité de management project qui est organisé avec le project manager sur le client-side qui va évidemment communiquer avec le SPOC, qui est un autre de mes names. Je suis un seul point de contact, mais je ne suis pas le seul. C'est juste que je suis la principale chaîne de communication dans laquelle le client va passer si il ou elle veut travailler avec le reste de nos experts. Et bien sûr, cet équipe est sur le project directeur. Je ne suis pas seul là-bas. Je travaille avec le premier état de protection et j'utilise la protection et je vais retourner à ce concept plus tard. Je travaille avec ce qu'on appelle le comité de management un CTO et un CMO ou directeur créatif. Et sous le CMO vous trouverez l'architecte d'information qui lui-même va coordonner le travail de web-designants et de thèmes. L'architecte d'information est un de les profiles les plus importants que vous avez dans votre équipe. Mettez ça en main et pourquoi est-ce que ça? Parce que je ne sais pas si vous voyez la couleur de l'arrivée entre le project directeur et l'architecte d'information. Mais ces deux profiles différents votre travail est un project directeur qui va s'assurer que ces deux gens aillent beaucoup avec eux et qu'ils travaillent tous les jours dans votre projet. C'est fundamental si vous voulez avoir du succès dans votre projet. Sous le project directeur qui lui-même est assuré par le comité de management et le CTO vous trouverez l'architecte, l'administration du système et les développeurs de front-end, de back-end et de builders. Je ne sais pas si c'est très clair si vous êtes dans le back-end. Excusez-moi? Vous voulez me définir le comité de management? Le comité de management est celui qui va planir mais pas seulement ça, il n'y a pas seulement un planer le team technique il va être celui qui va faire sure que le whole team technique est commis pour différents tasks qu'ils ont à faire. Je vais retourner au comité principal après ça. Mais prenez en compte qu'il est un safeguard pour le projet de management fonctionnel et pour le projet de management technique aussi. Est-ce que ça va être un peu plus clair? Oui. Une autre façon pour le mettre, si c'est peut-être plus visual, plus understandable c'est ce qu'on appelle le cercle virtuel. C'est ce que cette gouvernance nous a aidés à faire. Comme je l'ai dit avant, la plus importante team est là. Le diagramme que vous avez vu c'est vraiment un diagramme de gouvernance. Ce n'est pas un diagramme hierarchique, c'est un diagramme de communication. Bien évidemment c'est la plus importante team et les gens sont là. Tout le monde est important dans la team mais sans la team courte il n'y a pas de projet. Il n'y a pas de production. Et là je parle de les devs, les architectes, les développeurs, les constructeurs et les constructeurs. Évidemment, vous voulez qu'ils travaillent dans un environnement calme et safe. Comment faites-vous ça? C'est pourquoi je vais retourner au concept de la protection de la team courte. Vous avez ce profil que nous avons entendu avant. Qui est le premier guide de protection? Qui est le manager du projet technique? Il est le seul qui communique directement avec la team courte. Et c'est vraiment important parce que vous voulez éviter la team courte d'être déterminée par les emails et trop de communication pour aider le manager du projet technique dans la team courte. Vous avez ce que nous appelons le shield. Et le shield est fait de différents profils que nous avons vu avant. Vous avez le directeur du projet, le manager fonctionnel, le manager committement, le CTO. Les différents arrows dans lesquels ils représentent que tout le monde a un safeguard dans un projet. Personne n'est déterminé dans l'organisation. C'est-à-dire que le directeur du projet est là pour s'assurer que le manager fonctionnel ne rencontre aucun problème avec les clients ou la team courte. Le manager du projet technique est là pour envoyer des messages warnés pour le manager committement, pour le CTO, quand il a besoin d'aide technique sur la stratégie, quand il a besoin de plus de ressources, il va au manager committement, quand il a un problème avec le déti de Redet 9, il vient de moi et on va essayer de trouver des solutions, ensemble. De cette façon, le soutien mutual est promos dans tous les membres de la team mais aussi pour l'efficacité, d'ailleurs. C'est aussi une organisation qui m'emmène d'actuellement aller sur les holidays de temps en temps, sans avoir peur d'être transformé en un bonhomme quand je reviens. C'est vrai que c'est vrai, parce que j'étais en train de faire un projet, la whole team continued working. C'est pas qu'ils n'aient pas besoin de m'aide mais il y a plusieurs profils qui ont took my part during the summer and it all went well in the end. Once you set up this organisation and made it work you can actually add another project manager. It's just a diagram that's going to be repeating over and over again as long as you make sure that this governance that we saw before and that the virtuous circle is working well. So you really need to make sure that people and that's the basis of everything that people really do communicate well with each other, that the warning messages really do come and get through the core team through the technical project manager through the last layer of the shield. As a conclusion of this slide we can say that the core team this is the team that has the power because you trust your experts and you're not going to doubt their workload estimations, their expertise but it only works if you actually enable them to have this power so if you empower them if they were able to commit themselves to such workload estimation it doesn't work one without the other. To make it clear we're going to enter some planning strategy phase. There you can see we divided the project life cycle into seven different steps. So again we are not there today to teach you any new revolutionary method or whatsoever but really basically to say that we found solutions that have been working and there might be more steps than these seven there but for us it's really the most important phases that you can find. So we go from the purchasing to the implementation inception phase functional technical conception and then production and testing strategy until the end. I won't go into the details of the phases that you see which are the recurring phases on the left. Those are weekly meetings and monthly steering committees that you can put in place. This is not going to be what I'll be talking about today nor on the right side of the trunk. So Mathieu will be introducing the first step because it's more his expertise in a project which is then the purchasing phase. Just because I have also the responsibility to sell the big projects to key accounts. So I consider that the purchasing phase is the first step of the project. You give the keys to the project manager. So I recommend to respect some important points. First phase is to provide a business case to your client. So that's a pre-sales phase. This business case is just a document containing all the main aspects of your organization de preference, de methodology, etc. And it's very important to include a TOC. A TOC, Total Honor Cost is an addition of all the cost of your project on two years. Hosting maintenance license, if you want to compare with another technology and that's very important. By instance this year we make the comparison between Oracle and Drupal and we make the demonstration to a client that he could save until 40% of his budget on two years by choosing Drupal instead of Oracle. So this document is very good for Drupal. But after that there are POC proof of concept phase so Drupal has a lot of standard modules so it's easy to demonstrate out of the box functionalities and key accounts love that but you have after that to forecast your provisional budget. And there is an issue there it's not possible to manage all the variables at this step you don't know a lot of things you have to organize workshops so you have to be optimistic at this step and to write all the constraints in the contract so in the SOW and this constraints list is the keys that you provide to your project manager this is the most important point in this slide to remember and after that of course you have to wait the purchase order so but it's important to write in the contract all the constraints and after that the project manager can take the project so at this point as much you just said you don't have much when you start such a project as a project manager you only have 3 keys to play with the project the second one being the list of your clients constraints and you've got an implementation architecture what are you going to do with that and how are you going to play with that well your goal is to identify all the variables that you will be able to work with and for every single of these variables define a solutions find all the alternatives to be able to offer to your clients and in the end be able to confirm or sometimes unfortunately maybe for the client update the budget because I don't know if you really got it but at this point after the purchasing phase it's such a huge project that there are lots of things that were impossible to anticipate and to estimate so the goal there you're going to have to enter 2 validation tunnels the first one being the marketing workshops and there you'll be talking about site map content types volume of data regarding the marketing site that could have some impact on your planning or on your budget or on your scope second validation tunnel is the IT workshops you're the same we'll be talking with the client's teams about SSO adapte connection performance network third part integration system API and so on all these topics can have a major impact on both your scope of course budget then and as a matter of fact planning once this is done when you're able to start setting up a good project governance and organization by planning the weekly meetings and tools and so on but most specifically this is exactly the moment when you know how you will have to arbitrate with your client on what's going to be what will take part of your scope and what will have to be out of your scope once this is done and the road is a little bit clearer you're entering the functional conception phase the most important thing and really I'm insisting on this point is to have the internal kickoff before going to your client because this is the first time in the project when you'll be talking directly with your experts the information architect, the CTO the technical project manager these people will be able to tell you what you should be negotiating in terms of planning with your clients what package of development is more interesting to launch before another one and they will bring points of attentions to you that you hadn't seen maybe before and it's very important all this you're going to be talking about with your client during the client kickoff and there you start as an iterative so this is how we work you give your the project manager gives the information architect kind of a smart route plan which is for every single workshop a detailed scope of what the information architect should be working on with his clients of course this is exactly when you should be encouraging both of them, client and information architect to use full standard Drupal functionalities maximum and then you enter the cycle what's important to notice there is that the workshops will enable the information architect to start talking to the technical project manager so this is when these two actually meet and never leave each other until the end of the project this cycle here is very efficient in terms of how to detect any scope changes it allows you not to wait till the last minute of the conception phase to notice that the client has been requiring a lot of things that were actually not included in the scope you can detect these requirements after every single workshop because once the information architect goes out of a workshop he talks with you and he talks with the technical project manager making sure that everything was first included within the scope and is going to be feasible technically using full standard Drupal applications if not, if something comes out of the scope then it's early enough for you to go to your client and start arbitrating and say well, if you want this it's going to require maybe un scope or maybe an additional budget and deadline so yeah, this is what you should keep in mind always try to push out of the box modules and remember that actually 90% of a project could be created with standard modules going custom is not a necessity always so as I said before in parallel of the functional strategy your technical project manager already starts working so that at the same time as your information architect is writing the functional specifications you've got the technical pair who's writing in the technical strategy and technical specifications too so that when you arrive at the end, at the steering committee with your clients the point of validating wireframes ready design ready, functional and technical specifications done keep in mind that at this point when you validated the specifications on both sides any single modification implies a negotiation on the scope or on the budget the advantage with Drupal is that even if you've got some issues because the solution that you imagine first will take too much time or is too expensive whatsoever there are several ways to reach the same goal with Drupal so it's also up to you to challenge your experts and try to make them find other alternatives and then offer them to your client another good thing to keep in mind at this point is that you can have and we really do recommend to get your specifications validated by Acquia why should you do that because you want to get some kind of credits and quality label on your specifications so that you will avoid any potential judgements from your client once the project reach not a crisis point but some difficult phase so don't rest too soon because you just got started you might think that it's an exception phase a really detailed kind of detailed purchasing phase then an exception phase with architects with technical project managers we talked about CTOs I mean that's a lot of people involved right but it's not the end of your problems because you're gonna meet what we called the project manager I mean the first there are like kind of two biggest enemies to avoid but please meet the ostrich everybody is familiar with what we call the ostrich effect or not no well it's pretty simple it's like when you bury your head into the sand for many reasons there are many reasons for that what are they actually because you're of good will it's not that you don't want to see the problem is that you're not denying that there's a problem but you wanna do so well that you will make sure that anytime in any situation you will manage to to handle them to fix every problem that you have the second reason for the ostrich effect is the fear I mean the most organizations people are afraid of pressure or judgment so they tend to deny the problems right they hide it under the carpet and third reason for that is actually self confidence because well you think about that problem but you're like well yeah it's fine I mean I know how to take care of that and it's okay it's like a retarding bomb as a project manager you're facing the ostrich effect every single day and it comes from every single of your team members it's not their fault keep on loving them but it's a very it's a very very hard enemy to fight how do you fight it actually well first by trusting the expert the expert knows better than you I mean you are not as a functional project manager you're not a Drupal architect you're not a site builder you're not an information architect second solution for that is to never take it's fine I'll take care of that I'll fix this as an answer because it's not a good answer so instead look for pragmatic answers how do you do that well just ask pragmatic questions such as did you have did you receive written specifications have you read them did you list all the tasks that were yours to realize and complete did you actually estimate the workload for every single of these tasks that you will have to complete and so on once you've got all these answers from the expert you're like alright well you said that this task is gonna take you ten days I trust you with that but then do you commit yourself that it's really a safe workload estimation and this is when the commitment starts so I give you the power to say that and I'm not gonna doubt that this task is really gonna take you ten days but then don't mess up with me and don't make it fifteen days and commit yourself so that's the empowerment situation a fun fact or maybe not depending it's that based on our statistics unfortunately the ostrich effect actually doubled the budget and to three projects that we had it was really tremendous effect so learn how to identify the ostrich and then kill them all alright now that you know who your enemy is you can enter safely the production strategy phase it's the same way as the functional conception phase this phase will be iterative right so if you know the scrum methodology it's pretty similar because we will be able as soon as one functional package is validated and we've went to the end of it we'll be able to launch a package of development the matching one of course so you wanna make sure that your technical project manager first issues a really detailed route plan for every of the developers who are gonna be working on this package of development you wanna be looking for the commitments before starting anything don't wait until like half of the developments are done before wondering well if I asked them if they were actually sure that the development would take 10 days because then you're in danger so ask for the commitment before starting but no worries for the developers if they are in the room I know they are my colleagues but I don't know about you others you can still cancel and that's the magic of this organization is that you can still cancel a commitment I mean everyone is allowed to make a mistake to get wrong with an estimation it's really a hard task to estimate a workload precisely the only golden rule there to remember is that cancel your commitment halfway don't wait for the sake of the project manager don't wait until the end like the last minute to cancel your commitment because then it provokes a huge crisis obviously don't wait for the day before the delivery to say that you're not gonna be able to make it a good thing to remember is that this is the time this is the exact time when you should be creating your test plans because you will have to kind of educate your client to the idea that the test plans will be replacing at this steps the specifications that you validated cause test plans there are those scenarios that will enable your client and yourself to check and make sure that everything that was validated before was implemented and works well so the test plans at this point really become your referential and they replace the specifications keep that in mind for the the end of the cycle but don't run away too fast because you are not done yet almost it's long project life cycle takes long you're entering the testing strategy phase there are two sub phases in the testing strategy phase first the internal strategy the internal testing and then the external testing obviously you won't be delivering a project that hasn't been tested and validated before to your client this is when your second biggest enemy as a project manager and as a whole team comes up they are the regressions it's very important to not deny them because they exist and you have to work with them so this cycle is pretty simple you created the test plans before so now you're going to execute all the tests and then the functional project manager which I am will be qualifying every of these tickets giving them priorities and maybe identifying some tickets as evolutions or as real box to correct the technical project manager then will be estimating the workload for every single ticket that was created which is very important because then of course the core team will be resolving and testing again the tickets but the workload estimation is very important for your technical project manager to be able to issue everyday a report for which we will see an example of it later on but this report will tell you exactly how many tickets were created the workload that was estimated to treat all these tickets all together and this is when the technical project manager will be asking the commitment manager and the functional project manager to add more people because the workload estimation was actually too important or it doesn't happen so often unfortunately but it can ask for the bandwidth what we call the bandwidths how many people can treat how much workload to be reduced it becomes then it's in the hands of the commitment manager to either reinforce the bandwidths or reduce it reducing it is is not always easy for him but it's actually a little easier still than reinforcing it because when you arrive from one day to another to your commitment manager with kind of a crisis situation requiring 15 more people and you want them in the morning then you're pretty sure he's going to spend a good night but it's not your problem anymore that's also what you realize that thanks to Drupal it makes it easy to involve big teams from one day to another because the only problem that the commitment manager has to do then is to find the people but apart from that you can really add and I'm not kidding that's what we've been doing sometimes it happens that we needed from one day from one week to another a bunch of 10 more guys to respect our deadlines but be able to treat all the workload he was able to do that so it's good for him to have a communication on your ticket then you can involve builders, themers Drupal architects on more complex architectures and so on and have them all work together without disturbing the global project so this is an example of the report that our technical project managers can give us every day as soon as you start entering the testing phase what you want to require from your team from your technical project manager this is the only way that you can control what's going on and that you can make sure that you will be delivering a project on time why is that because I don't know if you see that well but in the first column there you have the bandwidth so that's pretty much how many people how many people were planned so far so as an example I took the date of the 17th of September on a project that we were testing we had 14 hours that were planned so it's two mandates we had two people available by then we had a number of 22 tickets left to complain sorry the workload was estimated to 25 hours so in other terms we couldn't make it when this happened the technical project manager the commitment manager and I we met had a nice chat and I asked the commitment manager to provide double the time that was actually estimated and that's our recommendation because when you have 25 hours estimated on tickets that are already created don't forget about your second biggest enemy which are regressions you wanna make sure that you'll have enough time to treat them all then for this example you'll be planning 50 hours so he had another quiet evening then when I asked him to find so many people from one day to another because we hadn't planned the project would extend further than the 20th of September it was a piece of cake once this is done I mean you're almost done but now you're gonna deliver the project finally to your clients and that's a dangerous road I'm not gonna go into details through the cycle again because that's what we've just talked about but I wanna point out the two the two things that I've added above and below the cycle diagram as soon as you enter the external testing phase you should be sending your client a validation report this is the little paper magic paper that you wanna get at the end of your project saying well alright good job you're done, the project's on I'm the client and I'm signing it how do you do that well if you send it to your client in the middle of the testing phase which is a time when the pressure can be pretty intense on both sides it's really not likely that you're gonna get it easily but if you send it to your client at the beginning of the testing phase it prepares him psychologically to the fact that at some point it's gonna end and he's gonna have to send you a report and that it's still gonna be possible for him to list all the things that are still to be corrected even if he signs up the paper and because he has a deadline and the project has to go online in the end you can reassure him and say well at this point that your client will be on his own after the project is online you can still list all the things that you want to have corrected and that's fine it's also very important because this validation report will put will put your client in a position when he also has to get into such a commitment your client has a responsibility in doing so the first one is to promise you that he's gonna execute his tests by respecting two things the validated specifications on one side and the test plans this is how you can make sure that you can keep being efficient during the testing phase and that you're not gonna be debating over problems that are not even problems because you can't be a person in your specifications so this is kind of a rule to respect and second is that he's gonna put him in a position that he will know that from the moment when he signs on the paper any new ticket that hadn't been created before so any problem that hasn't been identified before that will become an evolution so there won't be any correction but you can make sure that the project has a real end so at last but not least if there are three things that you can keep in mind for your project three things that you want to guarantee on your project is the production speed how do you guarantee that well thanks to your technical project manager working together with the CTO on the technical strategy so you want to make sure these two people work together budget and scope thanks to the project manager and project director there are the safeguards on this part and the bandwidth which is the commitment manager's job problem knife so it's thanks to these profiles the different layers of protection that we've been talking about before that you can ensure that your team will work in a safe and quiet environment they won't be polluted by external communication that they don't have to deal with and that you meet your objectives and deadline on time a lot to say on the methodology so we have to to end it took 7 ans to come up with this methodology but it still continuously improving so it's good to know that it increased by 5 our success rate since the beginning and it took 3 years to reach this goal become cost efficient because it was not the case at the beginning clearly we are cost efficient since 4 years thanks to that and to be able to manage the crisis and to keep a fun atmosphere that's maybe the most complicated goals to reach so I hope you can pick something for your own methodology it's done we explain a lot of things and I hope it could be helpful for you and thank you for your patience now if you've got some questions I think we still have time I don't know what time it is actually but we might still have yeah first of all I hope the commitment manager had time to come here is right behind you actually respect to you man yeah give him a big applause thanks for the insight it's very valuable one thing I wanted to know if you hear around here on the floor everybody's talking about Agile and Scrum and all of these more iterative approaches which you clearly are in a waterfall approach is that a particular choice you made I'm not sure I got it so that we didn't go 100% Scrum or why why didn't we go there what are the reasons that you don't adopt a Scrum Scrum methodology that's a good question actually because we noticed that major key accounts our clients are not I'm not really ready I mean that's the reality we understand the benefits of the Scrum methodology but our clients it's still hard on such major key account projects like more than 1000 main days they the most recent example came up like 3 weeks ago it took us 2-3 months to actually get what Matthew called the PO the purchase order because we were talking about a forecast budget a forecast planning so there was not anything was not fixed or so in that way it's pretty similar to the Scrum methodology but as long as they could not have the written and fixed promise that we would keep this budget we would keep this planning they wouldn't have they wouldn't have let us start with a project and it's hard for them to it's still hard for them to to to be convinced that the Scrum methodology is actually a good one so you have to commit somehow to the fact that it's going to be an end and that you can communicate already at the beginning of the project on an end date this is basically why but the iterative cycles that we actually go through gives our clients the feeling of agility it gives us a feeling of agility too I mean it's important because our teams don't work in a tunnel in a tunnel they don't have the feeling that they start and that it's never ending until a year later it gives us the possibility to really see the results pretty fast so that's the I hope it was a little bit clearer if not we're still at both 35 by the way any other questions Well if you happen to have any we're on booth 35 we'll be having some some cocktail hour tonight at six if you want and we'll be there till the end of the week basically so I'll be happy to share this little insight with you