Projects remain fluid, users firm
By Scott Sommer and Christopher Russell
Systems integration is not easy work and not for the faint of heart.
Often the task is about implementing someone else's design to the complete satisfaction of the owner.
Every project produces a list of lessons; the challenge after completing the project is to learn from those lessons and avoid repeating the same mistakes.
In the December 2007 and March 2008 issues, we talked about lessons for SIs. In May, we started our list of tips for those of us who hire and use systems integrators. We conclude our advice here.
Change management-Managing your internal customers: Not all change is good. A haphazard and "afterthought" approach to providing comments and feedback to the SI is almost certain to result in change orders and negative schedule impacts on the SI's work. Clearly delineate "must haves" from "like to haves" and make reviewers commit, in writing, to their thoughts and comments. Any comment not documented does not exist, period. All comments or requests that will result in changes to cost or schedule must get approval from the designated Project Manager and even then only after the SI has advised, in writing, of the cost and schedule impact of the proposed change. This is a common sense and disciplined approach to change management that we too often ignore in the heat of a project.
Change Management-Managing your SI: As in the previous rule, insist upon and enforce a firm rule that no changes are to be implemented regardless of who has requested them unless a formal submittal of cost and schedule change is made and approved.
Review system integrator submittals in a timely manner: Ensure you and staff review and comment on all SI submittals in a timely manner. The best way to discover errors and misunderstandings early is to thoroughly review the submittals and to advise the SI of your comments well before they go "off in the weeds" or in a direction that is not in keeping with the site's desires. It is often difficult for the site team to carve time out of an already overstressed schedule to perform these reviews, but it is an absolute necessity. Make it clear to the SI that proceeding ahead on a particular portion of the design without an approved submittal might result in their "working at risk." It is mutually beneficial then for the SI and for the site to have all submittals reviewed in a timely manner.
Leverage the SI's work for validation: Whenever possible, generate design, Factory Acceptance Tests, commissioning, and other official documents such as Functions Specifications in such a manner that they will satisfy Validation as well as project requirements. Get QA and Validation buy-in early on as to the format, content, and approval signatures for the documents that will allow them to serve for formal Validation purposes at the end of the project.
"Run interference" for your systems integrator: In addition to providing clear design documents, a dedicated, knowledgeable, and empowered internal project team, insightful and timely comments, and a disciplined approach to change management, the best thing you can do for your SI is to "run interference." Assign a dedicated Project Manager who will, among other things, clear their path of obstacles and impediments that may be standing in their way.
- The SI needs a face-to-face meeting with the production operators? Set it up.
- Where is a certain submittal in the review process? Find out for them.
- A meeting is necessary to approve the format of the graphics screens? Gather the appropriate site staff in a review meeting with the SI. Quickly.
Prompt attention to the requests and needs of the SI will result in a more cohesive and integrated effort. Everyone wins.
Be an active and involved partner in the SI process-Take ownership: It is difficult for a coach to direct his team from the locker room. The same goes for being "in the game" with your SI. Being actively involved in the systems integration process is more than just answering questions. It involves raising questions, participating in review meetings, actively reviewing documents and software, measuring the end product against the requirements, and foreseeing and remedying potential conflicts and problems.
See the original paper and complete 25-lesson list here: http://www.isa.org/filestore/25ValuableLessonsChanTalk.pdf.
These are hard lessons to learn. Some you will have to learn over and over again. We can attest to facing many of these lessons over and over again, project after project. Why?
ABOUT THE AUTHORS
Scott W. Sommer (firstname.lastname@example.org), P.E., CAP, is an automation technology manager at Jacobs Engineering. Christopher Russell is principal process-control technology specialist at Bayer Technology Services Americas in Pittsburgh.