You’re in charge of selecting systems engineering tools for your project. What should you prioritize?

Tailoring is one of the most important processes that a systems engineer should master, and project scope and complexity are one of its inputs. Depending on these two characteristics, all the processes and tool usage will be adapted. So the question does not resume to what tools I should use but how intensely I will use them. In the case MBSE perspective, this is a more usual concern to consider since these tools are very flexible and models are scalable.

It's important to prioritize those that are compatible with your existing technology stack, have a strong API for seamless integration, and support standard data formats. Consider tools with advanced analytics capabilities, modular architecture, and support for version control and continuous integration. Additionally, evaluate tools based on their performance metrics, such as response time, throughput, and scalability. Finally, assess the tool's track record, user reviews, and community engagement to gauge its reliability and future development prospects.

The complexity of many types of systems has grown considerably over the last decades. Starting the tool selection process can be intimidating because organizations often only have a vague idea about what they need. In my opinion while selecting System Engineering tools thorough analyses should be done of the actual needs and the available tools, grouping certain things and breaking them into small chunks often give us a clear vision of the desired objective.

Considering the project's scope and complexity is crucial in selecting systems engineering tools. For projects with large, diverse, and interdependent components, involving numerous stakeholders, domains, and interfaces, and where requirements and environments are dynamic and uncertain, the choice of tools becomes critical. For highly complex projects that necessitate formal verification and analysis, a Model-Based Systems Engineering (MBSE) tool is advantageous. MBSE tools enable the capture and manipulation of system models in a standardized language, facilitating a comprehensive understanding and analysis of the system's architecture and behavior.

When working a project of any size, I have found that if i break it down and prioritize each piece, it allows me to create a flow that links the pieces of the project together and assists the natural progression so nothing is missed.

tools integration is a very complex issue and open to interpretation. For instance, is the integration through a import or export of CSV file content; one way push through the use of a third-party tool; a very limited data access through an API; significant configuration to achieve business desired outcomes; or full development of customizations of add-ons and plug-ins to meet basic functionality. Does the team have access to a tools engineer to support the configuration and customization of the tool(s) to support the business and engineering processes such as configuration management, baselining, version control, user access, trade controls, collaboration and auditing.

For efficient systems engineering, prioritize tool compatibility and integration. Tools must align with existing systems, allowing easy data exchange and maintaining consistency across outputs. For agile and DevOps projects, opt for tools that integrate requirements, models, code, and tests in a continuous loop, ensuring real-time collaboration and adaptability. Seek tools supporting common formats for seamless interoperability, enhancing teamwork and project efficiency.

The single most important factor in choosing any tool is whether it supports how you work - or at least supports how you plan to work. Your working practices should drive the tool choice, not vice versa. This relates to the functionality but is often more about how that functionality is presented. For example, you can use a spreadsheet to store requirements, even with traceability, but a dedicated requirements management tool would generally be a much better choice. Similarly, you can draw diagrams using Visio, but you would normally be better off using a dedicated modelling tool.

While agreeing with the others on this point, I feel that we forget the team. The people who will use these tools. So I think it’s important to look at the team too and run some interviews. See what skills they already have, what is their experience with various tools and what would they recommend. You might learn more salient information to support the decision process. And in the end of the day if you can select tools that your teams is already familiar with you will save a lot on upskilling. But I need to articulate again: a tool is useless without a clear process. Tools need to support and implement your business process not the other way around. You’ll shoot yourself in the leg if you try to deploy the default process of a shiny tool.

In a manufacturing environment. The tools are often pre-defined and have existed as long as the tool has been in use. More and more I feel that the most important tool is your support team and listening to the ideas around using the tools and possibilities for improvements.

I have found that doing an evaluation of the Product Specification is not very useful to understand the functionality and usability. A pilot team needs to identify requirements and use cases to evaluate the tool against and run those use cases. In the past vendors claim a feature or function and in reality the function does not work for the specific project, engineering domain especially when indicating the tool can integrate with other tools. Another is product support with many companies I have found to be poor.

Prioritize tool functionality and usability, ensuring they meet both functional and non-functional requirements. Tools should be user-friendly, reliable, scalable, and customizable to your project's specific needs. Evaluate features against your criteria, considering tools that support complex analyses like multi-criteria decision analysis for projects with intricate trade-offs.

Ones that: 1) help all think together 2) record your developing understanding and decisions 3) enough of your team can use Don’t be a zealot or purist about best practice

Assessing the ROI of implementing a tool may not be an easy task. First, the full life cycle costs (including operational costs, support costs, etc.) of the tool should be considered. Second, the value that the tool brings to the respectives activities should be determined, what is usually a tricky thing to do. The adoption of a tool impacts activities and products in a systemic way and the consequences of using or not a given tool may be felt only after many years, by different stakeholders, in different contexts (e.g. operational issues due to problems in requirements that were managed without a tool support) being very hard to measure or estimate. Sometimes you need to go for a “rational leap of faith”.

Depends on the following 1) level of competency of the team in the various areas of SE such as Requirements Engineering, Architecture, V&V with in the tools space. 2) What are the critical areas of risk and possible defects in the System of Interest (SOI) requirements, customer risks and business risk. 3) Identify the digital thread tool chain based upon the SOI, customer and business risk to mitigate these risks and support project success. 4) Identify compatibility of tools in an integrated, interoperable and collaborative environment that support an ASOT (Authoritative Source of Truth) to support the team in developing successful system on time and budget.

Consider tool cost and availability, balancing acquisition, maintenance, and upgrade costs against your budget and project needs. Assess tool accessibility and security for all team members. Optimize value and ROI by comparing costs with benefits, focusing on long-term implications. For projects with limited budgets and timelines, choose affordable, user-friendly, and readily available tools.

Another key support aspect is the projected longevity of the tool/tool vendor. For complex multi-decade programmes, one should consider that vendors that are likely to be around for a long time to minimise obsolescence issues for tools assessed as critical.

When implementing a tool in your work environment, it is crucial to provide the necessary training for your employees and to have technical support at least until people get confident in its usage. Nowadays, most of the tools are offered in a subscription model that already includes support. However, when acquiring perpetual licenses, this aspect shall be observed.

For 100% service work achievements are totally depends on tools. In engineering dept Tools are playing major role. how you are using it and How you are maintaining both are very important factor. In simple words proper tools handling can prevent major or fatal incident. Handling tools training should be given to each employee once in year.

Prioritize tool support and training. Ensure vendors offer ample support and guidance, and that training resources are available for your team to use the tools effectively. Look for tools with comprehensive documentation, online tutorials, forums, and help desks, especially for new or complex tools. Adequate training and responsive support facilitate smoother tool adoption and utilization.

Efficient optimization is a crucial aspect to consider when defining project requirements. This approach focuses on meeting the needs of all stakeholders while minimizing the resources required for project execution. To ensure optimal performance, it is highly recommended to assess and enhance network capabilities.

Even the best tools will not compensate for poor process or lack of user knowledge. Automating a bad process will get you in the same mess more repeatably. Understand your process. Evaluate your requirements for the tool, plan your tool verification, design your tool architecture, including how you will work up and down the supply chain - in short use your engineering practices on design of your toolchain.

I'd also include the skills and experience of the team. A team that is already very experienced with the tool will have it up and running and performing in no time. A less experienced team may struggle to add the same value with the tool without further training which takes time and effort.

Consider the 'Whole Lifecycle Cost' of the tool as well. How many licenses do you need and for how long? Is your team going to grow? Which means a cost growth? Do you need IT support for the tool? How much is the training programme to bring on new starts? Is it an upsell model where higher levels of functionality increases the cost?