Four Ways to Judge Project Success

A lire sur: Method123

Ah, the ubiquitous triple constraint of project management. Every project must be on time, within budget, in scope - and meet quality standards. Adjust one element of the triple constraint and the other elements must shift accordingly. Unfortunately, meeting the triple constraint is often the only measure of project success, when other factors should be considered. These additional success factors should be listed in the Project Charter or other initiation documents. To verify that your project truly has been successful, here are:

Projects that nail the triple constraint are not necessarily a success. Conversely, projects may be deemed successful without satisfying the triple constraint. Ask yourself the following four questions to determine whether or not your project can rightly be judged a success.

#1 – Is the Client Happy?

One of the best indicators of success on a project is when a client is happy with the results, whether that client is internal or external to the organization. “But,” you may ask, “what if the project went over budget and we weren’t able to bring it in for the amount the client requested?” When that happens, it doesn’t mean the project failed. For example, I just had my house painted. Both the cost of paint and labor ran over budget. I’m still extremely pleased with the results and deemed the project a success.

#2 – Are You Looking Forward to Working Together on the Next Project?

Projects can get a little rough and tumble as people with different personalities, skill sets, expectations, and experience come together to complete a project. There are going to be moments of great exhilaration parallel to instances of deep despair. Does the sum total of these experiences net out to a positive vibe? If you, the team, and your client are able to see the project in your rearview mirror and stay excited about working on the next one - then it indicates that your project was a success.

#3 – Did You Get Paid for the Project?

