1. Introduction

Over the last four decades, numerous IT development models and project management standards have emerged. However, with the evolution of technology, companies specializing in IT development have encountered serious problems, which have gradually pushed them to reconsider their adopted methods of development and IT project management. This reconsideration becomes more and more urgent with the exponential evolution of technologies, from the era of new information and communication technologies “NICT” to the era of digital transformation “DT”.

In the late 1990s, IT project management methods based on a waterfall lifecycle approach were the most dominant methods (1). The most representative approach to this type of development is the “cascade” model. However, over the last few years, the principles of linear breakdown and IT project management based on “Waterfall” methods have been increasingly called into question. The permanent change in the functionalities to be developed and the “tunnel” effect caused by “cascade” projects have led practitioners to question this development model and to focus on the rapid and constant evolution of the technology market.

In very few years, the concept of agility has become a major success in the IT development industry. According to a survey conducted by the PMI in 2017, 71% of the organizations surveyed said they use agile approaches for their projects sometimes, often or always (2).

Despite the emergence of this new mode of development, which makes it possible to cover the shortcomings of waterfall models, and despite its exponentially increasing rate of use, the failure rate of IT projects remains one of the main concerns of companies. Indeed, according to the latest results of the Standish Group Chaos study published in their last report in 2018, only 34% of projects are successful. While 51.5% are challenged and 14.5% are cancelled before completion. That said, 66% of developed projects are partially or completely failed (3).

Despite the abundant literature on the concept of agility, the transition to an “agile” organization is a real challenge. At present, the context of the use of “agile” tools remains unclear. The analysis of the literature published on the subject underlines the contradictory positions of practitioners with regard to the applicability of the management practices and instruments carried by these approaches. Agile methods articulate new managerial concepts and devices without, however, participating in a unified management model. They do not seem to be based on a structured project management approach. They thus raise the question of the feasibility degree of the technical substrate associated with them, of the greater or lesser relevance of the management philosophy that they underlie, and of their internal contextualization (2).

While the application of these methods has received very positive feedback at the level of small teams, the results have been less telling in terms of their application in complex organizational structures, without mentioning the lack of project management skills within these teams and their ability to properly self-manage the content of each iteration. Among the empirical studies that have dealt with the implementation of these “managerial innovations”, few have focused on their application in “complex” organizational structures, and especially in an era of digital transformation. As a result, we note a real gap in the literature devoted to this subject.

The philosophy of “agile” methods thus seems to pose in a central way the question of collective sense, and this in an interactionist perspective (4) where the sensemaking is done in a processual way through communication between the participants. From this point of view, the organizing dynamics to which these methods refer can be understood as continuous sequences of interactions between the project’s actors. This leads us to wonder how this type of “managerial innovation” (2) can be implemented in a structured management approach to constitute a formalized organizing system.

The era of digital transformation is characterized by the need to produce IT tools very quickly to keep pace with competitors, and which requires a very high level of quality within very precise deadlines and in an exponentially changing environment that once again demands a very high level of adaptability and flexibility. To cope with these new requirements of this era, companies have been running towards agility that does not respond properly to the constraints of this new era, and they have resorted to a new mode of development that is not yet mature, and which they have called false agility. This new notion refers to the adoption of an agile project management model, while keeping the contractual aspects found in traditional management models. This need is linked on the one hand to the new requirements of this era of digital transformation, and on the other hand to the lack of mastery of agility in practice.

The purpose of this article is to respond to this research problem by articulating a critical analysis of the literature devoted to waterfall and agile methods and a case study conducted from the perspective of the “by doing” approach (5) (6) (7) (8) (9). The latter focuses on human action to understand the functioning of groups and their links with the organization and society (10).

The objective of the observations made is to analyze the process of “manufacturing” a project management strategy adapted to this new era of digital transformation and its implementation in an organization characterized by unstable teams, attached to several projects and geographically dispersed.

