Managing factory automation projects

Managing Factory Automation Projects Jack R. Meredith, University of Cincinnati, Cincinnati, Ohio

Abstract

Implementing advanced manufacturing technologies such as flexible manufacturing systems and CAD/CAM has been much more difficult and lengthy for companies than expected. Out of necessity, firms have thus turned to project management approaches to achieve the benefits of these automated systems within reasonable time and cost limitations. In general, project management has worked well for such complex systems, particularly where standard project management tools have been employed in the process.

This paper illustrates the major project management concepts and techniques used in a number of industrial automation projects. The focus is on project planning, implementation, and control, including the issues of budgeting, scheduling, resource allocation, monitoring, information system design, and post-auditing.

Keywords: Project Management, Factory of the Future, Automation, Justification, Champion.

Introduction

Installing and implementing factory automation systems such as computer automated design, flexible manufacturing systems, group technology, or manufacturing resource planning is one of the

most lengthy, expensive, and complex tasks a firm can undertake. An FMS, for example, can easily run over four million dollars for the most elemen- tary system and require over two years to install and implement. More typical systems are two to ten times as expensive and take over twice as long to install.

To mainta in managerial control over the implementation of such systems so that the firm obtains a reasonable payback on its huge investment requires excellent day-to-day management on a constant and continuing basis. In essence, the implementation manager is attempting to reach specified performance targets within certain time and cost constraints, as illustrated in Figure 1. For an FMS, for example, the performance targets may relate to system utilization figures, successfully operating software and hardware elements of the system, throughput times, number of FMS-complete parts put across the system, work-in-process inventory reductions, and other such measures.

Time is another critical element of the implementation, and one which the manager has little control over. By and large, the implementation process starts slowly, gathering momen tum as plans are initiated and people added to the team. As shown in Figure 2, progress accelerates as many of the initial and easier tasks are accomplished without running into major difficulty. However, as the implementation midpoint passes, the more difficult tasks start dragging beyond their due dates and slow down the

75

Journal of Manufacturing Systems Volume 6/No. 2

/

"c/Required ~.LPerformance

%%%

s S

/ ..-" I fsud e, / ' . . - ' " I / .,m,t t" V

)ue Date

Figure 1 Performance, Schedule, and Cost Targets

overall rate of progress. As the project nears completion some of the problems defy solution and delay the completion interminably.

This attempt to reach certain performance targets within time and cost limitations is one widely recognized characteristic of projects. Other elements of factory automation implementation are also common characteristics of a 'project': a unique, onetime activity with a well-defined purpose, con- sisting of subtasks that must be carefully coordi- nated and controlled in terms of timing, precedence, cost, and performance3 Indeed, not only is the implementat ion of an advanced manufactur ing automation technology a virtual project; it may well be the biggest, most complex project the firm has ever attempted.

However, because the implementation of factory automat ion is a project, there are a number of project management tools, concepts, and procedures that can be extremely helpful to the manager in this process. These are discussed and illustrated below. The discussion is divided into four primary sections: initiation, planning, implementation, and control.

A ,

IO

J

Time

Figure 2 The Project Life Cycle

Initiating the Automation Project A number of activities must, of course, precede

the implementation project and are briefly noted here. Since these activities are covered adequately in the literature and are not the major focus of our attention in this paper, they are covered only briefly. For more detail on these activities, consult the references indicated in each of the subsections below.

Company Goals and Strategy. Ideally, the automation project is the logical outcome of a business strategy that can best be achieved through factory automation. For example, the firm has con- c luded that shor t lead t imes and ind iv idua l customization will be the telling competitive wea- pons in their marketplace in the near to mid term future, say, two to seven years. Therefore, they need to totally change the way they produce their products if they hope to compete in this market and automation holds the key to this ability.

Unfortunately, the general state of the art of manufacturing strategy (see References 3-5) simply does not seem to be this sophisticated, though some individual firms may be. Much of the automation that has been installed in factories to date was

76


selected because of less complex reasons: the firm sells such automation and needs to show that it uses what it sells, the military wants its contractors to use automation, a firm's competitors are using automation and the firm doesn't want to fall behind, and other such reasons. However, based on the experi- ences of these early adopters, more is now known about the strategic benefits and costs of automation so other firms can employ these technologies more knowledgeably in their planning.

Automation Champion. In most of the successful automation installations to date, there has been a 'champion '~'* who has spearheaded the project, sold it to upper management, protected it when it was threatened, and kept it going until it paid off. This person is usually not the inventor or originator of the automation, but is often the visionary, sales- man, sponsor, and godfather of the project until it proves successful in bringing the firm to the point of competence the champion has foreseen. In small firms, the champion may also play the role of the project manager.

The "As Is" Study. This study I° is simply a careful, realistic review of how the firm actually makes its products and services. Though usually felt to be unnecessary, almost every medium to large sized firm is surprisingly ignorant of how their prod- uct is really made. Employees who know the activities on a task level do not have the breadth to see the overall process, and managers who have the breadth are typically not familiar with individual task elements.

The 'as is' study has a number of uses in the automation project. First, if conducted properly, the study identifies existing weaknesses in the firm's production process and its management that need to be rectified before automating the process, or seg- ments of the process. These improvements are often more significant in their benefits and cost savings than the automation, and may even make the automation unnecessary. Also, the study helps indicate where automation may be most advantageously applied in the firm's production process and thus, contributes to the justification study. Last, it provides a basis for later comparison and audit to determine the actual, realized benefits of the automation.

