Devops for Growth

Si un axe stratégique n’est pas couvert par au moins une priorité de l’année ou si une priorité de l’année ne correspond pas à un axe stratégique alors des questions de fond se posent et une redéfinition doit être opérée. Ne pas oublier que le succès d’une entreprise repose avant tout sur sa capacité à employer utilement les talents qui la composent, il faut donc un pilotage rationnel pour garantir l’efficacité et la tenue du cap.

Une fois les priorités de l’année fixées (en fin d’exercice en règle générale) alors on va lister les projets que l’on souhaite mener (projet à traduire en projet A3, explications sur les A3 à venir dans mon prochain article)

De la même façon, on va ensuite positionner des croix aux intersections entre les lignes « projets prioritaires » et les colonnes « priorités de l’année ». Si une priorité de l’année n’est pas couverte par au moins un projet ou si un projet ne correspond pas à une priorité de l’année alors idem des questions de fond se posent et une redéfinition doit être opérée.

4. La "Productization"

Si les années 90 étaient la décennie des projets, ce n’est qu’en 2010 que les produits ont enfin commencé à briller. En fait, pendant cette période, de nombreuses organisations ont abandonné les visions de projet (définies par des portées claires, des besoins en ressources et des points de départ et d’arrivée prédéterminés pour atteindre un résultat souhaité) au profit de visions de produit (créant des objets ou des services qui cherchent à résoudre les problèmes spécifiques des consommateurs au fil du temps).

Ce passage à une vision de produit coule de source pour la création de biens physiques, comme les voitures, les ordinateurs et les avions commerciaux. Cependant il peut sembler un peu plus abstrait lorsqu’il s’agit de services, comme les logiciels et les plateformes SaaS, même si tous deux appliquent la vision de produit comme un moyen de créer des solutions cohérentes et normalisées qui apportent des solutions à des problématiques métiers. C’est le cas lorsque les produits créés sont destinés à des publics externes ou internes car, par exemple, les solutions développées par l’équipe IT d’une organisation peuvent être déployées pour répondre aux besoins des employés (en d’autres termes, de leurs clients).
 

Cela dit, il ne faut pas confondre la gestion de projet avec la gestion de produit. Bien qu’il y ait des similitudes entre les deux, la gestion de produit se distingue par ces aspects :
 

• Les besoins de l’entreprise de manière globale, tandis que les projets identifient des solutions spécifiques pour répondre aux besoins de l’entreprise
• Adopter une vision à long terme de la trajectoire en constante évolution des besoins des clients
• La gestion de produit a pour seul but de résoudre à tout prix les problèmes des clients, alors que les projets sont limités par les contraintes fixées au début d’un projet

Par ailleurs, les outils utilisés pour la gestion des produits et des projets sont assez similaires, feuilles de route, comptes rendus et tableaux kanban, par exemple, mais la manière dont ces outils sont utilisés et dont les informations sont saisies en cours de route peut différer sensiblement. À bien des égards, le fait de s’appuyer sur une vision du produit – la « productisation » – a donné lieu à un changement de paradigme pour de nombreuses organisations, qui peut entièrement changer la façon dont vous percevez votre entreprise et ses opérations au niveau macro, quels que soient les outils que vous utilisez pour créer des produits ou mener à bien des projets.

Summary

The Prioritization Matrix is a popular way to make decisions, but using it for project prioritization and selection may not be very effective.

The concepts behind it are sound - we want to maximize alignment with our goals, and use weighted scoring to do that - but the practice typically falls short in areas such as:

• Defining the appropriate criteria to use
• Weighting those criteria (with stakeholder buy-in)
• Collaborating to score projects quickly and “accurately”
• Balancing factors other than “score”

Software like TransparentChoice can help you take the project prioritization matrix ideas to a new level leading to a portfolio of projects that enjoy stronger stakeholder support and, in turn, enjoy higher success rates.

Learn more

If you’d like to learn more about how to prioritize projects like a pro, this blog is a great place to start: How to Prioritize Projects. Also, we’ve created this Ultimate Guide to Project Prioritization and Selection for you.

Only TWO methods of prioritization are suitable

The two methods were called the Analytic Hierarchy Process (AHP) and Data Envelopment Analysis (DEA). DEA can be quite tricky to use, but AHP (despite it's rather scary sounding name) is pretty easy to use and there are now a small number of good tools that do all the hard work for you.

In concept, AHP is like a super-charged priority matrix. You set up criteria, weight them and then score your projects against those criteria. This gives you a weighted score for each project and this score (if you've done it right) gives a good indication of how "important" or "valuable" each project is.

The secret sauce is in HOW you do it. AHP has a structured method that helps the leadership team work out what strategic alignment means. The actual scoring of projects is relatively straight-forward, it's getting alignment between your stakeholders that's difficult.

AHP really works

I recently read an academic paper looking at AHP in the context of prioritizing IT projects2 . The paper looked at the case of a large company that had put a lot of effort into improving its project prioritization process using more traditional methods. This lead to 85% of stakeholders "feeling good" about the new process, but actually, gave them no benefit in terms of actually aligning projects to strategic goals.

Think of this as the "before AHP". They'd invested in (what I assume was) a priority matrix, or some other spreadsheet based method of selecting projects. They "felt like" they were doing a good job, but the real impact just wasn't there.... and this is how I believe most organizations are.

They then implemented AHP. The researchers collected performance and perceptual data  before, during and after the implementation of AHP -- this is proper research, not just some "marketing case study".

The result was a significant improvement in strategic alignment. This is exactly what I would expect. What I did not expect was a table showing some other areas in which they derived benefits. The benefits included;

• Finding a good solution [to the question of which projects to do] through consensus
• Creating more and better "viable alternatives"
• The ability to better pinpoint "the problem" you're trying to fix
• Making the decision more rational (and less about emotion, gut feelings or politics)
• Getting everyone involved and bought-in
• Reduced conflict between different areas of the business
• Improved transparency in decision-making
• Improved execution of projects

I spoke to one of the researchers who wrote the paper and he told me that the biggest benefit that the company achieved was "getting all the senior leadership aligned" and it's that alignment that makes many of the other benefits possible.