2. Literature review

2.1.     IT project and IT project management

2.1.1.   IT project

A project is a set of coordinated activities and actions that make it possible to respond to a precise and clearly identified need, by mobilizing resources and respecting a deadline (11). It is composed of a series of tasks that have one and the same objective. These tasks are subject to conditions, including the time, people and resources needed to complete them (12).

An IT project is a project whose deliverables consist of IT tools, methods, or services, it is characterized by its uniqueness and punctuality. Typically, IT projects consist of five steps: initiation, planning, execution, monitoring and closure. Each step is composed of specific tasks that enable the achievement of project objectives.

2.2.     IT project management

Project management is the art of managing one or more projects, and consists of providing the means of prevention, detection, and analysis to ensure, throughout the project, the best possible match between objectives, costs, and deadlines. Managing a project means knowing where you are going (objectives), how you are going to get there (budget and resources) and when you are going to get there (deadline). It is about building and maintaining a real information system around the project management.

To achieve this, we must have at our disposal means such as a methodology for breaking down the project into tasks, techniques for calculating deadlines, cost and budget plans, a methodology for periodically assessing progress, progress metrics, etc. It is all the operational and tactical aspects that make a project end up in a triangle representing the quality-cost-delivery balance (QCD). All these means implemented will enable the organization, forecasting, monitoring and analysis of the project’s progress.

2.3. Project management challenges in the era of digital transformation

The digital transformation presents several challenges for businesses. More specifically in terms of project management. The technological environment has evolved, the era of transformation is growing. However, project management processes remain frozen, no adaptation of project management methods has taken place to circumvent the requirements of this new way of doing business. Indeed, the difficulty of the digital transformation is furthermore since large global organizations often have traditional technologies and well-established work methods. In addition, they also have third-party partners, which adds to their complexity and therefore makes them vulnerable to competition, especially from smaller, more agile, and digitally focused start-ups.

Beyond the constraints listed above, digital transformation adds a new layer of complexity, linked to the fast-growing technological environment, with very specific IT processing and production deadlines, which require complete upstream project planning, with a well-defined scope and main objectives, but which may be subject to change.

2.4.  IT project management methods

2.4.1.   Waterfall methods

The waterfall model of V-Cycle (or Cascade) is a sequential and linear management method that allows to represent the developments through successive phases (figure 1) (13). It is divided into several steps identified from the start of the project. The validation of one step leads to the start of the next, without any overlap of steps. This method is mainly used in software development, it limits the returns to previous stages, requires the business to define a long-term objective, and focuses on end-to- end project planning and is resistant to change, they are called “predictive”.

Figure 1: Project Management Methods: Waterfall Method

These methods are characterized, on the one hand, by their sequential aspect and, on the other hand, by the “customer/supplier” relationship between the project owner and the project manager. They induce a real rigidity in the project management.

By applying this methodology, the project manager must then commit to a precise schedule for the project’s realization by foreseeing milestones for the beginning and end of steps as well as the tasks to be carried out. The project team commits to this precise schedule and defines all the tasks to be carried out. Each task is implemented on the following one, with a mandatory dependency, to reach the expected deliverable.

This methodology requires very precise specifications, tasks that are meticulously anticipated and described, with little chance for the unexpected. The project team follows these specifications to the letter and works on the entire project until its delivery. The project is therefore managed in its entirety, with little customer or external interaction during the production step.

2.4.2.   Agile methods

Agile methods proceed in stages with short-term objectives (figure 2). They use an iterative development principle which consists in dividing the project into several stages called “iterations” (14). These iterations are nothing more than mini projects defined with the client detailing the different functionalities that will be developed according to their priority. “The project manager then establishes a macro-planning corresponding to the tasks necessary for the development of these functionalities”. The goal is to assume that we cannot know and anticipate everything no matter how much experience we have. We then cut the project into iterations rather than anticipate and plan for everything, knowing that unforeseen events will occur along the way.

