Appendix G: Project Control

Hans Mikkelsen (PRODEVO Consulting, Aalborg University, Denmark)
Jens O. Riis (Aalborg University, Denmark)

Project Management

ISBN: 978-1-78714-830-7, eISBN: 978-1-78714-829-1

Publication date: 10 October 2017

Citation

Mikkelsen, H. and Riis, J.O. (2017), "Appendix G: Project Control", Project Management, Emerald Publishing Limited, Leeds, pp. 669-777. https://doi.org/10.1108/978-1-78714-829-120171023

Publisher

:

Emerald Publishing Limited

Copyright © 2017 Emerald Publishing Limited


G.1. Tool Sheet: Activity and Time Control

What

Project work is controlled by activity plans that are time schedules as well. They include master plans, phase plans, and work plans. This tool sheet describes a number of principles and methods for work planning and scheduling as a supplement to tool sheet C.6. Furthermore, it describes short-term rolling work planning.

Use – Where and When

Work plan and time schedule are used in all project phases.

Method

Activity Planning

Planning project activities has its roots in the milestone planning of main activities in tool sheet C.6. The idea is not to carry out too detailed long-term planning, as uncertainties may change the plan.

Rolling Work Planning

In the short term, main activities are broken down into work plans for each milestone and for as far a time period as possible. The horizon is guided by available knowledge and necessary preparation time. This includes providing materials, equipment, resources, work information, and documentation. The preparation horizon may be weeks or months. Short-term planning consists of three elements:

  • Necessary detailing of plan to ensure that everything is considered.

  • “Paving the road” – arranging all conditions and prerequisites for the work.

  • Starting activities in due time.

The rhythm for rolling planning for each milestone may be as follows: planning workshop – weekly meetings – milestone meeting. The beginning is a planning workshop for all work to be carried out until the milestone. Participants are all actors in the main activities leading to the milestone. The main activities should be broken down into deliverables and activities, activity sequence and time schedule (week plan) should be arranged and cooperation organized.

A rule of thumb for detailing work plans is: An activity is one week’s work to be done in one week and no longer than two weeks, making it possible to control. Describe the expected output from the activity, and let the workers do further planning as they find necessary.

Work plans can be illustrated as activity lists – see work plan form in Figure G1. Avoid using minutes of meeting as a work plan. List all agreed activities in a separate work plan (arranged by milestone and main activity), and let the minutes of meeting refer to that. The work plan is a living document where new activities are added and activities are marked as finished. If you add comments in the plan, it will be a logbook for each milestone.

Figure G1. 
Work Plan Form.

Figure G1.

Work Plan Form.

It is recommended to arrange a project room or at least a billboard – see Figure G2. The activities may be small descriptive cards (post-its), placed along the time line.

Figure G2. 
Example of Project Planning Billboard.

Figure G2.

Example of Project Planning Billboard.

Work is controlled via a weekly steering meeting – see text box. In the small project team, all members will participate. In the larger project, the core team will participate.

Core Team Steering Meeting

A steering meeting is held once a week (not later than Thursday). Agenda:

  • Check that this week’s activities will be finished. Remaining work is transferred to the next week – or later if there are problems.

  • Check that next week’s activities (week 1) will be completed.

  • New points of attention (issues).

  • Next two weeks’ actions, from the list “actions to the points of attention,” are transferred to the work plan.

  • Walk through the work plan for the following two weeks (weeks 2 and 3). List preparatory actions, necessary ahead of the activities in weeks 2 and 3 (making the activities healthy).

  • Work plan for next week – ensuring healthy activities.

  • Look for activities planned for weeks 4 and 5, which require preparatory action already next week.

The agenda for the meeting is built up successively. The participants note items on the billboard or on a website.

Participants prepare before the meeting – reading available documents and notes. Items are presented briefly at the meeting.

No lengthy problem discussion at the meeting – go for decisions. Problems with no immediate solution will be solved by the involved parties later on. Decisions – also those made after the meeting – are noted on the billboard.

Use the principles for “the healthy activity” at the preparation (paving the road) of activities in week 2 and later:

  • Work basis should be ready. Will preceding activities deliver results as planned and in correct quality?

  • Materials for the activity should be ready.

  • Work place should be ready and arranged as prescribed.

  • Equipment should be available and ready.

  • People should be ready and have the necessary capacities.

  • Instructions, methods, rules and other information should be ready. People should be informed.

  • The external conditions should be clear – as far as possible (e.g., weather, permission, admission). Are there alternative plans?

If the work is intensive with substantial progress every day, it might be useful to have daily morning meetings. See text box.

Daily Morning Meeting

In the small project team working intensively, the daily morning meeting is arranged in the project room in front of the planning billboard.

Agenda:

  • Work status – Done yesterday? Remaining from yesterday?

  • New tasks.

  • What should be finished today and tomorrow?

  • Problems, issues and hindrances today?

  • Who needs assistance for what? Who will help?

  • Decisions about methods and solutions for today.

The morning meeting is a stand-up meeting. Duration: 10–15 minutes. Documentation on the billboard or flip-over (post-it notes). Update activity list and issue list.

The milestone meeting:

  • Check deliverables, quantity, and quality.

  • Check if conditions have changed.

  • Agree on rectifying defects and missing deliverables.

  • Revision of time schedule.

Think About

The work plan and time schedule can be seen as an agreement. It is expected that the participants will act in accordance with the plan. But this does not always mean that they will take action as expected. It is often necessary to start new activities formally at the weekly steering meetings.

In technical and systems development work, the list of activities will often be a list of components to be designed, specified, ordered and manufactured.

Characteristics of the Good Work Plan and Time Schedule:

Content

  • Is complete – with all work paths.

  • Is arranged with activity levels.

  • Has well-defined activities/tasks.

  • Has milestones and decision points.

  • Shows connections/dependencies, sequence, priorities – also between work paths.

  • Shows critical activities in the time schedule.

  • Shows uncertain activities and bottlenecks.

  • Shows responsibilities.

  • Is flexible – with alternatives and consequences.

  • Describes preconditions.

  • Has points for progress measurement.

Preconditions

  • Is based on thought-through approach.

  • Is based on realistic methods.

  • Is based on realistic resource allocation.

  • Provides good resource utilization – normal workload.

Scheduling

Time planning is basically to define dates for milestones and for the start and finish of main activities. “Date” may be a target, an expectation or an agreement (commitment). Time planning requires a planned duration for each activity. Figure G3 shows different types of activities – each with their possibility for controlling duration. In some cases, it is not possible to influence duration. When duration depends on resource effort, you should calculate with available resource effort.

Figure G3. 
Conditions Determining Activity Duration.

Figure G3.

Conditions Determining Activity Duration.

Sometimes, we experience that the planned activity duration is too short – and we argue that we underestimated the amount of work, had unrealistic expectations to resource effort, or expected too favorable work conditions. On the contrary, the planned duration is often too long – because we expect the resource effort to be spread over time due to multi-tasking, or because we dare not promise shorter time, or because the persons responsible for the activity and the project manager both add a risk margin to the estimated duration. However, we do not discover that there is plenty of time, because work has a tendency to fill the planned time – plus a little more. Our experience therefore is that we need more time.

Some advice:

  • Use three estimates as explained in Figure G4 and deliberately choose a relatively short duration.

  • Do not add buffer time to each activity, because it will be used. Instead, aim at finishing the last activities some time before the milestone – i.e. the buffer time is placed just before the milestone.

  • Avoid planning to finish many activities just before the milestone. There is always a risk that some of them will be delayed.

  • Find the critical timeline – that is the chain of activities determining necessary time to the next milestone.

  • Observe “nearly critical activities.” They might be critical if they are delayed.

Figure G4. 
Estimating Activity Duration – Three Estimates.

Figure G4.

Estimating Activity Duration – Three Estimates.

Critical Chain

Critical chain is a time planning method, based on principles similar to the above mentioned. The principles are:

  • The classic PERT planning method uses the concept “the (time) critical line,” which is the continuous chain of activities determining the time duration of the project or part of the project. The “critical chain” concept adds the consideration of bottleneck resources. Figure G5 illustrates how.

  • Plan with short activity durations in the activity chain – often corresponding to 50 per cent probability. Place a buffer in front of the milestone. The buffer duration might be half the sum of the entire chain duration.

  • Start critical activities as early as possible, or at least on the planned start date. Therefore, they should be protected against delay from preceding activities. Add a feeding buffer.

  • Scarce resources (bottlenecks) are protected by a capacity buffer, to be used if necessary, such as overtime or extra resources.

  • Bottleneck resources should only work on one project at a time.

  • Activities are always started as soon as possible – not waiting until planned start.

  • Follow-up is to determine if the activities will be finished as planned – asking for estimated time to completion. Delay is regarded as “used from the buffer.” No reaction when the first third is used; when the second third has been used: action to rectify; and when the last third has been used: change plan. This principle is called “buffer management.”

Figure G5. 
Principles of the Critical Chain Method.

Figure G5.

Principles of the Critical Chain Method.

Practical Tools

Gantt Chart

The Gantt chart is a graphical technique for scheduling and following up on work progress. It was developed by R. Taylor’s colleague, Henry L. Gantt (1861–1919). The chart is widely used for scheduling and suited for that. It provides a visual overview of activities, their duration and the entire plan. It is suited for the coordination and control schedule and for detailed plans at the next level (detailing main activities).

The principle is illustrated in Figure G6. The vertical axis is the work paths. The horizontal axis shows the calendar line – and milestones and (main) activities. The degree of detail is to be decided. Activities are drawn as a line from planned start date to planned finish date. It is also possible to show the available calendar time. Typical elements (symbols) for hand-drawn charts and spreadsheet charts are shown in Figure G7.

Figure G6. 
Principles for Time Schedules in Gantt Charts.

Figure G6.

Principles for Time Schedules in Gantt Charts.

Figure G7. 
Elements in a Gantt Chart.

Figure G7.

Elements in a Gantt Chart.

There are several practical versions of Gantt charts:

  • The chart only shows work paths and milestones.

  • The chart only shows time span for activities. That means from earliest start to latest finish.

  • The activity line shows planned start to planned finish. More time available is illustrated with another symbol.

  • The activity line can indicate planned amount of work (performance) – with varied distribution over the planned duration (see Figure G7). Figures over the line indicate planned accumulated activity amount at the end of each time period.

Figure G8 shows a good and typical illustration of a plan, with many activities of the same type.

Figure G8. 
Example of a Master Plan as a Gantt Chart.

Figure G8.

Example of a Master Plan as a Gantt Chart.

Gantt charts are simple, and the graphical visualization makes it easy to focus on the most actual activities right now. The chart is well suited for follow-up. A weakness is that the chart does not show dependencies between activities. It is not suited for analyzing alternative approaches and effects of delay. It is difficult getting a quick overview, when there are many activities – unless you arrange it with plan levels.

IT-based project planning systems all have a Gantt chart module, with appropriate symbols and editing functions.

Cyclogram

