Project Management Institute

Mechanisms of governance in the project-based organization


Turner and Keegan (2000) described operational control processes in project-based organizations, and observed sometimes such organizations create an interface between projects and their clients, with two roles we labeled the broker and steward. We categorized project-based firms, depending on whether:

• They undertake a few, large projects or many, small projects

• For a few, large, dominant clients or many, small clients.

The interface was initially observed in the case of firms undertaking many, small projects for many, small clients, and we said it might be a transaction cost issue. Closer inspection, showed the interface and the roles of broker and steward exist in almost all cases. It therefore appears to be a governance structure adopted by project-based organizations, and so is by definition a transaction cost issue (Williamson 1996).

We will describe the background to our research, and compare the project-based organization to the classically managed one. We will summarize the four operational control processes in the four scenarios implied by the schema above. We will then describe governance mechanisms observed in each of the four scenarios. We will show substantially similar mechanisms are observed regardless of whether the project is undertaken in the market, (it is done for an external client), or in the hierarchy, (it is done for an internal client).

We will review Transaction Cost Economics (TCE) and what it says about governance of classically managed organizations. We will also conjecture how it might apply to project-based organizations. We will suggest transaction costs are created by risk and uncertainty in the project's product and the process of its delivery, and the need to use configuration management to manage the refinement of both, (reduce uncertainty), as the project progresses. We will also outline the roles of the broker and steward, consider why two roles are required, and will suggest it is because the broker is essentially an extrovert, entrepreneurial role and the steward an introvert, intrapreneurial role.


For two centuries, from the eighteenth to the twentieth century, functional hierarchical line management was the main paradigm for the management of organizations. Classical management is based on the work of:

1. Smith (1776), who introduced the linear-rational model of economics

2. Fayol (1949), who designed organizations with administrative routines and command structures through which work could be planned, organized, and controlled

3. Taylor (1913), who developed concepts of job design, to design the work of specialists within the functions in Fayol's command and control hierarchy.

Under orthodox economics, the firm is viewed as a production function (Williamson 1996). Following Fayol, a structure is created for the firm, which fulfils several roles:

• The setting of policy

• The creation of governance mechanisms

• Control of operations

• Management of human resources

• Organizational learning

It is because functionally managed organizations fulfill these roles so well, that classical management was successful for so long, working well if markets, products and technologies change slowly. Intermediate products procured in the market or made in the hierarchy are stable, decoupling production functions, enabling Taylor's ideas to be applied to the working of each function (separately).

Since the 1950s, project-based ways of working have been adopted to deal with operations that are substantially unique, novel and transient (Turner 1999). We define the project-based organization as one in which: the majority of products made or services supplied are against bespoke designs for customers.

If the end product is bespoke, so too will be the intermediate products, and the processes to produce them will be novel. The production functions are linked (bilaterally dependent), since uncertainty in the process and intermediate products consumed and produced in one step feed into uncertainty in the processes upstream and downstream. Thus, classical management cannot apply, (Turner & Keegan 2000), because:

• The functions are linked, (bilaterally dependent)

• The work cannot be predicted with absolute certainty

• Operational control is aligned with the project, not with the functional hierarchy.

New management models are required, but ones that retain the strengths of classical management.

Exhibit 1. Governance Structures Between BT‘s Back Office and Front Office

Governance Structures Between BT‘s Back Office and Front Office

Exhibit 2. Governance Structure for a Program of Projects

Governance Structure for a Program of Projects

Operational Control Processes in the Project-Based Firm

Turner and Keegan (2000) described operational control processes in the project-based firm, according to whether they undertake:

• A few large projects or many small projects

• A few large clients or many small clients.

1. Large projects for large clients are managed as traditional large projects. A large, dedicated team is created, a firm within a firm, and the project has its own command and control structure. Team members change as the project progresses, and isomorphic team structures are adopted, where the nature of the team is adapted to suit the stage of the project life cycle (Frame 1995).