The Agile methodology is generally opposed to the waterfall methodology. It is intended to be more flexible and adapted and places the customer’s needs at the center of the project’s priorities.

In the field of IT development, a certain number of practices have been established, allowing the implementation of agility in a team or a company, the notion of “agile development” remaining very general. Many of these methods can be found in variants of agile software development, such as Scrum, Kanban, extreme programming (XP), Feature-driven development, Behaviour Driven Development or Crystal:

• Backlog
• Retrospective
• User story
• Agile testing
• Programming in pairs
• Time Box

There are many other methods in agile methods. They have in common that they aim at improving the efficiency and quality of work.

Figure 2: Project management methods: Agile method

An “iterative” development prioritizes user requirements that may evolve during the project, while developing a relationship between product owner and sponsor of working partners with common objectives.

The agile methodology is suitable for projects that are not too strict on deliverables and above all that require real-time adaptation to customer needs and requirements. It is becoming more and more common, but requires good working habits, especially in the team members communication, in real time. This methodology allows the improvement of:

• The quality of
• Quality
• Risk
• Motivation and confidence of the
• Cost

2.4.3.   Analysis and comparative study of waterfall and agile management methods

By closely studying and analyzing both classical and agile methods, we can summarize the differences and characteristics of the two methods in the following table (table 1):

Table 1: Analysis and comparative study of classical vs. agile methods

Topic	Waterfall	Agile
Risk Management	Separate, rigorous risk management process.	Risk management integrated into the overall process, with accountability for identifying and resolving risks. Risk-based management.
Success Measuring	Respect of initial commitments in terms of costs, budget and quality level.	Customer satisfaction through the delivery of added value and speed of implementation.
Lifecycle	Cascading or V- shaped Key sequential steps. This model makes parameter rollbacks very tricky.	Iterative and incremental Allows adjustments Accepts changes during iterations Each iteration delivers a usable part of the solution.
Planning	Predictive Detailed plans based on a perimeter  and requirements defined and stable at the beginning of the project.	Adaptive with several levels of planning (macro and micro- planning) with the possibility of adjustments             if necessary, as changes occur.
Documentation	Produced in large quantities at each stage as a support for communication, validation and congratulation.	Reduced to the main essentials in favor of functional, operational increments to obtain customer feedback.
Team	A team with specialized resources, led by a project manager.	An empowered team where initiative, versatility and communication are privileged, supported by the project manager.
Quality	Quality control at the end of the development cycle, once the product is finished. The customer discovers the finished product at the end of the project.	Early quality control, regular at each iteration, and permanent, at product and process level. The customer visualizes and validates the results early, on a continuous basis, and remains involved in the control frequently.
Change	Resistance or even opposition to change. Cumbersome process of managing accepted changes.	Favourable reception of the inevitable change, integrated into the process.
Follow-up on progress	Measurement of compliance with initial plans: quality, cost and lead time. Gap analysis.	Only one progress indicator: the number of functionalities implemented and the rest to be done.

2.5.     Epistemological choices and research approach

2.5.1.   Epistemological choices

This article aims to dissect the techniques and practices of IT project management within companies specialised in IT production (the case of digital service companies). To do so, we first opted for an ethnographic study, i.e. a participant observation of a human process, a set of tasks and events in a particular site through a longitudinal data collection. Adherence to such a perspective already pushes us towards an exploratory type of research and to opt for a qualitative approach. The researcher then wants to continuously and systematically induce a meaning of the events he/she observes.

The study of IT project management models lends itself well to the ethnographic perspective. This is referred to as an idiographic rather than nomothetic research strategy.

2.5.2.   The research approach

Our research approach aims to identify traditional (Waterfall) and agile IT project management models, in an era of digital transformation, for the case of outsourcing (the case of digital services companies). We used the inductive method because although we had already thought about what we thought was a likely situation, we did not have a well-articulated theory a priori. We therefore limited ourselves to observing a situation, understanding its meaning and trying, from this new understanding, to induce, if possible, a certain theory.

