IT Project Management: a quick guide to tools and methodologies

Reading time: 9 min

Scrum, Kanban, Waterfall – what are they? When to use them and what are the pros and cons? Choosing the most suitable project management methodology is all about implementing the best way to plan, progress with and successfully complete your project.

Project management approaches can be divided into three broad categories: traditional, agile and hybrid. We have collated some of the most popular names in each category to give you an overview of what they are, how they differ from one another and to give you some guidance as to which one may work best for you.

TRADITIONAL: Waterfall, Prince2, PMI/PMBOK®

Traditional approaches are characterised by a rigorous sequential step-by-step process of product or service delivery. They emphasize meticulous requirements gathering, detailed analysis and design, and stress the importance of documentation. They are best for projects with well-defined requirements to start with. This is so, because the product or service must be delivered in accordance to the approved plan. In comparison to the Agile approach, the traditional approaches do not go into detail in terms of how to create a product; instead, they concentrate on a higher-level management of the project.


When best to use? In an IT setting, Waterfall is best for small or short and repetitive projects where the requirements are fixed and will not change under any circumstances.
What is it? The Waterfall Model is a sequential (non-iterative) project management methodology, where progress is represented as flowing steadily through project stages. The model originates from the manufacturing industry where progress is linear and stages do not overlap – each stage must be completed before the next stage can commence. Waterfall may not be the best choice for complex IT projects, or those likely to change as it does not allow for going back to previous stages or revisions of the product once it’s developed.
  • process is well documented and allows easy managerial control;
  • linear and thus easier to understand.
  • changes to the project deliverables will cost more and more the later they are implemented alongside project life cycle;
  • it will take time for the first results of the project to become visible since it’s not possible to make project stages run concurrently.


When best to use? Prince2 can be applied to almost any project, regardless of its size, type or the industry. It is traditionally most popular in the UK and Europe. Prince2 is best for projects which have a low level of uncertainty and require a high degree of regulatory control.
What is it? Prince2, also known as “PRojects IN Controlled Environments” is a prescriptive, process-based methodology for project management that originated in the UK’s public sector and is now also widely used in the private sector internationally. Prince2 divides the project into manageable and controllable stages that need to be followed with some detailed planning for stages closer in time. It is driven by the business justification and focuses the outputs that the project is going to deliver. A well-defined organisation structure and roles of the project management team, together with escalation and reporting procedures are a must for this methodology.
  • provides a singular standard approach to project management, divides the whole process into easy-to-manage stages and focuses on the final product;
  • supports regulatory compliance as project is well documented with document templates provided.
  • does not allow the level of flexibility offered by the Agile approach – changes may be difficult to implement since they need to go through a chain of approval and require many updates to the documentation;
  • while the process can be tailored to specific project, in general maintaining a number of documents and logs requires additional time and effort.


When best to use? PMI’s PMBOK® can also be applied to almost any project, regardless of its size, type or industry. It is traditionally most popular in the USA and the Americas. It works best with projects which have a low level of ambiguity and uncertainty.
What is it? The Project Management Body of Knowledge (PMBOK®) is a knowledge-based framework that describes established norms, methods, processes and practices. The Project Management Institute’s (PMI) PMBOK® Guide serves as a collection of recognised practices, knowledge and techniques for various aspects of project management. They should be obeyed to fulfil the needs of the business and the project. PMBOK® is driven by customer requirements and focuses on activities in the schedule and the role of the Project Manager.
  • provides information on what a project manager needs to know and what approach should be used while managing a project the PMI PMBOK® way;
  • new tools and techniques can be added and merged within the project.
  • as with other traditional methods, it relies largely on solid initial analysis and planning, which limits the project’s flexibility;
  • strict approach to be followed as a complete knowledge and methodology package.

AGILE: Scrum, Kanban

The Agile is a set of values for software development that contrast to the rigid traditional approaches.

