There is a way to get automation projects moving, even when they cannot be fully defined.

Manufacturers typically communicate the requirements for an automation project to a systems integrator through a comprehensive equipment specification. This document defines the requirements for a successful project.

These requirements include:
  • a comprehensive list of the processes to be automated.
  • the minimum production rate.
  • time limits for setup and changeover.
  • the equipment configuration.
  • preferred types or brands of equipment (an Allen-Bradley PLC, for example).
  • product features that need to be automatically inspected and tested-and how those tasks should be carried out.
  • the protocol to be followed to qualify the assembly process.
A systems integrator will respond to the specification with a comprehensive proposal that describes the equipment to be supplied and provides firm prices and delivery dates. The proposal addresses each item in the specification line by line, and explains how the equipment will meet the requirements. A project resulting from a comprehensive specification and a firm proposal is generally termed an integrated design and build contract. With the equipment well-defined and the proposal well-organized, the systems integrator should have no serious difficulty meeting the firm price and delivery date, and both parties should enjoy a relatively low-risk project.

Unfortunately, high-risk projects cannot be handled so comfortably. However, systems integrators do have an alternative to firmly quoting a high-risk project-that is, in addition to not quoting it at all. Even when projects cannot be fully defined in an equipment specification, there are still options to get them moving. One is the multiphase development project.

Systems integrators often suggest a multiphase development approach when there is not enough information to provide a comprehensive proposal. Without adequate specifications, integrators face considerable financial risk by providing a firm price quote. What constitutes a high-risk project? An integrator may prefer a multiphase development approach if, for example, the parts have not been designed for automated assembly; the technology requirements have not been identified; or the system will include a new, untested process.

A proposal for a multiphase development project includes the same information that is typically found in a firm proposal: scope of work, deliverables, lead times for each phase, payment terms, warranties, spare parts policy, intellectual property ownership, and liability policies. But, there are some differences. The builder can only give a firm price for the initial phase and an estimate of the prices for the subsequent phases. The proposal addresses each phase of a project individually, including the scope of work for the phase, the lead times, the deliverables and, usually, a firm price for the phase to follow. It is important that thenextphase-whatever number that phase may be-is always defined in the documentation, so the project always has a direction. The buyer has the option of “buying in” to the project at each phase, since each phase starts with a purchase order and ends with a payment.

Multiphase development projects are usually divided into two or five phases. In a two-phase project, phase 1 consists of conceptualization and detailed design work, while phase 2 comprises purchasing, fabrication, assembly, debug, installation and startup.

The five-phase development approach is the most popular solution for difficult-to-define projects. The phases are concept development; engineering and design; fabrication, purchase and assembly; debug and qualification; and installation, startup and training.

Concept Development

Scope of work: Review similar, current processes; obtain agreement on the features that comprise an acceptable solution; brainstorm a concept for the project; obtain agreement on the validity of the concept; document the concept; provide a firm quote for phase 2.

Deliverables: Concept drawings; approximate size of system; estimated processing rate; description of major machine components; elements of the control system; firm price for phase 2; and revised estimates of the pricing and lead times for subsequent phases.

Engineering and Design

Scope of work:Complete the engineering and detailed design; document the design, engineering calculations and specifications for machine components; obtain agreement on the design; provide a firm quote for phase 3.

Deliverables: Complete layout drawings; detail drawing package; specifications for all machine components; phase summary report; firm price for phase 3; and revised estimates of the pricing and lead times for subsequent phases.

Fabrication, Purchase and Assembly

Scope of work: Purchase and fabricate all system components; assemble and wire the system; program and run it under power; revise documentation to reflect the system in its current state; provide a firm quote for phase 4; revise estimates for subsequent phases.

Deliverables:A fully assembled system, with all subsystems in place, which is capable of cycling under power; documentation for the system as it stands; firm price for phase 4; and revised estimates of the pricing and lead times for subsequent phases. (“Deliverables” here is a misnomer; the equipment is not normally delivered at this phase, although it could be.)

Debug and Qualification

Scope of work: Process a range of product through the machine and debug the equipment; ensure quality and rate requirements are met; document the results of the tests; revise documentation to reflect the system in its current state.