This choice of the case study technique was made with full knowledge of the facts, since we know that it offers great advantages such as the in-depth analysis of a site, the possibility of developing historical parameters, and a strong internal validity. It is ultimately an adaptable technique.

2.6.     The steps of the research

We chose the multiple case study as our research technique. The value of such a technique depends greatly on the researcher’s ability to demonstrate the credibility of his or her approach. In order to put all the chances on our side, we have respected and followed, very scrupulously, the different steps generally adopted to respond to this research technique:

3. Methodology

3.1.     Data collection

Data collection for each of the cases studied was done mainly through participant observation.

3.1.1.   Data processing

In multiple case studies, it is good practice to develop a schema that will be used to code the data. This scheme (figure 3) is also a means of ensuring a consistent method of comparing data from different case studies.

Figure 3: Schéma de codification utilisé pour le traitement des données.

3.1.2.   Interpretation of the data

For the interpretation of the data, we linked the results of the coding of the raw data of each case. This is how we were able to see, for each dimension that makes up the proposed thematic grid, whether there were certain trends that emerged in the three codified cases. From this first globalisation, we were able to highlight the convergences between the traditional and agile management models in this era of digital transformation in all the cases, i.e. what works and what does not work in this era of digital transformation in each of the models used.

3.1.3.   The study population and the sample selected

One of the important steps in the multiple case study is to determine the area that is affected by the research. This means identifying, from clearly defined variables, the population under study. It is also necessary to state the precise rules from which we have chosen, from this population, a sample of cases that has been the object of our observation.

Three major variables are part of our problematic: the project management model (agile and classical), the era in which projects are produced (digital transformation era) and the production context (external).

3.2. Methodological motivations

Our research project aims to understand the modes of “construction” of a classical and an agile approach, while taking into consideration the new characteristics of IT projects, specifically in this era of digital transformation. The “practice” perspective can be considered as a relevant research angle to examine, in depth, the activities of the actors involved in the “making” of these project management methods and their continuous interactions with the environment in which they are located, as well as the tools and practices used in each of the phases of the life cycle of an IT project in general.

To date, no study has been conducted on how the actors collectively interpret and construct methods adapted to the constraints of this new era, which must be implemented in “complex” organizational structures. In the two “toolboxes” of classical and agile methods, which instrumentation(s) should be favoured? How do the elements of organizational contingency intervene in the implementation of the engineering and managerial principles specific to this era?

To answer these questions, it seems appropriate to us to focus on a field study to better understand how tools classified under the term “era of digital transformation” are implemented within organizations. The choice of an instrumental case study thus seems relevant to us to analyze, in depth, the phenomenon of implementing methods that consider the new constraints of this era in “complex” organizational structures.

The case method is a precise mode of observation of themes previously defined by questioning (15). It supposes an in-depth analysis of the various aspects of a situation to reveal the significant elements and the links between them. Moreover, case studies can be classified in three categories (16): intrinsic, instrumental, and multiple case studies.

Within the framework of this work, we wish to carry out a case study of instrumental type in organizations specialized in the production of IT projects in an era of digital transformation.

This approach gives us on the one hand a deep understanding of IT project management, specifically in this new era of digital transformation, and on the other hand the identification of recurring phenomena during the production of IT projects, to identify the requirements of this new era. It also consists in identifying the most recurring phenomena when using classical and agile methods, to identify what works and what does not work in each method in this new era. Our intention is to capture the way classical and agile practices are implemented in this new era as project management methods. To do so, we have decided to approach the selected cases from a “by doing” perspective, focusing on what the actors in charge of implementing project management tools do.

3.3. Presentation of the cases of the studied companies

The 3 companies studied are companies specialized in the production of IT projects, specifically web and mobile projects (information systems, web software, websites, e-commerce sites, etc.).

