IT Project management: how to choose the right method to achieve your goals?

Under the growing pressure of business challenges and technological innovation,CIOs are faced with a strategic choice: should they retain the rigor of traditional methodologies, or adopt the flexibility of agile approaches? This article provides a structured overview of the major families of IT project management methods, their advantages and constraints, and recommendations adapted to your organizational context.

With the rise of software development in the 1970s-1980s, and the subsequent explosion of digital technologies, project management methods have diversified to meet ever more varied objectives: regulatory compliance, speed-to-market, continuous innovation, cost optimization… Today’s organizations must navigate between several paradigms:

• Traditional methodologies, which have historically dominated the market, have favored exhaustive upstream planning and a sequential approach to Projects.
• Agility approaches emphasize iteration, continuous collaboration and constant adaptation to user feedback.
• Hybrid and scaled Agility frameworks seek to combine strict governance and incremental delivery, to get the best of both worlds.

In this article, we offer you a clear comparison of the different families of methodologies. You’ll find a simple description of each, as well as key criteria to help you make the best choice for your context.

1. What are the different traditional or sequential methods?

V-cycle and more traditional methodologies are preferred for IT projects requiring complete control of deadlines, budgets, risks and deliverables, such as ERP redesign or critical infrastructure deployment.

Their intention is to reduce uncertainty as far as possible through exhaustive scoping, hyper-detailed planning of each stage, upstream forecasting of each resource mobilized, and rigorously defined perimeter management.

However, this rigor comes at a price, the “tunnel effect”: longer lead times before an operational deliverable is available, and the risk of delivering “off the mark” if business needs evolve during implementation, limiting certain strategic advantages for the company and end customers.

1.1 Waterfall cycle

The Waterfall model, which emerged in the 1970s, is based on a strict division of Projects into successive stages: definition of requirements, design, development, testing, training, deployment and maintenance. Each stage must be fully validated before moving on to the next, ensuring a detailed, stable plan from the outset.

From a management point of view, Waterfall offers the advantage of complete visibility over costs and deadlines, with a fixed Budgets and formalized Milestones. Each deliverable is extensively documented and systematically validated – Statement of Work (SOW), technical specifications, test plans – guaranteeing traceability and conformity.

However, this solution suffers from great rigidity. If a stakeholder identifies a new need or changes his mind after the development phase has begun, it often becomes costly and complex to reintegrate these modifications. The risk is then to end up with a final product that conforms to the initial Statement of Work (SOW), but is obsolete in the face of market developments or real user expectations.

1.2 V-cycle

The V-cycle is an evolution of Waterfall that reinforces the quality aspect. Its distinctive feature is that each design phase (scoping, specifications, architecture) is “mirrored” by a corresponding test phase (unit testing, integration testing, system testing, acceptance testing). This type of V-model allows you toanticipate the validation process throughout the project, rather than concentrating all testing at the end of the cycle.

For sectors where reliability is non-negotiable, this structuring offers a double advantage: clear planning and an integrated quality control process, reducing the risk of severe defects being passed on to production. It is also a framework appreciated by “Waterfall” Projects managers who wish to reinforce their rigor without immediately switching to Agility.

On the other hand, the V-cycle is subject to the same adaptation difficulties as Waterfall. Downstream test iterations, although planned, can only correct what has already been designed. Any redefinition of requirements along the way generates a modification of specifications, redesign and new tests, often resulting in successive delays, which are disappointing for customers.

Requirements specification ←→ Acceptance validation
|_____________________|
Functional specification ←→ System test
|_____________________|
Technical design ←→ Integration test
\__________________/
Development
\_____________/
Coding
\________/
↓↑
Unit testing

1.3 PERT and CPM

PERT (Program Evaluation and Review Technique) and CPM (Critical Path Method) are often associated with traditional approaches to optimizing planning.

PERT establishes a network of tasks with optimistic, pessimistic and most probable time estimates, in order to calculate the average duration and identify the critical path. CPM, on the other hand, highlights the sequence of tasks whose non-adherence would introduce an overall project delay.

These management tools enable you to fine-tune deadlines and anticipate bottlenecks. They are particularly useful for complex Projects (industry…), where the coordination of numerous interdependent tasks is essential.

However, the complexity of their implementation – exhaustive completion of estimates, need for specialized tools and reliable data – often reserves them for large-scale Programs, rather than smaller initiatives.

2. What are the different Agility methods?

