Everything You Wanted to Know About Action Items

A lire sur: Method123

An action item is work that requires follow-up execution. By their nature, action items normally cannot be planned for in advance. They arise on an ad-hoc basis during meetings or as a by-product of working on something else. An action item is assigned because there is not enough knowledge, expertise or time to resolve the item at the time it originally surfaced.

In many cases, action items are trivial in nature, but in other cases they can require substantial work to complete. Action items need to be assigned, worked on later and completed. (If they are not going to be completed, they should not be called action items. Instead, simply note that the item will not be followed up on and then forget about it.) Examples of action items include forwarding information to someone, arranging a meeting and providing a quick estimate on a piece of work. 

Sometimes an action item is established to investigate an area where there may be a potential problem. Because of this, action items are sometimes mixed in with issues. However, this is not right; an action item should not be confused with an issue. An issue is a problem which will have a detrimental impact on the project if left unresolved. An action item may lead to the discovery of an issue or a risk (a potential issue in the future), but the action item itself is not an issue.

There are two common approaches used to manage action items. The best approach is to document the items as activities in the project schedule. A resource and end-date are assigned as well, and the activity is then managed and tracked as any normal activity on the schedule. In general, this is the better approach to follow, because it keeps the work items in one place and allows the project manager to enforce the discipline of knowing ‘if it’s not on the schedule, it will not be worked on.’ This approach also allows the project manager to see the impact of the action items on the schedule. For instance, you may have a small action item that is 3 hours of work. If you assign this action item to a person on the critical path, you may see the resulting delay to your project. This may result in you assigning the action item to someone else instead.

The second approach is to create a section on your meeting minutes for action items. Action items can be placed here if they are trivial (less than two hours) and they are scheduled to be completed by the next meeting. If you use this technique you can start each meeting with a review of the prior action items to validate that they are completed and then cross them off the list.

Don't Mix Issues and Action Items on the Same Log

In many cases, project managers are not using the Issues Log to identify and track true issues. Many items that are classified as issues are really risks (potential problems) or just action items. If you find that your Issues Log has dozens of items on it, you are probably tracking action items instead. Because issues are large problems, there should not be many items open at any one time. If you find that your Issues Log is full of action items, chances are that your true issues are hidden and not worked on as they should.

Green Project Management (GreenPM®)

A lire sur: Tenstep

The world is going green - even in the United States. We are collectively realizing that we do not have an unlimited amount of air or water or space to continue to utilize resources as we have done in the past. The pending warnings about climate change serves as a rallying cry for an environmentally friendly movement that has been underway since at least the 1970s.

How can we apply these "green" concepts to our project management discipline? One obvious way is that we can manage green projects more efficiently. For example, if you are the project manager on a project that will result in a using less packaging in your products, it would be good if your project completed on time. The sooner that project ends, the sooner the green benefits will be achieved.

On the other hand, most project managers do not run these kinds of projects. Most of us deal with projects such as installing a new software package or upgrading network infrastructure. How can these projects become more environmentally friendly?

The answer is green project management.

Green project management is a model where we think green throughout our project and make business decisions considering the environment as a project stakeholder. Here are some examples:

Project Charter

I have seen many Project Charters templates. However, I have never seen a charter with a section on environmental implications. Therefore, I am sure that most project managers never give it a thought as they are defining the project. I am also sure that few project sponsors give it a thought either.

But are there ways that your project can be greener if you would only think about it. For instance, if you are upgrading your network infrastructure, it is likely that some of your equipment will be obsolete. This old equipment should be recycled or donated. 

Managing Issues

You know the process - identify an issue, determine the cause, estimate the impact to your project, look for alternatives, make recommendations, etc. Now let's add a section to the Issues Form to identify environmental impacts - if any. Most issues do not have an environmental impact, but having the section on your template gets you thinking each time. 

The Point ...

The point about green project management is not that we make every decision in favor of the one that is most environmentally friendly. The point is that we start to take the environmental implications into account on our projects. You will make most decisions the same as you do today. But there might be some decisions you would make differently. These different decisions, multiplied by tens of thousands each day across the world, can make a difference.