The duration of the study of each company was limited to one year, which gives feedback of the experiences of the 3 companies for a global period of 3 years. Also, the choice to study 3 different companies allows us to generalize the studied phenomenon as well as the contributions made within the framework of this article.

3.3.1.   Case A

This company adopts the project management method imposed by its clients (the sponsors). Projects that adopt a waterfall model do not undergo strong changes compared to the definitions in the literature.

The projects that adopt an agile model undergo changes according to the constraints of each client and which is generally summarized by:

• definition of a fixed project cost
• definition of a specific contractual aspect of the project
• imposition of a precise schedule according to the customer’s constraints
• deleting or adapting the following events:
  • replace the daily meeting by a weekly team point
  • definition of the backlog by the project manager in the form of an excel file with a well-defined structure.
  • nonhomogeneous iterations in terms of time interval
  • a content of each iteration that is fixed, and that implies a shift of the next iteration if the delays cannot be maintained

For corrective maintenance projects, adoption of an iterative agile model removing the following events:

• Retrospective
• Demonstration

While including the customer constraints defined above.

The following table (table 2) summarizes the methods used, highlighting the size of the projects, the project failure rate, and the list of main causes:

Table 2: Failure rate statistics of case A

Method	Size	Number	Failure rate	Causes of fails
Waterfall	Small	29	10%	Team & Communication
	Medium & Large	67	30%	Cost Quality Change Team & Communication
Agile	Small	19	45%	Planning Documentation Progress tracking
	Medium & Large	5	100%	Planning Cost Documentation

3.3.2.   Case B

This company imposes an agile management method on all its customers (the sponsors).

The projects that adopt an agile model undergo changes according to the constraints of each client and which is generally summarized by:

• definition of a fixed project cost
• definition of a specific contractual aspect of the project
• imposition of a partial precise schedule according to the customer’s constraints
• deleting or adapting the following events:
  • deletion of the retrospective
  • addition of two events, project committee (weekly), and steering committee (monthly)
  • definition of the backlog by the project manager in the form of an excel file with a well-defined structure.

The following table (table 3) summarizes the methods used, highlighting the size of the projects, the project failure rate, and the list of main causes:

Table 3: Failure rate statistics of case B

Method	Size	Number	Failure rate	Causes
Agile	Small	3	33%	Planning Documentation
	Medium & Large	13	55%	Planning Documentation Cost Progress tracking

3.3.3.   Case C

This company adopts the project management method imposed by its clients (the sponsors).

Projects that adopt a waterfall model do not undergo strong changes compared to the definitions in the literature.

The projects that adopt an agile model undergo changes according to the constraints of each client and which is generally summarized by:

• definition of a fixed project cost
• definition of a specific contractual aspect of the project
• imposition of a precise schedule according to the customer’s constraints
• deleting or adapting the following events:
  • definition of the backlog by the project manager in the form of an excel file with a well-defined structure.
  • non homogeneous iterations in terms of time interval
  • a content of each iteration that is fixed, and that implies a shift of the next iteration if the delays cannot be maintained
  • addition of two events, project committee (weekly), and steering committee (monthly)

For corrective maintenance projects, adoption of an iterative agile model removing the following events:

• Retrospective
• Demonstration

While including the customer constraints defined above.

The following table (table 4) summarizes the methods used, highlighting the size of the projects, the project failure rate, and the list of main causes:

Table 4: Failure rate statistics of case C

Method	Size	Numb er	Failure rate	Causes
Waterfall	Small	7	42%	Team Progress tracking
	Medium & Large	13	70%	Change Team & Communication Quality
Agile	Small	—	—	—
	Medium & Large	6	50%	Planning Documentation

3.4. Investigation process

Our qualitative approach mobilizes a set of data collection and analysis techniques to identify, understand and interpret events in their context.

4. Results

The results of our investigation can be summarized as follows:

