The Pros and Cons of having a methodology

Table of Contents


The Pros and Cons of having a methodology


Is a methodology prescriptive, restrictive, or facilitative? Perhaps methodology is just a different form of persona, culture, identity or ways of working that may change according to circumstance.

In this article I explore methodology as a framework, tool-bag and process.


Methodology is defined as a system of methods used in a particular area of study or activity. In its most common sense, methodology is the study of research methods. However, the term can also refer to the methods themselves or to the philosophical discussion of associated background assumptions. A method is a structured procedure for bringing about a certain goal

If building a methodology should this reflect yourself, your style, your persona or perhaps that of your client, or maybe the supplier-vendor and product. For example, should your methodology be different for a retail, financial, charity or other industry or sector? Should your methodology be different when delivering different products: perhaps different for a roll-out of Product A or Product B reflecting both the nature of the product and possibly the culture of the supplier-vendor?


The key difference between Agile vs. Waterfall is that Waterfall breaks down software development into isolated phases that flow into each other, while Agile advocates iterative development cycles in which multiple lifecycle phases can run in parallel.

It is beyond the scope of this paper to go into detail of each, but it may be worth summarising as part of a broader discussion about methodology.

A Waterfall (PRINCE2) approach to packing might be used if kayaking in the Greenland wilderness. Anticipate every possibility and pack accordingly because failure to plan is planning to fail, and forgetting something like a sleeping bag may be the end of you, as well as your holiday!

An Agile (Scrum) approach to packing might be used if travelling in India where it may be better to simply bring money and buy what you need, when you need it, depending on the circumstances. No point in having more clothing and equipment than you actually need, it will slow you down and cost you more than necessary.


Agile development methodology and testing practices have worked wonders for several organizations with positive aspects. The positive aspects of agile are not hidden. They are very much visible in organizations. There are some of the important points related to the agile model listed as follows

1. Agile focuses on customer feedback, collaboration, small and rapid releases.
2. Its purpose is to manage complex projects.
3. The Agile produces better application suites with the desired requirements. Moreover, it can quickly adapt according to the changes made on time during the project life.
4. It has a small team size. Therefore, fewer people work on it so that they can move faster.
5. The agile model is not a suitable model for small projects. The expenses of developing the small projects using agile are more than compared to other models.
6. In agile methodology, the interaction of customers is very high, as after each iteration an incremental model is deployed to customers.

I have not included a list to all the Scrum roles, processes, tools and templates but have included links to further reading at the end.


It is one of the easiest and traditional model to manage. Because of its traditional development nature, each phase has specific deliverables and a review process. The waterfall model works well in smaller size projects where requirements are easily understandable.

The waterfall model is a universally accepted model. In this method, the whole process of software development is divided into various phases. The development in the waterfall model is seen as flowing steadily downwards (like a waterfall) as it is a continuous software development model. This model is named “Waterfall Model”, because its diagrammatic representation resembles a cascade of waterfalls. Some important points related to the waterfall model are listed as follows

1. Waterfall model is not an ideal model to develop a large scale project size.
2. The requirements in the waterfall model should be clear cut at the beginning time; otherwise, it may lead to a less effective method.
3. In the waterfall model, it is hard to move back in order to make changes in the previous phase.
4. The testing process in the waterfall model starts after the completion of development. So, there is a high chance of bugs to be found later in the project development.

I have not included a list to all the PRINCE2 roles, processes, tools and templates but have included links to further reading at the end.


In my experience as a Project Manager there are merits in each and often a hybrid approach is best according to the client, circumstances, product etc. I liken a methodology to a toolkit and you might pick different tools under different circumstances.

I have often combined the elements of Scrum master and Project manager, and accommodated both Product Owners and Sponsors.

While a Scrum master makes sure their team follows Scrum principles, Project managers oversee the entirety of a project, including logistics like budget and risk. Scrum Masters can be project managers, and project managers can be Scrum masters, but they’re not the same thing

The Project Owner is the individual responsible for the completion of the project on time and on budget. The Project Sponsor is an important stakeholder for the project that has resources invested in the project. The project’s completion typically benefits the Project Sponsor.


Where a methodology can be useful is as a way of explaining a step-by-step process that the organisation understands and follows. However, describing a step-by-step process need not be prescriptive about tools, templates or documents.

