“If you are not willing to learn, no one can help you.
If you are determined to learn, no one can stop you”. – Author Unknown
In today’s fast-paced product development cycles, the pressure to compress testing and certification schedules is constantly increasing, with global competitors all rushing to get their new technology to market first. Mistakes made in compliance testing and certification processes can have huge financial impacts if product releases are delayed, or lead to later stop-ships or recalls. Utilizing project management techniques can provide great benefits by improving the efficiency and quality of compliance projects.
What’s in your toolkit?
As regulatory compliance professionals, we are expected to stay current on the latest international standards and test methods, keep up with the latest regulatory requirements for our company’s market countries, and keep pace with the constantly changing technology in both products and test equipment. But what tools do you have to keep track of your assigned projects, and what do you do when things don’t go as you’ve planned? When you find yourself in a ditch, what do you do to get out?
I will provide a few effective project management techniques that can help increase your efficiency, lower your stress, and help to ensure more success with your compliance projects. This is not a comprehensive overview of all aspects of project management, but rather provides some exposure to the benefits of the subject, and to encourage additional study of this topic.
Faster, Cheaper…Better?
After a decade working of working in the compliance field at one of the largest ITE companies, I noticed that I kept running into the same types of problems with my product certification projects, and that my colleagues were having similar issues. As an engineer who was also involved with quality management systems, I knew there had to be a “root cause” for these glitches that kept showing up. As I examined the project data, I saw that these issues weren’t related to a lack of knowledge of the regulations or agency processes, nor were they related to a lack of technical knowledge such as operating test hardware or software, or the current prescribed test methods. Instead, they all seemed to be related to the internal processes for product development, the assumptions used to build schedules, and miscommunication.
The Big Elephants in the Room
This led me to the discovery of the field of project management. I was astounded to learn that not only were my issues fairly common, but there already existed a huge number of books, magazines, websites, and on-demand videos, all dedicated to these tools and concepts. I quickly realized how beneficial this information would be to increasing my project success and on-time completions. Over the next five years I dove into the study of the best practices of project management, taking formal classes, and culminating with my certification as a Project Management Professional (PMP) by the Project Management Institute (www.pmi.org).
Please don’t get nervous; I’m not recommending that you also spend five years of concentrated study on this subject. I just wanted to share the path that led me to identifying the most common non-technical issues with product compliance and certification projects, which I dive into below; the two “Big Elephants” that we don’t normally talk about in compliance engineering: project management and communications.
Elephant #1: Project Management
As mentioned, project management is a huge field, and has many parts and dependencies required for the full implementation of the methodology, but there are some vital tools that can be applied which will help to make your work more manageable. In this section I’m going to cover three very effective project management tools, those being project planning, risk management, and deliverables.
Defining and Planning Your Projects
Before I started learning about project management, I just accepted whatever schedules came with my assigned projects, and hoped that I could somehow run fast enough to keep up with them. I came to realize that these schedules were developed by well-meaning planners in product groups, who were working from “one-size-fits-all” templates and applying them to very different types of ITE projects, without accounting for the required resources. To have realistic schedules, you must understand your product requirements and the amount of resources needed, in order to develop your own specific compliance schedule, and you must actively work with the project team so your requirements can be grafted into the overall project schedule.
The “Golden Triangle” is an excellent tool for understanding the interplay between scope, schedule, and resources involved in a project, and is a key project management concept (Figure 1). Scope refers to the totality of the features and abilities of the product; for example, if we are making a printer, for our compliance work we would need to define the printing technology (laser? Ink jet?), the data input and output connections (USB? Wi-Fi?), the market country list (US only? EU? Worldwide?), and other pertinent regulated features. The schedule part we are interested in is how much time is allotted for the various product compliance activities, such as EMC and product safety testing, report writing, agency submittals and certification timelines, and every other scheduled activity in our process to cover all of the items specified in the scope. And resources refers to the employees, product samples, test equipment, agency and lab fees, and any other expenditure required to complete the project.
Figure 1: The “Golden Triangle” of Project Management
In formal project management, scope, schedule, and resources will define the major factors in the project, and how well they are defined can determine the success or failure of a project. You need to have a solid understanding of all of the processes and activities required to complete the compliance work covered by these three terms. If you are a new engineer, you need to seek out more experienced staff members who can provide this information, and help to mentor you through your first projects. In clarifying and documenting all three areas, compromise and trade-offs will be involved. If your company wants to speed up the schedule, it will take more resources, and you may have to drop some features from the scope.
Once you have completed your compliance “Golden Triangle,” it is vital that this information is incorporated into the overall product definitions and schedule, as you are the project team’s expert on these certification activities. Just think of scope, schedule and resources like the law of conservation of energy; you can’t give to one without taking from another, and you can’t magically create one out of thin air. The mantra of “Faster, Cheaper, Better” I used to hear in the 1990s was a denial of this reality, and would almost without fail result in products that were late to market, with high cost overruns, and de-featured so they could be shipped, to the point of making them undesirable.
Have a Plan B
In compliance engineering, as in life, it’s always good to have a backup plan. Market conditions change, technology advances, and suppliers can go out of business, so identifying the most critical links in your project processes is important in preparing alternatives for when things don’t go as expected. In project management terms, this is called risk management.
Think of the most critical paths on your project compliance schedule, such as product testing, agency submittals, and department members. You will realize some things you will have control over, such as where and when you perform EMC tests, and others you don’t have control over, like how long it will take for BSMI to review your submitted test reports. So for risk management, we will focus on the items where we have some control, such as choosing which test lab to use, and we will document the items we don’t have control over, like creating an estimated timeline for BSMI approvals, based on historical averages.
The time to address risk management is well before you have an issue. If you’ve just delivered your new product samples to your favorite test lab you’ve been using exclusively for ten years, and it is put out of business by a freak flood the next day, that is not the time to realize you have no plan B. Frantically calling labs all over the country to find out if anybody can fit you in right away so you can still meet your schedule is not risk management, it’s a crisis.
While most large and medium sized companies have disaster recovery plans, most of these are focused on overall infrastructure issues, such as finding new offices, restoring power,
and rebuilding IT and communications networks, and are not specific to the needs of the individual departments, such as compliance engineering. You are the experts on what is needed to operate your group, so it is up to you to define and make these alternative plans in advance of issues, so you can quickly implement them with as little impact to your projects as possible.
It is a good idea to have a team made up of several compliance staff members when formulating these plans. Having different levels of experience and backgrounds will help in developing a better overall plan, which will address the most critical areas presenting the highest levels of risk. You can start by brainstorming on the biggest risks, then following that up by rating each item for the potential impacts to a project, and the likelihood it could occur. Then you could create an ordered listing, from highest risk to lowest, and choose the top ten items to address in your risk management plan. Over time you can add in more risks to address, and you should also periodically review your risk management plan to make sure it is still addressing the likely major risks.
Here’s some examples of common compliance items needing contingency plans:
- Having internal test labs
- Losing key staff members
- Project load increases with a hiring freeze
- Regulatory documentation and certificates data storage
- Test equipment failures
- In-country representatives
- Product recalls
- Critical component suppliers
Once you have made your plans, they need to be documented, and the compliance team will need to receive training. There will also need to be someone designated as being in charge of these plans, making sure they are complete, periodically reviewed, and kept current. My experience has been if the attitude is “everybody is in charge” of the risk planning, then nobody is in charge.
The purpose of risk management is to lower the possibility of catastrophic impacts to the project by being ready to quickly implement prepared contingencies on the areas where you have choices and influence. Once you get into this mindset, you will start seeing the possible risks in other areas of your compliance work, and you’ll be able to make those processes more robust. Start by evaluating your own situation, and develop your own plan B.
Deliverables
Deliverables is simply project management-speak for your work product. In our world, that means compliance test reports, agency submittal forms and applications, and other required documentation supporting product certification and approval activities. This can be a key area for finding efficiencies, lowering costs, and increasing accuracy in submittal documentation, depending on the current processes in place at your company. Here’s the story of one of my experiences.
One of the first jobs I was assigned when I started my quest to learn about project management was the task of looking at our internal EMC compliance report writing process. I was at a global ITE development and manufacturing company, and we sold our products into over 200 countries, so we were dealing with a lot of regulatory agencies. We were receiving critical feedback, rejected reports, and complaints from almost every agency, mostly due to inconsistent report formats, and the large number of errors in the reports. Also, our EMC engineers were complaining, because the multitude of compliance reports they had to write for each product they were assigned was taking up an ever-larger portion of their workday, keeping them from their engineering duties. All of this was giving management a king-size headache; I couldn’t find anybody who was happy with the status quo.
I started off by interviewing agency contacts and our own EMC engineers, to document all of the issues, and to also define what actually needed to be accomplished to support the intended outcome of successful EMC agency approvals. The EMC agencies main complaint was that every report they received had a different format; they might receive one with radiated measurements in the front part of the report, followed by the conducted data, then concluding with the written portion of the analysis and summary, and the next day they would receive another with a totally different design and organization with sections covering combined radiated and conducted measurements for different voltages. They wanted a consistent standard report format to reduce the amount of time necessary for their reviews and so they could more easily identify errors in the reports.
In my interviews with the thirty EMC engineers we had in our regulatory compliance group, I discovered that each engineer was using their own individual report design, and thus I found the agencies had a valid complaint. We were, in fact, submitting thirty different versions of EMC reports. As to the errors contained in the reports, this seemed to be related to an overload of work and the reports were not being reviewed internally to catch mistakes prior to being sent out. For each assigned product, the engineer had to write eight different types of EMC reports. This could take more than a week to complete because the engineers had to gather the data, samples, photos, and everything else required for the submittals and also complete all of the agency application paperwork. Between this and their normal engineering duties, reviewing reports was not a priority, so it wasn’t happening.
After analyzing the agency requirements for the reports, I could see that we were wasting a huge amount of engineering time and resources with this system, as well as hurting our reputation and relationships with the agencies. I determined that a large part of the report preparation did not need an engineer to construct it, but how could this be addressed?
Our solution was to use this as a cross-training opportunity for our EMC technicians. This would free up our engineers to focus on engineering tasks, as well as implementing three levels of critical reviews of the reports. The EMC report templates were reduced to eight standard types, covering all of our worldwide market countries, and the product information, test data, and photographs added in by the technicians. The technicians would then review their work, checking against the original data. Next the EMC engineer assigned to this project would add in his or her engineering analysis, conclusions, and summary, then review the entire report for completeness and accuracy. The final report review would be conducted by another EMC engineer outside of this department. Each of the three reviewers would sign the report, and, to ensure accountability for the task of report reviews, their annual performance review included a metric for report accuracy.
Your situation is probably different, but ask yourself some questions about how you generate your deliverables:
- Can you automate any part of the process?
- Do you use standard templates?
- Who’s doing the data entry?
- Who reviews reports?
- Have you sought feedback from regulatory agencies?
Elephant #2: Communication & CLEs
In over two decades of product development projects, every project I have observed or participated in that was canceled, late, over budget, or in some other category of failure, had one thing in common: somewhere a critical communication was not delivered. Sometimes it wasn’t sent, other times it was not received, but the root cause I attribute to these transmission failures are assumptions. Assumptions may be human nature, but they kill effective communication.
In formal project management, the term stakeholder is used to mean anyone that is involved in a project, or affected by the outcome of a project. In the product compliance field, our stakeholders are our product development teams, management, regulatory agencies, and our customers, among others. Having constant and timely communications with our stakeholders is vital to having successful projects (Figure 2). Remember that communication is a two-way process; both sending and receiving, and to increase your chances at success you need to listen to your stakeholders a lot more than you talk at them. Regular communication with stakeholders also makes it more likely they will return the favor and keep you in the loop on any relevant information they receive.
Figure 2: Constant communication is the key to successful projects
At the beginning of your project, you should find out who is on the project team. This will be the group of stakeholders that you are in contact with the most. Find out their requirements and intended uses for project information; such as how often, and how much detail is needed. Next, do the same for stakeholders outside of this team who will need to know about any changes as quickly as possible, such as management (who can help when you run into obstacles), and your customers who will actually use the product (or marketing, as the customer’s representative). Provide project updates frequently, which might be weekly updates, but for critical issues daily updates may be required. The important point is to be out in front of the news cycle, meaning you are the one providing the latest updates, not the company rumor mill.
This up-front communication is important in keeping everyone informed so the current information can be used when making team decisions, but it is invaluable for those times when bad things happen to your project. If the project team hasn’t heard a peep out of you in the first three months of the project, and then you speak up for the first time proclaiming that the compliance submittals have all crashed and burned and there is no way the approvals will be received by the ship date, you will just have killed your credibility for future projects. If you had been providing those weekly updates, there would have been earlier indications of issues and someone else on the team could have stepped in to assist you to keep it on track. Don’t get the reputation for only being a bearer of bad news; we in the compliance field have a hard enough time as it is. Make sure you are reporting the good news when everything is going well.
One of the stronger impulses in humans is to try to hide bad news when it is received, hoping it can be fixed before anyone finds out, but this is another project killer. Usually by the time the truth comes out (and believe me, it will come out) the small, solvable problem has become a huge crisis and can be the death of a project. Stay open and honest, keep the constant communications open, and keep your integrity. This will open up the possibility for novel solutions from other team members and leaves open a path for you to recover your good name.
So speaking of bad news, let’s talk about something called a “Career-Limiting Event,” or CLE. I first learned about CLEs from my first compliance manager, and later mentor, Dave Staggs, who also taught me how to recover from them, which I’ll outline next. As a human, you will make mistakes from time to time, and every once in a while, they will be an error of monumental proportions. When we are talking about a product development project, this can have huge financial impacts which can result in a questionable employment future, hence the term Career-Limiting Event. If you’ve been keeping up the constant communication with your stakeholders prior to this event, I have advice to share with you on redeeming yourself. But if you haven’t, your time might be better spent on Monster.com.
First, you want to be the first to admit your mistakes. But before you do, you need to do some work, and do it quickly. Research what happened, and why it happened. Next, develop recovery plan options (more than one). This is vital, and the best single piece of advice I ever got from anyone about business: you have to come with solutions, not just talk about the problems. If you only talk about the problems, you’re being a victim. Don’t be a victim; they don’t have long careers.
Once you have all of this information, prepare and practice your presentation. Yes, just like any other presentation, you need to practice to make sure you can clearly and concisely deliver your message. This is not the time to “wing it” and hope for the best; your job security and future prospects may well be riding on this. Stick to the facts and focus on the issues; this is also not the time to start pointing fingers and spreading around the blame. You’re an adult, you made a mistake and you can take the consequences.
As soon as possible, deliver the news. Don’t delay this presentation. Be transparent, direct, positive, and truthful. Don’t dig a deeper hole by guessing or making assumptions.
At the end of your presentation, ask for feedback, and take notes on what is said and asked. Answer the questions you can at this time. If you don’t know the answer, state that you don’t know, and promise to find the answer and get back to them. Follow up on your commitments, implement the selected recovery plan, and then follow up to verify the results. Ensure frequent constant communications with your stakeholders during this recovery phase. Thank your stakeholders for allowing you the opportunity to recover; now is not the time to let pride or ego get in your way.
Admittedly, this is not a pleasant process, and it is not easy, but I haven’t found anything else that works better while also allowing me to feel good about myself. There is a way to avoid this, however.
To avoid your own future CLE, follow this process:
- Learn from the mistakes of others; note what they did right, and what they did wrong
- Learn from your own previous mistakes; and don’t repeat them
- Keep your skills current, be a permanent student
- Stay transparent and open; don’t have hidden agendas
- Assumptions: Don’t make any; communicate instead
- Projects: Verify, review, evaluate, check, re-check
Additional material on project management and communications are available from a wide variety of sources. In addition to the Project Management Institute (PMI) mentioned earlier, which has monthly meetings at local chapters throughout the world, there are many groups on LinkedIn, as well as a host of project management education providers available on the Internet. The IEEE Communications Society is also another great resource, also with monthly chapter meetings that are great for learning, networking, and finding experienced mentors. The only limitations are the ones you set on yourself, so don’t hold yourself back, and keep learning! 
 |
Mark Maynard is a Director at SIEMIC, a global compliance testing and certification services firm with strategic locations worldwide. He is also an IEEE Senior Member, iNARTE Certified Product Safety Engineer, and a certified Project Management Professional (PMP). Mark holds two degrees from Texas State University, a BS in Mathematics, and a BAAS in Marketing and Business. Prior to SIEMIC, he worked for over 20 years at Dell, in international regulatory compliance and product certifications, with various compliance engineering positions including wireless, telecom, EMC, product safety, and environmental design. He can be reached at mark.maynard@siemic.com. |
