Engineering Development, Time for the Ideal Tool

Abstract

This white paper addresses the urgent need for an ideal project management tool specifically designed for engineering teams. As organizations encounter increasing challenges such as fragmented data, inefficient communication, and cumbersome processes, the pursuit of a unified solution becomes crucial. This document explores the challenges faced by engineering projects and outlines the key characteristics of an ideal tool that consolidates project data into a Single Source of Truth (SSoT). It ensures seamless integration with existing software and promotes colocated communication among stakeholders. By automating processes and providing a unified user interface, the proposed framework not only streamlines workflows but also enhances collaboration, decision-making, and overall project efficiency. The implications of implementing such a tool are profound, offering organizations the potential to significantly improve productivity, proactively manage risks, and achieve greater success in their engineering projects. By redefining how projects are managed, this visionary framework unlocks new levels of efficiency and success.

Background Information

Engineering projects often face significant challenges that hinder their efficiency and success. Identifying these challenges is crucial to understanding the need for a more effective project management approach.

Poor communication between people and/or machines.

The organization of projects within companies is currently ineffective for three primary reasons:

1. Inefficient stakeholder exchanges: The communication between stakeholders (intra-company, subcontractors, external consultants, and suppliers) is not efficient, characterized by:
   - Slow question-answer turnaround times
   - Difficulty in using tools due to information format issues
   - Imprecision leading to information loss
2. Poor tool-stakeholder interaction: The interaction between tools and stakeholders is hindered by the complexity of these tools or inadequate training levels.
3. Inadequate data exchange: Data exchanges between different professional software tools, when they exist, are not smooth and often require manual operations.

Several symptoms manifest this situation, including:

• The proliferation of meetings;
• The tendency to search for information from various sources (superiors, subordinates, subcontractors, suppliers, and clients) in email inboxes, where information is least structured but most likely to be found due to its role as a primary communication channel.
• The widespread use of Excel spreadsheets;
• The difficulty of auditing a product's behavior as soon as it goes through multiple jobs (for example, ask an engineering team what the state of a pin on a connector of a device should be and observe the time needed to go through the schematic, then the digital parts, then the firmware source code, etc., to get a response!)
• The establishment of additional quality assurance processes to correct discrepancies and errors introduced by the inadequacy of other processes.

The last measure is essential and a key factor in project success. The significance of quality assurance processes cannot be overstated. It leads to standardization, such as ISO-9001, which is more accessible to large and mature companies. This standardization is crucial for ensuring the quality of products and services, ultimately contributing to project success.

Current Maturity: A Concrete Example

Engineering organizations typically have specialized tools that cover part of the needs related to the coordination of stakeholders and various activities of a project.

For example, in this type of entity for each project, you will find:

• A shared folder on the network (for example on "G", "U", or "Z") with a more or less complex and up-to-date structure;
• Outlook for scheduling meetings;
• Microsoft Project for creating and tracking a schedule;
• Excel for tracking budgets, suppliers, and inventory;
• Doors or Rectify for managing/tracing and covering requirements;
• Jira for managing team activities and tracking technical facts;
• Slack for instant messaging and conferences, or simply Outlook for exchanges and reports.

A Poor Technical Architecture

These tools do not work well together and are used by people with different responsibilities on the project, each having a partial view as their respective tools compartmentalize the data.

Generally, it is the human element that transfers and keeps the data updated between these applications. In large groups with an information systems management department, there are often projects aimed at creating "glues," "bridges," or "gateways" between these tools to specialize them for the organization and improve the overall functioning.

More often than not, this is a lost cause, as it leads to the development of a software house of cards, full of bugs, and also forces the freezing of versions of interconnected software because the result is impossible to maintain, and the whole cannot evolve harmoniously.

Severe Human and Operational Consequences

The fragmentation of data leads to a loss of efficiency, risks of inconsistency, forgetfulness, outdated data, and a lack of a global view of the project at the level of each tool.

