Les rémunérations en SSII

A lire sur:  http://www.zdnet.fr/actualites/chiffres-cles-les-remunerations-des-informaticiens-39790458.htm

Recul salaires à l'embauche - Les SSII sont parmi les principaux recruteurs de cadres dans l’informatique. Elles ne sont néanmoins pas nécessairement les plus généreuses (modèle économique oblige) en termes de rémunérations. Et 2012 a été marquée par une stratégie claire de rigueur salariale. Ainsi en ESN, le salaire moyen à l’embauche était de 35,5K€, bien loin des 38K€ de 2011. Le salaire médian était lui de 34K€, soit 2.000 euros de moins qu’en 2011. .

Les salaires soumis à la rigueur - Très classiquement, les rémunérations à l’embauche progressent en fonction du niveau d’expérience. Un jeune diplômé en 2012 percevait ainsi un salaire médian de 30.000 euros, contre 43.000 pour un candidat très expérimenté (+10 ans d’expérience). C'est moins qu'en 2011. Et surtout, les employeurs ont tiré vers le bas le salaire plancher des moins expérimentés, les jeunes diplômés. Pour le 1er décile, la rémunération est de 23K€, contre 25 en 2011 et 28 en 2010.
Et pour maîtriser leur masse salariale, les SSII privilégient en outre, plus que les employeurs des autres secteurs, les embauches de jeunes cadres (moins de 5 ans d'expérience). En 2012, selon l’Apec, Sur les 34.520 recrutements de cadres enregistrés dans l’informatique et les télécoms, 70% avaient moins de 6 ans d’expérience.

Les ESN rogne sur les éléments de la rémunération - Parmi les cadres recrutés en 2011 par les SSII, plus du tiers (37%) disposaient d’une part variable (prime) dans leur rémunération. L’autre composante majeure de leur rémunération était le téléphone portable (36%). En 2012, les entreprises se sont montrées beaucoup moins généreuses sur ces différents composants de la rémunération. Conséquence : 28% des cadres recrutés n'ont bénéficié d'aucun de ces avantages, soit 10 points de plus qu'il y a un an.

Les augmentations de salaires IT

1,8% d'augmentation de salaire en 2013 - En 2011 et 2012, c’est dans les secteurs de l’informatique et des télécoms que l’augmentation moyenne des salaires des cadres avait été la plus faible (0,4% et 0,6%) d’après l’observatoire Expectra. « Un paradoxe quand on connaît la pénurie structurelle d’ingénieurs informatiques et télécoms » commentait Expectra, qui attribuait donc la faiblesse des hausses de salaires aux pressions sur les prix subies par les SSII et au ralentissement de l’activité en 2012.
En 2013, si sur le plan économique le ralentissement est plus significatif encore, la tendance est inversée malgré tout et c'est dans l'IT que les cadres ont bénéficié de l'augmentation moyenne la plus forte (+1,8%). Un changement qui s'explique en grande partie par la forte modération salariale appliquée aux cadres des autres fonctions de l'entreprise, habitués auparavant à des hausses annuelles de 3 à 4%.
Pour Expectra, l’augmentation des rémunérations des informaticiens bénéficie toutefois en 2013 aux qualifications dont le rôle est d’accompagner l’évolution des infrastructures des entreprises, et ainsi en lien avec notamment le Cloud. Architectes techniques, ingénieurs sécurité et réseau se classent parmi les métiers dont le salaire médian a le plus progressé entre 2012 et 2013.

Marketing et DSI pas encore assez copains

http://www.zdnet.fr/actualites/marketing-et-dsi-pas-encore-assez-copains-39794126.htm

Analyse : Marketing et DSI, main dans la main ? Pas franchement de l’aveu même de ces professionnels dont seulement 10% estiment satisfaisante la collaboration entre leurs fonctions. La faute souvent à des déceptions passées, un manque d’agilité et une divergence de vue sur l’utilisation de l’IT.

Par Christophe Auffray | Mercredi 18 Septembre 2013

« Aujourd’hui le marketing et l’IT sont en point tous les matins pour guider les développements, et toutes les deux semaines une nouvelle version sort » témoignait en juin dernier le DSI du PMU, Christophe Leray.
Entre IT et marketing, manifestement, le courant passe. Mais ce n’est visiblement pas toujours la règle selon une étude menée dans 10 pays par Accenture auprès de 400 responsables marketing et 250 responsables informatiques.
Le marketing échaudé par les échecs passés
Seulement 10% d’entre eux « estiment suffisante la collaboration entre leurs fonctions respectives ». Mais contrairement à ce qu’on pourrait être tenté de croire, le principal blocage ne viendrait pas de la DSI.
« Plus de trois DSI sur quatre (77 %), contre 57 % des directeurs marketing interrogés, conviennent qu’un rapprochement entre directions marketing et informatiques est important » observe Accenture.
Les directions marketing ne seraient-elles pas échaudées et la DSI, avant d’espérer une collaboration plus poussée, n’aurait-elle pas déjà à convaincre et restaurer la confiance ? Car l’informatique s’est souvent vue reprocher un manque de réactivité.
Ainsi d’après un livre blanc d’IDC, paru en 2011, la DSI est considérée comme trop technophile, et estimant comme moins prioritaires la flexibilité et la réactivité face aux besoins. De quoi égratigner la satisfaction des directions métiers vis-à-vis de la DSI et décourager en partie les rapprochements.
« Or pour passer dans une relation de partenariat avec les métiers, il faut non seulement parler le même langage, mais surtout aussi parler dans le même temps » insistait justement à ce titre le DOSI de Celio, Laurent Rousset, lors d’une récente conférence de l’EBG.
La DSI un "partenaire stratégique". Un statut qui se mérite
Et ne faudrait-il pas en outre que marketing et DSI partagent une même vision sur les finalités de l’IT ? Sur ce point, Accenture observe que les deux entités ne sont pas nécessairement en phase sur l’usage de la technologie.
« Aux yeux des cadres marketing, recueillir des informations sur la clientèle est la première raison qui justifie leur collaboration avec les services informatiques, les DSI, eux, relèguent cet argument en dixième position sur leur liste de motivations. »
Pour favoriser la collaboration, la société de services préconise plusieurs mesures, qui tiennent parfois du changement culturel, comme par exemple pour le marketing de considérer la DSI « comme un partenaire stratégique », et « pas uniquement comme un fournisseur de plate-forme. »
Parvenir à ce statut, cela ne se décrète pas, mais se gagne par la confiance. Bref, cela prend un certain temps, en particulier dans les entreprises où marketing et DSI sont en froid ou culturellement peu enclins à collaborer.
Sur le plan des compétences, le marketing doit par ailleurs s’intéresser plus aux aspects techniques, pour cela en accueillant dans ses rangs - ce qui est déjà le cas - d’autres profils. Du côté de l’IT, le principal changement (voire parfois bouleversement) à opérer, sans surprise, est de montrer « plus d’agilité et de réactivité face aux impératifs du marché. »

Make Sure Your Team Meets Your Deadlines – Even When the Customer is Not Meeting Theirs

A lire sur: Tenstep

Many project managers face situations where they are asked to meet fixed dates with very little, if any, margin for slippage. It is hard enough to manage the dates on your own team, but sometimes your customers magnify the challenge by not meeting their commitments. For instance, they may not be available when you need them or they may not approve critical deliverables when they say they will. This can lead to more project delays. 

From a project management perspective, you need to proactively utilize risk management, issues management and proactive communication to your best advantage.

• Manage customer deadlines as a risk. Identifying customer responsiveness as a risk allows you to communicate the concern and maintain focus on the risk throughout the project. It also allows you to identify additional activities that will help you manage this risk.
• Manage communication and expectations. Proactive communications will help ensure that your customers understand what is expected of them and the consequences of missing their deadline dates.
• Manage missed deadlines as an issue. If the customers end up not meeting their dates in spite of your risk management plans, then you have an issue that needs to be addressed. Issues management (problem identification and resolution) needs to be performed. You do not have direct authority over the customers, so the issues management process helps you gain more visibility from your manager and the customer managers for helping to resolve project resource problems.

Although it appears that you are being held accountable for customer behavior that is not within your control, you do have control over the processes you use to manage the project. Manage risk, communication and issues proactively and utilize your manager and your sponsor to try to get everyone focused on meeting the deadlines.

Ten Techniques for Estimating Work (Part 1 of 2)

A lire sur:  Method123

Estimating work is a key element of project planning. The following techniques can be used at the project level or activity level, or for any sized work in-between. For instance, an expert opinion can be used to help guide the estimate for an entire project or a specific piece of work.

High-level estimating techniques are typically referred to as top-down. Top-down techniques include prior history, analogy and ratio. Estimates that rely on a more thorough breakdown of the work are called bottom-up. The WBS technique, for example, is a bottom-up technique.

Top-down estimates are typically quicker and easier to put together, since you are estimating at the overall project level. They can also be less precise. 

• Previous History. If your organization keeps track of actual effort hours and costs from previous projects, you may have information that will help you estimate similar new work. In this method, the characteristics of the prior work, along with the actual effort hours and cost, are saved so that the information can be leveraged for future projects.
• Analogy. Even if you do not keep actual effort hours from previous projects, you may still be able to leverage previous work. Analogy means that you find similar projects, even if the project team did not collect actual effort hours worked. For example, let's say a prior project was estimated to take six months and 2000 hours to complete. If the project actually was completed in six months, there is a good likelihood that the project also took approximately 2000 hours of effort.   
• Ratio. Ratio is similar to analogy except that you have some basis for comparing work that has similar characteristics, but on a larger or smaller scale. For instance, you may find that the effort required to complete an office move for the Miami office was 500 hours and that one of the big drivers for the effort is the number of people at the office. If there are twice as many people in the Chicago office, you may be able to conclude the work may take 1000 hours there.
• Expert Opinion. In many cases you may need to go to an internal or external expert to get help estimating the work. For instance, if this is the first time you have used a new technology, you may need the help of an outside research firm to provide estimating information. Many times these estimates are based on what other companies in the industry are experiencing. You may also have an internal expert who can help. Although this may be your first time estimating a certain piece of work, perhaps someone else has done it many times.
• Delphi. The Delphi technique is similar to expert opinion, except that you use multiple experts and try to reach an estimating consensus among them.

If possible, you should utilize multiple estimating techniques for a project, especially if you are using a quick top-down technique. You will have more confidence in your estimate if you use two or more techniques to arrive at similar estimates. 

(Look for the remaining five estimating techniques next week.)

Use These Five Techniques for Managing Schedule

A lire sur: Method123

There are dozens of good techniques to help you better manage your schedule. In this column we will look at five.

Be Cautious About Having too Much Slack in the Schedule

There is only one path through the schedule that does not have any slack or float. This is the critical path and it will drive the end-date. Although every other path in the schedule has some slack, there might be some concern if there is too much slack. “Too much slack” means that the other paths have many long gaps when no work needs to be done. This can lead to a long “skinny” network diagram. The potential implication of having too much slack in the schedule is as follows:

• Many resources are coming and going in and out of the project, and this can cause potential problems making sure everyone is available when needed and for as long as needed.
• If you use the same resources off the critical path, you may have to mix in non-project work for them when they do not have project work to do. You may assign them a few weeks of project work, then find other work for them during the slack time, and then make sure they are available for you again when they have more project work assigned.   
• There may be a lack of urgency on the part of all resources that are not on the critical pathThis can be de-motivating to the resources on the critical path.

Of course there may not be a problem with this occurrence. But it is an area to be aware. 

Be Cautious About Having too Little Slack in the Schedule

Just as there is risk with having too much slack, there is also some risk associated with not having very much slack. If this happens, minor schedule slippages off the critical path could force these paths critical as well. Schedules without much slack off the critical path are at more risk of schedule slippage.

"Just Right" Slack

It would be better if the project schedule could be built in such a way that the non-critical paths were “full but not too full” so that a group of resources could be utilized more efficiently on the project.

Determine if You Will Capture Actual Effort Hours

A very early decision needs to be made as to whether you will capture actual effort hours on the schedule. Capturing actual effort hours requires much more diligence on behalf of the project team to keep track of their time per activity and report it back accurately. There is a lot of value associated with capturing actual effort hours, including helping make future estimates more accurate. Collecting actual effort hours is usually something that is required on an organization-wide basis - not one project at a time.

Enter Work on Your Schedule in Chronological Order

Although schedule activities can be added in any order, it is easier to understand the schedule if you list the activities in chronological order. That is, the earlier activities should be at the beginning of the schedule and the later activities should be listed in the general order that they will be executed.

Tenstep N°188: Démarrage du projet (partie I)

A lire sur: Tenstep

La méthodologie TenStep de management de projet (« Méthodologie TenStep" » ou « "TenStep ») vous enseigne comment gérer (planifier et piloter) un projet de manière proactive. Cependant, cela suppose l'existence d'un projet à gérer. Chaque organisation dispose de procédures (ou processus) pour identifier et autoriser les projets. Ces processus comportent généralement les caractéristiques suivantes :

·         Certains procédés pour identifier tous les projets qui pourraient potentiellement être entamés.

·         Un processus d'entonnoir pour simplifier l'ensemble des projets potentiels dans le plus petit nombre possible qui ont le plus de valeur et qui sont le plus centrés sur les objectifs et les stratégies d'affaires de l’organisation.

·         Un moyen de documenter les coûts et les avantages afin que le projet puisse être comparé à d'autres projets.

·         Ce document est généralement appelé « analyse de rentabilisation ».

·         Identification d'un ensemble de renseignements requis pour obtenir l'approbation finale du projet.

Le processus décrit ci-dessus est employé pour obtenir l'approbation préliminaire d’un projet. Cependant, il peut y avoir un décalage entre le moment où un projet est initialement approuvé et celui où le projet commence réellement. Par conséquent, lorsqu'un projet est prêt à débuter, un certain nombre d'éléments doivent être validés pour garantir que le projet est prêt à démarrer.

Démarrer les projets de petite taille

Ce processus initial n'est pas nécessaire pour les petits projets.

Démarrer les projets de taille moyenne

Ce processus initial est facultatif pour les projets de taille moyenne. Si le projet est assez grand, vous pouvez mettre en œuvre le processus de démarrage conçu pour les grands projets. Sinon, le processus peut être omis.

Terminologie de management de projet

Référence de base des mesures de performances. Plan approuvé et intégré contenu-échéancier-coûts du travail du projet auquel son exécution est comparée pour en mesurer les écarts afin qu'ils soient maîtrisés par le management. Cette référence de base intègre généralement les paramètres de contenu, d'échéancier et de coût du projet, mais peut aussi comporter des paramètres techniques et de qualité.

Représentation en diagramme de flux. Présentation sous forme de diagramme des données d'entrée, des actions du processus et des données de sortie d'un ou plusieurs processus faisant partie d'un système.

Abréviations courantes

RACI (anglais) : Responsible, Accountable, Consult, And Inform

RACI (français) : Responsabilité- Autorité-Consulté-Informé

enterprise mobility management (EMM)

A lire sur:  http://searchconsumerization.techtarget.com/definition/enterprise-mobility-management-EMM

Published: 04 Apr 2013

Essential Guide

VMworld 2013 conference coverage

• This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
  4. - Terms to know at the show: Read more in this section
  • software-defined networking (SDN)
  • VMware vCenter Server
  • Infrastructure as a Service (IaaS)
  Read more in this section
• Explore other sections in this guide:
  • 1. - VMworld 2013 News
  • 2. - VMworld 2013 videos
  • 3. - VMworld coverage on Twitter
  View all sections in this guide

Enterprise mobility management (EMM) is an all-encompassing approach to securing and enabling business workers' use of smartphones and tablets.
EMM typically involves some combination of mobile device management (MDM), mobile application management (MAM) and mobile information management. These three technologies all address specific concerns but do not provide complete solutions to the problems that enterprise mobility can cause or exacerbate. For example, MDM protects against unauthorized device access, but it's powerless if the intended user forwards an email containing sensitive data to an unsecure or malicious recipient.
There's more to enterprise mobility management than security, however. A strong EMM strategy will also help mobile end users work more productively by providing them new tools to do their jobs on smartphones and tablets. Enterprise app stores or other application delivery and deployment technologies are common components of EMM, as are identity management systems to control user access to these new tools.
As more organizations adopt enterprise mobility management, vendors have started to productize EMM, usually by adding MAM features to their MDM products or vice versa.

Contributor(s): Colin Steele

This was last updated in April 2013

Posted by: Margaret Rouse

10 things you should NEVER say during presentations

A lire sur:  http://thenextweb.com/lifehacks/2013/09/12/10-things-you-should-never-say-during-presentations-2/

By Boris, Thursday, 12 Sep '13, 02:41pm

Use your < > (arrow) keys to browse more stories

1,413
inShare

At our TNW Conferences we see a lot of presentations and I have given a fair share of presentations myself. I often see people making the same mistakes and cringe when I hear the same excuses or basic errors when people get on stage.
The easiest way to lose an audience is to make a mistake in the first minute, and that is exactly where most mistakes are made. Here is my list of 10 things you shouldn’t say during presentations:

1: I’m very jet-lagged/tired/hungover

Not sure where this comes from but one in five presentations at any conference will start with an excuse. ‘They only invited me yesterday’, ‘I’m really tired from my trip’ or another lame excuse that the audience really doesn’t want to hear. We, the audience, just want to see you give it your best. If you feel like shit and can’t give it your best than maybe you should’ve cancelled. Take a pill, drink an espresso and kill it!

2: I’ll get back to that later

If you happen to stumble upon an audience that is eager to learn and interact you should always grab that chance and enjoy it. If someone has a question that you will address in a later slide just skip to it right away! If someone is brave enough to raise their hand and ask you a question you should compliment them and invite the rest of the audience to do the same. Don’t delay anything.

3: Can you hear me? Yes you can!

This is how a lot of people start their talk. They will tap a microphone three times, shout ‘can you all hear me in the back’ and then smile apologetic when it becomes clear that, yes, everybody can hear you but nobody raises their hands.
It isn’t your responsibility to check the audio. There will be people for that. If you speak into the microphone and you get the impression that it’s not working, just relax, count to three, and try again. If you still think the sound isn’t working just calmly walk to the edge of the stage and discreetly ask the moderator to check for you. Smile at the audience and look confident. Assume it all works until the opposite has been proven, then stay calm and wait for a fix.

4: I can’t see you because the lights are too bright

Yes, when you are on stage the lights are bright and hot and it will be difficult to see the audience. But they don’t have to know about all that. Just stare into the dark, smile often and act like you feel right at home on there. Feel free to walk into the audience if you want to see them up close. Don’t cover your eyes to see people but politely ask the lights people to turn on the lights in the room if you plan to count hands or ask the audience a question. Even better, talk to the lights people in advance so they are prepared when you are going to ask them.

5: Can you read this?

The common rule is to make the font size on your slides twice the size of the average age of the audience. Yes, that means that if you expect the audience to be 40 on average you are stuck with a font size of 80 points. You won’t be able to fit a lot of text on the slide that way, which is a good thing, and brings us to the next point.

6: Let me read this out loud for you

Never ever, ever, ever in a million years add so much text on a slide that people will spend time reading it. And if you do, make damn sure you don’t read it out loud for them! The best way to lose your audiences attention is to add text to a slide. Here’s what will happen when you have more than four words on a slide; people will start reading it. And what happens when they read it? They will stop listening to you!
Only use short titles on your presentations and memorize the texts you want them to read. Or, if you MUST include an awesome three-sentence quote, announce that everybody should read the quote, then shut up for six seconds so they can actually read it.

7: Shut off your phone/laptop/tablet

Once upon a time you could ask an audience to shut off their devices. That was a long time ago. Now people tweet the awesome quotes you produce or take notes on their iPads. Or they play solitaire or check Facebook. Times change. You can ask if people turn their phones to silent mode but apart from that you just have to make sure that your talk is so incredibly inspiring people will close their laptops because they don’t want to miss a second of it. Demanding their attention is just not going to work.

8: No need to write anything down or take photos, the presentation will be online later

It is really cool that you will upload your presentation later. But if it’s a good presentation it won’t contain too many words (see point 4) and it won’t be of much use to them. For a lot of people writing something down is just an easy way to memorize something you’ve said. The act of writing down a sentence also embeds it in your brain and who knows, they might be really inspired and come up with something they’ve heard in between your lines that might change their business. Allow people to do whatever they want during your presentations.

9: Let me answer that question right away

Of course it is awesome if you answer a question right away, but you need to do something else first! Very often the question from an audience member will be very clear to you but not to the rest of the audience. So please say “I’ll repeat that question first so everybody hears it and THEN I will answer it”. Make it a habit to repeat questions also because the extra time it takes to repeat it gives you extra time to think about an awesome answer.

10: I’ll keep it short

This is a promise nobody ever keeps. But a lot of presentations are started that way! The audience really doesn’t care if you keep it short or not. They’ve invested their time and just want to be informed and inspired. Tell them “This presentation is going to change your life” or “This presentation is scheduled to take 30 minutes, but I’ll do it in 25 minutes so you can go out and have a coffee earlier than expected.”. Now all you have to do is keep that promise, which brings me to the last point.

Bonus tip: What, I’m out of time? But I have 23 more slides!

If you come unprepared and need more time than you are allowed you’ve screwed up. You need to practice your presentation and make it fit within the allotted time-slot. Even better, end five minutes early and ask if anyone has questions, and if they don’t invite them for a coffee to talk one-on-one. Giving an audience five minutes back will earn their respect and gratitude. Taking an extra five will annoy and alienate them.
Conclusion: come prepared, be yourself and be professional. The audience will love you for being clear, serious and not wasting their time. See you in New York in a few weeks and see if you can catch me making some of these mistakes onstage. :-)

