These problems arise when the company grows. As long as the founder is in charge, and the number of employees is limited, the mutual understanding and motivation among managers is sufficient to limit “friction” to a minimum. Then, e.g. a new ambitious sales director comes onboard to reorganize the sales department. The changes might be positive overall, but the former mutual understanding with the director of Manufacturing is no longer there, leading to tensions, that evolve in a search for a “scapegoat” in meetings with the CEO.
What options does the executive have in dealing with the coming disorder?
1) The non-systematic option: manual control. The manager dives into cross-functional conflicts himself and makes decisions thus delivering results.
Problems arise: first, this is not a long-term solution. Too much stress, the subordinates find a way to escape control one way or another. Secondly, this only works to a certain scale, as the organization grows, then one day it is impossible to be involved in all activities.
2) This is often a time when performance indicators become appealing. Of course, having objective information regarding the company’s state is better than not havingthem. But let’s suppose, you received the long awaited information and the performance indicators do not satisfy you – what should you do?
Let’s use an analogy: a car driver looks at the speedometer, and if the car speed does not satisfy him, he can use his gas and brake pedal to put things back to normal. Company performance indicators are like the speedometer, but where are the pedals, that you can press to manage your company?
One option is to delegate the problem down the hierarchy to the department head or department director. However, this only works if the problem is confined within a single department. Cross-departmental problems cannot be solved this way: why should the operations director obey orders from a business development director, for example?
Furthermore, obtaining orders from a manager of equal rank is actually the best-case scenario. The hierarchical model tends to reproduce itself: when CEO asks a department head to deal with the problem, he in turn passes it to the deputy and so on continues the delegation. The problem finally falls on the shoulders of a mid-level manager who has to resolve it somehow without having neither the adequate competency nor authority.
3) When the pile of unresolved problems becomes scary, eternal theme begins: “We need to improve the discipline!” or “We urgently need a computer system to control our activities!”. Although these systems are not useless, expectations should not be too high either. These systems will not become the solution if there is no balance between responsibility and authority: the responsible person simply does not have the authority to solve the problem.
The fundamental flaw in the task control systems is that they only control task execution but do not identify who assigns a task, and how effective the decision about who should do what is. This is the toughest part of cross-departmental problems – those that cross al borders like e.g. “Request to Proposal” process in “Design to Order” business. Functional management works fine down the hierarchy yet is ineffective in horizontal coordination of end-to-end work.
Surprisingly, this problem has been fully realized not long ago. Geary Rummler and Alan Brache investigated it in depth in the classic book with a telling name “How to Manage the White Space on the Organization Chart.”
Currently, there are two systematic approaches to cross-functional problems: 1) project management 2) process management.
Let’s look at the first one. What is the essence of project management?
Basically, the company CEO delegates part of his authority to the project manager. That is, the ability to make decisions and assign jobs, regardless of the rank of project participants. This delegation is limited only by the scope of the project and the project charter.
How does this work in real life? I know a project manager who uses a magic phrase, when facing an opposition to the project: “Are you going to do it, or do you want the CEO to ask you personally? I will be glad to arrange it.” So on the one hand, the project manager bears the sole responsibility for the project success, and on the other hand – he receives a part of authority that belongs to the CEO normally. The right balance between responsibility and authority is the key to effective project management.
Process Management is an attempt to coordinate cross-functional work even further. It is applied when the work follows the same template repeatedly.
The fundamental idea of Process Management is to agree not on how a specific project will be carried out, but rather on how we will implement this and all subsequent similar projects, once and forever.
Key distinctions between the process management and project management are repeatability and predictability. If the structure and sequence of work is unique, then it is a project.
In Process Management, sequence of work can vary from instance to instance: there are gateways, conditions; business rules etc. The key is predictability: no matter how many forks in the road, we know all of them in advance, and we understand the conditions for the process to take one route or another. If this condition is met, we are dealing with a process.
Let’s summarize the difference between manual control, project and process management a table that we use in Comindware:
| Manual Control | Project Management | Process Management | |
| The transfer of responsibility between departments | Through memos and instructions | Arranged by the Project Manager | Automatically in accordance with the approved scheme |
| Initial Costs | No design, initial costs equal zero | Significant cost of project initiation | Significant cost of process design |
| Ongoing costs | High cost due to the use of critical resource – CEO | Significant costs due to the use of valuable resoruce – project manager | Minimal Cost – the work follows a template |
| Predictability | Result is hardly predictable as it depends on subjective factors | The project schedule is based on expert opinions of the project manager and participants | End-to-end monitoring based on baselines, performance targets and SLAs |
| Control | The state of affairs can only be known from the performers’ reports | The project schedule and actual results are controlled seperaly (by different systems), alignment is not guaranteed | It’s impossible to report a task completeness without providing the actual results; misalignments are impossible |
To summarize, Project and Process Management are two alternative methods to deal with unavoidable issues of functional management: loss of control between departments, loss of focus on company’s goals, sub optimization, etc.
Implications:
1) The effect of Project and Process Management is greater the bigger are problems caused by purely functional management. The scale of cross-functional problems is in turn determined by the following factors:
– The depth of the organizational hierarchy. In a purely functional hierarchy, if you need something from the neighboring department, you write an email to the top management who in turn, sends it to the appropriate department. The deeper the hierarchy, the longer is the path and hence the greater are the losses.
– The degree of inter – department collaboration (horizontal span of business processes). The customer doesn’t want to know about the company organization, what he/she wants is to come in and go out spending minimal time and nerves (product quality and price are implied ). Therefore, company operations require Sales, Logistics, Finance and Manufacturing to work in unison. A company failing to achieve this will probably go bankrupt. Claims processing requires cooperation and mutual understanding between departments too, yet it is often out of sight. Negative consequences for business will follow very soon.
– Company’s diversity – geographical, cultural, linguistic. A company spread over number of locations will have communication issues.. However, the dividing lines can happen even within a single office. For example, in one engineering company there are “we” – engineers, designers, developers and “they” -accountants, marketing and finance people.
2) Project and process management is not a substitute for functional management neither a compensation of functional incompetence.
Quite often, when dealing with various clients we have realized that a business process is often seen as a way to build a reliable machine from people who are considered as mechanical parts. Process definitions and diagrams are used to reduce the “human factor” and lower requirements to employee qualifications. The idea is that comprehensive instructions can solve any problem. However, “a smart employee does not need instructions, while for a stupid one they are useless” – this is an extreme point of view, but there is a grain of truth in it.
The enthusiasm towards projects and processes should not develop into neglecting functional competency. So you have great project managers? Excellent! But who is going to do the job itself?
Processes and projects cannot compensate lack of competent employees – this problem can and should be solved by traditional methods, within the framework of functional management. The Head of the department is usually the most experienced and competent professional and one of his duties is to monitor the professional development of his subordinates.
Processes and projects are the only options in another situation: each employee is functionally competent yet a project or a business process are so complex and span over so many departments that collaboration requires special efforts.
Remember how it all began: with the division of labor and competences. Functional structure is the way to accumulate required competencies. The idea to align the organizational structure with processes is bad – processes are cross-functional so we will end up with experts from one functional area spread over a number of single-process departments. As a result, it will become impossible to compare their competence, and their professional level will inevitably fall.
The example of this effect can be seen in companies were a business unit head could get a programmer or two under direct subordination to only work on departmental problems . After such a change, the programmers often begin to consider themselves stars because no one can easily replace them. At the same time, their professional level falls due to the lack of an objective evaluation that can only be done by colleagues from the same profession.
Another bad idea is to change the organizational structure, following the changes in business processes. If the company has reached certain maturity in the process management and/or project management, then it is able to respond to changes in the external environment through changing processes and projects and thus avoiding reorganizational problems.
