<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Réflexions d'un chef de projet internet - Julien Dassonval &#187; planning</title>
	<atom:link href="http://blog.juliendassonval.com/tag/planning/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.juliendassonval.com</link>
	<description></description>
	<lastBuildDate>Sun, 15 Aug 2010 12:35:02 +0000</lastBuildDate>
	
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Les plannings imposés par le client, comment s&#8217;en sortir ?</title>
		<link>http://blog.juliendassonval.com/gestion-de-projet/les-plannings-imposes-par-le-client-comment-sen-sortir</link>
		<comments>http://blog.juliendassonval.com/gestion-de-projet/les-plannings-imposes-par-le-client-comment-sen-sortir#comments</comments>
		<pubDate>Wed, 02 Dec 2009 05:51:05 +0000</pubDate>
		<dc:creator>Julien</dc:creator>
				<category><![CDATA[Gestion de projet]]></category>
		<category><![CDATA[planning]]></category>

		<guid isPermaLink="false">http://blog.juliendassonval.com/?p=454</guid>
		<description><![CDATA[Cela faisait longtemps que je n&#8217;avais pas rédigé un article sur la gestion de projet. Place à un sujet délicat à gérer et qui nécessite une bonne négociation, parfois rapport de force, avec votre client.
Il arrive assez souvent cette contrainte, vous recevez avec le brief, cahier des charges une date de mise en ligne. Problème, [...]]]></description>
			<content:encoded><![CDATA[<p>Cela faisait longtemps que je n&#8217;avais pas rédigé un article sur la gestion de projet. Place à un sujet délicat à gérer et qui nécessite une bonne négociation, parfois rapport de force, avec votre client.</p>
<p>Il arrive assez souvent cette contrainte, vous recevez avec le brief, cahier des charges une date de mise en ligne. Problème, après étude du cahier des charges, vous vous rendez compte que c&#8217;est intenable. <strong>Comment faire ?</strong></p>
<p><strong>La première</strong>, la plus intelligente serait d&#8217;arriver à convaincre votre client (avec la réalisation d&#8217;un nouveau planning détaillé avec les validations, temps aller/retours éventuels) qu&#8217;<strong>une nouvelle date doit être trouvée</strong>. Si celui-ci accepte un décalage, le sujet est clos.</p>
<p>Evidemment, c&#8217;est rare&#8230;</p>
<p><strong>Deuxième solution, négocier une mise en ligne partielle</strong>. C&#8217;est le meilleur deal pour votre client qui peut avoir tout un plan de communication déjà lancé, et/ou une contrainte de mise en vente de son produit qui nécessite un relais le jour de la sortie. Il va donc falloir étudier un échelonnement des fonctionnalités, avec une V1, puis V2 voir V3. Tout dépendra de l&#8217;importance du site. Il y a un rapport de force à gagner, pas toujours évident, le directeur de clientèle avec qui vous travaillez devrait logiquement vous aider dans ce travail.</p>
<p><strong>Troisième solution, le mode charrette avec plus de personnes</strong>. Celui-ci, je l&#8217;ai pratiqué pas mal à Publicis Net. J&#8217;avoue aimer ce type de contrainte, c&#8217;est très stimulant pour un chef de projet de réussir à se sortir de ce type de situation. C&#8217;est quand cela arrive trop souvent que ça devient un peu lassant de ne pouvoir consacrer plus de temps pour veiller à une vraie réflexion en conception et un suivi sur la qualité de la production (les petits pixels par ci, par là etc). Je n&#8217;aime pas bâcler le travail, je ne fais pas ce métier pour faire de la quantité mais plutôt de la qualité et tenter d&#8217;innover. Reste que c&#8217;est souvent risqué, un bug imprévu bloquant, un retard avec l&#8217;un de vos prestataires et tout votre dispositif se voit retardé. Mettre toujours plus de personne ne suffit pas. Les plannings sans marge, j&#8217;en ai géré plusieurs. C&#8217;est plus facile à faire quand on s&#8217;appelle Publicis Net avec une force de frappe importante (possibilité de réquisitionner tout votre plateau/équipe des meilleurs éléments, de faire travailler un prestataire un dimanche non stop etc) qu&#8217;une petite agence et il faut en avoir conscience. Réaliser une opération marketing pour Orange, un site pour Disney se gère différemment qu&#8217;un site e-commerce pour un client local. Les moyens ne sont pas les mêmes non plus.</p>
<p><strong>Quatrième solution</strong>, le mode charrette ne suffisant pas, vous allez devoir <strong>battre le client à son propre jeu</strong>. C&#8217;est à dire ? Pour lui (votre client), le seul objectif est de sortir son site à telle date. Dans votre planning sans marge, vous allez imposer à votre client des dates de validation et de retour très courts, imposer une réactivité intenable pour lui comme lui vous impose des délais de production intenables. Autant vous dire que vous allez devoir au début faire beaucoup d&#8217;heures pour le noyer sous des documents de spécifications, storyboard, maquettes, e-mails afin qu&#8217;il soit sous l&#8217;eau et ne puisse valider à temps. <strong>Si la validation client n&#8217;arrive pas à temps une seule fois, vous reprenez la main sur votre plannin</strong>g. Ou alors, cela devient vraiment politique avec l&#8217;intervention de votre boss&#8230; (expérience inside évidemment <img src='http://blog.juliendassonval.com/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' />  ).<br />
Tout l&#8217;enjeu avec cette méthode est donc de le noyer pour obtenir de sa part, qu&#8217;il le veuille ou non, un décalage. Nous sommes des professionnels de l&#8217;internet, nous connaissons notre sujet, les risques de telle ou telle production (utilisation de services annexes avec d&#8217;autres prestataires etc). Le client est rarement expert (ou simplement s&#8217;en fiche royalement tant que vis à vis de sa direction il gagne sa prime de fin d&#8217;année&#8230;) sur ces sujets, bien au contraire. Les responsables web qui n&#8217;ont jamais fais de web, j&#8217;en ai vu et pas pour des petits clients. Affolant.</p>
<p>Il n&#8217;y a pas de recette miracle, chaque situation est unique par la typologie du projet, le budget, les ressources internes, un choix politique interne de votre agence ou non (= perdre de l&#8217;argent, cramer une équipe) car cela fera une belle référence. Ce sont simplement des pistes de réflexions, l&#8217;expérience au quotidien fera le reste.</p>
<p>Et vous, comment gérez-vous ce type de cas ?</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.juliendassonval.com/gestion-de-projet/les-plannings-imposes-par-le-client-comment-sen-sortir/feed</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Planning : savoir défendre ses chiffres en interne</title>
		<link>http://blog.juliendassonval.com/gestion-de-projet/planning-savoir-defendre-ses-chiffres-en-interne</link>
		<comments>http://blog.juliendassonval.com/gestion-de-projet/planning-savoir-defendre-ses-chiffres-en-interne#comments</comments>
		<pubDate>Fri, 13 Jun 2008 12:12:08 +0000</pubDate>
		<dc:creator>Julien</dc:creator>
				<category><![CDATA[Gestion de projet]]></category>
		<category><![CDATA[planning]]></category>

		<guid isPermaLink="false">http://blog.juliendassonval.com/?p=29</guid>
		<description><![CDATA[Une des difficultés en tant que chef de projet est dans un premier temps d&#8217;élaborer un planning de production, mais ensuite le défendre. Si le défendre auprès du client est une chose, vous devez parfois aussi le défendre en interne. Cela vous étonne ?
Et oui, il arrive qu&#8217;un compte soit stratégique pour une agence et [...]]]></description>
			<content:encoded><![CDATA[<p>Une des difficultés en tant que chef de projet est dans un premier temps d&#8217;élaborer un planning de production, mais ensuite le défendre. Si le défendre auprès du client est une chose, vous devez parfois aussi le défendre en interne. Cela vous étonne ?</p>
<p>Et oui, il arrive qu&#8217;un compte soit stratégique pour une agence et on vous demande de faire des concessions, ou plus fréquemment, le directeur de clientèle ne sera pas d&#8217;accord avec vos chiffres. Sauf que bizarrement, quand les délais sous-estimés déjà vendus arrivent en production, on revient vers vous pour sortir un site de 3 semaines en 1 semaine (j&#8217;exagère à peine). Ce qui malgré toutes les bonnes volontés, <a href="http://blog.juliendassonval.com/2008/04/05/etre-charette/">charrettes</a>, ressources n&#8217;est pas possible.<br />
Personnellement, lorsque j&#8217;estime un projet, je sais que je m&#8217;engage sur les dates. Si le projet dérape, cela provient rarement d&#8217;une mauvaise estimation mais de retards en amont (créas qui tardent à être valider, client qui change d&#8217;avis).</p>
<p>Alors, vous devrez aller au front défendre votre planning, faire comprendre que ce que le commercial pense simple, le gardien fou que vous êtes lui explique que non (<em>quitte à devoir hausser le ton</em>). Vous êtes le responsable du projet, sur le planning, sur la qualité (<a href="http://blog.juliendassonval.com/2008/04/27/recette-site-internet/">n&#8217;oubliez pas la recette</a>). Si on vous demande de réduire le planning, alors réduisez le périmètre. Un chef de projet peut (<em>doit savoir</em>) dire non. Chacun son métier, un commercial n&#8217;est pas un chef de projet (<em>même s&#8217;il l&#8217;a été par le passé</em>). Oui, défendre un planning est aussi une bataille en interne parfois.</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.juliendassonval.com/gestion-de-projet/planning-savoir-defendre-ses-chiffres-en-interne/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>Comment chiffrer un projet web en 10 minutes ?</title>
		<link>http://blog.juliendassonval.com/gestion-de-projet/comment-chiffrer-un-projet-web-en-10-minutes</link>
		<comments>http://blog.juliendassonval.com/gestion-de-projet/comment-chiffrer-un-projet-web-en-10-minutes#comments</comments>
		<pubDate>Fri, 11 Apr 2008 06:52:15 +0000</pubDate>
		<dc:creator>Julien</dc:creator>
				<category><![CDATA[Gestion de projet]]></category>
		<category><![CDATA[planning]]></category>

		<guid isPermaLink="false">http://blog.juliendassonval.com/?p=9</guid>
		<description><![CDATA[Parmi toutes les difficultés du métier de chef de projet, il y a celle de chiffrer un temps de conception et surtout production. Le pire est celui en avant-vente ou rien n&#8217;est vraiment encore cadré mais vous devez imaginer ce qu&#8217;il y aura dans le site, comment il fonctionnera.
Tout peut aller très vite parfois, vous [...]]]></description>
			<content:encoded><![CDATA[<p>Parmi toutes les difficultés du métier de chef de projet, il y a celle de chiffrer un temps de conception et surtout production. Le pire est celui en avant-vente ou rien n&#8217;est vraiment encore cadré mais vous devez imaginer ce qu&#8217;il y aura dans le site, comment il fonctionnera.</p>
<p>Tout peut aller très vite parfois, vous recevez un coup de fil d&#8217;un directeur de clientèle à 18h pour une présentation le lendemain matin, voici un JPG (dans le meilleur des cas), combien de temps il faut pour le mettre en place ? J&#8217;ai eu la chance de faire des études multimédia qui m&#8217;ont permis de faire la production (intégration, développement, graphisme etc) ainsi que du freelance. C&#8217;est vraiment important pour moi qu&#8217;un chef de projet (technique ou fonctionnel) garde cette capacité de participer à la production, avoir conscience de la réalité pour développer un formulaire, intégrer une page, un mail etc mais aussi en terme de faisabilité du projet.</p>
<p>Combien de projets ai-je vu vendu 2 semaines alors qu&#8217;il en fallait 4. Beaucoup trop. Même des charrettes ne peuvent parfois pas faire de miracle quand les délais sont impossibles à tenir.</p>
<p>Si vous ne pouvez évidemment jamais être sûr de vous, l&#8217;idée est de donner des estimations avec une marge de sécurité. Il vaut mieux survendre un projet que l&#8217;inverse. C&#8217;est tout de même rare qu&#8217;au final un projet soit survendu&#8230;</p>
<p>Alors entrons dans le vif de sujet, <strong>comment chiffrer un projet ?</strong></p>
<ol>
<li>Prenez connaissance des éléménts storyboard, créa et des fonctionnalités</li>
<li>Demandez bien des précisions sur les choses dont vous ne voyez pas le fonctionnement</li>
<li>Quelle technologie est employée (html, ASP, .Net, php, flash, papervision, 3d, etc)</li>
<li>Dans votre proposition, redites le périmètre histoire que tout le monde soit d&#8217;accord sur celui-ci</li>
</ol>
<p>Vous avez rarement à ce moment là une arborescence du site, alors il faut réfléchir en terme de fonctionnalités</p>
<p><strong>Quelque chiffres repères pour un site html</strong></p>
<p><strong>Html</strong></p>
<ol>
<li>Intégrer un mail : 0,5 jours</li>
<li>Intégrer un gabarit xhtml (gabarit = une structure unique) : 1,5/2jours</li>
<li>Déclinaison d&#8217;un gabarit : 0,5 jours</li>
</ol>
<p><strong>Php</strong></p>
<ol>
<li>Structure (modélisation bdd, mise en place framework, archi MVC) : 2 jours</li>
<li>Inscription / Connexion utilisateur : 1j</li>
<li>Envoi de mail avec un template (confirmation inscription, rappel mot de passe etc) : 0,5j</li>
</ol>
<p><strong>Quelque chiffres repères pour un site flash</strong></p>
<p><strong>Php</strong></p>
<ol>
<li>Création des services amfphp : 0,5jr par service majeur (c&#8217;est très rapide en amf, ce sont de simples fonction la plupart du temps)</li>
</ol>
<p><strong>Flash</strong></p>
<ol>
<li>Structure (mise en place framework, montage des éléments flash reçus par un DA qui sont rarement optimum pour un développement, les classes principales) : 2/3 jours selon le projet</li>
<li>Formulaire dans flash : 0,5jour à 1jr selon la complexité. Attention, on sous estime souvent les formulaires mais les vérifications de champs etc si elles ne sont pas implémentées dans votre framework prennent du temps.</li>
</ol>
<p><strong>Une chose importante aussi qui se vérifie de projet en projet, ajoutez 15 à 25% de recette selon les risques.</strong></p>
<p>Après chaque projet est unique, il n&#8217;y a pas d&#8217;intérêt à lister d&#8217;autres points ici. D&#8217;autres facteurs sont à prendre en compte, taille du site (il est plus facile d&#8217;estimer un projet de 10 jours que 60), l&#8217;expérience avec ce client (change d&#8217;avis jusqu&#8217;à la veille, trop de temps pour validation) etc.</p>
<p>Certaines fonctionnalités reviennent régulièrement, vous avez vu combien de temps il fallait pour les mettre en place sur d&#8217;autres sites.<br />
Evidemment, ces chiffres sont vraiment à prendre comme des grandes masses, selon les éléments du projet, le background que vous avez avec ce client (sur les dérapages etc). Certaines tâches seront sous-estimées, d&#8217;autres sur-estimées mais vous pourrez avoir une vision globale du projet, ce qu&#8217;on recherche dans ces phases d&#8217;avant-vente.</p>
<p>Dans la majorité des cas, ces repères me permettent d&#8217;estimer en 10 minutes un projet, savoir si le projet prendra 2 semaines ou 2 mois de production. N&#8217;hésitez pas à soumettre vos premières estimations à vos développeurs qui de toutes façon sera nécessaire une fois que le client aura acheté l&#8217;idée pour établir le planning final. Vous êtes la personne qui délimite le périmètre, met en place ce planning de référence. Mais pour le fine-tuning, rien ne vaut l&#8217;appui de vos équipes.</p>
<p>Et vous, comment faites vous ?</p>
]]></content:encoded>
			<wfw:commentRss>http://blog.juliendassonval.com/gestion-de-projet/comment-chiffrer-un-projet-web-en-10-minutes/feed</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
	</channel>
</rss>
