How much and how long? These are key questions with regard to the phased approach. They are also the same questions that end-users and specifiers ask with regard to any system purchase and installation: "How much will it cost?" and "How long will it take?"

Determining Cost
While the actual cost for the integration will depend upon the scope of the integration, the following statement can be made: 

The phased approach, by providing the opportunity for an accurate and fully-detailed integration design, reduces the development cost to its lowest level.

Determining Schedule
How long the integration will take depends upon both the size of the job and the approach taken. Generally there are two approaches that can be estimated.

A standard development timetable can be calculated for a combination of best design-lowest development cost scenario. This involves normal using work-weeks and employing personnel of average skill. 

A fast-track development timetable can be worked out for the shortest time to implementation. The development work is accomplished by subdividing the tasks among more personnel, employing personnel of higher skill levels, providing closer and stricter supervision, and using extended work-weeks (10 to 20 hours of overtime). 

A fast-track timetable requires more work on the part of all parties (including the customer) in order to meet scheduled deadlines. 

As a general rule the fast-track timetable is only worth the increased cost and effort if it can cut the development time in half, or if facility operations deadlines require the shorter timetable . 


Allow for Debugging Time
Allow a period of time for debugging the installed front-end system equivalent to 10% to 20% of the development calendar time. For example, if the installed system took 25 weeks to develop, you should allow 2-1/2 to 5 weeks for debugging time.

Update Specifications and Design Documents
As changes are made to the specifications and design documents, the written documents should be updated and re-issued to all parties. A reasonable confirmation cut-off date should be provided, whereby changes are assumed to be correct as written unless the originator is notified otherwise in writing. 

Don't Skimp on Design Documentation
Graphical examples should be included to document or clarify design intent. "Screen shots" (printouts of system display screens) from example installations should be included where such systems are referenced in the specifications or design documents. Include actual examples of written reports.

Provide a Glossary
A glossary of technical terms used in specifications and design documents, where terms are explained in plain English, will go a long way to expediting the design and approval processes. 

End-users deserve to receive documents they can understand. 

Furthermore, educated end-users (end-users educated correctly in what all parties are trying to accomplish) cause significantly fewer problems than uneducated ones. 

The benefits of ensuring customer understanding always justify the small amount of extra time and trouble that it takes.

Ensure That the System Providers Are Not Only Qualified - But That They Understand The Job
System providers also deserve to receive documents they can understand. Furthermore, they have the specific obligation to request clarifications when they don't understand an item in a document.

Select Sub-Systems Whose Manufacturers Are Not Opposed to Third Party Front-End Systems
When the subsystem manufacturer does not provide a front-end integration package, ensure that the manufacturer is not opposed to the use of a third party front end with their product.

There may be hidden complications involved where the manufacturer expresses opposition to the idea of front-end integration. The soundest approach is to select sub-systems whose manufacturers will not oppose your efforts.

Instead of relying on the provider's past experience on this issue the manufacturer should be consulted directly, since company personnel and policies can and do change.

Avoid the "Everybody Knows" Syndrome
Avoid phrases like "industry standard". If the item really is an "industry standard", it will be easy enough to include an accurate description or to reference a standards document. 

Even if the specifier or designer knows exactly what is meant, it must still be clear to all the other parties involved. It is not a sound practice to assume that "everybody knows that." It is important to make sure that they do.

Use Functional Descriptions in Describing Customer Requirements
Don't just state what equipment or software interfaces to what other equipment or software. Whether the interface is  accomplished using "serial port communications" or "dynamic data exchange", you still have to state what it is that the interface will accomplish.