How to make more time in your day

A lire sur:  ProjectManager.com

Do you struggle to fit everything into your working day?

Most Project Managers find it hard to get all their tasks done each day, but you can get more out of your working hours by working smartly. Here's how to do it...

How to make more time in your day

#1: Use templates
Templates are documents or files that you can use time and time again. Don't create a new Project Charter for every project, for example. Use a template and simply fill in the relevant bits for this project. You'll save time because you won't have to set up titles, headers or footers or any other style elements.

You can also use templates for creating schedules, task lists, reports and anything else that you use on your project. Don't just limit yourself to documents!

#2: Use time sheets
The key to getting more done is understanding what you currently do with your time. Time sheets will show you what you have actually been working on, so you can assess how your time is being spent. You might, for example, find that you spend too long in meetings each week, or working on a particular element of project management like budgeting. Using timesheet software will help you keep track of where your time is going.

Once you have completed time sheets for a couple of weeks you will be able to see where you are wasting time in the day. You can also decide if there is anything you could delegate to another team member as a learning opportunity.

#3: Take breaks
It might seem counter-intuitive, but it really will help you get more done if you schedule some breaks into your day. Breaks help refresh your brain and your body, which means you come back to your desk feeling more motivated and capable of completing your tasks. Go for a walk, talk to a colleague or simply get a cup of coffee. Anything that gives your eyes a rest from the screen and your mind a change of scene will do.

#4: Use dashboards
Dashboards are visual representations of project progress and they are a great way to see the big picture status of your project. You won't have to review every element of the project to get a status update as you'll be able to see it all at a glance.

Dashboards are also great to share with your stakeholders. They will save you time producing bespoke reports month after month as instead, your project sponsor and anyone else who is interested can simply log on and see the status for themselves in real-time.

#5: Store your files online
Project managers and their teams spend a great deal of time looking for important project files. You can save time if you set up an online filing system that will structure your files for you and keep them secure. Then you'll always know where the latest copy of a document is kept, and you won't waste time hunting for it when you need it. This will also help your project team save time!

Of course, you don't need to spend your extra hours on project work! Why not use some of it to study for a professional qualification, or to catch up with a good book, or to just get home earlier and spend more time with your family?

La vision du risque stratégique est en train de changer pour 300 dirigeants du monde entier

A lire sur:  http://www.finyear.com/La-vision-du-risque-strategique-est-en-train-de-changer-pour-300-dirigeants-du-monde-entier_a27485.html

Résultats de l’enquête mondiale Deloitte/Forbes Insight « Exploring Strategic Risk ».

Laurent Leloup

Deloitte publie une étude mondiale intitulée « Exploring Strategic Risk ». Menée au printemps 2013 par le magazine Forbes Insights pour Deloitte auprès de 300 sociétés à travers le monde, cette enquête permet de mieux comprendre la manière dont les entreprises appréhendent la gestion du risque stratégique.

- 81% des sociétés interrogées affirment gérer de manière spécifique le risque stratégique
- La quasi-totalité des répondants (94%) affirment avoir changé leur approche de gestion des risques stratégiques au cours des dernières années.
- Le risque de réputation est désormais la plus grande préoccupation, en raison notamment de la montée des médias sociaux
- La majorité des entreprises interrogées (53%) pensent que les nouvelles avancées technologiques de type mobile, social ou « big data » peuvent menacer les business models existants
- Le risque stratégique est devenu une préoccupation majeure des entreprises

81% des entreprises interrogées affirment gérer de manière spécifique le risque stratégique et ne plus se limiter aux risques traditionnels (opérationnels, financiers et risques de conformité). De nombreuses entreprises adoptent désormais une vision globale du risque stratégique en se concentrant sur les risques majeurs qui pourraient affecter le positionnement et la performance à long terme d'une entreprise.

Le risque stratégique devient ainsi une priorité majeure des sociétés interrogées qui affirment en quasi-totalité (94%) avoir changé leur approche de gestion des risques stratégiques au cours des trois dernières années. On constate ainsi une intégration accrue dans les processus globaux de planification et de prise de décision stratégique. 61% des entreprises interrogées affirment que leurs programmes de gestion des risques soutiennent de manière adéquate le développement et l’exécution de la stratégie