4.1.     Case of projects following a waterfall model

Project size has a direct impact on the success rate of IT projects. Indeed, if the project is small, the success rate increases and with the increase of its size the risk of its failure increases. A small project is therefore a project that is simple to manage and control.

Communication in waterfall projects is very poor and has a very negative impact on the continuity and smooth running of the project. The rollback process in any project step is too risky or even impossible when it comes to advanced steps.

The detailed planning gives a precise vision on the continuation of the project, the customer / sponsor can afford to prepare activities that are related to the project by defining the deadlines in advance.

Project documentation always has an impact on the success of this type of project. However, in the same company, when there is no writing standard, there are very important quality gaps that depend on the project manager who wrote the documentation and his experience. Similarly, this increases the risk of oversights and major gaps in the requirements specification.

Quality control is only carried out at the end of the development process, which means that no quality risk management is implemented. The customer can only identify functionalities that do not or no longer meet his needs at the end of the project, with a very costly backtracking at this stage of the project.

This type of projects cannot accept any type of change, this is one of the main constraints of IT development in an era of digital transformation, technological evolution runs at the speed of light, and therefore customer needs can be subject to evolution and change and full process of project implementation. These changes are in opposition to this mode of development, they are expensive, even impossible in some cases, which pushes some customers to cancel their project before its completion, to start again another one that meets the new requirements, again taking the risk of throwing this project away if the needs evolve over time.

Exclusion of the customer during the different steps of production, therefore no risk can be anticipated, which generates customer dissatisfaction, and even the production of projects that will not be used afterwards, because it does not reflect the vision of the project on the customer’s side and this risk has not been identified in the primary steps. For projects managed according to a waterfall model, the presence of exhaustive and up-to-date project documentation has a direct impact on the simplification of its maintainability, handling, and subsequent scalability.

4.2. Case of projects following an agile model

The planning methods adopted in practice are not mastered or even understood by team members. In the same way, the macro planning of this development mode is never fixed in terms of time and is not respected either, this is linked to the fact that important functionalities are shifted from one iteration to another, especially in the first iterations where the production capacity is not yet mature. These shifts are indirectly responsible for wastage linked to the planning of tasks and activities that are external to development, but which depend on them at the same time. That said, if we look at the project only it can be considered as successful, but if we count the damages linked to its bad planning, the results are always catastrophic.

The documentation is always light, ideas are mostly developed in real time between the development team, the product owner, and the customer himself, through questions and requests for clarification. On the other hand, the latter are never documented, so the project evolves in the right direction, but its documentation does not follow this evolution and remains very limited.

Agile teams always suffer from project backlog that are not complete or very poor in terms of detail, which complicates their management of time, understanding, as well as production.

This type of documentation is considered in practice as one of the major problems that lead to the failure of IT projects, in terms of scope, quality, cost and planning. It has also proved its limitations in the maintenance steps, where new teams cannot find a written record of what has been produced, especially for projects where specific management rules are defined, and indeed it is most IT projects that require specific management rules. This complicates the maintainability of agile projects, or even makes it impossible to upgrade and stabilize them.

Agile project teams are self-managing, but in practice, developers and technical teams do not have the project management skills, making risk management and anticipation virtually nil. Decision-making during production steps does not necessarily reflect a relevant strategic and project management logic.

Progress indicators in agile management focus on the number of functionalities developed and what remains to be done. In practice, the contractual aspects required by customers add another layer that concerns the commitment to results, deadlines and quality. And therefore, a return to the 3 main constraints of IT development quality, cost, planning, by adding new constraints related to the scope, added value, and scalability of projects as well as other constraints related to this new era of digital transformation and the specific needs of each customer. That said, lack of freedom over the other variables that become fixed and binding constants for the company responsible for developing the IT solution.

5. Discussions

