Note this is an update to this blog originally posted in 2013.
A major challenge to implementing the chosen RDM capability for your organization and project is convincing management and co-workers that it is time to implement or perhaps improve your organization’s RDM capabilities and knocking down the walls of resistance. I have heard many reasons for not implementing or improving RD&M processes, some of which are:
“We have been doing product development using our current processes for years, why should we change?”
“Implementing an RDM capability may work for others, but not for us.”
“This all seems very complicated, we don’t have the knowledge, experience, or tools.”
“It is too expensive to procure the needed RDM tools, maintain the tools, and train our people to use those tools.”
“We don’t have the budget to define and implement an RDM capability at this time.”
“The expense and associated process to get new RDM tools installed on organizational computers and maintain them is too great.”
“We would have to make signification IT infrastructure upgrades to accommodate the additional volume of data and performance requirements of the new RDM tools.”
Sound familiar? Often the pushback can be attributed to a lack of understanding risks associated with the continuing operations at current state and the benefits of implementing a practical and effective RDM capability appropriate for your organization needed to address both current and future challenges and issues. Many managers don’t understand the importance of having a well formed set of requirements and the role requirements play in the product development lifecycle. I address this issue in my blog entitled “Requirements – What’s the Big Deal????”
So how can you overcome these walls of resistance and convince management that an improved RDM capability is needed? Three words – RETURN ON INVESTMENT! Think about it … what has been the impact of the current, poorly executed product development efforts? Failures, recalls, returns, warranty costs, lawsuits, negative reviews on social media, decreasing market share – not good for profitability. The ROI argument usually works with management especially when you can convince them that by investing in an RDM capability tailored to your organization’s needs, they can improve the overall product development process, improve product quality, and, especially, improve profitability.
Management has to be convinced that with a more effective the RDM capability, the less rework and fewer cost and schedule overruns. They have to understand that by implementing the appropriate RDM capability, you increase the probability associated with achieving a competitive advantage by removing obstacles to being able to deliver products on time, on budget, and that meet or exceed customer and quality expectations.
To convince management, we recommend you first assess what your organization’s RDM capability is currently at and what the current issues are having given your current product development processes. To help identify issues, you can identify the challenges your organization is currently having. Some of these challenges may include:
– Customers dissatisfied with the products
– Multiple failed tests during verification
– Recurring failures in the field
– Cost and schedule overruns and liquidated damages (fines for late delivery)
– High life cycle costs (testing, maintenance)
– Products not performing as intended (lacking needed function and performance)
– Health safety environmental realized risk
– Nonconformance / compliance with industry standards, customer requirements or contract requirements
– High warranty costs
– Expensive recalls
– Decreasing market share
If you can, try to quantify, with examples, these issues (could be monetary, lost opportunity costs given limited resources, time to market, etc.). All of these issues can be traced to a root cause. Studies and experience have shown that a key root cause is the lack of an effective RDM capability or a poorly executed and managed RDM process. Being able to quantify the costs and trace these issues to a root cause resulting from a poor RDM capability is key to showing management an ROI on investing in a practical and effective RDM capability.
The root cause of these issues can often be traced back to defective requirements that are poorly written, vague, ambiguous, and incomplete requirements. The reason for these defects are often an absence of a formal RDM process, a lack of training in implementing and following that process, and/or a failure of management to enforce the existing RDM process. I address the risks to the organization of not implementing good RDM processes in a paper entitled “Triple your changes of project success – Risk and Requirements” Send me an email at info@argondigital.com and I will send you a copy of the paper, a presentation that goes with the paper, and a checklist for a self assessment as to the risks facing your organization because of a poor RD&M process and the best practices you can adopt to mitigate these risks. Concerning the issue of requirements always changing, I address this in two blogs: “Why Do My Requirements Keep Changing?” and “Controlling and Managing Change”.
The information in these referenced sources should provide you with the information you need to make a good case for implementing or improving your RD&M process.
Next, determine what RDM capability would result in the issues you identified to be addressed. Provide rationale for the need for this capability. How will having this capability address the issues you identified as a result of continuing to operate without the chosen RDM capability. Again, management likes to see the numbers. You will need to do a gap analysis to determine what changes will need to be made and a rough order of magnitude of the costs and time needed to define and implement the chosen RDM capability. What ROI should they expect to see, if they approve moving the organization to this new RDM capability? What could be gained by investing in the infrastructure needed to get to this RDM capability and what would be the savings (costs of labor, tools, less defects, less recalls, less rework, etc.) If you can show a positive ROI, management will be much more receptive.
Even if you can make a good case for implementing your chosen RDM capability or improving your existing RDM capability and have management backing in doing so, the rank and file may still push back. When this happens, the source of the push back is more often due to cultural dread and anxiety associated with change; not process aversion.
Changing culture is often met with opposition.
To combat this opposition, you need to use soft skills to manage stakeholders. Determine which stakeholders are for and against the change and why. For each individual or group, identify their concerns and devise a strategy to get the change adversaries to become change advocates. Start with those stakeholders that have the most influence and convince them by addressing their concerns. You may need to enlist the aid of other stakeholders that can help you influence those that oppose the change. Success often depends on having a champion in the corporate office.
Many engineering organizations tend to be very conservative in the way they do business. Rather than making a big revolutionary change, develop a strategy that involves incremental change over time. It is easier to eat a turkey in small bites rather than trying to stuff the whole bird in your mouth at once. For example, initially, you might have the core Systems Engineering team be the only ones who actually work directly within the RDM tools for the short term. They can work with the other engineering and management team members to ensure the data and information is accurate and sharable. The broader team does not have to learn the ins and outs of the actual RDM tool immediately, but can have access to the various reports and view the outputs at any time. As the team gains experience with the new RDM processes, they can increase their direct use of the RDM tool associated with their specific function.
Developing an incremental approach to adopting the RDM capability chosen will enable you to take these small bites rather than having to eat the whole turkey at once. True, it may take a long time to get where you want to be, but as long as the small changes result in improvements and make the engineers’ jobs easier, they will go along with the change. Most people follow the path of least resistance.
You need to make the path you’d like them to follow easier/more beneficial than the current one. If the change is more difficult or makes communication harder, you are fighting a losing battle. For example, your lead engineer or project manager may already be over their head and working 50-60 hour weeks. You want them to learn and implement a new process and a new tool(s)! Good Luck! However, if you agree to provide them with a dedicated engineer that has the training, knowledge, and experience in the chosen RDM process and associated RDM tool to help implement the changes, they will be much more receptive. They will also be much more receptive if this results in them having to work less hours and having fewer crises to deal with each day!
People at all levels must be convinced of the utility of the changes, how the changes result in a better product, and result in less rework for them. [Frequently the reason they are working the long hours is because they are always fighting fires, going from one crisis to another, that resulted from the lack of the proper RDM process, tool, data, and information in the first place! You need to change the culture from one of firefighting to one of fire prevention.] As time passes, they may even start to be advocates for the changes that have been made and welcome further change. Depending on the size of your organization and culture, this process could take several years.
Even if individual projects only last a year or two, organizationally you will be in this for the long haul, you must persevere and not give up and lose faith. Be prepared to make minor course corrections when things don’t work as expected. Always keep the end in mind. Incorporate the incremental changes into the existing process rather than replacing them wholesale. Work to gain acceptance slowly. Get your people used to seeing and using bits of the processes in small ways and grow it outwards. People will never appreciate you telling them that their current way is poor or old fashioned – they must discover the benefits of incorporating your proposed changes themselves. As the old saying goes: “No one wants to be told their baby is ugly!”
Use a pilot project.
It is advisable to study the current organization and workflow and look for a project that you can use to demonstrate the benefits and ROI of your proposed changes in the short term. You can use this pilot project as a viable example to effect larger scale change within your organization.
A small project will allow you to get a feel of what works, what doesn’t, what you like, and what you don’t, etc. – maybe start from scratch to see what is possible, then work back with existing processes and tools to see if it is worth the cost and pain to switch to the new processes and tool (try other Pilot programs if necessary).
This pilot project can develop work products that can be used as a templates for other projects. Finally, the implementation of a practical and effective RDM process tailored to the needs of the project can be worked out. Armed with the lessons learned from the pilot project, the organization can develop a roadmap for new projects to implement the RDM process.
Several key steps include:
- Develop a practical RDM process that meets the needs of your organization. A good process is one that people can follow as part of their job, not something they have to do in addition to their job. Also, the process needs to fit the product line, domain, and culture of the organization. The implementation needs to be tailored to your project. Don’t try to follow a process developed by a tool vendor for some other organization or product line.
- Invest in training in your proposed RDM process, the tools involved, and the associated processes.
- Pick a pilot project to apply your process and assign the grass roots RDM process advocates to that project.
- Define and use measures so you can keep metrics so that the ROI of implementing the chosen RDM capabilities can be clearly communicated.
- Encourage your team to be actively involved in organizations like INCOSE and join working groups whose members can aid the implementation process.
- Invest in an outside consultant who has a proven track record in implementing RDM processes within an organization.
Once the project is completed successfully (an assumption) then the project can be used as an example to get other projects to follow. The core grass roots folks can be spread out among other projects and mentor other project managers and systems engineers and train them and their teams in the concept of practicing SE from a data-centric perspective and in the use of the chosen SE toolset.
In many of the cases where adoption has been successful, there has been both advocacy at the top as well as a strong grass roots support that has gradually gained acceptance across the organization, but typically only after one team has proven success.
You know you are successful in adopting your chosen RMD capability in your organization when it is considered to be the standard for product development. However, the road to success is long – it takes very strong, unwavering leadership and experience to get this done right. It is human nature to try to push back and say that it isn’t possible. It is possible! By implementing the chosen RDM capability in your organization you will be able to better address the challenges and issues discussed earlier reap the benefits of adopting the chosen RDM capability!
Comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
