This is a continuation of the previous chapter, which explained some organisational principles and also described some of the advantages and disadvantages of organising projects as teams. Generally speaking, the alternative to using a team organisation is to adopt a matrix configuration. Just as a team has its advantages and disadvantages, so does a matrix. A matrix can exist in various forms, and the most common forms of these are discussed in this chapter. Also described here is a task force organisation arrangement that can be effective in management change projects (projects that are conducted within companies and other organisations that have no inbuilt project management experience, and which are intended to bring benefits to those companies through changes in the company structure or its operating systems and procedures).
Characteristics of Matrix Organisations
Functional matrix organisations were introduced in Chapter 9. A simple example for a single project in a manufacturing company was shown in Figure 9.4. That form of the matrix is sometimes called a coordinated matrix (for the obvious reason that it includes a project coordinator). It can be regarded as a temporary matrix because, when the single project has been finished, the coordinator will either leave the organisation or return to other duties and the company will continue with its routine non-project operations.
A coordinated matrix is recognised as a weak matrix, because the power of the project coordinator or manager is weak when compared with that of the functional managers. The project is not given any special priority in the organisation, at least as far as support from the organisational structure is concerned.
A more permanent form of matrix can be established when a company carries out several projects at the same time, and expects to continue to do so. An example of this, again for a manufacturing company, can be seen in Figure 10.1.
Another example of a matrix organisation for handling several concurrent projects is shown in Figure 10.2, but this one is for a company that routinely carries out construction or mining, quarrying and petrochemical projects. Although apparently complex, the example in Figure 10.2 is based on an actual case.
Figure 10.2 Matrix organisation for mining, petrochemical or construction projects
Note: This chart is based on an actual company organization that carried out several large simultaneous projects. It is far from ideal. There are many dual lines of command, so that a person in a functional group might have to take instruction from both their own departmental manager and a project manager. Note that general company services lie outside the projects matrix, which is customary.
Most of the discussion that follows in this section is relevant to matrix organisations for projects in any industry.
Applying Two Rules of Organisation Theory to a Typical Matrix Structure
Project Manager’s Span of Control
As with the team organisation discussed and illustrated in Chapter 9, the project manager in a matrix will usually have a wide span of control, spread over several specialist functions. Thus the project manager will need as much support as possible with routine project planning, progressing, contract administration and report preparation.
A project support office (PSO), although placing yet another manager within the span of control, will usually provide that support and relieve the project coordinator or manager of routine tasks that would otherwise dilute his or her ability to manage across the wide span. It can be assumed, therefore, that the organisations depicted in Figures 10.1 and 10.2 would have a PSO, or at least some supporting staff occupying staff roles to assist the project manager with planning, progressing and contract administration.
So when a matrix organisation is compared with the alternative of a team organisation for the same project, neither will have an advantage over the other as far as reducing the span of control is concerned.
The Rule of Unity of Command
A team organisation supports the rule of unity of command. Every senior functional manager reports directly to the project manager and no person in the organisation is expected to serve two masters.
Most matrix arrangements have exactly the opposite characteristic. Indeed, in a typical matrix, the rule of unity of command is not simply ignored – a metaphorical chainsaw slices and shreds it into unrecognisable fragments. Whereas in the team everyone should know to whom they report and can expect to receive clear day-to-day instructions and guidance, in a matrix many people will find themselves being responsible both to the project manager and to their functional manager. Therein lies a strong factor for producing damaging resentment and conflict, especially if the different managers cannot agree. Methods for overcoming these problems are outlined below.
Stability and Longevity of a Matrix Organisation Compared with a Project Team
A typical project team organisation will change in size as the project moves through its life cycle, so that before the project begins no team will exist, and the team will disperse and vanish when all the work is done. That, as explained in the previous chapter, can be a powerful demotivator that can outweigh other motivational factors associated with teams (such the promotion of a team spirit). However, another demotivator occurs when people are moved too frequently between different projects or are left idle (sitting on the bench to use a sporting analogy) and those risks can be higher with matrix organisations.
A company using several project teams can expect its organisation to be disrupted and changed as its various projects progress from beginning to end. People will have to be moved between team-based functions from time to time and the organisation will always be liable to change. If a project is postponed or cancelled, the effect can be devastating. People in general do not like change, especially when they experience disruption to their careers and working environments.
A company with a matrix organisation can overcome these difficulties to a large extent because the life of the matrix is identified with the life of the company, and not with the life of any individual project. Thus a matrix organisation is more stable than a collection of separate project teams. That is a strong reason why companies eschew the apparent simplicity and simple lines of command of team organisations and choose instead to live with the more complex command structures in the matrix. The matrix tends to act like a giant friendly sponge that can soak up new projects and squeeze out the finished or cancelled ones without changing its permanent shape.
A General Note for Senior Managers Responsible for Their Company Organisation Structure
One way to reflect on how an organisation structure can motivate or disrupt an individual is to imagine yourself as a person working deep inside that organisation. I recommend that any manager who is faced with strategic decisions to establish or change an organisation should take time out to do this.
So, how would a typical matrix look from the point of view of an individual working within one of its specialist functions? This might be a quite junior person, perhaps being responsible for small design tasks. But remember that the success of each project will depend to a large extent on the collective performance and motivation of all such people. I shall call this imaginary person Jo, which might be short for Joseph or Josephine.
So Jo will arrive at work every morning to carry on with the assigned task, or to accept a new task. When that task is done, a new task will replace it – not necessarily on the same project because this is a multiproject matrix organisation. As time proceeds Jo will gain experience in the chosen technical discipline. Jo’s immediate colleagues will all be skilled in the same discipline and they will probably also become Jo’s companions.
The manager of Jo’s group or department will have attained that position through specialisation in the department’s discipline and through several years’ experience. Jo can go to that manager for help and technical advice whenever the task in hand proves difficult. The group remains in place from one project to the next, accumulating expertise and learning from past mistakes as time passes.
Performance assessments and salary reviews are likely to be fair, because in this stable functional group the manager knows the strengths and weaknesses of all the group members. In the longer term Jo can expect promotion within the group in line with performance and experience gained.
But Jo might experience difficulties when told to do one thing by the functional manager but is asked to do something else by the project manager. What now should this person do? To obey one manager would mean disobeying the other. So, over time, methods have been developed for adapting matrix organisations to avoid or resolve such conflicts.
Resolving Conflicting Commands in Matrix Organisations
Where commands to a subordinate originate from two different managers, and the principle of unity of command is violated, the risk of conflict can be averted if both managers always issue identical commands. Or, alternatively, those managers might be able to avoid disputes by adopting some friendly compromise, or perhaps one manager might be able to concede gracefully and allow the other manager’s will to prevail. But these are often only pipe dreams and more positive steps are usually necessary to prevent or at least discourage conflict.
Pre-Empting Power Disputes by Issuing Project Management Procedures
The usual way of restoring harmony in a matrix where conflict exists (although not always banishing resentment) is for senior management to arbitrate or rule to resolve disputes. Resolution of possible disputes can be pre-empted by announcing in advance which managers shall have the most power – the project managers or the functional managers. In other words, if the project and functional managers cannot agree, senior management can specify whose will should prevail.
We saw that in a coordinated matrix it was the functional managers who had the most power, because the coordinator (even if given the title of project manager) occupied a staff position and could only recommend actions and had no authority to issue commands to anyone.
Unfortunately, one weakness of organisation diagrams is that they cannot usually show which managers in a matrix have the most power and authority. So the diagrams in Figures 10.1 and 10.2 could apply equally well to any of the forms of matrix that will be described in the following sections. These difficulties can be reduced by putting relevant statements in project procedures or company procedures, or by including suitable clauses in manager’s job specifications.
For example a functional manager’s job specification might state that he or she has absolute responsibility for the technical content of the work in that department, whilst having to work within the timeframe and cost budgets set by the project manager. Of course job specifications are not usually worded in that way. A more practical general format is to have sections near the top of the job specification form under the separate headings ‘Responsible to’ and ‘Responsible for’.
Matrix Organisations with Different Strengths
By convention, and also for the purposes of this chapter, a matrix is said to be strong when the project manager has supreme power. By contrast it is weak when the project manager’s authority is limited to that of a coordinator. The most common variants of a matrix organisation will now be described. Remember that, owing to the deficiencies of organisation charts, both Figures 10.1 and 10.2 can be used to represent any of the following matrix forms.
A weak matrix is another name for a coordinated matrix. The project coordinator or project manager can only advise the functional managers of their project duties. Any failure by a functional manager to meet the demands of the project as requested by the coordinator will have to be resolved by another manager at a more senior level.
In a balanced matrix the project manager and the functional managers share power and authority on a more or less equal basis. On technical issues, the functional managers could usually claim the higher authority by virtue of their specialisation and professional experience, but difficulties can arise when determining which job or which project should be given priority within each functional group.
As with a weak matrix, the successful operation of a balanced matrix depends on the goodwill and cooperation of all its managers.
Project managers in a strong matrix are given greater power than the functional managers. When disputes arise, the will of the project manager must prevail. However, it would be a very unwise project manager who attempted to overrule a functional manager on a technical issue where the functional manager has the more appropriate professional qualifications and experience to make a decision on that issue. So the project manager’s power is more likely to be concentrated on work priorities, completion targets and budgets. Thus a strong matrix provides a possible solution for resolving disputes between project managers and functional managers.
There still remains the possibility, however, of conflict between different project managers within the matrix. This will happen particularly when two or more project managers disagree with each other about which of their projects has the greatest priority for using scarce resources from the functional departments. The most effective remedy for preventing this is to have a good multiproject resource scheduling system in place, operated by a project (or programme) support office. The scheduled dates in such systems must be driven by priorities measured in task float or slack, which are in turn driven by required project completion dates. That way, the allocation of resources between different tasks and different projects should be fair and not subject to personal opinions of the different project managers.
A secondment matrix moves the balance of power so far towards the project manager that it approximates to a project team. Each functional manager will be expected to name individuals within their departments who can be assigned to the project manager for the duration of the relevant project, as and when the project manager decides they are needed. These individuals might remain located in their usual places of work but in the very strongest form of a secondment matrix they could be asked to move temporarily into an area controlled by the project manager.
Project managers are able to use the resources placed under their immediate control to work to priorities that they decide. There is reduced possibility of conflict with other project managers about task priorities because all the project managers have their resources allocated specifically to them and are thus responsible directly for allocating day-to-day tasks according to the schedule requirements.
People in a secondment matrix still have an important direct reporting link back to their functional managers for such matters as seeking help with difficult technical problems or for ensuring adherence to design standards and codes of practice relevant to each technical discipline. Each person can still expect to be given training opportunities and equitable performance reviews from the functional manager of their ‘home’ group.
A secondment matrix arrangement can be chosen, for example, when one or two projects claim very special high priority owing to their potential benefits or their prestige. Other projects in the same company would then remain as projects within some more balanced or weaker form of a matrix, and that would allow the organisation to continue to experience many of the advantages of a matrix.
Sometimes companies adopt the solution of a hybrid organisation, in which most projects are managed across a common matrix organisation, but with self-contained teams set up for certain projects when the need arises. These teams can be enclosed within the matrix. An example of a hybrid organisation is shown in Figure 10.3 on the next page, which, like other examples in this chapter is based on an actual case. This was an international mining company and the organisation also included internal specialist advisory groups (not shown in this chart) for geology, mining, metallurgy and mineral processing.
This company successfully operated a balanced matrix for almost all of its projects. However, at the time when this organisation chart was drawn, one client required the upgrading and replacement of a large electrical transformer at a copper refinery. Because most of the design of this relatively small project concerned electrical engineers, a self-contained project team was set up within the electrical engineering department. An engineer from that department became the project manager.
The same company once had to deal with a project to pump out and drain underground workings at a client’s mine that had (many years before) been flooded with slurry in a tragic accident caused by the collapse of a tailings dam on the surface. When the causes for this collapse had been investigated and dealt with, the piping and fluids department became responsible for the reclamation project. A project team was set up inside that department, because most of the project was concerned with pumping and drainage operations and required specialist knowledge of the behaviour of the fluids involved.
Suppose that another client of this engineering company had required the construction of a tunnel or a bridge to connect two processing plants that were separated by a busy main road or railway line.
That project could most conveniently be handled entirely by a team set up within the civil and structural engineering department.
Figure 10.3 A hybrid organisation
Note: This international mining company is organised as a matrix. However, a team will be set up within the relevant department for any project that is confined to a specialist function. For example, project Y is confined to a pumping and drainage project and project Z is for the replacement of a large electrical transformer.
This was a very complex hybrid organisation, mostly operated as a matrix, but it worked well largely owing to the dedication and enthusiasm of the staff, which in turn was promoted by a company policy that respected all its staff, right down to the most junior levels, and provided generous perquisites. The founder of this company was once heard to say ‘If people are prepared to make their long journeys into this city to give their time, the least we can do is treat them properly’.
Organisation of Management Change Projects
This section considers projects intended to change a company or its working procedures. Examples of such projects include a company relocation project, a new or changed IT system, an internal reorganisation or a company merger or acquisition. Changes such as these often occur in companies that run routine operations and have no inbuilt experience of managing projects. An insurance services provider has been chosen for the example in this chapter.
An important feature of management change projects is the great influence they can have on staff whose working lives will be affected in one way or another when the change is implemented. That influence is often demotivating and disruptive, because people in general do not like change. They like it even less when they first hear about a proposed change through information leaks. Those leaks sometimes distort management’s intentions and can be founded on fear or prejudice rather than fact.
In the wider world of commerce, confidentiality about some changes has to be maintained for proprietary or market reasons. That would apply, for instance, in the case of proposed mergers and acquisitions. Premature leakage of information or the leakage of incorrect information can damage a company’s reputation or affect dealings in its shares.
The management of information through all life cycle phases of a management change project is important. Confidentiality is usually very important when any management or internal system change is being considered, which means when the proposed project is in the early phases of its life cycle. The way in which those engaged in the project are organised can either help or hinder efforts to keep a tight hold on information management. Undoubtedly the best way to ensure confidentiality, particularly during the early project phases, is to put all those planning the project into a self-contained and secure unit. That inevitably points to the desirability of establishing a project team or task force.
Establishing a Team for a Management Change Project
External consultants are often engaged to advise companies on change projects. Those consultants might be employed on an advisory basis, or they might be given a more substantive role in planning the details of the change and managing the resulting change project. However, no management change project should be planned without investigating the existing company organisation and its operations and performance. That inevitably involves cooperation from some staff working in the organisation. Therein lies a possible source of undesirable information leaks.
Figure 10.4 shows the simplified organisation chart of a company that is about to conduct an internal management change project. Let’s suppose that this company has chosen to replace its ageing IT system.
The functions shown indicate that this is a fairly small insurance services provider. It is self-contained and there are no external call centres. The company is very experienced and successful in its field of insurance. However, there is no inbuilt capability for managing a project. Fortunately, the company’s managing director is aware of that deficiency. Accordingly an external consultant has been engaged to advise on the planning and conduct of the project and to give advice and direction to the member of the company’s staff chosen to manage the project.
The IT manager will be well aware of the need to manage the changeover to the new system in a way that will not interrupt the company’s day-to-day operations. That, for instance, will inevitably mean running the new system alongside the old for a proving period. This IT manager will play a crucial role, and will probably be chosen as the project manager.
The intentions of the managing director and other senior managers towards the project have to be safeguarded, and a steering committee has been formed for that purpose. Some or all of the departmental managers will serve on that committee, which will meet occasionally to keep an overall eye on the project’s direction of travel, particularly with regard to its technical specification, budget and time schedule. The project manager cannot act in isolation, but must consult the managers of the various functional departments from time to time to ensure that their operations will be supported in all respects by the new IT system. So those managers will be seconded to the project task force as and when required or, more probably, they will send suitable delegates from their departments. However, Fowler and Lock (2006) recommend that only experts should take part in implementing management change projects, and that junior staff and trainees should learn their craft and gain their experience elsewhere, where they will not be able to cause harm to the project through their lack of expertise.
If a management change project should fail for any reason, the results not only deprive the company of the intended benefits. They can make the implementation of future change projects far more difficult because of the apathy, resentment or downright hostility caused to people who tried and failed to work within the changed procedures or organisation imposed upon them. Management change projects fall squarely within the ‘must get it right first time’ category. Thus, during the implementation stage of a management change project it is important to ensure that the change will be accepted by staff. Failure will mean that the expected benefits will not all be realised. That aspect of management change projects is discussed more fully in Chapter 49.
Contract Matrix Organisations
On very large projects, including those for big construction undertakings, petrochemical and mining, the project organisation can be complex because of the large number of suppliers, subcontractors and other service providers involved.
Project owners and investors will often appoint a specialist organisation to oversee or assist with the management of their project. This might be a main contractor or, in the extreme case a managing contractor that can assume all responsibility for carrying out the project. Thus this main contractor would have the authority to hire subcontractors, purchase equipment and materials, generally supervise all the work and might also carry out detailed design. A managing contractor will employ people in its own offices to carry out supervisory tasks and manage the project, so it will have its own internal organisation as well as having to manage across the contract matrix (as this kind of organisation is sometimes called). The project owner might have its own project manager who will cooperate with a project manager employed by the main contractor. A representation of a contract matrix is shown in Figure 10.5.
The work to be performed by the suppliers of major items of equipment and some of the large subcontractors can be regarded as projects in themselves. So each of those suppliers and subcontractors will have an internal project organisation, and each of those project organisations will have its own project manager.
So in a contract matrix there can be a plethora of project managers. But the project manager with principal responsibility for successful project conclusion, and with the most authority, will usually be the one that resides in the main contractor’s home office.
The funding of such large projects can become a very important factor, and one or more financial institutions (we can call those ‘the bank’ for simplicity) might be asked to lend or invest funds to support the project cash flow during the period before the project is completed and begins to repay its investment. But banks and other financial institutions will not usually have any people on their own staff with the expertise in the technology of the project, so they must take professional advice. That advice is often provided by a professional person or an engineering organisation that is independent of both the project owner and the main contractor. This engineering adviser is often called simply the engineer, and will usually be named in the financial contract.
The guarantor shown in Figure 10.5 is there in this example to protect the interests of the bank. For example if an overseas client should default on payments for any reason. Organisations such as the Exports Credits Guarantee Department (ECGD) in the UK or the Export-Import Bank (Ex-IM in the US) often act as guarantors in such cases.
These roles are all indicated in Figure 10.5 although, of course, with such complex and large projects there are many variations and no exact standard model.
In a contract matrix communications between people are very important. One important recommendation is that the managing contractor should publish a project manual. That, in addition to recommending or instructing the general project control procedures to be used, should include a skeleton organisation chart covering the principal players in the matrix. In particular one person or point of contact should be agreed for each suborganisation and main organisation in the matrix. Of course in a very large project there might need to be two or more designated points of contact within the same organisation, according to the aspects of the project that each is authorised to cover within the head contract and the subcontracts. A directory of these names should be distributed, preferably by including it in the project manual. Communications in the complex organisation of a project matrix can get confused and it is important to establish these points of contact and make sure that everyone who needs to communicate is aware of them.
More Complex Organisation Forms
This chapter and Chapter 9 outlined some organisational principles and have described some forms of project organisations. Chapter 11 continues with this theme, but deals with the even more complex issues of multicompany and international projects.