PRINCE2 suggests the following logical sequence, but I like to customise this to suit the organisation terminology, structure and governance taking account of existing roles, committees, forums and processes for decision making, funding etc.

1. Starting up a Project
2. Initiating a Project
3. Directing a Project
4. Managing a Stage Boundary
5. Controlling a Stage
6. Managing Product Delivery
7. Closing a Project


Making the methodology fit with the in-house process and culture greatly eases understanding and adoption. Indeed, it may facilitate a broader and useful dialogue about -house process and culture, improving the organisations delivery capacity and capability.

I might suggest that methodology needs to fit culture, but since both are “the way we do things around here” methodology IS culture and misalignment or incompatibility is likely to cause friction.

The culture of and working practices of a regulated financial business are likely to be different from a fast-moving retail business. The process involved in an office relocation will be different to software development. The ways of working for a product lead supplier-vendor operating out of Malaysia and will be different from a service-lead supplier-vendor operating in the US or UK.


The point is that methodology is a tool for communication (we understand where we are in the process) and a tool for control (we understand the roles, goals and process).


An often used term is that of a product roadmap. This is a shared source of truth that outlines the vision, direction, priorities, and progress of a product over time. It’s a plan of action that aligns the organization around short and long-term goals for the product or project, and how they will be achieved.

Your methodology may simply be a roadmap of checkpoints along the way to a destination.


As a coach I often use metaphors as a way to explore topics from a new perspective and unlock new thinking. One day I said… “Well if you were going on holiday you’d have a plan for where you are going, a list of ideas and activities to do when you get there, and enough money and time-off to be able to enjoy the experience”.

This metaphor stuck and grew as the thinking strategy for a technology change programme for a retail business. It is simple in its concept, but powerful because everyone has an experience of travelling and its gives people agency and common sense to their approach to achieving things that is sometimes lost in the complex ‘project speak’.
Key concepts…

1. Project Management Office = Air Traffic Control [ATC]
2. Project = Plane
3. Sponsor = Plane Owner
4. Project Manager = Pilot
5. Project Delivery Team = Crew
6. Stakeholders & Participants = Passengers
7. Budget = Fuel

Key processes…

1. Destination
2. Passengers and crew
3. Pre-flight checks
4. Taxi to the runway
5. Permission to take-off
6. Flying
7. Diversion
8. Landing
9. Disembarking
10. Arriving

I have written about this at length in another article ATC Project Management.

Journey Planner

For one organisation we used a London Underground style map to indicate a variety of routes and stops that may be taken on a change management journey. Perhaps for one project, programme or change initiative we pause at Coaching, Procurement, Training but for others we take a different route with different passengers to another destination via Outsourcing.

The advantage of the London Underground style map is that it can have clear checkpoints, stops or interventions but it is not prescriptive of the journey that you take or the order in which you visit these stations.


I think it is useful to be flexible about methodology and the sign of a good project manager is the ability to pick the right tools for the task. I do however feel that it is useful for everyone to have a common understanding to aid communication, collaboration, coordination and control. So whilst I am relaxed about which methodology, and am flexible to create one where necessary, I do feel organisations going through change should have one.


An experienced Management Consultant and Project Manager, used to working with people and teams in complex legal, regulatory, and technical environments.

• Management Consultant MBA
• PostGrad International Compliance Association
• PostGrad EC Competition Law
• APMG Change Practitioner
• PRINCE2 Project Manager
• Data Protection Officer (GDPR Practitioner)
• International Coaching Federation ICF Trained Coach
• IoD UK Business Mentor
• Chartered Management Institute Tutor for Level 3,5 & 7
• Experienced team and change facilitator

I have more than 30 years’ experience delivering projects, programme and change and have gathered many tools, templates and tips for every type and scale of project. I love drinking coffee and exchanging ideas, so if you need anything please feel free to message me.

Follow me on a journey exploring new ideas and opportunities @timhjrogers #timhjrogers

Tim HJ Rogers
MBA Management Consultant + Change Practitioner
ICF Trained Coach, IoD Business Mentor, Mediator
PRINCE2 Agile-Scrum Projects, Programmes and PMO
Mob 447797762051


We offer #consulting, #coaching, #mentoring, #facilitation and #mediating to support individuals, teams and organisations through #change. We understand #data, #technology and #process and support #people to drive #performance and #progress for #purpose, #profit and #planet.


Difference between Agile and Waterfall model