For external projects, payment is a huge indicator that a project was successful. Let’s face it; if you or your company doesn’t get paid for a project for any number of reasons, it would be considered a huge failure. The client may not be satisfied with the project results (see #1 above). You need to be diligent to ensure this doesn’t happen to you!

#4 – Were the Desired Outcomes Met?

A definition of project success is found in the objectives listed at the beginning of the project. They provide guidance for judging when a project can be considered complete. The list will detail the end state of the project, i.e.,

“The time tracking software will be deployed to all employees across three company locations. All employees will be trained on the software and have a Quick Start Guide to assist. Additionally, the Call Center will be brought up to speed to handle any support issues.”

If the results of the project match the desired outcomes, then it can be considered a success.

There’s more to judging project success than just being on time, within budget, and in scope. The triple constraint is the foundation of project management, but not the end-all, be-all of project success. Ask yourself these four questions and you’ll find your projects reaching an even greater degree of success!

Characteristics of Agile Iterations

A lire sur:  Tenstep
 

Most people understand that the days of the five-year, monolithic project are over - and have been for some time. The better approach is to break large projects into a set of smaller, easier to manage projects. Short projects are easier to manage than large projects. There are fewer things that can go wrong, fewer people involved, less time for scope changes, etc.

The Agile model takes this to an extreme by stating that even the days of the six-month development cycle is over, as is the three-month cycle and maybe even the one-month cycle. Partial solutions should be up and running in a very short time, with very short iterative cycles designed to deliver working code that is built up to a final solution.

Implement Complete Functionality

Agile iterations implement complete functionality for a set of selected customer requirements. This includes the complete mini-lifecycle of analysis, design, construct, test and implementation. The selected functionality within the iteration is not worked on simultaneously. Instead new functionality is worked on as team members are available, meaning at any given time there may be one or more requirements independently going through analysis, design, construct, test and implementation.

Implement Holistically

Each iteration is compressed to a few weeks or even a few days. Short iterations are the result of a holistic set of characteristics of the Agile model. It is not easy to deliver in very short cycles if you pick some of the Agile techniques and ignore others. For example, one of these characteristics of an Agile project is that the product owner is integrally involved in the project and is empowered to make decisions in short timeframes. Obviously you cannot run two week iterations if your product owner consistently takes a week or longer to answer questions and make decisions.

Create Short Iterations

Each team should determine the length of an iteration for its specific project. Shorter iterations are generally better than longer iterations, and 30 days is probably the longest that you want an iteration to last. Shorter iterations tend to squeeze out inefficiencies and overhead processes. For example, you may choose a 30-day iteration because you have a one week approval process at the end of the iteration. If you force the iteration down to two weeks, it will also force this review process to get shorter as well.

Keep Iterations Consistent

It is important that each iteration stay the same length so that your team can develop a steady rhythm of work. If you chose a 30 day iteration, for instance, you need to make sure that each iteration is delivered in exactly 30 days. You don’t want some sprints taking 35, 40 or 50 days. If that happens the Agile discipline breaks down and the project moves more toward a traditional model.

N°165: Gérer les risques

A lire sur:  Tenstep
 

Les risques renvoient aux conditions ou circonstances futures, qui se situent en dehors du contrôle de l’équipe de projet, et qui auront un impact défavorable sur celui-ci si elles se produisent. En d'autres termes, alors qu'un problème majeur est un gros problème qui survient et qui doit être traité, un risque est un futur problème potentiel qui ne s’est pas encore produit.

Un chef de projet réactif gère les problèmes majeurs dès qu’ils surviennent. Un chef de projet proactif essaye de résoudre les problèmes potentiels avant qu'ils ne surviennent. Il s’agit là de l'art de la gestion des risques.

Tous les problèmes majeurs ne peuvent être détectés à l’avance, et certains problèmes potentiels peu susceptibles de se produire, peuvent en fait se produire. Cependant, beaucoup de problèmes peuvent être détectés à l’avance, et devraient être gérés par un processus proactif de gestion des risques.

Diagramme de flux simplifié

Tout dans la vie présente un certain degré de risque. Marcher dans la rue peut être risqué. Vos projets aussi présentent des risques. Le chef de projet devra réaliser une évaluation des risques avec l’équipe de projet et le client pour identifier les niveaux de risques : élevé, moyen et faible. Si vous avez de la chance, vous constaterez que vous avez seulement des risques minimes. Cet exercice préparera le client et l’équipe de projet à l’éventualité de n'importe quel risque (qu’il soit moyen ou élevé), susceptible de poser des problèmes à l’avenir.

Identifier les risques qui menacent votre projet n’est pas nécessairement mauvais, puisque les risques sont communs à tous les projets. En effet, tous les projets ont un certain degré de risque. D’une manière générale, les projets ayant un haut niveau de risque exigent plus de rigueur au niveau de la gestion des risques, et doivent accorder l’intérêt le plus fort à leur gestion générale. Bien qu'on ne puisse pas éliminer entièrement tous les risques, beaucoup peuvent être prévus et gérés à l’avance.

Le but du management des risques est d'identifier quels risques peuvent survenir au cours d’un projet, puis d’établir un plan de gestion de ces risques, afin de réduire le tort au projet. Dans la méthodologie TenStep, la première évaluation des risques se fait lors du processus 1.0 Définir le travail. L'identification des risques supplémentaires doit se faire tout au long du projet suivant un plan défini ou à la fin d’un jalon important.

Terminologie de management de projet

Opportunité. État ou situation favorable au projet, ensemble positif de circonstances ou d'événements, risque pouvant entraîner des conséquences favorables aux objectifs du projet, ou possibilité de modifications positives. À opposer à une Menace.

Partie prenante. Personnes et organisations telles que les clients, les commanditaires, les entreprises réalisatrices et le public, activement impliquées dans le projet ou dont les intérêts peuvent être affectés de manière positive ou négative par l'exécution ou l'achèvement du projet. Les parties prenantes peuvent également influencer le projet et ses livrables.

Abréviations courantes

CPFF (anglais) : Cost-Plus-Fixed-Fee

         (français) : Contrat en régie avec honoraires fixes

Three leadership behaviors of successful project managers

A lire sur:  http://www.techrepublic.com/blog/tech-manager/three-leadership-behaviors-of-successful-project-managers/5643
 

By Andrew Makar

April 6, 2011, 7:14 AM PDT

Takeaway: Andy Makar discusses three leadership behaviors that every project manager should strive to demonstrate. Let us know which leadership behaviors you would add to the list.

A lot of project management articles focus on technical aspects of the work (e.g., the latest tool, template, or technique to help manage scope, schedules, and people), but it’s just as important to focus on the social and cultural aspects of project management. Leadership, teamwork, negotiation, problem solving, and politics also have a significant impact on a project’s success.
Leadership frameworks can be taught in business schools and professional development courses, but leadership behaviors need to be learned and demonstrated. I once worked for a company that identified three specific leadership behaviors that project managers should demonstrate in addition to successful project delivery. Here’s a look at the three leadership behaviors.

Leadership behavior #1: Demonstrate a drive for results

Project management isn’t easy or filled with glory. The reality is that projects are tough and can be stressful, frustrating, and have administrative challenges that can detract from the end goal. Focusing on the tasks that need to be accomplished (regardless of obstacles) and keeping the end goal in mind are easier said than done, but both concepts are critical nonetheless.
Effective project managers take responsibility to achieve the results defined by the project; this means you may not be able to simply delegate tasks to others and wait for the status update. On some of my projects, I never thought I’d be the person responsible for data cleanup in legacy systems or have to conduct menial and administrative tasks in preparation for the next day’s workshop; however, sometimes completing menial tasks and focusing on the end result helps move the project forward.

Leadership behavior #2: Demand the truth

In order to making the best decisions, project managers need to know the real issue or risk affecting the project. Effective project managers need to demand the truth from their teams and then present the truth to their management and peers. Minimizing problems and hiding issues with colorful explanations doesn’t help the project team or the project manager succeed. By asking team members to explain the status in basic terms without corporate rhetoric or political spin, the entire team will benefit.

Leadership behavior #3: Demonstrate courage

Projects don’t always go as planned, and it’s the project manager’s job to present the current status updates and describe any corrective actions needed to improve project performance. In some organizational cultures, there is a tendency to avoid reporting bad news until it’s too late. If you present a positive status update, it may give you a little more time to resolve problems on your own, but when a project is in trouble, project managers often need management support and attention to help turn things around.
It takes courage to communicate that there are problems with the project and to ask for help. It takes courage to have a conversation with a team member who isn’t performing well or to talk with a peer who isn’t providing the necessary support. It takes courage to make the hard decisions to cancel a project to save funding or to let an employee know they no longer have a position with the project. As project managers, these situations are difficult, but dealing with them is our job.

More leadership behaviors

It’s difficult to try to categorize all the leadership behaviors a successful project manager needs to exhibit into just three areas. A commitment to customer satisfaction, a focus on quality, and continuous improvement are secondary behaviors that I’d add to the list. Successful project managers possess the technical project management skills and the leadership behaviors to deliver a project.
What leadership behaviors would you add to the list? Share your feedback in the discussion.

L'explosion des données remet-elle en cause la place du DSI ?

A lire sur:  http://www.zdnet.fr/actualites/l-explosion-des-donnees-remet-elle-en-cause-la-place-du-dsi-39787635.htm#xtor=EPR-100

Analyse : L’importance croissante des données en entreprise conduit-elle à une nouvelle répartition des rôles entre le directeur technique, le directeur des données (CDO) et le DSI ? Pour l’analyste Gartner, Douglas Laney, c’est en tout cas une perspective au sein des grands groupes.

Par Christophe Auffray | Mardi 26 Février 2013

« La donnée devient essentielle, c'est à dire l'essence même du monde numérique » souligne Frédéric Charles sur son blog Green SI. Mais l’importance croissance des données doit-elle pour autant s’accompagner de l’émergence d’un nouveau profil au sein des entreprises, le CDO ou Chief Data Officer ?
Du côté des grands cabinets de conseil, ce CDO a clairement un rôle à jouer. Pour l’heure, c’est toutefois loin d’être le cas. Parmi 300 grandes entreprises interrogées par Gartner, seulement 2% d’entre elles ont nommé un chief data officer.
50% de grands comptes dotés d'un CDO d'ici 3 ans
Sa fonction ?  Gérer ce patrimoine numérique au sein des entreprises et en tirer de la valeur. Cette mission est-elle réellement nouvelle et nécessite-t-elle la création d’un poste dédié ? Ou le CDO n’est-il pas un énième acronyme pour consultant désœuvré ?
Pour l’analyste Douglas Laney, qui s’exprimait à l’occasion de la conférence Business Intelligence et management de l’information organisée par Gartner à Syndey, la réponse à cette dernière question est non. Car il l’assure, le CDO n’est « pas une mode ».
« Je dirais que 50% de ces entreprises [Ndlr : les grandes multinationales] auront un CDO au cours des trois prochaines années. » Mais pourquoi créer un poste supplémentaire quand le DSI paraît lui aussi à même de prendre en charge cette problématique des données ?
Le directeur des données appuyé par le DT sur l'infra
Laney reconnaît que le DSI pourrait assurer cette charge. L’analyste émet toutefois des doutes. « La plupart des DSI sont tellement préoccupés par la technologie qu’ils ont oublié que leur titre comportait la mention 'information'. Ils sont très focalisés sur le côté technologique des choses » objecte-t-il ainsi. Les DSI apprécieront sans doute…
D’autant que le CDO auront notamment en charge les aspects décisionnels, jusqu’à présent pilotés par la DSI, en partenariat, généralement, avec les métiers concernés. Un directeur des données pourrait-il lui se prévaloir d’une maîtrise des aspects techniques de la BI ? Non, sans doute pas, et c’est pourquoi la question d’infrastructure seraient prises en charge par le directeur technique (DT ou CTO).
Une organisation comprenant CDO, DT et DSI, assurant la gouvernance d’unités business, technologie et information, n’est cependant pas adaptée à toutes les entreprises, reconnaît Douglas Laney.

Gouvernance française des entreprises : vers une "vraie" révolution ?

A lire sur:  http://www.finyear.com/Gouvernance-francaise-des-entreprises-vers-une-vraie-revolution_a25238.html

Mme Laurence Boisseau du quotidien Les Échos.fr nous apprend que la France entend déposer un projet de loi à l'été visant à réformer la gouvernance des entreprises. Une révolution se préparerait-elle outre-Atlantique ?

Ivan Tchotourian

Aller plus loin dans l'encadrement des rémunérations des dirigeants, rendre plus transparents les processus de décision dans les grandes entreprises, accorder davantage de droits aux actionnaires. Tels sont les objectifs que se sont assignés les députés chargés d'une mission d'information sur la gouvernance.

Les propositions sont les suivantes :

Sur la rémunérations des dirigeants : Le rapport ne prévoit pas de plafonnement des rémunérations des dirigeants. Mais il entend corriger les excès par la fiscalité. Au-delà d'un montant jugé excessif, les rémunérations pourraient n'être plus déductibles de l'impôt sur les sociétés. Les stock-options seraient beaucoup plus encadrées. La mission prévoit une suppression de la décote, un allongement de leur durée de détention et une interdiction des mécanismes de couverture. Quant aux retraites complémentaires, les retraites dites « chapeaux », elles seraient purement et simplement interdites.

Sur les pouvoirs des actionnaires : Le rapport recommande l'introduction du « say on pay ». Il propose que les actionnaires votent sur la politique de rémunération des dirigeants à venir, mais aussi, ex post, sur le détail des rémunérations spécifiques des dirigeants : fixe, variable, bonus de bienvenue, indemnité de non-concurrence… Pour fidéliser les actionnaires, la mission est favorable aux droits de vote double dès lors que les actions sont détenues depuis plus de deux ans.

Sur la gouvernance des entreprises : Le rapport prévoit d'imposer la présence de deux administrateurs salariés (non actionnaires) au conseil d'administration pour toutes les entreprises de plus de 5.000 salariés. Il veut introduire de nouvelles règles sur le cumul des mandats : quatre mandats d'administrateur maximum pour les personnes qui n'ont pas de fonction exécutive. Ces règles seraient plus restrictives encore pour les administrateurs-dirigeants. Enfin, la mission veut instaurer, par la loi, une obligation de se référer à un code de gouvernance. Non seulement pour les sociétés cotées, mais aussi pour les sociétés non cotées dont le total de bilan dépasse 100 millions d'euros et celles de plus de 500 salariés. Si le code n'est pas appliqué, elle prévoit une injonction du tribunal, voire une sanction. Ce code de gouvernance pourrait être le fruit d'un accord interprofessionnel négocié avec les partenaires sociaux et établi avec l'Autorité des marchés financiers. Autre proposition, il pourrait être celui déjà élaboré par l'Afep-Medef, éventuellement révisé, mais son contrôle pourrait être renforcé. L'AMF pourrait ainsi se prononcer sur la pertinence du code, mais aussi sur son application et sanctionner les entreprises le cas échéant.

Je mettrais le rapport de la mission d'information sur la transparence de la gouvernance des grandes entreprises sur le blogue dès qu'il sera publié. Pas d'inquiétude, je veille au grain !

A la prochaine...


Ivan Tchotourian
Maître de conférences à l'Université de Nantes
Chercheur associé à la Chaire en droit des affaires et du commerce international (Canada)
droit-des-affaires.blogspot.com/

Scale Your Process Based on Project Size

A lire sur: Method 123

We can all relate to the frustration of dealing with a bureaucracy. Some organizations are famous for requiring copious amounts of paperwork but are slow to give real-time access to information. They can exhaust everyone’s patience -  whether it’s to obtain a building permit or permission for something very, very small by comparison.

You can encounter the same frustration if your own processes aren’t customized to fit your projects. Project management practices are not one-size-fits-all.

Take a minute to take an inventory of present or past projects. Are your project management processes always commensurate with the size and scope of the project? Have you had experience scaling processes back or up relative to the number of resources and timeline of the project? Processes designed to control a large scale, lengthy project with hundreds of resources will overwhelm a small, three-week project with a team of five.

Different organizations have different perceptions of small, medium and large project. A large project in one organization may be seen as a small project in another organization. Our scaling model is described below, but yours may be different. To ensure you have the right amount of process in place, use the following guidelines as a point of reference.

Small Projects

A small project employs from one to a handful of resources for three to four weeks. They are typically 250 effort hours or less. The team is tightly knit, meets daily and works in the same location. The process emphasizes near instant approvals with minimal paperwork, wide open communication where questions are answered immediately, and a high level of trust. Clients must be helped to adapt to this light version of project management process to ensure small projects are profitable for the organization.

Medium Projects

A medium-sized project involves many cross-functional resources and lasts three to six months. These projects can be up to 2500 effort hours. Teams are most likely dispersed. The process emphasis is on ensuring everyone stays on the same page with access to real-time information, and keeping clear approvals in place. Functional managers meet weekly and focus on change control and issue management.

Large Projects

It takes all your process know-how to pull off a large-scale, long-term project. A large project engages dozens of people (or more) for six months to years. These projects are from 2500 hours to infinity! You will want to ensure you implement and follow-through on all processes that are part of whichever project management methodology you follow. There’s no room for shortcuts when you are dealing with large project budgets and so many dedicated resources. Large projects require formalized communication plans. Large projects also require a process for corporate governance—regular executive reviews and objective, factual status reports provided to management. As projects get very large, they are also candidates to be broken up and managed as a program.

Scaling processes to project size will save you much frustration, and enable you to efficiently drive your projects to closure time and time again!

Proactively Manage Project Resources Without Authority

A lire sur:  Tenstep

One of the frustrating parts of being a project manager is that it can be difficult to manage the project when you have no formal management authority over the members of your team. From an organizational perspective, if the people do not report to you as a functional manager, then you are probably operating in some type of matrix structure. The matrix makes the most efficient use of people resources, but it can also be very challenging on the part of project managers.

How do you hold team members accountable for their deadlines without this authority?

Proactively Manage Project Resources Without Authority

If team members are missing their deadlines you must first try to determine the cause. For example, if it is due to a lack of skills, this should be addressed through training or replacement resources. If it is because they do not fully understand the expectations you have, then you may have some changes to make as well.

Although the team members do not report to you functionally, their work on the project should still be input into their overall performance review.  You can try to hold people accountable by making sure they understand that you will be providing performance feedback into their review. This should also be reiterated and agreed to by the functional managers

From a process management side, there are project management techniques and processes that should be utilized. First of all, if the availability and performance of the team is in doubt, you should raise this early as a project risk. As part of risk management, you need to put a proactive plan in place to make sure that this risk is addressed. When people miss their deadlines and your deadline is in jeopardy, you may need to raise an issue and perform issues management. During issues management, you again look for the cause of the problem and try to resolve it.

In addition, make sure your team members are communicating proactively with you. In many cases, it is not the fact that people miss their deadlines that gets you frustrated; it is that the team member does not tell you ahead of time. If the team member communicates proactively, you can see the problem beforehand while you still some ability to help. If he just misses the date and does not communicate, then he is not managing expectations as should be done. By the same token, the project manager needs to communicate proactively as well. Communicate well with your team and make sure they understand dates and expectations. Also communicate proactively with the functional managers and make sure they know when there are resource sharing issues or people performance issues.

Matrix management involves a complex and delicate balancing act between project managers and people managers. The project manager usually has limited people management authority in these situations. Even so, it is possible to complete your projects successfully. There are many project management processes and techniques that can help. Utilize them to raise risks and issues when needed. Also, make sure you utilize the project sponsor. The sponsor can help you generate urgency and focus, and can also have an impact on the functional managers to make sure that you have the resources you need to be successful.

N° 164: Élaborer le plan des ressources humaines

A lire sur:  Tenstep
 

Le bulletin "Les meilleures pratiques de management de projet" contient des conseils pour vous assister dans la gestion de vos projets. Il présente chaque fois une autre facette de la méthodologie TenStep. Plus de 3 300 entreprises et consultants dans le monde entier ont déjà choisi TenStep – constatez-le par vous-même en cliquant ici.

Vous pouvez trouver tous les bulletins sur l’hyperlien suivant : Abonnement.

Élaborer le plan des ressources humaines

Allocation du personnel dans une organisation matricielle

Dans les grandes organisations ou les grands projets, on peut se payer le luxe de disposer de personnel à plein temps pour constituer toute une équipe. Cependant, dans de nombreuses (voire dans la plupart des) situations, le chef de projet doit utiliser du personnel réparti ou affecté à temps partiel pour réaliser le travail. Certaines personnes peuvent travailler sur plusieurs projets, alors que d’autres occuperont des rôles (ou des fonctions) de soutien. Le processus consistant à réunir et garder du personnel dans ce contexte peut être problématique et est lié à la manière dont votre organisation est structurée.Dans une organisation matricielle, des personnes sont rattachées à plein temps à une organisation fonctionnelle, mais peuvent aussi bien être affectées, à temps plein ou à temps partiel, à un projet. Dans ce cas, le supérieur hiérarchique sera responsable d’une partie de la charge de travail d’un membre de l’équipe et un chef de projet aura la responsabilité de lui assigner des tâches liées au projet. Si vous êtes dans une structure où le chef de projet n’est pas la même personne que le chef hiérarchique, c’est que vous êtes en train de travailler dans un environnement « matriciel ». L’organisation matricielle est particulièrement efficiente si votre projet ne requiert pas un engagement à temps plein de personnes appartenant à votre organisation de soutien. Le personnel peut être utilisé à temps partiel sur un ou plusieurs projets, tout en continuant à rendre des comptes à une autre structure.

L’organisation matricielle peut être la formule la plus efficace pour utiliser et optimiser le temps et les aptitudes du personnel. Cependant, cela ne fonctionne que si le chef hiérarchique et le chef de projet (ou plusieurs chefs de projets) relèvent les défis et travaillent ensemble pour l’intérêt global de la compagnie.

Vous devez conserver un créneau dans votre planification pour les projets à venir et estimer leurs besoins en personnel. Si vos exigences en termes de personnel ont tendance à beaucoup fluctuer d’un mois à l’autre, ou si le projet ne peut être prévu plusieurs mois à l’avance, vous pouvez du moins planifier l’utilisation d’« une fenêtre » de roulement de trois mois. Ensuite, vous pourrez mettre à jour et affiner le plan suivant une fréquence mensuelle. Pour le mois le plus proche, les données doivent être assez fermes. Pour les deux mois qui suivent, elles devront être assez approximatives. Trois mois et plus est la meilleure hypothèse.

D’autre part, si les projets de votre organisation sont généralement longs et que votre plan du personnel est bien conçu, vous devrez conserver une fenêtre de planification de trois trimestres (9 mois) et mettre le plan à jour tous les trois mois. Le processus de planification devra impliquer les chefs de projets appropriés et les chefs hiérarchiques qui ont tendance à partager des groupes de personnel communs.

Après la planification vient la communication proactive. Gardez à l’esprit le fait que dans une organisation matricielle, les chefs de projet ont besoin de personnel pour accomplir le travail, mais qu’ils ne peuvent en disposer à leur guise, à la différence des chefs hiérarchiques. La responsabilité incombe alors au chef de projet de s’assurer que le personnel sera disponible lorsqu’il en aura besoin, sans être sujet à de mauvaises surprises. Par exemple, si vous vous mettez d’accord avec le chef hiérarchique pour qu’un nombre déterminé de personnes soit disponible pour l’un de vos projets, dans un délai de deux mois, n’allez pas vous présenter deux mois plus tard en vous attendant à ce que tout soit prêt. En fait, vous devriez vous attendre à ce que ces personnes ne soient pas prêtes, dans la mesure où vous n’avez pas réitéré votre demande durant cette période de temps. Le chef de projet doit obtenir l’accord au sujet du personnel deux mois à l’avance. Le personnel devrait être confirmé à la réunion mensuelle suivante sur le sujet. Le chef de projet devrait s’assurer par deux fois qu’il a bien tout son personnel deux semaines avant la date de démarrage, puis une nouvelle fois une semaine avant. Vous aurez plus de chances de disposer de personnel quand vous en aurez besoin si vous passez par ces étapes proactives.

Terminologie de management de projet

Nivellement des ressources. Toute forme d’analyse du diagramme de réseau dans laquelle les décisions concernant l'échéancier (dates de début et de fin) découlent des contraintes de ressources (par exemple disponibilité limitée de ressources, ou modifications des niveaux de disponibilité des ressources difficiles à gérer).

Objectif. Direction donnée à un travail, position stratégique à atteindre, ou but à réaliser, résultat à obtenir, produit à fabriquer, service à fournir.

Abréviations courantes

PMBOK^® (anglais) : Project Management Body of Knowledge

PMBOK^® (français) : Corpus des connaissances en management de projet

5 tips for managing scope changes

A lire sur:  Projectmanager.com
 

Project sponsors have a habit of changing their minds. However there's a way to keep on top of all those scope changes, it's not as hard as it first seems. Learn these...

When you start a project, you think you know exactly what you need to deliver, but then along comes a change. It can be hard to say no to a senior manager, and often the changes suggested are great improvements that you should really incorporate into the project.

So how do you manage the impact on the project scope, the team, the budget and the schedule? That's a lot of things to consider for one change! Here are 5 tips for successfully managing changes to scope on your project.

Tip 1: Record all the changes
First, regardless of where the change comes from, it should be recorded somewhere. Use software to make this job easier as it helps you prepare a consolidated list of all submitted changes and what happens to them afterwards.

Tip 2: Assess changes
Assess all the changes that have been submitted. Some will be great ideas and some won't be! Work out what impact they will have on the project and the benefits, and then you can put forward your considered recommendation to the project sponsor about whether to incorporate them into the project or not. The sponsor will make the final decision, but will be looking to you for that recommendation to approve or reject the change.

Tip 3: Prioritize changes
Assuming the change is approved, you will have to work out what sort of priority it needs. Is it something that you should drop everything for and work on now? Or can it wait a bit longer? Your team can help with this, and you'll also get a view from your project sponsor. Prioritizing is really useful if you have a number of changes as it will help you plan the work in the right order.

Tip 4: Review your plan accordingly
It is rare that you can incorporate a change without changing anything else on the project. Changes will have an impact on the project budget, schedule, resource plan and even the risks and issues log. Go through your entire project and work out what needs to be updated as a result.

Remember to share all the changes with your project team so they are also aware of anything different that they have to do now.

Tip 5: Don't agree to everything!
Don't say yes to anyone who suggests a change until it has been properly analyzed! Otherwise you could promise to deliver something that turns out to be really difficult or not something the sponsor will agree to. And you don't have to agree with your sponsor either. While they have the final say, if you don't agree with a change you can record this in the issues log but you will have to incorporate the change into the project.

Quand les directions métiers s'emparent du numérique

A lire sur:  http://www.distributique.com/actualites/lire-quand-les-directions-metiers-s-emparent-du-numerique-19816.html

Une étude d'OpinionWay réalisée en France à la demande de Microsoft s'intéresse à la conception de l'entreprise numérique par les directions métiers. C'est le grand amour, malgré quelques réserves.

L'entreprise numérique a le vent en poupe. Selon une étude réalisée par OpinionWay pour Microsoft, 84% des décideurs métier sont persuadés du caractère stratégique des technologies numériques pour le succès de leurs entreprises et notamment pour leur propre métier. Cependant, cette déclaration d'amour est plus nuancée. Tout d'abord, tous les décideurs ne se sentent pas une âme de geek, loin de là. 41% se définissent ainsi comme peu ou pas technophiles. Au sein de ces 41%, 23% regardent les choses venir dans leurs entreprises traditionnelles et 18% freinent des quatre fers dans des entreprises déjà très orientées vers le numérique.

Une courte majorité, 59% donc, se définit comme technophile. 21% sont des évangélisateurs enthousiastes du numérique dans des entreprises n'ayant pas encore basculé et 38% se veulent des influenceurs. Cette population de 38% des décideurs métiers est la plus intéressante. Leur approche est pragmatique. Ils veulent avant tout un apport concret à la performance de leur entreprise par la transformation du modèle économique (77% des répondants de cette catégorie contre 62% en moyenne sur l'ensemble des catégories) ou la réduction des coûts (82% contre 74%).