Le risque de réputation en tête des préoccupations
La réputation arrive en tête des risques stratégiques cités par les entreprises. La montée en puissance des réseaux sociaux et son corollaire, la propagation instantanée et de grande ampleur de l’information, rend de plus en plus difficile la maitrise de l’image et de la notoriété sur les marchés.

La majorité des entreprises interrogées (53%) pensent que les nouvelles avancées technologiques de type mobile, social ou « big data » peuvent menacer les business models existants. 91% d’entre elles affirment avoir changé leur business model depuis l’apparition de ces technologies. Les technologies qui ont eu le plus grand impact sont issues de trois secteurs : TMT (97%), C&IP (96%) et les sciences de la vie (94%).
Le capital humain et l’innovation sont les deux actifs stratégiques les plus cités par les entreprises comme nécessitant un investissement majeur sur le long terme.

« Intégrer la dimension stratégique, c’est se poser la question de couple risques / opportunités. L’analyse des risques doit supporter le processus de décision au plus haut niveau, puis aider au pilotage de l’exécution de ces décisions. Par ailleurs, le risque de réputation constitue effectivement un point d’attention majeur pour la majorité des entreprises, gérer ce risque ne peut reposer seulement sur des actions axées sur la communication proprement dit, mais doit relever d’une démarche plus globale, incluant par exemple la surveillance des réseaux sociaux, la remontée des incidents ou la gestion de crise » conclut Marc Duchevet, Associé Risk Advisory Deloitte France.

L’étude complète (en anglais – PDF 21 pages) est disponible en suivant ce lien :
www.deloitte.com/assets/Dcom-France/Local%20Assets/Documents/publications/1311%20Exploring%20Strategic%20Risk/Exploring_strategic_risk_nov2013.pdf