The cyclogram is a graphical visualization of workflow in space and time. The work plan is drawn in a system of co-ordinates, where the x-axis is time and the y-axis is place. The activities are sloping lines – from start date to finish date and from start place to finish place (see Figure G9).

Figure G9. 
Example of a Cyclogram.

Figure G9.

Example of a Cyclogram.

The diagram is useful for visualizing plans, where the same activity is repeated in different geographical locations – typical fitting rooms in a building. It shows the sequence and illustrates collisions between activities.

When Scheduling is Very Uncertain

Traditional methods for scheduling presupposes a determined duration of each activity, and thereby an expected/planned date for milestones. However, activity duration is often uncertain. Therefore, it is more interesting to find the time interval for expected project completion, and the probability distribution for the end date. There are some methods for time planning when it is difficult to estimate activity duration. They require IT programs, and their need for input data is troublesome to fulfill. They should be reserved for projects with substantial need for analysis of uncertainties and countermeasures.

The PERT method has its origin in the childhood of project management. Activities are arranged in a network, representing sequences in the entire approach. For each activity, three durations are estimated: shortest thinkable duration (optimistic situation); longest thinkable duration (pessimistic situation); most probable duration (normal situation). The network is analyzed several times with randomly selected durations for the activities – based on a chosen distribution model and within the range. The result is a time interval for completion and a distribution curve showing the probability.

Successive time planning (Lichtenberg, 2000) is a method, where the plan is detailed until a level where the uncertainty cannot be reduced by further detailing. The planning effort is minimized via focused effort on those activities contributing most to the uncertainty. Planning is stopped when uncertainty cannot be reduced through further planning. The activity network is supplemented by some “special activities” covering common uncertainty types (e.g., weather conditions, supplier reliability). Each plan analysis identifies those activities contributing most to the uncertainty in the chain. Those activities are planned more in detail – if possible – and a new analysis is carried out. When detailing of the most uncertain activity is not possible, or when the common uncertainties are dominating, the planning effort is stopped – until new information is available.

References

  • See planning in Method Sheet C.1.

  • Goldratt, E. M. (1997). Critical Chain. The North River Press USA.

  • Lichtenberg, S. (2000). Proactive Management of uncertainty using the successive principle. Polyteknisk Press.

G.2. Tool sheet: Network Planning

What

In a network plan, activities are connected in activity chains via logical interdependencies. The idea is to calculate the duration for the entire chain – for a main activity, a phase or the whole project. This technique allows rapid calculation of consequences from delays in the network or from changes in the plan.

Network planning was developed in the USA in the 1950s and 1960s. One form is the PERT (program evaluation and review technique) system used for controlling large defence projects and space rocket projects. Another form is the CPM (critical path method) system developed by Du Pont for engineering/construction projects. There are more versions of these methods today, and most IT systems for project planning contain elements of these original systems.

Use – How and When

Network plans are useful as coordination and control schedules for a phase of the project – and especially for projects with well-defined dependencies between activities. That is projects with defined product/deliverables structure and defined process.

Method

Network planning used in the appropriate way has advantages compared to Gantt charts and activity lists:

  • The planner is forced to think through and analyze the whole project/phase. Sequence and dependencies between activities are expressed in a model, showing the approach and the cooperation between the involved persons/sub teams/parties.

  • The critical line reveals activities requiring special attention, because of their influence on the total duration. It is defined when activities can start at the earliest and should end at the latest, if they should not delay the whole project/phase/milestone. The activity slack points out activities requiring attention, and activities allowing adaptation to practical resource availability.

  • The method allows you to calculate the probability of finishing the project/phase before certain dates – including keeping milestone dates in between.

  • The first plan can be improved in a systematic way. Effort to reduce total duration is concentrated on activities in the critical line/chain. The consequence of changes in resource allocation can be analyzed.

Network planning supplements traditional planning methods, but does not replace them. The Gantt chart schedule builds upon the dependencies in the network plan. Most project managers prefer to view the plan in a Gantt chart format.

Illustration Methods

There are two graphical illustrations of network plans: process diagram and arrow diagram (see Figure G10). Both diagrams may be drawn with activities grouped in clusters (work path, system, organization etc.)

Figure G10. 
Example of Network Plans.

Figure G10.

Example of Network Plans.

The process diagram provides a simple illustration of the logical process and is therefore a preferred illustration. It uses two symbols: boxes and arrows. Boxes symbolize activities – with name and data written inside. The arrows symbolize sequence dependencies between activities.

Construction of Process Diagram

The network plan can be constructed from a list of activities by defining the sequences. Another way is to start with activities somewhere in the network and find necessary preceding and subsequent activities. For each activity ask:

  • Which activities must follow directly after?

  • Which activities are direct predecessors?

  • Which activities should be carried out in parallel?

The questions are repeated for each activity, until all activities are in the plan. It is important to define dependencies correctly. The sequence is often defined by logical and technical reasons, but there may also be resource-defined sequences. Some activities can for practical reasons not be carried out at the same time as they use the same place, same documentation, same facilities, etc.

To improve overview of big network plans, it is best to build sub-networks and connect them to a network on the next level. Rules for construction of network plan:

  • Coherent network. All activities are coupled with preceding and subsequent activities – except start and end activity.

  • In principle, an activity can only start when all preceding activities have been completed.

  • No loop. Activities should not be connected in a ring.

  • Overlap. In some situations, an activity can start some time before the preceding activity is finished. Split in two activities or define degree of overlap (see Figure G11).

  • Identification. Mark activities with numbers and names.

Figure G11. 
Rules for Activity Overlap.

Figure G11.

Rules for Activity Overlap.

Calculating the Schedule

Define the duration of each activity – the expected time for the work, e.g., indicated as days. The network can now be calculated and analyzed with outset in date 0. For each activity, the following is calculated:

  • Earliest start and finish time, Tts and Ttf

  • Latest start and finish time, Tss and Tsf.

Earliest start and finish time are calculated as the sum of activity durations in the activity chains – determined by the finish of the last activity in the chain. The start time is noted in the box – in the upper left corner. The finishing time is noted in the upper right corner (See Figure G12). This is the shortest duration and earliest time.

Figure G12. 
Time Calculation in Process Diagram.

Figure G12.

Time Calculation in Process Diagram.

From this calculated finishing time, we can calculate backward through the chains, and find the latest starting time and finishing time for each activity. Start time is noted in the bottom left corner and finishing time is noted in bottom right corner.

The calculations will show that some activities form a chain, which determines the total duration. Delaying any activity in this chain will delay the end date. This activity chain is called “the critical line.” Activities in other chains can be delayed within limits, without influencing the total duration. The limited delay time interval is called slack. There are three types of slack:

  • Total slack means that all precedent activities are done early and all following activities are done late.

  • Free slack means that precedent activities and following activities are done early.

  • Independent slack means that all precedent activities are done late and all following activities are done early.

The time line may be the real calendar time, or a relative line with (working) days from day one. Note that activities representing human work might be measured in working days, but other types of activity (e.g., hardening time for concrete) are measured as calendar days.

Analysis of the Network Plan

Sequence, overlap and duration are adjusted until the schedule is appropriate and realistic. Then it might be issued in a Gantt chart format. Typical edit forms are:

  • Activities in start order

  • Activities sorted by slack

  • Activities in finishing order

  • Activities sorted by responsible person/team.

G.3. Tool sheet: Project Info-Room

What

Use of electronic documentation and communication means is a matter of course in project work. The project info-room (website) is the common place for filing and finding information, and a communication center and a portal to other IT systems, used for project control and documentation. See Figure G13.

Figure G13. 
Project Info-Room.

Figure G13.

Project Info-Room.

Use – Where and When

The project info-room is established at the project start and is used throughout the project.

Method

The project info-room has four main functions:

  • The manual. Contains procedures to be used in project work, forms, work processes, experience data related to time and resources, etc. Standards used in all projects.

  • Management and cooperation. Contains information related to cooperation, communication, and coordination between the actors in the project, as well as management and control (planning, organizing, initiation, follow-up, correction). Here you find management information and gathered management experience.

  • Product specification. Contains product information and documentation from all development steps.

  • Social room. Is a place for social communication between the actors – sharing interests and getting to know each other.

  • Information to interested parties. Contains information about the project, solutions, and progress.

At first, the room may be seen as a document file with retrieving functions. But that is a narrow view. The effective room is a cooperation and communication room. There are several types of room that may also be seen as steps in technological development:

  1. Documentation place – with all information about the project.

  2. Communication place – where the actors communicate in writing, and where documentation is found.

  3. Cooperation place – where the actors work together on shared documentation, and communicate via video and talk over the Internet.

Type C is becoming popular as a development from a simple to a complex info-room. The technology should support some basic requirements:

  1. Flexibility – Projects have different requirements to size, facilities, integration to other systems, etc.

  2. Easiness – Effort and time needed to establish the room and to use it daily.

  3. Simple administration – To be used by the project actors without a web master or administrator.

Some advice on type B: Basically, documents may be arranged as in the project control file (see tool sheet C.2). The information should be linked to the project structure, and be accessible in different user situations. Ideally, information should only be filed in one place (no duplicates) to facilitate updating. Duplicates have a risk of not being identical. Some facilities are in the room. Other facilities are accessible via links from the room.

Systems available on the market all have a basic structure – a set of functionalities – which are adaptable to each project. A checklist for evaluation of suitability is presented in Figure G14.

Figure G14. 
Info-Room Facilities.

Figure G14.

Info-Room Facilities.

Perspectives

Globalization means that geographically scattered units and partners work on a joint project. This raises the need for communication means, allowing cooperation in a shared info-room. The simple way is to exchange information via documents and emails – one to one or one to many. The next step may be to establish a common information and communication room – a virtual team space where information is shared and accessible for all. There are several systems on the market, but their project control systems are often traditional. Some systems are so complex that they need to be operated by the project manager or a project planner receiving data from the actors.

New types of systems are on the way – project management 2.0 systems and methods. The aim is to go from communication to direct collaboration and co-creation. An attribute is to support the cooperation with a social side – to create a project team with team spirit, and to develop personal networks. The tools are simple and easy to learn. They typically handle four types of information: Activities (actions, deliverables, milestones); structured data (specifications in a database); unstructured data (letters, email, minutes of meetings, various documents, presentations); and communication data (issue and problem discussions, letters, chat, blogs).

Examples are blogs and wikis. A blog is a common communication place for many actors around a problem or an issue or a solution. People may be asked to contribute, but anyone having a useful contribution can deliver. Wiki is a technology to create websites and connect them. It gives more actors access to create a document with information that would otherwise be communicated in emails and other documents.

Collaboration planning tools are simple and are used by each person as work plan and progress report – linked into the plan hierarchy. These facilities could be integrated with an email system.

Maybe the most valuable function is that people in different geographical places can communicate directly, using shared pictures of specifications, products, plans, etc. Co-creation is possible almost like being in the same physical place. Illustration in 2D format is available and 3D format is on the way.