Un Byod encore en devenir

Ceci dit, l'usage personnel des technologies numériques par ces décideurs métiers reste en retrait. Seulement 13% se considèrent comme des adopteurs précoces des technologies numériques et 31% déclarent utiliser un outil personnel, comme un smartphone ou un PC domestique, à des fins professionnelles (démarche Byod). Selon les directions métiers concernées, quelques particularités apparaissent. Ainsi, les directions générales sont intéressées par l'innovation et la réduction des coûts, ce qui est assez proche des préoccupations des directions marketing (compétitivité, nouveaux modèles économiques).

Bizarrement, les DAF sont peu tentés de voir dans le numérique un facteur de compétitivité (19% des DAF contre 33% de l'ensemble l'évoquent). Rentabilité et performance des équipes sont par contre des attentes de leur point de vue (respectivement 33% et 79% des répondants de la catégorie contre, en moyenne 31% et 60%). Les directions de la communication et des ressources humaines sont, de leur côté, intéressées par l'apport en image d'un bon usage des technologies numériques. Pour la DRH, le numérique contribue nettement à la marque employeur.      

A propos de l'étude

L'étude ci-dessus a été réalisée par OpinionWay pour Microsoft. Elle se base sur une enquête réalisée par téléphone, du 10 décembre 2012 au 18 janvier 2013, auprès d'un échantillon de 381 Business Decision Makers (direction générale, direction des ressources humaines, direction administrative et financière, direction marketing, direction communication, direction commerciale) hors direction informatique au sein d'entreprises de 250 salariés et plus. L'échantillon a été redressé pour être représentatif des entreprises de 250 salariés et plus en termes de secteur et de taille salariale.