"We only addressed half of the actions from the last report."

"Sorry, the specifications for such components have changed, but this has not been reflected in the documentation."

"The validation of such a feature of the developed product was not thought out in advance; we don't know how to test it."

"Oops, we didn't work from the same version."

No automated processing allows for alerts on a lack or risk in the project's development. To address these dysfunctions, the company introduces essential quality assurance processes.

People generally spend as much time on the substantive development of the project as on time-consuming activities such as formalization, documentation, verification, quality assurance, reporting, etc. They spend even more time on these activities when the tools set up for them are poor.

This situation can be represented by a diagram where each data flow between fragmented tools is laborious and leads to loss of information, delays, follow-ups, forgetfulness, and errors.

Root Causes

This situation is often viewed as inevitable or normal. However, the root of this inefficiency lies in the fragmentation of project data. This fragmentation occurs in two primary areas:

1. Functional and responsibility-based fragmentation: Fragmentation among people based on their functions and responsibilities.
2. Software tool fragmentation: Fragmentation between software tools.

Each data exchange between people or tools introduces friction, resulting in:

• Delays
• Inconsistencies
• Losses
• Version errors

Currently, it is the responsibility of employees to establish connections, analyze situations, verify, and trace back the chain of events. This task consumes a significant portion of the work time of engineers, managers, and quality assurance personnel.

Objectives of the white paper

Define the ideal tool features and demonstrate the feasibility of a framework that allows the implementation of the ideal tool.

Theoretical Exercise: Defining the Ideal Tool, What should it allow ?

In this section, we embark on a theoretical thinking exercise to conceptualize the characteristics of the ideal tool for engineering teams, quality assurance, and management. This exercise is unconstrained by technical limitations, allowing us to explore the possibilities of an ideal tool without consideration for technological barriers.
Key Characteristics of the Ideal Tool

1. Single Source of Truth (SSoT) AND complete: A centralized platform that consolidates all project data, ensuring a single, reliable source of information for all stakeholders. This eliminates data duplication, inconsistencies, and the need for manual data synchronization.
2. Seamless Integration with Company Softwares stack and Industry Standard: The ideal tool integrates with all company's softwares, including ERP (Enterprise Resource Planning), CAO (Computer-Aided Design), PLM (Product Lifecycle Management), CRM (Customer Relationship Management), and requirements management tools, and use an industry standard format/API for data exchange and integration. It is the responsibility of third-party software to integrate with this industry standard, not the company's responsibility to painstakingly maintain glue between its tools.
3. Colocated Communication and Project Data: The communication tool is embedded within the project data, facilitating real-time collaboration and ensuring that all project-related discussions are linked to the relevant data. This approach minimizes miscommunication and ensures that all stakeholders are on the same page.
4. Unified User Interface: A user-friendly interface that provides access to ALL project data, discussion, dashboards, and processes in a single, intuitive environment. Key quality factors include data navigation speed and smoothness, ease of use, and a minimal learning curve.
5. Self-Enforced and Automated Processes: The ideal tool automates most project management and quality assurance processes, ensuring that they are self-enforced and comply with organizational standards. This automation minimizes human error, increases efficiency, and frees up resources for higher-value tasks.
6. Global Project Overview: The tool provides a comprehensive, real-time overview of the project to all stakeholders, enabling informed decision-making and proactive issue resolution.
7. Early Identification of Risks and Opportunities: The ideal tool identifies potential risks and opportunities early in the project lifecycle, allowing for proactive mitigation and exploitation strategies.
8. Change Impact Analysis: The tool performs automated change impact analysis, ensuring that all stakeholders understand the effects of changes on the project scope, timeline, and budget.
9. Customer and Contractors Relationship Integration: The tool facilitates the integration of customer and contractors' relationships, enabling smooth data exchange and messaging, ensuring that all stakeholders are aligned and informed throughout the project lifecycle.
10. Access Right Management: The ideal tool includes robust access right management, ensuring that each stakeholder has access to the information they need while maintaining the security and integrity of project data.
11. Version Management: The tool includes version management, enabling travel in the project timeline, and ensuring that all stakeholders work with the latest version of project data and documents, minimizing errors and inconsistencies.

