Industrialize management to increase customer value

Project management stuck in the early 19th century

‍

Profitability and competitiveness have driven the entire industrial sector to optimize and automate production in order to maintain margins in an increasingly demanding market. Staying alive in a highly competitive sector. The face of industrial production has changed completely in 100 years. 

Conversely, projects have not been confronted with the same performance and operational optimization challenges. Methodologies and models for executing large programs or strategic portfolios have hardly changed in 100 years.

‍

Production vs. project management for 100 years

Industrie 5.0 - Production processes have been totally rethought over the last 80 years.

• ‍Progressive automation has drastically reduced the need for manual labor: ‍
  • The emergence of programmable controllers and technological development in the mid-20th century
  • The widespread use of robots at the end of the ^20th century
  • Machine learning and IoT in the 21st century

• Process optimization launched by Toyota at the end of the ^20th century: numerous studies and applications of lean management.

‍

On the other hand, program management methods and portfolios have remained fundamentally unchanged for 50 years. 

For example, the famous Gantt chart (by Henri Gantt) that all project managers use today dates back to 1912. In the 50s and 60s, the WBS, critical path and PERT diagrams were introduced in the USA. Over 90% of the methods used in today's large-scale industrial programs have remained absolutely unchanged for over 50 years!‍

Following the failure of numerous projects, the Agile manifesto was born in the early 2000s. Widely used in the IT sector and in start-ups, it is still of limited use to business teams, and is difficult to apply on a large-scale enterprise.

L’apparition de logiciels: depuis 10/ 15 ans, la plupart de collaborateurs sont équipés d’ordinateurs et utilisent de nombreux outils de messagerie ou outils collaboratifs. Cependant, à l’échelle d’un programme, d’un portefeuille, la méthodologie n’a pas réellement changé : les Pmos doivent prendre leur téléphone pour récupérer l’information auprès des différentes entités et chefs de projets. Ils cartographient les enjeux et principaux livrables à l’aide de post its et Pmos nous gratifient de magnifiques diapositives Powerpoint.

‍

Contrasting levels of maturity

‍

A conscious choice

‍

How can we explain the fact that major industrial programs have not kept pace with production processes, when the stakes are becoming ever higher? In the face of these failures, we have of course seen the emergence of many new products, and many radical transformations (Netflix, for example, moving from DVD rental to VOD, with the dazzling success it is known for) carried out successfully. What were the success factors behind these transformations?

‍

Customer projects VS in-house projects

We then interviewed many different project profiles in the industrial sector:

• Project managers, program managers
• ISD
• Business area manager
• Sales managers

We asked them about potential problems, delays and undelivered project scopes. The vast majority segmented projects into 2 categories:

• Customer projects (industrialization of a specific product following a customer request / tender)

"They are managed with the same level of priority and follow-up as production, and a delay is just not an option.

• Internal projects / innovation : internal transformation projects: financial, innovation ...

"We're not going to shut down a plant because one of these projects goes wrong. "It's often quite frustrating for those involved in these initiatives".

‍

A simple question of ROI?

Customer projects are considered with the same level of requirement/priority as production. So what are the differences between these two types of project? Are they more efficient thanks to their tools, processes or methodologies? 

The answers weren't always obvious, a bit like "the good hunter" and "the bad hunter" (for the older ones :-)). The problems encountered were quite similar to standard projects:

• Manual consolidation to recover most of the information
• Risks identified too late
• Lack of resource availability also identified too late
• People from the trade not trained in management techniques and issues
• Silo-based operations make it very difficult to consolidate and cross-functionalize information

‍

Unfortunately, the answers are always manual, not methodological or digital:

• We're adding a PMO to the core team
• An expert is brought in urgently from another country, to compensate for a poorly anticipated overload.
• Relying on an outside supplier 
• Duplicate the program manager with an external consultant with strong project expertise
• On recrute un PMO en charge de consolidé l’information venant des différentes entités à coup d’appels téléphoniques ou réunions.

‍

These answers are made possible by a single factor : profitability, ROI. 