The "To Be" Study. This study includes an assessment of existing technologies that can address

the problems, opportunities, and needs identified in the 'as is' study. Through detailed analysis of these technologies, two plans are drawn up. The 'long- range" plan identifies the best current estimate of what the eventual form of the company should be to compete in the future, taking market trends, com- petitor's actions, and environmental changes into account. It is expected that this long-range plan will evolve as time progresses to fit actual trends as they occur and unexpected changes that impact the firm. Of course, the long-range plan is always a plan for the future, not the current, and thus is the guide for the 'short-range' plan.

The short-range plan is the key to achieving the long-range goal; that is, it is the link between the current and the future. The short-range plan is what is proposed for immediate funding, with the long- range plan being understood as the goal. Pressing concerns in the short-range plan include compatibility with present capabilities and strengths, as well as compatibility with the long-range capabilities. However, present capabilities must not constrain the selection of short-range goals or the long-range plan will never be realized.

Pro]ectSelection. For the problem of selecting the most appropriate technology to achieve the 'to be' short-range plan, there are a number of models available. 2,''. One of the simpler approaches, an unweighted 0-1 factor model, is illustrated in Figure 3. Other approaches scale the contribution of the factors to the firm's goals, weight the factors in importance, or even employ mathematical programming techniques that maximize some objective subject to certain resource and other constraints.

In practice, both qualitative and economic factors (required investment, payback, ROI, etc.) are certainly considered, but superordinate objectives often make the difference in the selection of the technology. Examples include the need to obtain experience with the technology, what competitors are using, the image the technology brings to the firm, and so on. This relates directly to the justification exercise.

Justification. The justification of the automa- t ion project has frequently been the biggest stumbling block to implementing the firm's strategic plan. Caught in a strangling web of accounting and financial procedures, precedents, and regulations (many of them policies the firm itself instituted),

77

Journal of Manufacturing Systems Volume 6 /No . 2

Factor

Cost less than budget limit X Payback less than two years

Throughput less than two days X

Flexibility: Volume X Material Part X Sequence X Mix X Design X Defects

Vendor availability X ÷ Impact on firm image X

Totals 9

Does Not Qualifies Qualify

X

X

X

3

Figure 3 Project Selection by Unweighted, 0-1 Factor Model

managers seem unable to either circumvent the traps or adequately satisfy their requirements in order to proceed with the plan. ~2J~ This is largely because automation is frequently hardware driven and hardware has historically been justified on the basis of either cost reduction or capacity increase, thereby requiring accounting verification. However, the benefits of these new automation technologies often have nothing to do with costs, nor capacities, and so they stumble in the unnecessary pitfall of cost justification.

A number of new approaches are making headway against this problem and include analytic as well as strategic techniques and procedures. They are too numerous to describe here; refer to Refer- ences 13-18 for their description and details.

Project Manager Selection. Much has been written about the necessary qualifications and skills of the automat ion project manager3 However, in any project the best choice for manager is that person who has the greatest chance of successfully completing the project. Technical skill in the automation technologies is valuable, but more impor- taqt is the ability to work with and through people. If automat ion is the key to the future, p.eople are the key to automation. As most project managers already know, people are both the biggest obstacles to automat ion and the best solutions - it is the job of the project manager to avoid the former and achieve the latter.

Additionally, prior experience with the technology is a big plus. And experience in implementing any new technology in the firm is particularly valuable. In small firms, the technology 'champion' is also often selected as the project manager, which gives that person a greater range of power and influence.'"~' More discussion about the job of the project manager is included in the next section.

Project Planning It is generally believed that more automation

projects have failed due to poor planning than from any other reason. The temptat ion with a big, difficult project is to 'get on with it' and time spent planning the project doesn't bring any feeling of progress. Though all projects follow the standard 'time distribution of effort ' curve shown in Figure 4, with automation projects it is worthwhile to spend extra time in the planning phase, as indicated by the dashed line in the figure. The result is a decreased level of effort and a shorter implementation time over the durat ion of the project, as further indicated by the dashed line.

A common phrase in factory automat ion cir- cles is "plan from the top down, implement from the bot tom up". This statement gives further emphasis to the planning stage of the project and its importance in successful implementation. The planning for automation commonly includes the requisite

~o Peak effort level

"6 s "~ t S

I I I Planning, scheduling, I Evaluation I I .~p .=4,= l~ , ,o - - monitor ing, control - . 4 . 1 - - a n d ~ . l

i I terminat ion Conception" "°-'eSel ction

Figure 4 Time Distribution of Effort

78


hardware and software, but is usually deficient on two other items: systems integration and organizational aspects. For simplicity, we will refer to these items as 'systemsware' and 'orgware' (the latter phrase was coined by Tom Vollmann of Boston University).

Hardware. The planning for the hardware elements was partially described earlier. Here we are concerned with acquiring equipment that will attain the short-range goals of the firm, yet be compatible with and incorporate existing equipment as much as possible. Unfortunately, too many firms take the compatibility issue too far and actively search for equipment that simply upgrades existing processes and procedures, fitting into the existing system as smoothly as possible. This is a serious mistake and compromises the short-range plan to an unacceptable level. The project team must remember that with automation we are looking for greater effectiveness, i.e., stronger competitive ability, not higher efficiency.