The systems have resource management facilities. Participants can set up competency and interest profiles, which may be updated continuously, e.g., via logging activities and deliverables in project work. It is possible to search for persons with special knowledge and skills – also outside of project participants.

Some systems offer special structuring facilities for project data, making it possible to create experience-based templates and experience data to be used in other projects. Related information search facilities are part of this.

Project management 2.0 systems are often offered as software as a service via the internet. They are accessible from any computer and iPhone.

G.4. Tool sheet: Issue Management

What

An issue is a problem that may cause a deviation from project goal or plan, a change of project scope or missing quality in the project product. The problem cannot be solved by one person, but requires effort and input from several persons.

Issue management ensures that issues are handled by the relevant participants, that the issue is visible to other persons, that handling is prioritized by the project manager, and that the issue is monitored and brought to final action.

Use – Where and When

Issue management is used in all project phases.

Method

Everybody can raise an issue. It is described in an issue form and registered on an issue list, cf. Figure G15.

Figure G15. 
Issue Management.

Figure G15.

Issue Management.

The project manager decides together with the originator, who should be coordinator and responsible, who should participate in solving the problem and who should be informed. The issue form is distributed to the participants. They will add comments and suggestions – and talk together. More persons might be involved, if necessary. The coordinator will bring the issue to an end – either through unanimity or a decision by the project manager or the steering committee/project owner.

Along with this process, the coordinator will register the status. Open issues are monitored at the steering meetings.

G.5. Tool sheet: Project Logbooks

What

A logbook contains registration of events and actions, with explanation of circumstances and documentation of decisions. Sometimes, it is useful or necessary to look back in time to explain earlier decisions, to find causes of delays or failures, to retrieve agreements, etc.

Use – Where and When

Logbooks are used in all project phases.

Method

It might be useful to keep more logbooks in the project, depending on the need of formality, precision, and memory.

Problem logbook/change logbook. For problems, failures, defects, wanted changes, additions, omissions, etc. For each issue, the process is noted – e.g., decision about investigation, decision about action or refusal plus all steps until the issue is solved and finished. The simple system is a list with all issues arranged by work path and product. Useful process data are: deadlines and status for action (registered, investigated, decided, refused/finished) plus references to notes, minutes of meetings etc. The list and the issue form are shared documents.

Agreement logbook. Is related to the project charter and contract plus contracts with suppliers and partners. Notes about mutual deliverables, failures/defects, and related actions, changes to the agreement, supplements to agreement, important events changing the conditions for the agreement.

Negotiation logbook. Documentation of important negotiations between parties.

Correspondence logbook. List of important binding correspondence documents.

Activity and event logbook. Notes about work done and deliverables – plus important events and decisions.

Technical logbook. In technical engineering/construction projects and big product development or systems development, it may be useful to keep a technical logbook (see Figure G16). It includes all subsystems/units in the product. Also, there is a page for each main activity or milestone per subsystem. On this page, documentation data is registered, as well as change data, supplier data, quality control data, transportation data, etc. The logbook shows status for each subsystem and is the entrance to documentation. A database system is suited for this logbook.

Figure G16. 
Example of the Structure of a Technical Logbook.

Figure G16.

Example of the Structure of a Technical Logbook.

G.6. Tool sheet: Progress Measurement

What

Progress means work done, results delivered and observance of the time schedule.

Use – Where and When

Progress measurement is a basic part of project control and is done in all phases.

Method

Progress is measured in two ways:

  • How is the plan kept until now? What have we done, and are we ahead of or behind schedule?

  • What is the estimated date of completion or of reaching coming milestones? This is the so-called forward-looking follow-up.

It is expected that the project manager at any time knows where the project is according to the time schedule. But also forward-looking is essential. Progress should not only focus on work done, but how we will carry out the rest of the work.

Work progress is performance – amount of product delivered. It is not man-hours used or materials consumed. Below are four methods for defining work progress. For each of them, there are formulas for calculating progress and a prognosis for the finishing date and final costs. The methods may have some disadvantages and sometimes more methods should be used. Note that uncertainties in the project and in the plan also influence the progress calculations.

  • Work done. Used when the amount of work is measurable – e.g., m3 excavation, number of technical specifications to do, number of tests to do. Status is determined through measuring or counting work performed.

  • Valued step. The activity is split into a number of steps with finished work. Each step has a performance value out of the activity value of 100 work units. Status is measured in finished steps and their accumulated value. Note that the time interval between the steps should relate to the time interval between making status.

  • Percentage done. At the point of status, either work performed or remaining work to do is estimated and expressed as per cent. To ensure a reasonable certainty, the activity duration should not exceed four to five times the status time interval. A variant is 20/60/20. When work has begun, a value of 20 per cent is assigned. From then on, work done is estimated until an accumulated value of 80 per cent has been reached. The last 20 per cent are allocated, when the work is finished. Another variant is 50/50 – 50 per cent is allocated at work start, and 50 per cent is allocated when work is finished.

  • Work effort and estimated remaining effort. The trick is to express performance as resource effort. Actual resource consumption is registered at the status point and the effort necessary to completion is estimated. The sum of the two figures is now the expected total effort, and status is actual effort as percentage of total effort. Is also called degree of completion.

Status in a Gantt Chart

Activity progress can be indicated in a Gantt chart as mentioned in tool sheet G.1. Figure G17 illustrates some methods:

  • Define new end date for the activity.

  • Define work done. The activity plan-line is 100 work units. Status is estimated or measured amount of work done and may be indicated in three ways:

    • A thick line showing percentage of work done.

    • A progress front crossing the plan line at percentage of work done.

    • A figure expressing percentage of work done. Should be used when planned progress is not evenly distributed over the activity duration.

Figure G17. 
Work Status in a Gantt Chart.

Figure G17.

Work Status in a Gantt Chart.

If the work is interrupted at some point in time, a special line may illustrate when work is performed. The Gantt picture may be supplemented by colors: red = is or will be delayed; yellow = in danger of being delayed; green = following the plan.

These pictures show the deviation from plan and performance. Keeping the previous progress allows visualizing the tendency in progress development, which is more interesting than just the actual situation.

Deviations from the plan usually indicate that we should change the plan forward. This means that we lose sight of previous delays, unless we keep the original plan as a baseline plan.

When the plan has many activities, it is suitable to extract a list of actual activities for checking their status. It includes on-going activities and activities to be finished since the last status date. The coordination and control schedule form has a special status form to be filled in at each status point.

Monitoring in the Milestone Plan

The milestone plan form has a field for status data. The milestones may be colored. Red = delayed or will be delayed; yellow = in danger of being delayed; green = is on schedule.

Trend curve – Deadline Trend

A technique for reporting observance of deadlines is illustrated in Figure G18. The diagram shows when a milestone will be reached or the project will be finished – as expected at the status dates.

Figure G18. 
Deadline Trend Diagram.

Figure G18.

Deadline Trend Diagram.

Progress Curve

The progress curve (S-curve) is a tool for monitoring progress. The curve is drawn in a system of coordinates. The horizontal axis is calendar time and the vertical axis is amount of work (performance). Amount of work means production and is expressed by a suitable unit, e.g., percentage. The plan curve expresses the planned accumulated performance (see Figure G19). Another curve expresses actual accumulated performance – also called value of work done. The curves usually have an s-shape.

Figure G19. 
Basic Elements of the Progress Curve.

Figure G19.

Basic Elements of the Progress Curve.

Line of Balance

Line of balance is a tool for illustrating the project plan and work status. It is especially suited for projects with repeated series of activities – such as successive deliveries of a product or finishing flats in an apartment house. Figure G20 shows an example of a project plan with two elements:

  • Project plan and schedule with activities in planned sequence. Some activities overlap.

  • Completion plan showing the planned accumulated percentage completed for each activity over time. The activities represent 30 activity units in total. The number of activity units to be completed each month is calculated via the schedule. The number of units are accumulated from project start, and illustrated by a dotted line – the planned completion curve.

Figure G20. 
Example of the Line of Balance Tool (a) and (b).
Figure G20. 
Example of the Line of Balance Tool (a) and (b).

Figure G20.

Example of the Line of Balance Tool (a) and (b).

On a status date, August 31, the remaining work per activity is estimated, expressed as activity units. This is converted to progress, expressed as percentage done. These figures are shown in the table and illustrated as columns in the progress picture (value of work performed). In the completion plan, we can see the planned percentage completed – i.e. the point of intersection between the vertical status date line and the activity plan lines.

These intersection points are transferred horizontally to the progress picture. A difference between the column height and the horizontal line indicates progress – ahead of or behind the plan.

Planned cost consumption for activity number 2 is shown in the completion plan. The greater part of the cost is used at the beginning of the activity. The actual cost on status date is 55 per cent of the activity budget. This is illustrated by a column in the cost picture. This picture also shows planned cost for the actual completed work and planned cost at the completion date.

The line of balance technique is also used as a status and progress picture for a portfolio of projects, each represented by an activity line.

References

See Tool Sheet G.7: Performance Measurement

G.7. Tool sheet: Performance Measurement

What

Performance measurement (PM) is a technique for extrapolating the probable project completion situation. PM handles progress, resources, and costs, and the basic principle is to measure progress as earned value, i.e. measure the performed part of the budgeted total value. PM was primarily developed in the USA (Department of Defence).

Use – Where and When

Performance measurement is suited for projects with well-defined activity plans with related resource plan and cost budget.

Method

PM pictures require a set of data for each activity (also called work package):

Work package content SW (scope of work)
Work package budget expressed as agreed budget (SW x Rp), where Rp is planned resource effort per unit of SW. BAC (budgeted cost at completion)
  • Agreed budget covering uncertainty

BCR (budgeted contingency reserve)
  • Agreed changes of content (SC) with budget changes

BSC (scope change budget)
  • Estimated resource effort to completion.

CE (control estimate)
Planned work status WS (work scheduled)
Actual work status = performed work to status date WP (work performed)
Actual work effort = man-hours used to status date ACWP (actual cost of work performed)
Actual resource effort per performed unit of SW. Ra = ACWP/WP.

A set of value calculations are made at the status date:

Budget for planned work (WS/SW) × (BAC + BSC) BCWS (budgeted cost of work scheduled)
Budget for performed work (WP/(SW + SC)) × (BAC + BSC) BCWP (budgeted cost of work performed)
Value of work performed. EV (earned value).

This is supplemented by calculations of deviations and indexes, e.g., for extrapolating the end situation.

Budget observance – in some situations, called index for productivity CPI = BCWP/ACWP. CPI (cost performance index)
Plan/schedule observance SPI = WP/WS or SPI = BCWP/BCWS. SPI (schedule performance index)
Budget deviation – total difference between planned and actual in the schedule. BV = BCWS – ACWP. BV (budget variance)
Performance deviation SV = BCWP – BCWS. SV (schedule variance)
Consumption/efficiency deviation CV = BCWP – ACWP. CV (cost variance)
Progress related to agreement and agreed changes/regulations P = WP/(SW + SC). P (progress)
Extrapolated final cost EAC = ACWP + CE. EAC (estimated at completion)
Extrapolated budget deviation at completion CVAC = BAC + BSC – EAC.
To be compared with budget for uncertainties (BCR). CVAC (cost variance at completion).
Performed and necessary effort respectively:
  • Performed effort = average number of resource units (man-hours) per workday.

  • Necessary effort = necessary number of resource units per workday to reach planned finishing date.