2. Many small projects for large clients are managed as programs of projects, contributing together to a larger end. Homogeneous teams are responsible for each project from concept to completion. The teams work independently under the guidance of a program manager, who is responsible for the larger concept. The nature of projects is substantially different than in Number 1, and so we labeled them projettes to differentiate.

3. Many small projects for many small clients are managed as a portfolio of multi-projects, (multi-projettes); they share a common resource pool, but have independent outputs. The projettes are managed as in 2, with a homogeneous team responsible from concept to completion. But, we notice here the creation of the broker/steward interface to manage the relationship between client and project teams. A client with a requirement approaches a broker, who identifies the steward with access to resources. The steward compiles the team, including project manager, who deliver the requirement. The project manager, steward and broker work together with the client to ensure the project's deliverables meet the client's requirements. The broker/steward interface is created for efficiency. It is inefficient for all project teams to deal with all customers. It is better for each team to deal with one steward and each customer with one broker, and the brokers and stewards manage the relationships. This is as a Transaction Cost issue. If there are m competence pools and n customers, if the cost of managing a relationship is c, and of maintaining the broker/steward interface C, the broker/steward interface economizes the relationships if:

Exhibit 3. Governance Structure in an Entrepreneurial Start-Up Company

Governance Structure in an Entrepreneurial Start-Up Company

(m ! n) % c ! C < (m % n) % c                         (1)

4. The one case of a large project undertaken for many clients was a start-up company, where the company and its new product are the project. The managing director managed the teams producing different versions of the product. The marketing director worked with potential clients to try to identify their requirements, and match versions of the product to them.

Governance Mechanisms Adopted by Project-Based Firms

The broker/steward interface was identified first in the case of many-small projects undertaken for many-small clients, but we find it is a governance mechanisms adopted in all scenarios except the first.

Scenario 1: Governance Structures for Multi-Projects to Many-Small Clients

Exhibit 1 illustrates a governance structure adopted by BT‘s back office to deliver projects to the front office, but we observed similar structures for new product development in Reuters, by EDS (NZ) in servicing New Zealand Telecom and the University of St Galen's virtual factory in Switzerland. The same structure is adopted whether the projects are undertaken internally (within the hierarchy, BT), externally (in the market, the Virtual Factory), or in an intermediate, hybrid structure (EDS and NZ Telecom).

Scenario 2: Governance Structures for Programs of Projects for Large Clients

Exhibit 2 illustrates the governance structure adopted by Ericsson for the management of its work with its clients to deliver new networks for national telephone operators, as a program as a fishbone of small projettes. Essentially the same structure is adopted in Reuters for the delivery of internal infrastructure (the networks over which they deliver their data products). Thus, again, the same hybrid structure is adopted regardless of whether the project is undertaken in the internally or externally.

Scenario 3: Governance Structure for an Entrepreneurial Start-Up Company

In the entrepreneurial start-up company, Exhibit 3, there is only one project, the company's new product. However, there are several potential applications, with subprojects delivering different versions. The managing director, the original entrepreneur, is the steward assigning resources to all subprojects. The broker is a marketing director employed to sell the concept to various potential users. He was brought in for his selling skills; something the managing director did not feel confident with.

Scenario 4: Governance Structure for Large Projects From the ECI

The last scenario is for large projects from the Engineering Construction Industry, ECI (see Exhibit 4). In this case there is no need for the broker and steward roles. The Project Director maintains the relationship with the client directly. This is as we would expect. With a small number of large projects undertaken for a small number of large clients the relationships are economized with a direct relationship.

Exhibit 4. Governance Structure on a Large Project in the ECI

Governance Structure on a Large Project in the ECI

A Transaction Cost Perspective

Williamson (1996) says of Transaction Cost Economics, TCE:

Transaction cost analysis [is] an examination of the comparative costs of planning, adapting, and monitoring task completion under alternative governance structures…to align transactions (which differ in their attributes) with governance structures (which differ in their costs and competencies) in a discriminating (mainly transaction cost economizing) way.

In the classically managed organization, the fundamental choice is a buy-or-make decision, between:

• Buying intermediate products in the open market, where economies of scale and price competition lead to lower price

• Making them internally in the firm, where high management costs are offset by a better ability to manage maladaptation costs.

The decision between market or hierarchy depends mainly on asset specificity, the amount to which assets used in production are specific to the task or are redeployable to alternative uses. It is assumed production costs are always cheaper in the market due to incentives, economies of scale and avoidance of overhead. Hence at low levels of asset specificity, intermediate products should be bought in the market to minimize cost. However, at higher levels of asset specificity, assets become maladapted to the task, or the products produced are maladapted to the requirement, or the assets achieve low utilization. This increases the needed for control of the transaction. At intermediate levels of asset specificity, control is most cheaply achieved through hybrid forms of governance, and at high levels it is best achieved through the hierarchy.

Williamson (1996) also describes:

Bounded Rationality: Orthodox economics assumes people behave rationally, but human frailty makes it impossible. People try to behave rationally, but that requires them to be omniscient and clairvoyant. Behavior is intendedly rational, but limitedly so, limited by our ability to receive, store, retrieve and process information.

Incomplete contracting: All complex contracts are unavoidably incomplete, because of human frailty.

Adaptation: Bounded rationality and incomplete contracting require adaptation. There are two types, autonomous adaptation and controlled adaptation. The former arises in the market without controls, and the latter in the hierarchy. The greater asset specificity, the greater the need for controlled adaptation.

Opportunism: Some people behave opportunistically some of the time. However, Williamson discounts the notion oftrust. He says calculativeness, which he views as part of risk, causes most people, most of the time, to see that it is in their interest to cooperate. They take good bets.

Bilateral Dependency: This is a state of mutual dependency between supplier and buyer. It evolves during an ongoing contractual relationship. Incomplete contracting and opportunism increase bilateral dependency, and it requires controlled adaptation to manage.

The Fundamental Transformation: A buyer and supplier may initially have no mutual dependency. If there are many potential suppliers of a product, then in the initial bid process, the buyer has many suppliers to choose from. However, once the buyer has chosen a preferred supplier, and especially if the supplier then needs to invest in specific assets, the Fundamental Transformation occurs, they become bilaterally dependent.

The Project-Based Organization

Williamson (1996) states he is dealing with repetitive, routine operations. However, he says the ideas should apply to all transactions, including project-based ones. So how might the concepts apply in the case of projects, where transactions are unique, novel and transient?

The Buyer

The buyer has a problem. Even if an asset has high specificity, it may only be used once. The client cannot invest in the asset to use it once. This requires client organizations to take projects out of the hierarchy (where other conditions suggest they ought to be), and place them in the market. This places clients and suppliers in a state of bilateral dependency even outside the duration of the contract.

The Supplier

The supplier's problem is to deliver a product that meets the client's requirements. Because of bounded rationality, the project's product and delivery process will be imperfectly defined at the outset. This requires the use of configuration management to refine their definition as the project progresses, to ensure what is delivered at the end meets the client's requirements. Thus, the client needs to be involved in the process, creating a state of permanent bilateral dependency between client and contractor.

The Project Transaction

Whereas in classically managed organizations the steps in the process are decoupled because the intermediate products are stable, in the project-based organization the steps of the production process are linked:

• By the uncertainty of the project process

• By the lack of clarity in the definition of the final product

• By the need to take a holistic view of the project process and manage the risk throughout.

This creates a state of bilateral dependency between all the stages of a project, and the functions working on it, with several consequences:

1. It creates a state of bilateral (or multilateral) dependency between the client and the suppliers, (and between suppliers and suppliers)

2. It means the contract is unavoidably incomplete, increasing mutual dependency of the parties

3. It creates an environment for opportunistism

4. It creates a need for controlled adaptation (using configuration management), and a governance structure, which involves the client and supplier(s) in the process.

What Is Going on in the Project-Based Organization?

So what are these governance structures?

Scenario 1: Large Projects for Large Clients

Because both project team and client are involved in a small number of relationships, the need to economize is best served by direct contact. There is a strong, bilateral dependency between different stages of the project, and between different functions working on it, but this can be handled internally by the project director.