The values include: individuals and interactions, working software, customer collaboration and responding to change, and are shown as more important than processes and tools, comprehensive documentation, contract negotiation and following a plan. The values are set in the Agile Manifesto, a 68-word proclamation of what Agile is all about, and they help the team make decisions on how best to develop software.


When best to use? Scrum is best for projects which are very likely to involve a lot of changes in the backlog or when project requirements could change very often.
What is it? Scrum is an iterative software development framework for managing software development. The approach prioritises working software over in-depth documentation and emphasises team collaboration and self-management. Scrum is based on the assumption that stakeholders don’t know details of what they want the product to be like without seeing a working prototype. This is why, each iteration (called a ‘sprint’) contains a combination of project phases (e.g. analysis, design, implementation, testing, etc.) and aims to deliver a working, tested and potentially shippable product for the customer. The client can then review and request further functionalities to be developed and implemented within the product. Scrum framework values responding to changing requirements over following the rigid plan, thus planning is done before each sprint.
  •  accelerated time to market – functioning software is delivered faster;
  • flexibility to adapt at any time to new business realities as requirements change.
  • a Product Owner (on the customer’s side) must be committed to work alongside the team;
  • requires a cultural change of your team’s thinking if they are used to longer development cycles of the traditional methods.

Project Framework


When best to use? Kanban works best for projects which require quick response times with a minimal amount of planning and where priorities change frequently. It is great for projects where tasks need to efficiently progress from the backlog into the done list.
What is it? Kanban (literally a sign board in Japanese) is a lean scheduling system that originated in 1940s in a Toyota factory in Japan. Nowadays, Kanban is popular within agile software development teams. It is a visual methodology where current work progress is shown on a board. Columns represent various steps in the workflow (e.g. backlog, in progress, testing, complete) and tasks move along the board at a steady pace towards completion. Kanban improves project lifecycle time since it puts a limit on the number of tasks in each workflow step removing blocks and ensuring smooth progress (e.g. limits tasks in the ‘in progress’ column to push them towards ‘completed’).
  • improves time efficiency by removing unnecessary task switching;
  • great for removing problem work as minimises bottlenecks and blocks and encourages team collaboration.
  • may require good prioritisation for the input and then gives steady and regular output;
  • planning to be successful requires an experienced Kanban team – one with good historical data analysis and forecasting skills.


Hybrid models of project management take bits out of the two worlds – the traditional and the Agile, catering for both the development and the business side of the project.

A hybrid model uses different processes and tools from two or more various methodologies. An example would be using Agile methodologies to drive product development but relying on a traditional methodology in relation to detailed requirements gathering, analysis and design for more complex parts of the project.

DSDM Agile Project Framework

When best to use? DSDM may work well in outsourcing, where a detailed analysis and requirements gathering stage may be needed for the proposal or the contract, whereas the development itself can take place in an Agile manner.
What is it? DSDM Agile Project Framework has been created by the Agile Business Consortium (known previously as Agile DSDM Consortium). The framework is a stand-alone, full lifecycle Agile project management and delivery method that includes guidance and optional deliverables required for project governance and compliance. It is based on the assumption that best business value emerges when projects are aligned to business goals, delivered frequently and involve collaboration of empowered individuals. Business people are proactively involved in the project from its onset, guiding development, prioritising the work of the team and ensuring that what is delivered is the best that can be achieved within the budget and the time scale of the project. The framework allows integration with other project approaches – it can be tailored to become an agile project management framework to wrap around other agile development approaches and can also be integrated as an agile project delivery framework within a traditional project structure.
  • clear definition of roles and responsibilities for all involved;
  • effective prioritising with the use of the MoSCoW method which divides requirements into those that the customer ‘Must have’, ‘Should have’, ‘Could have’, and ‘Would like but won’t get’.
  • requires a cultural shift in terms of your development team’s thinking;
  • may be costly to implement as requires developer and user training.