Below is an example of an activity status. The calculations above can be supplemented with key figures for resource consumption per activity unit.

Plan Data:

The activity contains 100 activity units to perform (SW). Related resource budget is 2,000 man-hours (BAC).

Schedule: Activity duration is five months, completing 20 units per month and using 400 man-hours per month.

Extra budget for uncertainties: 250 man-hours.

Status Data: At Status Date End Month 2:

Work performed: 35 activity units (WP).

Planned work performance: 40 activity units (WS).

Actual resource consumption: 900 man-hours (ACWP).

Estimated resource effort to completion: 1300 man-hours.

Change agreement: Five activity units extra (SC) to planned completion date.

Related extra resources: 100 man-hours (BSC).

New work content: 105 activity units. New budget: 2,100 man-hours.

New estimated resource consumption: 900 + 1300 + 100 = 2,300 man-hours (EAC).

Value Calculations:

BCWS = (40/105) × (2000 + 100) = 800 man-hours.

BCWP = (35/105) × (2000 + 100) = 700 man-hours.

AWCP = 900 man-hours.

Calculated deviations:

Budget deviation BV = 800 – 900 = −100 man-hours – explained as:

Performance deviation SV = 800 – 700 = 100 man-hours.

Productivity/cost deviation CV =  700 – 900 = −200 man-hours.

Observance of budget CPI = 700/900 = 0.78.

Observance of plan SPI = 700/800 = 0.88.

Degree of completion P = 35/105 = 0.33.

Progress = 0.33 – 0.38 = −0.05.

Calculated budget deviation at completion

CVAC = 2,000 + 100 – 2,300 = −200 man-hours, which is to be absorbed in the extra budget for uncertainties.

PMS Diagram

Performance measurement is illustrated in the progress curve diagram, supplemented with budget control curves. It is called performance measurement system (PMS). Figure G21 illustrates the principle and the elements.

Figure G21. 
Basic Elements of PMS.

Figure G21.

Basic Elements of PMS.

PMS is a good tool for reporting project work status. It can also collect experience by showing dates of important events and describing them along the time line. The above described index calculations can be transformed into a set of trend curves (temperature curves) showing the development. The curves express actual values as per cent of planned values. Typical trend curves are:

  • Observance of budget (CPI)

  • Observance of plan (SPI)

  • Consumption per unit and performance.

G.8. Tool sheet: Status Report and Management Report

What

The project status report is typically a comprehensive statement of the actual situation, stating what has been done since the previous report and giving a view to the near future.

The management report is a brief statement looking forward to the project completion, and contains any request for and recommendation of actual decisions from project owner and steering committee.

Use – Where and When

Both reports are from the project manager to the project owner, the project responsible manager or the steering committee. The status report may also be information to some of the interested parties.

The project manager and project owner should agree on report types, report frequency and special report milestones.

Method

It is expected that the project manager at any time has a picture of the project status, with the following information/data:

  • Customer’s/user’s actual evaluation of the project and the relevance

  • Quality of actual project work compared to goals. Prospect of fulfilling goals and quality requirements at the end

  • Work done (performance) out of total work. Remaining work to be done

  • Work done compared with planned work (progress)

  • Resources and costs needed to catch up with delay

  • Expected/actual problems

  • Changes in external conditions

  • Necessary resource effort to finalize the project. Available resource capacity

  • Estimated cost at project completion. Available budget

  • Expected finishing date and milestone dates.

Project Status Report

The list of content could be as below:

  1. Important events since the last report – deliveries, milestones, internal, and external events

  2. Follow-up on issues from the last report – issues cleared, remaining issues

  3. Project foundation – important changes of conditions, needs and possibilities; consequences for product use/operation, economy, business case; consequences for project content, goals, and plan

  4. The project task – technical results; technical problems; expected operations economy; implementation, training of users; expected fulfillment of goals; and success criteria

  5. Environment – circumstances related to systems connections; physical milieu; norms and standards and rules; external conditions

  6. The interested parties – contact to customers and users, their attitude, problems; contact to authorities, actual and expected situation; quality, observance of schedule, uncertainties related to suppliers, contractors, consultants; other interested parties

  7. Resources – planned and actual effort; need for resources

  8. Activity and schedule – performance and progress; expected observance of deadlines

  9. Economy – committed and used/spent; changes of budget; observance of budget

  10. Project organization – staffing; changes of structure; staff changes

  11. Contract (with customer) – deviations from contract; agreed changes; coming changes

  12. The future – list of deficiencies; important events.

This might also be the agenda for a status meeting.

Milestone Report and Deviation Report

Instead of reporting status at regular intervals, you can report when milestones are passed and give a warning notice when milestones are delayed.

Content of the milestone report:

  • Project, date, author of report

  • System/work path, milestone

  • Result (quantitative, qualitative, observance of plan, deviations, and their explanation)

  • Project situation (status, coming important issues, schedule, resources, budget)

  • Action (planned work, necessary effort)

  • Report receivers, call for action

  • Next milestone report.

Content of the deviation report:

  • Project, date, from

  • System/work path, milestone

  • Problem – size and cause

  • Project situation – effect of the problem, solutions, advantages/disadvantages, recommended decision

  • Action – already done and actions to do, deadlines

  • Report receivers, call for action.

Management Report

The types of report described above are used when the project owner and interested parties want detailed insight and information. They are bureaucratic. It would be more in line with delegated responsibility to have the project manager deliver management reports, focusing on end situation and fulfillment of goals.

Content of the management report:

  1. Fulfillment of project mission and success criteria – including business case

  2. Interested parties’ satisfaction

  3. Fulfillment of important requirements to products

  4. Observance of deadlines

  5. Observance of budget (resources and costs)

  6. Important issues, uncertainties, risks and related actions

  7. Need for changes – goals, time, resource budget, cost budget

  8. Call for management support/action.

Project Scorecard

Status reports and management reports can have an attached scorecard. It is a form with project measurements – i.e. project process (leadership and control), direct results (products, timing, resources, costs) and utility values. Measurements are to be expressed quantitatively in figures, as far as possible. But satisfaction measured via questionnaires can also be used.

At the beginning, goals are noted in the scorecard form as baseline. At each status report, the project manager notes the actual data expressing the actual situation of the process measures and the expected situation at completion for utility goals and product goals. Decided changes of the project and the goals are noted underway. At project completion, all final results are noted. The scorecard is, in this way, a sort of logbook.

The scorecard may be built on the five-by-five model – see Figure G22. Behind each element in the model, there is goal description or questions. It may be supplemented by signal colors: Green = will be achieved or is achieved; yellow = in danger of not being achieved; red = will not be achieved or is not achieved.

Figure G22. 
The Five-by-Five Model as a Scorecard.

Figure G22.

The Five-by-Five Model as a Scorecard.

Figure G23 illustrates an example of a scorecard with columns. The first is filled in at project start. At milestones and phase shifts, updated date is entered in a new column.

Figure G23. 
A Scorecard Example.

Figure G23.

A Scorecard Example.

G.9. Tool Sheet: Resource Control

What

This tool sheet deals with the quantitative side of resource control and presupposes that the resources are specified per competency groups or individuals (persons, equipment).

Resource planning includes: choosing persons, equipment, facilities; estimating necessary effort; scheduling of the effort; examining available capacity; searching for alternative resources or adjusting the time schedule. Planning is followed by registration of actual effort.

In addition, control includes regularly re-estimating the need for resources for on-going activities and to finalize the project.

Use – Where and When

Resource control is used in all project phases, but the methods should be adapted to the structure of the project and any estimates.

Method

Estimating Resource Effort

Estimating may be done at different levels – the whole project, phases, work paths, main activities, and tasks.

Estimates build on experience – from earlier projects/activities, from other companies, from suppliers and consultants or from standard catalogs. It is natural to collect experience data, when the company has many projects of the same type.

Choice of estimation method depends on project transparency, internal and external uncertainties, comparability to other projects, possibilities for quantifying the work content – or rather the factors defining the resource effort.

We can distinguish between experience-based methods and guess methods. The latter are used for new, untried tasks.

In both cases, we will break down the project into phases, work paths, main activities and tasks. In the experienced situation, we will break down to elements seen before or similar. In the guess situation, we will break down to elements suitable for guesswork. Break-downs have pitfalls. The sum of contingencies covering uncertainty might be too large, if contingencies are added to each element. Resource effort for coordination and general activities might be forgotten. A control estimate at the next upper level or evaluation of reasonability is recommended.

Experience-based methods are:

  • Comparison with previous activities of similar type. Use registered data from previous projects and adjust to actual work and conditions. Usability depends on information about amount of work (performance), competency level of people, work conditions, project changes, work quality, etc.

  • Use of variables in key figures and formulas. Registered data from projects are converted to key figures or formulas with more variables, where the resource effort is dependent on factors (variables) in the project and the activities. For example, the number of specifications and drawings, number of modules in software programs, number of m2 to build. Again, the certainty is dependent on knowledge about conditions and work force capability.

In both cases, it is necessary to adjust for the degree of difficulty, resource experience, work conditions – see Figure G24.

Figure G24. 
Factors Influencing Resource Consumption.

Figure G24.

Factors Influencing Resource Consumption.

In some companies, experience data are rapidly out-dated due to technological development. In other companies, projects are few and different. Here, guess methods should be used:

  • Several competent persons guesstimate and discuss to arrive at an agreed estimate. Primarily, discussions treat different understanding of the work content, the work methods and the competencies.

  • Three guesstimates are to be made – a pessimistic, an optimistic and a most probable. This forces you to consider and note assumptions and conditions related to each guess. Calculate a mean value with heavy weight on the most probable guess.

Mean value = optimistic + pessimistic + 3 × most probable 5
… or choose a value based on an evaluation.

In general:

  • Quantify the work content whenever possible. Estimate resource effort per unit of the work content, multiply and adjust to a reasonable guess.

  • Describe the degree of difficulty and uncertainties and their assumed influence.

  • Consider people’s experience and routine.

Let the doers participate in estimating. They have experience and they will be committed to their own estimates. It is said that we tend to underestimate the task and to overestimate our capacity. But the opposite is also seen – we set aside too much time just to be sure. Remember Parkinson’s law: Work will consume the time reserved for it – plus a little more. A good policy might be to have tight estimates and to endeavor to keep them by applying a level of ambition, effectiveness, and efficiency.

Planning Resource Load

Some companies want to plan the necessary resources for all on-going and planned projects – to ensure capacity and to see the total workload. They look several months ahead to see the overall capacity need: competencies, equipment, and especially scarce resources. In the short term, they want to detect bottlenecks (key persons/equipment).