Imposez la tolérance zéro pour les modifications du contenu

A lire sur:  Tenstep

Beaucoup de projets commencent à accuser du retard parce qu'ils requièrent plus de travail que prévu. Cela peut être le résultat d’une mauvaise gestion des modifications du contenu. Cependant, s’il y a un risque de dépasser la date limite, le chef de projet doit travailler avec les membres de l’équipe et le client pour s’assurer qu’il n’y a absolument aucun travail non planifié qui soit demandé ou effectué, ne serait-ce d’une heure, sans passer par les procédures appropriées de modification du contenu. Toute l'énergie doit être dépensée pour accélérer le noyau de travail qui était convenu, et tout travail additionnel doit entraîner un financement supplémentaire.

Améliorez les processus

Quand vous cherchez la cause du retard d’un projet, vous constatez qu'une partie des procédés internes de travail peuvent être améliorés. Le chef de projet devrait solliciter les réactions en retour des membres de l’équipe et rechercher différentes façons d’améliorer la dynamique du processus sous le contrôle de l'équipe. Par exemple, peut-être tenez-vous des réunions quotidiennes pour faire le point sur la situation et qui sont sans grande utilité. Ces réunions pourraient plutôt se tenir une fois par semaine. Vous pouvez également constater qu'il y a des goulets d'étranglement au niveau de l’obtention de l’approbation des livrables.

Si vous trouvez que les retards sont occasionnés par des processus externes, essayez de négocier des changements de processus, au moins provisoirement. Par exemple, vous constatez que des activités sont retardées parce que les gens doivent travailler à l’évaluation de leurs performances annuelles. Bien que ce soit important, l'exécution de ces évaluations peut probablement être modifiée pour permettre à des activités critiques du projet d’être accomplies dans les délais.

Ceci représente une bonne technique pour les projets en cours de plus longue haleine quand vous avez la chance d'optimiser les processus de votre projet, d'observer les résultats et de les optimiser. Cependant, ceci pourrait ne pas être le cas pour les plus petits projets. D'autant plus qu'il est difficile d'effectuer des améliorations dans un projet de 30 jours. Au moment où vous auriez l’intention d'effectuer quelques améliorations de processus, le projet serait probablement terminé.

Obtenez de nouveaux les engagements

Parfois, les dates limites sont si souvent dépassées que l’équipe n’est plus mobilisée au niveau du temps ou du budget pour la réalisation du travail. Cela se produit notamment si des membres de l’équipe dépassent constamment les dates limites sans que l’on prenne aucune disposition à leur encontre. D’autres commencent alors à se demander pourquoi ils doivent travailler aussi dur pour respecter les délais et les limites du budget, quand leurs collègues ne se sentent nullement concernés. Si cela se produit, le chef de projet doit discuter avec les membres de l’équipe pour obtenir des engagements afin de terminer le travail dans les délais. Il s’agit d’essayer de focaliser à nouveau l'équipe sur les engagements concernant le respect des délais. Le chef de projet doit demander à chaque membre un engagement à titre personnel afin qu’il fasse ce qu’il faut pour être en phase avec les engagements concernant le budget et l’échéancier.

Remontez le moral des troupes

Il se peut que votre équipe soit démoralisée, mais que les membres de votre équipe respectent encore leurs délais. Cela pourrait être bien en ce moment, mais probablement pas pour longtemps. Le fait d'être démoralisé finira par vous causer des problèmes au niveau de votre échéancier. Lorsque les membres de l'équipe sont démoralisés, cela a un impact sur votre échéancier de différentes façons :

·         Le personnel n'est pas engagé à respecter les délais. Même si les membres de l'équipe sont encore dans les délais en ce moment, il y a peu de chances que cela puisse continuer si l'équipe est démoralisée.

·         La qualité en souffrira. Les personnes démoralisées ne se soucient pas vraiment de la qualité de leur travail et il se peut même qu'ils commencent à être négligents ou insouciants. Cela pourrait donner l'impression qu'ils sont en train de respecter les délais mais en fait, beaucoup de travail devra être refait.

