Four Responsibilities of Executives on Projects

A lire sur:  Method123

An executive has administrative or supervisory authority in an organization. That authority is used in a number of ways on projects. An executive is typically responsible for the Business Case of a project, which is used to determine whether the project should even be started. Once the project is approved they can impact the success of your project in four key areas.

1. Sponsorship and Funding

Every project within a company starts with an idea. It’s hard for that idea to go much further without backing from the right person and some money to make it happen. An executive can provide the sponsorship and funding your project needs to get off the ground. They are responsible for signing off on the project charter, which describes the project, gives you the authority to manage and, most importantly, allocates the necessary funds to keep it alive.

2. Escalations and Resolution

The second role an executive plays in your projects is to be the go-to person when unresolved problems surface. An executive needs to be on the escalation path, and more importantly on the resolution path of your projects. There are going to be times when others are unresponsive to the project’s needs, or in a dispute about the best direction to take. An executive can use his position to break through these bottlenecks. Here’s a hint: shorten the escalation process as much as possible. Rather than go through a gradual escalation of layer after layer of management, take it to the highest level of management and get it resolved in a fraction of the time.

3. Monitor Projects

Executives sponsor and fund projects. They should also be interested in how the project progresses. They should be interested in ore than when the project starts and when it finishes. They should monitor the project. This includes reading and understanding status report, approving major deliverables and being involved in gate reviews. Of course, the projects that are of interest will vary based on the level of the executive. Senior managers should monitor the larger and more strategic projects. Middle managers monitor more tactical projects.

4. Coach Project Managers

Let’s face it: despite the stereotype, most executives are talented, skilled, and experienced people. Tap into their knowledge. You’re going to run into rough patches on your projects from time to time or will need to make decisions when answers are not so obvious. Sit down with a respected executive and bounce some ideas off of them. At the very least, they may validate that you are on the right path or give you the encouragement you need to keep going. More often than not, they will provide you with a fresh perspective to help make your project a success.

If you want to benefit from the value an executive brings to project management, it’s up to you as a project manager to optimize their role on your projects. View them as another resource you need to bring your project to closure. Who knows, with such a great track record of project success, you may end up sitting in the corner office yourself!

7 Tips to Help Project Managers Track Their Tech Teams

A lire sur:  cio.com

IT executives and project managers provide practical advice on how you can best monitor your team and head off potential problems.

By Jennifer Lonoff Schiff
Thu, April 11, 2013

inShare19

CIO — While there are dozens of solutions for managing projects, managing human beings is a bit trickier. So CIO.com asked dozens of IT executives and project managers for their suggestions on how to keep tabs on what your direct reports and team members are working on, how best to monitor their progress and ways to quickly identify and prevent potential problems. Their top seven suggestions appear below.

1. Define what needs to get done by whom by when upfront. "As a manager, it's important for you to clearly define what needs to get done and by what date," says Wayne Mekjian, executive vice president and head of Information Services, Wells Fargo & Company.
[Related: 13 Tips for Keeping IT Projects Under Control]
"Running through various tasks on a list does not give your team enough understanding of what results are expected of them so they can make the right kind of progress," Mekjian says. So it's important to create a roadmap and schedule at the onset--and periodically check in with your team to see if milestones are being met.

2. Use tools that allow team members to share documents and files. "We use Google Docs, which enables us to see the progress on any project at anytime," says John Paul Engel, the president of Knowledge Capital Consulting.
[Related: 7 Must-Have Project Management Skills for IT Pros]
"Even our clients can view the work so they see the progress as well." How does sharing keep projects on track? "Visibility means I have to do less monitoring and reviewing," Engel says. "I trust them to get the work done and if it's not then it's clear to everyone. This level of visibility helps me identify problems early."
3. Meet with your team on a regular basis. "We have a monthly direct reports meeting where we discuss major initiatives, the overall state of the union and allow each person to share updates on what they feel is important," explains Larry Bonfante, CIO, United States Tennis Association (USTA). "Meeting with people on a regular basis ensures that you know how to best support their success and that projects never veer very far off target."
4. Take notes and follow up. "To help keep people and projects on track, I keep regular performance notes in an online performance journal (called Feedback Central)," says Mazin Abou-Seido, director of IT, Halogen Software, a provider of employee performance management services. "This feedback is then used both in my weekly meetings with staff, and to help keep goals on track over the course of the year."

Continue Reading

1 2 next page »

Create Schedule Management Plan

A lire sur:  Tenstep

The Schedule Management Plan describes the process used to develop and manage the project schedule. Not all projects need a Schedule Management Plan, but if your project has a complex schedule that requires special handling, you may find this plan helpful.

The components of the Schedule Management Plan can include:

• Roles and responsibilities. You can describe different roles and their ability to access the project schedule.
  • Schedule owner. This is probably the project manager.
  • Who can update? Normally the project manager, but on larger projects it could be more complex. For instance, a Project Administrator might make the initial schedule updates based on the project status reports and then provide this draft to the project manager for final updates. It is also possible that team members will update the status of their assigned activities and the project manager will perform final analysis after those updates.
  • Who can read? Usually the schedule is not considered confidential - anyone can read it.