Agility has revolutionized IT project management thanks to its ability to deliver software increments rapidly, confronting the product with real needs from the very first iterations and adjusting the trajectory along the way.

It is particularly relevant for continuously enriching a digital product or developing functionalities on an MVP (Minimum Viable Product), thus achieving strategic objectives and giving the company a competitive edge.

However, Agility is not synonymous with “everyone is free to work as they wish” – quite the contrary. Its effectiveness depends on rigorous management and a clear methodology. Without a precise framework, Agility can drift into endless iterations, lengthening deadlines and delaying final delivery, thereby increasing risks.

Agility methods therefore require discipline, maturity, alignment of resources and stakeholder involvement if they are to remain a lever of value, rather than a source of drift.

2.1 Agility foundation and principles

Agility approaches have emerged to overcome the slowness and rigidity of sequential models. Inspired by the Agile Manifesto (2001), they promote :

• People and their interactions rather than cumbersome processes and tools
• Collaboration with the customer rather than fixed contract negotiations.
• Responding to change rather than rigidly following a plan.
• Delivery of operational software rather than excessive documentation.

In concrete terms, these methodologies break down the project into small functionalities that are developed in short iterations (a few weeks) or in continuous flow, offering rapid feedback and the possibility of adjusting at each cycle according to user feedback.

2.2 Scrum

Scrum is probably the most widely used Agility framework. It structures work in sprints, cycles of 2 to 4 weeks at the end of which the team delivers a usable increment. The key roles – Product Owner, Scrum Master and development team – share responsibility for the backlog (list of features to be developed), ensuring that the highest value is given priority.

Scrum ceremonies (planning, daily scrum, review, retrospective) establish a regular rhythm, reinforce communication and enable continuous improvement of the process. This discipline encourages creativity and adaptation, while maintaining a tangible objective for each sprint.

For Projects where requirements often evolve – new feature launches, web platforms, mobile applications – we have the solution. Scrum offers great flexibility. On the other hand, it requires a high level of Agility maturity. The Teams must be sufficiently autonomous, the Product Owner must be available to arbitrate the backlog, and management must be prepared to accept a functional scope that is not guaranteed for a fixed financial investment.

2.3 Kanban

Kanban, derived from Lean Manufacturing (Toyota 50s), offers an alternative without sprints or formal roles. Each task is represented by a card that circulates on a table with columns (to do, in progress, completed), and the number of simultaneous tasks in progress (Work In Progress, WIP) is limited. The mission is to smooth the flow and reduce waiting times at each stage.

This type of methodology is particularly well suited to IT support, application maintenance or DevOps teams, who deal with tickets and incidents on a continuous basis. Kanban is quick to implement, improves visibility and helps identify sticking points in real time, thanks to the visual data on the board.

2.4 eXtreme Programming (XP)

XP pushes Agility down to the code level by integrating robust technical practices: automated tests written before the code (Test-Driven Development), continuous integration, pair programming and constant refactoring. Iterations are very short (1 to 2 weeks) and product quality is guaranteed by systematic test coverage.

This methodology is ideal for Projects requiring high stability and performance, such as financial or embedded applications. It does, however, require a significant initial investment in training and the ongoing commitment of stakeholders to maintain pace and technical discipline. Its advantages lie in the reduction of defects and rapid alignment with business objectives.

2.5 Crystal and Lean Software Development

The Crystal family offers a range of Agile methodologies tailored to team size and criticality, from lightweight Crystal Clear for small Teams to Crystal Red/Diamond for more critical Projects. The emphasis is on human interaction, communication and simplicity, with a formalism that can be modulated according to the type of project and its objectives.

Lean Software Development transposes the principles of Lean manufacturing to IT development: elimination of waste, just-in-time delivery, value chain optimization and continuous improvement. Often combined with Scrum or Kanban, this solution boosts efficiency and reduces lead times without adding procedural layers.

2.6 DSDM

DSDM (Dynamic Systems Development Method) is an end-to-end agile framework , structuring projects in timeboxes and using MoSCoW (Must, Should, Could, Won’t ) prioritization . It combines the flexibility of Agility with formal governance, thanks to a Steering committee and dedicated roles, including project managers.

DSDM is designed for organizations wishing to maintain strong planning while taking advantage of rapid iterations and rigorous management of data, Budgets and milestones.

3. How do hybrid approaches and agility at scale reconcile structuring and agility?

