Project Management in Manufacturing using IDEFo

by David OSullivan CIM Research Unit, University College Galway, Galway, Ireland.

Abstract
The failure of newly installed manufacturing systems to live up their pre-installation expectations, has been blamed on a number of factors. One over-riding factor is poor project planning. Traditionally project planning in manufacturing has been facilitated through the use of Gantt charts. This paper looks at one approach to project planning, which utilizes the structured methodology, IDEFo, to model the development process and perform many project planning activities normally left out in traditional planning techniques. IDEFo is a graphical modelling methodology developed for systems design and now used widely in manufacturing for activity modelling. In this paper IDEFo is used for project planning and scheduling as well as some other manufacturing project related issues. The technique helps to create overlapping time schedules and resource requirement tracking. It also help deal with issues such as process variables, decision tracking, and process constraints affecting project activities. The IDEFo approach not only presents a common perspective on project implementation for the various people involved, but also and very importantly in the context of manufacturing, helps to keep track of project goals and objectives.

David OSullivan

1. Introduction
Project managers in manufacturing face a unique array of issues over other types of project manager when trying to plan a project. As with projects in other industries they must match resource availability with the activities to be carried out over a given time horizon. But these are not their biggest problems. Other issues take precedence in most cases. One issue is that due to the nature of the various functional departments involved with projects there is a need for extensive overlapping between activities. Overlapping allows the necessary learning to take place between functions and therefore can reduce significantly the lead time of the project. Another issue is that the decision to develop the project in the first place normally comes through the business strategy. Many variables need to be considered in creating the business strategy. For example is it more important to create automated systems thereby improving order lead time or is it perhaps better to create human centred systems thereby improving flexibility. When a project is decomposed from the primary activity of project into its sub activities then this strategy must also be decomposed. The people responsible for carrying out change within the manufacturing environment are the manufacturing systems design group. Manufacturing system designers are finding new projects increasing in scope for a variety of reasons. Four primary reasons are; (1) technology is becoming more complex with the advent of more computerised processes; (2) competition within the marketplace is demanding more competitive systems which operate at the upper limits of productivity; (3) customers are becoming more demanding thereby requiring new manufacturing systems to become more flexible and have shorter lead times, and finally; (4) major changes within the manufacturing organisation demand that new systems are designed with people in mind. These changes are creating an environment of ever increasing complexity1. To cope in this environment, project managers need to be supported in a number of ways. One of these is the need to provide them with new techniques and tools to assist them in integrating their projects into an existing manufacturing environment. Another is the need for more efficient tools in project planning, which is now identified as one of the key problems in efficient project implementation2. Structured techniques can assist in both areas, firstly in helping create an integrated unambiguous architecture for the proposed new system both from a development and operational perspective , and secondly by tying project management procedures into an overall architecture for the total life of the project.

Page 2

David OSullivan

2. Project Development
Over the past decade a large number of manufacturing systems and sub-systems have been installed by industry. Some of these installations have not lived up to expectations. In fact one source suggests that as many as 80% of Computer Integrated Manufacturing (CIM) projects fail to meet their targets3. New systems have failed to meet cost targets, start-up dates, and subsequent performance. The reasons for these failures are many, however three reasons stand out as being more common than others. These are, - Lack of detailed planning. - Poor execution at the project development stage. - Resistance to change from within the manufacturing facility. Resistance to change suggests that more emphasis be placed on the sociotechnical aspects of project development. Issues such as the calibre and structure of the project team, the involvement of users at the design stage, and the effective exchange of information and ideas with rapid problem solving, all need to be addressed. On the issue of lack of detailed planning, there is a combination of social and technical issues to be addressed. At the social level, issues such as the skills of the project team, their ability to work together as a group, and the ability of their senior management to be flexible and adopt a learning mode of operation, also needs to be looked at. At the technical level a number of issues arise, firstly, the availability of tools and techniques for project managers to effectively control their projects and communicate project information in an effective way to developers, users and management alike. Secondly, the approach to scheduling of the project in order to facilitate the necessary learning now associated with complex, multi-functional projects. With regard to the scheduling of projects evidence now exists that the traditional emphasis by managers on 'sticking' to a schedule is not suitable for projects which by their nature will throw up major obstacles over their duration. The emphasis instead should be placed on viewing the project as a seamless web of activities that can be grouped together in phases and not assigned to functional groups. This along with changes in the approach to the organization of the project team, involvement of users, having a business manager leading and controlling functions directly, and using better, more flexible tools is all leading to a new paradigm for the manufacturing systems development activity.

