Appendix C: Planning the Course of Action

C.1. Tool Sheet: Planning Model

Opens in a new window.

What

The five-by-five planning model presents 10 steps with considerations for planning a project. The planning has two levels:

• Overall planning – Scoping and forming the project; defining mission and goal and later also product goals; designing approach (phases/steps, work paths, milestones); defining project structure, organization, communication procedures, resources, economy, etc.

• Detailed planning – Monthly/weekly/daily planning and follow-up. Activities, schedule, allocation of people, resource effort, economy control.

Detailed planning is seen as part of project control. This planning model handles overall planning.

Use – Where and When

Overall planning is carried out at the project start and later at the beginning of new phases in the project process – see Figure C1. Among other things, planning is a gradual detailing process. The first version is the project owner’s description of the project and its basis, also called the project charter.

Opens in a new window.

Figure C1.

Planning Points in the Project Process.

The project charter is the basis for organizing the project and for further planning carried out by the project core team and the project manager. The next version of the project plan (an overall plan) is published at the end of the phase of “establishing the project.” This plan is a more detailed description of the project and especially of the project organization and the approach.

This planning process is repeated at the beginning of each following phase (e.g., concept development, engineering, construction, and implementation) or time box. The overall plan is updated to new circumstances and the detailed plan for the phase is prepared.

Method

Planning Process

The planning is based on the five-by-five model and has 10 steps – see Figure C2. They are presented as a natural sequence of steps. However, it is necessary to return to previous steps for supplements and connections. Working with one step creates data for working on other steps. So, planning is an iterative and spiral-shaped process, handling more steps at a time – to achieve a consistent plan and assumptions across the steps.

Opens in a new window.

Opens in a new window.

Figure C2.

Planning Model.

The center of gravity in planning may change during the project. The planning at the beginning of a new phase is not a complete repetition of the overall planning at the beginning of the project. It focuses on the special content of the phase. The overall planning is revised in the light of changes internally and in the project environment. New opportunities may arise, requiring evaluation of attractiveness. New challenges may arise, requiring action, and preparation of readiness. The planning work – overall and for each element – includes:

• Situation analysis and establishment of the basis for planning.

• Limitation of the project work – What is completed/decided and what remains.

• Preparation of the plan.

• Review of the plan – Identification of critical circumstances requiring monitoring and attention.

Planning is typically regarded as deciding on actions, deadlines, roles, responsibilities, etc. However, it is equally important to prepare readiness toward uncertainties: time buffers and budget buffers, flexible solutions and plan B.

In the following, we will describe situation analysis and planning for each step as a general guideline. We use the term “picture” for the result of the analysis. The pictures provide relevant information for planning. For the sake of clarity, we recommend diagrams and other visualization means as supplement to text documentation.

Step 1: Project background and mission

Planning basis, situation analysis

Project owner’s description and other data

What project result is needed? Why should the project be started? To exploit an opportunity and a potential, or to solve a problem, or to fulfill an external requirement?

What is the operations and business purpose? How viable is it? What may change the basis? Which motives do the initiators have?

Who represents the project mission and purpose? What interests do other parties have?

What is the wider project perspective? Are there values reaching beyond the actual goal? Similar projects in the future? Potential qualifications acquired in the project and to be utilized in the future?

The project history until now? What has happened and been done until now? Previous attempts and their fate? Bindings to the past?

Similar initiatives – examples of same type of project? Experiences?

Who has been involved until now? Who are committed to certain decisions and choices?

What is defined, clarified and decided? Where are the opportunities?

Plan elements

Limitation of the project. Scope and content. What should not be included?

A picture of the system – the project and the environment.

Visions related to the project? Ambition for utility values and benefits? Wider perspectives?

Areas of special attention.

References

G.13 Tool sheet: Analysis of problems and needs

G.15 Tool sheet: Utility values and benefits

G.16 Tool sheet: Product/system specification

G.14 Tool sheet: Logical framework

Chapter 3

Comments

A project can begin in different ways: as a problem, an idea (opportunity) or a contract. It may be urgent to get started, but often the project manager should examine the background.

A contract project for a customer is often arranged and agreed by a sales department. It is useful to let the project manager and other key persons in the coming project team participate in concept design and contract formulation (review). If that is not possible, the project manager should examine the contracting process and the project background, talking with the involved sales persons and the customer as well.

An idea is a “positive” proposal – a new product, new technology, new method, new system, etc. The proposal contains a solution, although it may be vague. A problem is a “negative” description of a need, a disadvantage, a deviation from standard, etc. Sometimes, projects are started with a selected solution as goal, or the problem is defined as “we lack this solution.” A pitfall is that the need is not analyzed in-depth or that other attractive solutions are not considered.

Projects may also have a political origin. A new manager may want to manifest himself by starting changes: A new manager has another view on the organization, processes, and systems; a manager may want to demonstrate dynamics and initiative; a stressed manager may try to divert attention by “we are looking into it” initiatives.

That is why it is important to begin with the question “why.” It may lead to two types of answer. One begins with “Because ….” and will express the problem and the need for problem solving. Another begins with “To achieve ….” and will express the required benefit from the project.

When the beginning is a description of problems, you should analyze the causes – that is where solutions should work. Analysis starts with collecting symptoms from all involved parties and by asking them for suspected causes. Each of them may have pieces of an overall picture, and the analysis should lead to a total picture. A workshop with the involved parties might be useful.

Later in the project, the answers will be clearer and the analysis will concentrate on new information.

Step 2: Interested parties around the project and the product

Planning basis, situation analysis

Who are the interested parties, seen from the project? Who will be influenced by the project and the product, and how? Follow the project life cycle and the value chain.

How is the attitude to the project of each interested party? Their motives and expected behavior?

Expectations to the results of the project and to participation and influence? Success criteria and signs of satisfaction?

Coinciding and colliding interests, seen from the project?

Position and significance of each party? Mutual relations and attitudes?

Need for influencing the parties?

Need for contribution from the parties?

Uncertainties related to the parties?

Plan elements

Utility values for each interested party – benefits, success criteria, and measurement of success.

Picture of coinciding and colliding interests. Picture of mutual relations.

Principles for involvement of the interested parties. Plan for participation and influence – both ways. Agreements.

Principles for managing expectations. Plan for handling conflicts and coalitions.

Plan for development of understanding, knowledge and insight, and acceptance.

Points of special attention.

References

• B.2 Tool sheet: Analysis of interested parties

• G.14 Tool sheet: Logical framework

Comments

The analysis of the interested parties is important, because it contributes to the project scope and the approach – see Figure C3. It is the basis for:

• formulation of mission, product requirements, and success criteria

• arrangement of approach (tactics) – especially seen as a decision-making process and involvement of the parties

• planning influencing activities toward the parties – information and hearing

• arrangement of involvement – influence and contribution

Opens in a new window.

Figure C3.

Purpose of the Picture of Interested Parties.

Step 3: Project and product environment

Planning basis, situation analysis

How will the project contribute to realizing the company strategy? How sensitive is it to strategy changes? How may this project change the strategy?

Connections/relations to environmental systems?

Relations to other projects?

Which external conditions may influence the project? (Business fluctuation, market, politics, technological development, trends, and uncertainties). What is known and what is opaque and uncertain? Possibility of influencing conditions?

Requirements from norms and standards?

Data about physical milieu and work environment – conditions?

Compatibility with existing systems?

Plan elements

Relations to strategy.

Relations to other projects – point of coordination.

Relations to operations processes and systems.

Principles for handling external changes.

Information about milieu.

Profile of uncertainties, complexity, and points of special attention.

Plan for monitoring external conditions.

References

• B.5 Tool sheet: Analysis of uncertainty and risk

• G.16 Tool sheet: Product/system specification

• Chapter 3

Comments

The picture of the project environment is the basis for identifying necessary actions toward the environment – also called “the environment plan.” The interfaces should be analyzed and the project borders (scope) may be moved to ensure a good overall solution. The notion of being responsible for a project often means to define the project limits. Often, it is better to focus on the core of the project content – to identify and to take care of interfaces and connections, thereby to ensure the successful result.

The picture of the environment is drawn for each of the elements in that part of the five-by-five model. Do not forget relations to other projects. A similar picture of the product environment should be drawn as well. The pictures should be updated during the project process.

Use graphical illustrations: relationship diagrams and influence diagrams as shown in Figure C4. Mark interfaces and connections and describe them.

Opens in a new window.

Figure C4.

Pictures of the Project Environment.

Step 4: Forming the project

Planning basis and situation analysis

What is the project mission – why this project?

Visions of the interested parties?

What is the project scope? The content and the limits? Degrees of freedom?

The character of the project task – complexity, challenges, uncertainties?

Is there a holistic view of the value chain for the project product?

Expectations for the project result (product), expressed formally and informally. Requirements and ideas for functions and features?

Resources and competency – possibilities and limitations?

Deadlines?

Budget?

Plan elements

Mission and basic idea. Utility values, benefit goals, and primary product goals (distinctive character and positioning features).

The project task – complexity, new unknown or untried elements, human aspects.

Clarified versus unclarified circumstances.

Robustness and degrees of freedom.

Project structure.

Points of special attention.

References

• B.1 Tool sheet: Project challenges

• B.3 Tool sheet: Project goal

• C.3 Tool sheet: Project structure

• G.13 Tool sheet: Analysis of problem and needs

• G.14 Tool sheet: Logical framework

• Chapter 3

Comments

Forming the project means to clarify the mission and utility values, and to arrange “the whole project” including all elements necessary to fulfill the mission. Important pictures are the special requirements and opportunities, interested parties’ expectations and the scope. An illustration of the systems development task and the organizational change task is also important.

Limitation of the project has two aspects: What is included and what does not belong? What is our task and what is to be handled by somebody else? What is decided and defined and what remains to be done?

For some people, the general idea is to define, delimit and narrow in on the task. Often, it is wiser to have an open, broad task from the beginning to ensure a holistic and thorough solution. On the other hand, the task should match the available effort and resources. Time limits may also influence the size of the task. The whole project is important. Unsuccessful projects are often due to missing and neglected elements. A few examples: It is not useful to install a surface treatment facility without environmental protection facilities. It is not useful to implement a new IT system without sufficient training of users. Limitation, therefore, implies identification of the products, work processes and systems to be included and the level of ambition. Use the PPSOP model and the project value chain.

Defining limitations may be seen as an interplay between, on the one hand, to go to the limit of possibilities and, on the other hand, to narrow in, i.e., to “open” and to “close” the system in view. In the concept development phase, you might illustrate “the total and ideal solution” and then afterwards modify it into a more realistic solution and step-wise implementation. An important issue is the choice of realistic solutions and the implementation steps – will they shut off increased ambitions and better opportunities later? Decisions during the project should be accompanied by information about closed and open opportunities.

Complexity, lack of visibility, and uncertainty define the conditions for planning. Visibility makes it possible to structure the project and to prepare detailed plans. Lack of visibility suggests a step-wise approach. Uncertainty means rough planning with flexibility and buffer.

The principle is to arrange for maneuverability. Use the project portrait and the pictures of complexity and challenges.

Step 5: Approach and plan

Planning basis, situation analysis

Project scope and structure?

Unclarified elements and conditions?

Externally defined deadlines for approvals and deliveries?

Required involvement from interested parties?

Challenges and uncertainties?

Possible approaches (models, examples)?

Limits for resource consumption and costs?

Plan elements

Project structure. Work paths and their structure.