Six Steps to Resolving Project Problems

A lire sur:  Method123

Having a structured approach to solving problems will help you resolve them more quickly and directly. Guessing the cause of the problem rarely works. You want to not only resolve this particular problem, but you also want to understand the problem well enough so that you can identify the root cause and ensure that this particular problem does not occur again.

Use the following general process to identify and resolve problems.  

1. Identify the problem or symptom

You should not assume that everyone knows the problem already. Take the time to document the problem in clear terms that everyone can understand. If you cannot clearly document the problem, it will be difficult to solve it. Make sure that you also explain the impact of the problem to the project.

2. Identify the root cause (or causes)

This is the most important step, since you do not want to spend your time resolving a symptom that you think is a root cause. Instead you should be very clear on the root cause and explain how the root cause ultimately results in the problem. If you cannot track the root cause to the perceived problem, you have not taken your investigation far enough. There are a number of issues management techniques that describe how to focus in on the root cause.

That being said, it may be that the root cause is not within your power to resolve and you may be forced to try to solve a symptom. However, you want to still be sure to identify the cause(s) of the problem to make sure you understand if you are solving a cause or a symptom.

3. Determine alternatives and impacts

The project manager may assign one or more people to determine alternatives. For each alternative, they should also address the impact to the project.

4. Select the best alternative