Most IT systems for planning and scheduling have a facility for planning resource effort per activity and thereby the total need per time period.

When the project plan is dynamic and changes frequently, detailed resource planning will soon be troublesome and probably seen as bureaucratic. One way out is to focus on planning of scarce resources. Other resources should be flexible and adaptable to the plan. Another way is to let each participant plan her/his own workload – like most consultancy companies do. Participants know their projects and activities, the schedule and estimated effort. The personal plan is rolled every month with a three to four month horizon. It presupposes that management respects the plan.

Figure G25 shows a form and the principle. To the left are the projects and the activities for the person. There are also lines for operation activity, training, holidays, etc. Time period is the next three months plus the following quarter. Every month, all activities are re-estimated and a new month is added. Actual effort is registered, just for the logbook. Load is measured as working days or man-hours.

Figure G25. 
A Resource Planning Form for a Participant.

Figure G25.

A Resource Planning Form for a Participant.

The figures should consider efficiency and effectiveness. Participants’ gross capacity should be reduced to net project capacity. Transport time and waste time caused by work conditions should be included in the workload figures.

Capacity Calculations

Some IT systems with resource planning facilities can calculate and adapt the schedule to available resource capacity. Different calculation rules are available.

The resources are allocated to each activity in the activity plan and schedule, distributed over the activity duration. An activity may use more than one resource category. For each resource, the total load per time period is summed up – as a direct consequence of the schedule. In some periods, there will be overload and, in other periods, there might be excess capacity. The system may try to change the schedule to a more convenient load profile – using the activity slack.

For each resource, you can define the maximum capacity related to normal work time and to overtime as well. Time may be reserved for holidays and other activities. You can let the system calculate the dates for milestones and the end date, or you can define fixed dates. You can prioritize the resource categories, and some categories may be linked together. You can define the resource load distribution over the activity duration – it is not always evenly distributed. The system will calculate and suggest a new plan. It may not be acceptable, but it indicates possibilities for a better plan.

The system will probably not present the optimal plan because there are many considerations. Such planning is best suited for production type projects or phases. But summing up the total load is good for better identifying a load profile and avoiding overload.

Time Sheet

A natural consequence of the planning methods presented above is to register the actual work effort (man-hours). The registration should cover all man-hours – not just hours within normal working hours. One purpose is to document actual effort and related progress. Another purpose is to gather experience and to use this experience for revising estimates of effort for the remaining work.

In companies with many projects of similar type, the registered man-hour consumption can be converted into experience data for estimating new projects. But it is necessary also to measure related amount of work and conditions.

Companies delivering projects to customers may use registered man-hours for invoicing and for budget control.

Registered man-hour consumption gives a picture of average capacity for project work. Uncertainty in resource budgets for projects does not originate from optimism in estimates only, but also from overestimating the capacity.

G.10. Tool sheet: Cost Control

What

Costs are cost directly related to the project – the project work and the products. A building project will deliver a building, a systems development project will deliver a system, an event project will deliver an event. But a new product development project will deliver specifications, prototypes and possibly new production facilities. The product is delivered from the operation organization.

Cost control includes calculation/estimation of costs, definition of budget and observance of the budget. Cost and value related to the use of the products after the project is closed are not in question here. They are seen as part of the project result. But there is often a direct connection between project costs and user and operations costs and values – so-called life-cycle cost and value considerations.

Use – Where and When

Cost control is used in all project phases.

Method

Cost Estimation

Costs are calculated/estimated along the project life cycle, based on the work and product break-down structures (phases, work paths, activities and their deliverables). The calculations/estimates are more and more detailed, depending on where we are in the project phases. The first rough estimates might be in Euros for the project and for phases/elements. But it is preferable to first estimate quantity of work, materials, resources, etc. and their unit prices, and then to calculate the total amounts. Cost calculations can be arranged in three ways:

  • Activity-oriented – Related to phases, work paths, main activities (milestones), activities

  • Product/system-oriented – Related to deliverables

  • Resource-oriented – Related to types of materials and other resources.

They might all be used and be combined in the same project, depending on experience data and on level of details in the project specification. A product and resource structure is often preferred by tenders in the bidding phase.

For control reasons, costs should be tied to work paths, activities and milestones. The level of detail is influenced by the required certainty in control of progress and related cost consumption and payment on account to suppliers.

By tying costs to activities and milestones and adjusting them for payment delay, you can calculate a payment profile over time. Financing and incomes can be transformed into an income profile. The result is a liquidity plan. The schedule might be analyzed and rearranged to obtain a positive liquidity flow and to postpone heavy costs for as long as possible.

Uncertainty in estimates (calculations) – and thereby also in the budget – have several causes: unclear specifications, new ambitions and elements, quality problems, etc. Resource consumption may be uncertain. Unit prices may change. These elements should be kept apart in the calculations, because their uncertainty changes in different ways. For budget control in projects spanning several years, it is necessary to trace the changing prices caused by inflation and market conditions.

Comparison between old estimates and new estimates requires the same structure and content. An estimate in the design phase will typically consist of a detailed calculation for the specified part of the product plus an estimate for the remaining unspecified part plus allowance for uncertainty and price development.

Successive Calculation

The successive calculation method provides a picture of the total uncertainty of the estimate and a detailed picture, which guides the estimating effort to those elements contributing most to the uncertainty. The procedure is (Lichtenberg, 2000):

  • The system/project to be estimated is split into a few elements (deliverables, activities, resources).

  • For each element, three values are estimated – optimistic, pessimistic, most probable.

  • The mean value (expected value), standard deviation and variance are calculated (see Figure G26).

  • The element having the biggest variance contributes the most to the total uncertainty. This element is detailed into a number of sub elements.

  • Each sub element is estimated and calculated as above – and another element will now have the biggest variance.

  • Continue detailing until the total uncertainty is acceptable or until further detailing does not reduce the total uncertainty (variance).

Figure G26. 
Formulas in Successive Calculation.

Figure G26.

Formulas in Successive Calculation.

The method will only provide correct results, if the elements are statistically independent. A factor influencing the uncertainty of more elements should be isolated and calculated as a separate element. Examples are work-force efficiency, development in wages and price levels, weather conditions. Figure G27 illustrates an example of successive calculation.

Figure G27. 
Example of Successive Calculation.

Figure G27.

Example of Successive Calculation.

Budget

The cost estimate is converted to a project budget – with appropriate corrections and supplements. The budget is the basis for grants and actions such as purchase, contracting and ordering.

The budget may be changed along the way, but reasons for change should be documented: change in project content, price changes, wrong estimates, etc.

The budget should include a “budget reserve” or “set aside for uncertainty,” with an explanation of the rules for using the reserve. The project manager may use the reserve, if there are good reasons for doing so and according to the rules. Typically, the reserve will cover estimating uncertainties and price changes.

Budget Control

Figure G28 illustrates timelines for delivery of materials and resource effort. It shows that budget control based upon book entries from accepted invoices and timesheets is insufficient. It is necessary to keep an account of committed amounts. The comparison between budget and committed costs states the amount of money available for the remaining part of the project. But, of course, normal bookkeeping is necessary for the project account. Budget control should be tied to elements of the project structure and not to time periods in the schedule.

Figure G28. 
Timeline for Cost Control Actions.

Figure G28.

Timeline for Cost Control Actions.

When materials are consumed in a short time just after delivery, the time for consumption might be the time of delivery – just to avoid stock control. When materials are used in several activities and over longer periods of time, it is preferable to keep an account of consumption and stock. Accounts should be corrected when surplus materials are returned.

When more activities consume the same resource type or material type, the control will depend on the required control accuracy and accepted bureaucracy:

  • Resource consumption is registered per activity. Requires an account per activity and an account for common consumption.

  • Resource consumption is registered on one common account per resource. This requires that registered consumption is related to “value of work done.”

  • Materials consumption is registered per activity. Requires detailed registration of consumption.

  • Materials consumption is registered as delivered on site, regardless of consumption time. Correction for additional deliveries and for returned materials.

The budget is controlled regularly and at milestones. The committed costs need to be split into:

  • Committed – (invoice not entered) consumed before status date.

  • Committed – (delivery perhaps not arrived yet, and invoice not entered) for consumption after status date.

Then, the costs of completing the project are estimated, and the expected budget deviation at completion is calculated. The entire mechanism of budget control might be as in Figure G29. The next figures illustrate forms for budget control in spread sheet.

  • Cost summary (Figure G30), containing budget section (columns 2 to 5), a payment section (columns 6 and 7), a committed cost section (columns 8, 9, and 10) and an expectation section (columns 11 to 13)

  • Project account (Figure G31) as a supplementary form for registering received offers, accepted commitments and received invoices

Figure G29. 
Cost Control Activities.

Figure G29.

Cost Control Activities.

Figure G30. 
Cost Summary Take in Figure.

Figure G30.

Cost Summary Take in Figure.

Figure G31. 
Project Account.

Figure G31.

Project Account.

Project Accounts

It is necessary to define an accounting plan for the project. The accounts should relate to the project structure as explained earlier. See tool sheet C.3. Budget and consumed costs should also relate to responsible organizational units.

When the company has many projects of the same type, it is suitable to use the same account structure and thereby gather experience data for cost budgeting.

References

  • Jacobowsky, B. (1991). Project economy in reality (in Swedish). Konsultförlaget AB, Uppsala.

Lichtenberg, S. (2000). Proactive Management of uncertainty using the successive principle. Polyteknisk Press.

G.11. Tool Sheet: Materials Control

What

Project materials are materials and components consumed during project work and built into the project deliverables (products).

Use – Where and When

Physical components and their parts are specified in the design phase and the procurement phase. In engineering/construction projects, they are consumed in the construction phase. In other projects, e.g., new product development projects, they are not consumed in the project, but afterward. But, of course, prototype building will consume some materials during the project.

Method

Materials control contains the following functions:

  • Procurement guidelines for engineering/construction and procurement planning

  • Procurement or ordering of manufacturing

  • Parts list control

  • Monitoring delivery

  • Transport control

  • Receipt and quality control.

Procurement guidelines are for the design/engineering/construction personnel. The guidelines might describe alternative or preferred technical standards, preferred suppliers, price levels, standards for specifications and delivery conditions etc. Commercial circumstances, delivery certainty, political conditions and customer requirements might also be described.

Considerations in procurement planning include issues such as purchase versus own manufacturing, standard product versus own design, concentration on a few suppliers versus detailing into more components from several suppliers, political and geographical aspects of the choice of suppliers, commercial conditions, types of tendering. Some suppliers might be selected as preferred suppliers with a general framework agreement stating that the supplier is capable of meeting our requirements, quality standards, delivery terms and schedule. The procurement plan also describes schedule for deliveries and related latest deadlines for ordering and final specifications.

Procurement includes tendering (call for tenders), selection of suppliers for negotiation, negotiation, ordering/contracting. Negotiations are usually split into a technical part and a commercial part. Rules and regulations for commercial tendering and contracting should be observed. In simpler situations, procurement entails negotiation with one or two selected suppliers and simple ordering (purchase) with delivery conditions.