Another hardware issue that is relatively unique with automation is the potential 'synergy' that various hardware elements bring to the process. There are many examples: tying automation with just-in-time production, combining CAD with CAM, using group technology with cellular production and classification/coding systems, and so on. What this synergy does is significantly increase the benefits to the firm, 22,23 allowing a faster investment payback and accelerating the achievement of the short-range plan. It is this synergy that contributes so highly to the effectiveness of the automation, yet is difficult to plan for or anticipate in the justification process.

However, just as the synergy of the combined hardware elements is one of the primary advantages of automation, the extensive amount of integration that is required creates the major hardware (and other) problems too. This extensive integration gives rise to significantly more problems that are considerably more difficult to solve than with standalone equipment. When a solution to a problem is attempted, the change in the hardware has impacts throughout the automation system that alter other elements of the system and create new difficulties. And combinations of elements give rise to problems that would not have been problems in standalone situations.

One last phenomenon is worth mentioning. Ifa problem occurs anywhere in the project, it is ulti- mately seen in the hardware. If inadequate training is given, the system will not correctly produce the parts, or fast enough, or with adequate quality, or so forth. If the software hits a bug, the.machines perform incorrectly. Thus, the acid test of all planning and activity is the proper performance of the hardware in producing parts. However, to solve problems at this stage is extremely expensive. The incorrect mechanical performance is a symptom that points to other problems that point to earlier deficiencies and so on. Nevertheless, this has frequently been the way automation has been installed and accounts for the common rule of thumb that an automation project will take approximately twice as long to implement as expected.

Software. Software is typically considered to be the most difficult technical aspect of any automation project. As one expert has noted: t* The probability of project completion on time and within budget is primarily a function of the amount ofttew, unproven software.

One of the problems is simply that software is extremely difficult to debug; sometimes months of successful running go by before a fatal bug is acti- vated by an unusual set of circumstances. This can- not be eliminated and the wise project team will simply plan on these events occurring and expect to correct them on site.

Another problem is the difference between coding and user-friendly coding. Plans are usually drawn up based on the minimal amount of coding required to perform a task. However, experience has shown that if pieces of the software must be user-friendly, these sections will require two to three times as much coding as the minimal plans.

Along this line, when bugs are discovered in the coding they are rarely properly corrected. Because of the crush of time pressures, they are usually 'patched' instead, temporarily fixing the difficulty, but leaving a long-term mess in the software. And later, when there is time to come back and repair the patches, the programmers are typically transferred to another task or project so the bugs and patches never are permanently addressed. Further down the road, someone will want the software modified, or extended, but no one wants to touch the project because they know of the mess and

79


resultant traps lying in store for anyone who tries to alter the code.

Another software difficulty is incompatibility between systems. There are three primary software systems in an automation project: the engineering software, the business software, and the manufacturing software. The engineering software consists of part programming for the workpieces, tool delivery, etc. The business software includes cost accounting, order entry, management reports, and so on. And the manufacturing software consists of materials requirements planning (MRP), bills of material, expedite lists, and so forth.

Trying to tie these systems together can be pure torture. Many of the systems are programmed in different languages, use different databases, and interpret commands and phrases differently. For example, it is not unusual for firms to use three different part numbers to refer to the same part. Purchasing uses a system that describes the information they need to order the part. Manufacturing uses a system that tells them how to produce the part. And engineering uses a system that gives them information on the capabilities and characteristics of the part. This incompatibility problem is one step removed from the manufacturing automation pro- tocol (MAP) project that General Motors and the Society of Manufacturing Engineers are working on, so the success of MAP still won't solve these problems.

Systemsware. The difficulty of compatibility between systems has made many firms sensitive to the 'systems' issue. Factory automation is essentially the task of taking standalone systems and integrat- ing them. As just described for software above, this can be an extremely difficult problem and includes not just software but hardware elements, procedural aspects, and even organizational issues (addressed in the next section).

A common solution to many system problems has been tradeoffs between the elements of the automation system. For example, using probes on the machining centers to precisely locate parts, trades off machine utilization with labor and hardware effort to precisely locate parts through a number of hardware interfaces: part to fixture, fixture to riser, riser to pallet, pallet to cart, cart to machine shuttle, and shuttle to spindle head/tool. There are a number of such tradeoffs that can be

made and it is imperative that the right ones be chosen or months of effort can be lost in the implementation schedule. The most common tradeoff involves altering the software to solve a problem somewhere else in the system. It is not unusual for part programs to be rewritten 20 times before smooth system operation is obtained for the single part.

A number of vendors, aware of the systems problems, are attempting to fill this role of systems engineering for their customers. Today machine tool manufacturers, materials handling vendors, software firms, and many others are vying for this crucial role of systems integrator. And there are a number of elements that must be integrated in automating a factory. For example, to install an FMS requires the consideration of system elements such as: machining centers, wash station, coordi- nate measuring machine, computer system, pallets, risers, material handling/cart system, chip and cool- ant system, load/unload stations, fixtures, fixture build stations, tooling, tooling station, tooling delivery system, A S / R S warehousing, plant preparation, user training, part evaluation, and software.

To address all these elements requires that the project manager prepare a work breakdown structure (WBS) for the various system elements, as shown in Figure 5. The WBS forms the backbone of the project and gives it the structure needed for planning. The project master schedule, cost breakdown, work organization, and many of the other elements of the project can then be derived from the WBS.