The project team and appropriate stakeholders can all be involved with determining the best alternative. This may include members of the project team only, or outside stakeholders.

5. Resolve the problem

A plan is put into place to address the problem and implement the chosen alternative. This could just be one activity or it could be a complex plan of resolution. These activities should be moved into the project schedule to ensure that they are performed

6. Validate the problem is resolved

The situation must be monitored to ensure that the problem is resolved as expected. If the problem appears to be resolved you are done. If the problem or a related symptom still exists, you have more work to do. Return to step 1.

Be Prepared With a Full Estimating Packet

A lire sur: Tenstep

After you have prepared your estimate for project cost and duration, you may need to defend it if the sponsor thinks that the numbers are too high. Be prepared with an estimating packet. This does not have to be a thick document. It is only meant to show the rigor that you went through in the estimating process. Rather than just providing a final estimate, or an estimate range, provide the following information instead.

• Your understanding of the work that was requested
• The process you used to prepare the estimate
• The estimating technique(s) you used
• The actual estimate of the work effort (and duration and cost, if applicable)
• The detailed estimating information in case the sponsor would like to review. For instance, if you did a Work Breakdown Structure, you can include your detailed work estimates
• The assumptions you made in developing the estimate
• The level of uncertainty in the numbers that is reflected in the contingency or the size of the estimating range (more uncertainty is reflected in a wider range)