Hybrid methodologies have emerged to overcome the limitations of pure models. They combine the structured framing of the V-cycle with the flexibility of Agility, for example through solid upstream framing followed by agile iterations on certain modules, or through agile cycles framed by fixed milestones. Each type of hybrid solution adapts its stages and use of Resources to field constraints and stakeholder objectives.

Far from being a compromise on the cheap, hybrid solutions require a high level of methodological maturity, as well as a clear vision of what needs to be fixed and what needs to remain flexible according to objectives, risks and the business/customer context.

3.1 Water-Scrum-Fall

The Water-Scrum-Fall approach combines an initial waterfall scoping phase with a Scrum development core, followed by a more traditional final testing and deployment phase. This type of hybrid methodology makes it possible to meet contractual and budgetary requirements upstream, while offering flexibility to development Teams.

Water-Scrum-Fall is often a transitional solution for organizations wishing to introduce Agility without immediately overturning their existing governance. Its main advantage is its ability to preserve the initial structure of a Projects while improving operational responsiveness.

3.2 PRINCE2 Agility

PRINCE2 Agility is the fusion of PRINCE2, a highly formalized project management methodology, and Agile practices (Scrum, Kanban, MoSCoW). It offers a solid Governance framework (phases, committees, management products) enriched by iterations and Agility rituals. Public organizations, large Systems integrators (SI) or highly regulated sectors see it as a way of maintaining their compliance requirements while innovating faster.

3.3 SAFe and DAD

For large-scale, multi-site or multi-team Programs, frameworks such as SAFe (Scaled Agile Framework) and DAD (Disciplined Agile Delivery) offer an enterprise-wide synchronization mechanism.

SAFe organizes several Agile Teams into Agile Release Trains, with common cadences (Program Increments) and roles such as Release Train Engineer or Product Management. This ensures strategic alignment and cohesion of deliveries across large IT project portfolios.

DAD is an Agility and DevOps “toolbox”, guiding each team in its choice of practices (Scrum, Kanban, XP) to cover the entire lifecycle, from initialization to delivery. This modular approach is particularly appreciated by mature organizations seeking to harmonize their Agility without imposing too rigid a framework, while reinforcing the management and use of Projects data.

4. Summary of advantages and limitations according to Project management methods

Method	Key assets	Major limitations
	SEQUENTIAL METHODS
Waterfall	Detailed plan, controlled budgets and deadlines, high compliance.	Rigidity, difficult to integrate ongoing changes.
V-cycle	Quality reinforced by systematic testing, reliability.	Low adaptability, tunnel effect without feedback.
PERT / CPM	Precise optimization of lead times, identification of critical paths.	Complexity, reserved for very large industrial Projects
	AGILITY METHODS
Scrum	Flexibility, fast deliverables, strong collaboration.	Requires Agility maturity and available PO.
Kanban	Smooth, real-time visibility, quick to deploy.	Less structured, difficult to plan strategically.
XP (Extreme Programming)	High technical quality, reliable code, automated testing.	Highly demanding in terms of training and ongoing discipline.
Crystal	Adaptable to team size, easy to use.	Less structured for large-scale Projects.
Lean Software Dev.	Eliminates waste, fast delivery, efficiency.	Necessary cultural change, Lean discipline.
DSDM	Flexibility + governance, clear MoSCoW prioritization.	Less well known, demanding to set up.
	HYBRID METHODS
Water-Scrum-Fall	Initial framing + Agility in dev, flexible.	Increased complexity, risk of diluting Agility.
PRINCE2 Agility	Rigorous governance + Agility, compliance with regulated sectors.	Methodological complexity, strong coordination required.
SAFe	Multi-team coordination, Strategic alignment.	Heavy implementation, requires organizational maturity.
DAD	Modular and adaptable, it harmonizes Agility and DevOps.	Complexity of adoption, need for high level of expertise.

5. Choosing the right method

There is no universal methodology for IT project management. Their relevance depends above all on the nature of the Project, its objectives, context, available Resources and constraints. Each method – whether Agility, traditional or hybrid – brings its own strengths and limitations. The key, therefore, is to assess lucidly which framework will be best suited to maximizing the value delivered and achieving the objectives set by the company and its stakeholders.

Several factors should guide your decision:

5.1 Development team size

