This chapter will examine Enterprise management and organizational structures, the principles behind them, and the pros and cons as seen by managers, employees in the trenches, and general management.
We will look at the generic management job and some principles that can be applied to structure an effective organization and management team for several types of Enterprise. We will consider a range of models from single project Enterprises to those that may have many projects or programs going on simultaneously.
We will continue with the analogy used earlier that the Enterprise is a convoy of ships. We will use `enterprise' non-capitalized to refer to those organizations which represent the individual ships in the convoy, or the division of effort within the Enterprise as a whole. First level or lower level managers will be defined as the leaders of these individual enterprises or ships within the whole convoy.
5.1 Two Fundamental Tests for Management Structure
We can begin this discussion with two fundamentals to be applied when contemplating management structure and organization.
A. All managers manage some sort of enterprise having one or more customers with a charter for what they do, and five resources: people, facilities and equipment, information, money, and time. If even one of these elements is missing, the organization should not exist! (Note: by time I mean that if the need for the function is much less than one year, the function should probably be fulfilled by a task force or other ad hoc approach using existing organizations.)
B. Higher level managers supervise managers to whom they have delegated authority within their Enterprise, providing guidance and resolving conflicts among them. If higher-level managers do not meet this definition, they should not exist!
5.2 Organizing for Success
There are many ways to organize and manage an Enterprise to accomplish a mission. Most effective organizations seem to share some common characteristics. When they lose these characteristics, they lose the magic. So how should you as a leader organize your enterprise to best accomplish your mission?
5.2.1 The Importance of Organizational Clarity
A table of organization or organization chart should define an Enterprise's delegation of its mission with clarity (unless you want to hide some activity). Organizations are not blocks on a wiring diagram, but are groups of people with hopes, fears, pride, prejudices, strengths and weaknesses. Again, the convoy analogy seems appropriate. Cargo ships, oilers, and combat ships have their captains, crews, and a part of the overall mission. It is important that each part know how it relates to the whole. How they are segmented, how they are managed, and how they relate to each other has a profound effect on how they perceive the Enterprise and how well they perform within it. The thoughtful creation of the organization chart is a key communication of intended behavior.
Working at different levels in many types of organizations over 40 years offered me the opportunity to encounter and see the strengths and weaknesses of many approaches to management and organization as Enterprises grew and I grew with them. Here I will examine various viewpoints in the typical Enterprise, each with its own set of hopes, fears, triumphs and frustrations.
5.2.2 Five Guiding Principles for Organizational Structure Integrity
These principles spring from the fundamentals that we discussed in Section 5.1. If followed, they should facilitate accomplishment of the mission of any Enterprise by making the jobs of individual managers and those who report to them easier and clearer at all levels of the Enterprise.
The five principles:
1) The organization partitioning should provide for a clear division and delegation of responsibility and authority with a clear understanding of the bounds of that delegation, without stifling innovation and the application of common sense.
2) The organization partitioning should be compatible with contracting integrity among the parts with objectives that incentivize a team approach to meet the Enterprise mission, and with the provision of checks and balances to help identify problems. Contracting integrity means having the ability to commit, and having control over what it takes to meet that commitment. (See Fundamental A)
3) The organization structure should recognize the value of all disciplines and specialties as well as the checks and balances needed to successfully fulfill the mission.
4) The organization structure should minimize duplication of common disciplines, tools, and processes without undermining the delegations of principle 1 and without creating a conflict of interest for any manager or employee.
5) The organization should allow flexibility to grow, adapt to change, and fix problems without major disruption or losing the strengths of the enterprise.
5.3 Roles and missions defined by titles and charters communicate the intended division of responsibility within the Enterprise
An important test of an organization structure is to draw the chart with the organization names and wiring diagram, and then to write bullets under each box that delineate that organization's responsibilities as defined in its charter. If you find more than one organization with any of the same bullets, you should ask why. If no one can explain why in terms of the five organizational principles, then you have failed the test of organizational clarity. Figure 5-1 shows an example of this technique.
5.3.1 Ambiguity causes unnecessary and unproductive conflict.
A close look at the example of Figure 5-1 will show potential overlap between functions identified as marketing and functions in technical support. There is also potential overlap between product returns in marketing and stores under operations. Often it matters less where a
Figure 5-1 Organization Conflict Test
function resides than that it reside in just one place. I have seen all sorts of conflict caused by the simple failure to clarify roles and missions. That energy should be applied to the mission of the Enterprise.
5.3.2 Competition vs. Conflict
Sometimes it is desirable to create competitive activities in order to achieve a greater goal. If so, get the competition on the table openly and be prepared to deal with its fruits.
5.3.3 Setting Expectations
Define the contract with every organization. Measures of performance are part of the contract -- expectations, constraints, standards, and how you expect to be kept informed.
5.4 Organization Models
Now we are ready to think about the form of our Enterprise organization. Where is the Enterprise in its evolution? We will look at four evolutionary states and apply the principles of Section 5.2.2 to suggest effective tables of organization, considering the viewpoints of the managers within that construct and the potential for conflicting objectives among them.
5.4.1 The Small, Single-Product Enterprise
This one (schematically shown in Figure 5-2) is the easiest to think about and the simplest to implement. It is how most new start-ups begin. When there is only one product, everyone is working on that product all the time, in effect. All resources are directed to that product. There is no one working who is not paid for by the revenues of that product, no matter what he or she is working on. Therefore, the project manager for that product owns everything in the enterprise, and may even be the head of the company.
Figure 5-2 Single-Project Enterprise
Suppose we apply the tests of the five principles of section 5.2.2 to this model by asking the following questions:
What are the disciplines required and how much for how long? (Make vs. buy strategy/decisions determine how many people are needed, but not the need to have that discipline represented in-house.)
Which of these disciplines have common heritages, talent pools, education and experience? (Can one manager effectively take on more than one?)
The answer to these two questions establishes the lowest level of leadership responsibility. In this example, there are three subsystems or segments in the product with different characteristics.
Which disciplines are fundamentally embedded in the enterprise and cannot therefore be purchased outside? This gets to the issue of value added and vulnerability to loss of control.
What portions of the work required should be done in-house and what parts are better done by outside suppliers, and why? This determines what size various organizations should be.
What checks and balances are needed
a) to meet the fiduciary responsibilities to customers, suppliers, investors, or regulatory agencies (independent financial audit and reporting)?
b) to provide self-governance within the Enterprise -- for example, test and evaluation and quality assurance functions that are independent of design or software coding, contract and subcontract administration?
c) to provide different viewpoints (marketing, customer relations)?
The answer to these questions defines functions that must be on a comparable level to the much larger development and manufacturing functions.
5.4.2 The Medium to Large Multi-Product Enterprise with One Customer Segment and Common Disciplines among the Products
Figure 5-3 shows a schematic of this type of Enterprise.
The same disciplines are required, but they must be working on three projects at the same time. The projects are probably in different stages of development so the functional disciplines will be required for an extended time.
The same make vs. buy strategy/decisions are assumed to apply, but suppliers may be different on each project, requiring a larger procurement function.
The disciplines have common heritages, talent pools, education and experience, so the same management structure exists, but again on a larger scale.
The disciplines are fundamentally embedded in the enterprise and cannot therefore be purchased outside.
Because there are three projects underway serving the same customer base, the customer interface hasn't changed. However there is now a need for some dedicated project leadership in the product design area, as shown.
Since the products in the example involve the same disciplines, I have assumed that the same portions of the work required should be done in-house.
The checks and balances are the same.
5.4.3 The Medium-to-Large Multi-Product Enterprise with Many Customers and Common Disciplines among the Products
Figure 5-4 illustrates an example of this Enterprise model. I have assumed that the disciplines required for the products this Enterprise makes are the same as in the previous examples. Since we are talking about the same kinds of products, I have assumed the same make vs. buy strategy/decisions; however, this is not inherent in the model. Capacity limits might dictate more buy, or the business base might be large enough to justify investment in in-house capability for some items previously purchased.
We still have the same disciplines with common heritages, talent pools, education and experience. Now with a multiple product base and many customers, it is no longer possible for the Enterprise President and the Marketing Organization to be the primary interface with all customers. In this model, at least three of the products or projects are now big enough to warrant a full-time management function.
Some issues and observations about this type of organization are listed below:
Should product management be divided by type of product, by customer, by geography or by some other factor?
Which disciplines are fundamentally embedded in the enterprise and cannot therefore be purchased outside? Competitive teaming may determine what portions of the work required should be done in-house and what parts are better done by teammates or suppliers.
With many projects or products, there may be longevity and breadth enough to projectize6 certain disciplines in stable, dedicated organizations without duplicating effort. However, in this example I have shown project management offices that integrate across the functional organizations for their projects as denoted by the three arrow symbols. This example is approximately the model for the organization and management relationships discussed in the previous chapter.
Note the titles in the various organization boxes on the chart. If comparable levels don't exist between project management and functional management, this type of organization fails. Perception is important to the Enterprise, which takes cues from titles and relative levels. In order not to create a very busy chart I have not shown lower reporting structure, but it is assumed that all director-level positions have at least one level of management reporting to them.
Note also that the Enterprise has grown sufficiently to have a VP of administration with program controls no longer reporting to that box. There is now a chief legal counsel. The Enterprise also has enough product activity to warrant moving some of the service functions from marketing over to what is now called product support. Marketing now concentrates on sales to new customers, while the projects with product support for service take care of existing customers.
The same checks and balances are needed, but perhaps the Enterprise has gone public and has new requirements.
5.4.4 The Medium to Large-Sized Multi-Product Enterprise with Many Customers and Unique Disciplines for Each Product or Group of Products
Figure 5-5 diagrams this heavily projectized example.
The projects are now large enough and long enough in duration to be called programs. Only two management levels are shown for simplicity, but the substructures are similar to earlier examples. Some of the disciplines required are unique to each program or product line, so the Enterprise has projectized many functions. You can see that one effect of projectization is a duplication of functions within the Enterprise. In this case, only manufacturing and administrative functions remain centralized. In the case of manufacturing it is because of the large investments in facilities and equipment involved. Enterprise administrative functions still report directly to the president's office for fiduciary reasons, but program-related finance and control functions have been delegated to the programs. The Marketing and Business Development functions have largely been assigned to the programs, while the Enterprise function has become more oriented to new markets and strategic planning for new endeavors.
5.4.5 Combinations of the Above.
Of course, there are many combinations of the above examples and many totally different structures that can be constructed. Most will work if they satisfy the principles outlined earlier in this chapter, and have the relationships discussed in Chapter 4. Conversely, there is no organization structure that will work if these principles are violated.
5.5 Projectized vs. Matrix Organizations
Over the years much has been made of organizing by project versus organizing by a matrix of function and project.
In the case-model of section 5.4.1 there is no issue. It's all projectized by definition. In section 5.4.2, there is only one customer base, there are several products at the same location that are competing for resources and facilities, and if each is fully projectized, by definition we are facing duplication at many levels. I chose in the example to create project engineers to integrate the design of each product within the Enterprise. Section 5.4.3 introduces the concept of program or project offices that are dedicated to the management and integration of all activities required to accomplish that project.
Finally, section 5.4.4 introduces a heavily projectized organization driven by three things: disparate customer bases, unique engineering disciplines, and unique test facilities. But it is also clear that this model necessitates duplication of management talent across the board, and duplication of other resources as well. When does this make sense and when does it not?
5.5.1 Arguments For and Against Projectization
When discussing new programs, the question of projectization arises quickly and often heatedly. It is suggested that the program manager can exert greater control if all relevant program personnel, including engineering and operations personnel, are on the program's "badge". It is alleged that only then will the program manager have the requisite level of commitment from all the people working on his program.
If you ask almost any program managers about this, they will attest, for example, that when they don't have to depend on the cooperation of other organizations to meet their objectives, they don't have to expend enormous energy negotiating with their peer managers. If negotiations become stalled, as they often will, and the program manager has to go to general management for resolution, his power is eroded. Moreover, if organizational leadership on either side is allowed to engage in game-playing, the program manager's job becomes impossible. If all the resources report to the program organization, these issues are eliminated.
There are also problems with projectizing, however. As you might expect, the fully projectized organization managers in a multi-project enterprise end up in conflict with other projects vying for priority in resources and facilities. And the checks and balances of the aforementioned negotiations, while they may be time-consuming, can prevent serious mistakes of lack of experience in areas of the job.
In fact, the distinction between projectization and the matrix is not as clear-cut as one might think. I suggest that excepting an organization with only one project, there has never been a purely projectized organization. Any project that had every support person badged to its organization would be unwieldy and inefficient. Projectization and use of the matrix exist in all projects -- the only distinction is in the proportions of each. The success of these activities depends on the integrity of the involved management in fulfilling their respective roles. These roles are discussed in detail in Chapter 4. Interestingly enough, the more experienced project managers become, the less concerned they tend to be about who is badged where, if general management is doing its job in maintaining integrity.
5.5.2 My Preferred Model
If we think of a program as a task force, with every member of the task force committed to the program, then the question of to whose badge or organization the people report is irrelevant. All that remains is to establish conditions that make commitments among the organizations involved real and binding. The first of these conditions is empowerment. Representatives of functional organizations, co-located with the program, have the power to speak and make commitments on behalf of their functional organizations. Day-to-day decision-making authority should never reside with a remote "home organization". Additionally, there should be one person with authority at each "intersection" in the matrix -- not one from the program and one from the functional organization. I submit that in a company that has multiple projects or programs in progress, the most efficient approach is a hybrid organization which uses functional organizations to provide the expertise to many projects, while some functions are projectized. Figure 5-6 illustrates my preferred model.
The gray horizontal arrows cutting across functional organizations depict the program integration and coordination job of the program or project management teams, and the relationships described in Chapter 4.
Chapter 4 presented in a project context my view of the management relationships and guidelines that engender success. They have been very successful in a predominantly "matrix" organization structure, with centralized functional organizations serving all programs. In my experience, the matrix organization structure was the toughest crucible for management relationships. High-integrity relationships were expected, and these organizations functioned well. Certainly there were conflicts, but they were settled constructively and quickly.. It is up to general management to set the guidelines and the environment for successful implementation of a matrix structure, and to recognize when lubrication is needed to keep the system running smoothly.
The guidelines of Chapter 4 build and depend on high-integrity relations between all the parties, and setting and maintaining that environment is the most important responsibility of general management. This means specifically that general management must clearly demonstrate by action what behavior is rewarded and tolerated. As we know, actions speak volumes more than the noblest words. Failure of general management to act congruently with its words undermines all trust. I hope the reader can now start to see how this fabric of integrity is woven through every facet of our Enterprise.
5.6 Some Other Organizational Issues
5.6.1 Acquiring and Maximizing the Utilization of Key Talent
Examine the disciplines needed to support the product lines of the Enterprise. Organize to establish responsibility for the acquisition and effectiveness of those disciplines. This is one argument for not projectizing commonly used disciplines. Having a centralized function allows the cross flow of experience, technology and methods from one project to another.
5.6.2 Implications of Make-or-Buy Decisions on Organization
The decision to buy instead of making a segment of a product does not affect the need for in-house activities (other than manufacturing), only the size of the staffing required to implement the work. One of the frequent mistakes made is to decide to buy from a supplier without establishing a qualified buying expertise. This almost always leads to trouble.
5.6.3 Spans of Control, Deputies, and Assistants; "Flat" Organizations
Periodically, someone gets all worked up about so-called measures of management efficiency, such as span of control -- the number of people reporting to a given level of management. A popular "right" number is seven. More is "better" because it "flattens" the organization. Eliminating levels of management is also a popular theme. Another popular belief is that there should not be deputy or assistant managers. I suggest that these ideas are hogwash! First of all, the "right" span of control, and the need for a deputy or assistant, is a function of workload and time away from the office, not some arbitrary number; and believe me, the workload is very different for different organizations. I have flattened organizations, recognizing the risks, but not using those criteria.
It is also currently popular to talk about "Best Practices". I have noticed that most of the people talking about them have at least two difficulties. One is discerning the differences between apples and oranges: they assume that what has succeeded in one situation will also succeed in another. The second is applying what they espouse to themselves. I always shudder as the "best practices" staffs start staffing up so that they can gather metrics to reduce the number of people working elsewhere.
Careful benchmarking of peer organizations and Enterprises is a good thing as long as one understands all the differences in the nature of things being compared. I believe that the most valid and enduring measures of "lean-ness" are supervisory and managerial ratios over a large sector of the Enterprise, without trying to jam every organization into a standard mold. Supervisory ratio is simply the average total number of employees per supervisory personnel (including all managers) . In my business, a supervisory ratio of about 7 to 1 seemed to be right for the Enterprise as a whole. But some organizations belonged at 40 to 1, while others might quite logically be 1 to1. Similarly, the average number of employees per manager was about 35 to 1, but some organizations could be more than 200 to 1 while others were 2 or 3 to 1.
I personally don't believe in more than one deputy or assistant, unless they are deputies for some management function. The usual place for these is in project offices where, because they are management organizations, the total staff is purposely small, and the management job is across the entire enterprise as illustrated in figure 5-6. My observation is that assistants or deputies to higher-level managers fulfill two important objectives. One is to maintain decision continuity in high throughput environments, while one or the other is on travel, or otherwise away from the office, and where an acting subordinate cannot effectively make the decisions. Second, it provides a valuable training and testing opportunity for the deputy for succession planning. On the other hand, in large functional organizations with lots of subordinate supervisory or management structure, it is desirable to try to let subordinate managers act for their next level up in order to train and test their skills for advancement. Typically, these types of organizations have a more orderly environment over time, so that the risk of a mistake is lower than in a program management environment. But again, it depends on the situation. One critical job may already have a ready backup available, where another may need to develop one.
My point is simply that benchmarking by comparing large peer Enterprises with similar markets makes sense, but it is wrong to try to fit all levels and all parts with the same suit. There are no universal hard and fast rules.
5.6.4 Overarching Disciplines and Their Delegation
Overarching disciplines are the subject of Chapter 7, and are sometimes overlooked in the interest of saving money. This generally turns out to be penny-wise and pound foolish. In this chapter we examined organizational structures where these functions were delegated from the project manager to one or more functional organizations. This will work fine, as long as the delegate is given the charter and authority to enforce it. For product disciplines such as systems engineering or product safety, the clout required can be enforced by the design review process and the technical performance assessment mechanisms.
5.6.5 Division of Responsibility -- a Key Check and Balance.
Division of responsibility provides important checks and balances in the conduct of operations within an Enterprise of any size. In each of the examples we looked at in section 5.4, the last test was about Enterprise checks and balances. Similarly, in the development and production process, divisions of responsibility that require handoff to a separate group for evaluation have some benefits. Handoff of the product design when deemed ready to a separate organization with the skills and knowledge for independent evaluation and hand-over of manufactured product or software programs to quality assurance for acceptance does the same thing. First, it gets emotional investment in creation off the table during evaluation, and second, the hand-over provides a definitive measurement point of accomplishment and the quality of that accomplishment.
5.6.6 Centralized vs. Distributed Support Functions
Finally, an observation about support functions and how they are handled. By support functions, I mean administrative and personnel support and business management functions such as procurement, financial budgeting and control, strategic planning and marketing. Much heat and little light have been generated on the subject of how support functions should be organized. While centralizing support functions appeals to the bean counters, claiming efficiency, it tends to turn the function from an enabling function to a thwarting function, and the importance of this should not be minimized. My feeling is that support means helping and understanding, and that means proximity and local control. So, except for those things that must be centralized for the integrity of the Enterprise, such as financial accounting systems and facility acquisition and utilization, support functions should be distributed with only small central staff coordination groups to keep the Enterprise integrated.
6. projectize: to create a dedicated organization reporting directly to a project to perform a necessary discipline for the duration of the project.
Copyright © 2001 L. David Montague. All rights reserved.