Research and publish the best content.
Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
Already have an account: Login
Devops for Growth
107.5K views |
+9 today
For Product Owners/Product Managers and Scrum Teams: Growth Hacking, Devops, Agile, Lean for IT, Lean Startup, customer centric, software quality...
Curated by
Mickael Ruau
 Your new post is loading...
Your new post is loading...
Scoop.it!
Each company needs to decide how best to apply agile principles across this span of activities in its own organization. But in general, we see a future in which: 
Scoop.it!
Quelle que soit la méthode employée, les projets suivent toujours des règles auxquelles il est quasiment impossible d’échapper.
Scoop.it!
Project Management practices are designed for a project to meet requirements, stay on budget and finish on time. Real life, however, intervenes.
Mickael Ruau's insight:
Top Five Actions for Project Recovery. Project recoveries are highly successful once firms decide to focus on addressing the issues that caused the project to become troubled in the first place. The top five actions most often taken in a project recovery intervention according to a survey are: 1. Improving communication, stakeholder management (62%). 2. Redefining the project—reducing the scope, re-justifying the project financially (60%). 3. Adding and/or removing resources (58%). 4. Resolving problematic technical issues (49%). 5. Replacing the project manager or bringing in a consultant to manage recovery (36%). A Recovery Framework The rest of this article presents an approach for dealing with troubled projects with confidence and control. The approach deals with redefining project objectives and identifying and fixing problems across people, process, and product dimensions. The recovery process is broken down into distinct phases to improve control. Details are at a high level at this point. Simple project adjustments might be feasible in relatively small troubled projects. In larger projects, the complexity and nature of problems, strongly recommend that a recovery be treated as a project. There have been several attempts to deal with Troubled/Failing Projects. A notable one is: Moura, H. (2012). How to deal with troubled projects. Paper presented at PMI® Global Congress 2012—EMEA, Marsailles, France. Newtown Square, PA: Project Management Institute. The Recovery Framework is a structured approach for dealing with troubled projects, broken down into distinct steps: · Recognition — Formally recognizes that the project is in trouble and commits to fixing it. Authority and support are obtained to manage resources, reset expectations, negotiate objectives, and implement fixes. · Assessment — Assesses the project, based on documentation, questionnaires, checklists, and interviews. · Revision — Redefines the project, setting a new preliminary scope, schedule, and budget. Processes, teams, and communication are redesigned to fit a recovery process. · Redress — Implements remedial actions and risk responses. Monitors the troubled project until meaningful and credible baselines can be established. · Execute — Executes project management steps and monitors progress using established and approved plans.
Scoop.it!
Pour prévenir les difficultés, il est impératif de suivre de près l'avancée des travaux et les écarts avec le prévisionnel . Voilà à quoi sert un tableau de bord de pilotage : identifier très tôt les risques, pour les prévenir avant qu'il ne soit trop tard. Vous êtes alors à même de titrer la sonnette d'alarme auprès du comité de pilotage, ou simplement votre patron (suivant la structure de votre entreprise).Toutefois,lorsque le mal est fait, quelles sont les solutions à votre disposition ?
Scoop.it!
Contents
Scoop.it!
Key Takeaways
Scoop.it!
Scoop.it!
Scoop.it!
Learn how to save a project that seems to be spinning out of control.
Mickael Ruau's insight:
2) Reevaluate the project's core objectives.The best way to get things rolling again is to bring your team's attention back to the project's original purpose and primary goals. When things get chaotic, it's easy to lose sight of the bigger picture, and people can get bogged down in the stressful details. The purpose can get lost in the frantic shuffle. As the project manager, it's your job to keep an eye on the ultimate goal -- especially when the project isn't headed in the right direction. At the kickoff meeting, you likely went over the project's targets and milestones with your team -- but it might be time for a refresher. When you meet with your team, don't just rehash everything from the initial kickoff meeting -- make sure you take the time to identify where things have fallen off course. Are there any particular areas of your project plan that now seem unattainable? Any areas that require some careful reevaluation? Maybe something you thought would be a small component is actually demanding a lot more attention. At this point, you can't be afraid to be flexible. It can seem absolutely terrifying to pull a 180-degree pivot midway through an important project, but sometimes it's the only way to salvage things. Think about it this way: You know more about the project now than you did at the outset. At this point, you know what doesn't work, which makes you better equipped to formulate a better -- more realistic and informed -- approach. 3) Audit your team's communication channels.If your project isn't going as planned, there's a good chance that poor communication deserves a significant chunk of the blame. It's pretty simple: For your project to succeed, you need to have a communication infrastructure that allows team members to stay on the same page, even when they're working on different areas of the project. Take the time to examine your current communication process and look for any gaps or weak spots. What channels is your team currently using to communicate? How are you sharing information about individual team members' work? Is there a central place where team members can track the project's overall progress? How often are you checking in as a group? One of the easiest ways to keep your team connected is investing in a project management tool. There are a ton of tools available at various price points, making it a great option for agencies of all sizes. If onboarding your entire team onto a new piece of software midway through a project sounds like it might overcomplicate things, make the best of your existing tools and channels. Create a single place (such as a shared document) where team members can report on their progress and keep track of how the project is doing overall. Establish regular times to meet in person and discuss what's working, and what isn't.
Scoop.it!
Scoop.it!
8 Steps to Getting a Slipping IT Project Back on Track. As many organization leaders are aware, few (if any) IT projects materialize without runnin
Mickael Ruau's insight:
1. Evaluate Current State of AffairsProject managers will need to review all available project documentation and assemble their team for a closer assessment of where the project stands. At the very least, it may be a good idea to engage a third party (not connected with the project) to be present to facilitate the review. This will allow a distance from the project and afford an objective assessment of how the project ended up off track. Several questions to raise at this point may include:
2. Communicate with the Project StakeholdersProject managers are responsible for communicating with project stakeholders throughout the life of the project. Some questions to ask include, but are not limited to:
3. Prepare the Project Team for RecoveryAt this point, morale is likely to be low amongst the team. As a leader, it is the project manager’s responsibility to step in and get the team focused on recovery. Some actions to take in this step include, but are not limited to:
4. Develop a New Project PlanAt this point a new project plan will most likely be required. The following items should be considered:
5. Acquire Stakeholder Support for the New Project PlanBefore project managers can go forward they must obtain validation from the project stakeholders. In Step 2, the project managers notified their stakeholders that the project was failing and, presumably, obtained their approval to proceed in getting the project back on track. In this step project managers are obtaining stakeholder consent to press forward into plan execution. Without this critical step, project managers will lack the assurances that stakeholders are supportive of their actions and that the project is still viable.
Scoop.it!
Key Takeaways
|
Scoop.it!
Scoop.it!
Mickael Ruau's insight:
Three key reasons that I believe I am successful with this approach are:
This is roughly how I have driven teams into hyper-productivity in as few as four weeks, and why one of my co-workers calls me "The Scrum Whisperer." I have one team that has achieved 1,650% higher targeted value contribution per week after just four months (16 Sprints) together. We are pretty proud of those numbers.
Scoop.it!
Scoop.it!
The following project recovery plan template is a generic example designed to suit several kinds of projects. This project recovery plan template can also be freely downloaded as a Word document, so you can add information and amend it as necessary.
Mickael Ruau's insight:
Project Recovery Plan TemplatePurpose This first section is an introduction for the project recovery plan. Here you need to state the overall purpose of this document and briefly describe what is covered within its pages (i.e. the roles and responsibilities of the project team in the risk management processes, the steps that will be carried out to minimize the effects of the stop gaps, the time line and budget for process of project recovery, etc.). Project Team Provide the names and roles of the project management team members. Describe what responsibilities each team member has in regards to the project recovery plan. Project Assessment First, provide an overall picture of where the project is currently holding. What milestones have been achieved and what has yet to be accomplished. Next, define the core problems, obstacles, and risks that are preventing or slowing down project completion, and list them in order of importance, starting with the most critical issues. Include or reference here any risk-related documentation and any other supporting documents that help define these core issues. Project Recovery Strategies In this section you will define the steps the project team will take to minimize the damage, as well as re-organize project priorities, project scheduling, and the project budget to bring the project back on track and steer it towards completion. In short, at least five elements must be included in this section:
Conclusion and Appendix In section, you should summarize the project recovery strategies mentioned above as well as the overall goals of the project recovery plan. You should also include in the appendix any supporting documentation mentioned in the project recovery plan. Use this generic project recovery plan template to help you successfully recover from a potential project disaster and ultimately, project failure.
Scoop.it!
To save or not to save: Rescue vs Termination
Scoop.it!
Scoop.it!
This is a case study that describes how Kanban and lean development techniques were used to rescue a distressed project.
Mickael Ruau's insight:
Eliminate Waste and Control the Flow of Work with ConstraintsAs mentioned, the development team started off working in a waterfall approach. However, things ended up breaking down into an ad-hoc approach once development began and the big-up-front-requirements document became invalidated by uncontrolled change. From there, it didn't take long for the line from the code back to the requirements to become blurred and then eventually erased. The profile of the work assignment was a classic push system with a very large batch size. The development team was pushed a large requirements artifact from the analysis team. The test team was pushed a large code base by the development team plus the very large requirements artifact from the analysis team. During testing, when defects were uncovered, they were pushed to specific developers by a manager. When the fixes were made, a manager pushed them to specific testers for verification. This approach resulted in a lot of waste. In the analysis phase, a vast amount of unimplemented requirements accumulated. In the development phase, a vast amount of untested code was developed. In the test phase, a vast amount of unimplemented and improperly implemented requirements were identified.
Scoop.it!
Scoop.it!
Scoop.it!
Scoop.it!
Dans la mesure où le but de chaque organisation est de soutenir les initiatives de progrès pour obtenir des résultats significatifs, la tendance actuelle est de vouloir en faire le plus possible de la manière la plus rapide qui soit. Malheureusement, ce comportement est souvent contre-productif et apporte chaque jour son lot de déceptions au sein des équipes voire même un certain découragement. Il est pourtant tout à fait possible d’obtenir des résultats rapidement, mais il faut pour cela réduire le travail en cours nommé « WIP » pour Work In Progress et c’est sur ce point que la loi de Little peut apporter une réponse pertinente.
Scoop.it!
I am sure there are projects that cannot be recovered, but I have not seen one. It all depends on how much money you would like to spend. The practicality of recovering the project is the hard question to answer. I have recommended killing a number of projects based on the cost of recovering them. Occasionally, a client will reject that option for less tangible reasons, such as potential damage to their reputation. At that point, the goals of the project change and you need to add “save face” to the deliverables.
Mickael Ruau's insight:
AB: What’s the first thing someone should do when they realize a project is running into some real problems? TCW: Make sure that it is aligned to the strategic goals and remove all scope that is not critical to the project’s success. In attempting to reduce scope, it could be that the project gets broken into two or more deliveries (phased delivery). The most critical items delivered in the first phases followed by other functionality in subsequent releases. Essentially this decreases the size of each release and reduces risk. If you find that the project does not support a strategic goal of the company, cancel it and apply the resources to other projects. AB: Once they do that, what’s the next step? TCW: The three things to do in order involve:
|
Assurer une démarche structurée grâce à la méthodologie
Le partage de bonnes pratiques et d’accélérateurs fournis par une méthodologie projet doit faciliter le travail des équipes et leur permettre de focaliser sur la solution à livrer tout en rassurant le client quant à la nouvelle trajectoire suivie par le projet.
Une méthodologie qui place l’intégration au centre de sa démarche en proposant
- des référentiels partagés par toute l’équipe projet (Besoins métiers, anomalies, points d’intégration, indicateurs d’avancement …)
- des sessions de travail entre équipes IT et métiers pour partager l’information, résoudre les points d’intégration, présenter des prototypes et des résultats tout au long du projet
- des accélérateurs prêts à l’emploi
- des sources d’information sur nombre de thématiques capitalisées au fil des projets (formations, mode opératoires, informations éditeur …)
- un plan de travail clair permettant de mesurer factuellement l’avancement : des jalons, des livrables
La méthodologie doit permettre de s’assurer que les solutions définies potentiellement localement, par domaines fonctionnels ou métiers, sont viables dans le contexte d’une solution globale. Documenter est ainsi indispensable à l’obtention d’un consensus sur la solution et les objectifs à atteindre, tout en capitalisant pour l’avenir.
Transformer l’essai : S’assurer d’inscrire le travail réalisé dans la durée pour pouvoir transmettre et pérenniser.
L’essence même du projet est de livrer une solution nouvelle définie par le client. Les objectifs d’un projet en difficulté sont nécessairement définis à
- Court terme pour vaincre les difficultés rencontrées et redresser le projet : livrer une solution qui couvre les besoins métier vitaux pour l’entreprise.
- Moyen terme : finaliser la solution en livrant dans un second temps des fonctionnalités moins prioritaires en période de crise et remplir ainsi le contrat initial tel qu’attendu par les clients.
- Long terme : s’assurer de la pérennité de la solution. Les livrables nécessaires aux équipes en charge du support et du maintien en conditions opérationnelles de la solution ne doivent pas être la variable d’ajustement pour limiter les dépassements sur le projet au risque de compromettre la stabilité et la capacité d’évolution de la solution.
En synthèse, redresser un projet en difficulté consiste en premier lieu à réinstaurer une dynamique sur la base d’une confiance retrouvée entre toutes les parties prenantes, en établissant un nouveau contrat permettant de livrer une solution attendue qui doit être pérenne dans le temps.