The basis for materials control is the item list with all components in the project product. The list is established as early as possible in a first rough version. It is detailed along with the design and engineering work. Item list administration aims to register all items and their status – (quality) approval, procurement actions, quality control actions, transport actions, installation actions, test actions, etc. Also included are control of component changes and information about changes. See configuration management.

Monitoring delivery is proactive monitoring of delivery time, including coordinated delivery of connected components. Quality is also controlled proactively before delivery. The principle is that it is too late to control at delivery and find failures and delays there. Pre-payments may be related to progress and milestones – requiring progress control as well. Minimum monitoring may include ensuring order confirmation from the supplier, announcement of delivery in due time, and announcement of possible delay in due time. Monitoring leads to correcting actions and to re-planning.

Transport control includes transport planning from supplier to project site, including warehousing, planning of packaging and labeling, insurance conditions, and transportation.

Delivery on site encompasses control of correct components, correct quantity and quality, as well as acceptance and immediate notification of defects.

G.12. Tool Sheet: Contracting

What

This tool sheet deals with contracts with suppliers and consultants.

Use – Where and When

Contracts are used in all project phases.

Method

The main elements of contracts are the delivery and delivery conditions, prices and payment, contract documents and contract administration. There may be rules and regulations for tendering and selection of offers.

Types of Delivery

Typical types of delivery in an organizational and responsibility context are illustrated in Figure G32 for the case of consultants. In addition, you should define a price and payment model. Examples are:

  • Fixed price. Arranged fixed price for arranged delivery. Payment may be adjusted according to agreed price index and formula.

  • Price per delivered unit. Arranged price per unit (e.g., excavated m3 of earth). Quantity is measured during the work. Price may be adjusted in accordance with agreed index and formula.

  • Price per resource unit. Delivery is paid per consumed resource quantity (e.g. man-hours) and agreed unit price.

  • Cost plus contribution margin. Delivery payment is settled as direct documented cost (wages, materials, equipment, etc.), plus agreed contribution margin which might be: A) percentage of direct costs; B) fixed agreed amount; or C) variable percentage or variable amount, depending on observance of budget and deadlines

  • Maximum price. Delivery is paid as in one of the above models – up to a maximum amount. If the maximum is not reached, the difference may be split between the parties.

  • Percentage of construction cost. Consultant’s fee is calculated as an agreed percentage of the construction cost.

Figure G32. 
Types of Deliveries and Services.

Figure G32.

Types of Deliveries and Services.

Often, the challenge is that the quantity and quality, and the delivery and installation conditions cannot be defined precisely. However, the buyer and the supplier as well want to make an agreement protecting them from unpleasant surprises. The contract should contain possibilities for regulation, if there are uncertainties. Some mechanisms are unit price, measured quantities and agreed price for typical changes in delivery (extra modules and features). This may be supplemented with stimulus to minimize costs and increase value.

Types of Contracts

Contracts are arranged to cover the planned work and delivery situation and the foreseen types of disagreement. The contract should cover situations where mutual services deviate, and it should show how to end the cooperation in case of disagreement (conflict). A number of different standard contracts exist – national and international – suited for different types of projects and services. It is recommended to use one of these contracts, because they are well-known and unambiguous.

Suppliers, consultants and project owners sometimes have their own contract version. Beware of formulations that deviate from “normal” and of how changes of delivery and delivery conditions are handled. Look for formulations deviating from the standard contracts or favoring to one party.

There are many examples of unsatisfactory project results that are due to contract parties sticking to the contract, instead of cooperating to create the best product. This has led to some interest in so-called partnering contracts. The idea is that both parties should act for a joint best result. It is based upon common goals, loyalty towards the project (before own interests), honest and open communication, mutual helpfulness, respect and confidence. The project organization has mechanisms for conflict solution to protect against work stop.

An essential element of partnering is regular evaluations of the cooperation culture and behavior. Another element is stimulus of cooperation – such as bonus for work well done, and for cost and time savings. Morris (2013) discusses pros and cons of partnering.

Contract Administration

The explicit formulation of formal responsibilities and the rules for price regulation lead to careful control of compliance and documentation of the delivery process. The important elements in contract administration are:

  • Documentation of work start – Date, quality of work basis, quality of supplier’s resources.

  • Logbook documentation of important conditions and events during the work. Hindrances, deficiencies, deviations and other circumstances, and factors of importance at an eventual settlement of disputes. The logbook should be accepted by both parties.

  • Written agreement on all changes – Including consequence for delivery, deadlines, and payment.

  • Hand-over documents for all deliveries.

  • Documented status reports – Accepted by both parties.

  • Control of supplier’s invoices – Consistency with work done and contractual conditions.

  • Written acceptance of finished work and agreement with the contract.

  • Contract file with all relevant documents.

Typical contract elements are shown in Figure G33.

Figure G33. 
Typical Contract Elements.

Figure G33.

Typical Contract Elements.

References

  • Morris, P.W.G. (2013). Reconstructing Project Management. Wiley-Blackwell.

G.13. Tool Sheet: Analysis of Problems and Needs

What

Diagrams and pictures often speak more than words. They give overview and are easy to remember. This tool sheet presents some simple diagramming methods, useful for describing the problem situation, needs and goals.

Use – Where and When

The methods are used in the project charter and in the documentation of the solutions concept.

Method

Tree Diagrams

Tree diagrams are used for analyzing and illustrating problems, goals and means/solutions. Typical situations are:

  • Influence tree – Showing factors influencing a situation, a problem, a system, etc.

  • Goal/Means tree – Showing means to fulfil goals.

  • Goal/Means tree – Showing connections between superior goals and subordinate goals.

  • Decision tree – Showing alternative actions, decisions, and events and resulting situations.

Influence Tree

Figure G34 shows an example of an influence tree (influence diagram) illustrated as a simple hierarchy. Figure G35 illustrates a more complicated influence diagram with more connections. A set of symbols are used (Ashley & Avots, 1984):

  • A decision alternative – Possibility for selecting an effort or a solution.

  • A risk factor – A factor which is beyond the control of the project management.

  • A defined quantity or value.

  • A calculated effect – A result, a quantity, a value, etc.

Figure G34. 
Example of a Hierarchical Influence Diagram.

Figure G34.

Example of a Hierarchical Influence Diagram.

Figure G35. 
Example of an Influence Diagram.

Figure G35.

Example of an Influence Diagram.

The diagram may be used for risk analysis and sensitivity analysis – analyzing calculated effects with alternative risk factor values and alternative decisions.

Goals/means Tree

Project mission, goals and means are arranged in a hierarchical pattern. It is used for sorting goals and relating them to superior goals – and, going the other way, detailing a goal into subordinate goals and means. Select a goal and ask these questions:

  • How can this goal be fulfilled? This leads to subordinate goals and means.

  • Why this goal? This leads to superior goals.

Goals are formulated as verb plus noun plus quality specification. Figure G36 shows an example (from Delp, 1977).

Figure G36. 
Example of a Goal-Means tree for a Hydro Power Project.

Figure G36.

Example of a Goal-Means tree for a Hydro Power Project.

Decision Tree

A decision tree is used for analyzing situations with several possible different final results. The result will depend on circumstances and events beyond the reach of the project manager, and on choosing between alternatives. The tree illustrates the possible combinations of events and actions, but does not show their sequence. See tool sheet B.5.

Relationship Diagrams

Relationship diagrams are used for describing cause-and-effect connections. They can illustrate the structure of problems and situations and help identify important points of action.

Two questions are used at the diagramming. One is “Why” – revealing causes. Another is “What will be the consequence/effect?” It is often necessary to ask “Why” several times to reveal chains of causes.

Ovalogram

An ovalogram illustrates a problem, seen as a complex connection between elements of a system and elements in the environment. The diagram is used for achieving a common understanding of the situation.

Figure G37 shows an example – the same situation as in Figure G34. Figure G38 shows symbols and drawing rules.

Figure G37. 
Example of an Ovalogram.

Figure G37.

Example of an Ovalogram.

Figure G38. 
Symbols and Drawing Rules for an Ovalogram.

Figure G38.

Symbols and Drawing Rules for an Ovalogram.

Cause-and-Effect Diagram

Cause-and-effect diagrams illustrate processes and influencing factors. See Figure G39. They can also illustrate problems with their causes and effects.

Figure G39. 
Example of a Cause-Effect Diagram.

Figure G39.

Example of a Cause-Effect Diagram.

The descriptive factors (features, variables, parameters) are drawn as convergent or divergent arrows. An arrow going to or an arrow coming from another arrow indicates that the two factors are connected in a hierarchy. Causes and input are shown to the left of the problem/process. Effect and output is drawn to the right. See Figure G40.

Figure G40. 
Symbols in a Cause-Effect Diagram.

Figure G40.

Symbols in a Cause-Effect Diagram.

Problem Matrix

Problems and their causes are often connected in chains across the organization. This is illustrated in a problem matrix. See Figure G41. Identify problems for each department, arranged in three categories:

  • Internal – Coming from internal circumstances

  • Impressed – Originated in another department and transferred to the department in question

  • Forwarded – Transferred to other departments.

Figure G41. 
Example of a Problem Matrix.

Figure G41.

Example of a Problem Matrix.

The problem matrix is drawn in a joint discussion. Chains are identified and prioritized for action.

Gap Analysis

The gap analysis compares actual performance with planned performance. See Figure G42.

Figure G42. 
Example of a Gap Analysis.

Figure G42.

Example of a Gap Analysis.

Description of Functions

Describe the functions and features of a product or a system and relate them to the user’s need. Describe what we want to achieve, but not which solutions we will apply. Avoid getting caught in technical traditions.

A function is an activity (a capability) from a product or a system. There are main functions – primary performance – and there are support functions. Support functions support the use of the product, or make it more attractive and easier to produce etc. They are not necessary for the main functions.

Functions are expressed by verb and noun (e.g., “move package”) – with limits (e.g., 2–50 kg, 5–50 m, the same floor). A function may be detailed into sub-functions, illustrated in a hierarchical structure (function tree). See Figure G43.

Figure G43. 
Example of a Function Tree.

Figure G43.

Example of a Function Tree.

The tree can be detailed downwards by asking “how can we specify this need?” Similarly, we can see superior functions by asking “why?” For each identified need, we should note “who has this need?” (user, manufacturer, society, etc.). The functions are specified – functional limits, performance limits – and measurement methods are defined. Quality levels may be appropriate – maximum wanted and minimum acceptable. Functions are prioritized – need-to-have or nice-to-have. Functions may have an attached value, which is useful for prioritizing the work and for comparing alternative solutions.

By selecting a certain level in the function tree as basis for the design work, we delimit the room of solutions. We can expand the tree to be a functions-and-means tree (see Figure G43). Possible solutions to each function are placed underneath – at higher levels as principle solutions, and at lower levels as specific solutions. Single solutions are combined into total solutions. To be operational, they will often require additional functions, so-called design-related functions, in contrast to the basic user and stakeholder related functions. Attach a detailed description of the development and design task – see Figure G44.