This would be a powerful packet of information to return to the sponsor. This information will also stop many challenges because people will have difficulty disputing your facts. You may get asked to change your estimating assumptions or to try another estimating technique. These are legitimate requests and you can re-estimate based on new criteria. But at least the challenges are in terms of the estimating process, not on whether you did a poor job on the estimate itself.

If there were disagreements with your estimate, this would give you the facts to respond. For example, if your sponsor thinks the estimate is too high you can ask if the sponsor has any additional information that would allow you to revise your assumptions and perhaps revise the estimate. You could also ask whether any  requirements and functionality can be scaled back. In many cases, the original set of features and functions is more of a wish list. After seeing a price tag, it is very possible that the client can live without certain features.

There are many ways to respond, but the estimating packet gives you the details you need to support your estimate.

Tenstep N°187: Le contexte de la méthodologie TenStep (partie III)

A lire sur: Tenstep

Reconnaitre l’objectif du dossier d'affaires et de la charte du projet

Dans la méthodologie TenStep, le dossier d'affaires est utilisé pour justifier le projet, et ce, d’un point de vue commercial, et il est utilisé pour affecter le financement d’un projet. Cependant, le fait que le dossier d'affaires soit approuvé ne signifie pas que le projet est prêt à démarrer. Il se peut que plusieurs mois s’écoulent avant que le projet ne commence effectivement.