Overall approach – using the data from the portrait.

Major decisions – sequence and priority. Management of interested parties.

Actions for clarification of major issues, and handling of uncertainty. Preparedness and degree of freedom.

Project plan – coordination and control schedule. Work paths, milestones, main activities, and deliveries.

Main schedule.

Points of special attention.

References

• B.1 Tool sheet: Project challenges

• C.3 Tool sheet: Project structure

• C.4 Tool sheet: Project course-of-action models

• C.5 Tool sheet: Change process

• C.6 Tool sheet: Coordination and control schedule

• G.1 Tool sheet: About scheduling

• G.2 Tool sheet: About scheduling

• Chapter 3

Comments

The approach should be considered for the systems development task and for the organizational change task as well. There are professional methods for both tasks.

A hint is to carefully consider an idealized process for each of the four aspects in the project portrait – the technical, the organizational, the entrepreneurial and the political aspect. For example: Which main activities will produce technical results and which decision points are included in the work path; which approach will motivate the users to see the need for renewal, to participate in development and implementation and acquiring new competencies; when should documentation of business potential be presented and which implementation steps will be suitable.

Such four idealized approaches could be merged into a total approach.

Step 6: Organizing, manning, and cooperation

Planning basis, situation analysis

Actual knowledge about the project – at the interested parties?

Interested parties’ expectations regarding engagement and contribution?

Surrounding organizations and their conditions for cooperation?

Project need for know-how, skills and work effort?

Available persons?

Models for project organization?

Project work structure – work paths and milestones and deliveries?

Need for communication in the project organization?

Need for communication with the surrounding organizations?

How to acquire understanding and acceptance?

Plan elements

Principles for the project organization – structure, functions, and manning.

Organogram – structure.

Manning.

Arrange cooperation with the user organization and other interested parties – contribution, hearing, and test.

Arrange communication in the project organization – meetings.

Arrange communication with the interested parties. Influencing them to get their understanding and acceptance. Information about the project and the future thereafter.

Plan for making the project visible.

Procedures for distribution of documents.

Arrange the project database (info-room).

References

• D.1 Tool sheet: Arranging the project organization

• E.1 Tool sheet: Meetings

• G.3 Tool sheet: Project info-room

• Chapter 4

• Chapter 5

Comments

The main structure of the project organization should be arranged at the project start. At the beginning of new phases, the organization is adjusted to the new tasks and to the need for outwards coordination and communication.

Step 7: Resources, work effort, and economy

Planning basis, situation analysis

Required special know-how?

Resources needed and resources available? Expected effort?

Experience data for resource effort and for costs?

Limits for investment, costs and financing?

Financing sources?

Uncertainties and risks?

Plan elements

Overview of need for special competencies.

Principles for internal and external provision of resources – including user’s effort.

Estimate of resource effort for phases of the project process. Types of competency, disciplines.

Agreement with departments delivering resources.

Plan for training/education of project people.

Agreements with consultants, systems suppliers, etc.

Estimated resource costs.

Project budget – cost and financing.

Facility and equipment plan.

Points of special attention. Uncertainties.

References

• D.2 Tool sheet: Manning the project team

• G.9 Tool sheet: Resource control

• G.10 Tool sheet: Cost control

• G.12 Tool sheet: Contracting

• Chapter 7

Comments

Project scoping, arranging the approach and overall planning are linked to considerations concerning needed and available resources. The realism of the project scope and plan is based on sufficient resources. The project result is not always what you wanted, but determined by the actual resources (competency).

The resource analysis is primarily oriented toward the need for competent people – with knowledge and skills, creativity and ideas, engagement and will. Search for knowledge is essential for the project work: knowledge about potential technologies and solutions, requirements from authorities, knowledge about similar projects and solutions in other companies.

In organizations with many projects, it may be difficult to get commitments from people at the planning stage. Allocation of people to projects is also an on-going activity. Projects compete for key persons. Motivating people to participate and motivating managers to support are often necessary.

Realism of the project plan is based on sufficient work effort delivered as expected. A quantitative resource plan is necessary too – related to the activity plans. Man-days or man weeks for the main activities specified on types of competency and, possibly, on key persons.

The need for project effort should be compared to the available capacity. The participants should see their total workload.

Project costs are budgeted for each phase in the project approach. Some costs are related to resource estimates and other costs are related to supplies, facilities, and equipment. The estimates are converted into a budget, considering uncertainties in the estimates.

The project will probably first use existing facilities and equipment and buy or rent supplementary equipment. Critical (scarce and important) equipment should be a special focal point.

Step 8: Points of special attention

Planning basis, situation analysis

A full picture of complexity, challenges, and uncertainties from the preceding planning elements.

Essential assumptions? How valid are they?

Chances and opportunities – primarily in the project environment?

Risks and threats in the project process and the environment?

Project sustainability? What may change that?

Need for flexibility and potential adaptations?

Plan elements

Maneuverability – strategy for exploitation of chances and opportunities.

Maneuverability – potential actions toward risks.

Plan for quality assurance.

Environment plan – monitoring and influencing.

Point of special attention – responsible person for each point.

References

• B.1 Tool sheet: Project challenges

• B.5 Tool sheet: Analysis of uncertainty and risk

• A.1 Tool sheet: The project portrait

• Chapter 3

• Chapter 7

Comments

The outcome of the planning effort – the project plan – is usually regarded with optimism and enthusiasm. However, it should lead to a good result. Therefore, the project manager should know the uncertainties and challenges and the conditions for success and direct management effort toward them. The plan should be examined:

• What will be uncertain and difficult?

• What will be important for quality, acceptance, anchoring, fulfillment of success criteria and keeping of budget and deadlines?

Many mitigating activities are planned at the preceding planning steps (elements). In this element, they are gathered and refined.

Step 9: Control and management

Planning basis, situation analysis

Project challenges and uncertainties?

Requirements to project management? Interested parties’ expectations?

Points of special attention?

Required management competency?

Prescriptions and models for project management?

Plan elements

Principles for project management.

Control functions and procedures and systems.

Selected management type.

References

• C.2 Tool sheet: The project plan

• Appendix 7

• Chapter 7

Comments

Figure C5 illustrates the typical project management functions and processes.

Opens in a new window.

Figure C5.

Five-by-Five Model of Control Functions.

Step 10: Anchoring of the project and the plan

Planning basis, situation analysis

The support to the project – sponsors, resources, decisions?

Important tensions?

Changes in expectations from the interested parties?

Plan elements

Acceptance of the plan.

Acceptance of allocation of resource persons and work effort.

Acceptance of deliveries to the project.

Acceptance of budget and financing.

Opens in a new window.

C.2. Tool Sheet: The Project Plan

What

The result of the project planning is documented as:

• the project owner’s project charter, which at the project start is expanded into the

• the project plan, which is expanded into

• the project control file

It is a holistic plan consisting of several documents related to the steps in the planning process. More documents will be added during the project.

Some technical documents also exist – e.g., requirement specifications, systems, and product specifications – as working documents. The final editions of these specs are normally placed in the company’s product and process specification files.

Use – Where and When

The project owner’s project charter is the primary means of securing the project mission, scope, and limits. It is an agreement between the owner, the project manager and the project team. It should be updated during the project when the parties agree on changes. It may be seen as a contract, describing mutual obligations and important conditions. Similarly, the project plan may be seen as a mutual agreement.

The project control file contains all control documents. It should also contain project control procedures, document templates and standards, ensuring that the participants use a common set of documents. The file may be a website enabling electronic communication between all participants.

The control file is for the project only. The company may have a project management manual (handbook) with procedures, templates, and standards to be used in projects.

Method

The project owner’s project charter

The project charter describes the project mission and task and is the basis for the first version of the project business case. The charter will usually not tell about the project approach. This description is included in the project plan.

Proposed project charter content is listed below. More data may be added when the charter is a formal contract. The charter may be changed for good reasons during the project – but we recommend using the project plan as a dynamic and updated document.

1. The project task

   • 1.1.

     Project task

     • 1.1.1.

       Project description

       • –

         The project outlined

       • –

         The problem and background, actuality and character.

       • –

         Opportunity/potential or absolutely necessary

       • –

         The project as an element in a strategy and program

       • –

         Project limits

       • –

         Conditions and assumptions.

     • 1.1.2.

       Basic idea

       • –

         The basic and leading idea of the project.

     • 1.1.3.

       Description of goals

       • –

         Project mission and utility values

       • –

         First estimate of costs and benefits, profitability, business case.

   • 2.1.

     Organization

     • –

       Project anchoring in the basis organization.

     • –

       Project responsible manager, decision forum.

     • –

       Project management.

The project plan

The project charter is developed into a project plan by describing approach and organization. The elements in the five-by-five model may provide a list of content – to be adapted to the individual project. The proposed list of content is:

1. The project task

   • 1.1.

     Project task

     • 1.1.1.

       Project description

       • –

         The project outlined

       • –

         The problem and background, actuality and character.

         Opportunity/potential or absolutely necessary

       • –

         The project as an element in a strategy and program

       • –

         Project limits

       • –

         Conditions and assumptions.

     • 1.1.2.

       Basic idea

       • –

         The basic and leading idea of the project and in the solution/product

       • –

         Sales arguments for the product. Distinctive competitive character

       • –

         Positioning features.

       (The basic ideas in the product are developed in the concept development phase)

     • 1.1.3.

       Description of goals

       • –

         Project mission and utility values

       • –

         Success criteria

       • –

         First estimate of costs and benefits, profitability, business case

       • –

         Deadline for implementation – product in use and benefits acquired

       • –

         Cost and resource budget.

     • 1.1.4.

       The change task

       • –

         First picture of the size of change and the consequences.

   • 1.2.

     Interested parties

     • –

       Important interested parties

     • –

       Interests and influence on results.

   • 1.3.

     Environment

     • –

       Important elements and relations

     • –

       Essential connections and interfaces.

   • 1.4.

     Points of special attention

     • –

       Uncertainties in and around the project

     • –

       Tensions

     • –

       Critical assumptions and conditions.

2. Approach

   • 2.1.

     Proposed strategy. Phases, decision points

   • 2.2.

     Main milestones and deadlines

   • 2.3.

     Project structure, work paths

   • 2.4.

     Master plan and coordination and control schedule

   • 2.5.

     Work plans.

3. Organization

   • 3.1.

     Organization

     • –

       Project anchoring in the basis organization. Project responsible manager, decision forum. Structure, functions, and roles.

     • –

       Project manager

     • –

       Core team, key persons.

   • 3.2.

     Communication, internal

   • 3.3.

     Communication, external.

4. Resources

   • 4.1.

     Work effort, budget, and plan

   • 4.2.

     Project economy, cost budget, financing budget

   • 4.3.

     Facilities, equipment

   • 4.4.

     Materials, budget, and plan.

5. Management and control

   • –

     Control and reporting requirements.

6. Learning.

The project control file

The project plan may be converted into a document (information) file with this structure:

1. The project

   • 1.1.

     Project task

   • 1.2.

     Interested parties

   • 1.3.

     Environment

   • 1.4.

     Points of special attention.

2. Approach and plan

   • 2.1.

     Project structure, work paths

   • 2.2.

     Master plan, coordination, and control schedule

   • 2.3.

     Work plans.

3. Organization and cooperation

   • 3.1.

     Organization. Structure, functions, and roles. Manning and responsibilities. Names and addresses.

   • 3.2.

     Communication, internal. Meeting system, bulletin board, issues, meeting calls and minutes.

   • 3.3.

     Communication, external. Information plan and information materials. Correspondence.