Each of these key characteristics comes with inherent difficulties, making them seem unfeasible. Let's explore why.

Probable Difficulties and Paradoxes

Tool Overview

Now, let's outline the envisioned design of this tool.

Description of the tool

Data

project data: file is evil

No folder and file tree structure match project complexity.

When project data is stored in a filesystem tree, a file often needs to be in multiple places simultaneously, which is not desirable. The true data structure is a graph, so no filesystem can precisely match the real data structure.
Worse, the data must not be hidden in files that you sometimes don't even know exist.
The data must reside in the UI to be discoverable when navigating project data.

By decoupling data storage from data navigation, data access becomes obvious (from the UI), and most importantly discoverable, it shows up in the UI when you browse anything related to it.

File must be only acceptable for complex software format (CAD, etc.).

project data: everything is tree/graph

A project is the combination of an objective, individuals with their responsibilities, and material and financial resources.

The objective is often detailed in a specifications document, whether it is a client specification or an internal project. In any case, the objective can always be broken down and detailed at multiple levels. It is also common to decompose the objective into tasks (work breakdown structure) and responsibilities (organization breakdown structure). All these project aspects are represented by a tree-like data structure.

Furthermore, all project data, including architecture, design, testing, costs, and scheduling, are intrinsically trees. Everything in a project naturally breaks down into a hierarchy, thus forming a tree data structure: tasks, roles, costs, resources, etc.

However, all these concepts are closely linked, as resources are assigned to tasks, designs are justified against requirements, etc. Therefore, the global project data structure must be considered as a graph made of interconnected specific trees.

Once the true nature of the data is clear, it is possible to create a unique data model to store, manipulate and visualize the project's data.

technicals data

We can't replace dedicated and very complex tools such as Software IDE, CAD, simulation tools, project management tool.

The ideal tool should automatically integrate all data from the company's software stacks into its data model. This ensures that any modifications made in a specific tool are seamlessly consolidated within the tool without additional effort.

This integration should be facilitated by third-party software editors adhering to an industry standard.

Once an industry standard is established, it becomes feasible for anyone to develop a specific bridge.

The significant shift lies in the fact that it is now necessary to develop a 1:1 bridge and not 1 to N, which provides a strong incentive for third-party software developers to do so.

We can now make a unique project data model for both technical data, process data, and management data. This data model can be completely generic.

We therefore achieve SSoT, completeness, and Seamless Integration.

UI

The tool must provide a User Interface that enables the visualization and navigation of any kind of data, without being specific to any content. This interface should facilitate the visualization of relationships between data entities.

A node-based navigation interface is essential for representing graph data, where relationships are depicted by edges.

This interface should allow for zooming in on the graph to focus on specific details.

Users should be able to share their user interface view, facilitating real-time collaboration and knowledge sharing.

The navigation should be multi-layered, with more detailed information becoming visible at different zoom levels.

To facilitate focused analysis, the UI should include filtering capabilities to concentrate on specific types of data.

Modern collaboration features are also crucial, including real-time awareness of other users' pointers and cursors, as well as the ability to interact in chats and leave comments. In-context communication is vital, and the UI should provide chat boxes at any point within the data graph, allowing users to discuss specific concerns directly in the context.

When applicable, access to this user interface can be shared with customers, providers, and subcontractors by filtering their views. No more PDF or A4 document exports, anachronistic paper analogies, that make no sense in the current world and are symptoms of a failed digitalization.

Thus, it is possible to create a graphical representation that allows displaying any project data in its context, within a unified, aesthetically pleasing user interface capable of visualizing a high density of data in an intelligible and structured manner.

We therefore achieve Unified User Interface, Colocated Communication and Customer and Contractors Integration.