• Update frequency. You should describe the timing of schedule updates. In many projects the schedule will be updated on the Monday morning. You should also comment on whether the schedule will be updated weekly or bi-weekly. It is recommended that you update the schedule weekly.
• Progress feedback. This describes how the schedule feedback will be delivered. In many cases this will be in the team member status report. However, it is possible that the progress update will come during a team meeting or through an email.
• Schedule change review and approval. This is where you define the process required to evaluate and approve proposed schedule changes. It defines the authority for accepting and approving changes to schedule. This approval process does not include internal activity deadlines. It applies to changes in the overall project deadline. It is possible that the project manager may have some discretion to exceed the deadline date by some number of days or weeks, but after that threshold some formal body may need to approve the change.
• Tools. Describe about any scheduling tool that will be used on this project, who will have access to the tool and what various people can do with the tool (read the schedule, update schedule, etc.)
• Reports. Comment here on the types and names of reports you are using to manage the project, who will receive them, the frequency of the reports, etc. 
• Schedule integration. Normally each project keeps an independent schedule, but in some instances your master schedule is the result of a roll-up of other underlying schedules. It is also possible that your schedule could be integrated and rolled up to a higher-level program or portfolio schedule.

Plus l'IT progresse, plus le DSI risque d'être dessaisi de ses missions stratégiques

A lire sur:  http://www.cio-online.com/actualites/lire-plus-l-it-progresse-plus-le-dsi-risque-d-etre-dessaisi-de-ses-missions-strategiques-5024.html


Edition du 24/04/2013 - par Bertrand Lemaire

L'informatique remonte dans la hiérarchie des entreprises devant l'importance stratégique du sujet. Du coup, soit le DSI monte d'un cran soit, désaisi, il se retrouve cantonné dans des tâches moins nobles. C'est ce que constate Stéphane Potier, Partner au sein du centre de compétences IT & Opérations du cabinet Roland Berger Strategy Consultants.

CIO : Qu'est-ce qui change dans les DSI en ce moment ?

Stéphane Potier : Les changements sont considérables depuis une dizaine d'années. On le constate avec l'évolution des profils des DSI : il y a dix ans, c'était toujours un technicien; aujourd'hui il est orienté de plus en plus « business ». On trouve même des anciens directeurs généraux d'entreprises plus petites prendre en charge la DSI de grands groupes. Les missions informatiques comme la production ou les études ont globalement peu changé. En revanche, les manières de procéder ont été bouleversées. La place du DSI change également considérablement.
L'IT devenant une préoccupation stratégique majeure, elle se retrouve de plus en plus, dans certains secteurs, sous la coupe, par exemple, de la Direction des Opérations - le « Chief Operating Officer » -. Certains DSI sont promus, d'autres n'ayant pas évolué en tant que Directeur des Opérations ou en DG baissent donc d'un cran - au moins - dans l'organigramme par rapport au PDG.

CIO : Sur les missions de production qu'est-ce qui a changé ?

Stéphane Potier : La production reste sur un mode « il faut que ça tourne ». Autrement dit : « pas de nouvelle, bonne nouvelle ». Mais les entreprises développent leur aversion au risque et doivent faire face à des réglementations de plus en plus contraignantes. Le patron de la production IT, voire le DSI, doit donc gérer le risque. Il doit être capable de garantir l'organisation contre des risques dont la gravité s'accroît avec la place croissante de l'IT dans le fonctionnement de l'entreprise. Par ailleurs, la manière de créer des centres de services partagés (CSP) est changée. Jadis, le responsable de CSP - souvent le DSI- arrivait en disant : « confiez-moi vos outils, je vais les industrialiser et réaliser des économies d'échelle. »
Or, l'industrialisation est longue à mettre en place. Elle commence par coûter de l'argent et les résultats sont hasardeux si on n'a pas toutes les cartes en main. Conséquence: les directions métiers voyaient surtout les coûts s'envoler. Le responsable de CSP doit donc (...)


Lire la suite dans CIO.PDF 62

Anatomie d’un email n°2 : l'objet

A lire sur:  ContactLab

ANATOMIE D’UN EMAIL Chaque élément de votre email peut faire la différence

n°2

L’OBJET

L’objet, avec l’expéditeur, détermine en grande partie le taux d’ouverture. La majorité des messageries permettent de visualiser les 45 à 50 premiers caractères de l'objet. Vous avez donc très peu de place pour persuader, intriguer, surprendre, séduire ou accrocher vos lecteurs afin de les inciter à ouvrir pour en savoir plus. L’objet est aussi une promesse faite aux ouvreurs : il faut ensuite la maintenir dans le contenu. Les éléments les plus importants de votre message doivent figurer dans les 30 premiers caractères Quelques idées d’AB tests d’objets : Factuel vs teaser Long vs court Promotion en pourcentage ou en valeur Avec ou sans symboles Avec ou sans nom du destinataire

Watch Out for PM Mistake #5 - Poor Quality Results

A lire sur:  http://www.blogger.com/blogger.g?blogID=2424826937407221540#editor/target=post;postID=6823866701843716481

