By: David Krubsack, PhD
Throughout a company, different pockets of data can exist, data that can have an important impact on the company. This can be device characterization data, verification data, production test data, clinical data, and marketing data to name a few. Unfortunately, separate departments or individuals may not know this data exists and therefore make certain assumptions about the data that may not be accurate. Or if a data integration task is necessary, scramble to find or collect the relevant data. In such cases, simple periodic communication may be the only requirement necessary to minimize the occurrence of these situations.
This article presents a technique to help facilitate communication and documentation that focuses on the data that are the core competencies of a business and how that data is communicated throughout the company. The technique is presented from the early technology development perspective, with the goal of getting things done right the first time. If you are in remediation with the desire to get on to new projects, the communication and documentation you set up can and should be the same as you would set up for early technology development. So even though you are in remediation, you are actually laying the necessary groundwork for a new project.
As a point of reference, let’s take a look at two examples.
One example of data that should be readily available to the company is device electrical current measurement. Simple, right? Well let’s consider a few things. The device probably has a processor that wakes up occasionally to take care of a few things and then goes back to sleep. If the current is measured while the processor is on, it will record a much higher value than when the processor is off. Additionally, the device probably has several settings, each of which requires a different amount of current. Should the current be measured using true integration? For how long? Or should multiple values be measured over a shorter period of time and the results averaged? Once you start digging into the issues, there are many complicated decisions to make for a measurement that at the outset appears to be very simple.
If in our example the current measurement is not adequately documented, there will be problems and inconsistencies down the road. The current measurement method needs to be maintained as the new technology goes into development, then on to verification, production, customer support, and eventually failure analysis. While there could be multiple proper ways to measure the current, if all the decisions on how to measure current are not consistent from one department to the next, it becomes impossible to compare current measurement data taken at failure analysis to data taken in production, and back in the initial design.
An example where inter-departmental communication was improved using the principles in this article involves the engineering and clinical departments. For clinically relevant device characterization, engineering needed certain clinical data. This clinical data was not readily available. Upon investigation, it was found that to collect this data in a clinical setting, the device that engineering provided to clinical did not easily facilitate this data collection. Upon further investigation, the engineering improvement of the device to collect this data automatically in a clinical setting was relatively straight forward.
In both the current measurement and clinical data examples, tightly integrated inter-departmental communication is necessary at a technical level. To help facilitate this kind of communication, a data integration meeting can be established. For this activity to be effective, there are several elements that are required.
Management Support
A high level of support could include assigning personnel to the group during regular business hours. A low level of management support could include simply paying for a lunch meeting. This low level of support can still be quite effective, but relies on volunteer attendance (usually not a problem with a free lunch) and volunteer presentations. Careful selection of individuals is mandatory. At a company where inter-departmental communication is strictly controlled, even a volunteer lunch strategy may not work.
Select Individuals
Carefully select individuals from multiple departments. These should primarily include individual contributors and some management. You will want to select individuals that are passionate about solving inter-departmental issues, technically astute without ego, respectful of others, and good communicators including a willingness to present to the group their aspect of a given issue.
For larger companies, listed below are departments that should be considered. For smaller companies, especially startups, there might not be a large number of departments. However, the functions of these departments should still be considered during appropriate meetings. Some departments should always be in attendance. Others such as library management might only be brought in to cover article acquisition cost, proper copyright management, and legal distribution of articles used across the company.
Business Intelligence
Clinical Data Management
Applied Research
Technology Development
Product Development
Systems
Electrical
Mechanical
Software
Power Source (batteries)
Verification
Production
Technical Services
Customer Support
Failure Analysis
Statisticians
Library Manager
Document Control
Regulatory
Quality
Sales and Marketing
Finance
I find that a group of 12-20 people is a good number for a meeting. If there are less, the necessary ideas are not communicated across the company. More, and there is not enough time for every department to comment on their aspect of an issue. Select one, but no more than two people from a department for regular attendance. There should be a core of 10-12 people consistently attending, but the remainder of the group can come and go depending on the topic.
Select a Leader
Select a leader for the group. The same qualities apply (listed above) as the group members. Additionally, the leader needs to have a good basic knowledge of each of the technologies. The leader must be a good listener and be able to find the subject matter experts at a company who are able to answer specific questions. The leader is to run the meetings and is the primary person responsible for the deliverables (listed below) from the group.
Focus on the Data
Focus on the data that are the core competencies of the company and how that data is communicated throughout the company. This may include defining data life cycles. A helpful book is “Data Governance for the Executive,” by James C. Orr.
Where do you start? One important set of data is the data necessary to support the product claims via labeling. Also, people who care about productivity can be frustrated with problems that never seem to get resolved. Start with these issues. Ask the affected departments to give a presentation on their perspective of an issue.
Persistent problems often involve connecting ideas across departments, products, device systems, procedural systems, and projects. While a “core team” can be set up for a specific project, its specific deliverables and deadlines often do not lend themselves to resolving problems that are uncovered in the process, problems that have deep roots. If no single “box” exists to assign, investigate, understand, and resolve these cross functional issues, they usually do not get solved, although “everyone knows about them”. In a similar way, improvements in efficiency can have deep roots, such as using the same tool to measure the same thing, or at least measuring it the same way. The resolution to these problems and efficiencies need not be complex or expensive. In many cases, it just requires simple communication between departments, products, systems, and projects. However, it does require management support to acknowledge the validity of this effort.
Additional topics of discussion can come from the concept of data producers and data consumers. An example of a data producer is someone responsible for collecting production test data. A data consumer is someone who uses the data, for example to improve the product design. Such data needs to be documented and stored by the data producer, and accessed by the data consumer so Business Intelligence IT personnel will likely be involved to help provide systems for data documentation, storage, and access.
Request that data producers give a presentation on the data they are creating. Request data consumers give a presentation on how they are using data, or what kind of data they need. Request data handlers give a presentation on what they are doing, the tools they are using, and what resources they can make available to assist in the communication of the data.
In some cases, the data is a core competency of a vendor, but the proper use of the data for your products is a core competency of your company. If this is true, check to see if the vendor has the data you need rather than having your company invest in creating the data.
In some cases, data (information) should be delivered to the customer. This should be done through appropriate department channels such as regulatory when necessary.
The leader needs to consistently frame these discussions so that the focus is kept on the data. Do we have the data we need? Does the data already exist somewhere in the company? Are the data we have good enough or do we need to collect more data? Can we optimize the data we need in order to minimize the amount of data necessary to be maintained? Are the data we have being properly communicated to the appropriate departments? Are all the departments using the same data or measuring the data the same way? Are the data (our core competencies) being documented and stored adequately? Are our procedures adequate to ensure that our core competencies (data) are consistently being documented?
Duration of the Meeting
Schedule the meeting time to be less than one hour. Usually people need time to get to other scheduled meetings or activities. Here is a recommended agenda for a 50 minute meeting in a one hour time slot.
10 minute review, updates on previous topics of discussion
20 minute presentation
20 minute questions and discussion
10 minute optional time for individuals to connect for informal follow-up
For a lively discussion, the meeting culture can be cultivated so the 20 minute prepared presentation will take 40 minutes due to well-focused questions and discussion during the presentation. The leader and presenter will need to work together to ensure the review, presentation, and discussion can be completed within a total of 50 minutes.
If possible, reserve the room one half hour before and after the official meeting time. Let the attendees know that the room is available. In addition to the formal meeting and deliverables (below), one of the primary goals of the meeting is to encourage communication between departments that didn’t know they needed to be talking to each other on a regular basis.
Periodicity of the Meeting
How often should these meetings take place? The answer to this question can depend on several factors. It seems that once these meetings start, there is a pent up demand for communication. Many people will want to resolve on-going problems and/or give presentations on the data they are creating or data they need for their work. When the demand is high, one meeting per week seems to be quite packed with discussion.
During the weekly meetings, the leader maintains a list of topics to discuss, focusing primarily on cross-functional problems to resolve and efficiencies to improve, all in the context of identifying the data that are the core competencies of the business.
Once the individuals from the departments have had a chance to give their presentations and voice their concerns or suggestions, the leader should have collected a good list of topics for further discussion. At this point, the direction of the meeting should be changed from simply voicing perspectives to resolving topics (problems and efficiencies) the leader has identified as cross-functional (cross-departmental, cross-system, cross-project, etc.).
If there are many topics to resolve and if the meeting continues to have high management support (see management support above), the meeting can effectively continue once per week. If there are only a few topics and the meeting has spurred effective individual communication, once every two weeks or once per month would be adequate. If there is low management support, it will be difficult to assign tasks for the resolution of the topics and for further presentations. However, a monthly meeting will still be effective to review the status of the documented topics and encourage cross-functional technical communication. Having a meeting less than once per month is minimally effective, because the focus and culture of the meetings is difficult to maintain. Depending on new topics that come up and level of management support, the periodicity of the meetings could change.
Deliverables
The leader is primarily responsible for the deliverables.
Presentations: The leader will maintain a copy of all the presentations, preferably in electronic form so they can be easily referenced by cross-functional personnel.
List of Topics: As mentioned above, the leader must maintain a list of topics focused on core competency data involving labeling, cross-functional unsolved problems, and cross-functional efficiency improvements. Each topic should include a description of the topic, its status, and the primary point of contact (person) for the topic. If there is a high level of management support (see management support above), the primary point of contact will assist the leader in maintaining the documented status of the topic.
Topics Presentations: If there is a low level of management support, the leader will at a minimum, present these documented topics to his/her manager. If there is a high level of management support, the leader will present these topics to the appropriate management team, and at the request of an individual manager, present the relevant topics to the manager’s team. Working with the individual manager, the leader will invite select individuals from the manager’s team to attend relevant topics at the data integration meetings.
In addition to working with personnel management, the leader will work with program management to make them aware of topics that can affect their project and/or what alterations or additional tasks would be required on their project to facilitate a larger persistent problem or efficiency improvement.
Quality System: This activity may uncover problems or efficiency improvements in the quality system, document control, data storage, or procedures. Appropriate changes to the affected documentation should be proposed.
The leader or designated person will drive the topic toward a resolution including appropriate documentation along the way. If the topic is significant enough that the management team creates a separate project for its resolution, the data integration leader will facilitate in communicating the relevant issues from the data integration meetings to the project leader and the project leader will ensure appropriate documentation is created.
Conclusion
The technique presented in this article can significantly improve inter-departmental communication for data integration and associated documentation. The principles are more complex that those of the simple documentation described in the previous article. That is because they not only facilitate data integration, they also target resolution to systemic issues (problems and efficiencies) that require communication across departments, products, systems, and projects. The interrelated data build a foundation of a company’s core competencies both in early technology development and continuous improvement. Managed well, the integrated data can have a significant positive impact on the business.