Process description language (chorus description language)

While there is a huge benefit in being able to browse and interact efficiently with a consistent data set, the aim is obviously to derive value from it. Let's imagine a process description language built to express KPI extraction and QA enforcement.

Many processes in various fields resemble an integration or aggregation through a data tree. Often, professionals perform these tasks daily without realizing they are applying algorithmic principles identical to those of their colleagues in different jobs or industries.

• Cost computation
• Power consumption
• Safety and reliability analysis
• Thermal management
• Etc.

By defining a formal language enabling those process descriptions, we can both define AND enforce these processes effortlessly and automatically.

# a theoretical and illustrative example :
FOLLOWING(edge::COMPOSED_OF) FILTER(NODE::type = bom.part) REDUCE(SUM(bom.part.price)) WEIGHT(edge::count)

This language can be used to extract meaningful and complex KPI from project's data. A company can define its process as a set of formal rules, and simultaneously monitor and enforce KPI and QA, at no cost

Since we have SSoT and completeness, those process and KPI are safe and reliable.

We therefore achieve Automated Processes and Global Project Overview.

Target audience and use cases

The product thus takes a central role in the daily activities of the project's stakeholders. Data exchange becomes instantaneous between the various roles and processes within the project. The practice of sending emails with Excel spreadsheets as attachments after meetings becomes obsolete, and often, some of the meetings themselves are no longer necessary. Interactions between individuals take place continuously within the tool.

The structuring and centralization of data enable the execution of high-value-added tasks throughout the project's development (automatically and at zero cost), such as:

• Visualizing progress status,
• Monitoring the use of financial resources,
• Identifying and assessing process deviations or risks.

Thus, beyond its primary function, the tool has the potential to support management roles (project manager, technical leader) in project development and to alert them to abnormal situations.

• Requirements capture: Workshops, co-design sessions, and technical discussions during the pre-project phase
• Budgeting: Cost estimation, planning, issuing and responding to calls for tender, and Requests for Proposal (RFP)
• Project management: Action tracking, Agile processes (sprints), task allocation
• Requirements management: Coverage, traceability, validation test strategies, IVVQ (Integration, Verification, Validation, and Qualification), acceptance testing (formal client approval of the product), and standards applicability matrices
• Approval/signature workflows: Quality assurance activities
• Risk and opportunity management: Identification, quantification, and action plans
• System architecture/design: Requirements allocation to subsystems
• Documentation management
• Configuration management: Versioning and archiving
• Standards compliance enforcement: EN9100, ISO9001, DO-, MIL-, ESA/NASA
• Progress monitoring: Dashboards, milestone objectives, and reviews (e.g., preliminary design review, critical design review)
• Formalization of feedback: RETEX/REX (return of experience)
• Technical issue/anomaly processing: Resolution and instruction handling

Such a tool preserves the added value of complex processes often found in large organizations while eliminating the significant effort currently required for their rigorous application.

This restores meaning to these processes for individuals. Today, they are often asked to perform activities that seem superfluous and far removed from their core expertise, using inappropriate tools or requiring additional training.

Project manager

Aside from human relationships, which are fundamental in a manager's role, management can be considered as the following activity loop:

• Collecting information
• Consolidating
• Analyzing
• Deciding
• Planning
• Dispatching
• Verifying
• Repeat

By significantly alleviating the tasks in bold, the ideal tool allows the manager to focus on their true value: Analyzing, Deciding, Planning. And no one can pretends it not a good news !

Quality assurance engineer

Quality assurance engineers have at their disposal a precise and continuously updated dashboard of project KPIs.

They can access the smallest detail of the project without having access to specialized software, and really verify in depth the methods and processes.

They can define and build at the same time the backbone of the company development process standard

constractor and customer

They can access in real time to up to date informations, and discuss in the data context, the revelance of requirements, validation strategy, and so non.

Engineers