• Fewer than 10 people: Scrum, XP or Crystal Clear offer great flexibility and encourage autonomy in the work of Projects and Teams.
• Between 10 and 50 people: Scrum at scale, Kanban, DAD or Crystal Orange ensure cohesion while adapting the formalism to the objectives and work management.
• More than 50 people: SAFe, DAD or PRINCE2 Agile become necessary to coordinate several Teams, optimize the use of Resources and guarantee strategic alignment and sound management of Project data.

5.2 Stable perimeter

• Stable Statement of Work (SOW): Waterfall, V-cycle or PRINCE2 ensure project control and traceability of each stage, data, deliverables and risk.
• Scalable perimeter: Scrum, Kanban or XP allow us to integrate continuous change while preserving the benefits of Agility and responding rapidly to customer needs.
• Mixed: Water-Scrum-Fall or PRINCE2 Agile offer a balance between initial scoping and flexibility, representing an effective hybrid solution that reduces risk while promoting adaptation to change.

5.3 Criticality and regulation

• Regulated sectors (health, defense, finance): V-cycle, PRINCE2 or DSDM to guarantee compliance, data quality and security throughout all stages of the Projects.
• Innovation and R&D: pure Agility (Scrum, XP, Lean) favors experimentation, rapid adaptation and delivery of software or solutions that meet company objectives and customer expectations.

5.4 Agility maturity of the organization

• Beginner: hybrid approaches (Water-Scrum-Fall, PRINCE2 Agile) for a gradual transition while securing each stage of the project and the mobilization of Resources.
• Intermediate: Scrum, Kanban or XP to establish a structured agile rhythm, strengthen management, improve collaboration between stakeholders and minimize risks.
• Advanced: SAFe, DAD or other frameworks at scale to coordinate all initiatives, optimize IT project management and maximize the company’s competitive advantages.

5.5 A collective decision, steered by reality on the ground

Choosing a methodology is never an isolated decision. Above all, the company should not attempt to apply a method in the strict sense. In fact, these methods should be seen as toolboxes from which to pick and choose.

The support of a methodological unit (usually linked to the PMO) is key to implementing these practices. The choice is the result of a cross-analysis shared by several key players, whatever the size of the company:

• The business sponsor or requester, who expresses the objectives, needs and strategic constraints.
• The person in charge of operational management (PMO, project manager, Product Owner or initiative manager), who assesses feasibility, organizes the execution of stages, anticipates risks and optimizes the use of available Resources.
• Key contributors and stakeholders, whether business experts, end-users or technicians, who contribute their knowledge of the field and validate the relevance of the solutions envisaged.
• The CIO or IT manager, who, with the potential help of IS architects, ensures that projects are in line with technical and human capacities, other IT projects and the company’s overall digital strategy, while making sure that data is properly used, software performs well and internal and external customers are satisfied.

This collective decision must make it possible to select the method(s) best suited to the context, while ensuring a common understanding of the advantages, constraints and implications for all the players involved.

5.6 Leveraging the diversity of Skills

In most CIOs, Teams have a wide range of experience, from Agility to traditional methods. This diversity should be seen as a strategic asset, provided that practices are harmonized and the methodological framework is clarified.

This is where the PMO plays an essential role: defining and sharing the chosen method, embodying it, optimizing collective work and guaranteeing its adoption in order to transform this diversity into a collective force at the service of the project and the company’s objectives.

But beyond the choice of method, the challenge for the CIO and the PMO – as well as for their business and management stakeholders – is above all to have a consolidated, up-to-date vision of all Projects.

Whatever the methodology used, it is essential to be able to share a clear picture of the portfolio on a regular basis: progress, sticking points, alerts on risks and budget or Resources issues. These elements are crucial not only for effective steerage, but also for facilitating strategic arbitration at the macro level.

The ability to reconcile a coherent, real-time overview with more micro, operational management of Projects is therefore a key performance factor for the CIO. This is exactly one of Abraxio’s major contributions: to provide CIOs and their Teams with a single, unified environment for steering activity, monitoring the progress of Projects, managing risks and securing decision-making at every level.

Conclusion

There is no universal methodological answer: each company must assess its constraints, resources and ambitions to identify the most appropriate approach. Traditional methods offer a high degree of predictability, agile approaches guarantee unrivalled adaptability, while hybrid and scaled frameworks reconcile governance, flexibility and rigorous management of IT projects.

By judiciously combining these paradigms and clarifying each stage, CIOs will be able to deploy reliable, innovative and optimally steered IT Projects to achieve their strategic objectives, reduce risk, maximize competitive advantage and better serve their customers.