As individuals and organizations deploy model-based systems engineering, the unwary fall into several traps: starting too big (or too small), chasing standards, focusing purely on the tool (or technical) dimensions, and more. In an earlier blog, I discussed 7 classic errors or anti-patterns to avoid. As we look for positive patterns to implement, there is no “one size fits all” deployment model that will work for every organization and every situation. However, at the risk of being too much of a systems engineer, we can choose to treat this as a systems problem, spending time to analyze the problem and context before moving to implementation. Just as we systems engineer our products, we can – and should – engineer our organizations, processes, and change initiatives. Practicing what we preach, there are six simple steps that will fundamentally change the impact and increase the likelihood of success of your MBSE deployment.
Step 1 – Begin with your end in mind. When we think of this statement, we classically think of getting the right technical requirements in place at the start of the project. This is necessary but not sufficient as technical requirements and the voice of the customer are just one dimension. We must also listen to the voice of the business to understand those requirements and objectives. When undertaking a change initiative, the business need and value as voiced by a strong internal business champion is absolutely essential.
While it is true that MBSE can deliver “better, faster, cheaper”, positioning any approach, technology, or change initiative in that way is a fundamental error. First, positioning anything as satisfying all three conditions at once sounds like a silver bullet which we are conditioned to reject. Second, pursuing three simultaneous goals in a change initiative will likely lead to failure. The initial insertion and adoption of MBSE is best achieved if tuned to deliver against specific business desires, whether resolving a problem or leveraging an opportunity. This is one reason why trying to “keep up with the Joneses” and following their approach is a classic error in deploying MBSE.
What was key for their organization may not be essential for you. Is your business need increased quality because the cost of a single system failure is simply too high? Is it responsiveness to evolving customer needs? Is it agility in the face of an accelerating technology insertion cycle and an ever-changing environment? Is it effectively engaging across organizational boundaries to increase creativity and innovation?
MBSE can support any of these objectives. MBSE done well can deliver against multiple objectives simultaneously. However, an organizational change initiative (and deploying MBSE is an organizational change initiative) is best tackled by focusing on one or two priorities and tuning the implementation to ensure delivery against those objectives. Begin with your end in mind, and you are far more likely to undertake a journey that will get you to the destination.
Step 2 – Identify critical stakeholders. As we factor in the voice of the business so that we understand the overarching objective(s), systems engineering teaches us to identify all of the stakeholders to ensure we define the right problem and define the problem right. Overlooking the needs of a critical stakeholder leads to missed requirements. Missed requirements lead to schedule delays, cost increases, degraded performance, decreased satisfaction, and potentially system failure.
In the case of deploying MBSE, who are our stakeholders? The systems engineer immediately leaps to mind, but there are many others. If we consider the project team, we must include test & verification, design teams, subject matter experts, project management, and more. Looking beyond the project team, we operate within a larger organizational framework. This means we must include the business champion, management, the IT support organization, and process owners to name just a few. And taking a step back, certainly the customer, the user, and other project stakeholders would be stakeholders as we deploy MBSE.
In effectively executing a change initiative, we need to understand who all of our stakeholders are in order to ensure we do not overlook a critical need. However, we do not seek to serve them all on equal footing. When considering the objective you are seeking to achieve, which stakeholders are critical as part of this MBSE initiative? Certainly project team members adopting new processes and leveraging new technology are key, but it doesn’t stop there. The business champion supporting the change initiative is absolutely a critical stakeholder. Depending upon your culture and how your project operates, your customer may be a critical stakeholder interested in the initiative or may be a stakeholder to insulate from the change initiative. Identify the critical subset so that you can prioritize their needs, but do not overlook the others.
Step 3 – Elicit requirements and constraints. With the overarching objective to guide us and the critical stakeholders identified, we are positioned to elicit requirements. What do the stakeholders want and need in support of the objective? Classic needs that emerge include improved communication within the team, reduction in manual processes, elimination of error-prone steps, streamlining of bookkeeping tasks, enhanced connections across the engineering lifecycle for accelerated analysis, increased opportunities to innovate and explore design solutions, and more.
Just as important as the wants and needs of the stakeholders are the fundamental constraints that cannot be violated as you deploy MBSE. These may be process constraints critical to demonstrating compliance or supporting practice maturity levels. These may be organizational constraints regarding the handling and archiving of information. These may be contractual constraints defining how you communicate with customers and external stakeholders. Holding everything fixed and expecting change is a way to kill a change initiative before it begins. However, initiating change without awareness of – and respect for – true constraints is a prescription for failure. A good systems engineer challenges constraints, identifying those that are truly fixed, those with some degree of freedom and flexibility, and those willing to be abandoned in the face of new benefits.
Step 4 – Define the system boundary. Perhaps the most important step in any systems engineering effort is properly identifying your system boundary (or reengineering your system boundary to deliver greater value). Looking for the system boundary as you deploy MBSE is just as critical, deliberating deciding what falls inside and outside the change initiative.
With change, we often overreach in scale as we see all of the potential and therefore go for a “big bang” change. In this situation, at best we succeed in some areas and fail in others as we simply tackle too much all at once. At worse, we trigger the organizational immune response and area shut down. We need to treat this as a Goldilocks problem – not going too big or too small, instead choosing a scope that is just right.
The objective is to compartmentalize change and then treat the change initiative as a black box. Place change agents inside the system boundary and empower them. Protect those outside of the system boundary from any change. This means analyzing and honoring every existing interface in both content and format. Do not change the information you deliver, the schedule you deliver it on, or the format of information exchange – even if the change is as minor as substituting one diagram type for another. Any change which impacts others expands the system boundary, and a creeping system boundary will cripple the change initiative. The objective is to treat the system like a black box. What goes on within that black box should not concern those outside of the system boundary. Remember, change is difficult and many resist change that they do not initiate. This is one case where you want people to ignore you, and those outside of the system boundary will ignore what is going on inside the black box if existing interfaces are honored in content and format.
Step 5 – Identify components and allocate. Within the system boundary, we must develop and deploy a new system that responds to the business objectives, requirements, and constraints. Far too often, individuals and organizations develop tunnel vision and go off in search of a tool thinking that MBSE is a technical problem. A software environment that supports your business objective and problem is likely part of the solution. However, it is not the only component of an effective MBSE deployment.
As you look at your needs and develop revised methods and approaches, be deliberate in the definition of your new system design behaviors and the allocation to the right components. Provide yourself full flexibility in design (and maximize your likelihood of success) by thinking beyond the bounds of software tools. How can your engineering process change to fully leverage the evolution from low-fidelity representations in documents to higher-fidelity representations for both communication and analysis? How can you adjust your team boundaries and responsibilities to bypass classic silos and embrace the interconnectedness of systems (and the system model)? What training is necessary – in processes, methods, and tools – in order to properly equip your team? After all, MBSE is far more than drawing pictures and dealing with the buttonology of a tool interface. What value can mentoring bring? How can you establish an internal community of interest in order to share successes and lessons learned as you adopt model-based approaches?
Embracing the full breadth of the solution suite – tool, process, training, mentoring, and community – is critical in effectively mapping the solution trade space. Allocating properly to the chosen components of the solution is just as important as allocation in the product systems you engineer.
Step 6 – Plot the journey map (and the outcomes). Most organizations that find success in deploying MBSE recognize that it is a journey taken in multiple steps. They are deliberate – in planning and in execution – across the implementation phase. Each step of the journey is designed to deliver success in that project. At the same time, each step in the journey is designed to move the organization one step closer to the desired endpoint. While the initial change boundary may be small and the identified business objective narrow, over time the intent is to change the way the organization performs systems engineering and to maximize the business value across multiple dimensions.
With this in mind, for each project plan intentional outcomes to aid the greater organizational journey so that each project has a lasting impact. For example, a given project may innovate with new processes, delivering a new proven approach that works within specific bounds. A different project may result in a generic reference architecture ready for reuse alongside the specific instantiation required for the project. Early efforts should produce internal advocates and mentors as well as a toolkit of artifacts to help those to follow. Everything should contribute to a growing internal community of interest that enables “the new normal” so that over time the focus shifts from MBSE deployment to “the standard way we do systems engineering”. Understand the scope for a project within the context of the greater organizational journey map, explicitly designing outcomes and artifacts that aid the greater journey.
Deploying MBSE in an organization is partly a technical challenge but far more an organizational change and culture issue. The same systems engineering principles used for developing new products are applicable to re-engineering the engineering lifecycle. In doing so, key concerns include psychology, sociology, and all things human because the human plays a critical role in the success of our design system. Identify your why, consistently establish your scope with malice aforethought, honor existing interfaces, and leverage systems principles. Doing so minimizes the number of traps you encounter and maximizes the likelihood of success in the deployment of MBSE at within a project and across the organization.