·         Ils pourraient démissionner. Quand le moral va mal, les gens pourraient commencer à rechercher de nouvelles opportunités. Si c’est le cas, cela vous causera des problèmes quant à votre projet.

·         Ils passent beaucoup trop de temps à se plaindre. Quand les membres de l'équipe sont démoralisés, ils ont souvent tendance à compatir avec les autres. Vous finirez par avoir une équipe dont les membres passent leur temps à se plaindre au lieu de l'utiliser pour achever les livrables.

L'équipe travaillera plus efficacement et sera plus performante si elle ne passe pas son temps à se plaindre et à se prendre la tête. Le chef de projet doit fixer des objectifs partagés, favoriser un climat de camaraderie et détendre l’ambiance afin de rendre les gens de nouveau heureux et passionnés par leur travail. Pour plus d'information sur la gestion d'une équipe démoralisée, voir 8.2.3. P6 Attaquer les problèmes liés au moral de l’équipe sur tous les fronts.

Terminologie de management de projet

Projet. Entreprise temporaire initiée dans le but de fournir un produit, un service ou un résultat unique.

Processus de planification. Ensemble des processus accomplis pour établir le contenu total du travail, définir et affiner les objectifs, et développer le déroulement des activités nécessaires pour atteindre les objectifs.

Abréviations courantes

OBS (anglais) : Organizational Breakdown Structure

        (français) : Organigramme fonctionnel

A la mi-année votre DSI se conforme-t-il aux 10 questions stratégiques de 2013 ?

A lire sur:  http://www.projeticone.fr/actualites/la-mi-annee-votre-dsi-se-conforme-t-il-aux-10-questions-strategiques-de-2013-2013-07-31