4. Resources

   • 4.1.

     Work effort, budget, and plan

   • 4.2.

     Project economy, cost budget, finance budget

   • 4.3.

     Facilities and equipment

   • 4.4.

     Materials, budget, and plan.

5. Management and control

   • 5.1.

     Control procedures

   • 5.2.

     Logbooks concerning the project, the product, the implementation and the process

   • 5.3.

     Project reports, recommendations, scorecard.

6. Learning.

C.3. Tool Sheet: Project Structure

What

Projects will often lead to several products and impact several areas. Structuring the project means identifying the effects, the products and their elements and connections. The structure also includes arranging work paths and milestones.

Use – Where and When

The project structure is used for developing the project plan and organization. It is used for arranging documents, information/data, costs, etc.

A systematic and consistent structure is important in large and complex projects. The structure provides a common terminology, which is necessary when an IT system is used for project control, integrating the control functions.

The term “work break-down structure” (WBS) is often used. This term primarily covers activities and deliveries. It is necessary to use other structures as well.

Method

The project structure may have several dimensions or elements:

• Mission structure – The overall division into mission/effect areas.

• Product structure – The products and the division of each product into systems and modules and units. Functional division or physical or geographical division.

• Work path structure – The work paths leading to intermediate results/products and to final results/products.

• Method structure – The procedures and activity modules to be used.

• Document structure – Prescribed document types and standards to be used.

• Organization structure – Organizational units participating in the project and outside of the project. Responsibilities.

• Contract structure – Deliverables to the project (work effort, services, products, systems, etc.)

• Resource structure – The disciplines for the project work.

Structuring in Result Functions

The project task may be structured into the resulting functions – to be performed by the final product, system or process plant. For example, a new manufacturing and logistics control system may be structured into the following systems/functions: materials control, capacity and load control, procurement control, storage control, manufacturing control, delivery control.

At the very beginning of the project, the structure may include a list of problems and issues to be analyzed and decisions to be made. The project structure will be developed during the project.

Structuring in Systems

When a picture of the project product emerges, it may be the basis for a systems structure – the systems, modules and units in the final product and the environmental systems. During the design and engineering phase, it develops into a hierarchical structure. Figure C6 shows an example. The lowest level of a product structure is the materials and standard components. It should be possible to extract total amounts of these items across the hierarchical structure, for standardization and procurement reasons.

Opens in a new window.

Figure C6.

Structure for Development of a Manufacturing System.

The development of business processes with IT systems support may be structured in a similar way. A general structure is:

• Business and support processes, procedures

• IT programs, software

• Manuals, user handbooks, training

• Technical equipment

• Staff and organization

The basis for structuring into work paths is pictures of the planned final result. Figures C7 and C8 show two essential types of pictures. They should be supplemented by pictures of the environment, the interested parties, etc. Figure C9 shows the project structure related to Figure C7.

Opens in a new window.

Figure C7.

Process Diagram Is the Basis for Structure (an Example).

Opens in a new window.

Figure C8.

A Process Plant Is Divided into Modules/Units (a Cement Factory).

Opens in a new window.

Figure C9.

An Example of Project Structure.

Physical or Geographical Structure

Structuring in systems does not imply that each system is a physically separate unit. Systems are often integrated. For example, the electrical system in a process plant or a building spans across rooms and sections. A ventilation system is another example. This means that several systems meet in a room, making it necessary to arrange the room layout. Physical units and components are arranged and linked.

This means that a physical and geographical (three-dimensional) structure is necessary.

Structuring Organizational Affiliation

Structuring in mission and product deliverables and in work paths and milestone deliveries during the project leads to responsible persons and organizations (departments, suppliers, etc.). Establishing work groups for each work path may be a natural structure.

Tasks (work packages) in the project are naturally delimited to fit existing organizational units – engineering tasks for the engineering department, programming for the programmer group, and carpenter jobs for a carpenter company. Tasks (contracts) are delimited to trades/crafts and this division is natural in repeated projects (e.g., building projects) where interfaces, cooperation, and coordination are well known.

Trade (discipline) orientation, however, cuts across the above-mentioned systems and unit structure. The project idea is to create holistic solutions – meaning that the trades should cooperate closely together and maybe create new solutions together. Some suppliers may offer trade-integrated development, engineering, and construction. In other situations, such organizational entities should be organized.

Combining Structures

The described ways of structuring should usually be combined – either as a multidimensional structure or as a hierarchical structure. The combination is used for defining manageable work packages and their interfaces. The handling of interfaces is especially important. Figure C10 shows different types of interfaces between tasks in the same function, system or physical unit or between such entities. Figure C11 shows how an activity in the project plan links to several parts of the project structure. Figure C12 shows how a project structure may be used for systematic delimitation of activities.

Opens in a new window.

Figure C10.

Three Structures and Their Connections.

Opens in a new window.

Figure C11.

Activity Relations to Project Structure.

Opens in a new window.

Figure C12.

Different Activity Delimitations.

Some technical illustrations are necessary for controlling the project work – in addition to project activity documents and plans. Examples are function/process diagrams, systems diagrams, flow diagrams, pipe and instrument diagrams, layout arrangements and models.

References

• Chapter 3

C.4. Tool sheet: Project course-of-action models

Opens in a new window.

What

When the project scope is defined, we need to know “how to do it?” We need an approach or tactical plan. There may be several options and we should arrange the best approach to the actual project situation – considering both the systems development part and the organizational change part of the project. If the project is unique, the approach probably should be unique too. But many projects are similar to each other and a company model or an external model will be suitable – well known and easy to apply.

Use – Where and When

The course of action (approach) is arranged at the beginning of the project and is revised at new phases, especially in the concept development phase.

Method

There is an essential difference between course of action models for well-defined implementation projects and those for explorative development projects. The former should reflect clear goals and activities in implementation, and the latter should reflect uncertain goals and especially the uncertain plan. However, practice shows that implementation models dominate and are used in many development projects as well. There has also been a tendency to use one project approach model for all projects in the company. An understanding of the need for a situational approach has developed during the last years and new approach models have emerged. We will discuss:

• classic models

• concept-based approach

• parallel streams model

• step-wise development and implementation

• timebox approach

• version stages

• iterative development

Classic Models

For many years, the general models have been known as “waterfall” models – because their Gantt-chart illustration looks like a waterfall or stairs. There are several phases (stages) and they reflect the logical workflow in engineering, construction or systems development and implementation. See examples in Figures C13–C19. They presuppose a reliable requirement specification early in the process. They are decision-point models with sequential phases and stop/go and direction decisions after each phase. This is often difficult in practice and leads to long project duration. Their technical process orientation means that they pay limited attention to the organizational change process – it is typically called implementation as the final phase.

Opens in a new window.

Figure C13.

The Classic Phase Model – The Waterfall Model.

Opens in a new window.

Figure C14.

A Phase Model for an IT Project.

Opens in a new window.

Figure C15.

A Phase Model for Implementation of a Standard IT System.

Opens in a new window.

Figure C16.

A Phase Model for a Product Development Project.

Opens in a new window.

Figure C17.

A Phase Model for Medicare Product Development.

Opens in a new window.

Figure C18.

Phases in an Engineering/Construction Project.

Opens in a new window.

Figure C19.

A Phase Model for a Building Project.

An example is the classic new product development approach as steps in a progressive problem-solving process: (1) defining the need; (2) concept development; (3) design and engineering; (4) manufacturing arrangement; (5) pre-production; and (6) launch. Activities concerning marketing, sales, logistics, after sales service, etc., are included in the same phases.

Each phase leads to results. Some of them are states – e.g., that the problem and need are visible; that the concept has been selected and defined; that products are manufactured; that users are trained; that operations processes are working; that benefits are achieved. Other results are specifications, products, tools, equipment, and facilities. Each phase will deliver a basis for decisions and for work in the next phase. The first decisions are go/no-go and revision of the project scope, and later decisions concern solutions and implementation. The decision points are important as a basis for the project owner’s control of the project. It is possible to start the project with vague goals and limits, but still ensure control of the process.

Concept-based Approach

Figure C20 shows a phase model with a thoroughly prepared solution/product concept as the basis for a situational arranged implementation approach. The model has five phases:

• Foundation/scoping/establishing phase. Description of the problem and potential and a first vision that demonstrates that the project value is attainable and that the project is practicable. The first scoping of the project and first anchoring at interested parties take place.

• Development and concept design phase. Concretize the vision. Search for feasible solutions and sketch a preferred solution – a concept plus requirement specification or basic product specification. Demonstrate the practicality and arrange implementation approach.

• Implementation of the solution. Detailed design/engineering of the product, test and make ready for use. Prepare the operations organization.

• Operations/use phase. The product is brought into action. Start problems are remedied and operation is refined and improved.

• Closing phase. Responsibility is transferred to the operations/user organization. Results are measured and learning from the project is described and made accessible. The project is closed.

Opens in a new window.

Figure C20.

The Concept-Based Approach Model.

Figure C20 shows some important characteristics:

• Realizing/understanding continues parallel with development. The design and evaluation of possible solutions contribute to realization. The reliable requirement specification (basic product specification) emerges together with the solution concept.

• The result of the concept development phase should ideally lead to a goal-directed implementation with reliable budget and deadline.

• The implementation phase overlaps the operation/use phase because the product is implemented in steps/modules.

• The project terminates after some operation time. Problems, failures, and defects should be corrected and operation competency should be ensured.

• Project control and organization changes from phase to phase. Search-try-learn process takes place in the concept phase and goal/budget/time is controlled in the implementation phase.

The model in Figure C20 is ideal and general and should be adapted to the individual project. A qualified concept development work is key to good implementation and results. Another characteristic is the parallel work on the main work paths – e.g., in new product development: product, manufacturing, marketing, sales, and distribution – known as “integrated product development.” The phases in the model are described in detail below.

Foundation and Establishment

Development projects have three elements in this first phase – to verify or create the foundation for the project, to scope the project and to establish (mobilize) the project. The project basis is the recognition of essential actual or coming problems to be solved, or attractive opportunities (potentials) to be utilized – and, in some situations, to ensure alignment of a project idea and the project owner’s actual strategy and business goal. The work includes dialog on preparation of ideas and proposals, dialog with potential sponsors, persuasion of skeptics, etc. When the foundation is strong enough, it is documented in a “project foundation” document (a project charter) consisting of six elements:

• A first picture of the expected future environment – a scenario. For business projects, this could be a picture of markets, customers, technology, problems/needs/potentials, required functions and services, market competition, logistics, supply, milieu, people, etc. Social and political conditions and trends may be interesting too.

• Documentation of the value of the project or the need for the project – because the scenario means future problems or potentials.

• A first scoping of the project as a task and a description of the content and limits – and main work paths.

• A first picture of the expected future after project completion – for the owner and for the users. Improvements? First description of benefits.

• Description of the most important uncertainties and points of special observance.

• Anchoring, acceptance and prioritizing at important interested parties. Commitment – sponsoring, financing and resources.

To establish the foundation primarily means to make potentials visible and probable, or to make threats and problems visible. It is also to render probable that the project can be carried out technologically, politically and economically. It is to prepare the first profitability analysis and calculation: the business case.