Open Business : étendre la valeur de son activité

A lire sur:  Innov24

Calqué sur le modèle de l'Open Source Software (logiciel à code source ouvert), l'Open Business invite les entreprises à développer des liens d'inter-dépendances avec l'objectif d'augmenter la valeur de chaque activité.

Le mouvement Open Source prône la coopération plutôt que la compétition dans le logiciel. En effet, chaque développeur construit une brique du code au sein d'un projet global qu'il ne pourrait conduire seul. Fort de ce fonctionnement en réseau, chacun apprend des autres et progresse, tout en réalisant sa part du travail. Il en résulte des logiciels à code source ouvert qui sont massivement utilisés. Ce mode d’organisation a profondément remodelé le marché du logiciel. Aujourd’hui, ce type de travail en réseau inspire aux entreprises de nouveaux modèles économiques. Principe : plus l'activité totale du réseau est importante, plus la valeur de l'activité de chacun augmente. « Appliqué aux entreprises, ce fonctionnement pourrait apporter de la croissance. Non pas à un seul acteur, le plus fort comme on le voit d'habitude, mais à un réseau de PME et de TPE », souligne Michel Vandenberghe, analyste chez IBM et spécialiste des réseaux d'entreprises, qui s'exprime à titre privé. Il résume sa pensée par le concept d'Open Business.