Méthodologie
Les conclusions de ce rapport sont fondées sur une enquête mondiale menée au printemps 2013 par Forbes Insights, au nom de Deloitte, auprès de plus de 300 dirigeants en provenance des Amériques (33%), Europe / Moyen-Orient / Afrique (33%) et l'Asie / Pacifique (34%). Presque tous les répondants étaient des cadres de niveau C (263), les membres de la section (22) ou des cadres de risques spécialisés (21). Les entreprises interrogées provenaient de l'ensemble des cinq principaux secteurs industriels (produits de consommation / industriel, sciences de la vie / santé, technologie / médias / télécommunications, l'énergie / ressources et les services financiers), et tous avaient des revenus annuels de plus de 1 milliard de dollars US (ou équivalent)

Laurent Leloup

Friday, November 15th 2013

Métier : l'architecte IT plus intégrateur que jamais

A lire sur:  http://www.lemagit.fr/actualites/2240209122/Metier-larchitecte-IT-plus-integrateur-que-jamais

Anne-Marie Rouzeré Publié: 15 nov. 2013

Vieux comme l'informatique, ou presque, le métier d'architecte IT version 2013 vit à l'heure  de l'acronyme SMAC (Social, Mobile, Analytics et Cloud). Une évolution majeure commentée ici par Patrice Duboé, responsable de la communauté des architectes de Capgemini.

LeMagIT : L'animation de la communauté des architectes IT de Capgemini dont vous êtes responsable se réfère à l'acronyme SMAC – Social, Mobile, Analytics , Cloud. Quel est le message envoyé ainsi?

Patrice Duboé : D'abord une constante : la veille technologique est une des composantes essentielles du métier de l'architecte. Pour exercer cette activité, il faut être curieux, passionné, savoir se remettre en question. Faute de quoi, on peut tenir un an ou deux. Au delà, cela devient compliqué. L'architecte – à la différence de l'expert qu'il a peut-être été auparavant – doit avoir une vision transverse de l'état de l'art. Comme dans le bâtiment, ce n'est pas lui qui va monter les murs. Mais pour que la maison tienne et qu'elle soit conforme à la régulation en vigueur, encore faut-il qu'il se tienne au courant de l'évolution des matériaux, des normes et des règles. Les quatre piliers technologiques résumés par l'acronyme SMAC mettent encore plus en exergue cette nécessité de développer une vision transverse. 
 

LeMagIT : Encore plus transverse, pourquoi ? 

Patrice Duboé : Rien de révolutionnaire, en effet, pour l'architecte, quant aux réseaux sociaux qui constituent simplement une évolution des moyens d'échanger et d'exploiter les informations, avec cependant un surcroît d'exigence en sécurisation. Même chose pour la mobilité qui implique de concevoir des applications accessibles « Any Time, Any Where, Any Device ». De même, pour le cloud computing qui n'est pas un but en soi mais implique que tout projet soit tenu d'intégrer la composante cloud. Face à ces tendances de fond, l'architecte a essentiellement un rôle de conseil, de mise en garde, auprès des entreprises clientes et des équipes de conception-réalisation : « avez-vous pensé à … ? ».

En revanche, avec le Big Data, synonyme de prise en compte de sources de données et d'informations éminemment hétérogènes, issues de multiples environnements, multi-technologies, on peut parler de révolution quant à la vision transverse que doit exercer l'architecte. On sait ce qu'est un expert SAP. On ne peut pas se dire expert et encore moins architecte Big Data SAP.

LeMagIT : L'impact est-il le même pour toutes les catégories d'architectes IT ? 

Patrice Duboé : Jusqu'à présent, on distinguait en effet le rôle de l'architecte d'entreprise qui doit avoir une vision globale des systèmes d'information, à la façon d'un urbaniste, de celui de l'architecte d'infrastructure et de l'architecte d'application. Désormais, le mot-clé en matière d'architecture est intégration. La personne-clé est l'architecte capable d'assumer la complexité de l'intégration des solutions impliquées dans les projets SMAC. Un profil rare dont on va probablement manquer, d'autant plus qu'il faut du temps pour en acquérir la capacité sur la base de l'expérience.
 

LeMagIT : Assumer l'intégration, n'était-ce pas déjà le cas auparavant ? 

Patrice Duboé : Encore une fois, ce qui est désormais souligné est la différence entre le rôle de l'expert et la vision d'ensemble, transversale que doit avoir l'architecte. Quand on parlait de SOA ou d'architecture ESB (Entreprise Service Bus), comme l'entreprise et ses systèmes d'information fonctionnaient en silos, les architectes, même au niveau le plus englobant d'architecte d'entreprise, adoptaient eux aussi une approche par silos, recourant à des experts de niches. L'obligation d'interconnecter les solutions était moindre ou alors se situait au niveau des réseaux.

Désormais, la notion d'intégration est capitale, dans un contexte d'entreprise étendue, d'échanges permanents avec les clients, les fournisseurs et partenaires. C'est le point essentiel autour duquel se sont articulés les échanges de notre « Architecture week » annuelle qui, au delà des 3000 architectes du groupe Capgemini, s'est ouverte depuis quatre ans aux partenaires et aux représentants, architectes et DSI, d'entreprises clientes. Sachant que la première demande qui remonte de chez nos clients est du type : « Aidez-nous à organiser notre service d'architecture SI interne, pas tellement sur le plan technologique mais plutôt en termes de gouvernance ». Comment, par exemple, capitaliser, industrialiser l'approche des dossiers d'architectures dans une multinationale comme Alcatel Lucent, qui emploie 200 architectes répartis dans le monde, relevant de cultures différentes ?

LeMagIT : Justement, avec le cloud et l'externalisation croissante des services autour des SI, les entreprises ont-elles encore besoin de services d'architectes en interne ? 

Patrice Duboé : On a eu le même débat il y a dix ans avec l'essor de l'outsourcing. C'est bien connu : on n'externalise bien que ce que l'on maîtrise bien par soi-même. Pour les grandes entreprises, c'est une évidence. L'externalisation ne réduit pas l'importance de leur département architecture IT. Bien au contraire. Les PME et ETI s'appuient plutôt sur des ressources externes. Par ailleurs, l'hébergement dans le cloud, avec des acteurs, fournisseurs ou prestataires qui ont chacun leurs solutions cloud, implique d'autant plus de garder la maîtrise sur les échanges entre multiples solutions. Comme dans la logistique d'entreprise : ce n'est pas parce qu'on externalise auprès d'entreprises de transport que l'on n'a plus besoin de service logistique en interne.

LeMagIT : Si comme vous le dites, l'architecte d'intégration est une ressource rare, comment espérer que les projets cloud et big data puissent se fonder sur cette maîtrise de l'intégration ?
Patrice Duboé : Si l'évocation du big data et de la complexité qui l'entoure fait peur, on en est encore au stade de la montée de la demande de clarification. Quel est l'intérêt pour mon entreprise ? A quels acteurs faire confiance ? Comment aborder un tel projet ? Pour le cloud, de même, il n'y a pas de raison de s'affoler. Le fait que 90% des entreprises – selon certaines enquêtes – s'intéressent au cloud, ne dit rien quant au pourcentage de leurs systèmes d'information déjà, ou potentiellement concerné. Quant au changement induit au niveau de la structure de gouvernance, on en est encore au tout début. 

LeMagIT : Réciproquement, comment prétendre être cet architecte maîtrisant les problèmes d'intégration si ceux-ci en sont encore au stade de l'émergence ? Et d'ailleurs, comment devient-on architecte ? 

Patrice Duboé : Rien de changé sur ce point : on ne naît pas architecte, ni ne le devient sans avoir auparavant mis les mains dans la technologie. Chez Capgemini, l'architecte a au moins six ou sept ans d'expérience en tant que consultant en système d'information, concepteur-réalisateur, administrateur système-réseaux, voire développeur. L'architecte doit avoir non seulement un background technologique, mais que celui-ci soit fondé sur l'expérience. On voit des consultants métiers technophiles qui se disent architectes. A mes yeux, cela ne suffit pas. Je ne confierai pas la construction de ma maison à quelqu'un qui lit des revues d'art et de décoration.

Ensuite, le maître-mot pour rester architecte est de ne pas s'enfermer dans une mission longue. Comme dans tous les métiers, la courbe d'apprentissage est exponentielle. On apprend beaucoup en début de mission et au fil des mois, on entre ensuite dans une zone de confort, avec la sensation d'avoir moins besoin d'apprendre. L'architecte qui progresse est celui qui passe rapidement de projet en projet, avec une forte présence en début de cycle, nettement moins requise lorsque le projet entre en production, tout en se sachant responsable jusqu'à l'aboutissement du projet. C'est une façon d'entretenir sa curiosité, sa capacité à se remettre en question.

LeMagIT : Et quand on est fatigué de sauter de projet en projet, que devient-on ? 

Patrice Duboé : Beaucoup de chemins d'évolution sont possibles. Soit prendre en charge, en tant qu'architecte, des projets de plus en plus complexes. Ou devenir architecte d'entreprise, ce qui jusqu'alors représentait la voie royale pour l'architecte senior. Soit redevenir expert d'une technologie ou, sur la base de l'importance qu'a prise la connaissance d'un métier ou d'un secteur d'activité dans un projet, expert d'un service métier. Ou basculer sur le volet management en devenant chef de projet. Ou encore passer du côté de la stratégie, en cherchant à imprimer son empreinte dans certains choix d'innovation. Au sein de Capgemini ou chez des partenaires. L'éventail des possibles est large.

Des CIO prudents

A lire sur:  http://www.paperjam.lu/chiffre/des-cio-prudents

Mis à jour : 14.11.2013 19:30

Il s'agit, selon une étude de Deloitte, du taux de CIO luxembourgeois qui évoquent une baisse des budgets informatiques dans leurs entreprises. Ce taux est plus élevé que la moyenne européenne qui est de 22%.

Ten Areas to Consider When Discussing Project Approach

A lire sur: Method 123

Many organizations have a section in their Project Charter for the project approach. The approach describes the overall thinking of how the project is structured and why it is structured that way. There are two benefits to creating an approach section. First, this information will help the sponsor and stakeholders understand how the project will progress and why.

The other benefit of the project approach is that it allows the project manager and project team to lay out a high-level vision for project execution and use this vision to help create the detailed plans.  

The following sections describe the type of information in the approach. Some of this information may be available elsewhere, but it is in the approach section that you tie everything together for the benefit of the reader.

1. Discuss whether any broader company initiatives or strategies impact the structure of this project.
2. Identify any constraints or time-boxes in terms of budget, effort, time or quality, and the impact to the project.
3. Describe other options for the overall approach and why you chose the options you did over the others. Note why you think this approach has the best chance of success over the others.
4. Talk about how the deliverables will be supported and maintained after the project ends. Also indicate whether the approach was influenced by support and maintenance implications.
5. Discuss any other related projects that are completed, in progress or pending that influenced the approach for this project and why.
6. Discuss, at a high level, how the project will progress from start to end and the interdependencies between the high-level phases and stages.
7. Discuss any techniques that might be of interest to the reader. For instance, if the requirements will be gathered in a three-day Joint Application Design (JAD) session, you can note this in the approach.
8. Note whether new technology or new processes are being utilized and why.
9. Identify any unusual staffing requirements, such as consultants or outside specialists, and explain why you need them.
10. Describe the use of outsourcers, contractors or vendors, especially if they are doing significant work.

These are ideas. You do not need to comment on all of them and many may not be applicable to your project. The key is that this section is for the benefit of the reader - the writer already knows the information. If the writer is diligent and provides good context, this section can instead prove to be very valuable for the reader.

Create a Work Breakdown Structure in Three Steps

A lire sur:  Tenstep

The first major step in building a schedule (sometimes called a Project Plan) is to create a Work Breakdown Structure (WBS). This is a way to identify to work that is required to build the deliverables of the project. The WBS allows you to break the large project down into small enough steps that the work can be understood. The process for building the WBS is as follows

1. Identify the large “chunks of work” of the project

First determine the large chunks of work that must be completed for the entire project to be completed. When you start, it does not matter how you define the large chunks of work. For instance, a traditional breakdown might be "planning / analysis / build / implement", which lays out the project in a high-level timeline. The breakdown could also be by major deliverable such as "permits, pool, fence, landscaping". You can break down the work into whatever structure makes sense for your project.

2. Evaluate each lower element of the WBS

Check each component of the WBS to see if it meets the following two criteria.

• Do you (or someone on your team) understand the detailed work required to complete this work component? The detailed work components on the WBS will ultimately be moved to the schedule. You don’t want to have activities on your schedule that no one on your team fully understands. 
• Do a quick estimate of the work. Are the effort hours required to complete the work less than your estimating threshold? A rule of thumb is 80 hours or less, but this could be higher or lower based on the size of the project. If you don't understand the work, the chances are it will be larger than your estimating threshold as well.

If you understand the detailed work required to complete the component and if the estimated level of effort is smaller than the estimating threshold you do not need to break the component down further.

3. Continue to break down each component as needed

Work components that require more effort than the estimating threshold, or work components that you do not fully understand should be broken down further into smaller pieces of work. As you break the work down, you are ultimately going to create activities that are required to complete the deliverables. This is referred to as an "activity based WBS". The detailed activities from the WBS are what get carried forward to the schedule.    

This process of breaking the work components into a lower level set of components should continue until all of the work components are represented as granular as necessary to ensure that no activities have estimated effort larger than the estimating threshold, and that you understand the work. This takes you to levels 3, 4, 5 etc. Rarely would you need to break the work down greater than five levels. 

Planning Components

There is one exception to this process. If your project is large and long, it is likely that you may not know enough to be able to break all of the work down to a discreet level. Work that takes place a long way in the future may have to be left at a higher level. These are known as planning components. In that case, you can leave the work components at the higher level until you get closer to execution (three months), at which time you will know enough to be able to break the work down at a more granular level.

When you are done with the process above, you will understand the work at the lowest levels of the WBS and the work will be smaller than your estimating thresholds. At that point the WBS is completed.

N195: Établir un programme pour coordonner un ensemble de projets liés entre eux

A lire sur Tenstep

Si vous décomposez un effort de grande ampleur en plusieurs sous-projets, il est nécessaire de maintenir une gestion et une coordination globales. C’est la raison pour laquelle il faut mettre en œuvre un ‘‘programme’’. Un programme est une structure qui sert de parapluie à la gestion d'une série de projets reliés les uns aux autres. Chaque projet a un chef de projet à temps plein ou à temps partiel. Le programme est dirigé par un gestionnaire de programme. Celui-ci ne produit lui-même en aucune façon des livrables. Les livrables sont les résultats produits par les différentes équipes de projets reliés les uns aux autres. Le but du programme est de :

·         Donner l'orientation, la conduite et la direction globales des projets.

·         S’assurer que les différents projets liés communiquent efficacement entre eux.

·         Servir de plate-forme centrale de contact pour le client et les équipes du projet.

·         Déterminer comment les projets particuliers doivent être définis afin que l’ensemble du travail soit une réussite.

Travailler avec votre client quand il n’est pas en mesure de définir le projet de manière précise

Il arrive parfois que le chef de projet place de grands espoirs dans la capacité d’anticipation et de prévoyance des clients. Dans de nombreux cas, le chef de projet se tournera vers le client afin de chercher des réponses permettant d'arriver à définir le projet, alors que le client ne dispose pas de toutes les informations nécessaires. Cela se produit souvent et ne signifie pas que le client ne sait pas ce qu’il fait. Dans beaucoup de cas, particulièrement pour de grands projets, le client peut se faire une idée sur ce que seront les résultats finaux, mais ne peut pas encore articuler cette vision autour de livrables concrets. Il se peut également qu’il n’ait pas en sa possession toutes les réponses demandées sur le contenu, les risques, l’organisation du projet, etc.

Quand les informations dont il dispose sont incomplètes, le chef de projet va peut-être éprouver le besoin d’émettre des hypothèses concernant les détails. Ce n’est cependant pas une bonne solution. Au lieu de cela, si vous êtes confronté à une telle situation, vous pouvez procéder de deux manières différentes :

·         Commencez par exposer tout ce que vous savez, mais aussi tout ce que vous ne savez pas. Si on vous demande tout de même de proposer une estimation de l'effort de travail, du coût et de la durée, vous devriez élaborer une estimation qui comporte une réserve de temps et de budget suffisante pour compenser l’incertitude qui persiste. Votre évaluation peut prévoir une marge de 20%, 40% ou même plus.

Si vous n’êtes pas autorisé à répartir le projet en des lots de travaux plus petits, tâchez néanmoins d’en savoir assez pour pouvoir planifier le travail sur les 90 premiers jours. Dans une telle approche, planifiez le travail à court terme dans le détail, et le travail à long terme avec moins de précision. Tous les mois, vous devriez redéfinir et planifier à nouveau le travail restant. Car plus vous découvrirez d’informations, plus vous pourrez planifier le travail restant de manière plus détaillée. Puisque vous découvrez plus de détails, vous pouvez affiner vos estimations et travailler avec le commanditaire pour vous assurer que l’accord sur la poursuite du projet tient toujours.

·         Divisez le travail en une série de projets plus réduits (tel que décrit précédemment). Même si les résultats finaux ne peuvent pas encore être définis clairement, vous devriez disposer d’un certain effort de travail bien déterminé qui mènera peu à peu aux informations requises pour la solution définitive. Vous ne devriez définir un projet que dans la limite de ce que vous ‘‘voyez’’ aisément à l’instant. Ensuite, définissez et planifiez les projets pour couvrir le travail restant, au fur et à mesure que de plus amples détails sont connus. Par exemple, vous pourriez réaliser un projet qui permet de rassembler les exigences commerciales, puis utiliser les résultats de ce projet pour définir un second projet pour élaborer les livrables définitifs.

Terminologie de management de projet

Acheteur. Personne chargée de l'acquisition de produits, de services ou de résultats pour une organisation.

Autorisation des travaux. Autorisation et décision, généralement écrites, de commencer le travail d'une activité de l'échéancier, d'un lot de travail ou d'un compte de contrôle spécifiques. Cette méthode de sanction des travaux du projet permet d'assurer que le travail est effectué par l'organisation voulue, au moment voulu et selon la séquence appropriée.

Abréviations courantes

SPI (anglais) : Schedule Performance Index

IPD (français) : Indice de performance des délais