Railroad tunnels really are built from each end simultaneously, and the two bores actually meet with virtually nil offset. Yes, there’s more than casual communication between the two work crews as they approach each other. There also are precise alignments established at each end before either team starts digging.
The point is that difficult jobs can be done well if they are managed properly from the beginning through to their completion. But, it’s essential to know where you’re going before you start. Employing the services of a systems integrator is no different.
Preparing a detailed statement of work (SOW) is a good way to begin. Here’s a list of the typical steps required to generate an SOW:1
- Articulate dependencies such as schedule and resources.
- Produce a comprehensive requirements definition or work with the integrator to develop one. Address schedule, terms, conditions, and expected system performance.
- Approach test-system creation as a partnership with the systems integrator, with both parties openly discussing trade-offs, risks, and strategies to manage risks.
- Set up a structured management relationship (assign specific management roles, responsibility, authority).
- Establish a clear point of contact for communications.
- Be willing to participate in thorough de-sign reviews at the integrator’s site.
- Ensure that the systems integrator has access to the right people at your company in a timely manner.
- Provide the systems integrator with sup-port facilities at your site.
- Don’t use a time-and-material arrangement unless necessary. It is better to subdivide the project into smaller elements that can be bid at fixed prices.
- Tie payments to deliverables and specific milestones.
Most companies that have employed systems integrators would agree that the actions covered by the list are necessary. Obviously, you want your project completed satisfactorily. But before starting the job, you must determine if the listed actions are sufficient or if there is something else that you need to do.
Probably the most important decision you will make is the initial choice of a systems integrator. Will you award the contract based on an estimate of project cost and time to complete, engineering competency, or experience directly relevant within your narrow field of interest? For the projects we reviewed for this article, relevant experience turned out to be the factor having the greatest effect.
The Relevant-Experience Factor
Because little of the new project was revolutionary, Mr. Tomich could communicate the essential system requirements very concisely. He already had built a prototype system. He also knew most of the limits for the various parameters, how he wanted the data to be presented, and the range of data reduction and storage options that should be made available.
Before the systems integrator started in earnest, Mr. Tomich streamlined the partitioning of responsibilities. He defined the interface between the vendor-supplied data acquisition hardware and software and the electrical signals from the Paccar trucks.
The systems integrator was presented with a connector type number, a list of signals and their corresponding pins, and the characteristics of the signals. The fact there was a truck on the other side of the connector was irrelevant. Paccar provided the several custom cables required between the connector and their range of truck models. This meant that the systems integrator only had to design one system.
As Mr. Tomich said, “We took the wiring research out of their contract and just let them do what they do best. If the systems integrator sticks with the same hardware/software combinations [they have used in the past], then their learning curve is almost zero on any new project.”
Because the chosen vendor had already done many similar data acquisition and display jobs, the project was completed within budget, on time, and with few surprises along the way for either party. In fact, the systems integrator added value to the project because of their familiarity with the specified data acquisition hardware and programming environment.
Was each of the 10 steps in the SOW list followed? No, at least not formally. In fact, Mr. Tomich described the initial SOW documentation as “maybe just three pieces of paper that talked about the concepts and what we would use for parts and sketches on the back of an envelope.”
In this case, the systems integrator’s directly relevant experience made up for the lack of formal documents. Actually, in spite of the informality, the project was well defined and a manageable size so there really weren’t a large number of unknowns to confront.
The resulting system reduced test time from the previous 10 to 15 minutes per truck to two or three minutes. This allowed more time for proper repairs.
Success of the system is confirmed by the completion of eight test systems and orders from other Paccar plants for three more. Also, Mr. Tomich commented that he has some additions and modifications in mind that he will discuss with the systems integrator. “It was probably the best contract I have ever managed,” he said.
So, how did he choose the systems integrator? He already had selected a family of PC-based data acquisition products that he felt could meet his requirements at a cost lower than competing approaches. The product manufacturer provided a list of qualified systems integrators, and Mr. Tomich narrowed down the choice to three. Each company was invited to bid on the job, and the final choice was based on the price quoted.
All three had successfully undertaken similar projects in the past. But the chosen vendor visited Paccar before submitting its quote. During the visit, representatives talked with Mr. Tomich, reviewed his prototype system, and understood fully what they were being asked to do. They also saw the truck factory and the severe treatment the proposed system would receive.
After the project began, Mr. Tomich said, “We just kept in touch via phone and e-mail.” And when the systems integrator felt the work had been completed, “I did an acceptance test on the first unit at their place.”
Mr. Tomich commented that you should match the size and experience of the vendor to your needs. If there’s a good match between your job and the systems integrator’s size and expertise, then you’re more likely to be quoted a competitive price and schedule.
The Technical-Detail Factor
Is technical detail a substitute for a clear and complete statement of higher-level project goals? No, but attempting to make the substitution is a common problem.
Consider, for example, the case of the wind energy technology department at Sandia National Laboratories in Albuquerque, NM. They entered into a contract with a systems integrator to develop data acquisition, reduction, and display software.
From working with an earlier data acquisition system that ran on HP1000 computers with FORTRAN software, the group already knew how many channels they would need and how they should be analyzed. As Mr. Rumsey said, “We knew what we had and what we wanted. But getting from one place to the other was what we wanted the systems integrator to do. And it turns out that was quite a challenge.”
The systems integrator was chosen on the basis of competitive quotes from three vendors that specialized in LabVIEW programming. Mr. Rumsey wanted the project software written in LabVIEW but didn’t have enough qualified programmers available to do the work in-house. Unfortunately, there aren’t very many systems integrators that have developed data acquisition software for wind-turbine monitoring. None of the three contending vendors had this specific application knowledge.
For this reason and because Mr. Rumsey’s group had not previously worked with the chosen systems integrator, both sides faced steep learning curves. On the other hand, he had considered many aspects of the vendor-client relationship before awarding the contract. “First, neither the systems integrator nor the wind energy group was very large,” he said. “The systems integrator specialized in writing LabVIEW software, and what particularly attracted me to them was the team of people they had.
“We ended up having five different programmers on the project, which was very advantageous. Somebody was very specialized in graphics, someone else was good with the analytical part or signal processing, and another was good with database implementations,” he continued, “so it was interesting to see how the people interacted. I don’t think one person could have that much detailed knowledge. Organizationally, I worked with a program manager to get people scheduled on the project. He could tell me who was available and who wasn’t at any time.”
The wind energy group developed a set of internal documents that detailed the specifications. They elected not to use a formal software requirements documentation format. That choice was made because the formality of the process seemed excessive for the project and because there were budget constraints. Getting more people involved than absolutely necessary, even if from one of the other groups within Sandia, might have delayed the project and increased costs.
How did the project progress? “We probably spent four or five months on the planning or brainstorming phase. In fact, the lead test program project leader and I were getting nervous about it,” Mr. Rumsey explained. “We took a top-down approach and started developing some user interfaces just to see if it was the kind of screen that we wanted to see. We also worked from the bottom up, but it was a good four or five months before we finally got to the really heavy-duty coding.”
Should this detailed software-module definition phase have taken so long? Probably not. If they had the job to do over again, the wind energy group would approach it somewhat differently.
“I think we would do our homework better,” commented Mr. Rumsey. “That was one complaint the systems integrator had of us: We had some very good equations requirements, but there was a great deal between the lines that had to be filled in during those four or five months.
“What was obvious to us was not obvious to them,” he continued. “We are familiar with the [wind energy] business, but we didn’t communicate our knowledge properly to them in the initial phases. I think those programmers who worked on this project now know quite a bit about wind energy.”
Given a second attempt, the group also would change the day-to-day project management approach they adopted. Mr. Rumsey initially met with the programmers to determine the order of program module development. Then he left them alone for two or three weeks to do the work.
“I soon learned that was too much time. I had confidence in their abilities, so I left them alone instead of effectively being a micromanager. But it turns out,” he explained, “that they went off on a tangent. They thought they were doing the right thing, but they were actually going in the wrong direction. It was interesting. They did the wrong thing very well. Near the end of the project, we met on Monday mornings to go over what they had done and discuss their problems. That turned out to be very useful.”
Eventually, the project was completed. However, there were compromises along the way. Not all the functionality could be delivered within the time frame, and producing the reduced-specification software still cost 175% of the original budget.
The final proof of system performance is not yet available because of delays in implementing the hardware portion of the data acquisition system. Figure 3, however, shows the results of some of the first full-speed, continuous-acquisition tests on the new system.
Certainly, Mr. Rumsey and his group have second thoughts about how the project was initially defined and the time it took to develop the details of each software module. Both the systems integrator and Mr. Rumsey’s group acknowledge that their initial cost estimates were too low for a major piece of from-scratch software.
However, if you can’t find a systems integrator that has specific application knowledge, do what the wind energy group did: Choose an agile, energetic one with excellent technical skills. The results they achieved together with their software vendor may be the best that could have been accomplished under the circumstances.
Acknowledgement
Thanks to B&B Technologies, Paccar, and Sandia National Laboratories for their part in preparing this article.
Reference
- Jacob, G., “Successful Systems Integration Requires Multiple Commitments,” EE-Evaluation Engineering, July 1998, pp. 42-48.
Published by EE-Evaluation Engineering
All contents © 2000 Nelson Publishing Inc.
No reprint, distribution, or reuse in any medium is permitted
without the express written consent of the publisher.
July 2000