Logo

1. INTRODUCTION

Value management (VM), value engineering (VE) and value analysis (VA), are terms that are being used more and more frequently; but what do they mean? Most design organizations have a concern for value and have processes and design reviews to address owner requirements and the cost of any proposed scheme. Capital cost is certainly one element of value but general experience indicates that the cheapest is not always the best and a broader understanding of value is needed.

It is increasingly recognized that not only do design organizations need to provide assets that meet the owner's specification and are built to time and within budget but that the potential project maximizes the benefit to the owner's business. At the earliest stages of project thinking the owner specification is an expression of a number of perceived and/or actual 'needs'. As design proceeds and the cost of meeting those needs emerges it is often necessary to recycle the design to provide a scheme that is more acceptable to the owner. In the same way, as design proceeds, additional opportunities can be generated that could bring additional benefits to the owner's business.

It is a key role of the design organization to enter this debate of value and need at the earliest stages of design. Experience shows that 'loose discussion' and 'asking the owner what is wanted' is unlikely to be enough, and design organizations need to be able to get close to the owner, under- stand the needs and provide solutions which not only give good capital value but also enhance the business. It is this presentation of need and cost in a different form that VM techniques address. VM and associated techniques should not be seen as displacing normal design reviews but as providing a different perspective to the owner which is not apparent from the normal engineering specification and cost estimate.

2. DEFINITION OF VALUE

Value can be described as the relationship between satisfaction of need and the cost of resources required to achieve that satisfaction. This can be expressed as:

value = satisfaction of need

               cost of resources

From this relationship it is clear that value can be enhanced by improving the level of satisfaction as well as reducing the resources needed. In some cases the level of satisfaction might be improved to such a degree that an increase in resources is justified. In most cases capital cost is an important resource but operating and lifecycle costs and availability of skills could figure in the equation.

It is worth recognizing that different interests in a project have different needs; for instance a factory manager could be looking for ease of maintenance while the sales manager might value a quicker order lead time. VM techniques seek to provide mechanisms by which these differing interests and needs can be brought together.

3. VM DEFINITIONS

Although the terms value management, value analysis and value engineering are widely used, there is not total agreement on definitions. The European Union is working on an overall approach to the understanding, practice and training for value management within the EU and clarification of terms is expected.

However, it is generally accepted that VM covers a range of value improving practices, particularly those used for early conceptual thinking and the 'softer' front end issues of a project, while VA and VE are more usually used to cover studies of the traditional 'harder' issues at the later stages of design. Commonly, the term VE is used for studies at the project cost level with VA used to describe more detailed component analysis. However, some organizations transpose these terms.

It is possible to consider four broad levels of review as shown in Figure 1. The cost of change at the later stages of design is also greater as design proceeds. Although obvious, this point is often forgotten and expectations can be created that VENA studies at the later stages of design will deliver substantial cost-benefit opportunities. This is unlikely as major changes cannot usually be tolerated because the delay and cost of making changes is unacceptable. This often results in only minor changes of a cost cutting nature being made, which should have been identified by normal design/cost reviews. Thus the distinctive contribution that VM can make is not realized, and at worst the VM process is devalued.

   Figure 1. Levels of review

The reviews can be described as below:

• A technology/business review confirms the business strategy and establishes a broad understanding of the technology and overall operating and other requirements.

• A conceptual review establishes or confirms the overall project scope and, if orders of cost are available, confirms that the broad design and requirements are considered 'good value'.

• A project cost review is a more detailed examination of a proposed scheme carried out when the specific engineering elements have been specified and can be looked at to confirm that the design is optimal in meeting the requirements defined at the concept stage.

• A plant item or component review considers the design of specific items.

4. TIMING OF STUDIES

The opportunity to make savings or other changes diminishes as the project approaches detail design and financial authorization is given for purchase of equipment and other engineering works - see Figure 2.

Figure 2. Opportunity/cost of change relationship within project timetable

5. VALUE MANAGEMENT METHODOLOGY AND JOB PLAN

In general VM embraces three elements which together provide the uniqueness of the approach. These are :

1. team based working;

2. a structured 'job plan';

3. use of the principle of 'functionality' or 'need'.

The first two are not unique and are characteristics of many problem solving techniques. The latter is the distinguishing feature of most forms of VMIVENA techniques. 'Functionality' is used to describe what the component, system, plant or project is trying to achieve. For example, the 'function' of a door might be to provide privacy, provide security, create the right image or a combination of all three. This distinction provided by using 'functional' descriptions is not apparent from the engineering description 'door'. Describing components in this way enables costs of items fulfilling the same function to be added together, thus allowing the owner to understand the overall cost of that function. Taking the previous example, it might be that if an element of the door is primarily for image then other elements that are there for the same reasons can also be included within the functional description. A better understanding of the overall costs and options for providing the image function can be assessed - including that for the managing director's office! 'Functional' descriptions also differ from conventional engineering descriptions in that many items of equipment fulfil more than one function without this distinction being apparent from the cost estimate.