The key for keeping the project on target is for the project manager to keep all the system elements in balance. It has been found that no one area in particular is more sensitive than the others, but if any one gets far out of balance, it can easily stall the project and create major problems. Thus, it is crucial for the project manager to clearly identify all the system elements and interfaces early during the planning stage and maintain continuing control over them.

Another lesson learned from other automation implementation projects is that it is best, whenever possible, to use existing procedures and systems to aid in implementing new automation elements. For example, rather than trying to force a policy deci-

80


I FMS PROJECT ]

Function- al

Support

I !

I ! ! ! ! !

Project Mgmt. Office

I

! | t ! !

Advnc'd Mfgng.

Systems

I

Figure 5 Work Breakdown Structure for an FMS

sion for lower lot sizes through the firm, it is better to let the computerized lot-sizing algorithm calcu- late smaller lots by simply inputt ing a lower setup time and cost. Lead time changes and other such factors can be similarly handled.

Orgware. Organizational issues of project management, including the human aspects, are probably the most critical, yet the least recognized by most firms. Human issues in particular are con- sistently identified as the biggest problems in implementing automation. And education in all forms has constituted the large majority of the total automation effort in most installations to date.

Because of its wide level of integration, automation affects virtually all aspects of a firm's operation. To obtain the significant potential benefits that these new technologies offer, the firm has to change the way its people work and do their tasks, if not the tasks themselves. Automation touches almost every-

one and extensive change is required. However, people do not usually like to change and can resist it to the point that the automation benefits are not realized. To facilitate this change and its acceptance among the firm's people, new incentive and motiva- tion schemes need to be installed that reward people for using the automat ion and bringing its benefits to fruition.

An important issue in this regard is the matter of when to bring people into the automation plan. Standard implementat ion advice is to bring everyone in early so they understand what is happening, why, and how they will be affected. However, in practice this has wasted a lot of time when the automation design kept changing. When this hap- pens, the people start getting frustrated and lose interest in the project; besides, they still have their regular job to do. It is now felt to be better to bring people into the plan at a time more appropriate to

81


their unique interface with the new system, i.e., still early enough for their input to make a difference, but not so early that the decisions at that point are irrelevant to their activities.

Another major element of the organizational aspect is the role of the firm's infrastructure--its ru les , p r o c e d u r e s , sys tems , and f u n c t i o n a l organizat ion--in supporting the automation project. :4,~5 Researchers have noted the importance of the existing infrastructure in supporting the implementat ion effort and its contribution to the success of the project) 6 Unfortunately, most firms do not have an infrastructure capable of supporting automation and those who have tried have usually had to go back and improve their infrastructure to handle the additional burden that these new technologies place upon it in terms of quality, timing, consis- tency, and so on.

Altering the infrastructure to support the automation project is one of the major responsibilities of the project team. Based on the work breakdown structure, or WBS, all the project subtasks define who should be on the project team and what their responsibilities should be. This information is captured in the 'linear responsibility chart', illustrated in Figure 6 for an FMS project. This chart shows not only the primary responsibility for every required project activity, but secondary and notifi- cation responsibilities as well.

Once the project team has been assembled, there is the question of its place in the organizational structure and its reporting responsibility. There are a number of organizational schemes that can be used and seem to work acceptably. The simplest and often most acceptable for small projects is to form the project team as a special activity that reports to a high level manager. Yet, some firms, such as con- sultants, only do project work and organize their firms as team of projects. However, factory automation typically does not fit either of these roles.

A better organizational arrangement for a project of the scope of factory automat ion in a typical manufacturing environment, that is, one organized by function, is to start a matrix organization. This preserves the functional organization, yet allows for growth of the project form as additional change is needed. That is, there may later be an office automation project, or a marketing technology project, and so on. This form is illustrated in Figure 7. As can be seen, the project draws on and interacts with all the functional organizational entities, thus maximizing representation and communicat ion as is typically required with a factory automat ion project. The project manager can either report to an overall program manager or else the president or other high- level executive in charge of the functional groups.

The project team usually includes representation from each of the functional areas plus a manu-

Individual

Task

Establish project plan

Define WBS

Set hardware specs

Set software specs

Determine schedule

Assign personnel to project

Install equipment

Note: I : responsibility 2 - notify

. m

3 2 2 I

2 2 2 I 2

3 I 2 2

I 3

2 2 2 I 2

3 I 2

2 2 !

3 = approval

Figure 6 Linear Responsibility Chart for an FMS

82


I %

Program t Manager t

I % ,o

i " ! : ( AuFta°Ctm~rt iY° n ~ 1 I

o i I I I 0 I t • o I I I Office • 0 I" "~ Automation / - - - -0 I I • / I I • o I I I

President I

I I I

Engineering I I Manufacturing

I

I I I I I

I . . . . I o I I I o I

I I Marketing

I I I I

I I I e I I I I I I

Figure 7 Matrix Organization

facturing engineer, project controller, software engineer, vendor representative/project manager, plus the project manager. The representation may be full or part time, depending on the size of the project, but the project manager must be full time. (If the project is small, the project manager may be responsible for other projects as well, but must not be a part-time project manager.) Automation projects commonly run from 2-5 years and top management must be committed enough to the project to keep this team relatively intact the entire time. Under no circumstances should the project manager be changed during th.is period or significant progress will be lost; the entire project may even fail.

In addition to the difficulty of change for the people external to the project, there are also significant conflicts among the project team personnel throughout the life of the project. Typically, general conflict concerns administrative policies and technical performance early in the project's life, priori- ties and schedules in the mid-life period, and then mainly the schedule near the end of the project.

