Integrating SE From a Data-centric Perspective Into Your Organization.
In this second section of part 5 of this blog series, I provide advice to help sell the idea of moving toward a data-centric practice of SE to management.
A major challenge to implementing the chosen SCL for your project is convincing management and co-workers that it is time to implement or perhaps improve your organization’s SE capabilities and knocking down the walls of resistance. Some common reasons for them not wanting to implement or improve SE capabilities include:
“We have been doing product development using our current processes for years, why should we change?”
“Implementing SE from a data-centric perspective may work for others, but not for us.”
“This all seems very complicated, we don’t have the knowledge, experience, or tools.”
“Our current SE work products, like requirements, are managed in an RMT. FFBDs, etc. are models, so aren’t we already doing model-based SE?”
“It is too expensive to procure the needed SE toolset, maintain the tools, and train our people to use those tools.”
“We don’t have the budget to incorporate SE from a data-centric perspective at this time.”
“The expense and associated process to get new SE toolset installed on organizational computers 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 SE tools.”
“We deal with the development of classified systems; controlling access and maintaining security will be too difficult.”
Sound familiar? Often the pushback can be attributed to a lack of understanding risks associated with the current state of the organization, the benefits of moving toward a more data-centric practice of SE, and what level of SE capability is appropriate for your organization.
So how can you convince management that some level of SE 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 SCL tailored to your organization’s needs, they can improve the overall product development process, improve product quality, and, especially, improve profitability of the enterprise.
The more effective the SE processes, the less rework and fewer cost and schedule overruns. By implementing the appropriate level of SE capability, you increase the probability of 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.
We recommend that you first assess what your organization’s current SCL is currently at. Next identify the issues you are having given your current SCL. To help identify issues, you can use the challenges to managing complex systems and the discussion on the benefits of implementing SE from a data centric perspective contained in part 1 of this blog series. If you can, try to quantify, with examples, these issues (could be monetary, opportunity costs given limited resources, time to market, etc.). You can also address the costs associated with having multiple databases and the cost, effort, and issues associated with integrating and sharing data across organizational stovepipes.
Next, determine which SCL you would like to be at that would result in the issues you identified to be addressed. Provide rationale for being at this level. How will being at this level address the issues you identified because of operating at your present SCL. 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 to get to the new SCL. What ROI should they see if they approve moving the organization to this new SCL? What would be gained by investing in the infrastructure needed to get to this SCL 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 SCL or improving your existing SE 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 his or her 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 SE team be the only ones who actually work directly within the SE toolset for the short term. They can work with the other engineering and management team members to ensure the data is accurate and sharable. The broader team does not have to learn the ins and outs of the actual SE toolset immediately, but can have access to the various reports and view the outputs at any time. As the team gains experience with the new SE processes, they can increase their direct use of the SE tools associated with their specific function.
Using the SCLs defined earlier 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 SCL and associated processes and SE toolset 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 SE tools, processes, 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 old tools to see if it is worth the cost and pain to switch (try other Pilot programs if necessary).
This pilot project can develop an example PMP, SEMP, and IMP that can be used as a template for other projects. A project ontology and a master schema can be developed that can also be reused by other projects. Finally, the implementation of a common, integrated dataset for 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 practice SE from a data-centric perspective.
Several key steps include:
- Develop a practical process that implements the chosen SCL. 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 chosen SCL, the SE tools involved, and the associated processes.
- Pick a pilot project to apply your process and assign the grass roots data-centric SE advocates to that project.
- Define and use measures so you can keep metrics so that the ROI of implementing the chosen level of SE capacities 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 SE capabilities consistent with your chosen SCL and chosen SE toolset.
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 practicing SE from a data-centric perspective in your organization when it is considered to be the standard for system 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 SCL your organization will be able to better address the challenges discussed earlier, meet the intent of the MBSE Initiative, reap the benefits of data-centric SE, and move your organization closer to INCOSE’s Vision 2025!
This concludes the blog series “Integrated Data as the Foundation of Systems Engineering”. The concepts discussed in this blog series have been submitted in the form of two papers for presentation at IS 2017. In addition, the INCOSE Requirement Working Group has prepared a draft document with the goal of making the document an INCOSE product available to all INCOSE members. This draft document has been submitted to INCOSE Tech Ops for review and approval for publication.
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.
