Project Management: Traditional vs. Agile Approach

These days there are a number of project management approaches being employed by IT project managers and business analysts. Approaches can range from the traditional (waterfall) method, to Critical Chain project management and Agile, all the way to more Extreme project management approaches. Each of these methodologies has their strengths and weaknesses, and the approach chosen is often a reflection of the type of implementation needs required by the project team. Of all of these competing methodologies, the two that are most widely used in practice today are the Traditional approach and the Agile approach.

Traditional Project Management

This project management methodology is a linear model and is the simplest and most intuitive of all the major models in the project management landscape. It identifies a sequence of steps to be completed, and attempts to complete each step in a specified order, with each step needing to be complete before the next step begins. The sequence of steps is:

1. Project Initiation
2. Project Planning and Design
3. Project Execution
4. Project Monitoring and Controlling
5. Project Completion

Strengths: The entire project is scoped out and scheduled at the beginning of the project, resource requirements are known from the start, provides a methodical and structured approach, team members don’t have to be co-located
Weaknesses: Does not accommodate change very well, requires complete and detailed plans early in the project, extends the time before any deliverables are produced, must follow a rigid sequence of processes

Agile Project Management

This project management methodology is a non-linear model that bases its’ approach on collaboration, with a series of relatively small tasks conceived and implemented in an adaptive manner, rather than as a completely pre-planned process. Instead of attempting to plan all aspects of an entire project at the very beginning, the project team evaluates a prioritized list of high level requirements – sometimes referred to as a “product backlog” – and implements a set of features from this list. Iterations of planning, execution and delivery of a feature set – sometimes referred to as “sprints” – are short in duration (usually 2 to 4 weeks).

Strengths: the client can review the current partial solution for suggested improvements, scope changes can be processed between iterations, you can adapt to changing business conditions
Weaknesses: it requires a more actively involved client, it requires co-located teams, the final solution cannot be defined at the start of the project