Pourquoi mettre en place le BYOD ?

A lire sur:  http://www.islean-consulting.fr/le-blog/3/pourquoi-mettre-en-place-le-byod/

mercredi 19 septembre 2012, ISlean Consulting
Stratégie, Lean Management et organisation des SI
Paris, France

Liberté de choix pour le salarié, souplesse de maintenance et coûts réduits pour le service informatique, le BYOD « Bring-Your-Own-Device » se répand de plus en plus dans les entreprises. Cette pratique permet aux collaborateurs d’une société de travailler avec leurs équipements personnels (informatiques et téléphoniques).

Comment en sommes-nous arrivés là ?

Depuis l’apparition de free.fr au début des années 2000, qui a amené le haut débit dans les foyers à 30 € par mois, chaque année le rapport performance / coût des systèmes d’information personnels se rapproche voire dépasse celui des systèmes d’information d’entreprise.

Par ailleurs, la tendance à standardiser fortement les postes de travail, à des fins de sécurité et de réduction de coûts, a rendu ceux-ci très rigides, fragiles et peu ergonomiques. Prenons par exemple les monolithes (portables, le fixe étant en voie de disparition) gris Dell ou HP qui peuplent encore les groupes du CAC 40 et dont les charnières entre l’écran et le clavier finissent souvent par casser, l’écran par s’éteindre, ou encore le clavier par avoir des touches hors service. Pourtant, le coût de possession (TCO : Total Cost of Ownership) reste prohibitif : près de 3 000 € par poste et par an, incluant le support et les logiciels installés.

C’est donc naturellement dans les start-ups que le BYOD a éclos : ici, impossible de se permettre de payer 3 000 € par poste et par an ! Chaque employé, en partant du créateur, a donc commencé à travailler avec son poste personnel. La pratique s’est pérennisée puis étendue à toutes les personnes qu’il a embauchées.

Certes, le support n’existe plus et devient de l’autosupport. Dans ces cas-là, avoir une machine en réserve est une nécessité pour pallier les pannes. De même, il est important d’être en mesure de débrouiller les petits pépins (virus, malwares) seul ou avec l’aide de la communauté.

Le poste de travail passé, les smartphones ont fait leur apparition dans les années 2005-2007, avec les HTC Windows mobile (souvenez-vous !) et surtout l’iPhone et les Android Phones. Avec ces appareils, la frontière entre personnel et professionnel, déjà difficile à poser avec les postes de travail, disparaît totalement. D’autant que ces appareils sont étroitement connectés aux systèmes de l’entreprise : messagerie, calendrier, contacts, tâches, partage de fichiers dans le nuage, notamment.

Après les smartphones, les tablettes prennent le relais, et deviennent, graduellement, de véritables alternatives aux postes de travail portables, exception faite lorsqu’il est nécessaire de saisir de grandes quantités de textes. Les systèmes de reconnaissance de la parole ne sont pas encore aussi performants qu’un humain qui écoute, comprend, et retranscrit, et ils sont de toute façon inutilisables en open-space ou en public.

Pour lire la suite, http://www.islean-consulting.fr/le-blog/3/pourq...

Les entreprises commencent à intégrer le digital à leur ADN

A lire sur:  http://www.atelier.net/trends/files/entreprises-commencent-integrer-digital-adn?utm_source=emv&utm_media=mail&utm_campaign=alerte_emea

Pour communiquer, pour créer du lien, pour vendre, les sociétés sont de plus en plus nombreuses à multiplier les initiatives mêlant le digital. Mais cette transformation ne doit pas passer que par l'outil, et surtout elle doit s'opérer aussi bien en externe qu'en interne.

Pour améliorer leurs processus, et surtout pour continuer à croître, les entreprises commencent de plus en plus sérieusement à repenser leurs stratégies et à penser digital. Du coup, elles investissent en conséquence. Dans un rapport, KPMG soulignait ainsi récemment que de nombreuses compagnies ont revu leurs priorités et sont passées des réseaux sociaux au digital et au mobile. Le but : développer leurs activités autour des appareils numériques, des services et de la distribution de contenu. Les exemples récents sont nombreux, de Marks and Spencer, qui propose du contenu en réalité augmentée sur mobile, à Pernod Ricard, qui a lancé plusieurs applications de services. Reste que, pour être efficaces et faire véritablement basculer l'entreprise à l'ère du digital, ces initiatives ne doivent surtout pas ne reposer que sur l'outil. En effet, selon CapGemini Consulting et le MIT Center for Digital Business, beaucoup d'organisations mènent des expériences dans le marketing mobile, les médias sociaux, les analyses.
Une migration autant externe qu'interne
Cela dit, un grand nombre se trompe en pensant qu'il suffit d'adopter les technologies le permettant pour que cela fonctionne. Pour une migration réussie vers le digital, il faut avant tout étudier la culture de l'entreprise et voir comment y insérer de nouvelles manières de faire compatibles avec son identité et avec les compétences de chacun. Des changements qui doivent passer par le top management. Ce qui amène à une autre composante du problème : pour réussir sa migration vers le digital, il ne faut pas penser que celle-ci ne se joue qu'en externe. Les transformations en interne sont aussi importantes pour la longévité et la crédibilité de l'entreprise. Notamment parce que de nouveaux processus, moins horizontaux, permettent une meilleure efficacité et productivité.
Les DRH au centre des relations humaines
Mais aussi parce que si l'entreprise se montre innovante en externe mais trop traditionnelle en interne, elle risque de se confronter à des salariés qui amorcent de nouvelles façons de travailler et à une génération de nouveaux entrants appâtés par une image innovante et qui devraient fuir des processus trop traditionnels, et même peut être ternir la réputation de la société. Et pour créer cette passerelle, pour faciliter ces nouveaux modes de collaboration, il y a certes la DSI, mais aussi la DRH, qui va jouer un rôle de plus en plus prépondérant. Celle-ci passant d'un rôle de Direction des Ressources Humaines à celui d'une Direction des Réseaux Humains.

Sommaire

• Le digital et le mobile seront les principaux vecteurs de croissance d'ici à 2015
  Par L'Atelier - Paris 26 sep 2012
  
• Pernod-Ricard mise sur le mobile pour séduire ses consommateurs
  Par Elyse Charvin 11 sep 2012
  
• Marks and Spencer mise sur l'expérience digitale sur le point de vente
  Par L'Atelier - Paris 21 sep 2012
  