The part of the budget corresponding to project management costs is "the thin end of the wedge in relation to the overall project budget". What's more, in the case of industrialization projects, this part of the project is totally disconnected from the product execution/production phase (the phase on which the project's profitability is concentrated).

‍

Gains that are not always tangible or disconnected from the product 

ROI at the heart of the project

Some projects do not always have tangible benefits (HR, Innovation - R&D ...), or have long time horizons. Many organizations now require each project to go through a validation/launch committee, providing details of the financial, business and environmental gains expected from the project. However, there are a number of pains and shortcomings reported by executive management:

• Gains are not always tangible 
• Gains are often difficult to measure
• Gains and ROI are achieved several months or even years after the project. However, the realization of these gains is no longer monitored at the end of the project. 

‍

The link with the product

Discussions with innovation team project managers reveal a mixture of strong motivation and frustration. 

Project managers and researchers have a great deal of autonomy, real confidence from management and a wide range of possibilities. However, their frustration lies in the materialization of their projects on the company's products. One researcher, for example, explained to us that he had developed an IoT-based prototype for interacting with equipment (even when it had a network connection problem), in order to avoid the need for a technician to travel all the time. In the end, his work and publications were taken up by another market player and not implemented in his company's products. Product teams are often quite disconnected from the work carried out by innovation teams.

‍

A gap between operational staff & execs  

‍

A loss of meaning for teams

Many of the people we interviewed told us that they were quite frustrated (sometimes at their own level, often within their teams). The feeling that the transformation, and the succession of plans 2022, 2025, 2028 ... , is leading to very few concrete achievements. The feeling that certain programs are being followed with laxity, and that numerous delays are accepted, or even definitive stoppages sometimes after several months of execution.

The main issues raised were :

• An underestimation of the value of customer projects or more strategic projects. 
• A lack of transparency and operational value-added: operational staff sometimes feel that a large proportion of initiatives are launched to bring value to the company, and not always to improve their day-to-day operational tasks.
• Lack of cross-functionality : it's very difficult for a project manager to have a cross-functional view of all the teams involved in a project, and to validate capacity. It doesn't allow operational staff to project a corporate vision.

These irritants have led to operational inefficiencies on many projects, and to a sharp rise in staff turnover in recent years. 

‍

A loss of management confidence 

We spoke to a number of CIOs, board members and CEOs about their observations on program and portfolio management and the feedback received from their teams. 

They are all very lucid and aware of the reality on the ground. 

Some people can be a little cynical, emphasizing the bottom line and the impossibility of doing everything at once. Depreciating or even halting certain projects is a healthy act of management.

Of course, they all want to involve all their employees as fully as possible in the transformation of their company. However, they face several major challenges:

• Change management: many operational staff take a dim view of every initiative launched by management, or don't understand why things should change. Whatever the communication & efforts made, it's very hard to get certain players on board.
• Inheritance of an old vertical managerial structure: large groups have piled up numerous hierarchical layers in support, engineering and business teams, creating an overly complex and vertical organization that makes it virtually impossible to efficiently execute major transformation programs.
• A lack of corporate vision, of meaning: many CEOs are disillusioned by the lack of meaning, of questioning the value contribution of their employees. They carry out many tasks, manually, without questioning why?" We get the impression that certain players are doing projects for the sake of doing projects".

‍

Increasingly high-stakes projects

‍

Energy devoted to projects has increased by a factor of 5 over the past 100 years 

Since 1900, the proportion of production costs devoted to projects has increased 5-fold: from a ratio of 90% (prod) / 10% (project) to a balanced ratio, with a gradual shift towards project activities. The rapid evolution of products, markets and regulations has forced groups to invest massively in R&D and transformation projects, in order to increase their sales every year and maintain their margins. However, these strategic projects are not carried out with the same rigor as industrial production.

‍

Failures that cost a lot of money

We can all think of project failures (in their execution) that have cost a company dearly in terms of image or even longevity. Examples include :

