Appendix D: Organizing

D.1. Tool Sheet: Arranging the Project Organization

What

Opens in a new window.

Arranging the project organization encompasses planning the organizational structure and roles, staffing, and arranging communication and cooperation with neighboring organizations.

Use – Where and When

The project organization is arranged at the beginning of the project and is adjusted at the beginning of new phases. The core organization should ensure continuity in leadership.

Method

Arranging the project organization encompasses these elements:

• The main organizational structure – especially management structure

• Definition of roles, responsibility, and authority

• Work team structure

• Mechanisms for inwards cooperation, coordination, and communication (see tool sheet E.2)

• Mechanisms for outwards cooperation, coordination, and communication (see tool sheet D.3)

We suggest the following approach, which consists of seven steps, although the approach is iterative.

1. Analyze the situation

   The basis for arranging the organization is clarification and analysis of the project task and its structure, the challenges and uncertainties (see “the project portrait”), work paths and phases, and their activities. Also, the analysis of the interested parties, telling about suitable involvement, available resources, management structure in the participating companies (organizations), and their management culture.

2. Guiding principles

   It is useful to begin considering potential organizational structures and formulating guiding principles for handling organizational issues, for example:

   • Connection to the surrounding organizations – especially in terms of ownership, co-responsibility, and management authority

   • Project management – position and authority

   • Adaptation to new phases

   • Degree of formality – mechanistic versus organic; contract-based versus partnership-based; deliveries versus integrated work

   • Development of cooperation and culture

3. Immediate ideas

   At this stage, it is useful to illustrate some immediate ideas. They may be intuitive and come from experience concerning three elements – as described in Chapter 4 and Figure D1:

   • Decision part – authority and drive to make major decisions

   • Management part – daily management

   • Work part

4. Views on the project organization

   The next step includes more detailed consideration and arrangement for each phase, elaborating on the four views in Figure D1.

   • Technical/professional contribution: Technical contribution and technical insight necessary in each of the above-mentioned three elements? The work paths of the systems/product development process and the change process are the basis for identifying necessary competencies. See Figure D2.

   • Management contribution: Management elements and authority necessary in the above-mentioned three elements? Finding a competent project manager and a core team. Co-management from managers. Competent team leaders of work teams, reference groups, and anchoring groups, etc.

   • Anchoring: How should the project be anchored in the project owner’s organization, in other parties’ top management, and in the user organization? How to ensure decision power for the project owner or responsible manager. Ensure decisions anchored in project owner’s management team or in a steering committee. How to activate change agents and managers? Identify opinion makers.

   • Influence: How should interested parties influence the project and be involved? Use the analysis of interested parties for organizing and staging the involvement.

   These questions will generate ideas for how to arrange the three elements. The picture of the necessary competencies will lead to identification of staff. See tool sheet D.2.

5. Evaluation of the proposed organizations

   The alternative organizations may be evaluated from different angles. They may be compared to the principles. The push and pull forces introduced in Section 3.3 and the need for anchoring may be considered. You should consider the development of the organization during the project process and adaptation to the character of each phase.

6. Detailed planning of roles and cooperation

   The roles of the actors in the three elements may be described in a responsibility chart – which might also form the basis for a meeting structure, decision processes, and information procedures. The work form in the project core team and work teams is discussed. Communication with interested parties is considered.

7. Mobilizing the organization

   This step deals with allocating persons and making agreements on effort and time, in addition to introduction and team building activities. This step is handled in parallel with the preceding steps.

Organigram

The organigram illustrates the formal lines of responsibility, accountability, and authority – but not all communication lines in the project organization. In larger project organizations, additional contact symbols may be useful – see Figure D3.

Opens in a new window.

Figure D1.

Basic Pattern of the Project Organization.

Opens in a new window.

Figure D2.

The Project Team Structure Is Related to the Work Paths.

Opens in a new window.

Figure D3.

Organogram with Contact Lines.

Responsibility Charts

Charts showing distribution of tasks and responsibilities are more differentiated illustrations of the complex project organization. The task distribution chart shows who participates in each main activity and who has which role. It should be included in the coordination and control schedule. The responsibility chart shows who is responsible for elements of the project – subprojects, systems, technologies, management and control functions, external relationships, etc.

The charts illustrate the distribution of tasks and responsibilities, including suppliers and advisors. They should also illustrate contact with the interested parties. The actors may have one or more of the typical roles:

• Decide – about scope, goals, methods, plans, budget, resources, solutions, etc., and based on propositions.

• Work – proactively on agreed activities.

• Deliver – specified and ordered from project management.

• Advise – the project management, work teams, and the owner as well.

• Monitor and control – quality and observance of rules and standards.

• Evaluate – proposed solutions before decision.

• Be informed – about plans and solutions and progress.

Figure D4 shows an example of a responsibility chart. It should be read horizontally. For each task/activity, it shows who is involved and in which role. Authority and limitation of authority may be described in the responsibility chart with comments.