Page 3

David OSullivan

3. Structured Techniques
Structured techniques are finding many applications in systems which involve the complex flow of information. In the past, these applications have been limited to the service industries such as banking and business units. More recently, however, manufacturing systems have been adopting these approaches in a quest for more organized and unambiguous information flows. One of the reasons for this, is the recognition of manufacturing systems as complex information systems, rather than simple metal cutting workshops. This coupled with the need to create manufacturing excellence for company survival, has meant that manufacturing system designers are under pressure to understand their systems better and communicate proposed changes to other designers and suppliers in a more efficient manner. One structured technique that has become synonymous with the design of manufacturing systems is the Icam DEFinition zero (IDEFo) language4. IDEFo was developed by the US Air Force under its ICAM (Integrated Computer Aided Manufacturing) programme. In this program three inter-related areas of systems modelling were examined and three techniques or methods developed to facilitate designers in carrying out the modelling process. The three were IDEFo for activity modelling, IDEF1 (later extended to IDEF1x) for data modelling, and finally IDEF2 for dynamic modelling of the manufacturing system. IDEFo has become the most widely used of all three and is a variation of a technique entitled Structured Analysis and Design Technique (SADT) developed by Douglas Ross5. IDEFo in fact closely reflects the activity modelling part of the SADT methodology. The diagrams in this report have been developed using the IDEFo methodology. The essential principle of IDEFo is that complex systems can be described in terms of the activities performed in the system and in such a way as to expose detail progressively through a hierarchical decomposition. This means that a model begins with one diagram which describes generally, between 2 and 7 main activities in the system. These activities are then decomposed to expose further detail until the required definition for the system is reached. Diagrams are linked together using a code, so the the reader can search out exactly what detail is of interest, rapidly. Also, because the diagrams have a set method for displaying inputs and outputs the reader can read into the diagram exactly what is important for what ever analysis is being conducted. A set of diagrams for a particular system coupled with text explaining the activity is generally called a model. Figure 1 shows how the inputs and outputs are classified in the model which follows in the next section of this report. Controls are inputs which in some way dictate the execution of the activity. Typically these are requests and directives to the activity. Inputs are used by the activity and converted into the output. The output may also be a function of the control. Finally resources are inputs used by the activity in performing its tasks, typically, people and machines. The difference between inputs, resources and controls can sometimes change depending on the objective being pursued by the designer, and it is this difference that gives IDEFo its power over other techniques, although sometimes designers have difficulty in allocating inputs to either of the three. The remainder of this report will concentrate on the points raised thus far and make use of the IDEFo methodology to create a model of the project development activity. There are of course many other details to the IDEFo methodology, the explanation of which are outside the scope of this paper. Figure 1 : IDEFo Activity Box Convention

Page 4

David OSullivan