This implies ideas of potential solutions, the cheapest and the most expensive. But the solution should not be found and decided on in this phase. You should find enough information for a Go or No-Go decision and framing of the concept development phase. The project foundation should also be reinforced in this phase in some situations, to qualify the project to proceed to next phase. The project is formally decided on and authorized – with clear commitment from important interested parties.

The next part of the phase is establishing the project. It entails to structure the project task, to consider the approach, to organize the project management part of the project organization, to allocate resources for the first phases and to prepare a first version of budget and time line. It is still important to ensure commitment from important interested parties, especially some managers. The result of this phase should be:

• the project owner’s decision

• the work basis for the next phase and documentation of the foundation

• the first version of the project master plan

In this way the project is born in a somewhat lengthy process – the recognition of the necessity is spread and the scope emerges via discussion between managers and via analysis done by selected people and task forces. The project owner decides when there is basis for a project. Managers from the project owner and certain interested parties should participate in dialog and analysis to ensure understanding, commitment and allocation of competent people to the project management core team. The five-by-five model can serve as a vehicle for a constructive dialog and ensure a coherent project definition.

This preliminary work is done “the project way” and key persons are already allocated in this phase. However, we recommend to have a formal project start at the end of the phase and a formal establishment of the core of the project organization.

Delivery projects to customers are usually scoped in a bidding and contracting phase. The foundation is documented in a contract with mutual services/deliveries and conditions for the cooperation. The project starts during the contract negotiations and it may look like a sudden start – an order.

The project will start on several levels in the project owner’s organization:

• Project owner decides on the scope, and the project responsible manager and project manager are appointed.

• The project manager analyses the situation and prepares the first plans – and arranges the first manning.

• The project management core team starts working.

Project start has two elements:

• Project start involving formulation, publishing, transfer of responsibility, motivation of participants and interested parties, prioritization, resource allocation.

• Project planning and organizing.

It is recommended to highlight the project start for the participants – a start meeting or workshop with project planning is a suitable means. See tool sheet C.7.

Concept development phase

The concept development phase is especially important in process plant projects, building projects and event projects – projects with “point of no return” or “point of very costly return” early in the engineering and construction phases. Different potential/possible solutions are sketched, modeled, visualized, discussed, evaluated or even tested. A holistic picture of the result is created – how does it look and function. Much is at stake in this phase as mistakes may lead to expensive consequences in the following phases.

The concept phase is also widely used in new product development and systems development, and even organizational development may begin with a holistic picture of the future organization, cf. Riis & Johansen (2003), Kotter (2012). The concept phase in explorative projects is the preliminary planning and consideration of alternative approaches, with uncertainties and preparedness.

It is a general experience that solid concept development contributes to quality and speed. But uncertainty in subsequent phases (the future) is an important point of attention. Some of the following approach models address this issue, but, in general, is it advisable to create a solution that allows for changes later in the project – or in use.

The analytical work in the concept development phase includes a study of user’s milieu and business processes and work processes, a study of competing products, a study of new technologies, and other explorative actions. The introduction is often an idea of a new product or technology – or a description of a problem or a potential, at first glance a well-defined task. However, it is useful to ask questions about the idea or problem. More information, analysis of the problem and its causes and use of creative methods may change the understanding of the need and produce new ideas. The front end of the phase is a search for real need and for alternative solutions – and continued search, although good ideas already are visible. This understanding is important, because most project participants are used to deciding and acting when the first feasible solution is visible. Selection should wait until later in the phase.

A holistic content model is the PPSOP model presented in Chapter 2. An important part of the concept is visualization of the wanted/expected user operations, customer service, etc.

It is obvious to see the concept as a “systems concept” – as an ideal and completely new system. But the concept should also be influenced by consideration of the change and implementation approach. Appropriate implementation steps require a product structure (modules, components, and versions) suited for step-wise implementation. Such considerations may collide with the systems developer’s idea of the ideal product design. An essential part of the concept is pictures of the product architecture and user processes serving as the basis for arranging step-wise implementation and for project control.

The concept is not developed through interviewing the users. It is developed by creative people and some of them might be users. They will study the user’s milieu and be inspired to new ideas. In some cases, the challenge is to convince the users that they will get the best solution. Most real development projects have a “sales task” somewhere in the project process, early on or later.

The concept development phase ends with “seen right,” which means that the real user needs are seen and understood, and that there is an attractive solution (a future scenario and product). The solution is not engineered, only sketched. The concept should be tested to ensure realism and attractiveness. The functionality and technical mode of operation should be proved, and the attractiveness to the users should be proved. It is difficult to test a sketched product – especially for some users. They will evaluate the final product and decide if they like it. The challenge is to visualize the product in operation – a simulation, a model, a prototype or a pilot version might serve this purpose. Users’ experience from a concept test should lead to understanding and acceptance, but will in many cases also create new ideas of needs and attractive properties.

The front end of the concept development phase is marked by searching for solutions, keeping possible solutions open, evaluating, criticizing, improving and expanding with new ideas. You might call it a “di-phase” – diffuse, divergent, diagnose, dissect, dialog, dilemma, dispute. The last part of the phase is to select, decide, act and execute. You might call it the “con-phase” – convergent, concrete, conclusion. The concept phase is a recognition process, circling between need, goal, and means.

The message is that products should be tested to be right. It is a balance between test in the concept phase and test in the final operations phase – but, of course, it should primarily be carried out as early as possible when it is cheap to redesign the product. Creative ways to user tests are recommended. Product launch and a full-scale user test in a selected user milieu are preferable, if it is relatively cheap to change the final product. A concept test is recommended when a product failure will be expensive – expensive or impossible rework and users’ bad will.

A concept test might be isolated to new elements in the product and to compatibility between modules/components. Select user groups for each type of test instead of using a permanent test group.

Of course, it is ideal to end the concept phase with “seen right.” In case of new technology and new user functions, it might be necessary to launch a first product version and test it in a selected user group – and gain experiences and reactions useful for further concept development. It might be a chain of “use and learn” and “further development and improvement.” But the concept is necessary even in such situations.

See Tool sheet B.4 about the concept content and documentation.

Implementation Phase

The implementation phase includes detailed design/engineering of the product/system and related business processes and preparation for operations/use. In explorative projects, this phase includes experiments, research, test of hypothesis, documentation, etc.

When the product concept is visible, we should deal with implementation. Technical method and logical sequence are the starting point – a house is built from the foundation and upwards. But the house may be built on site, or elements may be manufactured in a factory and assembled on site. If there are more houses on site, we should consider whether they should be built simultaneously or in clusters for stage-wise occupancy during one or two years. When should roads and park areas be constructed? Should the common heating plant be built to full capacity at the beginning or in two stages?

Similar considerations are natural in new product development, in business process development and implementation of IT systems. Implementation and use take place in stages. Functional modules in the new IT system are brought into use in sequential stages – being easier to learn for the users. The new product is launched one market at a time with versions for each market. One question is: How can the user organization overcome the implementation burden? Another question is: How is the logical engineering/construction sequence?

In explorative projects, you should consider searching for information and solutions in several directions at the same time, versus searching in one direction at a time. Consider decision points in the search process and consider “what to do if …?” situations.

Operations and Use Phase

The project solutions should be transferred to operation. The new product should work and be sold. The new process plan should operate and produce. The new IT system should operate and deliver benefits. The operations and user organization should acquire benefits – and the project organization assist until the operations organization is ready to take over. However, some projects include the operation phase as well. A theater performance, a congress, an exhibition are examples.

To bring a system or a process plant into operation is a technical process with a number of tests – tests of modules and of the total system, of interface with surrounding systems, of functionality, effectiveness, quality, stability, etc. It is often an intense process with a high degree of preparedness to correct and improve the system. A step-wise change or an overnight switch from the old system to the new system and subsequent removal of the old system. The plan may have a number of “in place” milestones.

The users bring the system into action through a number of activities – change work and processes, change organization, change roles and jobs and related competency and behavior. Keywords are understanding, competency, and acceptance. The operations organization is mobilized and trained. To bring into action also means that defects and improvements are identified, new routine is built up, habits need to be changed – and the change is an extra burden. The users’ expectations should be adjusted to this somewhat tiresome period. A point of attention is the capacity to overcome the change along with daily operations.

Closing phase

It is recommended to mark the formal closing of the project and the hand-over to the operations organization. The project manager delivers and the operations organization takes over – and both parts are important. The closing of the project is related to the well-functioning product and achievement of the first benefits as well. Project planning includes definition of the necessary “in place” measurement.

Parallel Streams Model

In the seventies, some Danish researchers recognized that the waterfall model and sequential phases did not reflect the natural way of developing a new product. For example, manufacturing issues should be considered along with technological and design issues, and not after the design had been “frozen.” This led to the idea of “integrated development” and a parallel streams model.

The starting point is the main work paths – see tool sheet C.5, Project structure. There are more work paths (streams) and more end products. Each stream has a specific approach and activities are coordinated across the streams. There may not be a distinct overall phase, but there are milestones, synchronizing points and project-decision points.

The three-stream model in Figure C21 is used in new product development for integrating marketing and manufacturing with engineering. All three elements are handled from the beginning.

Opens in a new window.

Figure C21.

A Three-Stream Model for Integrated Product Development.

In production systems development projects, it is necessary to decide on 1) production process, flow and production technology; 2) factory layout; 3) production and materials control; and 4) production organization and wages system. They are four different – but interdependent – elements. See Figure C22. For example, a manufacturing line (assembly line) versus a number of production groups around product modules will imply a different layout, different control systems, different wage system, etc. A step-wise development and definition of solutions coordinated for all four elements will be the right approach.

Opens in a new window.

Figure C22.

A Four-Stream Model for Development of a Production System.

Development of administrative systems (IT system and business process) may be seen as parallel streams – information system, organizational system, technical system, and social system. The PPSOP model is a similar structure.

Figure C23 shows the streams in a technical delivery project. Combined with the phases in Figure C18 it may create a plan structure.

Opens in a new window.

Figure C23.

Streams in a Technical Project.

Step-wise Development and Implementation

Fast implementation is often wanted and may comply with a step-wise implementation. It requires a modularized product with modules to be delivered and brought into action separately. There is often a technically defined delivery sequence, and temporary solutions may be necessary. However, the delivery sequence may be conditioned by the user’s understanding and acceptance of the solution, or by political signals or by visibility in the market.

A new highway often has several construction sites at the same time. A major IT system is implemented in functional modules.

A modular structure is created in the concept development phase. It might imply that an ideal architecture and functional integration of the product are compromised.

Step-wise is sometimes used as synonymous with iterative development, which might not be correct.

Timebox Approach

The steps may be related to so-called time boxes, meaning that there is a deadline for delivery of the module and a “time box” for the work, cf. Schwaber & Sutherland (2016). The deadline is to be taken seriously, implying that it must be kept whereas the delivery may have to be reduced. Allocating more resources is often not possible or allowed. For instance, the delivery date may be a Thursday to avoid working overtime in the weekend. The project manager is empowered and able to make decisions in most situations – to avoid lengthy decision processes.

The product module to be developed in a time box is defined by properties (functions and features). They are prioritized in three groups:

• Necessary properties – Must be delivered to ensure a useable and useful module. But they may be restricted to “absolutely necessary.”

• Useful properties – Each useful for one or more users, and considering most recurring user situations.

• Nice-to-have properties – Considering seldom situations or making useful functions easier.

The plan for a module timebox is to deliver all necessary properties – and all useful properties as well, as far as time and resources allow. In addition, there may be room for some nice-to-have properties. The remaining properties are transferred to a later time box. The plan considers delivery, resources, time and uncertainties.