Opens in a new window.

Figure D4.

Responsibility Chart.

D.2. Tool Sheet: Manning the Project Team

What

This tool sheet presents some checklists for selection of project team members.

Use – Where and When

The checklists can be used in all project phases.

Method

Project results and success are determined by the competencies in the project team and the steering committee – plus other people used in the project process. Consequently, the starting point for manning is a list of necessary competencies, as far as they are visible in the project approach and plan. Next step is to identify potential people for the team and the committee and as ad hoc advisors and assistants. These people will, in turn, be useful helpers in the search for more competencies. The search for and identification of competency is one of the most important activities for the project manager.

A competency chart may be useful – vertically showing the competencies, and horizontally a column for each person (actor). The level of competency is shown in the column, e.g., “has some knowledge,” “has practical experience,” etc. It will identify key persons and disclose lack of important competencies. General competencies required in the project team are:

• Knowledge and experience of

  • –

    the user’s world (operation needs and conditions, operation economy, etc.)

  • –

    new solutions and technologies

  • –

    systems design and engineering, construction and implementation

  • –

    change strategy and leading change in the user’s world

  • –

    project work methodology and project management

• Personal network and relations inwards in the project team and outwards to users and other interested parties.

• Project teamwork behavior.

  • –

    Ensure binding cooperation in the team – feeling responsible for the whole project, not just own activity. Feel responsible for cooperation.

  • –

    Focus on the problem behind the project, the scope and mission, and users.

  • –

    Acquire insight into neighboring areas, new technology, and new solutions. See and understand connections.

  • –

    Discuss methods and approaches, be open and objective to new ideas, accept responsibility for searching for better solutions and not just use own ideas.

  • –

    Discuss quality of the work basis (previous work and documentation, etc.)

  • –

    Communicate and keep contact to colleagues providing information.

  • –

    Conclude, accept considering other interested parties and the whole.

  • –

    Present, propose, promote.

  • –

    Participate in managing the project.

  • –

    Evaluate and learn.

The importance of these competencies changes from phase to phase. In the concept development phase, we need creative and innovative persons capable of seeing the whole, and capable of describing and visualizing future scenarios and of testing ideas. In the construction phase, we need persons who can analyze and work with details, construct and build, and document and test solutions. In the implementation phase, we need persons who can execute, train people, solve problems, and keep things going in spite of troubles.

Besides these competencies, a couple of other factors are important:

• The participant should spend sufficient effort on the project. Too little time has a negative influence on the other participants, because too much time is spent on staying informed – not on being productive.

• The participant should be motivated to work on the project, and work together with the other participants.

• The participant should be objective and loyal to the project as a whole and not promote certain departmental and political interests. The participant might feel a pressure from colleagues and department managers to only deliver statements and contributions that are acceptable in his department, or she/he is instructed to deliver.

• Participation in the project should have a positive influence on the participants’ careers.

The above-mentioned pressure from the basis organization may be relieved by the project team by working together and rallying round. Political reference groups and a steering committee might also relieve the pressure.

Participants from the user organization should have some additional capabilities:

• See and explain the user’s needs and not just personal opinions.

• Evaluate and test solutions and contribute to quality and usability.

• Describe, explain and “sell” the solutions to colleagues.

• Arrange and assist in implementation and running-in.

• Train and supervise colleagues at implementation.

The above-listed competencies stress technical and user circumstances. However, the team must also function with the personal attitudes and behavior of the participants. Belbin (1981) has identified nine roles in a team:

• Plant – creative, imaginative, solves difficult problems

• Specialist – single-minded, dedicated, provides knowledge

• Monitor – Evaluator – sees options, evaluates

• Implementer – disciplined and efficient, turns ideas into practical actions

• Shaper – dynamic, drive, and courage to overcome obstacles

• Completer – Finisher – conscientious, searches out errors and omissions, delivers on time

• Teamworker – perceptive and diplomatic, listens, averts friction

• Coordinator – mature, confident, chairperson, clarifies goals, promotes decision-making

• Resource investigator – extrovert, communicative, explores opportunities, develops contacts

Later Briner, Geddes, and Hastings (1990) have restructured the nine roles into six roles:

• Company worker and implementer – does things

• Chairman and shaper – provides direction

• Plant and resource investigator – provides new ideas and perspectives

• Monitor and evaluator – ensures realism

• Completer and finisher – completes work

• Team worker – keeps the team together

Based on research, Belbin concludes that the roles should be balanced to create a good result. For example, an overweight of shapers will lead to endless discussions about directions, whereas too many company workers will meet difficulties handling open-ended projects with uncertainties and a need for new ideas.

Larsen (2002) has especially studied coordination in teams. People preferring formal coordination mechanisms are important in the team.

The Engagement Interview