Le projet démarre officiellement lorsque le chef de projet est assigné. La première chose que fait le chef de projet est de définir le travail et d’élaborer l’échéancier et le budget. Le dossier d'affaires est utilisé comme une donnée d’entrée. Le résultat de ce travail est une charte de projet, un plan de management du projet, un échéancier et un budget. Lorsque la charte du projet est approuvée, le projet est alors prêt à démarrer. (Contrairement au Guide PMBOK du PMI où c’est la charte du projet qui autorise le projet. Dans la méthodologie TenStep, le projet est autorisé lorsque le dossier d'affaires est approuvé, et le projet est prêt à être exécuté quand la charte du projet est approuvée.)

Le modèle TenStep se concentre davantage sur les projets internes

L’approche générale du modèle TenStep assume que vous disposez d’un projet interne avec des clients internes. Tandis que la plupart de la méthodologie est également applicable aux projets clients-fournisseurs, une partie du modèle doit pourtant être révisée. Par exemple, dans un projet où vous avez un client externe, vous pouvez utiliser un « énoncé de travail » au lieu d’une charte de projet. Vous pouvez également avoir des attentes plus sévères quant à la possibilité de dépasser l’échéancier et le budget. Un grand nombre de ces rôles pourraient également être différents.

Le rôle du commanditaire est très important