Interdépendance vertueuse. « Rejoindre ces réseaux d'entreprise crée des opportunités de développement sur des marchés qui n'avaient pas été identifiés jusque là », explique Michel Vanderberghe. Par exemple, un fabricant de caisses en bois pour œuvres d’art s’est associé à un spécialiste des puces RFID. Résultat, ils ont inventé la ‘‘caisse intelligente’’ qui a permis de réduire les primes d’assurance. « L'idée, c’est de générer des liens d'interdépendance vertueuse entre les entités de manière à créer un réseau d'entreprises qui se mobilisent sur les mêmes objectifs commerciaux », poursuit le spécialiste des réseaux d'entreprises. « Selon ce modèle, en contribuant au développement opérationnel et commercial d’un écosystème global, chaque entreprise se valorise elle-même. »

Open Business Plan. Pour cela, l'Open Business implique de rédiger un document d'un nouveau genre, appelé Open Business Plan. « Les choses bougent et changent vite. Il faut des contrats ouverts dont les termes ne sont pas complètement définis au moment où les partenaires signent », soulève Michel Vanderberghe. « La méthode, c'est de cartographier l'activité de plusieurs entreprises sur son marché. De repérer les points d'intersection. Puis de développer à plusieurs des offres innovantes capables de correspondre aux différentes formes de coopération possibles. »