Project team members should discuss work conditions with their personal manager and the project manager when they enter the team. The personal manager and the project manager should follow up with regular talks during the project.

The project manager should have an engagement interview with each team member, talking about these subjects:

• Project background, mission, and importance

• Organizational interfaces, interested parties

• Project participants

• Team member’s role and tasks. Reason for being engaged

• Personal outcome from participating

• Challenges, inconveniences, and conditions

• The team member’s professional interest in participating. Expected challenges

• The team member’s view on cooperation

• “Rules of the game” in project management

• Capacity and release from other work

• The situation when the project job finishes

Opens in a new window.

J. Evensmo, a Norwegian management teacher, has six questions to the new team member:

1. CAN you solve this problem satisfactorily? Do you have the necessary skills?

2. Can YOU solve this problem satisfactorily? Will you take on the task personally?

3. Can you SOLVE this problem satisfactorily? Will you solve the problem and not just analyze and discuss?

4. Can you solve THIS problem satisfactorily? Do you understand the problem, or are you thinking of something similar?

5. Can you solve this PROBLEM satisfactorily? Do you agree that the problem is real and important?

6. Can you solve this problem SATISFACTORILY? Will and can you find a valuable and acceptable solution?

References

• Belbin, R. M. (1981). Management Teams – Why they succeed or fail. Butterworth-Heinemann.

• Briner, W., Geddes, M. & Hastings, C. (1990). Project Leadership. Gower.

• Larsen, J. H. (2002). Teams: Understanding team performance in terms of coordination policy, coordination quality and team roles. Ph.D. Dissertation. Dept. of Production, Aalborg University.

D.3. Tool Sheet: Interaction with the Company Organization

What

This tool sheet describes some typical models of interaction between the project organization and the parent company organization – including types of matrix organization.

Use – Where and When

Most projects have a parent organization – a company, an institution or a public administration – called the basis organization. The anchoring builds on several circumstances:

• The company is responsible for the project (project owner).

• The project will use competencies and resources from the company.

• The project result is used by the company.

Some examples are new product development, IT systems development, organizational development and development of business processes and facilities.

Some projects are systems delivery to a customer such as process plants and IT systems. The types of interaction between the company and its delivery project may also relate to such projects, to be discussed below.

Method

There are more ways of anchoring a project in the parent organization, as shown in Figure D5. The project team members come from the company departments; sales, engineering, manufacturing, etc. Below is a description of five different ways of organizing, based on Davis and Lawrence (1977) and Youker (1977).

Opens in a new window.

Figure D5.

Two Examples of Interaction.

Traditional Organization with Unambiguous Responsibility Structure

• Only one manager.

• Functional department structure.

• Staff functions have no line authority.

• Committees may analyze and propose – but not decide.

• Projects belong to departments

Temporary Authority Overlap

• The company organization is supplemented by ad hoc project teams for cross-organizational tasks. Examples: IT systems, organizational changes, process development, new product development.

• Resources are allocated from the basis organization plus consultants.

• Modest experience with project work.

• The project manager needs to gain authority.

• The project work form should be learned.

Permanent Authority Overlap

• Cross-organizational problems/tasks/functions are allocated to special organizational units. Examples: product and account managers, IT department.

• The role of such units is to develop and implement strategies, plans, products/services and methods.

• Many projects at the same time – project work is well-known.

Matrix – Double-sided Authority Relationship

• The organization is arranged for operation and for projects. Examples: Technical process plant projects with projects of different type and technology, see Figure D6. New product development and manufacturing and sales of different product families, see Figure D7.

• Projects are an essential part of company life and professionalism in project management is developed in organizational learning processes.

Opens in a new window.

Figure D6.

Example: Matrix Organization in a Technical Manufacturing Company.

Opens in a new window.

Figure D7.

Example: Matrix Organization in a New Product Development Department.

Project Organization As Separate Department

• Large and complex tasks with long duration are organized as separate projects – a separate organizational unit. Examples: Large turnkey process plant project for a customer. Building a new factory in another country.

• The project has its own resources plus ad hoc assistance from departments.

More types may exist simultaneously in a company. The department for new product development runs more projects in a matrix organization. A program for development of new environment protection or quality assurance standards is handled as a case of permanent authority overlap, whereas a reorganization of the manufacturing department is handled as a case of temporary authority overlap or just within the department.

Comments

When the interaction is about delivery of competencies, know-how and professional resources from the basis organization to the project organization, there should also be feedback. The projects should contribute to learning and professional development in the departments – so-called organizational learning. The projects should expect that the departments develop state-of-the-art know-how and improve their professionalism.

References

• Davis, S. M. & Lawrence, P. R. (1977). Matrix. Addison-Wesley.

• Mikkelsen, H. (ed.) (1982). Organizing Export Projects. Foreningen Projektplan. Teknisk Forlag.

• Youker, R.(1977). Organizational Alternatives for Project Management. Project Management Quarterly (March).