4. Application
The development of a system comprising, handling equipment, processing equipment, and a computer system will be presented to illustrate how the IDEFo structured methodology can be applied to the project management function. The methodology will be used to identify tasks to be executed by the project team members. It will also indicate the resources and tools to be used, what inputs and controls are in operation, and the expected output over a given time horizon. This places emphasis on the task or activity to be completed rather than pre-stated time objectives. The development of any system, must be preceded by a request for the system. This must emanate from a body responsible for the manufacturing strategy of the company. Implied in this is a preliminary justification and availability of funds for the project. Once the initial approval or request is made for the new system, the development process can begin. The context for this process is illustrated in figure 2. In this figure two activities are identified. The Operate New System activity, may be seen as an activity that when further decomposed will, yield information on how the new system will operate. This is the technical, operational, and functional description of the system as it should work when installed. Figure 2 : Context for System Development The Develop New System activity explains the approach to project development from a Project Management perspective. It is this activity that is of primary concern in this paper. The inputs and outputs to these two activities have been limited, for clarity. Arrows shown with parenthesis indicate that their effect will not be seen on the lower level diagrams. The Develop New System activity is controlled by a request for a new system. This request can be a simple statement on the performance to be achieved by the new system, or may be a complex statement on the performance, budgetary and time constraints to be achieved. The input to this activity is technology. Technology here implies information as well as physical equipment to be transformed into the output, or in this case, the integrated system. The resources for this activity are system designers, a project manager, as well as any tools and techniques required for development. 4.1. Develop New System Exploding the Develop New System activity, yields two new activities, as illustrated in figure 3. These two activities illustrate the separation of the management or controlling function from the development function. The management activity is typically carried out by a senior business manager with good management skills and proven ability in project execution. The Project Manager will typically select the individuals necessary to carry out the development activities. Figure 3 : Develop New System The resources used by the Manage System Development activity, are techniques and tools usually associated with project management. These include Perth Charts, Gantt Charts as well as guide-lines for the project manager. By using structured techniques, each project management and project development activity can be part of a total modelling scheme and integrated into one unified model for the entire project. The output from Manage System Development are directives aimed at the development activity. These directives may include schedules, schedule changes, strategies as well as requests for status reports. Another output from the management activity will be project status to possibly higher management activities in the company and to the users.

Page 5

David OSullivan

4.2. Develop Sub-Systems The Develop Sub-systems activity is decomposed into four further activities. It is assumed that the new system can be easily and conveniently broken into the activities illustrated in figure 4. Figure 4: Develop Sub-systems The first three activities are concerned with the development of the three main items in the new system. The output from these activities are independent systems which have been designed and developed according to the integrated model which describes the activity Operate New System . This is an important aspect of the total approach being discussed here. While each of the development activities produces specifications and systems they need to be knitted together in the Operate New System model before the next stage can be started. The final activity involves the integration of the systems provided by the development activities. This integration may simply involve connecting the various systems, since the true integration, i.e. Communication and Information, has already been developed through use of the Operate New System model. 4.3 General Schedule At this point in the development of the activities of the project, it is appropriate to present a schedule for the execution of each task. As is typical with manufacturing projects there will be extensive overlapping of activities. Figure 5 shows the main activities discussed so far, against the time-scale of the project. Figure 5: Develop Sub-systems - Schedule From this figure the developer or manager can see the same terminology as that used by the project development and operation model. Precise information on the meaning of each task in the schedule is also available from the model. Further decomposition of the latest activities will expose more detailed activities which when applied to schedules will offer shorter time frames to the developer. The developers are therefore always aware of their position in time, the activities they have to execute, what information they have available to perform the task, what tools they have available or have to use in the performing of their task, and the expected output of their tasks over time. Figure's 6, 7, and 8 shows the expansion of activity A121 and the resultant information and schedule. Figure 6: Develop Handling Systems Figure 7: Develop Handling Systems Definition Figure 8: Develop Handling Systems Definition - Schedule

5. Benefits
The approach outlined, using the structured technique IDEFo, has been used for the development of two projects, each having different development features. The first project involves the development of a large software system for the generation of process plans and optimisation of material flows in a flexible assembly environment. The use of the approach by the design team which is operating in a 'green field' situation, has yielded the following benefits;

Page 6

David OSullivan

