 | How many times have you seen flashy corporate “blue books” with impressive process maps of how an organization do their business and perform their work? I’ve seen quite a few. It’s not that I have anything against them, it’s just…. Is this really how the organization work? Are the corporate processes updated to actually reflect how work is performed, or are the processes really enforced in the organization? Are the processes adjusted based on feedback from the project organizations? And last but not least, are projects measured against the processes? |
To my experience this very rarely happens, if at all.
I have however seen one company take drastic measures to do something to bridge the gap between the corporate processes and how the organization actually worked. This company decided to visualize their corporate processes in a PLM platform for use across all countries they were involved in. Due to regulatory differences between countries they managed variants of the processes in each country as well.
So how is this different from any other process map you might ask. Well, they not only visualized the processes, they also instantiated the processes, so when a particular project were to be executed the project manager would select the appropriate process and got an instantiated project with template WBS (Work Breakdown Structure) together with all document deliverables that were expected for such a project related to tasks and milestones.
This way they forced the organization to follow the defined processes….. As you might expect there was an outrage, because the instantiated processes was not at all how the organization worked. The project organization had through experience figured out where the corporate process did not work in the real world and had found ways to overcome the problems. This was however the intention, because now there was a very clear feedback loop so that the processes could be adjusted to reflect how the organization actually worked, and since the processes were instantiated in real projects, they could now also be analyzed, measured and improved across the entire organization through dashboards in the PLM platform. This practice became a competitive advantage, and it also allowed processes to be verified and tested in one country before being rolled out in other countries.
I’ve also seen examples of what typically happens when there is only a loose coupling between the corporate processes and how projects are executed and measured. In one company they had very impressive process maps with clearly defined input, output, description of responsibility and activities to be performed within each process step. However, the processes were not really instantiated and measured in the projects.
The obvious question then became: “How is it possible to measure and improve the processes if they are not instantiated and measured in actual projects?”
Well, it worked as long as the company was fairly small and key persons managed to have an overview of most projects. Mostly the projects were executed based on experience and a functioning culture at the main site. The challenge then became apparent when trying to replicate this for other sites where the culture was different. Those other sites tried to execute their projects solely by the process maps….
And that led to some very real problems
In such cases it is of paramount importance to harvest all experience from such projects, analyze, validate and update the process maps accordingly.
So where am I going with this?
In my view companies should work hard on closing the gap between their corporate processes and how the organization actually perform their work. Creating feedback loops from the project organization is one way of doing it. Another way is to actually instantiate the processes for use in projects and thereby making sure that the processes are followed. If the latter approach is selected it becomes very important to have an organization in place to collect feedback, analyze and adjust the processes as the company evolve and develop over time.
Some points to ponder
Bjorn Fidjeland
I have however seen one company take drastic measures to do something to bridge the gap between the corporate processes and how the organization actually worked. This company decided to visualize their corporate processes in a PLM platform for use across all countries they were involved in. Due to regulatory differences between countries they managed variants of the processes in each country as well.
So how is this different from any other process map you might ask. Well, they not only visualized the processes, they also instantiated the processes, so when a particular project were to be executed the project manager would select the appropriate process and got an instantiated project with template WBS (Work Breakdown Structure) together with all document deliverables that were expected for such a project related to tasks and milestones.
This way they forced the organization to follow the defined processes….. As you might expect there was an outrage, because the instantiated processes was not at all how the organization worked. The project organization had through experience figured out where the corporate process did not work in the real world and had found ways to overcome the problems. This was however the intention, because now there was a very clear feedback loop so that the processes could be adjusted to reflect how the organization actually worked, and since the processes were instantiated in real projects, they could now also be analyzed, measured and improved across the entire organization through dashboards in the PLM platform. This practice became a competitive advantage, and it also allowed processes to be verified and tested in one country before being rolled out in other countries.
I’ve also seen examples of what typically happens when there is only a loose coupling between the corporate processes and how projects are executed and measured. In one company they had very impressive process maps with clearly defined input, output, description of responsibility and activities to be performed within each process step. However, the processes were not really instantiated and measured in the projects.
The obvious question then became: “How is it possible to measure and improve the processes if they are not instantiated and measured in actual projects?”
Well, it worked as long as the company was fairly small and key persons managed to have an overview of most projects. Mostly the projects were executed based on experience and a functioning culture at the main site. The challenge then became apparent when trying to replicate this for other sites where the culture was different. Those other sites tried to execute their projects solely by the process maps….
And that led to some very real problems
In such cases it is of paramount importance to harvest all experience from such projects, analyze, validate and update the process maps accordingly.
So where am I going with this?
In my view companies should work hard on closing the gap between their corporate processes and how the organization actually perform their work. Creating feedback loops from the project organization is one way of doing it. Another way is to actually instantiate the processes for use in projects and thereby making sure that the processes are followed. If the latter approach is selected it becomes very important to have an organization in place to collect feedback, analyze and adjust the processes as the company evolve and develop over time.
Some points to ponder
Bjorn Fidjeland
RSS Feed
