The purpose of this article is to outline some SCADA and Automation Project Management issues that you may want to consider as useful to your organization or projects. However, it is not the purpose of this article to imply that this outline is comprehensive and suitable for your business but to provide a basis for discussion and comparison.

Often, SCADA and/or Automation projects are smaller components of a larger facility project. Occasionally, one of these projects is executed as a standalone project. Issues addressed below may apply to both of these project types.

1. TAKE TIME to LEARN the CUSTOMER'S BUSINESS or PROCESS.
   It is a lot easier to develop a proposal and deliver a SCADA or Automation system that contains the necessary functionality to improve the customers business if the system integrator has knowledge of the customer's business and processes. System integrators need to spend the time necessary to learn how the customers business or process works BEFORE beginning development of the customer's SCADA project proposal or application.
2. WATCH OUT for the CUSTOMER WHO does not KNOW WHAT THEY WANT or NEED.
   Keep this in mind when dealing with a customer who has had little experience with technology or how technology may be applied to their business. Additionally, this customer may have a difficult time communicating what their system should do and the integrator has little understanding of the customers business or process. And to make it worse, the customer may see this project (and this technology) as an enabler to help them compete by becoming more efficient or achieve a lower cost structure. Sounds like a recipe for disaster? You bet! Keep your proposal simple and understandable to the customer.
3. NARROW the SCOPE.
   It better to have a less ambitious and achievable scope than a grand plan that attempts to bring a customer's business from the Stone Age to the Space Age in one fell swoop. Don't swing for the fences on the first at bat. Successes build on previous successes but rarely (or never) build on failures.
4. DO the ECONOMICS.
   Run a base case of economics on the proposal. If the rate of return for the investment meets the hurtles set by the company, present the project for consideration. If the economics does not meet the companies hurtles, go back to the drawing board and see if enough cost may be taken out to meet the hurtles without sacrificing needed functionality. DO NOT INFLATE the economic case with any set of assumptions that have little chance to be correct. If you need a better rate of return for your project, try to make project intangible benefits tangible without raising eyebrows questioning your credibility.
5. HAVE OPERATIONS INVOLVED.
   These are the guys who will be using the system. Often, but not always, they know what they need and can provide guidance in developing the proposal and the system.
6. MANAGEMENT needs to be UPFRONT with OPERATIONS about the PURPOSE and PLANS for NEW TECHNOLOGY INVESTIMENTS.
   Operations can make or break a company. These are the guys who will be using the system and if they don't want it to work, it will not. Operations needs to be fully informed about the purpose for the investment in the technology and if it means a reduced number of jobs, both Management and Operations need to work out this issue.
7. INFORM the CUSTOMER about SUPPORT and MAINTAINANCE AFTER the SYSTEM is DELIVERED.
   The customer should know up front that the system will require some maintenance and administration after delivery. Many systems operate until maintenance is needed and then fail. No one may be available to support the system and restore it to operation.
8. TRY to AVOID a FAST TRACK PROJECT, if at ALL POSSIBLE.
   When a project gets on the fast track, you can usually figure on a 20-30% minimum increase in project cost. Factors that contribute to increased cost are overtime wages, increased number of errors, rework due to evolving project scope, increased material and services charges, etc.
9. USE the APPROATE LEVEL of TECHNOLOGY.
   Over-designed systems may be much more costly to capitalize and much more costly and complex to administer and maintain. Many times the over-designed system was actually designed to be used in a much larger application. Often these systems are sold on the basis that they are the latest and greatest and are being used in much more critical systems than ours, so the logic is that we can't go wrong by selecting this bigger system. On the other hand, under-designed systems usually lack adequate functionality, expansion capability, or both. Often when project specifics are vague and project budgets are tight, an under-sized system may be selected. Later when expansion needs arise the under-sized system cannot meet the new requirement, and may have to be changed out entirely, or at least upgraded.