• An ERP migration program that failed a major pharmaceutical distributor(FoxMeyer)
• The failure of Queensland Health's project to roll out a new payroll system.‍
• Sidney Opera House: emblematic for its architecture but also for the disastrous execution of its project: budget multiplied by 15 and 10 years behind schedule!

‍

Crucial time to market in the face of the advent of new players

New market players are offering new products and processes. Regulations (notably environmental) are imposing ambitious new schedules. Transforming your company and its products is essential if you are to respond rapidly to these new constraints and competitive technological challenges.

The players we interviewed raised several issues in response to this problem:

• Tighter and tighter schedules are being demanded in RFPs (particularly under the impetus of Chinese customers).
• R&D teams' roadmaps are often opaque and not always shared with sales teams. As a result, they lose certain markets because they are unable to commit or communicate on time horizons and value contributions to their customers.
• Customers are becoming more and more involved in project organization and are pushing for increasingly agile approaches.

‍

Too much time wasted in steering meetings

All the people we interviewed, our customers and our past experience identify a multitude of recurring meetings that mobilize numerous players. 

Steven Rogelberg, a lecturer and researcher in organizational science at the University of North Carolina, conducted a study in 2022 to analyze the schedules of 623 employees from 20 different industries and assess the time they actually spend in meetings. 

This study highlights the following points:

• 18 hours per week in 17.7 meetings 
• Refuse only 14% of invitations when they would prefer to attend only 31% of them

‍

These "useless meetings" represent $25,000/year per employee, or $101 million/year for a structure with over 5,000 employees. 

When you combine this figure with the high level of involvement of business teams in projects, it's easy to understand the impact on a company's productivity.

Numerous meetings are held to gather information and align players. The result of a siloed organization. This process of sharing/aligning players, based on meetings, is one of the main obstacles to agility and decision-making in project management. The information that reaches the program manager is the result of consolidating information from numerous meetings. Beyond the energy wasted, we understand that the decision and action timeline is mechanically lengthened, and very far from near real-time management. While we talk about time to market, we accept delays in information feedback and decision-making on a monthly scale.

‍

Industrialization by consulting firms

‍

Les grandes industries n’ont pas optimisé, ou que partiellement, leur process projets. Principalement pour les éléments de ROI / rentabilité évoqués. Les sociétés de conseil, spécialisées dans le pilotage de programme, portefeuille, ont de vrais enjeux d’optimisation. L’efficacité du pilotage de leurs missions de projets et la satisfaction client sont des éléments primordiaux pour préserver leur marge ou gagner certains AO en diminuant la poche de coût des fonctions PMO.

For a long time, however, these companies had to contend with the Kodak syndrome: their photographic film was their PMO consultant. They hesitated between two options:

• Offer a digital tool for automatic data collection, consolidation and reporting
• Propose a PMO consultant (to add to their turnover immediately) to carry out this work manually.

Today, of course, we have forged partnerships with companies that have favored a medium/long-term vision and a real contribution to customer value. These companies have built their Consultant 3.0 offering around 3 main axes:

• A digital tool to disseminate their methodology and industrialize management 
• Project and tool training for their teams
• A proven team and governance

This quasi-military organization saves a few precious weeks when launching your program. You don't ask questions, you just get on with it, and quickly put in place a model that works. However, the subsequent impact is partly limited, and largely depends on the customer's organization and maturity.

‍

Tooling

Today's consulting firms have understood the need to digitize and automate these management processes in order to offer their clients real added value. Some strategy firms (McKinsey or BCG) have developed their own tools, focused on portfolio financial management. Other players are gradually forging partnerships with software publishers to structure a tool-based offer for their management processes.

This digitization makes it possible to :

• Improve efficiency (industrialize management and updating)
• Focus on high value-added tasks 
• Disseminate their methodology more easily
• Ensure a consistent level of quality among all consultants

‍

Training courses 

One of the pitfalls we often hear about is the lack of project management training for many of our staff. Some business players (former plant or site managers) are propelled into the position of director of a major program. Management controllers are mobilized to implement an ERP changeover, in addition to their operational activities. Many operational staff have experienced this transition to project functions as one of the most painful experiences of their careers.