Engineers accelerate development!
They have access to reliable information, can discuss in the context of the data, and are relieved from many ancillary tasks. The process now makes sense and adds value from their point of view.

How ?

How to do that ? Here is a very brief technical how to.

UI

The UI must render the data graph and allow easy navigation within the graph but also render the data itself in convenient and relevant way. This means that each node render a preview of its content and can be open for reading (only). example an electronic schematic, a source code file, a mechanical part, a requirement, a test, a test result, etc.

The ideal tool can't render all this specific item without keeping fully generic. So The UI is able to load component plugins to add support for specific kind of data.

1. use open industry standard format viewer. for PCB, schematics, CFD simulation, CAD mechanical formats

2. third party software editor provides viewer for their file format. in loadable plugin of UI component libraries.

Instead of having to switch constantly between different software windows, let's imagine we can break down each software into user interface component libraries and build a single integrated tailor-made user interface.

workflow execution

whenever someone edit a project's item in a dedicated tool such as CAD software, FPGA IDE, etc. update must sync in the ideal tool.
to achieve this, each dedicated tool must have its import plugin.

Finally, dedicated tool can provide specific and proprietary feature, that can be triggered from the ideal tool on some events.
Let's say run a thermal or fluid simulation whenever mechanical part is edited, or run automated source code test suites.

So to sum up, the ideal tool is comprised of a core engine and a collection of third party plugins each specific of a software tool and composed of :

• UI component library,
• data sync logic,
• optionally complex or proprietary feature and logic

process automation engine

Everything is graph, every process is a tree reduction

Many processes in various fields resemble an integration or aggregation through a data tree. Often, professionals perform these tasks daily without realizing they are applying algorithmic principles identical to those of their colleagues in different jobs or industries. These similarities highlight the importance of generic algorithms, which allow us to tackle and solve complex problems systematically and universally.

Generic Algorithm

Many tasks in research and development (R&D), production, or project management rely on a generic tree traversal algorithm. These algorithms involve:

1. Defining the data to process: identifying the relevant information to analyze or aggregate
2. Determining the types of links to follow in the tree: choosing the relationships (composition, hierarchy, dependency, etc.) between nodes to structure data traversal
3. Applying a reduction function: combining collected information according to specific rules (sum, average, multiplication, etc.)
4. Including weighting factors: adjusting the importance of data based on contextual parameters (duration, quantity, probability, etc.)

These principles are found in a wide range of practical examples, as a few are illustrated below:

1. Unit Cost Calculation

To calculate the unit cost of a product:

Data to process: costs of parts, manufacturing processes, labor, and tooling.
Links to follow: the hierarchy of the product’s Bill of Materials (BOM).
Reduction function: sum of individual costs, weighted by the duration and quantities required for each step.
Result: a consolidated cost that includes all components and manufacturing steps.

2. Electrical Power Balance

To analyze energy consumption:

Data to process: power consumption of subsystems.
Links to follow: composition relationships between subsystems in an electrical system.
Reduction function: summing the power consumption of subsystems, adjusted for specific characteristics (efficiency, operating modes, etc.).
Result: an estimate of the total system consumption.

3. Reliability Analysis (MTBF)

For a Mean Time Between Failures (MTBF) analysis:

Data to process: MTBF of each component or subsystem.
Links to follow: composition relationships in the system.
Reduction function: combined MTBF calculation, weighted by redundancy or lack thereof.
Result: the overall reliability of the system, identifying critical weak points.

4. Test Coverage Analysis

To assess test coverage:

Data to process: performed tests and covered specifications.
Links to follow: hierarchy of tested specifications or modules.
Reduction function: weighted sum of coverage percentages for each subsystem.
Result: a consolidated view of the project's test coverage.

5. Carbon Footprint Calculation

To evaluate the environmental impact of a product or process:

Data to process: greenhouse gas emissions associated with each component or production step.
Links to follow: hierarchical structure of components or production processes.
Reduction function: sum of emissions, weighted by the quantities produced or used.
Result: a consolidated carbon footprint, highlighting the most impactful steps.