The structuring into time boxes will make the work more manageable for the participants. There are no lengthy activity plans and the work is coordinated every day. Time and resources to complete the work are re-estimated every day or week. Low-priority elements are cut and transferred to a later time box if the planned delivery turns out to be not possible.

Version Stages

The product concept is often planned to be realized and launched in a series of versions – each being a new edition of the product. Typically, each new version will have more, enhanced properties.

The idea is fast implementation/launch or to deliver to limited user groups or to publish product news frequently.

Version stages are usually planned from a total picture of the final product and selected versions.

Iterative Development

Users’ evaluation of new products and systems is most reliable, when the users can test the final product. This has led to approach models with early tests – typically, in the concept development phase. Rapid prototyping, e.g., is early development of a “one-time” prototype, being useful for identifying users’ needs and reaction to solutions, before expensive design work is started. A spiral model suggests developing a series of prototypes – typical for reduction of risk elements.

Experience from complex projects, such as major IT systems, shows that the waterfall model, beginning with a systems requirement document and a lengthy development process, is not suitable. New requirements emerge during development, and other requirements are found not to be useful. The environmental conditions change during the project. There is a growing interest in faster and step-wise approaches – among other things, iterative development, time box, and extreme programming. See Section 3.4.5 for an introduction to Agile Project Management.

A common denominator for these models is a qualified concept development work, not resulting in a “frozen” concept, but in a flexible and adaptable concept. An important characteristic is the product/systems architecture dividing the product into a set of modules to be developed separately, and allowing changes of modules as well as removal and addition of modules. The architecture is changed and detailed during the project, and the concept is developed further in the light of experiences and new conditions. A module may represent a development stage and a module may be developed in an iterative process.

In each stage (time box), there is a dialog with the user, and there are test and improvement. Figure C24 shows the principle. The modules are prioritized based on three criteria: functional necessity, technical challenge, and usefulness.

Opens in a new window.

Figure C24.

The Principle of an Iterative Approach.

An example from Microsoft product development is shown in Figure C25 (Cusumano & Selby, 1996). In the engineering phase, the developers develop new ideas about functions, design and user interface. It requires decisions from the designers – they should be fast and ensure product coherence. A systems architect updates and controls the concept architecture. New components are added frequently – several times every week – and all participants can see the actual structure. It is a visual synchronization of the participants’ work and the product is tested continuously for component compatibility. The product is stabilized at certain points and this may include changes in already delivered components.

Opens in a new window.

Figure C25.

An Example of an Iterative Approach.

Concept development in organizational change projects may be difficult and demanding. Sometimes, it is best to begin implementation of the first concept edition – to learn from that, change and develop further and then re-implement.

Different Views

Approach models for technical delivery projects and building projects are often common standard models and include terminology used in this line of business – typical phase models with a clear definition of deliveries from each phase. They also distinguish between project owners’ model and consultants’ and suppliers’ models. The technical approach is one view. However, the commercial approach may be somewhat different – see Figure C26.

Opens in a new window.

Figure C26.

Different Views – Different Phases.

References

Andreasen, M. M. & Hein, L. (1987). Integrated Product Development, IFS (Publications) Ltd, UK and Springer-Verlag. An English and later version: Andreasen, M. M. & Hein, L. (2000) Integrated Product Development, IPU, The Technical University of Denmark.

Beck, K. (2000). Extreme Programming Explained. Addison-Wesley.

Cusumano, M. A. & Selby, R. W. (1996). Microsoft Secrets. Harper Collins Publishers.

Kotter, J. P. (2012). Leading Change. Harvard Business School Press.

Riis, J. O. (2009). Models for Company Development – A participatory approach taking manufacturing as point of departure. Center for Industrial Production, Aalborg University.

Riis, J. O. & Johansen, J. (2003). Developing a manufacturing vision. Production Planning and Control. 14(4), 327–337.

Schwaber, K. & Sutherland, J. (2016). The Scrum Guide. Retrieved from http://www.scrumguides.org

C.5. Tool Sheet: Change process

What

The change process includes all five elements of the PPSOP model (product, processes, systems, organization, and people), but here we will focus on the human side of change management and present a few relevant methods.

Use – Where and When

Change processes and change management are relevant in all project phases – see Figure C27.

Opens in a new window.

Figure C27.

Organizational Conditions for the Project.

Method 1: Considering the approach

When the project approach primarily is a change process and secondary a systems development process, we recommend a situational approach instead of a standard phase model. Be aware that several change management books prescribe a stage model (or a circular model) that, in fact, is very similar to a classic project process. Their starting point is a change goal and the process is to convince the interested parties.

There are three different starting points for the considerations and approach:

1. When somebody has recognized a need of a change – but the direction is unclear.

2. When there are a need and a vision (future scenario).

3. When there are a vision and a solutions concept.

The following introduction is related to the interested parties in the change. The starting point is an analysis of the parties’ understanding, acceptance and competency. The analysis of interested parties and of the change situation may lead to a number of pictures of the situation – shown in Figures C28–C30 – and is composed of the notions of understanding, acceptance and competency. Each picture (combination) leads to a number of possible approaches to the change process. It is not a catalog – only some possibilities. Our intention is to inspire to reflection, and we believe that our readers can create good approaches.

Opens in a new window.

Figure C28.

Interested Parties’ Understanding and Acceptance of Necessity or Value.

Opens in a new window.

Figure C29.

Interested Parties’ Understanding and Acceptance of the Concept and Vision.

Opens in a new window.

Figure C30.

Interested Parties’ Change Competency.

The choice of approach is basically decided by the selected change strategy – see Chapter 3. Look at Borum’s four strategies and Kotter’s change model. Each example of an approach is related to a change strategy – and it is possible to describe an approach for each strategy – in each situation picture. The change leaders’ choice of change strategy may be based on:

• their attitude to leadership and their preferred behavior in change situations

• their understanding of the size and extent of the change – radical renewal or an improvement

• their understanding of change complexity and opaqueness

• their interest in consideration for interested parties – humanistic considerations or relationship considerations

• their understanding of power balance – interested parties and themselves

• their understanding of the interested parties’ acceptance of different strategies

• their understanding of risks and consequences of negative attitudes

A situation analysis at starting points 1 or 2 may lead to the situations shown in Figure C28 – a combination of understanding and acceptance of the necessity or value of the change. Notice that acceptance includes situations with disagreements between parties. Conflict resolution may be needed. The arrows show directions for shifting acceptance and understanding.

When there is a solutions concept and the change task is to gain understanding and acceptance, the situation analysis may lead to the combinations shown in Figure C29.

In addition to the above reflections, you may consider the interested parties’ change competency – how accustomed and which record of results – see Figure C30.

The approach considerations lead to an approach plan (master plan) with work paths and milestones and stages, and with some “what-if” stages/points. Each milestone has a related situation analysis and re-planning activity. The systems development process should be adapted to the change approach, which the developers may find a bit troublesome.

Method 2: Change analysis

Some interested parties – primarily users of the project product throughout the life cycle – will experience changes due to the project. The change analysis should deliver a picture of the change and of the necessary anchoring. The change analysis is prepared several times during the project as a step-wise clarification and adaption to new knowledge and new attitudes:

• At the project beginning – as far as possible. The changes may only be visible as differences between the vision and the present state.

• At the end of the concept development phase – as part of the planning approach.

• At the planning of the operation phase.

The elements of a change analysis are shown in Figure C31. Some elements may not be relevant for all parties.

Opens in a new window.

Figure C31.

Change Analysis and the Change Task.

Related questions are:

• Which understanding of the changes and their requirements does the interested party have?

• How is the attitude to the changes? How is the actual acceptance and anchoring? How will the interested party react?

• Which effort will the changes require?

• Which potential for realizing the changes does the interested party have?

Method 3: The change task

The above-mentioned analysis will provide a picture of the change task, either as part of the project or superior to the project. Another contribution to the picture is the project portrait (see tool sheet A.1). The picture is a basis for considering a tactical approach to the change.

Method 4: Influence and engagement

The picture of the change, its consequences and expected reactions from interested parties provides a basis for considering how to involve the parties. Immediate questions are:

• Which degree of anchoring and commitment do we need?

• How do we ensure anchoring?

• How will we see signs of anchoring?

• Which party effort will be required to change?

• When and how should the party be involved?

• How can the party support the change?

• How can the party obstruct the change?

Figure C32 shows some means to create engagement from interested parties (source: PWC Consulting). In addition, it is emphasized that attitude to changes very much depends on whether:

• the interested party feels heard and respected

• the interested party feels that competency is developed and running-in is supported

• the interested party is prepared to meet troubles until a new routine is built up

• the interested party is prepared to meet failures and defects in the product at the beginning

• the interested party sees that failures and defects are rectified resolutely, and user effectiveness and productivity increase every day

Opens in a new window.

Figure C32.

Means of Creating Engagement.

It is what the involved party sees and feels that counts – not how the project and change manager see things.

The influencing effort and activities toward interested parties require some thought. The parties reflect on what they hear and see and they react in different ways. Figure C33 shows some factors that they may consider. They may be supplemented by advice for how to present proposals and ideas.

Opens in a new window.

Figure C33.

Considerations from interested parties.

References

• Chapter 3

• Relevant tools are available in:

• Ackerman Anderson, L. & Anderson, D. (2001). The Change Leaders Roadmap. Pfeiffer

• Brandi, S. (2010). The practice of change (in Danish). L&R Business.

C.6. Tool Sheet: Coordination and Control Schedule

What

The coordination and control schedule is the overall plan for project work in each phase. It should show work paths and their milestones, and in addition the main activities leading to the milestones, who is responsible for activities and who works on activities.

Use – Where and when

The coordination and control schedule is used in all project phases. It is prepared at the beginning of each phase. Preliminary plans for later phases might be prepared too.

Method

The coordination and control schedule is primarily a plan for the approach to each phase. It shows work paths and the milestones in each path – until delivery of final results from the path. The schedule is also a coordination plan, showing how the milestones are interrelated across work paths.

For each work path, the schedule should show the main activities to be carried out before each milestone, and who should lead and participate (deliver) in these activities. The activities may be rearranged to show the deliveries per working participant – enterprise plans. A rule for detailing into main activities might be: One person per activity should be responsible, but there may be more participants.

At one-time projects, the plan is a result of the design of approach. Alternative ways of carrying out the work may be discussed based on available development methods. Product development, systems development, and some technical projects are often characterized by the use of (nearly) the same approach from project to project. Here, the schedule should ensure that all project elements are considered.

Figure C34 shows the principle behind the structure of the plan. The left column is the work paths, and milestones and main activities are shown horizontally. This is also the timeline.

Opens in a new window.

Figure C34.

Structure of the Coordination and Control Schedule.

Work Paths

Work paths are defined for each phase although some work paths may cover several phases. General paths are:

• The system, product

• The change process

• The environment

• The interested parties

• Project management

Elements of the system/product and the change process are the PPSOP elements – the elements to be developed or improved and delivered to customers/users:

• Products – Services and products from the operation organization.

• Processes – Business and work processes in the operation organization, to produce and deliver the products. Related support processes and control processes.

• Systems – Technical systems, information systems, facilities, etc., necessary for the processes.

• Organization – Operations organizational structure, performance norms, etc.

• People – Operators in the operation organization with new competencies, understanding of norms and values, attitude, behavior, and performance.

