The previous blog post discussed the merits and impact of a “decision-first” approach, and why it might benefit your organization. This post will delve into how to implement the approach itself.
The overarching theme of this article is that at every turn, the project team should be guided by the following question:
Will the time or financial investment associated with this task lead to better decisions, ultimately improving the project goal metric?
Decision-First: A Simplified Manufacturing Example
Clearly, a decision-first approach is impactful. But what does it look like? Let’s use a simple example for illustration.
Suppose you work for a toy company that manufactures yo-yos, stuffed bears, and slinkies. Your company runs four factories in New York, California, Kentucky, and Minnesota.
The company aims to maximize its profit over the coming fiscal year. Its decisions that impact profit are as follows:
- How much to produce: The quantity for each product - e.g., 100 units of stuffed bears or even none at all
- When to produce quantities of various products over the course of the year - e.g., week 1,2,3
- Where to produce quantities of various products - i.e., which factories to produce from
Each product requires different resources in different amounts. Naturally, these resources have different costs. For example, slinkies require steel, whereas stuffed bears do not. Therefore, each unit of a product itself has a different cost.
This manufacturing problem is often referred to as the “product mix problem,” and can be solved using mathematical optimization.
A data-first approach might focus on first collecting, storing, and deriving various types of manufacturing data. In contrast, a decision-first workflow starts with identifying factors that affect production decisions and, ultimately, product profitability. For example:1
- Product demand, for each product, region, and timeframe. E.g., a demand of 2,000 stuffed bears in New York in June.
- Product prices, for each product. E.g., yo-yos will be sold for $5 each.
- Resource costs, for all resources, which could vary by source company. E.g., a unit cost per ton of steel could differ by suppliers, each having a maximum order size per month.
- Product shipping costs from each warehouse to each customer region.
- Product shipping times from each warehouse to each customer region.
- Warehouse production capacity: How much can each factory produce per day across the product portfolio and in what product combinations, such as 500 yo-yos and 300 slinkies?
- Warehouse storage capacity: How much space exists in each warehouse, which can be translated to numbers of units of various products that can be stored at the same time. Additionally, how much storage is remaining at any given time?
The company’s output metric is profit, which for our purposes is calculated as the following across all products and resources:
Profit = (Product Revenue) - (Resource Cost) - (Resource Shipping Cost) - (Product Shipping Cost) , where:
- Product revenue is the (sale price to customers) * (number of units) , totaled across all products, e.g., ($5 x 100,000) for yo-yos if the company is projected to sell 100,000 yo-yos at $5 each.
- Resource cost is the total company spend on all raw materials for manufacturing. For example, $1,000,000 on steel, $600,000 on textiles, and $750,000 on plastic.
- Resource shipping cost is the total cost to ship raw materials to all company factories. For example, the cost to ship the quantity of steel required to Kentucky.
- Product shipping cost is the cost to ship finished slinkies, stuffed bears, and yo-yos to customers as well as to company store locations.
Note that the output metric data must be accurate and reliable, to ensure we can measure the quality of our decisions.
Determine the Data You Need
We are now equipped to focus on the data needed for this initiative, namely information specifying the above factors. This information is referred to as “input data,” as it is the input to a decision model or process.
All of these elements require data collection and/or derivation, and some require forecasting/projection. For example, since we are planning for the future we must forecast future demand for each product. In contrast, shipping costs and times usually need no forecast, as they can be contractually agreed upon with transportation carriers.
If we had instead started by thinking about data related but not critical to our project, we might inadvertently brainstorm second-order data that we do not actually need. For example:
- The frequency at which warehouse machines for stuffed bears are non-functional and need repair.
- The cost of replacing machine parts, for all machine types.
- The frequency and timing of snowstorms in each warehouse location (New York, California, Kentucky, and Minnesota).
This data is certainly associated with manufacturing stuffed bears, yo-yos, and slinkies. But unless equipment outages and weather disruptions happen regularly, information about them will not help you increase the profitability of your company’s toy production. Hence, spending time and resources on data collection and forecasting related to equipment outages and weather disruptions will not yield meaningful dividends compared to the primary task at hand.
Chasing after unneeded data or unnecessarily refining data is unproductive for the following reasons:
- Unnecessary Staff Cost: Time is money. Time spent on unrelated tasks means extra costs to the company in salaries.
- Project Delay: Additional steps in a project mean the project will take longer. Every day a project is delayed is a day without that project’s ROI.
- Unnecessary Data Cost: Storing and processing data in databases typically costs money (such as credits with a database vendor). Working with data that does not advance the project goal incurs additional database costs.
Clearly, our goal should drive the data components that we need, not the other way around. Specifically, choosing a project based predominantly upon the data we currently have would severely limit the scope of our possible initiatives, and the impact they could have2.
Data Quality and Implementation
But when is the input data “ready for use?” There are multiple ways to answer this question, often focusing on data accuracy. But experience has shown me that an effective and efficient standard is: use the data without further processing if it contributes to making better decisions. Of course, data validation is important as well. Specifically, the data must sufficiently represent each model input, but not necessarily go too far.
Play out the actions we would take using the input data and our project’s decision-process: testing against the goal metrics before a large-scale rollout increases confidence in project success.
Exact methods to assess data readiness and ultimately, project readiness, are outside the scope of this blog post. But feel free to reach out to me if you would like help implementing this critical step of the decision-first approach for your team.
Comparing Data-First and Decision-First
At this point, we’ve explored the differences between data-first and decision-first approaches at a high level. Now let’s compare data-first and decision-first approaches by looking at them step-by-step.
Here is a diagram of a data-first approach:
In contrast, here is a diagram of a decision-first approach:
The core difference between the two is when your objectives, and decisions to reach them, are formulated. With decision-first, objectives are front and center from the outset. With data-first, they do not appear until much later on.
Go Decision-First Today
The decision-first approach outlined here keeps your team laser-focused on outcomes and how to deliver those outcomes. This way of thinking means that project plans almost write themselves, ensuring each milestone has purpose and value.
Is your team data-first or decision-first? If you would like to partner with me to implement a decision-first approach let me know.
Footnotes
Staffing costs and machine CapEx are ignored in this simplified version of the problem.↩︎
That said, there is a case for building out foundational data early on, which can be applied to multiple projects. This can be a viable strategy if your team knows what it will do with the data and why it is valuable.↩︎