Practices & Principles — Is it the End of the Processes?
For many years, the processes were the “icing on the cake”. PMBOK was completely process oriented, new associations arised to curate BPM practices, such as ABPMP, and lean manufacturing, Six Sigma and other practices were on top of mind.
With time, people got so eager to adopt ITIL, COBIT, BPM, PMBOK and other practices, ignoring completely the mantra “adopt and adapt”, that those same processes ended up becoming synonymous of bureaucracy.
When the agile manifesto started being misinterpreted — I mean, being used — people, already tired of senseless controls, saw in it a chance to get rid of the bureaucracy, and a crusade against processes took place.
Following this wave, recent releases from PMBOK and ITIL have been shifted the focus from processes to practices and principles, reflecting this anti-processes movement.
Processes professionals started reaping the results of adopting management practices as an end, not a mean.
However, the same eager to implement management practices that brought us here, seem to be caughting again the professionals, who don’t seek for understanding what is behind the so called Practices and Principles.
What is a Business Process
Accordingly to the BPM CBOK, a process is “a set of activities which transforms one or more inputs into an output (product or service) with value for the client”.
Taking into consideration this definition, let’s look at some traditional so called “agile” models.
- Scrum — a product backlog (input), which is prioritized (activity), sent to the backlog, which is developed and delivered to the customer;
- PDCA — a set of sequential activities to Plan what to do, Do what was planned, Control what was done and Improve the process;
- Kanban — “…is a workflow management method for defining, managing and improving services that deliver knowledge work” [source] etc.
Well, I don’t know you, but these agile practices look like processes for me.
I would say that a process is universal in our entire ecosystem:
- The translational movement of the earth around the sun
- The 4 seasons
- The economic cycles
- The human life cycle
- The math calculation etc.
Processes are inherent to existence itself. There are processes everywhere.
Processes and Technologies
A fun fact about all of this is that an algorithm is nothing else than a process in a low level, while an application is the automation os a set of processes.
How can we say that processes doesn’t exist anymore? If not, what are the software developers doing?
So, what are the ITIL4 practices?
When ITIL4 was released, I was working on implementing the IT operations of a global technology company. In one of my interactions, a stakeholder argumented that we didn’t need to implement processes, but practices, as this is what ITIL4 recommends now.
Until ITIL v3, the IT Service Management practices proposed came along with a recommended workflow. These workflows were being copied and pasted, and the “adopt and adapt” mantra was hidden and widely ignored.
The public sector in Brazil was full of masters in copying and pasting ITIL and COBIT. I remember a situation where, in an ITIL implementation project at ANAC, a client insisted with me that we didn’t have ITIL implemented because our workflow was different from the book.
By shifting to a practice oriented mindset, ITIL4 switched this focus, passing a clear message that “practices” may be practiced in different ways by different companies, but following more or less the same logic.
In this new version, practices are defined as “[…] a set of organizational resources designed for performing work or accomplishing an objective.”, what point us to a model where the processes are just part of the necessary to achieve the result.
In addition to that, ITIL4 states 4 dimensions to a product or service:
Can you see “processes” in there?
Processes are the means to make sure the Best Practices are really being practiced!
PMBOK Principles
Indeed, PMBOK has also shifted from a Process Oriented approach, to a more Principles Oriented approach. However, just as ITIL, people must remember that PMBOK is not the process of the company, but a set of things the best companies in the world practice and the results are positives.
The set of specific activities you define to put this practices in place are up uniquely to your company, and will depend on the technologies in place, the culture, the maturity and so forth.
Let’s take some information from the official PMBOK 7th Edition page.
PMI states “The PMBOK® Guide — Seventh Edition, which includes a revised The Standard for Project Management, will support this need for flexibility by adopting a principle-based structure for the standard and performance domains for the guide, in place of Process Groups and Knowledge Areas.”
So, no processes, tools and techniques anymore? Let’s see.
The addition of an expanded list of tools and techniques in a new section of the guide titled “Models, Methods and Artifacts” — with additional content on how to apply these tools and techniques by project type, development approach and industry sector are available on a digital platform, PMIstandards+™.
.. and completes:
A new section with guidance on tailoring, which is the deliberate adaptation of the project management approach, governance and processes to make them more suitable for the given environment and the work at hand.
The movement supports the necessary flexibility in adoption project management practices, but in a way or another, you still need processes.
Consequences of Ignoring Processes
Imagine you are raising your son. You can decide guiding him, modeling his behavior and defining clear values as guidelines for his life. This way, you teach him the best practices you’ve learned along your own life.
Or you can let him grow by his own rules, as a savage. He will grow up maladjusted and to fix it may be impossible, or really hard. The processes are similar.
Accepting or not, they are there, and if you do not curate their growth, they will grow anyway by no-one’s rules, and it will be really hard to revert that.
Automation
As we saw, a software automates a process. Then, it is impossible to automate an undefined one. Even Artificial Intelligence must learn from a reference of ideal behavior, otherwise the machine would start repeating the bad ones.
“But Breno, the solution is simple: each team will run their own processes, as they want.”
If, to automate a given process, we need to know it, we would need to create different algorithms to automate each work of each team and, besides that being highly expensive and inefficient, teams would lose the benefit of reusing what are considered the successful practices, being obligated to learn from scratch every lesson by their own pain.
Finally, it is impossible to be a data-driven company without standard processes running over smart softwares.
Can you imagine measuring how many bugs your platform has if each team uses a different name to declare a bug, or use the same names but for different purposes, where a bug might have different definitions for different teams?
As a result, a huge effort to manipulate and clean up data takes place.
Conclusion
- The processes are there, accepting or not;
- If you don’t curate and govern their growth, they will grow as they want;
- Good data comes from good processes;
- Consistent automation is impossible over chaotic systems;
- ITIL Practices doesn’t replace processes, they are implemented by them;
- PMBOK Principles doesn’t replace the processes;
- Bureaucratic is the Manager, not the Process.
If you want to empower people and master the processes without falling into a bureaucratic system, read my article about Service Oriented Organizations.
Did you like it? Applaud, share and comment with that friend who insists the processes disappeared suddenly.