• Le digital joue un rôle transversal sur la stratégie marketing des marques
  Par Claire Cavret 21 sep 2012
  
• "En externe comme en interne, l'entreprise doit se mettre en phase avec le monde 2.0"
  Par Claire Cavret 17 sep 2012
  
• "Le succès de l'intégration du 2.0 dépend de la capacité d'échange entre entités"
  Par L'Atelier - Paris 25 sep 2012
  
• La transformation digitale de l'organisation ne doit pas se focaliser sur l'outil
  Par L'Atelier - Paris 27 sep 2012
  
• Le DRH doit plus que jamais créer du lien entre les salariés
  Par Claire Cavret 14 sep 2012
  

Les DSI européens rejettent et bloquent en masse les réseaux sociaux

A lire sur:  http://www.decideur-public.info/article-les-dsi-europeens-rejettent-et-bloquent-en-masse-les-reseaux-sociaux-110622323.html

Jeudi 27 septembre 2012

Selon l’étude Killer Apps 2012 réalisée par Easynet et Ipanema Technologies, les DSI européens rechignent à admettre les avantages des médias sociaux pour les entreprises. Ce rapport a été compilé sur la base d’enquêtes de terrains conduites cette année en ligne auprès de 550 répondants constitués à parité de DSI, directeurs IT, responsables IT et gestionnaires de réseaux. Les répondants sont des employés de grandes entreprises à travers l’Europe. Les répondants proviennent du Royaume Uni, de France, d’Espagne, d’Italie, de Belgique et du Benelux.

 

Les entreprises risquent de perdre des clients, de mettre en place des stratégies marketing inefficaces, de démotiver le personnel et de perdre leur avantage concurrentiel si elles ne tiennent pas compte des médias sociaux, préviennent les auteurs. Les principaux points de l'étude font ressortir que 67% des DSI et des directeurs IT européens déclarent bloquer Facebook, 60% bloquent YouTube, 49% bloquent Twitter et 56% bloquent toutes les vidéos online.

 

Pour Lisa Myers, CEO de Verve Search, une agence spécialisée en SEO & Social Media : « Il est risqué de bloquer les réseaux des médias sociaux. Je suis fortement étonnée par ces statistiques démontrant qu’autant d'entreprises le font. Le retour sur investissement des médias sociaux est simplement la garantie de l’existence de votre entreprise d’ici cinq ans. Plus de la moitié de la population mondiale a moins de trente ans et n'a jamais connu un monde sans Internet. Pour ces jeunes, Internet - et les médias sociaux par conséquent - est un mode de vie. Les entreprises ont besoin d'intégrer le pouvoir des médias sociaux pour ensuite l'utiliser, au lieu de le combattre, afin de fidéliser leur personnel et améliorer leur expérience client. »

 
Philippe Guichardaz

N°146: Créer le plan de gestion des risques

A lire sur:  Tenstep

Le plan de gestion des risques décrit comment vous allez définir et gérer les risques du projet. Ce document ne décrit pas les risques et les réponses eux-mêmes, mais les processus et techniques à suivre pour définir les risques et déterminer les réponses.

Le plan de gestion des risques doit comprendre les informations suivantes:

·         Les rôles et les responsabilités. Cette section décrit les rôles de dirigeant et de support pour les différents processus de gestion des risques. La gestion des risques est une responsabilité traditionnelle du chef de projet. Cependant, certains grands projets peuvent avoir recours à un spécialiste dans ce domaine d'activité. La participation de spécialistes extérieurs peut aider à mettre en place une analyse des risques plus impartiale que celle provenant de l'équipe interne.

·         Budgétisation. Discutez du budget attribué à la gestion des risques du projet. Peut-être qu'au moment de la création du plan de gestion des risques, vous ne détenez pas encore suffisamment d'information pour concrétiser ce budget. Mais vous pouvez décrire le processus que vous pensez utiliser pour déterminer le budget nécessaire.

·         Délais. Indiquez quand l'évaluation initiale des risques sera effectuée, et avec quelle fréquence les processus de gestion des risques seront effectués durant le cycle de vie du projet. Les résultats de ces analyses doivent être disponibles suffisamment tôt pour influencer les décisions. N'oubliez pas que les plans détaillés de réponses aux risques doivent être revus périodiquement durant l'exécution du projet pour s'assurer qu'ils fonctionnent correctement.

·         Méthodes d'évaluation (scoring) et d'interprétation. Vous devez définir les méthodes de notation (scoring) et d'interprétation appropriées aux types d'analyses qualitatives et quantitatives des risques utilisées. Les méthodes et la notation doivent être déterminées à l'avance pour assurer leur intégrité.

·         Seuils. Les seuils déterminent le niveau de risques qui sera considéré comme suffisamment important pour s'occuper de ceux qui le dépassent. Le chef de projet, le client et le commanditaire peuvent avoir des perceptions différentes du seuil de risque. La détermination du seuil acceptable permet à l'équipe du projet de classer les risques lors des séances d'analyse. L'équipe développera des réponses différentes dépendamment si le risque détecté se trouve au-dessus ou au-dessous du seuil.

·         Communications. Décrivez comment les informations concernant la gestion des risques seront documentées et diffusées. Ceci comprend les risques, les réponses aux risques et la situation de ceux-ci. Si vous avez déjà traité ces informations dans le plan des communications, cette section pourrait ne pas être nécessaire.

·         Suivi et audit. Décrivez comment les différents aspects de la gestion des risques seront documentés et ce, pas seulement en ce qui concerne ce projet mais aussi au bénéfice d'autres projets à venir car ceux-ci profiteront des leçons apprises lors des projets antérieurs. Vous vous demanderez également si et comment les processus de gestion des risques seront surveillés.

Terminologie de management de projet

Limites de contrôle. Zone recouvrant trois écarts-types de chaque côté de la ligne centrale (la moyenne) d'une distribution normale des données tracées sur un diagramme de contrôle, cette zone reflétant la variation attendue des données. Voir aussi Limites de spécification.

Liaison début-fin (DF). CLien logique où l'achèvement de l'activité successeur de l'échéancier dépend du démarrage de l'activité antécédente. Voir aussi Lien logique.

Abréviations courantes

AC (anglais) : Actual Cost

CR  (français) : Coût réel

Liens intéressants

Logiciel: PMO Advisors LLC

·   Société: PMO Advisors LLC, Wilmington, Delaware, États-Unis d'Amérique

·   URL: www.pmoadvisors.com

·   Catégorie: Gestion de projet basé sur le Web