Figure G44. 
Description of the Development Task.

Figure G44.

Description of the Development Task.

The description of functions may also be a future scenario – description of future user situations (use cases) with the coming product – not designed yet, only described by its functions. It is so to speak a matter of writing the user manual before the product is designed. This arrangement requires that the users and the developers communicate directly, that the developers experience the user milieu directly, and that the developers present new technological ideas to the users.

The System Concept

System concepts and system thinking are an important way of illustrating and understanding projects and their products. We talk about systems in different ways – traffic system, solar system, social system, production system, planning system, etc. System thinking is useful for explaining and describing a wide spectrum of situations. A system is a part of reality with well-defined boundaries so it is possible to determine what is inside and what is outside of the system. It holds a number of interconnected elements and connections to the environment (surrounding systems).

Systems are seen as objects and as processes. Objects may be a machine, a building, an administrative system, a human being – described through the elements it contains – machine components, rooms in a building and the construction elements, the forms and files in the administrative system. The connections between the elements may be illustrated as:

  • a hierarchy with superior systems and subsystems (see Figure G45).

  • a geometrical/geographical arrangement and connection (layout).

Figure G45. 
Example of a Systems Hierarchy.

Figure G45.

Example of a Systems Hierarchy.

The process view describes how an object is transformed through a number of activities (processes, actions). Objects are materials, energy and information. Input (object in one condition/form) is transformed to output (object in another condition/form). A complex system, with objects passing more processes, is illustrated in a process diagram – see Figure G46 and G47.

Figure G46. 
A Black-Box Description of a System.

Figure G46.

A Black-Box Description of a System.

Figure G47. 
Illustration of Systems.

Figure G47.

Illustration of Systems.

A system is characterized by:

  • system purpose.

  • technical and human components and sub-systems.

  • input.

  • output.

  • processes.

  • structure – Arrangement etc.

  • environment – Systems, factors, interested parties, etc.

Systems with technical and human elements are called socio-technical systems. Figure G48 shows the principle. The PPSOP model is socio-technical, cf. Section 2.2.2.

Figure G48. 
Description of a System.

Figure G48.

Description of a System.

A system is always part of or neighbor to another system. Therefore, defining interfaces is an important aspect of project work.

References

  • Ashley, D. B. & Avots, I. (1984). Influence Diagramming for Analysis of Project Risks. Project Management Journal, March.

  • Delp, P. (1977). Systems Tools for Project Planning. International Development Institute, USA.

  • Johansen, J. & Mitens, L. (1986). Analysis and diagnosis (in Danish). VIPS, Aalborg University, Dept. of Production.

G.14. Tool sheet: Logical Framework

What

Logical framework is a method for describing a project – mission, goal, input and output. The idea is to formulate these elements more specifically and measurably, and to make planning easier. The method should also make it easier to measure project results.

Use – Where and When

Logical framework is suited for preliminary analysis of the problem and the need, for delimitation of the task (scope), and for identification of the project and product environment and conditions. The method is used in the concept development phase and later at the measurement of results.

Method

Logical framework may be documented as a form with two dimensions – see Figure G49. One dimension describes why the project should be done. The other dimension describes what to deliver and the success criteria (results).

Figure G49. 
Logical Framework Example.

Figure G49.

Logical Framework Example.

The “why” dimension has four sections: Purpose/mission is the wanted future operations situation or use situation. The goal is the required functions and features in the solution/product. Output is the specific product (solution). Input is the activities and means necessary to create the solution.

The “what” dimension has four sections: Description is the above-mentioned mission, goal, output, and input. Measurable indicators are specific quantities and qualities. Measurement method is how to demonstrate actual quantity and quality. Important preconditions are assumptions and conditions related to mission, goal etc. and to the quantities.

Logical framework may be developed into a goal setting and planning method for projects. It has seven steps – in two stages:

  • Analysis of the situation

    1. Analysis of target group and interested parties

    2. Analysis of the problem

    3. Analysis of purpose and goal

    4. Analysis of possible alternative solutions.

  • Arranging the project

    1. The project elements (work paths and activities and milestones)

    2. External circumstances and connections

    3. Indicators of fulfilled goal.

Logical framework is developed from experience with deficient problem analysis at the beginning of the project – see Figure G50.

Figure G50. 
Activity-Oriented and Goal-Oriented Planning.

Figure G50.

Activity-Oriented and Goal-Oriented Planning.

References

  • Vagnby, B. (1999). Manual for Logical Framework Approach: A Participatory Planning Tool. Institut for Samfundsudvikling og Planlægning, Aalborg University.

G.15. Tool sheet: Utility Values and Benefits

What

Projects are carried out to achieve utility values (business values, life values, society values, etc.) from the project products (services). Project control should therefore focus on these values – even when the values might be achieved after the project ends and managed by people outside of the project organization. Value control (management) includes the following elements:

  • plan the utility values, appointing the people being responsible for achieving the values, and arranging the actions to ensure achievement.

  • steer towards achievement during the project.

  • measure achieved values after implementation of the project products (solutions).

Use – Where and When

The wanted or expected values are described in the project charter and defined in more detail in the solutions concept, which should also include a plan for implementation. In the development and implementation phases, focus should be on anchoring responsibility and accountability in the user organization, and on relevant management methods. Focus should be maintained after first implementation, by regular measurements of achieved results.

Method

Value control includes the following processes:

  1. Determine wanted utility values.

  2. Arrange plan for realization.

  3. Keep focus on the values.

  1. Determine wanted utility values

    • Describe the utility values wanted and expected from the project – or, rather, from the project products (solutions). Begin with “soft” formulations (better, cheaper, easier, etc.), but specify quantitatively as far as possible afterward. Relate to cost savings, increased turnover, increased profit as far as possible.

    • Describe who should achieve what (among the interested parties and stakeholders).

    • Identify uncertainties – optimistic, pessimistic, most probable goal. Identify possible influencing factors and arrange actions.

    • Arrange measurement system and reporting. Define measurements – key performance indicators. Define baselines, who should measure and report, who should receive the report, who is responsible for correction actions, and who should be informed.

  2. Arrange plan for realization

    • Define who is responsible and accountable for achieving utility value in defined areas. Describe related conditions.

    • Describe the change from now to wanted future situation. Describe the organizational change challenge (see Section 1.5.3).

    • Arrange change strategy and implementation process and schedule.

    • Potentially, arrange a reward system for achieving the values.

  3. Keep focus on the values

    • Arrange control routines in the project. Who is responsible for acting (besides the project manager and the project owner) if the values are in danger.

    • Monitor attitude to the project, the progress and the products in the target groups. Monitor change and implementation activities. Compare attitudes, behavior and achieved results with the goal and plan (business case). React to deviations.

Achievements are the responsibility of the operation organizations. They should arrange and carry out the necessary measurements.

G.16. Tool sheet: Product/System Specification

What

The system specification or the (basic) product specification should define requirements and related choice of solution. The future product is anchored in the specification, which is a reference document for control of technical performance and quality.

Use – How and When

The specification is developed in the concept development phase. But it is changed and developed in further detail in the design and engineering phases – and even in the implementation phases, when practical experience calls for it.

Method

Typical content of the basic specification includes:

  • Main criteria in the technical goals

  • Definition of basic and important requirements

  • Description of basis for design

  • Important functions and features

  • Systems structure and interfaces.

Figure G51 shows an example of the content of a systems specification. It may be supplemented by description of production facilities, marketing, distribution, service, administration, and economy.

Figure G51. 
Example of Content in the System Specification.

Figure G51.

Example of Content in the System Specification.

An example of a basic product specification is shown in Figure G52. It is built on the life-cycle principle – to describe the requirements in each phase in the product lifecycle from birth to destruction.

Figure G52. 
Content in a Basic Product Specification.

Figure G52.

Content in a Basic Product Specification.

G.17. Toole sheet: Quality Assurance

What

Quality assurance activities are first determined by the technical disciplines in the project. But some general methods and principles are useful in all projects.

Use – Where and When

The methods are suitable in all project phases – see Figure G53.

Figure G53. 
The Road to Quality.

Figure G53.

The Road to Quality.

Method

Quality Assurance Activity Plan

The quality assurance activity plan has two starting points. One is the company policy for quality management in projects – e.g., based on the principles in ISO 9000 (see Figure G54). Another is the analysis of the points of special concern coming from these questions:

  • What will be difficult and uncertain?

  • What will be important and critical to achieve success?

Figure G54. 
Quality Management Activities.

Figure G54.

Quality Management Activities.

The answers will lead to points of special concern (or worry), where a quality assurance effort might be necessary.

The analysis of the points of special concern is the basis for planning quality assurance activities – and for choosing design, engineering and construction approach, and choosing product/components. You should arrange a quality assurance plan. For each item of concern, you should arrange assuring activities:

  • Preventive actions and responsible persons

  • Control actions – Specification and planning of quality control and reporting of results, and appointing persons responsible for corrective action.

The quality assurance activity plan should not be a separate plan, but should be integrated in the project activity plan, cf. Figure G55.

Figure G55. 
Quality Assurance Plan.

Figure G55.

Quality Assurance Plan.

Quality Assurance Actions

Quality assurance of project activities targets six elements:

  • The method/approach

  • The resources (people, equipment, etc.)

  • Input (data, materials, etc.)

  • The work

  • The result/output – including documentation

  • The milieu – physical conditions, interested parties etc.

Quality assuring activities could be:

  • Control, examination

  • Review – walk-through, evaluation, and constructive critique

  • Test

  • Regulations and norms.

A walk-through exercise is typically done by technical colleagues, whereas a test is often done by users, assisted by test technicians. Special attention is paid to quality control before milestones – ensuring that the milestone is reached and ensuring a basis for activities after the milestone.

Review

Review is a critical evaluation of the product (output from an activity), asking: Is this correct, suitable and useful for the next stage in the project or for final users? Typical review points are:

  • The systems/product specification

  • The solutions concept

  • The prototype

  • The design and its documentation

  • The production methods

  • The marketing material and set-up

  • The user manual and product documentation.

Note that reviews often lead to rework (changes, improvements). Review should be done as early as possible on models and prototypes. Forward-oriented review of ideas and sketches is more productive than review of finished work.

The review team is formed so as to represent the technical disciplines and user areas to be covered in the review. The review is arranged to focus on certain quality aspects and themes. Each of the reviewers is assigned to certain aspects and should prepare for the review meeting – and receive relevant information beforehand. The review session is documented, and there should be a follow-up on the results afterward. The review team does not decide, but comments and suggests. The project team/manager will decide. See a review procedure in Figure G56.

Figure G56. 
A Review Procedure.

Figure G56.

A Review Procedure.

Test