The system-oriented structuring into work paths is based on the structure of the phase product or the final product. The product structure (composition) is defined in detail during the development and design work. Part of the management job is to ensure coherence and fit across interfaces – to ensure creation of a holistic solution.

At the beginning, when the product structure is not visible, the work path structure of the systems development process might be functions or problems calling for solutions and decisions. A “decision plan” is often a good first structure.

See also Tool sheet C.3 on Project structure.

Approach

Planning per work path may begin with milestones in a chosen or logical sequence (approach) – or may begin with a list of main activities. Milestone planning is often the best way, because milestones call for activities. Milestones are also coordination points across work paths and they are used for progress measurement. Deliveries from the main activities are not milestones. A milestone is a situation, when all planned deliveries are in place.

Milestones

Essential milestones in the project process are:

• “In place” milestones – New systems, procedures, processes work satisfactorily and with visible benefits.

• Delivery milestones – Useful products with related user training and guidance. It may be total products or functioning modules.

• “A bargain is a bargain” milestones – Now, it is costly or impossible to regret and change the product or the plan.

• Knowledge milestones – A problem is illustrated and clarified. Focus on learning and knowledge.

• Risk (mile)stones – A risk is analyzed and clarified, dealt with or removed.

• Decision milestones – Decision about project directions and solutions.

The work process leading to a milestone is traditionally arranged in an activity plan. However, Agile project management is promoted by planning with smaller work milestones:

• Work results – Analyses, sketches, components, manuals, etc.

• Agreements – Contracts, order confirmation, acceptance to solutions.

• Coordination milestones and integration milestones – Components/elements from more work paths are coordinated and tested together. Descriptions of functions are ready for coordination, all specifications of components are ready for purchase, system modules are ready for integration test.

• Test milestones – Functionality, reliability, usability, etc., are tested.

• Anchoring milestones – Acceptance, user competency, etc., are demonstrated.

• Approvals – Authorities, managers or control agents approve.

• Transfer of responsibility – The project receives responsibility from supplier or transfers it to user.

A milestone is a stage, a clear state or situation, a visible event, or a visible (major) work result (delivery). The milestone is described by its status; for example, “user manual is ready for use,” “purchase order is confirmed,” “machine is tested and ready for operation,” “authorities have approved,” “users are satisfied.”

Some milestones are natural points for re-evaluation of the project and the approach. Such decision points should be marked in the plan.

A clear description of milestones creates a common understanding of the approach and plan, e.g., by using the milestone form. The hearing and decision process and the involved parties should be described for important decision milestones. Quality control and required milestone documentation should be documented before each milestone. Typical milestone data are shown in the textbox.

Activities

Main activities end with a delivery – a documentation, a research result, a test result, a product module, etc. For coordination reasons, the main activities should be broken down into important deliveries (from or to whom) during the main activity.

The person or supplier responsible for a main activity should prepare the detailed activity plan in due time before starting the main activity. However, a first breakdown into activities might be useful for estimating duration and resource effort.

The activity data should be delivered by the responsible people, departments, and suppliers. They know what to do, duration, resource effort, cost, etc. Discuss the plan with the participants – they will comment on activity interfaces and coordination, and this will contribute to acceptance of the plan.

Activities are carried out by the project team members and by suppliers and departments – in both situations preferably defined as deliveries to the project. The project team will monitor deliveries from suppliers and departments. Time-consuming processes without human effort are also activities, e.g., curing time for concrete, growth period for plants, and chemical processes.

Activities have work content expressed as the performance, e.g., the number of functions to specify or to program, or to grout X m3 of concrete. Activities require resource effort expressed as categories and amount. Activities have a duration expressed in calendar time. Activities consume and convert/transform materials. Activities deliver output (including waste).

Project work is delegated to people responsible for work paths and activities – so coordination is important. The participants should discuss and describe the interfaces and the need for coordination.

The activities in a work path usually have a natural and logical sequence, defined by the technical content or by the chosen approach. Interdependencies also exist between activities across work paths – preceding and succeeding work paths, installation sequences, coordination of procurement, etc. This is part of the detailed work planning.

Activity responsibility

The coordination and control schedule should also define “who does what” for each main activity. Typical tasks and roles are:

• Responsible – Responsible for execution and for delivery, for deciding on work basis, method, activity plan, resource budget, cost budget, etc.

• Work – Carry out work on the activity – with initiative

• Deliver – Deliver services and components, required by the responsible person

• Advise – Advisor to workers and for the responsible person – on request

• Monitor and control – Control observance of regulations, standards, and requirements

• Evaluate – Evaluate proposed solution before decision

• Be informed – Be informed about plan, progress, solutions (after decision, but before execution).

Schedule

Milestones are defined as situations and have an attached date (deadline). In this way, milestones are used for keeping speed – they are focal points for monitoring. A maximum of four to eight weeks’ time distance between milestones means that the participants have a feeling of being in a hurry. Some advice for scheduling:

• Time critical activities should have a suitable time buffer before the milestone.

• Nontime critical activities should be finished in due time ahead of the milestone.

• Define a “check signal” in each main activity some time before the deadline to allow for time to control if the activity will finish on time.

Figure C35 shows factors that determine activity duration. A deliberate optimistic or pessimistic estimate will reduce confidence in the plan as a control tool. Duration is often estimated via comparison with previous similar activities. Experience from more persons should be used in case of considerable uncertainty and the uncertainty should be indicated through the estimated most realistic duration and pessimistic duration.

Opens in a new window.

Figure C35.

Factors Determining Activity Duration.

Milestone planning

The method described below may be used for activity and milestone planning in a single work path. It is based on classic milestone planning and is inspired by the Lean method “vertical value stream mapping” (developed by Lean Advisors Inc.). The idea is a careful planning of the process by using people’s experience and creativity. Focus is on good experience, standard methods and avoiding waste (see also tool sheet C.8).

The planning is done by the project core team and supplemented by persons with experience from important areas. The participants should develop a coherent workflow and understand how their contributions (deliveries) are most useful for the next actor in the flow.

The plan is visualized by colored post-it notes on the wall.

Opens in a new window.

Opens in a new window.

Opens in a new window.

Step 1:

Draw a timeline on top of the wall.

See, at first, the workflow as a logical sequence of milestones representing accepted deliveries – specifications, models, prototypes, finished products – or similar milestones in the change process. Identify 4–5 mile stones, depending on how far planning is realistic. Write a post-it note for each milestone and place them under the timeline – with an estimated time distance.

Step 2:

Describe input to each milestone – information to be used and deliverables. Each participant should contribute with knowledge about necessary input. Use a new post-it color and place over the milestone note. Describe the result after the milestone with visible results and decisions. Which criteria are there for go/no-go? Choose a new post-it color and place under the milestone note.

Describe what should be “frozen” after the milestone – things not to be changed or expensive to change. Choose a new post-it color and place notes to the right of the milestone note. Describe the conditions for possible changes. If flexibility is needed, it might be useful to describe the degrees of freedom too.

Describe uncertainties and challenges related to the milestone. Write on a post-it and place to the left of the milestone note.

Now, there is a bloc with five notes for each milestone. Due to the limited space on the notes, it may be useful to document the data in the milestone form.

Step 3:

Describe the core disciplines of the project work including project management. Write a post-it note for each discipline. Place the notes in a vertical column to the left. Describe how each discipline is represented in the project – a person in the core team, persons outside of the team, departments, suppliers, etc. Describe how to decide on contributions from the disciplines.

Describe the customers/users in the value chain for the project product. Write on post-it notes and place them in a column to the left.

Describe the suppliers to the project on post-it notes and place them in a column to the left.

Decide which core discipline should be in charge of each milestone – preferably, a person in the core team. Move the milestone bloc of notes down – on level with the discipline note to the left.

Describe the main activities to be done before each milestone. All participants should contribute to a complete list, including discussion of alternative approaches. Describe the deliveries from each main activity – ensuring best value for the recipient. Write a post-it for each main activity and place it to the left of the milestone – in sequence, if there is a workflow.

Then, move each main activity to the level of the discipline in charge and mark the leader role.

Step 4:

Extend the main activity to participating disciplines. Place a copy of the post-it on the level of each participating discipline.

Place post-it notes with participants in milestone review and in milestone decision.

Opens in a new window.

Opens in a new window.

Step 5:

Planning the methods. Describe how to do each main activity in a simple and sure way. Find standard methods or use methods from other/previous projects. Improve and simplify the methods. Describe on post-it notes and place them at each main activity.

Step 6:

Planning the cooperation. Describe the way of working with each main activity on post-its and place them at the activity.

Step 7:

Re-evaluate the milestone dates. Some may be dictated externally and some are determined by the work and resource capacity.

Documenting the plan

It might be useful to describe the milestones using the milestone form. Describe the hearing and decision process for important decisions. Describe the quality control of deliverables/results. Describe the documentation from main activities, from the milestone, and of the state after the milestone.

The main activities may be described in the main activity form, which may be used as work basis for the leader of the activity.

The coordination and control schedule is documented in several ways:

• Form: Coordination and control schedule. Roles are also described in the form.

• Form: Milestone plan. Suitable for management overview.

• Gantt chart or, possibly, a network plan.

The network plan is for calculating the time schedule and for consequence analysis. It is a tool for the project planner and not for all participants. Use Gantt charts, activity lists and milestone plans.

Think of

Do not make the plan too detailed. Overview and milestones are important characteristics. See main activities as deliveries. The activity responsible persons should prepare detailed work plans for their work.

However, for estimating reasons, it may be useful to do some detailed planning – especially for identification of critical lines. Be critical about the first schedule:

• Try to reduce duration. Find critical activity chains and activities with long duration.

• Evaluate uncertainties and try to reduce them. Uncertain activities should be removed from the critical line.

• Choose a tight, but realistic duration for each main activity. Place buffer time before and at the end of a milestone.

Opens in a new window.

Opens in a new window.

Opens in a new window.

The idea is to stick to the plan as long as the uncertainties are only possible variations and difficult to estimate. The rolling and detailed work planning should aim at keeping the milestone dates. Do not change the plan, but show the deviations until a rescheduling is needed. Consider and prepare plan B.

Opens in a new window.

References

• C.3 Tool sheet: Project structure

C.7. Tool Sheet: Planning Workshop

Opens in a new window.

What

Planning should be done through an intensive effort – in a short time and with mental concentration to ensure a holistic and coherent plan, e.g., a planning workshop. A one-day workshop may correspond to two to four weeks of planning via two-hour meetings.

It will give the project a flying start. An intensive planning work has quality and provides speed to the project – see Figure C36.

Opens in a new window.

Figure C36.

The Active Project Start.

Use – Where and When

The planning workshop is used at the project beginning for preparing the approach, the first project plan and, possibly, for preparing the concept development phase. Workshops are repeated at the beginning of development/engineering and construction/implementation phases.

The theme is planning and organizing, and not the actual execution of project work. But it is, of course, necessary to consider some technical aspects in the project.

Method

A planning workshop may last one to two days, full-time and working in a project room. The agenda may be as shown here – related to the planning model in tool sheet C.1:

Workshop, part one

1. Project background and mission. Project owner’s introduction

2. Interested parties

3. Project environment

4. Project goal and scope

5. Approach. Work paths. Major milestones

6. Agreement on leader and planning team for each work path.

   For a period of time until the second part of the workshop, the planning teams prepare milestone plans for each work path and estimate duration, resource effort and cost. Interfaces to the other work paths are identified.

   Workshop, part two