TenStep considère que le rôle du commanditaire est indispensable à la réussite du projet. Plusieurs organisations disposent d’une telle personne remplissant cette position, mais elle peut être appelée différemment, tel que le champion du projet ou le client. La méthodologie TenStep compte sur ce rôle pour obtenir le financement du projet, pour approuver les livrables importants, pour éliminer les obstacles, et généralement pour assurer que le projet bénéficie du soutien nécessaire pour réussir. Cependant, certaines organisations ne disposent pas de ce type de rôle du commanditaire. Dans certaines organisations, le commanditaire est éloigné de l’accès direct au projet et est remplacé par une personne intermédiaire qui représente l’intérêt du client. Dans certains projets, tels que les dons gouvernementaux, il se peut que le rôle du commanditaire n'existe pas du tout. Cependant, dans la méthodologie TenStep nous avons besoin d’une personne qui remplit ce rôle. Si un vrai commanditaire n’existe pas ou ne peut pas être identifié, le chef de projet devrait chercher une autre personne pour remplir ce rôle.

Terminologie de management de projet

Référence de base. Plan approuvé pour un projet, plus ou moins les modifications approuvées. Il est comparé à la performance réelle pour déterminer si le niveau de performance se situe dans des seuils d’écarts acceptables. Il se rapporte généralement à la référence de base actuelle, mais il peut également se rapporter à la référence de base originale ou à une autre référence de base. Habituellement utilisée avec un déterminant (p. ex. référence de base de performance des coûts, de l'échéancier, des mesures de performances, référence de base technique).

Répertoire de l'équipe de projet. Liste documentée des membres de l'équipe de projet, avec leurs rôles dans le projet et les informations nécessaires à la communication.

Abréviations courantes

QA (anglais) : Quality Assurance

AQ (français) : Assurance qualité

5 Tips For Project Baselines

A lire sur:  ProjectManager.com

The project schedule is a document that changes regularly. So how do you know what the original looked like without saving a new copy every time? Easy-use project baselines.

Here are our 5 tips for creating and using baselines on your projects.

Tip 1: Create an initial baseline
A baseline is a snapshot of your project schedule at any given moment. Baselines help you see what has changed on your project by giving you something that you can refer back to.

Work with your project team to create a full, comprehensive project schedule. Use a task list as the basis, then add in dates, links between tasks and the details of who is doing what. Use the baseline feature in ProjectManager.com to create an initial baseline. This will let you refer back to the original plan if you need to.

Tip 2: Update your schedule regularly
Remember to update your schedule regularly. Your project schedule will change as tasks are marked as completed, new tasks are added, or dates change. You may also find yourself updating the resources on the schedule. Keeping your schedule up to date is essential for managing your project successfully.

Tip 3: Don't baseline every change
It might be tempting to create a new baseline every time you change something on your schedule, but that really isn't a good idea. You'll end up with far too many baselines and it will be difficult to know which one to use if you want to see what has fundamentally changed!

If you are making day-to-day updates that don't require a formal change control notification or approval by your project sponsor, then you don't have to create a new baseline for that schedule modification.

Tip 4: Create regular baselines
However, you should create regular baselines, especially after a major change to your project schedule. For example, if you add in a new block of tasks, change the project scope to include more work or to take out tasks, or your key milestone dates change, then it is a very good idea to create a new baseline. If you are updating the schedule as a result of an approved change that has been through the change control process, then it is a good idea to create a new baseline.

You can save multiple baselines in your software tool, so don't worry about losing any information that you have already saved.

Tip 5: Refer to your baseline at project completion
Project baselines are excellent tools when it comes to the end of your project, because you can use them to see exactly what has changed. When you complete your closure documentation for the project you can refer back to your initial or interim baselines and see how your schedule evolved over the life of the project. You can also use your baselines during a lessons learned meeting.

This can be really helpful when it comes to working on your next project, as you can easily see if any tasks needed to be replanned, and this can help you plan more accurately for next time.