Quality

Quality in a professional engineering firm is not what the engineers put in. It is what the client gets out and is willing to pay for. A design output is not quality because it is hard to make and costs a lot of money, as engineers typically believe. This is incompetence. Clients pay only for what is of use to them and gives them value. Nothing else constitutes quality.

P. Drucker

The Design/Engineering industry has two clock-speeds:

  • A very slow clock speed: The quality of the service.
  • A faster clock speed: The quality of the product (transportation designs).

We acknowledge the critical distinction between technical quality (how good is our work) and service quality (what kind of experience does the client have with our firm). We focus on clients’ experiences and design these experiences using clients’ journey maps.

Sometimes our clients cannot judge the technical quality of some services even after they have received them. The designing and engineering services are high in credence qualities – characteristics the buyer normally finds hard to evaluate even after consumption. How could someone for example evaluate a technical report on the durability of an existing structure?

Because the quality of professional services depends on who provides them, when and where, and to whom, transportation designing services are highly variable. We have reduced this inherent variability by applying our four operational frameworks: Design Thinking, FEED, Scrum and CCPM.

Inside Race we give emphasis in three qualities:

  • Quality of Information.
  • Quality of Process.
  • Quality of Discussion.

Quality Assurance in Race

During our operations there is no one group of experts in Race that "Assures Quality". Quality as a whole has a lot of dimensions and it takes the entire team of skilled transportation designers and engineers working together to solve a given problem with design.

In transportation design development there is the phase where design is developed (this is also the phase where design bugs and errors are introduced) and there is the phase where design errors are found and then hopefully fixed. The closer those phases are with each other, the sooner the design team members understand the perceived quality of the design product under development.

So, is there a place for factory design testing in Race’s agile context? The answer is plain and simply no. Why? Because factory design testing (most Traditional Quality Assurance mindsets that focus on requirements, test cases, design error counts, etc.) is too slow, has too much overhead and our clients lose money and time. The focus of factory design testing in Race is mostly placed in process and design documentation.

Under the above context, our team members with the role of design checkers or testers focus on:

  • Their skills as a tester which revolves around learning about the transportation system under test as fast and as efficiently as they can.
  • Curiosity.
  • The ability to communicate effectively.

Effective design testing starts by understanding risks brought about by any change that's introduced to our product (design).

In reference to continuous design deployment that we apply in Race, we ask what the design team’s primary objective is. Is it to produce designs? Or produce designs that are constructible? If it's the latter, then yes. We need to test and we do test our designs by all means.

We are what we repeatedly do. Excellence then is not an action but a habit.

Aristotle.

Race has a certification under the standard ISO 9001:2008 (Reg. No. 01 100 124393) from TÜV Rheinland® and is currently under assessment with the PMI OPM3® framework and the standard ISO 14001:2015.

Tags: quality