7. Plan. Coordination and control schedule

8. Responsibilities, communication, and cooperation also with interested parties

9. Resources and cost

10. Points of special attention

11. Management/control procedures

12. Anchoring the plan

13. Finishing the plan – actions.

A planning workshop may develop the cooperation and culture in the project team. To be together and create common results are stimulating. There should be room and time for social contact to strengthen the team spirit. The agenda may be extended with activities promoting cooperation and work culture:

• The participants learn about each other.

• The participants present their knowledge and competencies

• Work culture (team behavior) is discussed.

• Team values and project image are discussed.

• Motivation conditions are discussed.

• The participants plan their personal benefit from the project.

The project owner and other managers should attend the workshop when relevant. They should state their understanding of the project and the project priority. However, they should also acquire a better understanding of the conditions for the project and the approach.

The above agenda is general – the content of a workshop depends on when it is arranged in the project course. At the beginning of concept development, the agenda may include: background and basis, interested parties, environment, project scope, plan, project organization in the concept phase, and points of special attention.

At the beginning of the construction and implementation phase, the agenda may include: interested parties, environment, change process, approach and plan, responsibilities and effort, cost, points of special attention, control.

The project plan is not completed in the workshop. There is work before and after. Work before is:

• Information to participants about agenda and expected results

• Preparation of material, search for useful information. The participants should prepare their contribution.

• The work after is:

• Documentation of the plan

• Search for information, check of data

• Resource agreements.

Use the walls in the project room and get someone to take notes from the discussions.

Think of

The workshop may be arranged as common work when the team is small (five to six persons). As regards larger teams, it is advisable to split into smaller task forces during the workshop session. Each task force has a limited task and coordination is treated in plenum during the day.

Explain the expected output from the workshop. Illustrate plans and documents. Use the workshop for training in efficient project work.

Customers and suppliers may participate in the workshop, part of the time. Be aware of potential conflicting interests and demonstrate professional project management.

C.8. Tool Sheet: Agile Project Management

What

The general Agile project management concept focuses on delivering actual value to users and the project owner. This means that the project should adapt in an Agile and flexible way to learning during the project, and to changes in users’ requirements. The project should be able to change direction, when it meets challenges, new opportunities or new conditions. Agile also means avoiding nonvalue-creating activities. It is important to understand that the Agile approach and adaptation to changing requirements – also in the implementation phase – build on an adaptable product.

Our view of Agile project management combines principles and concepts from both Agile and Lean management and builds on seven principles:

• Concerning the product

  Value and quality

  Topicality.

• Concerning the process

  Direction and coherence

  Users on board

  Flow and speed

  Competent and empowered organization

  Simplification and improvement.

Use – Where and When

Agile project management is an overall approach to the project and characterizes the approach and the project and product structure. A number of methods and means are described below. It is a catalog rather than a complete Agile project management recipe.

Method

Methods and means are described briefly. Use the references for more detailed explanation.

Principle: Value and Quality

Genuine insight in users’ world. Some team members are responsible for focusing on the customer’s/user’s need and values. They should experience the customer’s world and transform this insight into an integrated product vision and specific values and requirements. They should communicate and keep these goals during the project.

Holistic view. See the product, its use and effects as a whole. Describe and visualize through various means:

• Vision/metaphor. A picture of or storytelling about the expected future shows the direction. The picture visualizes the future with the project product – a scenario. Storytelling describes the scenario as a story, e.g., how the system/product will be used. It is a challenge to describe the scenario without product details, but only by its functions and properties. The product picture is to be detailed during the project.

• Product brochure: A dummy brochure, advertisement or newspaper article about the new product and its properties. Shows the direction and elucidates the most important properties and the success criteria.

• Actor goal list: Summary of the users and their use situations (with product functions) in the product life cycle.

• Quality function deployment: Matrix showing the connections between interested parties, functions and properties and product modules (see tool sheet G.18).

• Product feature list: Prioritized list of product properties (features).

• Project data one-page: The project described in one A4 page to highlight goals and limits.

Adaptable product: The product can be changed during the development and implementation – and later in use/operations. Changes may be functions and features, structure, user interface, etc., within some limits and at reasonable cost.

Exploratory 360 degrees: Analysis of the project sustainability – value, requirements, limitations, scope, technology, plan, organization, approach, methods.

Control the product features: Controlling product functions and properties is an essential element in Agile project management – ensuring focus on value for users in the product value chain.

• Feature specs: A page for each feature: feature identification (name), description, interfaces/connections to other features, approval test, the degree of new development, uncertainties.

• Find the marginal value of features: Most customers/users will be satisfied with a basic set of features – plus a few extra. If the number of features is increased and the product cost and price are higher, fewer customers will buy. If the number of features is below the basic set and the price is lower too, fewer customers will buy. Find the optimal set of features – in the product as a whole and in product versions to market segments.

• Test for superfluous features: A property/feature is probably superfluous if it does not lead to higher price and larger sales volume.

• MoSCoW priorities: The properties/features are prioritized in categories: must, should, could, will not (see text box).

• PDE priorities: The properties/features are prioritized in categories: Positioning properties give the product distinct character and competitive advantages, great value. Duty properties must be in the product to make it attractive and competitive. However, these properties do not add value if they are better than competing products. Properties expected by users are of value to the customer and influence their satisfaction, but may be adjusted in the light of cost and value.

Focus on quality. There may be several important and critical quality elements in the product, requiring attention. A couple of means for focusing on quality are:

• Performance requirement specification: A note for each performance requirement: identification, requirement, approval test, degree of difficulty.

• Test of unnecessary complexity: The simple solution with focus on the customer/user and with user-friendly interface is the most economical. The test is a critical review with simplification and improvement ideas.

Principle: Topicality

Topicality has two aspects. One is to deliver what is valuable for the customer now, and wait until later to address future needs or wait for a more mature customer. This is related to the competition – actuality means to be ahead of or in line with competitors. The second aspect is preparation for future demands – create preparedness, be ready, analyze opportunities. Property structure and product architecture are some of the means.

Product feature list: See above.

Product architecture: A picture of the product structure and arrangement will guide the design, allowing changes for reasonable cost. The picture should show the actual architecture and the planned future architecture, and is redesigned at each design decision.

Deliver frequently and fast – the pull principle: Agility and speed mean delivery of useful product/solution frequently and fast – as versions with more and more properties or as functioning modules. But iterations and prototypes are also deliveries – temporary versions for test and improvement in dialog with a limited number of users. The pull principle is often seen as the user’s request for priority, but remember that development often requires that the users are being inspired to see new ideas.

Step-wise implementation: Develop the product structure and the project for step-wise implementation. Deliver the most useful properties now – the rest should wait until they are needed. Implement structures to counter uncertainty and risk, and to ease adaptability.

Prioritize properties and modules: The users should decide the priority of modules and versions.

Delivery plan: The delivery plan may be time boxes and milestones. Re-planning is done at the end of each step.

Early victory: Easy solutions may be delivered first as it is motivating for the project team and for the users.

Consider uncertainties: Identify external and internal uncertainties and arrange for maneuverability and for ensuring value. Arrange for preparedness.

Model and prototype: Visualization, models, and prototypes as early as possible will ensure understanding and are cheap means for testing usability and sustainability.

Principle: Direction and coherence

A challenge for the step-wise and modular development and delivery is to ensure a “whole product.” One principle is to embrace change, meaning that the product should be rebuilt when it is too complicated and difficult to handle. But planning and concept design should be used when the future is visible. The project manager should pay attention to the environment and arrange for product changes when the future is opaque.

Holistic orientation: People, processes, and technology should be a whole. It may be ensured through competent participants, processes that utilize the competencies and solution-oriented technology.

Concept development first: Begin with a concept development phase resulting in the first product concept, the first architecture and basis for a first step-wise delivery plan. The concept is adjusted during the project.

Product architecture: A picture of the product structure and arrangement – the best possible solution at any time and redesigned when new modules are decided on. Guides the solution to be changed at reasonable cost.

Rolling planning: Initial plan with vision, goals, approach and the first milestone plan, followed by step-wise adjustments and detailing of the plan.

Simple design: Aim at a simple product design prepared for future extensions and changes. New modules are integrated with the main module to ensure coherence.

Principle: Users on board

Users on board is an essential element of Agile project management. The developers’ direct insight in the users’ world and their dialog with the users should inspire innovation and inspire the users to see new ideas. Close dialog and frequent tests should ensure actual utility and quality (usability).

Analysis of interested parties: Identification of interested parties and their needs. Use the information to engage the important parties and to control expectations. (See tool sheet B.2).

Genuine insight in the customers’ world: Some participants in the project team should focus on the users’/customers’ need and values. They should experience the customers’ world and transform this insight into an integrated product vision and specific values and requirements. They should communicate and keep these goals during the project.

Dialog between user and developer:

• Daily dialog: At least one real systems/product user should participate in the project team, ready to answer questions and to participate in test. The alternative is a fast and direct access to users. The users in the project team may write specs and arrange test and write manuals.

• Dialog with customer/user: Organize the dialog with customers and users. It should be clear who is in charge of: the product vision, the feature list and specs, prioritization of properties, specification of performance requirements, and acceptance of properties and performance.

• Focus groups: Use focus groups for the tasks above to ensure broad representation of users.

Model and prototype: Visualization, models, and prototypes as early as possible ensure that the participants understand solutions. They are means to test usability and sustainability.

Principle: Flow and speed

Flow and continuity are means to achieve speed and quality and to minimize nonvalue-creating activity. The key is to see and arrange the process, to structure into parallel paths and to arrange the activity sequence. Process management is an essential function in Agile management of projects. A supplementary key is to “pave the road” – to prepare the activities in the near future and to ensure no-stop.

Value stream mapping: Is a method for diagraming and describing activity flow, and critical analyzing and improving the flow.

Arrange flow: Principles for arranging an activity flow with value, continuity, and speed are:

• Identify value-adding and nonvalue-adding activities in the work paths. Nonvalue-adding activities are classified as “necessary under the actual circumstances” or “unnecessary.” Remove nonvalue-adding activities – improve the conditions. Simplify the value adding activities.

• Arrange activity chains in each work path. Arrange deliveries in each path. Synchronize the flow via milestones. Create an even flow – consider activity sequence and connection. An uneven flow creates uneven resource load and failures from business and hurry.

• Control resource bottlenecks (constraints). Avoid overload as it leads to failures, risk and waiting time. Find ways to increase capacity and speed.

• Create a rhythm (eventual cyclic rhythm) and synchronize across work paths and participants. Arrange smooth transfer from person to person (or group to group), so that the person next in line actively is receiving like in a relay race.

Plan for speed: Methods and means of speed in the approach and in the management of the project work.

• Frontloading: There may be more problems to investigate, more alternative solutions to examine and some “may-be” solutions as well. Sequentially working on one thing at the time has long duration and may be costly because of rework. Parallel work (frontloading) is preferable. Frontloading is important in the concept development phase, because there are more degrees of freedom and the possibility for creating optimal holistic solutions. Use analysis of uncertainty and pictures of the uncertainty to identify problems to be clarified early. Identify modules and components that should be designed correctly to avoid waste in subsequent processes. Use “value of shorter time to profit” and “cost of time to profit” as arguments for speeding up. This method may seem to collide with the iterative method – but iterations are steps in a work path: requirement specs, research, models, prototypes and modules on the path to a sustainable solution.