These conflicts are illustrated in more detail in Fig- ure 8. In large part, they also reflect the project manager's concerns: performance at the start, costs midway through the project, and schedule slippage at the end.

Project Implementation Project implementation follows planning and

consists, here, of budgeting, scheduling, and resource allocation. Though these are requisite planning activities, they also occur throughout the life of the project and thus we include them in the implementation tasks. The activities of day-to-day monitoring and control are discussed later.

Budgeting. Budgeting is a continuous activity for the project manager. Initially there is an estimate of overall project cost and its probably range, as well as estimates of individual activities, but as the project progresses, this estimate, and its outer limits, are modified to take account of actual events, as shown in Figure 9.

83

Journal of Manufacturing Systems Volume 6/' No. 2

. 4 -

) _>

0J

t - i n

O

. 3 -

.2

.1

0

Start

m

-

=_ o ? ~

= == E _=_=1~.1 6

o o_-_

0 0 0 0 0 ~J L~ lJ L) ~J ~L

At the Project Formation

X._._

I

l

I i

>

¢.:~ ¢. o.

At the Early Program Phases

Program Life

\

During the Main Program

x _ . . , _ . . . .

Average Total Conflict

l

---

T o w a r d the End of the Program

Finish

Time

Source." Thamhain, H.J. and D.L. Wilemon, "Conflict Management in Project Life Cycles", Sloan Management Review, Summer, 1975.

Figure 8 Conflict Intensity Over the Project Life Cycle

to t 1 t 2

Project cost

Figure 9 Estimates of Project Cost at Times t 0, t 1 , t 1

The data that comprise these estimates are based initially on the work breakdown structure and overall project schedule to identify monthly cash flows as shown in Figure 10. As actual results come in, a form such as Figure 11 is used to track the actual costs and variances. The variances can then be highlighted for management attention and investigation.

Scheduling. As with the budget, the WBS also provides the basis for the project master schedule, shown in Figure 12. The individual activity times are first determined and then precedence relations are considered to time phase the activities. Milestones are identified on the schedule and overall project completion is determined. The standard project scheduling models such as PERT (program evaluation and review technique), CPM (critical path method), and precedence planning can be used to identify critical activities, slack resources, probabili- ties of completion, and so on. These models are well

84


A (100.00) B (110.00) C (120.00) D (200.00) E (300.00) F (310.00) G (310.00)

Est. ($) Jan Feb Mar Apr May Jun

A 33 12 8 13 B 16 7 9 C 45 5 18 12 10 D 122 37 55 25

Jly Aug Sep Oct

5

Activity

Totals 756 12 25 62 108 146 111 98 • • •

Figure 10 Monthly Project Activity Budget

Month of April, 19XX