6. Software Dependency Analysis

To manage dependencies in a software project:

Data to process: libraries or software modules used, their versions, and known vulnerabilities.
Links to follow: dependency graph or hierarchy between modules.
Reduction function: aggregation of security risks or compatibility issues, weighted by their impact.
Result: a dependency report that facilitates updating and securing the project.

Formalization of a Language for Automating Processes

To automate processes based on this generic tree traversal algorithm, formalizing a dedicated language is essential. This language should clearly and concisely define the four key elements of the algorithm: the data to process, the links to follow, the reduction function, and the applied weights. The following example illustrates such a formalization:

FOLLOWING(edge::COMPOSED_OF)
FILTER(NODE::type = bom.part)
REDUCE(SUM(bom.part.price))
WEIGHT(edge::count)

This example syntax, inspired by query languages like SQL or Cypher (used in graph databases), offers a modular and intuitive approach:

FOLLOWING: This clause defines the links to follow in the graph. In this example, COMPOSED_OF specifies navigating through composition relationships (e.g., between a part and an assembly). It can include directionality (e.g., downward or upward) or constraints on the types of relationships.

FILTER: This clause selects relevant nodes to process based on specific criteria. Here, only nodes representing parts in a BOM (bom.part) are included. This ensures only necessary data is integrated into the analysis.

REDUCE: The reduction function combines data collected at each step. In this example, the reduction sums the prices of parts (SUM(bom.part.price)). Other functions, such as AVERAGE, MIN, MAX, or custom aggregations, could also be applied.

WEIGHT: Weighting factors refine calculations by incorporating additional parameters. Here, edge::count adjusts the sum based on the number of COMPOSED_OF relationships. This adaptability allows the algorithm to handle complex scenarios like redundancy management or volume handling in logistics flows.

Such a language could be expanded to support:

Conditional traversal: for example, following multiple relationship types (FOLLOWING(edge::COMPOSED_OF OR edge::RELATED_TO)).
Dynamic weighting functions: calculated based on contextual data, such as coefficients adjusted for seasonality or uncertainty factors.
Multi-level reductions: enabling the combination of multiple metrics into a single analysis (e.g., calculating both cost and carbon footprint).

By combining expressiveness and modularity, this language opens up possibilities for automating complex processes while enhancing their traceability and transparency. Coupled with a dashboard-style user interface, it allows any company to implement and enforce its process effortlessly.

Conclusion

In this white paper, we have explored the pressing need for an ideal project management tool tailored for engineering teams. The proposed framework emphasizes the importance of a Single Source of Truth (SSoT), which consolidates all project data into a centralized platform, thereby eliminating data duplication and inconsistencies. This foundational characteristic not only enhances data integrity but also streamlines communication among stakeholders, fostering a collaborative environment.

The tool's seamless integration with existing company software and adherence to industry standards ensures that data flows effortlessly between various systems, reducing manual operations and the associated risks of errors. By embedding communication within project data, the tool promotes colocated communication, allowing stakeholders to engage in real-time discussions directly linked to relevant information.

Furthermore, the unified user interface simplifies access to project data, making it intuitive for users to navigate complex information. The automation of processes minimizes human error and enhances efficiency, enabling teams to focus on high-value tasks rather than administrative burdens.

The implications of implementing such a tool are profound. By addressing the root causes of inefficiencies in project management, organizations can expect significant improvements in productivity, decision-making, and overall project success. The early identification of risks and opportunities, coupled with automated change impact analysis, empowers teams to proactively manage challenges and capitalize on potential benefits.

In conclusion, the envisioned ideal tool not only redefines project management practices but also positions organizations to thrive in an increasingly complex and competitive landscape. By embracing this innovative approach, companies can unlock new levels of efficiency, collaboration, and success in their engineering projects.

Author

Antoine Durand

LinkedIn Profile