Deliverables:A debugged system that runs at rate with the desired quality of output and at the specified staffing level; a formal report on the system’s performance, including the results of rate and quality testing; documentation for the finished system; and a firm price for phase 5.

Installation and Training

Scope of work:Pack the equipment for shipping; ship to buyer’s facility; prepare for production; conduct and document acceptance tests to complete validation; train operation, engineering and maintenance people.

Deliverables:The equipment; production startup with all parameters subject to plant control; and training, including documentation.

Multiphase development projects are not limited to two phases or five phases. It could consist of four phases, seven phases or any number that can be agreed upon by the manufacturer and the integrator. A project could start with five phases and be terminated after any phase when it does not make sense to proceed because of financial or technical risks. Similarly, a project could start with a few phases and expand to many more as knowledge is gained.

Regardless of the approach, both parties want a successful project. The multiphase development project is one way to implement special factory automation with minimal risk for both the buyer and the builder. Just remember to keep it focused, controlled and documented.

Sidebar: Is Your Project High-Risk?

If all of the questions below can be answered in the affirmative, it is likely that a manufacturer in need of special factory automation will have enough information to write a comprehensive equipment specification. A multiphase development approach is probably not necessary.

  • Has the technology for the project been identified based on objective criteria?
  • Is there a history of production for the components and materials used in the product?
  • Are the parts in acceptable configurations for automation?
  • Have the principles of design for manufacture and assembly been followed?
  • Can the project outcome, including the deliverables, be defined objectively and completely?
  • Has a similar process been validated according to an industry-standard protocol? Are the results of that effort complete and retrievable?
  • Will the venture produce an acceptable return on investment?
  • Do you know which assembly processes will be included in the project, and which will not?

Sidebar: The Project Summary

The progress of a multiphase development project is sometimes difficult to follow. Developments can be recorded in letters, e-mails, meeting minutes, marked-up catalog sheets, teleconference notes and status reports. Much of the information on these records is redundant, and yet it can be hard to track down when you need it.

A simple, organized method to keep track of the important details of a developing project is called the project summary. This document divides the project information into four categories: scope and execution, parameters, assumptions, and issues to be resolved. Over time, the project summary will take on the function of an equipment specification, eventually defining the entire project.

The first part of a project summary is scope and execution. The entries include the processes to be performed, the technology to be used, the operation sequence, and any specific equipment or concepts that should be integrated into the project. Early on, this section will cover mostly the scope of the project-what needs to be done? As the project develops, the entries will define the execution of the project-how will those things be done?

The second part is parameters. What are the limits on the product and the system that will assemble it? This section may refer to several of the scope and execution entries, or to the project in its entirety. Parameters include the throughput rate; product components and materials; part tolerances; the price ceiling for the project; and any restrictions on the physical characteristics of the system, such as overall footprint.

Every multiphase development project includes some assumptions. What parts of the project do we think we know, but are not quite sure about? The scope of the project may not be defined in detail until engineers are well into the process of designing and building it, so both the manufacturer and the integrator will need to make some informed guesses in order to proceed. This section should list the items that both parties agree are reasonable assumptions.

The last section of the project summary covers unresolved issues. What parts of the project are definite unknowns? This section collects the items that eventually must be resolved to keep the project moving. It’s a reminder to all that action is required. This section might include changes to the overall scope of the project; decisions about prototyping part of the process; dates when materials or components will be available; and decisions from management.

To remain relevant, the project summary must be updated continually. A machine will be found to execute a particular task. Assumptions will be validated. Unresolved issues will get answered. Items that are no longer important will be dropped.

To make updates easy to interpret, the project summary should follow pre-established conventions for revisions. For example, new and significantly revised entries can be done inbold italics, and entries that are no longer relevant can be indicated by astrikethrough. These editing conventions should be used only once per revision. In subsequent revisions, earlier changes should revert to normal type, and lined-out entries should be deleted.

A short note in parentheses at the end of each line entry can identify the origin of the item or its revision, for example (12-09-06, review meeting minutes by ERG). Anyone who wants to see more than a simple condensation of the item can refer to the original document. Of course, each new project summary should be identified by the issue date or a revision letter.