© Guillaume Pierre

Photo : Michel Vandenberghe, spécialiste de l'Open Business. © D.R.

How to Save Time on Projects

A lire sur:  Method 123

On projects, there's always too much to do. When you think you don't have enough hours in the day, then read these 5 tips on...

How to Save Time on Projects

The more time you save at the beginning of your project, the more time you'll have left at the end. So check out these 5 top tips:

1. Look at Dependent Tasks
It's just as important to see the big picture as well as the details. Understanding the overall purpose and goal of the project allows you to make decisions and resolve issues that arise.

If you have linked tasks in your plan with a finish-to-start relationship, then think about whether you really need to wait until the first task finishes, or if there is an opportunity to move forward with the second task early.

For example, if you have two tasks called "write requirements" and "design solution" and they are linked in your plan, then do you really have to wait until 100% of the requirements are written before you can begin designing the solution? Maybe you can start the overall design when the requirements are 80% finished. If that's the case then the overall elapsed time for the project will be shorter.

2. Get Rid of Unnecessary Tasks
When you first write your plan, you'll be writing a task list under the impression that everything is achievable, so you'll include all of the tasks you can think of that might need to be included to deliver your project.

However as the project progresses, things change and you'll becometime constrained. It's then that you need to review the list of tasks in your plan and cull anything that isn't absolutely necessary to deliver as part of the project. Some of those "nice to haves" will have to go.

By the way, you don't have to delete the task - but instead just move it to a "Post Project Completion" phase so that once the project is complete, you have some odds and ends to tidy up. This will save you time and make sure that what's delivered is the real "meat on the bones" and not the necessarily the whipped cream on the top!

3. Add More Resources
Are there tasks or deliverables that anyone can do without specialized training? Can you add more people without tripping over each other? If so, then bring in more people and delegate those non-specialized tasks to them-it will save you considerable amounts of time.

4. Outsource Where You Can
If you have confidence in a third party to get the work done, outsourcing part of the project can be a huge timesaver. You might outsource to an external organization, independent contractors or even another department. Just make sure that they take responsibility for the work you give them and include them as through they are a core part of your team. Make them feel loved and don't treat them differently to your full timers and you'll get a lot more out of them.

5. Help Your Team Save Time
Watch everything your team do and where you see inefficiency, help them improve to save time. Also, teach them to delegate their tasks to others, so that they can work smart with their time.

Give them the right tools they need to do the job quickly. React to their needs immediately and make sure they are never "waiting on you" to do their job. If you give your team the right direction, support, tools and love then they will save you time on projects and make your job easier!

If you'd like a toolset that helps your entire team to save time on projects, then try ProjectManager.com.

N°163: Pourquoi tout le monde ne pratique-t-il pas un management de projet efficace ?

A lire sur:  Tensteop

Après la lecture de cette partie, vous vous demanderez sans doute pourquoi tout le monde n’utilise pas de bonnes techniques de management de projet. Peut-être même vous demanderez-vous pourquoi ne les utilise pas moi-même ?

Il y a à cela différentes raisons :

·         Cela nécessite un investissement préalable à la fois en temps et en effort. Nombreux sont ceux qui se considèrent comme des « meneurs ». Ils ne sont peut-être pas très compétents en matière de planification. Souvent, ils ont tendance à discuter d’un problème puis à aller le régler. Cette méthode convient à un petit projet de cinq heures. Elle ne peut nullement s’appliquer à un projet de 5.000 heures. Celui-ci pourra être mené à terme si vous le planifiez correctement ,au préalable et si vous pouvez appliquer la discipline nécessaire susceptible de le gérer efficacement.

·         Votre organisation ne s’implique pas. Il est difficile d’être un bon chef de projet dans une entreprise qui n’accorde pas d’importance aux compétences en matière de management de projet. Par exemple, si vous consacrez du temps à donner une bonne définition du projet et que le client vous demande par la suite pourquoi vous y avez mis tant de temps , vous ne serez sans doute plus très enthousiaste quant à planifier votre prochain projet. Pour être efficace, toute entreprise doit promouvoir un processus commun de management de projet.