31/07/2013
A la mi-année la tendance ne s’infléchit pas ! Les équipes informatiques sont confrontées à un ensemble impressionnant de défis tant internes qu’externes à l’entreprise. Tout comme les dirigeants exigent plus de la valeur métier extraite de leur IT, les clients exigent plus des produits et services qu'ils achètent, notamment en matière d’engagement et de nouvelles expériences.
Dans ce contexte, les DSI doivent trouver un moyen de concevoir et d'exécuter de nouvelles approches audacieuses afin de satisfaire ces deux besoins simultanément.
En conséquence, les DSI dits « stratégiques » doivent tout retravailler de l'architecture d'entreprise, aux médias sociaux, au déploiement du cloud computing, à l’implémentation de nouvelles expériences client dans un soucis de simplification de leur informatique, d'innovation, de croissance et d’amélioration des processus (ouf !)
Quelles sont donc les 10 questions que le DSI devra continuer d’aborder dans ce second semestre 2013, tant sur le front des défis technologiques que des opportunités métier:
1) Transformer les habitudes concernant les dépenses informatiques en misant sur le cloud computing pour débloquer et libérer d'énormes pans de budgets informatiques. Envisager la transformation voir la disparition de certains métiers.
2) Faire une place au business dit « social » de façon à améliorer la collaboration interne et les engagements externes.
3) Exploiter le Big Data et les nouvelles formes d’analyses pour débloquer de nouvelles opportunités de croissance.
4) Créer des systèmes centrés sur le client et sa culture à travers l'organisation. Elire de nouvelles méthodes de travail agiles au-delà de la simple gestion de projet, rapprocher les équipes dev et ops, s’inspirer des architectures des géants du web pour garantir l’évolutivité.
5) Eprouver la pérennité de votre architecture informatique afin de répondre aux exigences de l’entreprise dans un monde de plus en plus tiré par le mobile, les réseaux sociaux, le Big Data et de l'Internet des Objets. Ne pas inventer ou redévelopper des solutions qui n’apporte pas de valeur métier et surtout un avantage concurrentiel, concentrer l’effort de vos talents sur votre savoir faire ils ne vous en remercieront que trop !
6) Le cloud computing comme agent de transformation métier: basculez votre vision en ne considérant plus le cloud comme un simple atout technologique réducteur de coût, mais comme un différenciateur métier. Arbitrez au sein de votre SI les périmètres éligibles ou non aux différentes formes de cloud et déroulés votre plan.
7) Le Big Data devient stratégique: Big Insights, Big opportunités et Big croissance deviennent les nouveaux thèmes. Ne négligez pas les nouvelles sources de données et ne limitez pas l’intelligence économique à la seule BI traditionnelle basée sur des données purement transactionnelles.
8) Bouger à la vitesse de vos clients: trouver des façons élégantes et évolutives de marier les systèmes transactionnels traditionnels (ERP) avec des systèmes d'engagement plus «social ».
9) Le DSI devient le responsable de la croissance : le DSI doit aider ses dirigeants à accélérer le développement des produits et services pour répondre aux demandes des clients. La latence est l'ennemi! N’oubliez pas d’identifier vos besoins en talents de demain, les formations diplômantes ont un temps de retard sur les ruptures technologiques.
10) Plus d'innovation, moins d'intégration: notre ancienne forme de DSI n’est plus capable de répondre aux nouvelles demandes tout en garantissant les engagements d’hier. Les DSI doivent donc trouver de nouvelles approches efficaces pour répondre aux nouvelles exigences des clients d'aujourd'hui et de demain.
Cette liste est ambitieuse et extrêmement large. L’atteinte ne serait-ce que de la moitié des items serait déjà une réalisation monumentale. Pourtant, le monde extérieur continue de se développer sous de nouvelles exigences, de plus en plus mobile et réactif, de plus en plus contrôlé, et de plus en plus impatient…
Et c’est parce que l'avenir se meut de plus en plus vite, qu’il est nécessaire et viable pour les DSI de s'assurer que leurs entreprises peuvent s’adapter aussi vite que le monde dans lequel nous vivons aujourd'hui!
C'est pourquoi je pense que la liste que est encore d’actualité pour ce second semestre. Même si cette liste n’est pas transposable en totalité à chaque société, elle offre une source de réflexion pour les DSI, qu’ils pourront partager avec leurs collaborateurs ou dirigeants.
D’après une idée de bob Evans

Three Scope Change Management Techniques

A lire sur:  Tenstep

There are a lot of interesting scope change management techniques that can be easily applied to your project. Here are three that will keep you out of trouble.

Make Sure Only the Sponsor Approves Changes

A typical problem on a project is that the team does not understand the roles of the sponsor, client and end users in the area of change management. In general, the project sponsor is the person who is funding the project. If the client were embodied in one person, it would be the project sponsor. The people that the project team tends to work with most often are users. These are the people that use the solution that the project is building. The end users are the ones that will generally make requests for changes to deliverables. However, no matter how important a change is to a user, they cannot approve scope changes. The sponsor (or their designee) must give the approval. If the change is important enough the sponsor will approve it, along with the appropriate budget and duration changes. If the change is not important enough, it will not be approved. 

Saying 'Yes' to Change Requests May not Show Good Client Focus

The project manager and project team sometimes think that they are being client-focused by accepting scope change while still trying to deliver the project within the original commitments. However, if the project is delivered late or over budget, it is usually not good enough to point out all the additional work that was included because of this 'client focus'. 

The sponsor is the primary client representative. Allowing the sponsor (or their designee) to make scope change decisions shows good client focus. If the project team or project manager approves scope changes, he is not showing good client focus from the sponsor's perspective.

An Engaged Sponsor Will Often Say 'No' to Scope Change Requests

One of the neat things about enforcing the discipline of having the sponsor approve scope change requests is that, unless the change is very important, the sponsor will often say 'no'. The sponsor is usually someone high in the organization. He normally doesn't want to hear about requests for small changes. He wants the original project fulfilled within the original commitments for cost, effort and duration. Even though it may be hard for the project manager to say 'no', the project sponsor usually doesn't have any problem saying 'no' to the people in sponsor's own organization.