Activity (acct. #) Actual Budget Variance (-)

Totals

Subproject

Determine Need

Solicit Quotations

Percent

Figure 11 FMS Monthly Budget Report

Write Appro- priation Request

Determine tooling COSTS

AI

A2

BI

CI

C2

Task

Find operations Industrial that benefit most

Approx. size and Project type needed Engnrng.

Contact vendors P.E. & review quotes

Tool Design

Responsible Dept.

Dependent Dept.

I.E.

Fin.. I.E. Prchsng.

I.E.

I.E.

Tool Dsgn Fin. I.E.

Determine labor I.E. savings

Actual writing P.E.

Figure 12 FMS Project Master Schedule

Legend: * Project Completion o Milestone Planned i"1 Contractual Commitment • Milestone Achieved A Planned Completion Planned Progress • Actual Completion Actual Progress

Status Date

85


described in the literature (e.g., see Reference 2) and will not be detailed here.

In terms of overall scheduling, it should be understood that these time estimates, except for very small projects, are in reality aggregations of subtasks that themselves form a project, as illustrated in Figure 13. And even these subtasks may themselves be projects comprised of interdependent activities for the individual doing the work. The complexity involved is, unfortunately, more complex, however, since any of the subtasks can be

i i

, , Level 1 Plan

• i

/ I

,," Level 2 Plans

i j . ,

• Level 3 Plans

Source." H a r r i s o n , F.L., Advanced Project Management, Gower , 1983.

dependent on another task in the project that is someone else's responsibility. Nevertheless, the project manager must oversee these activities, keep them on schedule and budget, and take these interactions into subjective account when trying to solve the inevitable problems that arise in the project.

It is important for there to be regular (usually monthly) progress meetings among the project team and other involved persons, including the vendors. It is at these meetings that problems are discussed and solutions suggested so everyone knows about them and can state their concerns from their perspec- tive and responsibility. When the air has been cleared, the schedule is reviewed and new time estimates are obtained from the people responsible for implementing the project activities and any solutions for the problems. If the new time estimates are unacceptable to someone on the team, then alterna- tives can be discussed, such as expediting the activities or sidestepping that problem for the moment.

Resource Allocation. As with the budget and project schedule, the resource requirements and their timing can also be largely derived from the WBS. The result is a 'load chart 'as shown in Figure 14. The load chart is planned for the nominal completion date of the project, but there is obviously a tradeoff between the completion time and the resources available for the project. A higher level of resource availability will allow some expediting of the project, but not in the same proportion that less resource availability will extend the project. Further-

8

7

el 51

4

3 Spec. & Install.

2

1 Development

0 Jan. Mar. Ma,

19X3

. . . .

Tooling

( NC Programming

& Install ] Spec

System Coordination

July SePt. Nov. Jan. Date

1 March May 19X4

Figure 13 FMS Activity Aggregation/Disaggregation

Figure 14 Load Chart for an FMS Project

86


more, withholding resources to some capacity limit may keep some resource costs within bounds, but will usually tend to increase other costs at the same time, as described further below.

The problem of obtaining the needed resources for a project is a continuing one for most project managers and one to be expected. However, with automat ion projects, there are some personnel resources that are especially critical for success. One is maintenance personnel, particularly electronic maintenance. These people are typically in short supply and may need additional training to cope with the complexities of the new advanced manufacturing technologies.

Another skilled resource that is particularly crucial to automat ion is programmers, both part programmers and software programmers. Though more plentiful than electronic maintenance personnel, many more programmers are usually needed as well. Furthermore, as implementation starts to drag and the problems require software solutions, additional programmers are often required beyond the upper limit of what was expected in the proposal.

In general, most factory automation projects tend to slip about 100% in their completion times. Unfortunately, major elements of the cost for automation projects are almost directly related to its implementat ion schedule at a rate of about two to one. Thus, a schedule slippage of 100% can easily translate into a cost increase of about 50%.

Controlling the Project Managing a factory automation project has

been likened to steering a tub through rapids: the tub doesn't move easily or in the proper direction and the obstacles, some visible but many hidden, come quickly and without warning. In such an environment, all the tools of good project management are a welcome help. A crucial tool for the project manager is a good, responsive information system to let the manager know what obstacles are coming up, what obstacles have already hit the project, and where the project is 'leaking' or in danger of failing.

Use of Information Systems. There are a number of computerized project management information systems available these days (see Refer- ences 2, 27, 28). Most of them can be used on a

microcomputer and display a tremendous amount of capability. In addition to monitoring activities and costs, these packages help plan, schedule, budget, allocate resources, print tables and graphs, prepare reports, and a number of other functions that are valuable to the project manager.

In addition to helping prepare and analyze the PERT or CPM schedule, they also are valuable for replanning as the project starts deviating from the baseline plan. In much the manner of a spread sheet program, changes in the schedule, costs, and activities can be easily input and quickly reanalyzed for alternative solutions. Or in the same fashion, sensi- tivity analyses can be performed in the planning stage to determine which activities are critical or particularly sensitive to environmental changes.

Interfaces. The automation project manager doesn't have the time to oversee each of the project activities and instead works primarily at the interfaces between activities, personnel, departments, and systems.:9 This is typically where the ball gets 'dropped ' and problems arise: the customer meant something different than what the contract implies, department A is not giving department B what they need to perform their job, top management feels some activities should be curtailed and want an oral report, and so on.

A tool that can help the project manager anticipate where these problems are likely to arise in the project is the TREND diagram, an example of which is shown in Figure 15. This tool considers three elements that typically give rise to problems in projects. The first is the interdependence between project elements--which activities are dependent on earlier activities. This information can be taken from the WBS.

The second consideration is the uncertainty of each of the activities, again, usually available from the WBS and taken as the pessimistic activity time estimate less the optimistic estimate. The third factor is the prestige level of the people performing the activities, which can be found from the linear responsibility chart and an organizational chart.

Interface problems typically occur where a more prestigious person is dependent on a less prestigious person, or vice versa. Or, given the same two parties, problems can arise if there is a high level of uncertainty in the preceding activity. These rela- tionships can be illustrated on the organizational

87


High Uncertainty

I - - q Low Uncertainty

__J r F . Quality =nance Control

i Inspectors

t

1 1__

l ngineering -

Plant Manager

b 1 Project Mgmt.

Prestige V.

High

Figure 15 TREND Organizational Overlay of FMS Activities

chart as shown in the figure and special coordination arranged by the project manager for those critical interfaces, as indicated in Table 1.

Automat ion projects are somewhat different compared to other projects in that training on the new systems is almost a continuing activity and a key element of success. Virtually everyone in the company needs to be educated about the firmwide changes that automat ion will bring and how to conduct their work in the new environment. Since the implementation is a multiyear task, the training must also be conducted over an extended time frame. Early training in the ultimate system (which may never be achieved anyway), is premature and will not be useful to those who need to cope with the first interim system. The project is best perceived as an evolutionary change, with people and systems evolving together over an extended period.

Monitoring. As noted earlier, a highly responsive information system is needed by the project manager to head off problems and circumvent obstacles. Some tools are available to analyze the

information provided by the information system and help the project manager determine which activities are in trouble and which are not.

First is the 'earned value' chart, which displays both actual cost and value for comparison with planned cost and value. An example is shown in Figure 16. The difference between actual cost incurred and baseline cost is clearly an important variance in which top management is particularly interested. However, this figure doesn't account for actual progress, a factor given by the 'value completed' curve on the figure. Clearly, if value completed is ahead of schedule and cost incurred is too, management will be less concerned than if value is behind schedule, but cost is ahead. The relationship between the three curves yields three different variances, each of which tells a story of its own.

The total variance is of particular importance to the financial executive since this person must provide the cash needs of the project. The schedule variance, which can also be translated into a time variance as shown in the figure, is of special interest

88


Table 1 TREND Interface Coordination Required of Project Manager

Effect

1. Quality Control Manager/Tool Design: different functional areas, mixed uncertainty, low status depend on high status

2. Project Engineer/Purchasing Manager: different functional area, mixed uncertainty, reciprocal dependence, different status

3. Project Engr. Mgr./Project Engrs: same functional area, high status depends on low, same low uncertainty

Required Coordination

Set up interfunctional system for coordination and monitor regularly.

Set up regular review meetings for coordination with project manager chairing the meetings

Depend on regular authority and information structure. Stay current, frequent talks.

to marketing/contract administration because it indicates whether the project will be completed when promised. And the spending variance is of interest to the controller because it indicates how efficiently the project is being managed. Top management is, of course, interested in all three, but particularly the last two: can we deliver when we said we would and will we make or lose money on the project?

Another valuable monitoring tool is the critical ratio measure. This measure can be defined in a multi tude of ways to suit the needs of the project manager, but one common approach is shown in Table 2 where the ratio considers both cost and progress compared to baseline. If either measure gets out of line with respect to the other, the value of the critical ratio deviates from 1.0. Values less than 1.0 indicate a problem, values greater than 1.0 indicate an unexpected bonus (but should nevertheless be checked).

A tool for monitoring the critical ratio above is the control chart, two examples of which are shown in Figures 17and 18. In Figure 17, the critical ratio is plotted over the course of the project and limits for various levels of action are plotted on the chart. These limits may be determined arbitrarily by the project manager or by general management agreement.

In Figure 18, total project cost is monitored on a regular basis with limits for management action or intervention plotted on the graph. These limits may be managerially decreed or statistically related to the normal cost fluctuations of the project, for example, three-sigma limits based on similar projects conducted in the past.

T h e P o s t A u d i t

A valuable element of the implementation process is a post audit of what actually occurred during the project and why. This audit, conducted six months or so after the project ends, gives management some insight into organizing and conducting future projects, as well as feedback on the conduct, problems, and benefits of the subject project. For automat ion projects in particular, because of their extended duration, a mid term audit conducted at the middle of the project (when the project was expected to be completed) would also be valuable.

~ n (Baseline)

Actual ~ .~/ . . . . . . . . C o s t - . F-7-1 . . . . . . . 1

",iiJ r / L Total I . . . . . . / r / r Variance I Spending Variance or / ( " - - - I . . . . . . . ~" C_°S_t_Q.v.er_r_un ~4 / L Schedule | (quantity and price)

J

I I i I I i I ~,1~/ 1 2 3 Time Month

Variance (10 day delay)

Figure 16 Earned Value Chart for an FMS Project

89

Journal of Manufacturing Systems Volume 6 / N o . 2

Table 2 Critical Ratio Examples and Interpretations

(Actual Progress/Scheduled Progress) x (Budgeted Cost/Actual Cost) = CR

AP/SP x BC/AC " CR Interpretation

x 6000/4000 = 1.00 Actual progress less than schedule but cost is correspondingly less than budget also.*

x 4000[6000 = 0.67 Actual progress is on schedule but actual cost is 50% over budget. Investigate!

x 600/6000 = 1.50 Actual progress is 50% ahead of schedule while cost is right on budget. Good news but should investigate immediately.

Progress is behind schedule while cost is over budget. Investigate immediately!

i. 2000/300o

2. 3000/3000

3. 3000/2000

4. 2000/3000 X 6000/7000 = 0.57

* As illustratedhere, the critical ratio is nat foolproof. The lack o f progress in example I should certainly be investigated, but, relative to its cost, is not out o f line.

With a project of the magnitude and complexity of automation, there is a tremendous amount that can be learned. Rarely are the true costs, benefits, and problems of automation accurately perceived beforehand in the 'as is' and 'to be' studies and, if more such projects are contemplated for the future, the learning that has occurred in this project must be captured - the knowledge gained may be greater in value than the automat ion benefits themselves.

The audit should absolutely not be confined to an accounting audit that considers only costs and revenues. Intangible benefits, expected problems

that didn't occur, synergies that were unexpected, difficulties that were expected and did in fact occur, impacts on fringe departments, and other such information is invaluable to the firm and should not be ignored.

Concluding Remarks The complexity and extensive integration

required for factory automation projects makes the implementation of automation an extremely difficult process for most firms. Yet, there are a number of tools of project management that can aid in this process and help increase the probability of success.

1.4

' . 3

.2

.1

.0

.9

.8

.7

.6

,5

Investigate Immediately

Investigate at Leisure

Ignore

I I I ! I I I I I I I I I I I I ~,J 2 3 4 5 6 7 8 9 1011 1 2 1 3 1 4 1 5 1 6 Week

Watch Carefully, Have Project Engineer Investigate

Investigate Immediately

Inform Company Management

50

4 0

30~

20

2O

30

40

5O

Cost Overrun Limit for Management Action

J 1~ 2 ~ 3 ~ 5 6 7 8 9 10 11 12 13 14 15 16

Week

Cost Underrun Limit for Management Action

Figure 17 Critical Ratio Control Chart for FMS Activity D

Figure 18 Control Chart for Project Cost

90


Many of these tools relate to the most difficult issue that automation project managers face, i.e., the human aspects and interfaces.

These tools also help maintain control over the three difficult, yet interdependent project parame- ters of performance, cost, and schedule. To effec- tively implement these three requirements of factory automation requires recognition of the task as one of implementing a project of major proportions. Use of the standard project management tools will not, of course, guarantee success, but can significantly contribute to its likelihood.

References 1. J. Jablonowski. "Special Report 774: Reexamining FMSs", Ameri-

can Machinist, March 1985. 2. J.R. Meredith, S.J. Mantel, Jr. Project Management: A Managerial

Approach, John Wiley, New York, 1985. 3. T. Hill. Manufacturing Strategy: The Strategic Management of the

Manufacturing Function, MacMillan, 1985. 4. W. Skinner. Manufacturing in the Corporate Strategy, John Wiley,

New York, 1978. 5. W. Skinner. Manufacturing: The Formidable Competitive

Weapon, John Wiley, New York, 1985. 6. A. Ashburn. "Flexibility, Patents, and Champions", Editorial for

Special Report: Reexamining Flexible Manufacturing Systems, Amer- ican Machinist, March 1985.

7. M.A. Maidique. "Entrepreneurs, Champions, and Technological Innovation*, Sloan Management Review, Winter, 1980. 8. J.R. Meredith. "A Champion for Automation*, Industrial Engi-

neering, May 1985. 9. J.R. Meredith. "Strategic Planning for Factory Automation by the

Championing Process", IEEE Transactions on Engineering Manage- ment, November 1986. 10. V.P. Rovito. "Planning and Implementing Hi-Tech Manufacturing Systems", Technical Paper, Cincinnati Milacron, Cincinnati, Ohio, undated. 11. B.V. Dean. Evaluating, Selecting, and Controlling R&D P~.ojects, American Management Association, New York, 1968.

12. R.S. Kaplan. "Yesterday's Accounting Undermines Production', Harvard Business Review, Volume 62, July-August 1984. 13. N.C. Suresh, J.R. Meredith. "Justifying Multimaehine Systems: An Integrated Strategic Approach*, Journal of Manufacturing Systems, Volume 4, No. 2, November 1985. 14. F.T. Curtin. "The Executive Dilemma: How to Justify Investment in New Industrial Automation Systems", CIMCOM Conference Pro- ceedings, Society of Manufacturing Engineers, Dearborn, Michi- gan, 1984. 15. R.J. Fotsch. "Machine Tool Justification Pqlicies: Their Effect on Productivity and Profitability", Journal of Manufacturing Systems, Volume 3, No. 2, 1983. 16. J.M. Grud. "Can Manufacturing Systems Change be Justified.'?", Production and Inventory Management, 2nd Quarter, 1984. 17. J.R. Meredith, N.C. Suresh. "Justification Techniques for Advanced Manufacturing Technologies", International Journal of Production Research, Volume 24, No. 5, 1986. 18. R.J. Meyer. "A Cookbook Approach to Robotic and Automation Justification", Proceedings of the Robots IV Conference, Society of Manufacturing Engineers, Dearborn, Michigan, 1982. 19. E. Ginsberg, G. Vojta. Beyond Human Scale: The Large Corpora- tion at Risk, Basic Books, 1985. 20. J.R. Meredith. "Peerless Laser Processors*, ease study conducted under Cleveland Foundation grant Management Issues in High- Technology Manufacturing Industries, December 1984. 21. J.R. Meredith. "The Strategic Advantages of New Manufacturing Technologies for Small Firms", Strategic Management Journal forthcoming. 22. M. Baudin. "Experience Curve Theory: A Technique for Quantify- ing CIM Benefits", CIM Review, Summer 1985. 23. J.R. Meredith. "The Economics of Computer-Integrated Manufac- turing", J.W. Nazemetz, W.E. Hammer, Jr., R.P. Sad owski, Computer Integrated Manufacturing Systems: Selected Readings, Norcross, Georgia, Institute of Industrial Engineers, 1985. 24. M. Blumberg, D. Gerwin. "Coping with Advanced Manufacturing Technology", Journal of Occupational Behavior, Volume 5, 1984. 25. J.R. Meredith. "Automation Strategy Must Acknowledge Organi- zation's Infrastructure", Industrial Engineering, May 1986. 26. D. Gerwin, J.C. Tarondeau. "Case Studies of Computer Integrated Manufacturing Systems: A View of Uncertainty and Innovation Pro- cesses", Journal of Operations Management, Volume 2, No. 2, 1982. 27. E.W. Davis, R.D. Martin. "Project Management Software for the Personal Computer: An Evaluation", Industrial Management, January-February, 1985. 28. J.C. Wheelwright. "How to Choose the Project Management Microcomputer Software That's Right For You", Industrial Engineer- ing, January 1986. 29. J.R. Meredith. "Implementing Factory Automation: The Need for Strategic Control", Long Range Planning, forthcoming.

Author Biography Jack R. Meredith is an Associate Professor and Director of Graduate and Undergraduate Programs in

Industrial and Operations Management at the University of Cincinnati. He received his undergraduate degrees in engineering and mathematics from Oregon State University. He obtained his M.B.A. and Ph.D. degrees in business administration from the University of California, Berkeley. Dr. Meredith has held positions with Ampex, Hewlett-Packard, TRW, and Douglas Aircraft Company. He is past, founding editor of Operations Management Review and his articles have appeared in Operations Research, Management Science, Computers and Industrial Engineering, International Journal of Production Research, and Indus- trial Engineering. His textbooks include Fundamentals of Management Science (with E. Turban, BPI, 1985), The Hospital Game, The Management of Operations (Wiley, 1987), and Project Management (with S.J. Mantel Jr., Wiley, 1985). Dr. Meredith is a member of CASA/SME, RI/SME, liE, TIMS, AIDS, APICS, and OMA.

91

Documents

Managing factory automation projects