10. INCLUDE BUDGET and SCHEDULE CONTINGENCIES in YOUR PROJECT ESTIMATE.
    Leave your self some breathing room in your project budget and schedule. Plan for some contingencies and delays. Lock down firm prices, deliveries, and schedules from vendors and sub-contractors, if possible.

1. WRITE a SPECIFICATION or GUIDELINE BEFORE THE PROJECT STARTS.
   Know what functionality and scope is important to the end-user and make sure the SCADA application specification includes that functionality. Specify the level of project documentation required. Develop project P&ID's, as necessary.
2. FREEZE the SCOPE.
   When the project is funded, freeze the scope to prevent "feature creep". If you do not have a definite scope, how do you know when the project is really complete?
3. DEVELOP a TIMELINE and SCHEDULE.
   Keep this project schedule current and updated to avoid any nasty surprises related to delivery date. Review and update the progress of the project's development with the customer frequently. Do not wait until the system is ready to be delivered to the customer before reviewing the SCADA application for gaps in functionality.
4. FILL out a SCORECARD.
   As in a baseball game the manager fills out a scorecard identifying who is playing first, who is pitching, etc. For your project, identify the players and what roles they should play and what portions of the project for which they are responsible. Define clear expectations down to each company and individual involved with the project. Distribute this "Score Card" to the customer, to all the players involved, and to their respective companies.
5. DISTRIBUTE the PROCESSING.
   If the system involves multiple PCs and PLCs, distribute the processing to avoid a single point of failure, if possible. Critical safety or process control systems should be designed to be fail safe and be designed to fail in a known state.
6. KNOW YOUR COMMUNICATIONS MEDIA CAPABILITIES.
   Do not promise the customer 1-second updates on a system with 10 radio remote PLCs or RTUs and 1200 baud modems! In fact, there is no such thing as real-time but only varying amounts of delays. Know what your media and system can deliver before you make promises about system performance.
7. MAKE PROVISIONS TO TRAIN THE OPERATORS.
   The SCADA system operators need to be trained on how to use the system. Operator training needs to be completed not too far in advance of system deployment nor too late after system deployment. Include adequate training in the project budget.
8. DEVELOP a CONTINGENCY.
   In the event undesirable things occur or case the project incurs unexpected delays, have a contingency plan.

1. INFORM the CUSTOMER at LEAST WEEKLY on the PROJECT's STATUS and BUDGET ACTUAL vs. ESTIMATED.
   The customer should know exactly where their project stands as per the schedule and as per the budget on at least a weekly basis. Customers hate last minute surprises on schedule issues or budget overruns. Take this opportunity to talk about the work scheduled for the next week or so in this project update communications. Identify possible roadblocks and communicate to the customer your plans to deal with these perceived problems.
2. NETWORK with YOUR STAFF ASSIGNED to the PROJECT.
   Network with staff assigned to the project daily, if possible. Also network with the sub-contractors assigned to project on a frequent basis. This will give you an early warning if some unanticipated obstacles come up and will hopefully allow your project team time to resolve the issues.
3. REMOVE the OLD SYSTEMS.
   When the SCADA project is complete, if it involved replacing some older equipment, retire and remove the older systems or equipment. If it is easy to bypass the new technology and revert to the old, rest assured at the first sign of trouble most people would revert back to what they know and understand. Force them to deal with the new technology by removing the crutch of the older system.
4. DO the PAPERWORK.
   Don't forget that project documentation is very important to most customers. Comment source code and complete as-built drawings. Organize equipment manuals and vendor receipts.

• Organizing Your RTU Data - to maximize communication efficiency.
• How NetSCADA - supports your project management efforts.
• SCADA system administration - the necessary elements for effective Automation administration.

Above are some of our ideas about project management. We hope you may glean a few good points from our outline that may help your project management efforts. We would sure like to hear from you with your ideas about what you think is important when managing SCADA or Automation projects. You may contact us by email at: info@netscada.com