1. Each member of the project team understands exactly what tools are to be used in the different phases of development, through study of the IDEFo model. 2. The expected output from each of the different phases are known in advance, thereby helping designers not to stray from their immediate objective. 3. The schedules for the project are related to the overall model, and quick reference is always available for explanation of the activity to be performed. 4. By creating the operational model in isolation from the development model designers are able to concentrate on the operational aspects of the software tools and not confuse this work with development or project management work. 5. Because the schedules are tied to the activities in the model, the time constraint is, to some extent, flexible. This is necessary to facilitate the learning usually associated with manufacturing projects, and emphasizes the need to complete a task rather than satisfy the time constraint. 6. Since the models are basically concerned with the activities found in the operation and development of the project, there is no noticeable differentiation between the functional areas, covered by the members of the project team. Software specialists, information specialists, and manufacturing specialists all form part of one team that covers certain tasks or activities in the model. They add to, or revise the one model as a team. The second project involves the development of software and hardware systems for a factory which is already operating in a complex manufacturing environment. The input of user information and expertise, as well as existing system constraints, become an important factor. The same approach is used, and along with the points described in the first project, yield the following benefits 1. Users are automatically drawn into the design team, since to model the operation of the system it is necessary to examine the role of the user. The user activity, in other words, is one of the primary activities in the model. 2. The users, who normally have difficulty reading functional specifications, are now given a model with a defined structure. Once learned, this model can be read with relative ease, and in a structured fashion. The users are then able to reflect their own ideas, more rapidly, and have them implemented into the model.

6. Conclusion
It is clear that manufacturing system designers need better and more structured planning tools in the execution of manufacturing projects. A number of project development areas need to be addressed and this paper has concentrated on the need to structurally define the activities to be performed by the project manager and system developers and tie them together with a model of the new system. A structured methodology has been used to indicate the approach to the development of a new system. Using structured techniques, activities to be performed during the life of the project are unambiguously defined to the project manager and project developers alike.

Page 7

David OSullivan By using the information in the IDEFo model, system developers can see where their information will come from, what tools and resources they are to use, what output is expected, and at what times. By developing a model of the operation of the new system in parallel with the actual development, developers are able to knit together their respective areas of responsibility, to ensure an integrated system.

Acknowledgements
The author gratefully acknowledges the support of the following bodies, for research into this and other fields of study - Eolas, the Irish Science and Technology Board, Thermo King Europe, and the EC, through its ESPRIT CIM-PLATO project.

References
[1] Hayes, R.H. 'Manufacturing Crisis: New Technologies, Obsolete Organizations' Harvard Business Review Sept.-Oct. (1988) pp 77-85 . [2] Hayes, R.H., Wheelwright, S.C., & Clark, K.B. Dynamic Manufacturing : creating the learning organization The Free Press, New York (1988) [3] Anon, 'Eighty per cent CIM failure rate' Automation Dec./Jan. (1989) pp 4 [4] Ross, T.R. Applications and Extensions of SADT Computer April (1985) pp 2534 [5] R o s s , T . R . Structured Analysis for Requirements Definition IEEE Transactions on Software Engineering Vol. SE-3 No. 1 Jan (1977) pp 6-15

Page 8

David OSullivan Figure 1 : IDEFo Activity Box Convention Figure 2 : Context for System Development Figure 3 : Develop New System Figure 4 : Develop Sub-systems Figure 5 : Develop Sub-systems - Schedule Figure 6 : Develop Handling System Figure 7 : Develop Handling System Definition Figure 8 : Develop Handling System Definition - Schedule

Page 9

David OSullivan

CONTROL INPUT

INPUT

PERFORM ACTIVITY

OUTPUT

RESOURCE INPUT

Page 10

David OSullivan

TOP CUSTOMER DEMAND REQUEST FOR NEW SYSTEM

RAW MATERIAL

OPERATE NEW SYSTEM 2

PRODUCT

TECHNOLOGY

DEVELOP NEW SYSTEM 1 A1