Test is an important means and can be carried out at all stages in the development process – targeting all six elements in the above mentioned quality assurance activity. Test is a feedback mechanism, and there is a tendency towards more frequent test and feedback to the developers – before their solutions get too locked. An example is Microsoft’s “daily build”, where the systems developers and programmers should deliver their daily work output (modules, components) to test every day. The modules are tested together with the already finalized part of the system, and the developer will get the test result a few hours later – for corrective action. Another example is iterative systems development, where the developers meet the users frequently for review or test.

G.18. Tool sheet: Quality Function Deployment

What

Quality Function Deployment (QFD, House of Quality) is a method for arranging a large number of requirements to be more accessible for the developers/engineers, Hauser & Clausing (1988). QFD aims to deploy features and quality requirements to functions in the product. QFD has become popular because it is systematic and can make user requirements visible during the project process. It provides a common language and a shared picture of the requirements.

Use – Where and When

QFD is used in the concept development phase for describing and arranging requirements for the design/engineering work. The method is extended to cover subsequent stages – planning of manufacturing and logistics.

Method

QFD uses a number of cross diagrams for arranging data and visualizing their connections. Figure G57 illustrates the first diagram (house). It has a “what” field with user requirements (voice of the customer). The requirements are described in the user’s own words. The next field is for the requirements from other interested parties. The requirements are arranged and prioritized, e.g., following the stages in the product life cycle such as manufacturing, sales, distribution, use, and disposal.

Figure G57. 
The Requirement Picture in QFD.

Figure G57.

The Requirement Picture in QFD.

The field “who” is for tying requirements to interested parties. Interested parties may share views or have conflicting views. The preference may be indicated by a symbol.

A comparison with the most important competing products can be illustrated to the right in the diagram – their fulfillment of the requirement and our intended fulfillment. This may lead to accentuating the positioning features in the market. Requirements being difficult to fulfill may be marked, too.

Product features and qualities selected or necessary to fulfill are noted in the “how” field. The features should be measurable – describe features and not components. An example is an adjustable spanner. Changing the position of the jaws should be very easy – requiring only little finger strength. The corresponding features will be the diameter of the thumb-wheel, thread pitch, and the surface roughness. The features are connected with corresponding requirements in the cross field. Symbols may indicate the degree of positive connection and degree of conflict.

The field “how much” contains target values for each feature – potentially as minimum and maximum values, and may also contain comments on stability, serviceability and technical challenges.

Features may be conflicting. That is noted in the top cross field.

The defined product features are transferred to a second cross diagram – choice of components. Here, product features are transferred to required component features. This is done during the engineering stage and is often seen as an iterative process, including choices between alternatives and with optimizations.

A third stage aims to connect component features to production processes, and to define technical requirements to the production processes, such as surface finish and tolerances. A fourth stage aims to transfer these requirements to “how” each production activity should be done.

An example of the first cross diagram is illustrated in Figure G58.

Figure G58. 
Example of Requirements in QFD.

Figure G58.

Example of Requirements in QFD.

References

  • Hauser, J. R. & Clausing, D. (1988). The House of Quality. Harvard Business Review, May-June.

G.19. Tool sheet: Imposed Effects

What

People working with creation and development in the project produce solutions and decide on solutions, which has effects in later phases – in the product and when the product is used. They impose effects – values and costs. They need methods for anticipating and envisioning the effects to make the best solutions. In the following, we will describe life cycle cost, design for value, design to cost, and value engineering.

Use – Where and When

The methods are used in the concept development phase and during the design phase.

Method

Life Cycle Cost

The life cycle cost of a product, a plant or a system (LCC) is the costs to create and build it, to use and maintain it and to dispose of it in the end. Knowledge about LCC is used for choosing between solution alternatives – seeking the alternative having the lowest life cycle cost. But other considerations may influence the choice, such as available investment capital.

LCC can be seen as project and product owner’s cost. But often there are more interested parties in the life cycle, making it necessary to balance the interests – e.g., in favor of the end user. The society may also focus on certain costs – e.g., energy consumption, environment related costs, disposal costs, and green product.

It requires some effort to estimate costs, because they belong to several parties and you need to get access to experience data. Estimate direct costs and indirect costs as well – such as cost of environmental protection.

Design for Value

The developer will focus on the user/customer. The product should have the features required and valued by the user. But there are several “customers” on the way to the end user – and even after the end user. In new product development, for example: the manufacturing department/company, the sales organization, the retail shop, the after sales service organization. Each of them has requirements to the product seen from their view and business. The developer may use some methods for considering their requirements, such as design for manufacturing and assembly (DFMA), design for logistics etc.

The basis consists of requirements defined from each customer/user/interested party and a description of values and cost-creating circumstances – so-called cost drivers. Design for assembly is an example. Typical means for rational and cheap assembly of a product are: few components, simple handling of components, easy and quick assembly and visibly correct quality for each assembly step. The first step is a description of the product functions and features, to ensure that the necessary and sufficient functions are defined. When a technical solution is sketched, the assembly process is thought through and envisioned – with estimated time and necessary tools. Ask the following questions for each component:

  • Is this component necessary?

  • Is special (different) material necessary

  • Does the component need to move in relation to other components?

  • Does the component allow easy mounting of other components?

  • Is the component easy to adjust?

If the answers are “No,” the component should be integrated into another component or be removed. The next step is to redesign the product.

Design to Cost

The purpose of design to cost (DTC) is to keep the product below a certain cost level. DTC has the following elements:

  • Define a systems structure of the product.

  • Define cost limits for each subsystem (component). They are related to future activities in the life cycle and should be prioritized. For a new product, they typically include manufacturer’s cost, user’s operations cost, user’s service and maintenance cost, user’s disposal cost etc. This division of a total cost is not easy – but useful. The division expresses the importance of the component and should of course be compared to the value.

  • The cost limits and additional descriptions are handed over to the designers/developers being the cost creators. Their job is to design the system (component) and to observe the limits. It is often necessary to let experienced cost estimators (calculators) estimate the systems cost during the design process – using the designer’s sketches and ideas. It is important that the estimators work closely with the designers to ensure fast feedback to the designers. If components are too detailed and finalized before they are cost calculated, there is a risk that they will not be changed, because of too much rework. It is difficult to make a finished design cheaper – often it is better to use another design concept.

  • If it is impossible or takes too much effort to keep the cost limit, the project manager should decide. He has a budget reserve and he has the overall cost picture.

This cost control method requires a simple reporting procedure – registration and summing up the calculated costs, and comparison with cost limits. The fast calculation and feedback to the designers are important. The project team should have experienced people from all steps in the product life cycle or experienced review groups.

Value Analysis

Value analysis is the use of systematic design methods and creativity for product design, aiming at lowest costs and best value. It is often exercised as an analysis of a product. Under the name value engineering the method is used for development of a new product. The method uses life cycle cost and value considerations.

References

  • European Commission (1995). Value Management Handbook.

G.20. Tool Sheet: Failure Modes and Effect Analysis

What

Failure modes and effects analysis (FMEA) is used for identifying failures and risks in a new product, before it is released to the market. The potential failures and defects are found and their effect, probability and cause are analyzed. The result is mitigating actions.

Use – Where and When

The method is used for ensuring product quality when arranging tests and preparing user’s manual.

Method

The aim is to ensure required product quality. The analysis is based on four notions:

  • Functional quality: The product has functions and features as expected by the users.

  • Reproduction quality: The product can be manufactured in great numbers with a uniform quality.

  • Reliability: The product will maintain its quality throughout its life-time (in use).

  • Durability: The product has satisfactory physical lifetime.

Sources of failures are typically to be found in three places: in the product construction, in the manufacturing process and materials, and in the user manual. Experience says that failures are frequently found in the construction and the manual.

FMEA is carried out on design solutions and on defined manufacturing methods. The analysis is done by a team of experienced people covering the product life cycle. The analysis may, of course, be limited to elements in the product and to steps in the life cycle. The analysis is documented in a form – see Figure G59.

  • Column 1 describes the product element or process to be analyzed. Functions are described in column 2.

  • Column 3 describes the failures and defects imagined by the analysts. Column 4 describes effect/consequence (for the user etc.) if the failure arises. Column 5 describes the possible causes of the failure.

  • The probability of each cause is estimated – e.g., on a five-step scale from unlikely over small, moderate to high and very high. Index is noted in column 6.

  • Seriousness is evaluated next. For example, on a five-step scale from no measurable/visible effect over little effect, noticeable effect and some user dissatisfaction, noticeable effect and strong user dissatisfaction to possible safety risk and total breakdown.

  • Column 8 describes the chance of identifying the failure before the product reaches the market and the user, applying normal control procedures. The scale might be: big chance, moderate chance, little chance, will not be found before the product is at the customer.

  • Column 9 shows the risk factor. The indexes in columns 6, 7, and 8 are multiplied.

  • Big risk factors are selected as points of special concern. Preventive actions aiming at one or more of the three indexes are arranged. Causes are removed.

  • The analysis is repeated after carrying out the preventive actions.

Figure G59. 
Form for FMEA Analysis.

Figure G59.

Form for FMEA Analysis.

G.21. Tool sheet: Configuration Management

What

Configuration Management (CM) should ensure that there is always a correct specification of the product. CM is also a control procedure for changes of the product and a change logbook.

Use – Where and When

Configuration Management begins with the solutions concept as the original configuration. Change control is done in the following phases and in the product life time.

Method

The CM system has the following elements:

Identification of Configuration

Each subsystem (each component) should have an unambiguous identification (name, code). The identification should also identify the version, when there are more subsequent versions or customer/country versions. Documents describing the component should be identified.

Reference Basis

The idea of CM is to freeze a systems/component specification as a reference basis for further project work. It may be reasonable to change the specification later, but only via a formal change procedure.

Design Review

Each reference basis is specified, documented and approved at a design review. It is authorized by special announcement.

Change Control

Control of changes has three steps: Initiative and preparation, evaluation and decision, and ordering. All participants can suggest changes and address them to the change manager. He will conduct further analysis and write a formal change request. It should include:

  • Reasons for the change and what will happen if it is not carried out.

  • Description of consequences of the change – schedule, costs, risks, procurement, other components etc.

  • Estimated cost.

  • Suitable time for executing the change.

Figure G60 shows types of change and may be used for classification and prioritization. The evaluation leads to a decision – acceptance or rejection and time for execution. Acceptance will lead to a change order, which should include:

  • Description of the change

  • Description of all consequences – changes in documents, in programs, in other components and eventual discarding of components

  • Execution date.

Figure G60. 
Example of Types of Changes.

Figure G60.

Example of Types of Changes.

The change order is a clear message to all involved people. It calls for response (work done).

Change file

The administrative system for change control includes:

  • Documentation of actual and previous reference basis

  • Incoming change requests and requests in process

  • Decided changes and logbook for execution.

Change control organization

Two organizational units are necessary:

  • A CM coordinator – receives requests, manages the analysis, notes decisions, issues change orders, follows-up

  • A CM committee – evaluates and decides. The committee is usually the project manager and the technical leaders.