One of the key elements for consulting companies is to ensure that all their consultants arrive on assignment with :

• An internal training base
• Certifying training for some (although we're not convinced on the Tabsters side that this is always the key).
• Training on the digital tools used for execution and management
• Internal referents to support them and potentially validate their deliverables/actions

‍

A team and governance

When it comes to executing a major program, consulting firms put in place tried-and-tested governance systems:

• A core team of internal and external players, project managers and business experts
• Governance to ensure the right level of sponsorship and efficient decision-making processes
• An adapted communication plan to ensure the support and involvement of all stakeholders

‍

Limits encountered

Many of the players we interviewed mentioned two main pitfalls:

•  The use of junior consultants who have no understanding of the customer's business issues and have great difficulty in communicating effectively with experts or business players.
• A core team program seen as "staying in its ivory tower" and too far removed from the real issues in the field, from the program itself.

Consulting firms come with a tried-and-tested management framework, but it is vital to include it in the customer's ecosystem, and therefore to address the following obstacles:

• Consultants' lack of business knowledge and expertise
• A customer information system that is often not open, limiting the use of digital sharing and consolidation tools.
• Highly vertical customer organizations not compatible with the cross-functional challenges of a strategic program

It's easy to understand, then, that the performance and industrialization of management cannot be achieved without the strong involvement of in-house teams. This requires them to rethink and even overhaul their internal organizations and methodologies.

‍

Industrialization through AI? 

‍

The state of the art

Artificial intelligence (AI) is playing an increasingly important role in project management, providing innovative solutions to improve efficiency, decision-making, and resource optimization. Here are a few key applications in the field:

• Schedule projection: Schedule projection based on predictive models calibrated on your past projects. Detect delays, propose corrective actions...
• Risk identification: Detecting risk patterns from past data 
• Resource optimization & automatic planning Intelligent allocation of resources according to constraints and skills
• Data analysis and decision-making: analysis of large volumes of data: customer feedback, team performance, financial indicators, etc. Decision-making based on hard data rather than intuition.
• Communication and interaction management: automatic generation of meeting minutes, analysis of e-mails to extract important information
• Simulation & scenarios: simulate different scenarios and optimize strategic choices. 

Mainly :

• Symbolic AI / expert systems for resource optimization, automatic planning or dashboard proposals
• Predictive AI for schedule projections and risk identification
• Language analysis (LLM) and generative AI: to analyze e-mails and automatically generate meeting minutes

The 3 main value contributions are:

• Save time: automate a wide range of tasks, from scheduling to reporting.
• Pattern detection: ability to analyze large volumes of data and identify risk patterns or data quality problems that humans would not have been able to identify (due to lack of time).
• Predictive analysis Predictive analysis does two things:
  
  • Anticipating delays 
  • Participate in continuous improvement: by identifying the root causes of delays, we can potentially improve our management and monitoring processes.

‍

The limits of AI in program management

The two main limitations of AI (especially those based on neural networks - excluding symbolic AI) are data-related:

• Data sensitivity & customer AI policy: many customers wish to have their own private servers, and do not want their data to be sent to an external AI server. This means creating dedicated customer servers. When you consider the power required to run an LLM model (for analysis and language generation) in terms of CPU / GPU and RAM, this poses a real problem of profitability and competitiveness for software publishers.
  What's more, the major groups are all in the process of developing their own AI models, and want to streamline them. This already represents a major challenge internally, with fairly heterogeneous levels of confidentiality: from simple IT/office support chatbots to the analysis of financial and customer data. But why train and have servers performing 90% of the same operations? This raises the question of integrating external AI engines (supplied here by program management applications)? The question is totally open, and no policy on whether or not to integrate these AI engines into the IS is clear in these large groups.

• Data depth: all neural networks (even if intelligent learning methods or models with less data have emerged) require a large volume of historical data (quality and standardized data). Program control doesn't have a huge public database like Wikipedia, used for conversational bots, or Github, used for code-generating AI. For repetitive tasks (support or application maintenance), we can achieve interesting results. For risk management, which in the final analysis is 80% fairly transverse across programs (availability of resources, validation of elements, budget, adhesions, etc.), models can help to anticipate certain elements and estimate their probability and potential impact (on deadlines and finances). However, when it comes to managing complex programs, even if you often find the same macro steps and key deliverables, it's quite complicated to find a volume of data deep enough to produce relevant results (i.e. not already identified by the PMO).
  We can, however, make some fairly interesting projections of task schedules and completion dates. However, they are produced by fairly conventional expert models which calculate the average progress rate of tasks (potentially with a history by resource, nb tasks in // ...) and recalculate task end dates from the observed average progress rates, while adding resource dependency and availability constraints. This saves the PMO time by proposing more realistic schedules or providing alerts. However, this is not real predictive / generative AI.

• The human factor: as all project managers know, the most complex component of program management is the human factor. For example, some players tell us that "it's great to have all these new AI engines, but we need to start by making sure that people are using the tool, updating it, that we have the data". 

‍

This problem can be summarized in 2 issues:

• Data quality: for many PMOs, if they had reliable data filled in on a weekly basis (we're not even talking daily), they would have no problem steering their program, providing visibility and making the right decisions at the right time. Like these PMOs, IAs engines are bound to be ineffective if they don't have data on certain scopes.‍
• L’hétérogénéité et la donnée qualitative: même si on essaye de quantifier, rationaliser au maximum tous les éléments d’un projet (on évoquera SMART plus tard dans cette étude) on retrouve de nombreux éléments qualitatifs. Toutes les organisations ne fonctionnent pas en sprint ou ne se pilotent pas en consommé / reste à faire. Les éléments de progression sont alors évalués à dire d’expert, par chaque contributeur voir par le chef de projet. On retrouve sur presque tous les programmes l’utilisation d’une météo (ou feux de signalisation). Même si de nombreux clients essayent de normer cette météo en donnant un sens à chaque niveau, on observe des évaluations de la progression ou des sentiments optimistes / pessimistes sur le respect des délais variant énormément en fonction des acteurs. On retrouve la même problématique dans la gestion des risques. Cette hétérogénéité rend complexe la composante « normée » essentielle au bon calibrage des réseaux de neurones.

Some studies based on psychological and philosophical research are quite interesting, and are beginning to work on solutions aimed at erasing this cognitive bias as far as possible.

‍

Ockham's razor 

Faced with our doubts about the cultural and psychological aspects of some of the data we received, a researcher (working on polycrisis systems in a large French group) explained to me how to approach it from 2 angles:

• Retrieve data from many different countries to factor cultural differences into models
• Work on different philosophical precepts. To remember the simplest and most easily applicable: Ockham's razor. 

‍

Ockham's razor, in other words "why make things complicated when you can make them simple".  

This concept of rationalism particularly caught my attention, as it applies perfectly to program/project management. With all the customers and prospects we've been able to talk to, we've always observed a strong correlation between an organization's level of maturity and its quest for simplicity. On the other hand, we sometimes observe organizations with a low level of maturity wishing to implement ultra-complex management models and KPIs.

Les moteurs de LLM offrent la capacité d’analyser l’intention et la complexité d’une phrase et d’une idée. Ils peuvent donc facilement analyser la structure globale et la description des projets, livrables pour remonter un niveau de complexité estimé. De plus, quotidiennement, ils peuvent analyser par exemple les risques et les actions de mitigation définis ou les commentaires, synthèses réalisées en complément d’indicateurs météo. Les moteurs d’analyse du langage peuvent donc alerter d’une certaine forme de complexité ou incohérence dans les données qualitatives remontées. 

The objective is to :

• Provide confidence levels or alerts on defined qualitative data (rather than adjusting or normalizing them using a complex, uncertain model)
• Support and contribute to continuous improvement processes aimed at simplifying the definition of elements and monitoring.

‍

Organizational limits to stakeholder involvement

The main limitation, or rather the prerequisite, is the involvement of all players and the sharing of information. The vertical structure of most organizations is often an obstacle to cross-functional programs, and therefore to information sharing. The many layers of management, and the associated validation processes or comitologies, make information consolidation and decision-making very slow and complex.

‍

New organizational models 

‍

Organizational obstacles

One of the obstacles to the implementation of certain methodologies based (notably, on information sharing and value contribution) is the very vertical and pyramidal organization.

This organization gives rise to the issues raised by the people interviewed:

• Managers focused on team performance rather than overall value contribution
• Operational staff far removed (no many layers of consolidation) from the company's challenges

‍

Holacracy

The early 2000s saw the emergence of new organizational models such as holacracy. Holacracy is a decentralized organizational management model that replaces the traditional hierarchy with a system of autonomous "circles", each with its own responsibilities and decision-making powers. 

Rather than following a pyramid structure, holacracy enables every member of the company to participate actively in the management and direction of the organization. Roles are clearly defined, but can evolve according to the organization's needs, and decisions are made collaboratively. This model aims to foster agility, transparency and accountability. Meetings are structured for rapid problem-solving and operational decision-making.

 Holacracy requires a profound cultural change and a high level of employee involvement, but it can lead to greater flexibility and better innovation within the company. 

‍

Spotify: setting up chapters and tribes 

Quite similar to holacracy, Spotify is often presented as an example of successful organization. Faced with rapid international development, the challenge was to be able to respond to the numerous technical initiatives and projects by mobilizing teams around the world. 

The idea is to group profiles with the same skills or players working on the same project into tribes or chapters .... This model makes it possible to:

• Facilitates exchanges and cross-functionality
• Focus on adding value to the project
• Foster collective intelligence and the emergence of new ideas 

‍

Agile product owners

In the spotify model and in Agile methodology, the product owner is the guarantor of the product vision, and is responsible for refining and prioritizing the product backlog, in order to maximize the value added by the product for end-users. This role is formally defined in the Scrum agile framework, but can also exist in more traditional organizations. This product transversality ensures that the organization is designed to ensure coherence and the contribution of value to the final product, the product delivered to the customer. 

‍

Limits of these organizational models

However, these models have limitations in their application:

• Size of organization (startups vs. large corporations)
• A major change which adapts well to new structures, but which quickly becomes complicated in existing companies, with managers putting up strong resistance.
• Tolerance of failure-> possible in certain organizations, start-ups, but impossible in a highly competitive model or in the industrial programs mentioned above.

‍

In particular, we can cite a rather striking failure. In 2015, at Zappos, an online shoe retailer and subsidiary of Amazon, holacracy was imposed on employees (over 200 of the company's 1,500 employees decided to leave at the time). The experiment was discontinued less than two years later, as managers felt that employees were too self-centred and no longer thought enough about the benefits for the company or its customers. 

This demonstrates that the balance to be struck is not a simple one: freedom does not exclude responsibility, the end of managers does not mean the end of management, and the ultimate goal of the company remains sales and profitability to ensure the long-term survival of the whole. These new organizational models offer real gains in terms of stakeholder involvement and productivity, but they cannot be implemented by simply copying (from a successful example) and pasting (onto your company). 

‍

Agile is die?

‍

More and more papers and posts on social networks have provocative titles such as "agile is die". Issued by promoters of the Agile methodology, the purpose of these messages is not to demonstrate the ineffectiveness of this method, but rather to denounce its application in many companies.

Numerous biases are denounced: meaning lost, scaled up without cultivation, speed rather than value, resistance from management, human factor not taken into account in implementation...

These papers then echo the feedback from actors interviewed in organizations or teams in agile mode. In summary, and in line with our analysis, the implementation of Agile methodology enables : 

• Gain speed 
• Increase efficiency and added value (prioritize the elements that add value)

‍

However, the main testimonials we have gathered focus solely on speed:

• Optimization of teams with 2-week sprints and breakdown into micro-tasks
• Work on team velocity and delivery capacity.
• Stand-up meetings (and all Agile ceremonial) have been hijacked for team management (something vertical).

‍

We therefore "preferred speed to value". We implemented a transverse methodology designed for the project, for the product, in a vertical organization. As a result, we lost all impact on value creation for the company and the customer, and concentrated on the individual performance of a team.

The implementation of new methodologies aimed at cross-functionality and value creation can never be achieved without a global rethink of the organization and management model. It is crucial to put the "why" back at the heart of every manager's and every resource's thinking. A company's objective is not to ensure that all its employees are used to almost 100% of their potential, thanks to precise, close monitoring. The challenge is to ensure that its employees work together to bring real value to the company and its customers. 

‍

Why?

‍

10 years ago, I was working with a major American strategy firm on an assignment for the general management of a large international group. The objective: to optimize a business that had been loss-making for several years following a sharp drop in margins.

 A succession of elements particularly impressed me during the execution of this mission:

1. Why this process? The simple question "Why do you perform this task?" Over 90% of the operators questioned, at several sites around the world, didn't know how to answer. The answers were often along the lines of "we've always done it this way", "it's in the procedures"... 
2. First surprise: we realize that it's useless: after analyzing the overall process, we realize that the control carried out is useless (since more than 3 years) because an automatic electronic validation is carried out upstream of this process.
3. Second surprise: we realize that this process is in the process of being offshored: a project was launched a few months ago which identified this procesuss as one of the elements to be offshored. The project focused solely on its value contribution (making savings by reducing the daily cost of resources), without considering the overall contribution and meaning of this process for the company.

‍

This absence of why is terrible in today's corporate world. It is at the root of the lack of meaning observed among many employees, or of the feeling expressed by executive management that they are "project managers who sometimes do projects just to do projects". 

‍

OKRs

Many organizations have introduced OKRs (Objectives and Key Results) to ensure alignment with management (and potentially customer) objectives, or conversely, to give meaning and transparency to operational staff.

This methodology was initiated in the mid-20th century, then implemented at Intel around 1970 in the form of iMBO (Intel Management By Objective). This methodology became popular in the early 2000s when Lary Page declared, "OKRs helped us multiply our growth by 10 several times". Many companies have strangely sought inspiration in this approach.

To go into more detail, OKR steering is a performance management method that involves defining clear, measurable objectives, accompanied by key results that enable progress to be monitored. Each objective must be ambitious and inspiring, while the key results must be precise and quantifiable. 

OKRs are generally set at regular intervals (quarterly or annually) and help to align teams on common priorities. This system promotes transparency, motivation and adaptability. It is often used to improve coordination and the achievement of strategic objectives within organizations.

The value-added of an intelligent implementation of OKRs is twofold:

• Management ensures that its strategic challenges are translated into operational objectives
• On a day-to-day basis, operational staff know what their objectives are, and why their mission is directly linked to the company's strategy.

‍

SMART 

It's important to complement the SMART principle when it comes to program management. OKRs are more often used as part of a global strategy, with objectives that are often ambitious and longer-term. SMART allows us to focus on realistic, rapidly attainable objectives. When it comes to managing large industrial programs, we understand the need to ensure that all objectives sold to the internal sponsor or customer are achieved.

The SMART principle is therefore to ensure that objectives are

• Specific
• Measurable
• Achievable
• Realisticand time-bound

This ensures a clear, shared vision among all stakeholders. To draw inspiration from the OKR methodology, the ideal is to succeed in breaking down the macro-objectives (defined at the start of the project) into a set of precise operational objectives, on shorter timescales, and for project teams or players.

‍

A first step with an integrated solution

‍

An integrated solution

We have built an integrated solution, by which we mean the complementarity between software (Tabsters) and the methodology implemented. The deployment of software is systematically doomed to failure unless it is framed, structured and methodologically thought through. Conversely, the implementation of new methodologies or organizational models cannot function without the support of software for sharing and consolidating information (projects, values, teams, KPIs, etc.). 

Tabsters will enable us to support and leverage the methodologies put in place thanks to :

• Its matrix structure: providing each player with a prism adapted to his or her role, scope and objectives. This real-time cube provides a hybrid between a vertical and cross-functional model.
• Its standard: program management doesn't stop at a WBS (or a succession of Agile sprints). It is crucial to define effective governance, manage objectives (SMARTs, etc.), identify and mitigate risks .... Managing a program or business is therefore part of a global methodology  

A hybrid organization

We worked on a hybrid organization in order to 

• Maintain continuity and avoid radical changes. Facilitate change management, get all users on board and avoid turnover.
• Drawing on the value contributions of Agile organizations

‍

We then find :

• Vertical organization: the vertical management dimension is retained. However, it is refocused on individual and human management: positioning, skills, development wishes ....
• A cross-functional dimension: we encourage the creation of cross-functional project/program teams. These teams focus on collaborative work, sharing information and adding value (internal or customer).

It's vital that management accompanies this change and gives as much importance to cross-functional work bubbles as to more traditional vertical teams.

An adapted methodology

Definition of a methodology for managing your projects, programs, portfolios, etc., adapted to the challenges facing your organization. This methodology should be broken down by project type/size. However, it is best to avoid unnecessarily multiplying special cases.

The main challenge of this stage is to identify the real success factors for your projects and your transformation, without getting bogged down in formalism and, above all, in counter-productive processes. It is also essential to distinguish between the strategic and operational layers of management. It is utopian and unrealistic to think that we can define a detailed methodology common to all players: from project managers to simple contributors involved in a few tasks, from an IT product owner to a metallurgy researcher. 

In addition, it is important to define a semantic, a lexical field common to the company: the definition of a project, a program, a risk, a metric... 

To sum up, it is essential to :

• Focus solely on a global, harmonized steering methodology at company level
• Limit the number of indicators to a few (less than 10 or even 5 if possible).
• Allow each team a certain degree of freedom in setting up its own operational management system.
• Ensuring that the tool implemented (Tabsters in our example) automatically connects (either via internal tool bubbles or APIs with operational tools) strategic management data with operational data.

‍

Indicators and KPIs 

The implementation of the methodology associated with the definition of the corporate strategy should enable the definition of KPIs for cross-functional project/program teams.  

These KPIs must combine : 

• Tangible, realistic, short-term indicators linked to program execution
• Longer-term indicators linked to corporate strategy
• Indicators more specific to the steering methodology: the aim is to ensure that all players are involved in this transformation.

‍

The first two groups of indicators should be largely correlated (the reverse demonstrates a worrying discrepancy between the energy spent on projects and the company's stakes), but they may diverge in certain respects:

• Participation in regulatory and remediation projects, for example. These are mandatory projects, but they are not always directly linked to the corporate strategy defined a few months earlier.
• The time scale and level of attainment are different: as discussed in the differences between OKR and SMART.

‍

Automation and analysis 

Once your environment has been structured (organizational, methodological axes, etc.) and standardized (methodology, shared semantics), you can industrialize all consolidation, analysis and communication processes in a single tool.

An analysis by our customers shows a time saving for PMOs and project managers (with at least 20 contributors) of over 20%. 

This software industrialization brings several benefits:

• The time saved, with the 20% mentioned allowing you to concentrate on higher value-added tasks.
• Standard through use. By producing all reports automatically, you can mechanically ensure the consistency of all reporting.
• Centralization through communication: as all communications are produced by the tool (internal & customer communications), we ensure that all information is centralized.

‍

Change management & continuous improvement

The challenge of industrializing industrial programs is very high, and requires us to take many steps forward. It also requires a real acculturation of the teams. For example, the hybrid organizational strategy we have put in place will inevitably require gradual adjustments.

The implementation of management KPIs (third group of KPIs) should be complemented by a feedback process (integrated into the tool) on tool use, methodology and information sharing.

‍

Conclusion

In conclusion, industrializing management is a crucial step for organizations seeking to adapt to the realities of the 21st century. Thanks to innovative tools such as those developed by Tabsters, and a balanced organizational approach, companies can reduce inefficiencies, accelerate projects and maximize their value contribution. The future of management lies in the synergy between technology and cultural evolution, offering organizations a unique opportunity to thrive in an increasingly demanding environment.