INTEGRATED SYSTEM REQUEST FOR TECHNOLOGY

AO

DEVELOPMENT RESOURCES

OTHER PRODUCTION RESOURCES

Page 11

David OSullivan

REQUEST FOR NEW SYSTEM AO MANAGE SYSTEM DEVELOPMENT 1 TECHNOLOGY INTEGRATED SYSTEM PM DIRECTIVES

DEVELOP SUB-SYSTEMS 2 STATUS AND FEEDBACK A12

STRUCTURED TECHNIQUES AND PROJECT MANAGEMENT TOOLS A1

STRUCTURED TECHNIQUES AND OTHER RESOURCES DEVELOPMENT RESOURCES

Page 12

David OSullivan

PM DIRECTIVES A1 HANDLING TECHNOLOGY

DEVELOP HANDLING SYSTEMS 1 A121 PROCESS TECHNOLOGY

HANDLING SYS. STATUS HANDLING SYSTEMS PROCESS STATUS DEVELOP PROCESS SYSTEMS 2 PROCESS SYSTEMS COMP. STATUS

STATUS AND FEEDBACK

TECHNOLOGY

INTEG. STATUS

COMPUTER TECHNOLOGY

DEVELOP COMPUTER SYSTEMS 3

COMPUTER SYSTEMS

INTEGRATE SUB SYSTEMS 4

INTEGRATED SYSTEM

A12

Page 13

David OSullivan

ACTIVITIES

MAY 89

JUNE 89

JUL 90

AUG 89

SEP 89

OCT 89

NOV 89

DEC 89

JAN 90

FEB 90

MAR 90

APR 90

MANAGE SYSTEM DEVELOPMENT A11 DEVELOP HANDLING SYSTEMS A121

DEVELOP PROCESS SYSTEMS A122

DEVELOP COMPUTER SYSTEMS A123

INTEGRATE SUB. SYSTEMS A124

Page 14

David OSullivan

PM DIRECTIVES A12 HANDLING TECHNOLOGY DEVELOP HANDLING SYS, DEFINITION 1 A1211 TENDERERS SPECS. 2 INSTALL HANDLING SYSTEM 3 CHANGES A121 RESULTS AND STATUS SYS. LAY. OP. SPEC. FN. SPEC. DEVELOP HANDLING SYS. DESIGN SPECS. TO TENDERERS HANDLING SYS. STATUS

HANDLING SYSTEM

HANDLING SYS.

Page 15

David OSullivan

PM DIRECTIVES A121

INFO. REQUESTS HANDLING TECHNOLOGY SURVEY HANDLING SYSTEMS 1 GENERATE GENERAL DESCRIPTION 2 GENERATE GROSS DEFINITION 3 SURVEY INFO. CHANGES GENERATE FINE DEFINITION 4 INFO. REQUESTS TRIP REPORTS AND STATUS GEN. DESC. AND STATUS RESULTS AND STATUS

SURVEY'S STUDY GROUPS

GROSS DEF. AND STATUS

SURVEY INFO.

FINE DEF. AND STATUS

SYS. LAY. OP. SPEC. FN. SPEC.

A1211

Page 16

David OSullivan

ACTIVITIES

MAY 89

JUN 89

JUL 89

AUG 89

SURVEY HANDLING SYSTEMS A12111 GENERATE GENERAL DESCRIPTION A12112

GENERATE GROSS DEFINITION A12113

GENERATE FINE DEFINITION A12114

Page 17

David OSullivan

25th March 1991 Angela Jamieson, Executive Editor, Butterworth-Heineman Ltd., PO Box 63, Westbury House, Bury Street, Guildford, Surrey, GU2 5BH, England. Dear Ms. Jamieson, Please find enclosed the completed paper as per your referees comments. I hope that this paper now meets with your approval. If you have any additional comments or changes please do not hesitate to contact me. Yours sincerely David OSullivan

Page 18