Processes for operational control in the project-based organization
J. Rodney Turner, Professor of Project Management, Department of Business and Organization, Faculty of Economics, Erasmus University Rotterdam
Anne Keegan, Ph.D., Docent and RIBES Researcher, Department of Business and Organization, Faculty of Economics, Erasmus University Rotterdam
During the second half of the 20th century, there has been an evolution in the nature of organizations, their work and its management, from the functional organization almost universally adopted in the first half of the century to the project-based organization (Peters, 1992; Hastings, 1993; Turner, 1999a). This evolution has been caused by the changing nature of work from mass production, with essentially stable customer requirements and slowly changing technology, to the current situation where almost every product supplied may be against a bespoke design, and technology and markets change continuously and rapidly. Whereas the design of the functional organization is underpinned by a strong theoretical base, namely the classical management theory developed in the 19th and early 20th centuries (Mintzberg, 1979; Huczynski, 1996; Morgan, 1997), the design of the project-based organization has no such theoretical base. The project-based organization requires new theories for its management. With the eventual aim of developing such a theoretical base, we at Erasmus University Rotterdam are conducting an international research project to determine how project-based organizations are and should be managed, (Turner & Keegan, 1999). In this paper we present our findings on practices and processes adopted for the management of operations within the project-based organization.
We start by defining the project-based organization (PBO), and argue that it requires different approaches to its management than those used successfully in the functional, hierarchical, line management organization. We then describe a model for the management of the project-based organization, and show how the size and nature of customers and the projects undertaken for those customers leads to four different approaches to the structuring and management of operations. We describe the different ways in which project-based organizations manage their operations in each of the scenarios identified of:
• Large projects—few customers
• Large projects—many customers
• Small projects—few customers
• Small projects—many customers
In order to create customer-focused processes, organizations strive to maintain a one-to-one relationship between project teams and customers. This situation exists perforce in the first case. In the second case, an internal sales or marketing department manages the interface with the many customers, and acts internally as a few customers for the few large projects. In the third case, the organizations group projects into a few large programs of projects for their few customers. In the fourth case, many different approaches are adopted to manage the interface between the projects and the customers. These include:
• The assignment of specific project roles to coordinate the network undertaking the projects
• The creation of an internal market to manage the interface between projects and customers
• The grouping of projects into programs, where each program has a few customers
• The use of matrix management.
The Project-Based Organization and Classical Management Theory
We define a project-based organization as:
An organization in which the majority of products made or services offered are against bespoke designs for external or internal customers.
Exhibit 1. Customer-Focused Processes Versus Internally Focused Functions
The project-based organization may be stand-alone, making products for external customers, or a subsidiary of a larger firm, making products for internal or external customers. It may even be a consortium of organizations, which collaborate to make products for third parties (Katzy & Schuh, 1998). (Throughout the rest of the paper, we use the word “product” to mean “product or service” for simplicity.)
We previously described why classical management theory, developed as the basis for the management of the functional, hierarchical, line management organization, is inappropriate for the project-based organization (Turner & Keegan, 1999). Classical management (Mintzberg, 1979; Huczynski, 1996; Morgan, 1997) is based on the work of Smith (1776), Taylor (1913), Fayol (1949) and Weber (1947):
1. Smith proposed that economic improvement comes from a constant drive for greater efficiency. This striving for greater efficiency still pervades management thinking. We have previously called it the Economic Orthodoxy (Turner & Keegan, 1999).
2. Taylor developed concepts of job design. Based on his scientific management thinking, the jobs of the organization are precisely defined, the competences required to do the job described, and people found to fill the roles. This standard approach of assigning the person to the previously defined job, and not vice versa, we call the Human Resourcing Orthodoxy.
3. Fayol and his followers (Urwick, 1943) designed organizations with administrative routines and command structures through which work could be planned, organized, and controlled. From this comes the concept of the organization structure, a single model of the organization and its functions, which is used for multiple purposes, including its governance, operational control, and knowledge and people management. The focus on a single model for the organization we call the Organization Structure Orthodoxy.
4. Weber (1947) said this unfortunately led to the creation of dehumanizing bureaucracies. The subsequent developments of human relations and neo-human relations (Huczynski, 1996) merely put a humanistic gloss on the dehumanizing nature of the bureaucratic organization identified by Weber.
Classical management theory works well, and is highly appropriate where the work of the organization is stable (Mintzberg, 1979; Huczynski, 1996; Morgan, 1997). This will be the case if the customers’ requirements and the technology of the organization are slow to change. Job roles can then be identified independently of the people doing them, stable bureaucratic command and control structures can be put in place, and the whole structure can work to make itself more and more efficient through habitual incremental improvement (Turner, 1999). Stable functions can be defined because both the work of the functions, and the intermediate products that pass between them are well defined and unchanging, leading to the functional approach to work. Such organizations work like machines (Burns & Stalker, 1961; Mintzberg, 1979; Morgan, 1997).
The ideas of Smith, Fayol and Taylor, and the associated orthodoxies, are at best inappropriate for the project-based organization, and sometimes positively damaging:
(a) Because every customer's requirement is different, a unique, novel and transient project must be undertaken to deliver every product or service (Turner, 1999). This means the work of each function changes for every order, as does the intermediate products passing between them. This in turn means different, customer-focused processes must be adopted for the completion of every order, see Exhibit 1, (Turner & Peymai, 1995; ISO 10,006, 1996; CCTA, 1996; Turner, 1999). Exhibit 2 shows a version of customer-focused processes recommended by PRINCE 2 (CCTA, 1996). It is therefore not possible to define a single model for the organization to cover all circumstances. A different model must be developed for governance, the control of different operations, and for the development of the knowledge and people. Thus, the Organization Structure Orthodoxy does not apply to the project-based organization.
Exhibit 2. Customer-Focused Processes Recommended by PRINCE 2
(b) Because work is always changing, it is not possible to define job roles precisely, nor independently of the person fulfilling the role. People with a different type of competence must be found; those who are familiar with the technology and knowledge of the firm but are able to work in unfamiliar, unstructured situations, (Keegan et al., 1999). The individuals determine what job roles are required by the task, and adapt their work accordingly. This requires different approaches to people development, and means the Human Resourcing Orthodoxy is inappropriate for the project-based organization.
(c) It is therefore not possible to aim for efficiency. Indeed, efficiency works against effective project management. A drive for efficiency reduces the ability to flexibly respond to risk and the uncertain, changing nature of projects (Turner & Keegan, 1999; Turner, 1999a; Turner, 1999). The economic Orthodoxy can be positively damaging for the project-based organization.
(d) In some project-based organizations, the nature of the projects and customers are such, that new command and control structures need to be created for every project, and sometime even at each stage of a project. Some project-based organizations can have stable command and control structures, but others, particularly those undertaking large projects for a few customers cannot. This requires organizations to adopt several models for their governance and control, several organization structures.
Thus we need to find new theories for the management of the project-based organization to replace those of Smith, Taylor and Fayol.
A Model for the Project-Based Organization
To identify practices and processes adopted in the management of project-based organizations, we have undertaken an international research project in which we interviewed firms from countries throughout Europe, see Exhibit 3 (Turner & Keegan, 1999). We have identified that in the functional, hierarchical, line management organization, the functions fulfill five roles, which must also be fulfilled in the project-based organization:
Exhibit 3. Organizations Interviewed
• Operational control
• Management of human resources (people and competence)
• Management of knowledge, learning and innovation
• Management of customers.
In this paper we report the finding from our findings about the management of operations within the project-based organization. We identify that different operational models are adopted for different project types, and that this is influenced by the nature of the customers and projects undertaken for them. Exhibit 4 represents the management of operations as a process. (Exhibit 4 loosely follows the IDEF0 approach to process modeling developed by the U.S. Air Force, Turner, 1999.) It shows six essential steps in the process:
• Winning the customer's order
• Designing the product and the process for its delivery
• Producing the components of the product
• Configuring the components of the product
• Commissioning the product and delivering to the customer
• Maintaining customer support after delivery.
Winning the customer's order: In order to win the order the firm must identify potential customers, define their requirements, and demonstrate a superior ability to deliver them. This will often involve preparing a competitive tender, or bid, for the work.
Exhibit 4. The Operations Processes in the Project-Based Organization
Exhibit 5. Our Sample by Size of Project and Number of Customers
Designing the product and the process for its delivery: The unique product and novel production process required to deliver the customer's requirement is designed. This includes the functionality of the product, its components and how they are configured to deliver the functionality, and the process by which they will be produced.
Producing the components of the product: Components of the product may be sourced from a number of different places, internal or external to the organization. The chain or network of supply needs to be designed and managed.
Configuring the components of the product: The individual components must then be configured into the eventual product to deliver the required functionality.
Commissioning the product and delivering to the customer: Not only must the product deliver the required functionality, but it must also work to meet the customer's requirement. The commissioning may be done by the customer, or the project-based organization, or both working together. The firm may also need to provide ongoing support to the customer, and continue to manage the relationship to win future work.
Maintaining customer support after delivery: After delivery of the product the customer may require ongoing maintenance or other support. This will also be an essential part of maintaining links with the customer to obtain leads for potential future work.
The Influence of Customers and their Projects or Products
Different organizations adopt different approaches to the realization of this process dependent on the nature of their customers and the projects undertaken for them. Most organizations undertake a portfolio of projects for a range of customers, but we find that the operational processes adopted depend on whether the organization undertakes a few large projects or many small projects, and whether they have a few large customers or many small ones.
Size of projects: We define a large project as one that is a significant proportion of the firm's turnover, and a small one that is a small proportion. Simple arithmetic says that if an organization is undertaking large projects it can only do a few of them, whereas if it is doing small projects it must be doing many of them to make up the turnover. The emphasis here is on the size of the projects as it is that which determines the operational management approaches adopted. Obviously some organizations have a mixture of large and small projects. Almost all firms for which the dominant part of their business is large projects will be undertaking some small ones. However, it is the few large projects that dominate the approach to managing the business.
Exhibit 6. Managers Responsible for the Operations Processes
Number of customers: Some organizations work for a few dominant customers, whereas others have a large number of customers. Again, simple arithmetic says that if there are a few customers, each must provide the firm with a significant proportion of its turnover, (hence the reason they tend to be dominant). On the other hand, if there are many customers, each will provide the firm with a smaller proportion of its business, and the firm will be less reliant on any one customer. The emphasis here is on the number of customers as it is that which determines the operational management approaches adopted. Again, a firm with a mixture of large and small projects may have a mixture of large and small customers, but it is the few dominant customers that determine the operational management approaches adopted.
Exhibit 5 shows our sample by size of project and number of customers. The organizations doing work for internal customers are all shown in the bottom right box, below the dotted line in italics. Organizations tend not to retain the expertise internally to undertake large projects. Since the work tends to be rare, large projects are almost universally let to external suppliers. It might be said that internal departments doing internal work have just one, dominant customer. However, the nature of the relationship with the other parts of the business with which they work tends to be the same as external suppliers with many customers. We consider in turn the different operational processes adopted by organizations from each of the four quadrants in Exhibit 5. Exhibit 6 gives examples of the names used to describe managers responsible for the steps in the process.
Large Projects—Few Customers
Firms undertaking large projects for a few customers tend to be from the Construction or Heavy Engineering Industries. As the projects are large, dedicated teams are created to deliver them, and these are inevitably large, being almost small organizations in their own right. The project organizations created have what Frame (1995) describes as an isomorphic structure; the structure of the project organization reflects the nature of the task being done. The project organization has elements reflecting each of the six steps of the process in Exhibit 5.Within the project organization, dealing with different steps of the process, there are teams with differing substructures.
Winning the order: This is the responsibility of the contracts or bid management department. The bid team is a task force, led by the bid or contracts manager. However, the structure of the task force may be one of two types described by Frame (1995), either a surgical team or an egoless team. In the surgical team the preparation of the bid is clearly managed by the bid or contracts manager, who draws on the expertise of others as required. In the egoless team, the group preparing the bid works together as a team of equal players, and the bid or contracts manager facilitates the process, perhaps even working as a junior member of the team. Most of the organizations in our study adopted the surgical team. In one company, ABB Lummus Global, bid management is viewed as a core competence, and attempts are made to continuously identify and spread best practice in bid management.
Designing the product: At the design stage, a matrix approach is adopted (Frame, 1995). That is teams of engineers and designers work in their specialist functions, doing the design work for that function or discipline for all areas of the plant. A lead engineer will be responsible for the input of a given engineering discipline. They work closely with the project engineers who are responsible for coordinating the design of a given area of the plant and configuring the components of the product. This is matrix working at the project team level; it is not matrix management since the designers are working for one manager only, the lead engineer, and the project engineers must work through them to obtain the design input to their part of the plant.
Construct components of the product: The construction is managed by the project engineers and specialist construction supervisors. The team structure adopted is a task hierarchy (Frame, 1995). Multidisciplinary teams do all the work to complete area of the plant.
Configure the components of the product: The delivery of each area is managed by a project engineer, who ensures plant is delivered in accordance with the design. They are responsible for link up and commissioning of the plant. During this stage, the team type moves from the task hierarchy adopted during construction, back to the surgical type as the final product is configured and commissioned for the customer. Multidisciplinary task forces work under the lead of a specialist to ensure work is completed quickly and efficiently.
Deliver the product to the customer: The project is managed by a project manager or, if of sufficient size and complexity, by a project director. Reflecting the importance of this role, one firm we interviewed assigned it for a strategic project critical to the firm's future to the previous Project's Director; he went from a governance role on the board to an operational role. However, the new role was of such risk and significance to the firm's future and to the client that it was viewed as a development for the individual concerned. In all of the companies in our sample project management is considered as a key source of value added both to the company and the client.
Maintain customer support: After commissioning, the project team will be disbanded. Ongoing customer support, which may include maintenance or the supply of spares, or the design of plant upgrades or new products. The maintenance of customer support is essential for the winning of new business. The work at this stage will be handed back to the functional organization, to be undertaken by appropriate departments. However, it may be managed by a commercial or contracts department, on a matrix working basis again.
There are two further points of interest:
(a) It is clear that organizations adopting this approach create a command and control structure for each project. Further, the nature of the projects is such they are often undertaken remote from head office. Until recently, communications were such that project managers had to be empowered to take decisions without reference back to head office. Communications are now instantaneous, but project directors still expect to operate as the head of their autonomous command structure. We interviewed one project director from a company that had recently been taken-over by a company from the defense electronics industry, which does many projects for a few customers (see below). More stable command structures are adopted by this type of firm, and our interviewee found it difficult working for a master that would not empower him to the extent he was used to. (He left and is now a general manager with a competitor.)
(b) The overall project structure adopted is isomorphic, so as a project progresses the nature of the team varies, reflecting a changing need of the process and a changing emphasis on the customer and product. It starts as a surgical team of experts led by a specialist, focusing on the customers’ requirements. For design, a matrix structure is adopted, to manage the simultaneous input of several resources into several of components of the product. For construction, a task hierarchy is adopted, to manage the input of the resources into the construction of discrete components. For commissioning, the focus changes back to the customer's requirements and so a surgical team is readopted. For ongoing support a matrix structure is adopted again, with specialists performing work on all areas of the plant as required.
In this case of large projects for large customers, there is a direct, one-to-one relationship between the project and the customer. We find in all the other cases a broker linking the project team to the customer is created in one form or another.
Large Projects—Many Customers
Only one organization from our sample could be said to be undertaking large projects for many customers. That is a research company established to develop an idea of the entrepreneurial managing director. It really only has one project that is the entire business. Indeed, one of their customers is viewed as being the main potential user for this product once developed. However, there are many other potential users for whom different variants of the product will be made. Hence, although one is funding much of the development work, and obtaining patent rights as a result, they are seeking many other related (but different) applications for the product, and so are talking to several customers. However, as far as the internal project team is concerned, there is only one external customer, the Marketing Director. Hence the organization has created an artifice whereby the project team appears to be undertaking a large project for a single dominant customer. The Marketing Director is the broker between the project team and all the external customers.
The firm also adopts an isomorphic approach for the project structure. Effectively at the moment the project team is only working on the design of the product, and different members of the team are developing different components of the product. The firm is considering setting up a manufacturing unit to make the product, which would just extend the isomorphic structure, but they are also considering contracting out the manufacture.
Small Projects—Few Customers
These organizations effectively undertake a program of work for each of a small number of clients. Each program is large in itself, and is therefore a significant proportion of the firm's turnover, but each program is made of several small projects. The essential difference with the large project is the large project leads to a single deliverable, and when that is delivered the project is over. The programs undertaken here can carry on indefinitely, and indeed the eventual outcome is always being updated. Each individual small project is well defined, but technology is continuously developing. Although the clients know the general scope of what they want, the actual scope evolves as the technology develops. One organization we interviewed from this category was Ericsson in the Netherlands. They are developing telecommunications networks for several of the operators in the Netherlands. The networks evolve with time, but there are clearly identifiable projects to deliver individual components of the network.
Because these organizations have a longer-term relationship with their customers, they tend to adopt functional approaches to the management of the early and later steps of the delivery process, see Exhibit 7. A Sales and Marketing Division, with Account Managers, manages the relationship with the clients, and draws on the skills of an Operations Division to undertake the work. However, within the Operations Division are Solutions Managers who have a long-term relationship with the client, working with the client on the evolution of the program. They identify, with the client, a need for individual components of the program to be delivered, and only then are individual project managers assigned, from within the Operations Division, to deliver the individual project requirements. This leads to an overall structure of the program, which has not been previously identified in the project management literature, but which may be described as a fish-bone approach, see Exhibit 8. The backbone represents the ongoing development of the program, with project teams consecutively contributing individual components. The individual project teams tend to adopt a specialist, or surgical, structure (Frame, 1995). Thus the operations process therefore works as follows:
Exhibit 7. The Relationship Between Sales and Operations in a Project-Based Organization Undertaking Many Projects for Few Customers
Win the order: This is a continuous (functional) process undertaken by Accounts Managers within the Sales and Marketing Department. They win the order for the overall program, and work with the client to maintain the relationship. The Account Managers and Solutions Managers are constantly working with the clients on the developments of the programs, and the identification of new projects.
Design the product and delivering individual components: One surgical project team tends to be responsible for the design and delivery of each project. The project managers and their specialist teams design the individual components of the program delivered by the projects. Each project delivers a single product, but it is in effect a component of the overall program. Hence the project managers and their specialist, surgical teams deliver the individual project components.
Configure the components: The Solutions Managers work with the Project Managers to configure the individual project components into the overall program. Though each component is in itself unique and novel, this does tend to be an ongoing, repetitive, development task.
Exhibit 8. The Fish-Bone Approach to Program Delivery in a Project-Based Organization Undertaking Many Projects for Few Customers
Deliver the product to the customer and Maintain customer support: Hence the delivery of the final product to the customer and the ongoing support is also a repetitive development task, undertaken by the Solutions Managers and the Account Managers.
We see a different approach here for the adoption of command and control structures and team types than we did with the companies undertaking few projects for few customers:
(a) Stable command and control structures linked to the overall structure of the business are adopted in this case. This is possible because there is a longer-term relationship with the customer based on the programs of development. The individual projects, though unique, novel and transient, deliver only a small component of the overall product. Although the project managers may be empowered within the context of their project, their scope for flexibility is limited by the size of their project, and the constraints imposed from above by the program. You can imagine the tensions that arose when a firm used to this way of working tried to apply their standard control techniques to the project director on a $0.5 billion project (see above).
(b) Again, the team structure changes between the interface with the customer and the project delivery; the emphasis shifting from customer focus to product focus. In this case, the team approach adopted at the customer interface is a functional approach, Sales and Operations. The team structure adopted for projects is a surgical team, a team of specialists led by an expert delivering a component of the product.
Small Projects—Many Customers
The most significant observation in this scenario is how organizations reduce the number of interfaces between project teams and their customers. The project teams here need to focus on completing the projects, managing the process and the product delivery, not managing the relationship with a large number of customers. Just like in the one large project-many customers scenario, it is necessary to create an internal customer so that the project team can deal with that one customer. The project teams just do not have the capacity to manage an interface with a large number of external customers, and so an internal customer, or broker, must do it on their behalf. However, there are several ways of achieving this:
The Virtual Factory
The Virtual Factory was created by the University of St. Galen and involves a consortium of manufacturing companies around Lake Constance (Katzy & Schuh, 1998). Bespoke products are delivered to clients, which are beyond the capabilities of any one of the companies working on their own. They do this by forming a network in which individual companies fulfill different roles in the operational process. Effectively an isomorphic network is created project by project to meet the individual customer requirements, the product and process required to deliver it. This is most like the large projects-few customers scenario, with isomorphic project team structures created with bespoke command and control structures.
Katzy and Schuh (1998) identify that companies in the consortium must undertake certain specialist roles on the project team, corresponding to some of the managerial roles associated with the operational process in Exhibit 4. These are listed in Exhibit 7. Particularly, the broker acts as the customer interface, shielding the rest of the project team from the need to deal with several customers.
BT‘s Back Office
BT‘s Back Office suffers because the Front Office is constantly changing. Since 1990, the operating divisions have gone from three (domestic, business and international) to sixteen and rising, recognizing growing telephone usage, market segmentation, and demographic changes. If the Back Office were to constantly adjust itself to deal with the changes in the Front Office, it would become chaotic. It has solved this problem by creating an internal market between itself and the Front Office. The internal market changes its structure to reflect the changing operating divisions. Effectively this works by the internal market maintaining a series of account managers, corresponding to the operating divisions in the Front Office, passing their requirements back to Solutions Managers, who place the orders for systems solutions on the Back Office. The arrangement is very similar to that illustrated in Exhibit 7. The individual projects so generated are of such a size and nature that the steps 2 to 5 in the operations process tend to be undertaken by specialist surgical teams.
Programs of Development
A variation of this approach used by many organizations for their internal development work is to recognize the projects can be grouped into development programs. A program manager is assigned to coordinate the projects, while a promoter or champion takes responsibility of dealing with the many internal customers who will use the development product and feeds their requirement into the project teams through the program manager. The program takes on the nature of a large project.
This approach tends to be adopted by firms of consultants doing work for external customers. There are solutions managers working with customers, and drawing on central resource pools to create teams of consultants to work for the clients. However, we interviewed one consultancy in the Netherlands that had grown so successfully that the application of this approach was leading to a growing feeling of isolation of the consultants, from their resource leaders and from their clients. They solved the problem by changing their organization. They have created multidisciplinary teams doing work for categories of clients. These strategic business units may service:
• A dominant client
• A geographic region
• An industry
• A collection of similar clients.
Effectively they have created several suborganizations, each a project-based organization. Some do large projects for large clients, some small projects for large clients, and some small projects for small clients. In this structure, an individual's career development and assignment to work is managed by the strategic business unit they work for. Their competence development is managed by the functional group they are assigned to. The functional groups also develop new products for the strategic business units. So they too are project-based organizations servicing internal clients.
The Need for Different Approaches
The need to have different approaches for these different scenarios is recognized by some organizations and not by others.
(a) We interviewed one organization in the Netherlands from the Engineering Construction Industry, an organization undertaking large projects for a few customers, with an American parent from the Defense Electronics Industry, an organization undertaking many projects from one client. The American parent tried to manage the subsidiary in the close way required by their industry, rather than the empowering way required by the Engineering Construction Industry, creating serious tensions.
(b) On the other hand, this contrasts with ABB, a European based firm with high project orientation. They recognize that not only do projects from the construction industry require an isomorphic structure to reflect the nature of the task, but also the culture of the different divisions needs to reflect the culture different businesses they operate in, and the customers within those businesses.
Project-based organizations undertaking unique, novel and transient work to deliver bespoke products or services to their customers, require a different approach to their management than the functional, hierarchical, line management approach that has been successfully adopted by organizations with stable products and technologies. The functional organization can adopt an internally focused, discrete approach with:
• Well-defined job roles designed to meet the internal needs of the organization
• Stable command and control structures
• A focus on increasing efficiency.
The project-based organization needs to adopt versatile, customer-focused processes to do the work required to meet the customers’ bespoke requirements. We have observed that, within these constraints, project-based organizations adopt different strategies for their management approach, dependent upon the size and number of projects undertaken and the size and number of clients they service. They also adopt different tactical approaches, particularly the type of team structures used, for different stages in the project life cycle:
1. Organizations undertaking a few large projects tend to adopt traditional project management approaches, whereas organizations undertaking many smaller projects tend to group the projects into larger programs of work and adopt emergent program management techniques. Because the large projects truly are transient, bespoke command and control structures are adopted project by project. It is also appropriate to adopt isomorphic team structures appropriate to the stage of the project. Organizations undertaking programs of small projects find the programs are more continuous in their existence, and so they can adopt more stable command and control structures. They tend to use specialist, surgical teams, to deliver the individual projects.
2. Organizations with a few customers tend to have a one-to-one relationship between the projects or programs and their customers. This becomes inappropriate where there are many customers, because the number of interfaces is the product of the number of customers and number of projects or programs. To avoid this, organizations create an “internal market,” so the projects or programs supply the internal market, and that supplies the customers. This reduces the number of interfaces to the sum of the number of customers and the number of projects or programs. We speculate that some form of transactional analysis (economy of transaction and organization), would determine when it was appropriate to make the switch from one-to-one relationships to the internal market.
3. Organizations undertaking many projects for many customers tend to operate this internal market in many ways, depending on whether the size of project or number of customers dominates:
• The virtual factory adopts the isomorphic structures of the firms (in a versatile network) undertaking a few large projects for a few dominant customers, but using the broker rather than the project manager to manage the interface with the client.
• Companies undertaking many related internal development projects to be used by many internal departments, create large programs working for those many customers, with a program director managing the program and a promoter (champion) managing the interface with the many users.
• One company undertaking many less related development projects, created an internal market so that the projects had just one customer to work for. They deliver the product to that customer, and the customer passes it on to the Front Office.
• Matrix management tries to design a solution specific to this scenario, but when the operation becomes large, the need to maintain customer focus means that individual project teams need to be limited to doing a few projects for a few customers.
Finally, one consistent message coming from the firms we have studied and projects we have observed is organizations need to recognize differing approaches and when they are appropriate. They should adopt different approaches for different businesses within a larger group, and not try to adopt a one size fits all approach.
Burns, T., & Stalker, G. (1961). The management of innovation. London: Tavistock.
Central Computer and Telecommunications and Agency. (1996). PRINCE 2: Project management for business. London: The Stationery Office.
Fayol, Henri. (1949). General and industrial management. London: Pitman.
Frame, J. Davidson. (1995). Managing projects in organizations, revised edition. San Francisco: Jossey-Bass.
ISO 10,006. (1996). Quality management: Guidelines to quality in project management. Geneva: International Standards Organization.
Hastings, Colin. (1993). The new organization. London: McGraw-Hill.
Huczynski, Andrzej A. (1996). Management gurus: what makes them and how to become one. London: International Thomson Business Press.
Katzy, Bernhard R., & Schuh, G. (1998). The virtual enterprise. Handbook of Life-cycle Engineering: Concepts, Tools and Techniques. AM Gutierrez, JM Sanchez & A Kusiak (eds).
Keegan, Anne, Turner, J. Rodney, & Paauwe, Jaap. (1999). People management in project-based organizations. RIBES Working Paper Series (in production). Rotterdam, NL: Rotterdam Institute of Business Economic Studies, Erasmus University Rotterdam.
Mintzberg, Henry. (1979). The structuring of organizations. Englewood Cliffs, NJ: Prentice Hall.
Morgan, Gareth. (1997). Images of organization, 2nd edition. Thousand Oaks, CA: Sage Publications.
Peters, Thomas J. (1992). Liberation management. New York: Fawcett Columbine.
Smith, Adam. (1776). The wealth of nations. London: Stratton and Cadell.
Taylor, Frederick W. (1913). The principles of scientific management. New York: Harper & Row.
Turner, J. Rodney. (1999). The handbook of project-based management, 2nd edition. London: McGraw-Hill.
Turner, J. Rodney, & Keegan, Anne. (1999). The versatile project-based organization: Governance and operational control. The European Management Journal. 17 (3), 296–309.
Turner, J. Rodney, & Peymai, Reza. (1995). Process management: The versatile approach to achieving quality in project-based organizations. Journal of General Management. 21 (1), 47–61.
Urwick, L. 1943. The Elements of Administration. New York: Harper and Row.
Weber, Max. (1947). The theory of social and economic organization. Oxford: Oxford University Press.
Proceedings of PMI Research Conference 2000
An essential tool for project planning, a work breakdown structure organizes a project’s total scope to help practitioners track projects across disciplines and project life cycles.