• Set-based concurrent engineering: Find and evaluate alternative solutions to problems, functions and components before selecting a solution. Analyze the alternatives in parallel instead of one-by-one (point-based) to gain time. The analysis of alternative solutions should encompass modular sets and their connections – to avoid later lacks of coherence and components not fitting in. Use “trade-off” evaluations (weighted criteria, checklists, diagrams, life-cycle economy) of the different solutions’ fulfillment of requirements and of advantages and disadvantages. The analysis should be based on the “design for X” principle – considering all life-cycle situations and the needs from all interested parties in the value chain. The analysis and especially the evaluation should be organized across disciplines and across the organization. Important interested parties should participate.

• Identify activities with long duration: Find means to reduce duration, e.g., by changing the product. Split into step-wise delivery.

• Focus on critical activities: Direct attention to the chains and clusters of activities defining the total duration or representing the largest risk of delaying the project. Direct attention to critical resources being bottlenecks or being used in more projects at the same time.

• Step-wise specification: Plan overlapping activities, e.g., building prototypes along with design/engineering.

• Parallel development activities: Parallel work on more product elements instead of sequential work.

• Remove delaying approvals: Reduce formal approvals to a minimum. Organize continuous quality assurance as dialogs between project team and users.

• Forward-oriented review: Review and critique of already created solutions usually lead to rework. Use the effort on forward-oriented preparation of design activities, e.g., ensuring list of all relevant requirements, list of points of attention, evaluation of alternative solution concepts.

• Pre-information and overlap: Do not postpone sending all documents and information to the next person/group in the activity chain until your activity is completed. Send information elements and design elements as soon as they are ready – allowing the next person to begin to work earlier. But remember to tell about uncertainties.

• Buffer for uncertainties: Place time buffers in front of important milestones, based on an evaluation of uncertainties and risk of delay in the preceding activity chain.

Arrange the plan as a delivery plan: The project approach is often arranged from a phase model where all phase activities are completed before the next phase starts. But project products can be structured in modules and projects have more work paths. This means that the approach can be arranged as a number of deliveries – at least after defining the solutions concept. The plan is a number of product deliveries, e.g., in versions and modules. Progress is measured as delivery of usable modules and product versions. In between, there may be iterations and prototypes. The iterations may be research for more information or for inspiration, working on more possibilities in parallel (ref. frontloading).

Time box principle: A rhythmic approach with fixed time intervals for delivery, called time boxes. See textbox and Schwaber & Sutherland (2016) for an introduction to Scrum.

Milestone principle: An approach with a sequence of milestones in each work path. Well-defined situations in the project, typically a delivery. The duration between the milestones is defined by the amount of work, the resources, and the process. See tool sheet C.6.

Plan in three levels: The overall plan is a milestone plan for each work path. The next level is a rolling delivery plan with a 2- to 6-month horizon. The lowest level is a work plan for the coming two to four weeks.

Paving the road: Prepare the activities to be started in the coming weeks. They should be “healthy activities.”

Focus on the job: Rules for concentrating on the job. Activities should be healthy before start. Remove interruptions and noise. Work in peace and with a work rhythm. For part-time team members: work concentrated at least half a day at a time and preferably one to two days in sequence.

Daily team meeting: Daily coordination and planning meeting with focus on common issues. Agenda: Work done (finished) yesterday; work to do today; problems requiring help. Stand-up meeting for 10–15 minutes. Documentation on the wall in the project room. Update activity list and issue list.

Visual status: Plan, issues, important problems, etc., are visible for everyone on the wall. Use colors and symbols to show priorities and points of attention.

Progress curve, burn chart: Project progress is visualized graphically.

Control the use of capacity to ensure availability and intensive effort.

• Intensive resource effort: Project manager and members of the core teamwork full-time. Participants working part-time are working in concentrated periods, at least two to three days in sequence.

• Capacity plan: Agreed plan for work effort from each participant to ensure delivery milestones.

• Capacity reservation: Resources being bottlenecks (scarce capacity) should reserve capacity in due time. The project manager should ensure no delays of their work basis.

Delphi estimation: Method for estimating resource effort to activities and deliveries. More persons contribute individual estimates. At first, describe and estimate the size of the task, find dimensioning elements and conditions influencing the resource effort. Evaluate competency and experience of the people doing the job. Estimate the number of working days/hours needed. Discuss uncertainties derived from the differences between the individual estimates.

Here-and-now decisions: Instead of meetings in the steering committee or with the project owner with several weeks interval, the deciding managers meet in the project room for here-and-now decisions. If a manager cannot attend, he will be contacted beforehand for a statement. Problems to be cleared with individual managers are handled here and now. Core team members should participate in these short meetings to gain insight and know-how, enabling them to make decisions in the core team instead of in the steering committee. This is called empowering the team.

Principle: Competent and empowered project team

Agility is easier when the project core team can decide – presuming agreement from key interested parties, steering committee, and project owner, of course. This is a question of delegating and of empowering the core team and trusting the team – provided that the team deserves trust. A team will gain trust and authority when it acts in a competent way. Competency is developed via dialog with managers – giving relevant and actual decision information, talking about considerations and thoughts and giving reasons for attitudes.

Genuine insight in customer’s world: See above.

Experience from next actor’s world: Developers should have direct insight in the subsequent processes/activities in the activity chain and meet the actors (participants) there. For example, building architects should see the building constructor’s world or the component prefabrication world. We call it imposed thinking and imposed knowledge – making deliverables correct and easy for next actor. Organize multidisciplinary project groups and cross-organizational groups. See tool sheet G.19.

Specializing and coherence: Focus on the project and product whole – connections and interfaces between modules, technologies, functions, etc. Arrange communication between the participants and develop their sense of responsibility for coherence.

Competent participants: Allocate people with knowledge and skills, and outgoing people, willing to assure quality of own work – and capable of making decisions. Arrange development of their competency.

Competency-gap analysis: Prepare a list of necessary competencies and actual competencies in the organization. Identify missing competencies and act. Competency ensures quality. Quality assurance before decision: The project manager and the project team will make decisions and should ensure quality and acceptance beforehand. Explore and test at important interested parties.

Coaching, mentoring and team development: Organize mutual sparring and support the development of competency and cooperation in the project team. Use mentor, coach, sparring, working in pairs, time-out for reflection and learning.

Co-management: Managers support project manager and team members in decision situations and in meetings with interested parties – to develop competency and independence. Another group of means relate to the cooperation in the project team, aiming at creating value, quality, topicality, and speed.

Shared ownership: All group members take responsibility for the product whole and act proactively.

Personal safety: Rules should create openness about lack of knowledge and about failures. You are allowed to say: I miss information to do this job; I do not understand the job; I do not feel competent; I need help; I made a mistake and want to correct it.

Co-decisions: Decision processes ensuring relevant participants in decisions and developing participants’ insight.

Osmotic communication: Daily direct communication between team members and with the user/customer based on self-coordination. A project room is preferred. Important documents and visualizations are on the wall (being an information radiator). The room is arranged for natural communication and with the possibility of calling for advice and assistance and for working in smaller groups (pairs). Conversations may be heard from other members because it spreads information, draws attention to problems and opens up the possibility of contributions from others.

Common project planning: Members of the core team participate in arranging the approach, structuring into work paths and delivery plan.

Daily team meeting: See above.

Reflective improvement: Time-out meetings for reflection on approach, methods, and performance. Questions: What went well – how do we continue like that? What could be better – how?

Principle: Simplification and improvement

Standardization: Standardization encourages re-use, reduces variations causing uncertainty, and ensures predictable results. Design standards include product platform, architecture, modularization, components and form elements. Process standards include methods and instructions, activity chains, test, specifications, etc. Use standardized workflow and methods to achieve simplicity through re-use and to ensure correct deliveries to subsequent actors and processes. Use templates and models adjusted to the type of development task, instead of only one model. Use common toolbox, defined concepts and terms to ensure common reference basis. Competency standard includes skills and abilities in the team and ensures trust when tasks are delegated.

Adapt technology to organization and processes: Technologies should be integrated in a qualified way. Technologies should support processes – not drive processes. Change of technology leading to change of process is costly. Technology should help the developers – not replace them. Technology should be used in more projects and products. The better technology is often the enemy of the good technology – choose a sufficient level of ambition.

Focus on the simple and good – especially avoiding nonvalue-adding activity in subsequent processes and in product use and operation.

• Use standards and best practice: Do not develop when there is no value. Re-use known and tested solutions, methods and work processes.

• Review and test. Frequent technical reviews and test to ensure best design, usability, and sustainability.

• Simple design: Aim at simple design, prepared for future extensions and adaptations.

• Refactoring: The product architecture/structure is re-evaluated at each extension with new features – aiming at simplification. Simplify when there are good arguments for a better product – even if it means rework.

Simple and sufficient control methods – Avoid bureaucracy, exert forward-oriented management and minimize backward-oriented follow-up and reporting.

• Simple set of plans: Overall plan. Release plan. Iteration and prototype plan. List of risks and uncertainties plus actions. List of issues.

• Simple project control: Weight on scoping, forward-oriented management, delegation of tasks and responsibility, self-coordination and deviation report.

• Methodology shaping: Initial arrangement of methods and conventions for the team and cooperation with users.

• Issue management: Focus on actual problems – and fast reaction and assignment of responsibility for solution. Method for description of problem and problem solution (see tool sheet G.4).

Project room: Arrange a project room or create a virtual room to achieve close communication and information for the participants. Visualize by using the walls for documentation of work and control.

Efficient work meetings: Short meetings – only one to two items on the agenda, preparation before the meeting, only include involved participants at the meeting, nonrelevant issues are parked for later action, complete with clear decision and action plan.

Learning and improvement of the process:

• KPI (key performance indicator) as a driving force: Use performance goals and visualization of the performance as a driving force for improvement of processes, methods, and performance.

• Time-out, reflection workshop: Frequent time-out meetings for reflecting on approach, performance, methods, and progress.

• Value-added scorecard: List typical types of waste in the project and note the important types on a scorecard. Discuss them at a reflection workshop and decide on improving actions. Waste may be: wasted time in meetings, waiting for delayed deliveries, defects in deliveries and unnecessary interruptions.

References

• In this tool sheet we have drawn on the following references:

• Beck, K. (2000). Extreme Programming Explained. Addison-Wesley.

• Charette, R. N. (2003). Challenging the Fundamental Notions of Software Development. Cutter Consortium, Executive report vol. 4, No. 6.

• Chin, G. (2004). Agile Project Management. Amacom, USA.

• Cockburn, A. (2005). Crystal Clear. Addison-Wesley.

• Highsmith, J. (2004). Agile Project Management. Addison-Wesley.

• Larman, C. (2004). Agile & Iterative Development. Addison-Wesley.

• Manifesto for Agile Software Development (2001). Retrieved from http://agilemanifesto.org

• Mascitelli, R. (2002). Building a Project-Driven Enterprise. Technology Perspectives, California.

• Mikkelsen, H. & Riis, J. O. (2006). Agile Company Development (in Danish). Center for Industrial Production, Aalborg University.

• Morgan, J. M. & Liker, J. K. (2006). The Toyota Product Development System. Productivity Press.

• Poppendieck, M. & Poppendieck, T. (2006). Implementing Lean Software Development. Addison-Wesley.

• Schwaber, K. & Sutherland, J. (2016). The Scrum Guide. Retrieved from http://www.scrumguides.org

• Womack, L. & Jones, D. (1996). Lean Thinking. Simon and Schuster.