Does the phrase “Formal Change Control” lead to scary thoughts like “We don’t have the time to set that up,” or “We don’t know how to do it or where to start?” If this sounds like you, likely your organization is spending more time dealing with the downstream and long term repeated issues than if they took the time to outline a change control process.
While every company will vary, there are three basic phases of creating a formal change control process. Find out how to implement a formal change control process in these three phases.
- Issue or Problem Reporting
- Change Request or Approval Process
- Change Notice or Execution
Phase 1: Reporting & Logging Issues
- Provide an efficient way for anyone in the organization to report and log issues.
- Store issues in an Issue Queue that will resolved it in one of three ways:
- Take no action
- Put the issue on hold
- Request a formal change
Phase 2: Formal Change Request
- The Formal Change Request is the second stage of review that can be handled in one of three ways:
- Rejection
- Request more information
- Approved for further action, either fast track or Full Formal Change
- If the change is approved for further action, it typically is reviewed by a board that will do one of the following:
- Reject the change request
- Proceed to the change notice
Phase 3: The Change Notice
- At this point the change request can no longer be rejected, it must be addressed and acted upon.
- This phase can be defined as Static or Dynamic:
- If it is a Static process, the same departments and teams will be notified and responsible for executing the change
- If it is a Dynamic, a new process is developed specifically for each change
- When the plan is fully defined, typically a change implementation board review occurs.
Formal Change Control processes are simple, the added control of these processes alone could save your organization money in the long run. The possibility of increased productivity and reduced quality issues will far outweigh the initial time and resources required to get a change control process implemented.
We like to keep it simple, not scary here at EAC. For a full overview of how to design an effective change control process, download our eBook, Designing an Effective Change Control Process.
When is PDSA season?
We all know when it’s cold and flu season and what precautions to take to get back to health or at least dial down the symptoms. However, do we recognize when it’s time to conduct a Product Development System Assessment (PDSA) to get our organization back to health?
To analogize a real life situation, if someone is sick and goes to the doctor, the doctor would want to treat the immediate sickness and then propose a physical to determine what else is going on within the patient’s body. The doctor then sets a diagnosis for continuous improvement of health. A PDSA lends itself to something close to this from a product development standpoint.
An organization must first acknowledge a problem from a department stakeholder (i.e: Vice President, Director, Manager). They must obtain an understanding of how this problem effects downstream departments and create a sense of urgency that this one problem, is only one problem, and more problems are likely to be a major inhibitor to reaching goals.
Sure, organizations can operate with these inefficiencies and still make products, but we want them to know that they could make even more products or run more projects by taking part in a PDSA, which is when we come in to align an organization’s goals and measure achievement recognition through a secure and obtainable continuous improvement plan. PDSA’s are our way of measuring an organizations pain in their processes and providing a long-term solution to provide continuous improvement and maintain a healthy organization.
PDSA’s are the only way for EAC to truly understand the heartbeat of a company and the only way a customer or prospect can become a partner. Their goals become our goals for that organization.
Why would you want a PDSA?
PDSA’s are valuable for two reasons. First we, EAC, help clients to see their product development operation as a system which is a critical first step in making the operation better (i.e. more systematic). Secondly, we provide, as the output of the assessment, a set of high leverage improvement initiatives that will directly lead to increased productivity of their product development system.
Organizations may know something is not right with their product development operation – maybe for instance due to the number of recurring fires they fight – but they don’t know where to focus their improvement initiatives until they learn to see their operation as a system as opposed to a process.
The PDSA aligns a company’s business strategies and objectives to product development initiatives to determine areas of improvement. This is so valuable to be able to motivate a company or the internal champion to see how an improvement to a product development system would be tied to or contribute to a portion of the company’s objectives.
For example, an organizations objective or value opportunity is to reduce product development cost. Then we would streamline the product development system by making sure the people, process, and technology within a product development process are all working together without disrupting another part of the product development process thus taking waste out of the system enables reduction in cost.
During a PDSA, we engage with multifunctional groups within a company to extract process information and where waste is. Over and above that, a continuous improvement strategy will be set in place for the company to achieve the desired state or desired maturity level. Without an investment in continuous improvement, a one-time fix to a process or system will not sustain in the long term.
What’s so great about PDSA’s?
PDSA’s are learning events and EAC consultants learn something new with every PDSA because of the uniqueness of each client we work with. Beyond spreading our understanding of seeing operations as systems, it is exciting to be able to learn the details of the client’s operations and then provide critical improvement information.
The ability to tell an internal champion or the economic buyer that their organization is “leaking oil” or specifically being able to quantify to them the dollars being wasted, and that we, EAC are here to help reduce that and get them in a better state excites me. The ability to whiteboard the organizations processes and ask them why they would perform a certain task in that fashion. The ability to ask the tough questions, like “what is the biggest headache or challenge they have right now?” and “what is working well for you?” The ability to help the champion to present to their executive board is what is rewarding in the end.
We live and breathe to make a difference for our customers. PDSA’s are a mental marathon that test every part of a person’s attention to detail, savvy, note taking, and overall listening abilities. The challenge is what we get revved up for. We never know what we are going to find.
For over 20 years I worked in the manufacturing industry as a designer, CAD or IT manager. One issue I have seen and experienced many times is the difficulty of getting upper management to understand the need and benefit of getting the latest CAD, PLM systems, or any other IT systems. In each role there was always the need for new software to keep my teams and systems as productive as possible. In this blog I will, at a very high-level, outline how I was able to get upper management to buy in on projects I felt were needed.
Very early in my career I was a CAD administrator. At the time we needed new CAD software. I was able to talk to upper management very often. I would try to explain and tell them the need. I would verbally walk through the benefits and even give them demos of the software. But… they would not want to pull the trigger on buying the latest software. I could theorize with them until I was blue in the face. It just didn’t matter.
Then, a mentor of mine recommended I put everything to numbers, such as creating a ROI and roadmap of what was required to implement the new software. So, I did. First, I did time studies against what we were doing today. I did this by getting input from various different users. This was basically recording how long it took them to do the most common tasks. I would always take multiple samples and then take the average. Then, using a trial install of the new version of software I was able to get comparisons for each use case tested against current software. I put the time savings to cost savings based on hourly rate averages. I also related it to increased engineering department output capabilities. For instance, our department could produce four projects a year. With the time improvements we can now produce five.
The next time I spoke with my manager, I simply put a one page short summary of total potential time and cost savings in front of him. Which in this case, immediately got his attention. He of course wanted to know how I came up with those numbers. I had to be ready to back my numbers up. I did this by giving him a more detailed page and walked him through my findings at a high-level. I also had a page outlining the general implementation roadmap with a timeline summary. Only three total pages, not a short novel. He could no longer just dismiss or put off the need. I received approval to proceed with my plan in less than a month after presenting my numbers to my manager. In this case my manager was one of the company owners, but having hard numbers and a tentative plan got the ball rolling.
One thing to note from the above example, by doing what I outlined above, it elevated my standing at my company. They were impressed at my willingness to push for, justify, and plan for something I believed in. Not just asking them to take on the burden of something I felt was a good idea.
This scenario was repeated throughout my career. I could bring in vendors to demo their product, put quote after quote in front of management. Meeting after meeting with vendors and upper management, I could not get management to agree until I took the time to document the true benefits in time and money (roadmap and ROI).
If you have product or process improvements you feel will benefit your company, you need to show your management that you truly believe in it. You need to do the needed research and documentation to show the benefit and how you recommend proceeding. You cannot just go and tell management there are problems. You must present a solution for the problem you are identifying. If you do this extra work, it will not only help get your request approved, but will also help how you are viewed by your management.
Look, I know what I am outlining is no small task. It can be time consuming, very time consuming in some cases. That’s why many times this never gets done and needed improvement projects never happen. There is just not enough time for internal staff to do the needed research, and get their day-to-day tasks done as well. That is why you need to partner with a company dedicated to help with product development improvements at your company, such as EAC. We don’t want to just sell you software, we want to help you and your company improve the way you design, manufacture, connect to, and service your products. We do this with our proven people, products and processes. If you and your company improve and succeed, we improve and succeed. We will do as much of the work as we can to help you get the needed numbers and roadmaps put together. There is always going to be some time needed from internal people. However, we try to keep this as minimal as possible.
In summary, if you can see areas where your processes or systems could be improved you need to put it to numbers. You need an ROI and a roadmap to take to upper management. It may seem frustrating at times, but you need to understand where management is coming from. They also have people they answer to. They can’t go to a board, or an owner, or their manager with just a demo and a quote. Not only is that not the information they are concerned with, but you typically don’t get that type of time with them. They need quick and real information to justify the need. You must be willing and ready to get this for them. Just remember, EAC is here to help you do this. Please reach out to us.