·   Fonctionnalités:

o    Fournit un portail en ligne pour les activités de gestion de projet et un entrepôt pour le stockage de documents.

o    Offre un accès à plus de 400 pages des meilleures pratiques, des modèles, des lignes directrices et des matériaux de référence.

o    Comprend le matériel pour les ateliers de formation.

7 common risk management mistakes

A lire sur:  http://www.csoonline.com/article/717341/7-common-risk-management-mistakes?source=CSONLE_nlt_update_2012-09-27

Faulty statistical methods and other common errors that can trip up your program

By George V. Hulme

September 26, 2012 — CSO —
Executives know they face risks, but they often don't know which risks are real, or what that exposure means to their business.
The aim of security risk management is to remove the guesswork and help the business make smarter decisions.
As Jay Jacobs, vice president of the Society of Information Risk Analysts (SIRA), says, "Security risk management is simply a decision-support system for the business. It should exist to inform the decisions of the business."
Unfortunately, many experts believe that most companies aren't quite there yet and that their efforts, while well-meaning, fall short and may even incorporate bad habits that can increase an organization's risk.

[Also read Risk's rewards: How to organize for ERM]

Jeff Lowder, president of SIRA, says, "There is a mistaken perception that expertise in security equals expertise in risk management. In fact, we see many experts in security who also claim to be experts in risk management. They're often not. These are two separate disciplines and, ideally, someone is knowledgeable about both if they're performing security risk management."
To get a better understanding of where many enterprises go wrong, CSO asked a handful of experts what they commonly see enterprises do wrong in security risk management. "In many organizations, based on what we've seen, it could actually be better if the organization chose to make decisions based on coin flips rather than their internal security risk management frameworks. At least when you flip a coin, you have a 50 percent chance of getting it right," says Jacobs.
Here are the most common mistakes and misconceptions made in well-intentioned risk management efforts:

1 Starting from scratch.

Many security professionals will attempt to reinvent the discipline of security risk management. Fortunately, there are well-established methods for risk-analysis tasks, such as how to solicit an expert opinion and how to represent uncertainty in risk models. However, as Jacobs and Lowder explain, most people remain unaware of the research about how to do this correctly, and end up re-creating not only the same models but also the same shortcomings that basic approaches suffer from.
"The most prominent model is to pick some 'risk' factors that seem important, assign some ordinal score, and then perform basic arithmetic on these or place them on a matrix that has been shown to produce poorly," says Jacobs. The only saving grace for organizations that rely on these homegrown frameworks is that experienced decision makers often distrust the results these basic approaches produce, Jacobs says.

2 Replicating the audit department.

One way security risk management programs set themselves up for failure, says Alex Hutton, director of operations risk and governance at a large financial services firm and faculty member at IANS, is to copy the functions of the audit department. "While there are similarities between the two, the roles are dramatically different," says Hutton. The audit team should be concerned about where failures can occur through breakdowns in security controls, whereas risk management should be concerned with the potential frequency and impact of IT risks. And where audit's role is to help the company understand how to implement controls, risk management's role is to determine how to get the most out of investments in security controls and related processes.
"Most organizations whose risk management programs end up failing do so because they end up merely enforcing policy rather than consulting to the organization about what controls do and don't make sense," says Hutton.
"Audit doesn't necessarily concern itself with threat and audit doesn't necessarily care about reporting an aggregate picture of risk, based on the entire outlook of threats, assets, controls and impact," says Hutton. "Security risk management does."

1 2 3 »   

12 Common Project Management Mistakes--and How to Avoid Them

A lire sur:  http://www.cio.com/article/717321/12_Common_Project_Management_Mistakes_and_How_to_Avoid_Them?source=CIONLE_nlt_projmgmt_2012-09-27

IT executives and project management experts share their tips for avoiding some of the most common--and costly--project management mistakes.

By Jennifer Lonoff Schiff ,  Wed, September 26, 2012

CIO —

So many projects, so much mismanagement. That's the refrain of many IT executives. Indeed, even with project management software, IT projects often wind up taking longer (much longer) than planned and costing more than budgeted. Why do good projects go bad? CIO.com surveyed dozens of IT executives and project managers and came up with a list of 12 Common Project Management Mistakes -- along with ways to avoid these often time-consuming and potentially costly problems.
Project Management Mistake No. 1: Not Assigning the Right Person to Manage the Project. "Typically during resource allocation, most of the effort is focused on finding the right resources other than finding the right project manager," explains Sudhir Verma, vice president of the Consulting Services & Project Management Office at Force 3, a technology solutions provider. Indeed, too often "project managers get picked based on availability, not necessarily on skill set." However, an inadequately trained and/or inexperienced project manager can doom a project.

Solution: Choose a project manager whose skill set(s) match the project requirements.
[Related: Six Attributes of Successful Project Managers]
Project Management Mistake No. 2: Failing to Get Everyone on the Team Behind the Project. Too often, projects are doomed to fail because they didn't get enough support from the departments and people affected by and involved in the project. Either managers: "1) Didn't make clear what everyone's role was. 2) Didn't describe the personal payoff everyone would get when the project was completed successfully. 3) Didn't tell how each person's contributions to the project would be evaluated. And/or 4) Failed to generate a sense of urgency about the project, leading the team to think business as usual will be fine," argues Bill Rosenthal, CEO of Communispond, which provides employee training on how to communicate effectively.

Solution: "The project manager should start by calling the team together (being certain to include off-site staff via the best technology available) and delivering a presentation about the project and its significance in a way that gets everybody fired up."
[Related: How to Become a Better Communicator With Your IT Staff]
Project Management Mistake No. 3: Not Getting Executive Buy-in.

Solution: "Somebody at the higher levels of the organization needs to own the project from start to finish and be personally vested in its success," says Casey Halloran, co-founder and chief marketing officer, Costa Rican Vacations & Panama Luxury Vacations. "When [a project] has no clear head, things tend to fall apart."
Project Management Mistake No. 4: Putting Too Many Projects Into Production at Once. "Most managers think that they can get more done by starting all projects at once, but in reality, it's counterproductive," says Sanjeev Gupta, CEO of Realization, a Silicon Valley firm that helps organizations complete projects faster. "Multitasking slows people down, hurts quality and, worst of all, the delays caused by multitasking cascade and multiply through the organization as people further down the line wait for others to finish prerequisite tasks."