·         Vous n'avez pas les compétences appropriées. Vous trouvez peut-être que l’absence de processus de management de projet n’est pas une affaire de volonté mais de compétence. Parfois, on demande aux chefs de projets de gérer ces derniers alors qu’ils n’ont ni la formation ni l’expérience nécessaires. Dans ce cas, les chefs de projet auront tendance à se démener sans disposer de la formation et des outils appropriés pour gérer efficacement les projets. Il se peut que votre organisation ne possède pas un Bureau des Projets (PMO) ou un autre organisme chargé de faire usage de ces compétences en management de projet.

·         La direction pense que le management de projet est un logiciel. Lorsque vous discutez de management de projet avec certains managers, ces derniers pensent, au début, que vous envisagez d’installer un logiciel qui vous permettra d’améliorer votre compétence en tant que chef de projet. A vrai dire, si c’était un logiciel, vous auriez plus de chance des convaincre de sa valeur. Même si certains aspects du management de projet, comme l’élaboration et la gestion de l’échéancier, peuvent avoir recours à un logiciel, ce n’est pas là que réside la valeur du management de projet. La vraie valeur d'une méthodologie de gestion de projets réside dans l’utilisation disciplinée de processus précis et cohérents.

·         Vous avez peut-être été « brûlé » (ou enterré vivant) dans le passé. Dès que vous commencez à parler de processus, de meilleures pratiques et de modèles, un certain nombre de gestionnaires pensent immédiatement surplus de travail, retards et "paperasserie". Ils n’arrivent pas à percevoir immédiatement la valeur qu’apporte une méthodologie. Ce que l'on reproche généralement aux méthodologies c'est qu'elles sont encombrantes, qu’elles produisent beaucoup de papier et qu’elles retardent le travail en cours. Parfois, ces critiques sont légitimes et fondées, du fait que la méthodologie n’est pas adaptée convenablement à la taille de votre projet. Par exemple, si vous devez élaborer une charte de projet de quinze pages, alors que votre petit projet ne représente que 250 heures de travail, vous serez peut-être rebuté par la méthodologie de management de projet. Cependant, ceci n’est pas tant un problème de méthodologie que de mauvaise application de la méthodologie.

·         Les membres des équipes ont peur du contrôle. Nombreux sont ceux qui aiment effectuer leur travail d'une manière qu'ils considèrent "créative", et avec le minimum de supervision possible. Ils redoutent que des techniques de management de projet trop formelles n’entraînent des contrôles plus stricts qui feraient disparaître toute créativité et tout plaisir dans leur travail. Dans une certaine mesure, ils ont raison. Cependant, les procédures standard éliminent une part de la créativité surtout dans des domaines où elle n’a probablement pas à occuper le premier rang. Il n'est pas nécessaire d'être trop créatif lorsqu'on est confronté à une modification du contenu. Il suffit de suivre les processus standard déjà en place.

·         Les chefs de département ont peur de perdre du pouvoir. Si vous voulez réellement qu’une discipline de management de projet soit respectée dans votre entreprise, vous devez donner un certain niveau de contrôle et d’autorité aux chefs de projet. Certaines organisations et certains managers de niveau moyen dans la hiérarchie ne veulent pas partager ce pouvoir. Ils acceptent que le chef de projet s’occupe de la coordination, mais ils veulent, néanmoins, prendre toutes les décisions et tout contrôler. Un management de projet formel ne sera pas possible dans une entreprise où cette peur risque de prévaloir.

Certaines de ces peurs sont naturelles et logiques, tandis que d’autres sont irrationnelles et infondées. Cependant, bien qu’il y ait des raisons d’hésiter à faire appel à un management de projet formalisé, ces peurs doivent être surmontées. La ligne de conduite en management de projet est la suivante: si la méthode de management de projet a pour conséquence une certaine lenteur dans l’exécution du projet, ou que le coût de ce dernier est plus élevé, ou que le projet lui-même soit de qualité moindre, il serait alors insensé de l’utiliser.

En fait, c’est l’opposé qui est vrai: l’utilisation de techniques précises de management de projet feront en sorte que votre projet soit terminé à temps, que le budget soit respecté et que le niveau de qualité soit acceptable.

Ceci dit, lorsque vous utilisez des processus de management de projet, utilisez-les de façon intelligente. Ne créez pas des processus de management pour un projet de 10 milles heures si le vôtre ne nécessite pas plus que 200 heures. Prenez en considération tous les aspects du management d’un projet et faites en sorte que le processus approprié à votre projet soit spécifique.

Terminologie de management de projet

Mettre en œuvre le contrôle qualité. Processus qui consiste à surveiller et enregistrer les résultats des activités liées à la qualité pour évaluer la performance et recommander les modifications nécessaires.

Modification du contenu. Modification du contenu du projet. Une modification du contenu entraîne presque toujours un ajustement du coût ou de l'échéancier du projet.

Abréviations courantes

FPIF (anglais) : Fixed-Price-Incentive-Fee

         (français) : Contrat à prix fixe avec intéressement

DSI : priorité à la BI, au mobile et au Cloud

A lire sur:  http://cloud-experience.fr/dsi-priorite-a-la-bi-au-mobile-et-au-cloud.html#more-2912
 

Posté par Cloudexp le 7 février 2013

Décisions IT : Sans réelle surprise, les DSI vont se concentrer en priorité sur le décisionnel, les technologies mobiles et le Cloud d’après Gartner. Des DSI qui par ailleurs sont de plus en plus mis à contribution en dehors de la sphère traditionnelle de l’IT dans le cadre de la mutation vers l’entreprise numérique.

D’après la dernière étude priorités IT de Gartner (2053 DSI interrogés), les responsables des systèmes d’information des entreprises vont se consacrer en priorité, au cours des prochaines années, sur le décisionnel, les technologies mobiles et le Cloud (IaaS, PaaS et SaaS).
Rien de réellement surprenant dans ce classement, la BI par exemple, gagnant généralement en importance dans des contextes économiques tendus car perçue comme un moyen de créer de la valeur pour l’entreprise.
Budgets IT : -0,5% en 2013
D’ailleurs parmi les 10 priorités business des DSI figurent en tête de classement l’augmentation de la croissance de l’entreprise, les résultats opérationnels et la réduction des coûts. Une baisse des coûts à laquelle la direction des systèmes d’information n’échappera pas, une fois encore, en 2013.