This series of emails describes the five most common project management mistakes. In the past four weeks we have looked at a lack of planning (#1), poor scope change management (#2), not keeping your schedule up-to-date (#3), and poor project communication (#4).

The purpose of quality management is to first understand the expectations of the client in terms of quality, and then put a proactive plan and process in place to meet those expectations.

Mistake #5: Poor quality leads to poor results

Like the other common project management mistakes we have looked at, problems with quality show up in a number of areas. For instance:

• Rework. Rework means that you have to fix a deliverable that you thought was complete. Rework is always caused by flaws in your quality management process.
• Higher operations costs. If errors are caught within the project, there is a cost associated with correct and rework. However, quality problems may surface after the solution is in operations. This causes operations (and maybe support) costs to increase.  
• Client dissatisfaction. If a solution is of poor quality, the customer will not be happy. If the customer has a choice, they may not buy from you again. 
• Missed deadlines and budget. Projects that build poor quality products tend to miss their deadlines and exceed their budget. This can cause the entire business case to be less attractive.
• Poor morale. No one likes to work on a project that produces poor quality solutions. Morale and motivation tend to go down on these types of projects.

Don't fear. Quality management can help.

What Can be Done?

There are three main components to delivering quality solutions. 

1. Quality requirements. You cannot meet the customers expectations for quality if you don't know what the expectations are. Quality requirements are identified when traditional functional and non-functional requirements are gathered.
2. Quality control activities (QC). Quality control activities ensure the deliverables are of high-quality. This can include walkthroughs, completeness checklists, etc.
3. Quality assurance activities (QA). These activities ensure that the processes used to create the deliverables are of high quality. This can include third party audits and checklists to ensure that a process were completed.

Everyone on the team needs to have a quality mindset to ensure that work is completed with a minimum amount of errors – the first time.

Five Options for Project Start Dates

A lire sur:  Tenstep

One of the characteristics of a project is that it is a temporary endeavor. In other words there is a start and end-date. This seems simple enough until you start to try to define exactly what these dates mean. Is it after the Project Charter is signed? Is it when the schedule is finalized?

There are no universally recommended definition for either date. It depends on each organization and whether there are any implications for choosing one alternative over another. Here are some of the options for identifying the project start-date.

• The need/idea is generated. The definition you choose can depend on what the implication is. You may choose this definition of project start date if your company is trying to focus on the time it takes between when an idea is generated until the idea is fulfilled. Your company may be concerned that it takes too long to commercialize good ideas. If your company wants to minimize this total time span between idea and fulfillment, you might go with an early project start-date definition like this.
• A budget is approved. In this definition, an idea has been generated and the idea has made it far enough that a cost/benefit statement has been prepared. The project has also made it through the prioritization process and an actual budget has been approved. Keep in mind that the budget may have been approved during the prior year business planning process. The actual work may not start until the following year. Therefore, this definition may also start the clock too early for many organizations.
• A project manager is assigned. This one is more common. The assumption here is that the project manager is the first resource assigned to a project. When the project manager is assigned, the project initiation and planning begins. This is the definition for project start-date in the TenStep Project Management Process.
• The Project Charter is approved by the sponsor. In some organizations the project officially starts when the sponsor approves the Project Charter. Some companies require an approved Project Charter and schedule before the project team can be allocated.
• The project kickoff meeting is held. Using this definition, the planning work is considered to be “pre-project”. The projects starts with a formal kickoff meeting with the major stakeholders and the project team. The kickoff meeting is the time to tell everyone that the project is ready to begin.

In some respects the exact definition of the project start is not as important as whether the definition is applied consistently. For example, if you wanted to compare the time it takes for two projects to complete, it is important that both projects use the same definition for start and end date. 

Tolérances du projet (partie II)

A lire sur: Tenstep

Déclaration de réussite dans une perspective de projet

Une fois que vous avez compris ce que sont vos tolérances (s’il y en a), vous pouvez commencer à évaluer la réussite du projet. Généralement, les membres de l’équipe du projet peuvent déclarer la réussite, si:

1.     Le projet est livré dans les limites du coût estimatif, y compris la tolérance, en plus ou en moins.

2.     Le projet a été livré avant l’expiration de sa date limite, y compris la tolérance, en plus ou en moins.

3.     Tous les livrables principaux ont été accomplis (quelques produits mineurs ou des fonctionnalités mineures peuvent ne pas être livrés).

4.     La qualité globale est acceptable. (Elle n’a pas à être parfaite.)

Quelques entreprises vérifient également si le travail avec l’équipe de projet s’est bien déroulé, c'est-à-dire si le client et l’équipe de projet ont bien travaillé ensemble, s’il y a eu une bonne communication, par exemple. Si le client avait un autre projet (et le choix entre plusieurs entreprises), ferait-il appel à nouveau à la même entreprise ?

Déclaration de réussite dans une perspective d’entreprise

Du point de vue du projet, la déclaration de réussite relève normalement de la responsabilité de l’équipe de projet. Du point de vue de l’entreprise, votre réussite est également liée à la réalisation de la valeur ajoutée promise par les calculs initiaux de ROI. Si le projet est un échec du point de vue du projet, c'est normalement un échec pour l’entreprise également. (Bien que ce ne soit pas toujours le cas : certains projets dépassent leur budget et leur date limite. Pourtant, la solution est toujours considérée globalement comme une réussite commerciale.) Il y a également beaucoup d’exemples de projets qui ont été livrés avec efficacité, et ce, sans avoir produit la valeur ajoutée attendue. Si l’équipe de projet a bien livré les résultats dans les délais qui lui étaient impartis, il n’y a habituellement rien de plus qu’elle puisse faire. Cependant, il est possible que les calculs de rentabilité des investissements aient été biaisés, ou que le marché ait été mal jugé par le client et le commanditaire. Il est également possible que ce projet ait fait partie d'une plus grande initiative. Bien que votre projet soit réussi, l'initiative globale, plus grande, peut être un échec.

Chaque entreprise devrait suivre quelques règles générales pour déclarer la réussite ou l’échec d’un projet dans son ensemble. Votre projet n'est pas un échec si vous dépassez le budget d’un euro, et que vous le livrez avec un jour de retard. Normalement, un projet sera encore considéré comme réussi s'il est mené à terme dans les tolérances de coût et de durée, et qu’il fournit les principaux livrables avec une qualité acceptable. Dans une perspective commerciale globale, d’autres questions devraient être posées afin de savoir si la valeur marchande réalisée correspond aux attentes.

Terminologie de management de projet

Organisation par projets. Structure organisationnelle dans laquelle le chef de projet a toute autorité pour fixer les priorités, affecter les ressources et diriger le travail des personnes affectées au projet.

Planifier les communications. Processus qui consiste à établir les besoins en information des parties prenantes et à définir une approche pour les communications.

Abréviations courantes

EVM (anglais) : Earned Value Management

        (français) : Management par la valeur acquise

Five agile project management migration tips

A lire sur:  http://www.techrepublic.com/blog/tech-manager/five-agile-project-management-migration-tips/2798

By Rick Freedman, January 14, 2010, 12:49 PM PST

Takeaway: Rick Freedman shares five tips for PMBOK, CMM-style shops considering agile migrations. He also recommends an agile PM book that he says is a must-read.

I’ve written previously about the ideas and philosophies that form the foundation of agile project management. The history of project management, especially as it applies to IT, has resembled a pendulum, swinging from the lax controls and do-it-yourself ethic of the early mainframe “glass room” to the rigorous methodological controls and formal software development life cycles (SDLCs) of Project Management Body of Knowledge (PMBOK), Capability Maturity Model (CMM)-enforced practices. Many IT shops have fought painful ideological and cultural battles to make the transition to disciplined project management; in my career, I’ve seen the Project Management Institute (PMI) certification evolve from an obscure and unknown credential to a virtual requirement for employment in many organizations. We’ve also seen CMM certifications become critical differentiating factors, especially for offshore IT service providers, who have used CMM Level-5 certification as an “assurance factor” to help Global 500 firms feel comfortable outsourcing to far-off partners.
I’ve developed project management offices (PMOs) and project management methodologies for large IT firms and service shops, and I’m a strong advocate of adding these disciplines to the corporate toolkit to improve delivery consistency and process excellence. Now that I’m working with firms to train them in agile methods and to help them migrate to agile, however, I’m finding that these same disciplines that brought such strong benefits in project success rates can also be an impediment to agile adoption. Many firms have committed so completely to PMBOK process flows and CMM best practices that many of the core concepts of agile development, such as “barely sufficient” documentation and change-friendliness, seem like heresy.
In fact, I’ve had people in my Agile Project Management classes tell me that their perception of agile is that the key message is “everything you know about project management is wrong.” While this may in fact be the message of some purists in the agile community, I’m much more of a pragmatist, and my counsel to firms migrating to agile methods is that, not only can agile and traditional project methods co-exist, but in fact, in most organizations and for most projects, a hybrid approach is key to success.

Bridge to agile PM

In her outstanding book Software Project Manager’s Bridge to Agility, Michele Sliger walks readers through the PMBOK and relates agile concepts to the well-known Project Management Institute (PMI) knowledge areas and process areas. Sliger’s key message is that both the agile and traditional project management camps have misconceptions about the ideas and capabilities of the other side. Some PMI-focused PMs and organizations believe that PMI and the PMBOK don’t support agile methods, and that migration to agile automatically means abandoning PMI ideals. Conversely, some agile proponents believe that PMPs are so committed to “predictive” project methods that they can’t become agile. By relating the key practices of traditional PMOs, such as time, cost, and risk management, to agile approaches that address the same requirements in a slightly different way, Sliger demonstrates that the foundation disciplines of project management remain intact as your enterprise becomes agile, and that only some tactics and approaches change. For any enterprise considering migration from PMBOK-style project methods to more agile approaches, Sliger’s book is a must read.

Agile lessons learned

From my experience in the trenches, some of my key lessons learned for PMBOK, CMM-style shops are the following points:

• Sell: Evangelizing the benefits and features of agile methods and ensuring that the sponsorship exists to make this often wrenching and difficult transition are prerequisites. Each of your audiences will need a different sales pitch; managers need to understand that agile teams can plan, that we do estimate, and that we can create a long-term strategic roadmap that gives them the information they need to budget and set expectations (ideas that conflict with agile myths). Development teams need to internalize the leaps in self-direction, creativity, and maturity that working in an agile environment can enable. Many agile teams observe that the expectation of self-direction encourages them to take responsibility and ownership of their commitments, and to develop mature skills like facilitation and negotiation. And PMO managers need to understand that their hard-won battles for discipline and consistency were not in vain.
• Train: A robust training program for all audiences is the next key element of a successful transition to agile. The language is different, the development life-cycle is different, and the foundational philosophies of iterative development, constant customer involvement, minimal project management “ritual,” and change-friendliness must be understood and embraced for the organization to be united and prepared for the evolution ahead.
• Pilot: Many organizations transitioning to agile select specific projects, typically suitable for an agile approach due to their innovative nature and their need to quickly respond to changes in the technical, business, or competitive landscape, and run them as “skunkworks” outside the standard PMO line of command. This allows development teams to quickly sidestep some of the process overhead that often accompanies SDLC-compliant programs, without requiring the organization to change its sanctioned approach without proof that agile works, and is suitable culturally for the company. To give a negative example, I recently worked with a team that is experimenting with agile methods, but is still also required to comply with strict PMO documentation and process requirements. This “double duty” is not a fair test of agile methods and, in fact, dooms agile to fail as it requires even more overhead, such as both burn-down charts and Gantt charts, and both story-driven and task-driven project plans.
• Reflect: Once the team has a few agile projects under its belt, honestly reflect on what was best and worst about these efforts. These retrospectives should focus on the process of delivery and the actual deliverables, and should concentrate on the idea of balance and adaptiveness. Which elements of the existing, PMBOK-compliant methods must stay, because they add real value and also provide the predictability and comfort level management needs? Which agile methods have demonstrated that they can enhance the creativity and self-motivation of the team, and boost the collaborative spirit between the development team and the business sponsors?
• Adapt: Adaptiveness is, in my view, the key to successful agile implementations. In fact, Jim Highsmith, a signatory of the Agile Manifesto and the author of the influential book Agile Project Management, uses the language of “adaptive development” as his core explanatory term for these methods. The agile approach that any enterprise adopts must be adapted to fit the culture, the risk profile, the history, and the preference of all the affected audiences. By experimenting with agile methods in some key “skunkworks” projects, honestly assessing their successes and challenges, and looking for the right mix and balance for your organization, your chances of a successful migration increase substantially.

Just as many firms took a long time to evolve from the “glass house” of mainframe development to the disciplined approaches of SMM and PMI, firms should expect migration to agile to be a process, not an event. Small steps are more easily digested by all audiences, and, although they may not bring the quantum leap in innovativeness and speed that a rapid agile adoption might, they make up for that by being acceptable and comfortable, and by preparing the way for success iteratively and incrementally, and iterative and incremental improvement is what agile methods are all about.

How to Work More Effectively

A lire sur:  ProjectManager.com

Here are 5 tips to help you collaborate with your team, so that you can all work more effectively...

With more teams working in different offices, travelling and working at home these days, the chances are that some of your team members don't work in the same building as you from time to time. This can present a challenge: how can you work with them when you can't meet them physically?

Online collaboration tools are the easiest way to work effectively with people on a project, wherever you are. There are even benefits if you are all based in the same office space. So here are 5 tips to help you...

Tip 1: Keep all your discussions online
One of the most effective ways of working is to move everything online. Online collaboration software can help you do this, as it is designed for running projects on the web. The benefit of having all your project information and discussions online is that everyone can see the latest status at any time. You can even move your emails online into the software that you are using so that the whole discussion trail is in one place.

Tip 2: Use instant messaging
Instant messaging is great for getting the answer to a quick question, or checking if one of your colleagues is available for a longer discussion. You can archive your messaging trail securely online so that if you need to refer to it later it's there in your project files. It's faster and easier than email and once you start using it you'll never look back.

Tip 3: Share pictures
Do you know what all your team members look like? That might sound like a silly question, but if you are working with colleagues overseas or even in a different office, you may never have met them. Even if you have met them, chances are someone on your team has only ever talked to them on the phone. Upload photos to your team area so that you can see each other. It's easier to collaborate if you can put a face to a name!

Tip 4: Upload files
Stop sending huge email attachments by uploading all your core project files to a central online location. Using a document repository like this means that everyone always has access to the latest version, which can be a massive time-saver. It also means that people don't get frustrated looking for the latest copy and your IT department will be very happy that you aren't using your inbox as a document store!

Tip 5: Share calendars
It can be difficult to collaborate with team members if you don't know where they are. Sharing calendars means you can check if they are on leave or out of the office, and schedule meetings appropriately. You can also put key project milestones in the calendar so that everyone knows what is coming up without having to look at the project schedule. Make sure that you keep your own calendar up-to-date as well and include all the national holidays that are appropriate for your international team members, so you know when their offices are likely to be closed.

DSI et digital workplace, du passé faisons table rase ?

A lire sur:  http://www.atelier.net/trends/chronicles/dsi-digital-workplace-passe-faisons-table-rase

Anthony Poncier

Associé et «social business director» EMEA - Publicis Consultants Net Intelligenz
En savoir plus sur l'auteur

25 mars 2013

Mots-clés : Innovation, Management, Gartner, Anthony Poncier, entreprise 2.0, Jane Mc Connel, Europe

Pendant longtemps les DSI ont géré les dossiers liés au digital. Mais avec l'avènement du SaaS, beaucoup de métiers ont mis en place notamment des réseaux sociaux d'entreprises hébergés chez l'éditeur.

Une DSI désavouée ?
En partie désavoués dans leurs choix (même si certaines DSI ont compris qu’elles devaient faire évoluer leur rôle vers plus de stratégique et d’ouverture), beaucoup de directions des systèmes d'information restent accrochées à leurs vieilles approches projet. Et c’est sans parler de celles qui souhaitent développer leurs propres outils ou n’être qu’en lien avec un éditeur partenaire. Au final, de plus en plus souventc’estla direction de la communication, accompagnée des métiers et parfois de la DRH, qui prenden main ce type de projets digitaux limitant - au mieux -  la DSI à un rôle d’accompagnateursur le choix de l’outil. Ce schéma, pour caricatural qu’il soit, a largement contribué à faire la démonstration que ces questions n’étaient pas un problème d’outils, mais bien d’usage et de réponses à des besoins métiers. D’ailleurs une part non négligeable des projets relatifs à des questions IT et les budgets qui y sont liés, sont portés dorénavant par la communication et le marketing.
Quand Gartner annonce que 80% des projets collaboratifs vont "planter" à cause d’une vision outil, on se dit que peut-être certains enjeux n’ont pas été correctement abordés, notamment l’adhésion des utilisateurs finaux.
S'il ne s’agit pas de faire porter un chapeau trop large à la seule DSI, la question de leadership se posant aussi, force est de constater qu’un déploiement réussi de projet collaboratif est trop souvent anecdotique : la vision outil ayant primé sur le reste.
La montée en puissance des digital workplace
Peu importe, le nouveau projet à la mode est la digital workplace, incluant RSE, communication unifiée… Pour reprendre la définition de Jane Mc Connel : "Un écosystème de plateformes d’entreprise et de services qui permettent de travailler, collaborer, communiquer, développer des services et produits afin de mieux servir le client final". Tout est dans "écosystème de plateforme d’entreprise et de service". C’est le grand retour de la DSI, qui doit brancher tout cela avec le SI existant, et qui, malheureusement, transforme le tout  en grand portail de services de type "année 2000" ou en intranet à tout faire.
Et nous voilà repartis dans un long "effet tunnel" de plusieurs mois, avec des spécifications techniques à ne plus savoir quoi en faire. On repart à zéro. On fait table rase du passé. Oubliés les échecs liés à ce type d’approche !  Les temps de déploiements d’outils collaboratif sont multipliés et qu’importe que l’utilisateur final soit quelque part perdu dans les limbes du projet.
Comprendre que la réussite ne passe pas, par la multiplicité des fonctionnalités et des branchements, semble avoir été oubliée avec l’apparition de ce nouvel espace digital. Mais comme à toute chose malheur est bon, on assiste à un retour en force de la DSI et à une expertise dont elle est à la seule à pouvoir se prévaloir.
C’est la revanche de la DSI qui a du mal à reprendre la main sur les projets de RSE…  Question : même méthode et même échec en perspective ?

En savoir plus

Réseau social en entreprise : "Evaluer l'équipe, plutôt que l'individu"

Marketing & PublicitéSociété & Usages16 juin 2011

Des bloggeurs pas si crédibles que ça pour les entreprises ?

16 mars 2012

Entreprise 2.0 : la tête et les jambes

InnovationManagement09 janvier 2013

Sur Twitter, le citoyen est le meilleur porte-parole de son pays

Marketing & PublicitéSociété & Usages17 avril 2012

PROJECT MANAGEMENT MISTAKE #4: Poor project communication will cause many projects to end unsuccessfully

A lire sur:  Method 123

This series of emails describes the five most common project management mistakes. In the past three weeks we have looked at a lack of planning (#1), poor scope change management (#2) and not keeping your schedule up-to-date (#3).

PROJECT MANAGEMENT MISTAKE #4: Poor project communication will cause many projects to end unsuccessfully

Many years ago, a good project manager might have gotten away with being a poor communicator. The customers typically didn’t like it, but as long as the project manager could deliver the goods, the customer may have been inclined to let them do their own thing. In today’s world, however, projects need to be undertaken in partnership with the sponsor and customers, and this partnership absolutely requires solid communication. In fact, many of the problems that surface on a project are actually the results of poor communication. A project Communication Plan can help but still needs to be proactive. Poor communication can lead to the following trouble areas.

Differences in expectations

Project managers need to strive to ensure that all stakeholders have a common set of expectations. Perhaps it is just as simple as not informing some stakeholders that the project end date was changed from December 31 to March 31. People make decisions based on the information they have at the time, and if the project manager does not keep everyone under a common set of expectations, things can start to get out-of-sync fast.

People are surprised

If people are not kept informed as to what is going on, they will be surprised when changes occur. Proactive communication means that you keep people up-to-date. People get angry and frustrated when they find out bad news at the last minute, when there is no time left to have an impact on the situation. 

No one knows what the state of the project is

On some projects, people are not really sure what the status is. The communication on these projects is short and terse and does not give the reader a real sense as to what is going on. This leads to confusion and missed expectations.

People are impacted by the project at the last-minute

This is a prime cause of problems. In this situation, the project manager does not communicate proactively with other people about things that will impact them. When the communication does occur, it is at the last minute and everything is rush-rush. This frustrates people and leads to inevitable conflicts.  

Team members don’t know what is expected of them

Poor communication also occurs within a project team. Some project managers do a poor job of talking with their own team to explain what they are expected to do. This causes extra work and extra frustration on the part of the project manager and team members alike.

What’s the solution?

In most cases communication problems are not based on a lack of skills, but a lack of focus. Many project managers place communication on the bottom of their priority list. When they do communicate, it tends to be short and cryptic, as if they are trying to get by with the minimum effort possible.

The key to communicating is to focus on the reader - not yourself. Try to think about what the receiver of the communication needs and the information that will be most helpful to them. 

Many projects have problems. Poor communication can cause many problems and aggravate others. On the other hand, proactive communication can help overcome many other mistakes. Don’t consider communication to be a necessary evil. Instead, use it to your advantage to help your project go smoothly with less frustration, less uncertainty and no surprises.

Seven Components to a Risk Management Plan

A lire sur:  Tenstep

The Risk Management Plan describes how you will define and manage risk on the project. This document does not actually describe the risks and the responses. This document defines the process and techniques you will use to define the risks and the responses. The information in this plan includes:

• Roles and responsibilities. This section describes the leading and supporting roles in the risk management process. The project manager typically has overall responsibility for risk management, unless the team is large enough that this role can be delegated to another team member – perhaps a specialist. Third-party risk management teams may also be able to perform more independent, unbiased risk analyses of project than those from the sponsoring project team.
• Budgeting. Discuss your budget for risk management for the project. Since you may not know enough to request budget for risk management you can also describe the process that you will use to determine a risk management budget estimate.
• Timing. Defines when the initial risk assessment will be performed, as well as how often the risk management process will be conducted throughout the project life cycle. Results should be developed early enough to affect decisions.
• Scoring and interpretation. You should define risk scoring and interpretation methods appropriate for the type of the qualitative and quantitative risk analysis being performed. Methods and scoring must be determined in advance to ensure consistency.
• Thresholds. The threshold level is how you determine which risks are important enough to act upon.  The project manager, client, and sponsor may have a different risk threshold. The acceptable threshold forms the target against which the project team will analyze risks.
• Communication. Describe how the information on risk will be documented and communicated. This includes the risks themselves, the risk responses and the risk status. 
• Tracking and Auditing. Document how all facets of risk activities will be recorded for the benefit of the current project, future needs, and lessons learned. Also describe if and how risk processes will be audited.

Tolérances du projet (partie I)

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.

Tolérances du projet (partie I)

Vous avez tous lu des histoires au sujet du grand nombre de projets qui échouent. Selon les rapports que l’on lit, on apprend que plus de la moitié, voire 80% d’entre eux échouent! Selon ces mêmes rapports, plus le projet est grand, plus il y a de chances qu'il échoue. Cependant, si vous considérez les projets dans votre entreprise, diriez-vous vraiment que 80% d'entre eux sont défectueux? 50% d’entre eux seraient-ils même considérés comme des échecs? Il n'y a aucun doute que quelques-uns sont des échecs absolus. Ils subissent des accidents, sont annulés, prennent fin nettement au-delà du budget et de la date limite, ou sont inférieurs aux attentes. Cependant, y a-t-il vraiment 50% à 80% des projets qui correspondent à cette définition ?

Tolérances

Pour répondre à la question de savoir combien de projets ont échoué, vous devez d'abord comprendre la définition d'un projet raté. Le concept qui joue un rôle clé, dans ce contexte, est alors celui de tolérance. Si vous estimez qu'un projet coûtera 230.000 €, est-ce que votre projet est un échec si le coût effectif est de 230.500 €? Vous avez dépassé votre budget, n’est-ce pas? Oui, mais ceci entre dans la zone de tolérance. Si vous livrez avec moins de 500 € de dépassement sur un budget de 230.000 €, l’équipe devrait vous porter sur ses épaules et vous faire faire le tour des bureaux de votre entreprise, tellement cela relève de l’exploit.

Votre entreprise doit établir le niveau de tolérance qu’elle considère raisonnable pour ses projets. Dans certaines entreprises, par exemple, le niveau de tolérance varie de -10% à +5%.

Si vous fournissez le projet avec un dépassement de budget de 5%, il sera toujours considéré comme une réussite. Pour notre projet de 230.000 €, cela signifie que nous pourrions avoir un dépassement de budget allant jusqu’à 11.500 € et continuer à le considérer comme étant réussi.

D’autre part, si le coût final est en dessous de plus de 10% par rapport au budget, cela posera également un problème. Ici, le problème est que l’entreprise doit normalement livrer des projets qui répondent aux attentes : si le commanditaire avait su que le projet coûterait réellement beaucoup moins que ce qui avait été estimé, il aurait pu prendre d'autres décisions concernant le budget inutilisé. L'estimation des coûts doit être aussi précise que possible et devrait également inclure tout changement du contenu formellement approuvé. Si votre budget original était de 200.000 € et que le client a approuvé 30.000 € complémentaires dans le cadre des modifications du contenu, le montant final dont vous aurez la responsabilité est de 230.000€, plus les tolérances.

Normalement, il y a également des tolérances concernant les dates limites. Si vous estimez la durée d’un projet à six mois et qu’il est achevé en six mois et une semaine, cela est normalement acceptable. Votre date limite originale doit également être reportée si des modifications du contenu ont été approuvées. Naturellement, tous les projets n’ont pas cette flexibilité. Les projets de logiciels de passage à l’an 2000, par exemple, devaient être fins prêts pour le 31 décembre 1999. Une semaine de retard n’aurait pas été concevable.

Terminologie de management de projet

Organisation matricielle. Structure organisationnelle dans laquelle le chef de projet partage avec les responsables fonctionnels la responsabilité de fixer les priorités et de diriger le travail du personnel affecté à ce projet.

Planifier le management des risques. Processus qui consiste à définir les méthodes de conduite des activités de management des risques d'un projet. Aussi appelé Planifier la gestion des risques dans certains pays francophones.

Abréviations courantes

CV (anglais) : Cost Variance

EC (français) : Écart de coût

10 best practices for successful project management

A lire sur:  http://www.techrepublic.com/blog/10things/10-best-practices-for-successful-project-management/904

• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  
• 
  

By Tom Mochal

July 23, 2009, 2:10 PM PDT

The right mix of planning, monitoring, and controlling can make the difference in completing a project on time, on budget, and with high quality results. These guidelines will help you plan the work and work the plan.

---

Given the high rate of project failures, you might think that companies would be happy to just have their project finish with some degree of success. That’s not the case. Despite the odds, organizations expect projects to be completed faster, cheaper, and better. The only way that these objectives can be met is through the use of effective project management processes and techniques. This list outlines the major phases of managing a project and discusses key steps for each one. Note: This article is also available as a PDF download.
PLANNING

1: Plan the work by utilizing a project definition document

There is a tendency for IT infrastructure projects to shortchange the planning process, with an emphasis on jumping right in and beginning the work. This is a mistake. The time spent properly planning the project will result in reduced cost and duration and increased quality over the life of the project. The project definition is the primary deliverable from the planning process and describes all aspects of the project at a high level. Once approved by the customer and relevant stakeholders, it becomes the basis for the work to be performed. For example, in planning an Exchange migration, the project definition should include the following:

• Project overview: Why is the Exchange migration taking place? What are the business drivers? What are the business benefits?
• Objectives: What will be accomplished by the migration? What do you hope to achieve?
• Scope: What features of Exchange will be implemented? Which departments will be converted? What is specifically out of scope?
• Assumptions and risks: What events are you taking for granted (assumptions), and what events are you concerned about? Will the right hardware and infrastructure be in place? Do you have enough storage and network capacity?
• Approach: How will the migration project unfold and proceed?
• Organization: Show the significant roles on the project. Identifying the project manager is easy, but who is the sponsor? It might be the CIO for a project like this. Who is on the project team? Are any of the stakeholders represented?
• Signature page: Ask the sponsor and key stakeholders to approve this document, signifying that they agree on what is planned.
• Initial effort, cost, and duration estimates: These should start as best-guess estimates and then be revised, if necessary, when the workplan is completed.

PROJECT WORKPLAN

2: Create a planning horizon

After the project definition has been prepared, the workplan can be created. The workplan provides the step-by-step instructions for constructing project deliverables and managing the project. You should use a prior workplan from a similar project as a model, if one exists. If not, build one the old-fashioned way by utilizing a work-breakdown structure and network diagram.
Create a detailed workplan, including assigning resources and estimating the work as far out as you feel comfortable. This is your planning horizon. Past the planning horizon, lay out the project at a higher level, reflecting the increased level of uncertainty. The planning horizon will move forward as the project progresses. High-level activities that were initially vague need to be defined in more detail as their timeframe gets closer.
PROJECT MANAGEMENT PROCEDURES

3: Define project management procedures up front

The project management procedures outline the resources that will be used to manage the project. This will include sections on how the team will manage issues, scope change, risk, quality, communication, and so on. It is important to be able to manage the project rigorously and proactively and to ensure that the project team and all stakeholders have a common understanding of how the project will be managed. If common procedures have already been established for your organization, utilize them on your project.

4: Manage the workplan and monitor the schedule and budget

Once the project has been planned sufficiently, execution of the work can begin. In theory, since you already have agreement on your project definition and since your workplan and project management procedures are in place, the only challenge is to execute your plans and processes correctly. Of course, no project ever proceeds entirely as it was estimated and planned. The challenge is having the rigor and discipline needed to apply your project management skills correctly and proactively.

• Review the workplan on a regular basis to determine how you are progressing in terms of schedule and budget. If your project is small, this may need to be weekly. For larger projects, the frequency might be every two weeks.
• Identify activities that have been completed during the previous time period and update the workplan to show they are finished. Determine whether there are any other activities that should be completed but have not been. After the workplan has been updated, determine whether the project will be completed within the original effort, cost, and duration. If not, determine the critical path and look for ways to accelerate these activities to get you back on track.

• Monitor the budget. Look at the amount of money your project has actually consumed and determine whether your actual spending is more than originally estimated based on the work that has been completed. If so, be proactive. Either work with the team to determine how the remaining work will be completed to hit your original budget or else raise a risk that you may exceed your allocated budget.

5: Look for warning signs

Look for signs that the project may be in trouble. These could include the following:

• A small variance in schedule or budget starts to get bigger, especially early in the project. There is a tendency to think you can make it up, but this is a warning. If the tendencies are not corrected quickly, the impact will be unrecoverable.
• You discover that activities you think have already been completed are still being worked on. For example, users whom you think have been migrated to a new platform are still not.
• You need to rely on unscheduled overtime to hit the deadlines, especially early in the project.
• Team morale starts to decline.
• Deliverable quality or service quality starts to deteriorate. For instance, users start to complain that their converted e-mail folders are not working correctly.
• Quality-control steps, testing activities, and project management time starts to be cut back from the original schedule. A big project, such as an Exchange migration, can affect everyone in your organization. Don’t cut back on the activities that ensure the work is done correctly.

If these situations occur, raise visibility through risk management, and put together a plan to proactively ensure that the project stays on track. If you cannot successfully manage through the problems, raise an issue.
MANAGING SCOPE

6: Ensure that the sponsor approves scope-change requests

After the basics of managing the schedule, managing scope is the most important activity required to control a project. Many project failures are not caused by problems with estimating or team skill sets but by the project team working on major and minor deliverables that were not part of the original project definition or business requirements. Even if you have good scope-management procedures in place, there are still two major areas of scope-change management that must be understood to be successful: understanding who the customer is and scope creep.
In general, the project sponsor is the person funding the project. For infrastructure projects like an Exchange migration, the sponsor might be the CIO or CFO. Although there is usually just one sponsor, a big project can have many stakeholders, or people who are impacted by the project. Requests for scope changes will most often come from stakeholders — many of whom may be managers in their own right. One manager might want chat services for his or her area. Another might want an exception to the size limits you have placed on mailboxes. It doesn’t matter how important a change is to a stakeholder, they can’t make scope-change decisions, and they can’t give your team the approval to make the change. In proper scope-change management, the sponsor (or a designate) must give the approval, since they are the only ones who can add funding to cover the changes and know if the project impact is acceptable.

7: Guard against scope creep

Most project managers know to invoke scope-change management procedures if they are asked to add a major new function or a major new deliverable to their project. However, sometimes the project manager doesn’t recognize the small scope changes that get added over time. Scope creep is a term used to define a series of small scope changes that are made to the project without scope-change management procedures being used. With scope creep, a series of small changes — none of which appear to affect the project individually — can accumulate and have a significant overall impact on the project. Many projects fail because of scope creep, and the project manager needs to be diligent in guarding against it.
MANAGING RISK

8: Identify risks up front

When the planning work is occurring, the project team should identify all known risks. For each risk, they should also determine the probability that the risk event will occur and the potential impact on the project. Those events identified as high-risk should have specific plans put into place to mitigate them so they do not, in fact, occur. Medium risks should be evaluated to see whether they need to be proactively managed. (Low-level risks may be identified as assumptions. That is, there is potential risk involved, but you are “assuming” that the positive outcome is much more probable.) Some risks are inherent in a complex project that affects every person in the company. Other risks may include not having the right level of expertise, unfamiliarity with the technology, and problems integrating smoothly with existing products or equipment.

9: Continue to assess potential risks throughout the project

Once the project begins, periodically perform an updated risk assessment to determine whether other risks have surfaced that need to be managed.

10: Resolve issues as quickly as possible

Issues are big problems. For instance, in an Exchange migration, the Exchange servers you ordered aren’t ready and configured on time. Or perhaps the Windows forest isn’t set up correctly and needs to be redesigned. The project manager should manage open issues diligently to ensure that they are being resolved. If there is no urgency to resolve the issue or if the issue has been active for some time, it may not really be an issue. It may be a potential problem (risk), or it may be an action item that needs to be resolved at some later point. Real issues, by their nature, must be resolved with a sense of urgency.