Project management methodologies have come a long way in the last few years. The last two decades have seen an evolution of project experience in organisations. Despite following the project management disciplines, many projects never succeeded, were not delivered on time or did not produce the products they set out to.
This was mostly because the methodologies were flawed, too rigid, or were not suitable to the type of project, or product being produced. New methodologies have emerged to address these problems and much progress has been made toward higher success rates.
So what is a methodology?
A methodology is a specific project management approach with its own set of rules, methods and processes. These are mainly associated with the way the project is initiated and implemented, how teams are organised, and how the products are developed or built. Some of these refer specifically to software development of which project management is an integral part
Project Management Methodologies Summary
Below is a summary of commonly used methodologies.
The Waterfall model is used less often than it used to be in software development because of its inability to cope effectively with changing requirements and rapidly evolving businesses. It is the classic approach to the System Development Life Cycle (SDLC) and is characterised by:
- a sequential set of processes from project concept through design, implementation, testing and installation and maintenance
- requirements and system documentation is done as part of the development process
- there are no overlapping steps or iterations
- requirements are decided at the beginning and can’t really be changed until the end of development
- a final product is generally not seen by the client until the end of the process
The Waterfall Model provided a structured measurable approach that was fairly simple to manage. It also made testing from the accurate requirements easier, and cost estimation simpler, because product specifics were defined at the beginning of the project.
It does not allow for reviewing of the requirements as the project progresses leading to expensive changes and reengineering later, if the client’s idea of the product is not met. The sequential approach can also lead to delays and project overuns.
Joint Application Development (JAD)
Joint Application Design is a project management methodology that focuses on collaboration, and was originally used as a technique for developing requirements for business systems by IBM but can be used to refer to the whole software development process. The basics of JAD:
- it uses facilitated group meetings to define requirements
- sessions typically include a facilitator, end users, developers, observers, mediators and experts
- a few key steps are followed including identifying project objectives and success factors, defining deliverables and deciding the length and structure of the workshops
- a set of documents is produced and distributed after the sessions
JAD is said to speed up system development and improve the quality of the final product. It also improves business stakeholder buy in and increases customer satisfaction.
Sessions with the right people can be difficult to organise. Stakeholders can come to sessions unprepared and address the wrong issues. Trained facilitators and scribes are needed to get the best out of it and are not always available.
Rapid Application Development (RAD)
Rapid Application Development methodology was really developed in reaction to the rigid constraints of the Waterfall Model. It allowed users to react to and refine what they actually saw during the software development process rather than try to define all the requirements before starting. RAD is characterised by the following:
- it works on a system of prototyping
- it focuses on quick development of components to help users visualise the end product
- requirements are adjusted in reaction to reviews of the prototypes as the project progresses
- it emphasises reuse of software components
- often uses computer tools for requirements gathering, prototyping and collaboration
Less upfront requirements and the reuse of components means development time is drastically reduced. Better quality products are produced at the end because of more active involvement of users during the process of development. This in turn leads to better customer satisfaction.
The requirements of the users and developers may not converge as the project progresses leading to inconsistency in the finished product. Developers may not understand the client’s needs or have the skills to interpret them well, creating less control. It is a more risky approach, especially when integrating with larger, existing systems with specific architectures that need to be adhered to.
Agile is a collection of project management and development methodologies have become very popular in recent years because they work! Agile Project Management solves many of the project problems associated with the traditional Waterfall model and is mostly associated with software development projects. The most important one is that requirements don’t need to be finalised at the beginning but can be refined as product development progresses. Agile has the following approach:
- it has an iterative approach, dividing work into short phases
- collaboration between all stakeholders is essential
- the project timeline is fixed but requirements can change
- focuses on delivery of small features built up in increments
- frequent testing is a continued part of the Agile process
- frequent reflection and adjustment allows the team to work more effectively together
- satisfy the customer through continuous delivery of quality software
Good stakeholder engagement throughout the development process creates transparency and a better quality end product. Agile allows for change, and also seeks to deliver frequent business value with its feature based approach. It produces software much better suited to the client’s needs at the end of the project.
Agile is difficult to use on larger more complex projects that cross system or organisational boundaries. Because it relies on close user involvement, if the client base is large or users are short of time, the process can be less effective. It is also more difficult to make estimates and and predict effort required at the beginning of an Agile project.
Scrum is the leading Agile methodology and defines more specific work processes and roles for the project and the team. It was developed as early as 1986 when Hirotaka Takeuchi and Ikujiro Nonaka attempted to create a new product development approach that would increase speed and flexibility. Scrum’s objective is to reduce complexity and produce quality software that meets the client’s needs. Scrum takes the following approach:
- three main roles are defined – the product owner, development team and the scrum master
- the product owner represents the business, organises reviews and communicates progress
- the development team must build the product and have the analysis, design and development skills to do so
- the scrum master is a facilitator and works between the development team and the product owner to assist with progress, remove obstacles and coach the team.
- the workflow is divided into sprints (usually 2 weeks) which start with a planning session that decides on the product feature to be built. The feature is then built, testing completed and the finished product delivered. Each sprint ends with a review.
- Daily standups or ‘Scrums’ are attended by the whole team and used as a way to report progress and raise issues.
- A product backlog is kept which lists all features for the product and whatever requirements are known about each feature at that time.
Scrum has been successful because it has moved the delivery of software value in to the control of the business. The incremental approach allows for more frequent product releases which means it gets to market faster.Frequent reviews improve quality and allow the team to change scope or requirements more often. Autonomy, self-direction and frequent feedback all influence the team positively and create an exciting work environment.
The lack of clear project and requirements definition can make project managers very nervous and be confusing for team members. Changing scope or ‘scope creep’ coming from revised requirements can put pressure on the team to deliver more within the fixed time frame, and the relentless pace of delivery can lead to burnout. Scrum is more suited to projects that are well understood and not highly specialised with specific fixed requirements.
Project Management Methodologies Summary
Many other project management methodologies exist and are variations on the ones listed above. They often have processes specific to particular industries and project types. Other methodologies to explore include Prince2, PMBOK, Extreme Programming, Lean Software Development, Spiral Methodology, Crystal Methods, DMAIC, Critical Path and Six Sigma.