Solution: "To stop these productivity losses, a good first step is to reduce work in progress (WIP) by 25-50 percent," he says. "This reduces the back and forth and makes managers and experts more responsive in dealing with issues and questions. Though counter-intuitive, reducing the number of open projects by 25-50 percent can double task completion rates."

Continue Reading

1 2 3 next page »

The ins and outs of IT project portfolio management

A lire sur:  http://www.infoworld.com/t/technology-business/the-ins-and-outs-of-it-project-portfolio-management-203133?source=IFWNLE_nlt_advice_2012-09-26

September 26, 2012

When managing the IT project portfolio, don't rank projects by priority -- either schedule them or reject them

By Bob Lewis | InfoWorld

.

Do companies sometimes have to estimate what projects will cost and how long they'll take, even though they have no foundation for their estimates? Yes, they do. As RobertRadina pointed out in a comment on last week's Advice Line, companies typically plan their project portfolios as part of their annual budgeting cycle, when many of the projects are nothing more than concepts. What do you do?
Next-generation IT doesn't have this problem. It does what you would do if you could, which is a better job of project portfolio planning. But if your company isn't hospitable to next-generation IT, you have to estimate anyway. The question then is how to go about it.
[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
How to estimate projects when you know nothing about them
In another comment last week, Mild Mannered Henry suggested taking your worst possible estimate, multiplying by two, then adding another 10 percent. Another commenter, Mike, suggested a more aggressive approach: Start with the worst possible estimate, then square it.
These are fine algorithms, but better is a technique I learned way back when I was earning my reputation for spaghetti coding in my Fortran days: Take your initial gut-feel guess, multiply by two, and move to the next higher unit of time. Thus, a project that feels like it should take four weeks gets an estimate of eight months, while a two-monther gets an estimate of four fiscal quarters.
Do these all sound like jokes? Of course they do. But any estimate given to a project that hasn't been subjected to scrutiny beyond assigning it a name is going to be a joke. Telling one of these jokes because you have an annual planning process to feed is an example of the third-axle syndrome: getting a flat tire, and instead of fixing or replacing it, bolting on another axle while leaving the flat tire alone. In this case, the flat tire is having an annual portfolio planning process in the first place.
Project portfolio planning uses a master schedule, not a master list
Let's start with this: What does a project portfolio look like? To answer, let's start with what a project portfolio isn't: a list of projects with assigned priorities. It doesn't look like this because:

1. A list of projects is about as useful for project portfolio management as a list of tasks is for project management -- which is to say, not at all.
2. Priorities are just as useless, for the same reason.

In case that isn't clear: If you were managing a project, would you build a list of tasks, then sort it based on the relative priority of the different tasks?
A useful project portfolio looks a lot like a useful project schedule: It describes what's supposed to happen, when it's supposed to start, and when it's supposed to finish. Project portfolio management is a matter of managing a project master schedule, not a master list. It consists, that is, of everyone involved in managing the project portfolio agreeing on what's going to happen and when.
Understand this and you'll understand why "prioritization" is useless: If managing the project portfolio means managing the project master schedule, there are no priorities. As the governance practice (not process!) evaluates each project proposal, there can only be two outcomes: "no" and "when." Projects are either added to the master schedule or rejected. There's no other outcome because, really, what would be the point of another outcome?

 

next page › 

12

Des méthodes obsolètes de développement applicatif font peser des risques importants aux entreprises

A lire sur:  http://www.itchannel.info/articles/135482/methodes-obsoletes-developpement-applicatif-font-peser-risques-importants-entreprises.html?key=862d53eea2c1d2fe

Dimanche 23 Septembre 2012

53% des DSI françaises considèrent que l’obsolescence de leurs processus internes de développement ralentit la mise sur le marché de nouvelles offres. Près du tiers des directions des études avouent des retards fréquents entre les phases de développement et de test. Ce qui a bient évidemment un impact sur la perte de clients et la réputation de l'entreprise. Surtout lorsque l'on sait qu'il en découle des problèmes de disponibilité des systèmes et des applications dans le cadre de phases de développement ou de test... Tels sont les premiers constats de l'étude que commente Paolo Restagno, Directeur des Solutions de Virtualisation des Services chez CA Technologies.


La virtualisation des services est une approche révolutionnaire du développement et du test d’applications. Basée sur l’utilisation d’un environnement de services virtuel, elle supprime les contraintes de disponibilité des applications ou environnements techniques tiers. Elle offre un moyen unique de simuler un environnement réel de production pour réduire les coûts, améliorer la qualité applicative et réduire les cycles de développement.

CA Technologies annonce aujourd’hui les résultats de son étude « Les bénéfices métiers de la virtualisation des services », réalisée auprès de 301 entreprises au Royaume-Uni, en France et en Allemagne. Principal enseignement de cette étude : selon plus de 60% des directions informatiques dans les trois pays, les approches traditionnelles de développement et de test freinent la croissance des entreprises et retardent le lancement de nouvelles applications et services.

Cette enquête menée par CA Technologies dévoile également que 53% des directions informatiques, en France, considèrent que l’obsolescence de leurs processus internes de développement ralentit la sortie de nouvelles offres. Ils attribuent à ces mauvaises pratiques la perte de clients (50% des sondés) et une atteinte à la réputation de leur entreprise (49%). Par conséquent, les développeurs français prévoient d’adopter des environnements de développement basés sur le Cloud et des méthodes de développement Agile, afin de réduire les coûts (67% des personnes interrogées), mieux gérer les ressources (59%), réduire les délais de mise sur le marché (53%) et améliorer la qualité (48%).

« Les développeurs de logiciels sont aujourd’hui frustrés par les limites des méthodes traditionnelles de développement et de test. Comme l’indiquent les résultats de cette étude, les équipes de développement et de test des entreprises françaises doivent délivrer en moyenne 6,3 versions par an (contre 7 au Royaume-Uni et 5,9 en Allemagne), mais 26% d’entre elles doivent en délivrer plus de 10 par an. Par ailleurs, même si 4% des développeurs français pensent que les fonctionnalités à mettre en production seront moindres en 2012, ils sont malgré tout 61% à prévoir qu’elles seront plus nombreuses » explique Paolo Restagno, Directeur des Solutions de Virtualisation des Services chez CA Technologies. « Ceci accroît la pression sur les départements informatiques qui doivent délivrer de plus en plus d’applications complexes, malgré les limites de leurs environnements traditionnels de développement. Si les entreprises ne prennent pas rapidement des mesures pour moderniser leurs processus de développement et de tests, je crains que nous n’assistions à une recrudescence d’incidents et de pannes liées à des méthodes de développement obsolètes ».

La virtualisation des services répond spécifiquement à ces défis en permettant aux entreprises modernes de concilier leurs exigences de qualité avec le respect des délais et du budget. Elle aide les équipes à développer et à tester une application à l’aide d’un environnement virtuel, configuré pour reproduire à l’identique un environnement de production existant, tout en facilitant la modification du comportement et des données de ces services virtuels dans le but de valider différents scénarios.

Selon l’enquête de CA Technologies, si 31% des entreprises françaises avouent des retards fréquents (et 33% des retards occasionnels) entre les phases de développement et de test du fait de l’indisponibilité d’applications ou de systèmes, cette proportion est la plus faible comparée aux autres pays couverts par l’enquête. En moyenne, selon les développeurs français, ces retards dans les mises en production peuvent atteindre un trimestre. Ce constat est à l’origine selon eux de la nécessité d’embaucher de nouvelles ressources (66%), de la réduction du nombre de fonctionnalités offertes par une mise en production (61%) et des retards dans la livraison d’applications clients (57%)


Ces conclusions suggèrent que les tests ne sont pas réalisés suffisamment tôt dans le processus de développement (lorsque les bugs sont plus faciles et moins coûteux à corriger) et que les tests réalisés lors des dernières étapes du développement (tests d’intégration et de performances) sont plus coûteux et à l’origine d’importants retards dans la livraison de l’application.

La virtualisation de services permet aux entreprises d’éliminer les freins imposés par l’utilisation des approches traditionnelles et d’accélérer les délais de mise sur le marché. Son principal bénéfice réside dans la capacité des équipes à développer et à tester une application en exploitant une infrastructure virtuelle simulant le comportement, les données et les performances d’un environnement réel de production.

L’ensemble des sondés interrogés dans ces trois pays s’accordent à penser qu’éliminer les contraintes associées aux approches traditionnelles contribuera à la croissance de leurs entreprises, avec pour conséquences : l’accroissement de la satisfaction des clients (80%), la réduction des coûts (76%) et l’amélioration de son image sur le marché (72%).

The black art of estimating IT project costs

A lire sur:  http://www.infoworld.com/t/application-development/the-black-art-of-estimating-it-project-costs-202504?source=IFWNLE_nlt_advice_2012-09-19

September 19, 2012

To estimate a project's expense, you need to understand and plan it. Anything less is a wild guess that will become an albatross

By Bob Lewis | InfoWorld

.

Last week I received a question about project estimation. If you're part of a next-generation IT group, project estimation is a critically important capability. If, on the other hand, you're part of a more traditional IT group, project estimation is a critically important capability.
For that matter, if you play a role anywhere in any sort of business that isn't entirely moribund, project estimation is ... that's right.
[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
For more than a year, Advice Line has focused on next-generation IT: what it is, how it differs from traditional IT, why the differences matter, and how to make it happen.
But every so often I get a question worth sharing that doesn't have a next-gen-IT focus. And so, this week, we resurrect the old Advice Line question-and-answer format.

---

Sensei,
I was re-reading "Bare Bones Project Management" because I just started a new project.
The first thing I was asked: "How long do you think this will take?"
On page 20, your footnote says, "The answer lies in a black art called 'Project Estimation,' which is outside the scope of this book."
Have you ever written anything about this "black art"? Apparently "I have no idea" wasn't a good enough answer!
— Grasshopper
Grasshopper,
Jeez, quote a guy's own words back at him? Words in a footnote, no less?
I've written a bit about estimation, but not very much. It remains, to me, a black art. When I have no choice, here's how I go about estimating a project.
First and foremost, I inform the questioner:

• I won't know the answer until I'm in a position to develop a work breakdown structure that goes at least three layers deep.
• I'd rather not provide a SWAG (scientific wild-ass guess) because of the rule of corporate numbers, which states that any number uttered within anyone else's hearing is immediately chiseled into a slab of granite, there to be enshrined forever as an absolute commitment.
• I also need to know whether my estimate should include or exclude an allowance for contingencies.

The rule of corporate numbers
Understanding the rule of corporate numbers is vitally important to anyone hoping for a career in management, project management, or for that matter, any professional responsibility. The question, "What will this cost?" asked when all you know is the name of a project, is a landmine. If you step on it, shame on you because you've ignored something said by Isaac Asimov years ago: "I can answer any question, so long as you agree that 'I don't know' is an answer."
If a guy as brilliant as Isaac Asimov was comfortable answering, "I don't know," you should be too.

 

next page › 

12

« La maîtrise et la protection de l'information stratégique constituent les domaines de l'intelligence économique »

A lire sur:  http://www.cio-online.com/entretiens/lire-defendre-la-performance-economique-par-la-maitrise-de-l-information-449.html?utm_source=mail&utm_medium=email&utm_campaign=Newsletter

Philippe Ramon

Adjoint du Délégué interministériel à l'intelligence économique, Chef du pôle sécurité économique et affaires intérieures

par Bertrand Lemaire

« La maîtrise et la protection de l'information stratégique constituent les domaines de l'intelligence économique » explique Philippe Ramon, adjoint du Délégué interministériel à l'intelligence économique, Chef du pôle sécurité économique et affaires intérieures.

(17/09/2012) - L'intelligence économique repose sur trois axes : la veille informative sur sources ouvertes, l'influence et la sécurité économique. Existant depuis l'antiquité, elle a été remise au goût du jour grâce aux technologies de l'information.
La délégation interministérielle à l'intelligence économique porte la politique publique en la matière depuis 2009. Elle vise à développer l'économie nationale. La DDIE opère sur les trois axes classiques de l'intelligence économique en les déclinant à sa nature propre : veille, valorisation et aide à l'export.

L'intervention en vidéo

The golden rules of IT projects: Ignore them at your peril

A lire sur:  http://www.techrepublic.com/blog/cio-insights/the-golden-rules-of-it-projects-ignore-them-at-your-peril/39749371?tag=nl.e053&s_cid=e053

By Peter Cochrane

September 13, 2012, 3:23 AM PDT

Takeaway: Having tried and tested rules in place are essential for mission-critical tech projects because when things go wrong you need proper procedures to fall back on.

The RBS systems crash was clearly a self-inflicted disaster that registered an 8 on the IT Richter scale. Photo: RBS

Written in Singapore and despatched to TechRepublic at 3Mbps over wi-fi at London Heathrow.
In any mission-critical situation, it’s vital to have rules, procedures, checklists and cross-checks, and the tried-and-tested must prevail over innovation, guessing and relaxed decision-making.
No matter how many times you have done something, no matter how confident you are, you follow procedures. You check and double-check, never skip a step, and you never wing it.
This thoroughness applies to software and hardware changes and upgrades just as much to flying an aircraft. Procedures and checks are there to reduce the likelihood of human error. Because if things go wrong, they go badly wrong.
So I wouldn’t be surprised if there is now a new phrase in the industry manual: “Doing an RBS”. You’d have had to be living on a desert island not to have heard of the UK IT fiasco affecting millions of Royal Bank of Scotland customers, who were left without money and banking facilities for days. The bank has set aside £125m ($200m) to cover the cost of the crash.
The UK’s Financial Services Authority has just ordered RBS to appoint an independent expert to probe the disastrous sequence of events of last June. Whatever the inquiry concludes, this episode was clearly a self-inflicted disaster that registered an 8 on the IT Richter scale. If the bank had lost customer data it would have been a 9 or a mass extinction event.
It seems impossible to find out what went wrong; RBS chief executive Stephen Hester has denied that cost-cutting was behind the failure. He pointed to a software upgrade managed in Edinburgh, but whatever the true cause, it seems someone really took their eye off the ball and an upgrade went ahead with some significant deviation from agreed procedures.
When you look at the industry best practices, and what should be done, the golden rules are simple:

1. Have at least three backup copies of all data in different physical locations giving immediate, fast and slow recovery abilities.
2. Maintain copies of all variants of the operating system and applications.
3. Apply strong version-tracking and control.
4. Record and save all upgrades.
5. Run three parallel systems online, on, off and a cold reserve.
6. When loading anything new, test it thoroughly.
7. Never load anything untested, uncertified, or unsupervised.
8. Before the day, load everything onto the hot standby and do as much testing as possible for at least 24 hours.
9. When satisfied that all is well, bring the hot standby into frontline service and demote the old online system into standby cold mode.
10. Fire up the cold system and promote it to hot standby status.
11. When the operational system has proved stable, upgrade the software of the hot and cold standby systems.

Needless to say all these measures have to be managed by well-trained and experienced people. You dare not delegate any of these steps to a raw team.
The real details behind the RBS failure are unlikely ever to be made public, but I can guarantee that many banks, finance houses and companies will now be paying special attention and checking their procedures.
No one needs the damage, notoriety and shame of doing an RBS.
I wouldn’t be at all surprised if the continuous cost and people cuts suffered by RBS were conducted by those who know nothing about technology, systems and operations.
And I think we can also assume that some other bank or company is about to experience a similar sequence of events for the same reasons and through the same mechanisms.

Tenstep N°145: Risques positifs (opportunités)

A lire sur: Tenstep

Les risques sont des événements futurs ou conditions qui ont une certaine probabilité de se produire et un certain impact sur le projet. Habituellement, on pense aux risques comme des événements négatifs et on met en œuvre un plan pour les régler.

Toutefois, est-il vrai que tous les risques représentent un danger potentiel ? Disons que votre projet est en train d'utiliser un nouvel outil ou de nouvelles technologies. Est-ce que votre projet est plus risqué qu'un projet similaire qui utilise la technologie actuelle?

À priori, la réponse semble être "oui". Un projet au cours duquel on utilise une nouvelle technologie a plus de risques que celui pour lequel on se sert d'une technologie connue. Votre équipe comprend probablement mieux la technologie actuelle; elle est probablement plus stable. Par contre, si la nouvelle technologie n'est pas si bien comprise, il est plus probable qu'elle rencontre des problèmes inattendus et que votre infrastructure de maintenance ne soit pas suffisamment solide pour faire face aux problèmes potentiels. Même sans spécifier de quelle technologie il s'agit dans cet exemple, il est logique de penser que les projets qui utilisent de nouvelles technologies sont exposés à plus de risques que des projets similaires qui utilisent des technologies matures.

Cependant, s'il est vrai que tous les projets sont généralement plus à risque lorsque vous utilisez de nouvelles technologies, pourquoi iriez-vous entreprendre un projet et vous servir d'une technologie de pointe ? La réponse réside dans l'avantage que vous pensez obtenir pour votre projet. En d'autres termes, l'impact potentiel sur votre projet est positif. Cela est encore conforme à la définition du risque.

·         Il y a un impact sur votre projet. Normalement, les évènements à risque ont un impact négatif sur votre projet. Toutefois, dans le cas de risques positifs, l'impact potentiel demeure positif.

·         Il existe une probabilité que l'événement survienne. C'est encore le cas avec les risques positifs. Dans l'exemple précédent, si les avantages du passage aux nouvelles technologies étaient garantis, vous pourriez prendre la décision d'aller de l'avant avec 100% de confiance. Toutefois, les avantages ne sont généralement pas garantis. La technologie, ou la mise en œuvre de la technologie, pourrait s'avérer mauvaise. Dans ce cas, cela pourrait être pire qu’au début de la création de votre entreprise.

Les risques positifs sont aussi appelés «risques d'opportunité." Dans ces circonstances, le chef de projet ou l’équipe de projet prennent consciemment un risque afin d'obtenir plus tard un avantage ayant une plus grande valeur que les problèmes potentiels liés au risque assumé.

De même, vous pourriez avoir entendu que vous devriez savoir prendre des risques. Dans plusieurs organisations, ils changent cela en disant que vous devriez prendre des risques "intelligents". Ce concept rejoint la question : pourquoi seriez-vous un preneur de risques si ces derniers sont toujours mauvais? Certainement, la raison est qu'il y a aussi plusieurs risques d'opportunité.

L'un des aspects distinctifs des risques positifs est que vous vous placez dans la position de prendre un risque. Les risques négatifs sont des événements négatifs qui peuvent survenir. Ce sont ceux que vous voulez éviter ou éliminer. Les risques positifs sont ceux que vous prenez de bon gré. Ils ne sont pas à l'extérieur. Au contraire, ils sont prêts à ressurgir. Ce sont les risques que vous prenez afin d'obtenir les bénéfices qui leur sont liés.

La tolérance aux risques est bien différente au sein des organisations. Il faut se demander ce qui arrivera si vous prenez un risque positif et que ses bénéfices ne se réalisent pas. Si votre organisation récompense les personnes qui prennent des risques tout en réussissant, mais qu’elle punit ceux qui les prennent mais n’en tirent pas les bénéfices escomptés, c'est qu'elle est réellement opposée aux risques. Il est facile de récompenser les personnes qui prennent des risques et réussissent. C’est la situation face à l’échec à la prise de risques qui détermine si votre organisation est tolérante ou non à la prise de risques positifs.

En général, lorsque vous faites de la gestion de risques, vous faites mention d'événements potentiellement négatifs. Toutefois, vous pouvez également prendre des risques d'opportunité dans l'espoir d'obtenir les bénéfices ayant un lien avec ceux-ci. Ces risques d'opportunité peuvent être gérés de la même manière que les risques négatifs, sauf qu'au lieu d'essayer de les éliminer, la réponse à ces risques comprendra des activités visant à vous donner les meilleures chances de réaliser des bénéfices.

Terminologie de management de projet

Leçons apprises. Enseignement profitable tiré de l’exécution du projet. On peut identifier les leçons apprises à tout moment dans le projet. Ces leçons sont aussi à considérer comme éléments du dossier du projet à inclure dans la base de données des leçons apprises.

Maîtrise. Comparer les performances réelles et prévues, analyser les écarts, évaluer les tendances dans le but d'améliorer les processus, évaluer les alternatives et, au besoin, recommander les actions correctives appropriées. Aussi appelé Contrôle ou Pilotage dans certains pays francophones.

Abréviations courantes

AC (anglais) : Actual Cost

CR  (français) : Coût réel

Liens intéressants

Logiciel: Matchware Inc.

·   Société: Matchware Inc, Tampa, Florida, États-Unis d'Amérique

·   URL: www.matchware.com

·   Catégorie: Mind Mapping

·   Fonctionnalités:

o    Permet aux utilisateurs de représenter visuellement des idées et ajouter des notes, des fichiers et des liens.

o    Aide les utilisateurs à déterminer les budgets et les coûts du projet par l'ajout de valeurs, de variables et d'équations.

o    Permet aux utilisateurs de visualiser l'échéancier du projet, d'examiner le chemin critique, d'assigner des priorités et de définir des valeurs d'achèvement.

Les Directions Générales s'impliquent toujours trop peu dans les stratégies de disponibilité de leur entreprise

A lire sur:  http://www.infodsi.com/articles/135187/directions-generales-impliquent-peu-strategies-disponibilite-entreprise.html?key=

lundi 10 septembre 2012

80% des DSI estiment que la disponibilité de leur entreprise est importante voire cruciale mais ils ne sont que 21% à penser qu’elle relève du niveau de la Direction Générale. Tels sont les premiers enseignements que l'on peut tirer de l'étude menée par SunGard Availability Services. Les clients sont moteurs à 55% d’une stratégie de continuité d’activité (« l’entreprise toujours opérationnelle »), mais seuls 22% des entreprises prennent en compte son impact positif sur les salariés.


Selon les résultats de l'étude menée en juillet 2012 auprès de 100 DSI français par le cabinet Vanson Bourne et commanditée par SunGard Availability Services, acteur majeur de la disponibilité de l’information et de la continuité d’activité, une très grande majorité des sondés (80%) placent la disponibilité de l’entreprise au cœur de leurs préoccupations. L’actualité des derniers mois, où différentes entreprises ont dû faire face à des interruptions d’activités, a par ailleurs mis en exergue les conséquences particulièrement négatives qui en résultent pour les sociétés et leur écosystème.

Le Client, plus que jamais au cœur des stratégies de continuité d’activité, mais un marché encore en quête de maturité.
Si pour 82% des sociétés interrogées, les clients jugent la disponibilité des entreprises comme très importante, voire cruciale, leurs exigences devraient encore s’accentuer dans les 5 prochaines années d’après 61% d’entre elles. Dans ce contexte, 55% estiment que les attentes des clients sont les moteurs d’une stratégie de continuité d’activité. En parallèle, 56% des entreprises perçoivent la disponibilité comme un outil d’augmentation de la productivité et 55% comme un réel avantage compétitif. Ainsi, dans un environnement particulièrement concurrentiel, la disponibilité est devenue un véritable levier de satisfaction des clients.

Cependant, la mise en place d’une stratégie de disponibilité peine encore à sortir du périmètre des départements informatiques. En effet, si la majorité des sondés (56%) l’entendent au-delà de la simple disponibilité du système d’information (ie, en prenant également en compte les hommes, les processus, et les nouvelles tendances), seules 21% des entreprises pensent que l’adoption d’une stratégie de continuité d’activité relève de la Direction Générale, sous estimant ainsi sa dimension stratégique et globale.

« Le concept de l’entreprise réellement disponible nécessite un changement des mentalités accompagné d’une structure organisationnelle à même d’en assurer la gestion » déclare le Professeur Nelson Philips, professeur en stratégie et comportements organisationnels, Imperial College, Londres. « Les sociétés doivent désormais initier les processus et les investissements qui leur permettront d’opérer avec succès la transition vers ce business model afin de bénéficier de certains avantages mis en avant par cette étude, notamment les gains de productivité, de compétitivité, mais également de satisfaction des clients. »

« Dans un environnement international en constante évolution, la disponibilité des ressources peut faire la différence entre le succès et l’échec ! Les pressions sur les sociétés pour maintenir un niveau constant d’activité vont encore s’intensifier, mettant plus que jamais l’accent sur la nécessité d’adopter une stratégie ‘d’entreprise toujours opérationnelle’ », commente Loïc de Montgolfier, Directeur Général Europe de l’Ouest de SunGard Availability Services.

La continuité d’activité : un atout encore mal appréhendé en termes de RH
Au même titre que les clients, les employés ont d’ores et déjà des attentes très fortes dans ce domaine et leurs besoins devraient s’intensifier d’après 52% des entreprises interrogées. Néanmoins, l’amélioration de la satisfaction des collaborateurs, dans le cadre d’une disponibilité accrue de l’entreprise, n’est considérée que par 22% des sociétés sondées. Dans un contexte économique, où les entreprises doivent chaque jour relever de nouveaux défis pour gagner en compétitivité, les employés sont l’une des clés de voute de leur réussite. La capacité d’une entreprise à être disponible, et par conséquent pérenne, constitue un réel avantage, qui semble encore peu perçu, pour recruter et retenir les salariés les plus talentueux.

Source: infoDSI.com

The personal side of board relations: Three things CIOs should know

A lire sur:  http://www.techrepublic.com/blog/tech-manager/the-personal-side-of-board-relations-three-things-cios-should-know/7965?tag=nl.e106&s_cid=e106

By Mary Shacklett

September 18, 2012, 4:12 AM PDT

Takeaway: Mary Shacklett talks about the “behind the scenes” side to relations with the board of directors that can catch many CIOs off guard.

Most of us in technology leadership positions already understand that any technology discussions directed to the board of directors should be in plain English and should relate directly back to the business and how technology will provide benefit. We also know that the dollars and cents side of each technology investment should be carefully spelled out-and that it is important to develop trust and open communications.
But there is also the “behind the scenes” side to board relations that occurs outside of meeting rooms. This is an area where many executives-including CIOs-can be caught off guard.
What makes the CIO particularly vulnerable is that many board members have questions about technology -both for the company and even about the technology they use in their own households.
Here is what can happen:
#1-You propose a new technology solution for the company in the boardroom (let’s say it is a private cloud). Everyone nods their heads in agreement, with little discussion. This can mean total agreement with the proposal-but it can also mean that board members who may not fully understand what you are presenting are afraid to ask a question in an open forum.
Solution: This happens most often in not-for-profit organization operating with “volunteer” boards that might also lack business expertise.  As CIO, I addressed this situation with offerings of outside board education in the form of technology strategy seminars that were company-paid, or even in-house presentations and demos of IT products. The settings are relaxed, and no one is afraid to ask questions. Most importantly, real learning occurs.
#2-You issue company-paid-for mobile devices and PCs to board members so they can do board-related work, but members proceed to let their children do homework on their devices and even freely share their security codes.
Solution: This is a tough one-especially when you have already spent time in board meetings talking about the importance of corporate security! A good approach is to get the board (and your auditors) to define and police a usage policy. This can be done by forming a board subcommittee. Of course, it’s sometimes easier said than done! It took me over a year with the subcommittee to get the usage guidelines defined! This was because many “personal” issues came up-such as, if a board member wanted to add more RAM to his device, could he be reimbursed? Could he have the device serviced wherever he wanted to? These meetings were difficult. But in the end, the board had a set of guidelines for usage that they had defined and that auditors approved.
#3-Theboard tries to “take over” management. You often find erudite technology pros and consultants on the board who are itching to get back into IT operations.
Solution: The job of the board is to define strategy, not to micro-manage company operations. The best person to remind the board of this fact is the CEO– and a very useful vehicle for effecting gentle reminders is to review at least annually the company by-laws-which will surely differentiate the roles of board and management. It is much more difficult road for the CIO if the CEO doesn’t do his or her job in this area. In this case, if you have a board technology subcommittee, this subcommittee can review the by-laws and make its own recommendations to the board.
#3-The job market is tight, so it’s natural for board members to try to secure part-time or full-time employment for their children. IT is a natural area that they gravitate to.
Solution: A good approach is to proactively define job and internship requirements and processes, and also to let managers on your staff who hire for these positions  proceed as they would normally do-and select the best candidate.  The more transparent this process is, the better. If the CEO overrules you, there is not much you can do.-but whatever the result, tranparency of the hiring process is extremely important. So, too, is the CIO’s continued support of staff managers. If a manager makes a hiring section and it is not the board member’s son or daughter, it is the CIO’s (and possibly the CEO’s) job to personally get back to the board member.

Top 5 Types of Project Reports

A lire sur:  Method 123

Most companies have enough reports to go around for everyone on your team to have at least two or three of their own. But, every report takes time to put together, time to maintain, time to read, and time to act upon.

It's your job as a project manager to get to the heart of what is important for project stakeholders to know. To accomplish this below are the:

Top 5 Types of Project Reports

Entire forests could be destroyed if we printed out all the various reports we receive each day to manage our projects. Many reports end up being either auto-forwarded to the Trash bin or they are manually deleted them any time they show up in the Inbox.

Focus on what's important by zeroing in on these top 5 types of project reports:

Report 1: The Project Status Report
The Project Status Report does just that...it provides the general status of the project. This mid-level report should be detailed enough to answer questions about the current health of the report yet not-so detailed that people who read it are lulled to sleep with trivial details. This report should answer the following four questions:

1. Where do things currently stand with this project?
2. What are the next steps on this project?
3. What obstacles are in the way of this project coming to completion?
4. What are the key metrics about this project?

Report 2: The Risk Register
The risk register, or summary of the risk register, is another vital report you want to create. Risks are always lurking in the background of any project just waiting to knock it off course. The risk register identifies those risks, quantifies the potential negative impact they could have on a project, and then offers mitigations plans for each of the identifies risks.

A summary of the risk register could feed directly into the Project Status report as one of the key metrics. For example, you could show the total number of risks that are still open on a project and categorize these by severity. This will give the reader of the report a good indication as to the general state of risk that is associated with each project.

Report 3: The Issue Log
The issue log report is your way of dealing with risks that have either come to realization or an unexpected event occurred. For example, the risk may have been that a particular key resource could find another job and delay the project. The Issue is now that the project is delayed because that resource did find another job. Or, an issue may be an unexpected event such as a coding issue on a software deployment that brought the software to a grinding halt.

This report should show what is ACTIVELY being done to address each issue and prioritize them by area of impact on the project. This can range from "Showstopper" to "Minor Cosmetic" and will then serve as the marching orders for everyone to follow in order to get the project back on track.

Report 4: The Executive Summary
The Executive Summary is a very unique report that is written in a different language than the reports mentioned above. The Executive Summary is a high-level report that can provide a solid understanding of the project status, benefits it will yield, how the project fits into future strategies, and ultimately improves the bottom line of the company. This is written in the mindset of a busy executive who has moments to spend on one of many projects and initiatives that are under their purview.

Keep this report objective and factual. Paint a realistic picture as executives know that everything does not always go as planned. They just want to know that you have a plan for how to corral the project back to where it belongs.

Report 5: Whatever you Want
This is not meant to be a flippant statement. What it is meant to be is a reflection on reality. The reality is that it is hard to have just the right report for every company, project, circumstance, or audience. It's up to you as the project manager to combine the best aspects of each report and come up with whichever one works for you. You'll learn over time which pieces of information are relevant on a report and get the most action and reaction from those who read them.

Make sure this report is easy to generate week after week. You want to spend more time working on what the report tells you rather than working on the report itself.

Get a jumpstart on these top 5 reports plus any others that you need generated by using ProjectManager.com. You can view, print or email your project reports as you wish!