The analysis of these research results has allowed us to identify what works in practice in the different waterfall and agile development modes. It has also allowed us to put our finger on the constraints of this new era called the era of digital transformation, to propose a new development mode that highlights the 3 elements studied (Waterfall mode, Agile mode, Era of digital transformation).

Before proposing a new development mode, it is essential to define a matrix that highlights what works in each of the studied development modes (table 5):

Table 5: Constraint matrix of waterfall model, agile model, and the era of digital transformation

Topic	Waterfall	Agile	Things to keep in mind
Lifecycle	Perfect life cycle for small projects	Iterative life cycle, allows to divide the project into small projects.	Divide each project into small projects equal in terms of the effort required for each iteration.
			=> How to do this division?
Planning	Definition of a detailed schedule	Feedback to identify the realistic production capacity of each iteration.	For each iteration produces a detailed planning (classic mode).   Consider the feedback of the previous iteration to fix the perimeter of the next iteration.
			Each iteration must include a list of prioritized features according to the MoSCoW principle.
			This principle gives a risk management variable on the functionalities that can wait during each iteration without impacting the macro planning.
Documentation	Important for each step and allows to define the communication, validation, and contractual aspects	Production of a  validated backlog before   the start of each iteration	Production of a detailed backlog of each      iteration (documentation of the waterfall mode).   The backlog of each iteration is fixed, only the project manager and the customer can modify it.
			Modifications must be of type: cancellation of functionalities subject to evolution and change (to be put on standby in the current iteration) Identification of the most urgent features of the next iteration that are already validated
Team	A      team with specialize d resources , led by a project manager.	An empowered team where initiative, versatility and communicate on are privileged, supported by the project manager.	At the head of the team a project leader, (conductor) to manage the project and not the team.   The project leader will enable the implementation of project management strategies, priorities, and alignment of the teams on the project roadmap. He will also have the role of simplification for the development teams.
			The teams are also the technical managers of the project, and must in their view alert, propose, communicate, and warn if necessary.
			Each team member, including the project manager, is responsible for the entire iteration and not for a part of the iteration or a particular task within the iteration.
Quality	—	Writing of the test document in parallel with the writing of the backlog.	Production of the quality definition document in parallel with the specifications of each step.
		Each iteration ends with a validation demonstration with the project owner and the customer.	Each functionality requires a continuous control within the team with a first validation by the project manager.   Each iteration requires complete control and validation by the team, the project manager and the customer.
Change	—	Favorable reception	Favorable reception but   following processes, so as not to endanger the current iteration.
			Each change must be studied by the client / project manager.
			Once the decision is made between this pair, it must be validated with the development teams.
			Once validated, this requires an arbitration to cancel the functionality subject to the change in the current iteration (if the change is heavy), and replace it by an urgent, detailed, and validated functionality of the next iteration (if the production capacity of the current iteration allows it).
Follow- up on progress	Measurement of compliance with initial plans: quality, cost and lead time. Gap analysis.	Indicator of what remains to be done	Continuous analysis of what remains to be done in relation to the scope of each iteration, which allows anticipation of risks related to contractual aspects and quality, cost and deadline compliance, with continuous gap analysis that will guide managers in making project decisions.
Risk management	—	Risk management integrated into the overall process, with accountability for identifying and resolving risks. Risk-based management.	The project evolves, and the risks evolve in parallel. This implies a risk management plan integrated into the overall process, with everyone being accountable for Identifying and resolving risks for each iteration.
Measuring Success	Respect of initial commitment in terms of costs, budget and quality level.	Customer satisfaction through the delivery of added value and speed of implementation.	Compliance with initial contractual commitments. Production of added value with continuous integration. Customer satisfaction.

To respond to the constraints of this new era of digital transformation, and to face the limits of mastery of development modes observed mainly in agile models, as well as the contractual aspects not dealt with in agile modes, but which are required for computer production companies. It is essential to propose a hybrid development mode, which highlights the strengths of each mode (what works), as well as the constraints of this new era (requirements linked to continuous and rapid technological change). This hybrid mode (figure 4) can be defined as follows:

6. Conclusion

First, confirm that you have the correct template for your paper size. This template has been tailored for output on the A4 paper size. If you are using US letter-sized paper, please close this file and download the Microsoft Word, Letter file.

In this article we deal with the issue of IT project management in an era of digital transformation. To do so, a study of the literature was essential to understand project management as a managerial innovation in the literature, and as a complement to this study, a practical application in the field which lasted 3 years in 3 IT

Figure 4. Hybrid mode for IT project management in the era of digital transformation

In this study, we put our finger on what works and what doesn’t work in waterfall and agile project management methods. We have production companies. The objective of this study through practice is to understand the environment, links and interactions between the different entities that make up the IT project management ecosystem added to this matrix the constraints related to the digital transformation era.

The result of matching between different entries of this matrix, allowed us to define the outline of a new development mode, which we called hybrid, because it is composed of a mix between waterfall and agile practices.

7. Conflicts of Interest

The authors confirm that there are no known conflicts of interest associated with this publication and there has been no significant financial support for this work that could have influenced its outcome.

8. Acknowledgment

National School of Applied Sciences of Kenitra, IBN TOFAIL Univeristy, Morocco

1. T. Nonaka, H. Nonaka, I. Nonaka, “The new product development game”, Harvard Business Review, 137-146, 1986.
2. P. M. Institute, “Success Rates Rise – Transforming the high cost of low performance”, Global Project Management Survey, 2017.
3. J. Johnson, “CHAOS Report: Decision Latency Theory – It Is All About the Interval”, Standish Group International, 2018.
4. A. David, “Structure et dynamique des innovations managériales”, Ecole des mines, 1996.
5. W. K. E. V. Bénédicte, “Le sens de l’action: Karl E. Weick, sociopsychologie de l’organisation”, Paris: Institut Vital Roux, 2003.
6. H. Mintzberg, “Le manager au quotidien – Les 10 rôles du cadre”, Organisation editions, 2002.
7. H. A. R. L. D. Albert, “Les nouvelles fondations des sciences de gestion: Élements d’épistémologie de la recherche en management”, Presse des Mines, 1er édition, 2012.
8. S. Gherardi, “Practice-Based Theorizing on Learning and Knowing in Organizations”, Organization, 1(27), 211-223, 2000, doi:10.1177/135050840072001.
9. R. Whittington, “The Work of Strategizing and Organizing: For a Practice Perspective”, Strategic Organization, 1(21), 117-125, 2003, doi: 10.1177/147612700311006.
10. R. Whittington, “Completing the Practice Turn in Strategy Research”, Organization Studies, 1(5), 613-634, 2006, doi: 10.1177/0170840606064101.
11. E. Antonacopoulou, “Strategizing as Practising: Strategic Learning as a Source of Connection”, Advanced Institute of Management Research (AIM) Research Paper Series, 1-35, 2006, doi: 10.2139/ssrn.1307066.
12. F. A.-P. V. W. L. Rouleau, “Le numéro spécial de la RFG-AIMS fait peau neuve ! ”, Revue française de gestion, 1(174), 13-14, 2007, doi: 10.3166/rfg.174.13-14.
13. E. MAILLOT, “Diriger un projet web Agile – Utilisez la dynamique des groupes pour décupler Scrum”, ENI, 2015.
14. B. Boehm, “Spiral Model of Software Development and Enhancement”, Computer, 21(5), 61 – 72, 1988, doi: 10.1016/B978-0-08-051574-8.50031-5.
15. H. D. Benington, “Production of Large Computer Programs”, Annals of the History of Computing, 5(4), 350 – 361, 1983, doi: 10.1109/MAHC.1983.10102.
16. J. Stenbeck, “Agile project management mastery in sixty minutes, guaranteed! MI® Global Congress”, Project Management Institute, 2010.

(Click Here)