D’après Gartner, le budget moyen de la DSI devrait ainsi reculer de 0,5% par rapport à l’année précédente. Le cabinet relativise toutefois ce paramètre. Les budgets IT « stagnent ou baissent depuis l’éclatement de la bulle Internet en 2002 » fait ainsi remarquer Gartner.
Bref, rien ne vraiment nouveau pour les DSI. Ce qui change en revanche, estime Gartner, c’est l’évolution du métier de DSI vers celui CDO, « chief digital officer », c’est-à-dire de directeur du numérique.
Du DSI au directeur du numérique
Et l’évolution ne serait pas que sémantique, traduisant ainsi le fait que le DSI n’a plus seulement en charge la supervision des systèmes et applications, mais également la mutation vers l’entreprise dite numérique (au travers par exemple de la création de nouveaux marchés et canaux de distribution).
Une transformation qu’illustrait notamment le DSI de Monoprix, François Messager, à l’occasion de la présentation du baromètre CIO 2012 de CSC. Selon lui, la baisse des coûts de fonctionnement n’est pas une fin en soi, mais doit permettre d’ « investir sur des éléments qui sont à grande valeur ajoutée comme le commercial, le client, le cross-canal… ».
« On peut avoir des investissements de long terme de façon à construire l’entreprise pour l’avenir. Et l’informatique est aussi là pour cela. La DSI doit offrir de l’innovation process, métier, parler en très grande proximité avec les métiers et ne pas hésiter à offrir de nouvelles solutions » ajoutait-il.

Lire l’article original.

Directeur informatique : une fonction en pleine mutation

A lire sur:  http://www.itchannel.info/articles/138591/directeur-informatique-fonction-pleine-mutation.html

Dimanche 10 Février 2013

Big Data, Cloud, sécurité & conformité, voilà les trois grandes thématiques du moment au sein des entreprises de la zone EMEA, et leurs principales sources de préoccupation. 

D'après une étude menée par EMC auprès des décideurs informatiques des entreprises de la zone EMEA, 47 % pensent que les technologies d’analyse du Big Data décideront des gagnants et perdants de leur secteur et 46 % que les architectures IT traditionnelles auront cédé la place aux architectures Cloud d’ici à 2016. "Si cette vision semble avoir fait son chemin en Arabie Saoudite (75 %) et en Turquie (60 %), les entreprises russes (32 %) et tchèques (26 %) sont nettement plus sceptiques" indique cependant EMC.

La plupart des entreprises sondées estime que ses priorités informatiques sont alignées sur ses objectifs stratégiques. Et 78 % d'entre elles affirment qu'elles ont les compétences nécessaires en interne pour atteindre ces objectifs. C'est particulièrement vrai en Turquie (87 %), au Maroc (87 %), aux Pays-Bas (84 %), en Pologne (84 %) et en Autriche (83 %). Le rapport souligne toutefois la nécessité de compétences centrées sur les technologies de Cloud Computing et d’analyse du Big Data.

Car, pour 56 % des entreprises, le Cloud Computing fera naître de nouveaux rôles au sein des départements informatiques, et ce, même si les entreprises allemandes et autrichiennes ont des avis plus nuancés. 23 % des entreprises étudiées dans les pays émergents disent également qu'elles pourraient avoir déployé d'ici peu une solution d’analyse du Big Data, contre 18 % seulement dans les pays développés. 48 % des entreprises des marchés développés n’ont d'ailleurs actuellement aucun projet de ce type, contre 33% seulement dans les pays émergents. "Le taux d’adoption des technologies d’analyse du Big Data semble progresser plus rapidement dans les marchés émergents de l’EMEA que dans les marchés développés, constate Adrian McDonald, directeur d'EMC EMEA. Si cette tendance se confirme, les entreprises des pays émergents pourraient s’avérer de redoutables concurrentes pour celles des pays développés et intensifier la pression concurrentielle dans la région".

Enfin, avec le Cloud et le Big Data se pose évidemment le problème de la sécurité et de la gouvernance des données, et ce, aussi bien dans les pays émergents (79 %) que dans les pays développés (75 %). Et ces préoccupations vont s’amplifier à mesure que les entreprises prendront conscience de la véritable valeur de leurs données stratégiques.

Six Reasons You Need a PMO

A lire sur:  Method 123

We all have many wants in our lives but only a handful of needs—food, clothing, and shelter being the top three. Similarly, companies may want many things, but really only find a few things absolutely necessary for survival. A Project Management Office (PMO) should be at top of that list of priorities, along with sales, profits, and growth. Read on for the:

Six Reasons You Need a PMO

1. Consistent Methodology – The bane of many organizations is when departments and groups develop home-grown ways of completing projects. Some processes may work beautifully, some may work terribly; the point is that none are consistent with each other or across the organization. You need a common project management methodology. A PMO allows everyone in the company to speak the same language and follow consistent processes.
2. Economies of Scale – It’s not uncommon for a company to have a half dozen or so timesheet or project management applications within a company, each with its own financial cost for implementation and training personnel. A PMO implements affordable and sustainable enterprise-wide solutions.
3. Objective Opinions – Departments running their own projects can sometimes be compared to a fox watching a henhouse. Project sponsors may be looking for the current status of a project, but a departmental project manager may stretch the truth just a bit so that their department is viewed in a favorable light. A PMO provides an unbiased and objective opinion regarding the status of a project. This is invaluable to project stakeholders and executives.
4. Perpetual Improvement – A PMO is always on the lookout for new and better ways to get things done. They have the benefit of aggregating lessons learned from previous projects and the missive of implementing those best practices across the organization. Additionally, there are countless opportunities for project managers to continue their education and bring newfound knowledge back to their companies.
5. Transcends Departments – “Why can’t we all just get along?” is a common refrain in many companies. One department may go head to head with another department over unrealistic demands or unreasonable timelines. A PMO can mediate their heated conversations and keep everyone focused on the bigger picture. Members of the PMO can facilitate sessions between departments for the purpose of identifying root cause and coming up with alternatives.
6. Reduces Cost – All of the benefits of a PMO as described above are realized at the bottom line. As unnecessary tangible expenses are uncovered, such as paying for multiple versions of the same software, they are removed from the income statement. Real savings derived from resources being able to do their work faster will appear as net income. The value of everyone getting along better? Priceless!

You can benefit from a PMO regardless of the size of your company. Even though larger companies are likely to benefit in greater ways exponentially, a small but growing company needs to at least foster the spirit of a PMO. It’s easier to put the foundation in place while small rather than go back and implement a PMO later.

PMOs and every one can benefit from a pre-built project management process. Take a free 14 day trial of MPMM. Buy now and receive MPMM V5 for free in only a few weeks.