Understanding Risks in Real Time

Creating and using Multivariable Process Maps as a tool for deep awareness of your startup’s well being
(Post 6)

Understanding the risks: The Knowns and Unknowns

The name of this blog is Full Arc, which is English translation of my company’s name, Arc Completa.  I truly believe those who are endeavoring to create value through a startup enterprise need to understand and not underestimate the risks and the pitfalls, particularly as the risks combine and compound over time and through each phase of the product life cycle. It is necessary to maintain this deep awareness from the very inception of an idea to volume production shipments, that is, for a product’s full arc.

This blog and these methods don’t describe a canned solution for success, as some other business systems may claim.  What it will give you is the best prescription lenses to assess your performance objectively, with a high gain “Spidey Sense” antenna to predict and model risk.

I’ve also learned that I achieve the highest level of awareness when I’m able to admit I don’t know the solution to a particular problem.  It doesn’t mean that I’ve given up; it means that I know that I’m trained and objective enough to determine and eliminate what’s not causing the problem (the Knowns).  This allows me to stay focused on as-yet-undetermined roadblocks (the Unknowns).

In Post 3, I stated: “A hard-tech entrepreneur needs to be comfortable with the knowns and unknowns.  Once something (parameter, process, material recipe) is better understood and is heading toward a Known, control it and make sure it can be realized repeatably and sustainably, and at a sufficient level of control to ensure it does bother you again.  If the parameter keeps sliding back into instability, or has a disproportionate impact on performance, it might be a CTF.  These need special attention.”

But how does one understand and capture the knowns?  Furthermore, how does one start to identify possible candidate CTF (Critical to Function) parameters?  The answer is you create Multivariable Process Maps for major design elements and sub-elements.

Capture the process early in the process

This is where the informed reader may pile on, so hold on (…assuming someone out there is interested enough).  Arc Completa’s theory is that Multivariable Process Maps, established very early in the product development cycle, should capture the realization process that achieved the most stable desired outcome and performance of the product.  This means THERE WILL BE MANY unknowns. And that’s OK.  I acknowledge that there is disagreement about creating a formal Process Map so early in the process, but our experience bears this out. Capturing the knowns will aways emphasize the unknowns, and the variability and uncertainty can be addressed in a structured manner.

This is the basic idea:

Create Process Maps using major process steps

  • Process steps are the natural break point in creating something.

  • These major steps often require set-up, preparation, execution, waiting for something to happen, and then measuring the result.

  • Early process maps always have a lot of hair on them, and need to be curated and refined by a committed leader and a team.

  • But really, where else should you start? This is the process that created what you think has value.

Process Maps

  • These types of Multivariable Process Maps are developed to capture basic information about product: what it is, how it’s built in the originator’s imagination, how they got to the result.

  • The method uses the originator’s brain’s “process flow” as a guide, to describe how a design was built and what exactly went into the effort.

  • In these early stages, these process maps become the Fundamental Backbone for storing information until it can be formalized and controlled (more on this later).

  • Process mapping of any type is typically associated with manufacturing, and if executed, these process maps become the engine for more advanced modeling methods, which you get for free (more on this later).

  • The established Process Workflow, as the reference during product, process and test development, and the product and process are refined, often providing momentum toward achieving your goal, while avoiding rehashing less productive, previously eliminated outcomes.

  • As you achieve success and pass phase stage gates in a Product Life Cycle, Process Maps become accounting and storage tools to safeguard information until it can be transferred to an appropriate document, specification, ERP (Enterprise Resource Planning) System and or PDM (Product Data Management) System.

  • Critical to Function (CTF) Parameters and Interdependencies start popping up.  Because these are the pain points everyone talks about in the lab, the ones people stay up late thinking about, they are already consuming resources from different directions, and might be the factors people are fearful to mention, because it will chill everyone’s startup revery excitement?.

  • Once established, your set of Process Maps become a reference that is regularly updated to reflect most current assumptions from product, test, and process development.

  • And lastly, if the product development, operations, and supply chain teams do their jobs, all the content will migrate to appropriate tools and applications, rendering the process maps obsolete until the next generation (more on that later).

A Sample Process Map

So, what does a Process Map look like? It’s a spreadsheet. Yup, a good old Microsoft Excel spreadsheet. Why Excel? Because I’ve found it to be ubiquitously available, understood in technical communities, and powerful.

What’s in the spreadsheets?

The basic data types collected in a Multivariable Process Map

In the next chapter I’m going to share the definitions and examples for each section.  Future posts will cover the methods and processes associated with running a workshop to harvest the information without getting discouraged.  Also, we’ll cover some ideas on how to use and prioritize what you’ve learned.

This is where I’m going to have to ask you to trust me.  I’ve been wrong and have made mistakes in my technical and commercial endeavors.  I try my best to own them and get ahead of them, constantly finding new tools and methods to help my clients.  But in my career as a technical and operations leader, variations of these basic process maps were the secret to my success.  They allowed me to see potential when others lost hope.  They allowed me to master complex technologies and systems and communicate highly technical topics is terms of dollars and risk to boards and investors.  They allow companies I’ve managed to grow quickly and increase profitability, faster than competitors.  They allow me to solve problems faster because I always know the baseline performance.  But mostly, they memorialize critical information that all stakeholders at startups need access to in order to succeed and become profitable.  I’ve used them at greenfield startups and Fortune 500 companies.  The basic concepts were taught to me by one of my most gifted mentors 35 years ago and I’ve been improving them since. 

These process maps will be your guide and framework to decide where resources will be applied, what is working and what is not, and what costs too much or uses too many resources.  But mostly, they function as an objective scorecard for your success.  These are the foundation for multivariable modelling methods.  Inherent in modelling is capturing the present state, and then testing scenarios for the future desired outcomes.  Having an accurate awareness of the present and a solid foundation to model the future is the power, and the visibility that will set you apart as a startup enterprise from other startups.  You will use quantitative models that inform decision making and communications, backed up by the most current and up to date data, experiences, and outcomes, to drive your company to the shortest Time to Profit.  And that is just the beginning.