Scenario 2: Large Program of Small Projects for Large Clients

Now the need is to manage the configuration of the product and process of the whole program. Indeed, the vision of the final product of the program may evolve as the program progresses. This requires strong communication between the client and program team throughout.

Scenario 3: Many Projects for Many Clients

The need is to maintain communication between many projects and their many clients. The need to economize is not best served by a direct relationship. That would create confusion, lead to potential maladaptation of the projects’ products, and high risk of error, with a heavy impact of seemingly small errors.

Scenario 4: Start-Up Company

The managing director wanted to focus on the science, that was his skill. If he liaised with clients, his skill would be wasted, creating maladaptation. Also, as he was not skilled in commercial issues. Thus the need to economize is best served by the managing director fulfilling the role of the steward, where his skills lie, and employing a marketing director to negotiate with clients and achieve the optimum outcome there.

Why Is the Project Pulled Out of the Market or Pushed Out of the Hierarchy?

External Clients: The answer in this instance is easy. With strong bilateral dependency between client and project team, direct relationships need to be maintained. This cannot be achieved in pure market-based governance structure. It is necessary to create a hybrid, and this will be necessarily focused on the project.

Internal Clients: Now bilateral dependency between the functions working on the project means that they cannot be decoupled (as Taylor and Fayol would have us do). Thus, project centric operational control and governance structures need to be adopted, separate from the functional hierarchy.

The Same Governance Structure: That is different reasons for why the project is pulled out of the market or pushed out of the hierarchy, but does not answer the question of why similar governance structures are adopted. The reason is project centric operational control and governance structures are required in both instances, and so once the project has been made the unit of analysis, then the same solution will be achieved in each case.

The Role of the Broker and Steward

The Broker

This role is to maintain the relationship with the client:

• Identifying and attracting new clients

• Bidding for and winning work

• Liaising with the client during the work and delivery of the product

• Ensuring the client is satisfied, and winning follow-on business

• The role combines ambassador for the firm and resource investigator for the client.

The Steward

The steward puts together the network of resources to deliver the project, ensuring the right people are in the right place at the right time. It is the project manager's role to manage the process. We called the role “steward” after the stewards at a sporting function. Their role is to ensure resources are available on the day, but not to manage the process—that is the job of the referee.

Two Roles?

Why are there two roles? Why cannot one person do both? This requires further investigation. However, we have some anecdotal evidence. An Irish psychiatrist working in Malta, and a psychologist in Australia, gave similar responses. The former said the broker must align with the culture of the client, and the steward with the culture of the competence pools. The latter said the broker is an extrovert, entrepreneurial role, whereas the steward is an introvert, intrapreneurial role. The only empirical evidence is the marketing and managing director of the start-up company, who both match the psychological profiles of them.

With the repeat orders, the roles disappear. With the second or third orders the broker disappears; the steward maintains direct contact with the client. The risk of error is reduced with experience; the need to manage configuration reduces. Eventually the supply becomes routine, the contract is placed in the market or the hierarchy, and the role of the steward also disappears.

Fayol, H. 1949. General and Industrial Management. London: Pitman.

Frame, J.D. 1995. Managing Projects in Organizations. San Francisco: Jossey-Bass.

Smith, A. 1776. The Wealth of Nations. London: Stratton and Cadell.

Taylor, F.W. 1913. The Principles of Scientific Management. New York: Harper & Row.

Turner, J.R. 1999. The Handbook of Project-based Management, 2nd edition. London: McGraw-Hill.

Turner, J.R., and Keegan, A.E. 2000. Processes for Operational Control in the Project-Based Organization. Proceedings of PMI Research Conference 2000, Paris. Newtown Square, PA: Project Management Institute.

Williamson, O.E. 1996. The Mechanisms of Governance. New York: Oxford University Press.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

Proceedings of the Project Management Institute Annual Seminars & Symposium
November 1–10, 2001 • Nashville, Tenn., USA



Related Content