#4. Project management philosophies, methodologies, and frameworks
A rookie project manager may find it difficult to differentiate between project management philosophy and methodology. This is certainly understandable, given the many books that have been written on the subject, each offering a different take on what philosophy is and what methodology is. Furthermore, if the novice peruses a few web articles, this can only serve to further confusion, possibly leading them to lose interest in the matter or form a conclusion without a full understanding.
Later, this confusion can extend to the professional environment, with heated debates between project managers over whether X is a philosophy and Y is a methodology. In light of this, it is essential to gain a comprehensive grasp of the relationship between "philosophies" and "methodologies" in order to make sense of it all.
Let's start with a definition of science:
Science is a particular type of cognitive activity, the purpose of which is to develop objective, systematically organized, and informed knowledge about the world.
Simply put, if a specific set of ideas is formed, and other sciences have not previously described these ideas, and moreover, these ideas are widely accepted in the world: we have a new science.
Simply put, if a specific set of ideas is formed, and other sciences have not previously described these ideas, and moreover, these ideas are widely accepted in the world: we have a new science.
Management is a science that studies the control of intellectual and material resources.
Philosophy
Whereas science is based on facts and axioms, philosophy, which is a derivative of science, has an ideological, more abstract core. Philosophy is a belief system that changes our attitude toward life. Philosophy, in general, shows how we are guided by default when making decisions in our interaction with the outside world.
If you believe that people who wear sneakers or classic shoes are more talkative and trustworthy, then this is one of the elements of your philosophy, as it, to some extent, determines your attitude to people.
Philosophy in project management is a set of ideological principles that answer the question, "What do we need to take into account when managing a project."
For each individual project, we can outline the philosophy that will meet our goals as well as the goals of the project.
For each individual project, we can outline the philosophy that will meet our goals as well as the goals of the project.
Methodology
Whereas philosophy shows us what we need to take into account in project management, the methodology is a set of principles and practices that tells us how to manage the project. A methodology may consist of many different principles and practices that can be used selectively, depending on the specifics of the tasks to be solved.
Framework
A framework is essentially a ready-made, self-sufficient structure with predetermined rules and practices, the preservation of which, in theory, should lead to predictable results. In the context of project management, the framework is a proven, standalone workable set of actions that, in its pure form, does not require the addition of any other practices.
However, we can choose a methodology that is more consistent with the goals of our project, consider what additional principles and practices we need from other methodologies, and borrow those.
Then we can run this mix on our project, complete it, and then come up with some cool name for the framework approach we used (because it was a modified version of a framework, though :) ).
Then we can run this mix on our project, complete it, and then come up with some cool name for the framework approach we used (because it was a modified version of a framework, though :) ).
Philosophy, Methodology, and Frameworks in IT-projects
These days, Agile is an extremely popular and highly appropriate philosophy in IT projects.
The philosophy of Agile is based on 4 points of a manifesto that was written and agreed upon by 17 independent IT experts back in the year 2001 (copy-pasted):
The philosophy of Agile is based on 4 points of a manifesto that was written and agreed upon by 17 independent IT experts back in the year 2001 (copy-pasted):
- People and interaction are more important than processes and tools.
- A working product is more important than comprehensive documentation.
- Cooperation with the customer is more important than agreeing the terms of the contract.
- Readiness for change is more important than following the original plan.
- “That is, without denying the importance of what is right,
we still value more what's left. ”
As you can see, there is not a word about how to manage projects and what practices to use, although fundamental principles to bear in mind when managing projects have been clearly stated.
And despite this rather abstract introduction, Agile is being considered more of a methodology than a philosophy, and the reason is that the creators of the manifesto, at the same meeting in 2001, also declared 12 Agile principles in addition to the four values:
We follow these principles:
- Customer satisfaction is our highest priority, thanks to the regular and early delivery of valuable software.
- Changing requirements is welcome, even in the later stages of development. Agile processes allow changes to be used to provide a competitive advantage to a customer.
- A working product should be released as often as possible, with a frequency of from a couple of weeks to a couple of months.
- Throughout the project, developers and business representatives should work together every day.
- Motivated professionals should work on the project. To get the job done, create the conditions, provide support, and trust them completely.
- Direct communication is the most practical and effective way to exchange information both with the team and within the team.
- A working product is the main indicator of progress.
- Investors, developers, and users should be able to maintain a constant rhythm indefinitely. Agile helps to develop such a sustainable development process.
- Constant attention to technical excellence and design quality increases project flexibility.
- Simplicity - the art of minimizing unnecessary work - is essential.
- The best requirements, architectural and technical solutions are born from self-organizing teams.
- The team should systematically analyze possible ways to improve efficiency and adjust the style of their work accordingly.
Here we see more specific instructions. An attentive manager can notice that these principles answer the question "how to manage?" thereby allowing us to assert that Agile is a methodology.
To avoid confusion because of somewhere abstract, somewhere specific instructions, we can use the values of the Agile manifesto in tandem with the principles of a completely different methodology, and there will be nothing to worry about as long as our decisions are for the good of the project.
Or vice versa, we can use Agile principles along with the values that our company professes.
In other words: we use corporate values as our philosophy (the question "what to take into account?") and the principles and tools of Agile (the question "how to manage?") as our methodology.
Or vice versa, we can use Agile principles along with the values that our company professes.
In other words: we use corporate values as our philosophy (the question "what to take into account?") and the principles and tools of Agile (the question "how to manage?") as our methodology.
Thus, the values that guide you (the question "What to take into account?") are the core of your philosophy. In turn, the principles that describe how to manage a project are your methodology.
So now, we have a general understanding of philosophy and methodology.
Further, I place my old notes about popular methodologies. I won't go into details. You can google anything that is not covered.
Further, I place my old notes about popular methodologies. I won't go into details. You can google anything that is not covered.
Lean (Lean Manufacturing / Lean Development, often used and interpreted as a philosophy):
XP (eXtreme Programming):
Lean Startup:
A few outdated methodologies:
Frameworks
As was already said, a framework is a pre-defined set of instructions that should, theoretically, lead to a specific result if followed. Unlike philosophies and methodologies, frameworks are popular because even a novice can use them - select one, assemble a team, and hire a manager who can be told, “We’ll use [framework name]”.
Frameworks provide guidance on what, where, when, and how to do something. Sometimes they also include safety instructions to avoid certain risks or pitfalls. Though a framework may seem like all you need to succeed in the sector, it is not that straightforward. Still, you can learn just one framework and run a small business that can participate in outsourcing and generate some profit.
So you may ask, “What’s the point of philosophy and methodology? Take the framework, memorize it, and conquer the world!” In fact, there are several reasons why it’s not so simple.
- Without understanding the philosophies and methodologies, a project manager cannot hope to manage large projects effectively. This lack of knowledge will stand in the way of their professional and career growth;
- Frameworks alone cannot conquer the world; only ideologies formed from philosophical foundations can. Examples of this can be seen throughout history.
High-quality teamwork is organized, conflict-free, and puts customer needs first. It is easier to achieve this with a small group, but as size increases, philosophy and methodology are needed to avoid conflicts, inconsistency, and mismanagement. Ad hoc solutions are not ideal, so it is best to outline principles and priorities from the start.
Still, if desired, a framework alone can be sufficient for a company, and many software development outsourcing companies use only this.
Now let's look at frameworks.
Still, if desired, a framework alone can be sufficient for a company, and many software development outsourcing companies use only this.
Now let's look at frameworks.
Kanban
Kanban is very popular among modern companies, and it's also the subject of clan wars: some people call Kanban a framework, whereas many others call it a methodology. In a nutshell, Kanban is neither the one nor the other. Kanban cannot be considered a framework because it is too inferior and abstract for a framework. Still, you cannot call it a methodology either because it contains many clear rules, tools, and instructions that are typical of frameworks.
Kanban was originally developed in the second half of the 20th century as a system for planning and managing the production flows of Japanese industrial companies. At that time, it was called the method. In certain circles, to avoid a dispute, it retains that name today (and that, hopefully, concludes the clan war). In IT companies, only the key tool from Kanban is used: its board.
In its classic form, the Kanban board has three columns. The first column is called “To Do,” and it contains the tasks that need to be done. The second column - “In progress,” is a list of the tasks that are currently in progress (the team is working on them). The "Done" column indicates those tasks that have been successfully completed.
A stolen image from the web:
SCRUM
This is the most common framework (in 2018, 56% of IT companies used it, and there is a growing tendency). We will be discussing it frequently in the following articles, so I will not go into detail here.
Hybrid - SCRUMBAN
As you can guess, this is a hybrid of Scrum and Kanban. Basically, Kanban uses the board and the FIFO ("First In - First Out") principle.
Hybrid- SCRUM/XP
A hybrid of Scrum and XP. From XP, the following elements are mainly used: TDD (Test-Driven Development), Code Refactoring, and Continuous Assembly.
If you would like to read more about the popularity of frameworks and methodologies, you can take a look at VersionOne’s latest public report.
Conclusion
In this article, we have discussed project management philosophies and methodologies and understood their differences. We examined how philosophies, methodologies, and frameworks relate to each other and discussed the meaning of each of these terms.
In the next article, we will learn about the different types of software development cycles and focus on common aspects for Agile teams, gradually delving into the workflow.