The principle of functionality can also be used to help develop the scope of a proposed project. A successful chemical plant project will not just have the main process function of 'react feed stocks' but will probably have other process functions such as 'recover materials', 'remove impurities', 'achieve product form', etc. There will also be functions such as 'ensure operability', 'make safe', 'protect the environment', 'provide for the future', 'improve customer service', etc. These are all typical functions for a process plant, the costs of which are not apparent from a normal engineering specification and cost estimate. It is these other functions that determine whether an asset will be 'world class' or ahead of the competition and not just a copy of that being used by others. It is critical, therefore, that these functions are properly defined and explored.

It is normal to present functional descriptions in the form of a FAST - functional analysis system technique - diagram. A feature of this type of diagram is that the hierarchy of needs/functions enables costs and opportunities to be understood at different levels. An example of a FAST diagram for a chemical plant is shown in Figure 3. From this it can be seen that 'assure product quality' could be considered at different levels, i.e. change the product specification, change the process technology to give a more effective process, change the equipment type or change the detail design of the selected equipment. All of these present opportunities with different levels of ease of implementation and trade off. This form of presentation gives an enhanced view of the project that is not apparent from a normal engineering estimate.

  Figure 3. Typical FAST diagram

A feature of the FAST diagram is that it is developed from the left-hand side by asking 'how?' and from the right-hand side by asking 'why?' It is this questioning that enables the fundamental purpose to be established. For instance, asking 'why a distillation column?' could give a variety of answers including: 'remove impurities', 'recover material' or 'concentrate the product'. These different descriptions give a quite different perspective of the need for a distillation column and the possible options, e.g. different process, equipment, operating (get someone else to do it) or commercial. A further feature of the FAST diagram which leads to greater clarity is the use of 'verb-noun' descriptions of functions. For instance 'increase product quality', might probably require a quite different solution from 'maintain product quality'.

5.1. The Job Plan

The job plan helps to work in an ordered and systematic way. The main phases of the job plan that are commonly used during design development are as follows.

Information phase

The information phase involves defining the project, gathering the available information, establishing constraints and carrying out a function analysis to describe 'What is it we want the project to do?' rather than 'What are the physical components of the project?' It is at the start of this phase that the level of study and potential team members should be defined.

Creative phase

During the creative phase the team uses the functional descriptions, normally presented in the form of a 'function' or 'FAST diagram' to explore alternative ways for accomplishing the desired functions. 'Brainstorming' is usually used to generate ideas.

Evaluation and analytical phase

The ideas generated during the previous phase are screened and evaluated by the team during the evaluation and analytical phase. Normally, some form of decision evaluation technique would be used to help during this phase.

Development and recommendation phase

During the development and recommendation phase the team reviews the selected ideas and agrees on the proposals to be adopted or requiring further investigation.

Presentation phase

The presentation phase involves the presentation of the agreed design proposal including any outstanding developments.

Implementation phase

It is important to see that the recommendations are developed and progressed during the implementation phase. Often, a lot of energy is put into the first five phases over a fairly short period but as implementation is over a longer period and involves people not involved in the initial review, momentum can be lost.

The job plan is not meant to be prescriptive but is there to help a team to work systematically through the design phase. Judgement is needed to structure the job plan to suit the level of study and complexity of the project.

5.2 The study team and resource

There is a view that studies interrupt the design process. The opposite is the case. Properly set up studies enable the interested parties to come together and conduct a comprehensive and orderly review of the project, particularly at the early stages of design. In many cases the study can take the place of normal design reviews and team meetings. Reviews present the opportunity for people not normally engaged in the design process to be involved. It is only the owner and interested parties that represent the owner's various interests that can change the scope of the project, the engineering team can make recommendations, and then only if they understand the wider aspects of the project.

As for most team based activities, the size of the study is important. Too many or too few participants results in the study being unmanageable or there not being sufficient interaction of ideas. A team of five to eight people is ideal and selecting the team often gives a good insight into who is really important in the project decision process.

The formal team based stages of a study, i.e. construction of the function diagram, speculation and evaluation, can normally be carried out over a half to two days for each phase with breaks to summarize and generate more data. Thus, over a period of one to two weeks, most small to medium- sized projects can be reviewed. In some cases a very detailed analysis of a large scheme down to the component level will take longer, but note needs to be made of previous comments on the opportunity to make significant changes.

6. CONCLUSION

Although the value management techniques that have been described are based on well-established and proven techniques there is the need to recognize that the experience and track record of the 'study leader' is critical to success. For any individual to become proficient and suitably experienced it is recommended that study leaders should be carrying out approximately one study a month. There is the temptation to believe that engineers and designers who have attended a VM training course are able to lead VM reviews. The experience needed to underwrite a sound theoretical under- standing of the techniques can only - as in any activity - be gained through practice and the personal learning that takes place. The techniques need to be used flexibly and with imagination: a too mechanistic application can sometimes miss the issue and the study leader needs to be aware when to adapt the technique to draw out the real issues. This requires the study leader to be able to draw on other techniques and methodologies to support development of solutions to the issues raised by the formal 'function' analysis.