Success Assured®
Do your RFP/RFQ Responses both 'wow' your customers and avoid over-committing?
Do you often win deals, but set yourself up for failure or unprofitable situations?
ABOUT THE SITUATION
Critical Trade-Offs to be Made, but Plagued with Uncertainty
Some of the most difficult and most critical decisions made in any engineer-to-order company are made in the RFP/RFQ Process. If you don’t push the limits or innovate enough, then you won’t win the business; but if you push too far, you can end up losing money on the deal… or create tremendous headaches for the team that must deliver on it.
At the same time, there is no decision process more plagued with uncertainties: uncertainty in what is being requested, uncertainty in what competitors will be bidding, uncertainty in what capabilities you have to deliver, uncertainties in your supply base, and so on. You typically need to engage experts from many different domains, each with their own uncertainties, their own rules of thumb, their own innovative (but unproven) ideas… and somehow you want to create some level of consensus on the right decisions of what to propose to the customer.
So, although we only invest 8% in the early conceptual development phases, 75% of the lifecycle costs are actually fully committed by the decisions made in those phases. 85% before you start the detailed development work.
In other words, if you want to reduce rework and optimize overall lifecycle costs, you need to change how you make decisions very early in the project.
To better understand the type of modeling needed to optimize the multi-dimensional trade-offs in the face of uncertainty, we need to look closer at the uncertainty faced by RFP/RFQ Response efforts...
Similarly, INCOSE's Systems Engineering Handbook makes the point with the following chart. The bars show how much of the lifecycle costs are spent by the end of each phase. The gray shaded area shows how much of those lifecycle costs are actually committed by decisions made in that phase.
So, although we only invest 8% in the early conceptual development phases, 75% of the lifecycle costs are actually fully committed by the decisions made in those phases. 85% before you start the detailed development work.
In other words, if you want to reduce rework and optimize overall lifecycle costs, you need to optimize how you make decisions very early in the project... and that will involve those "off-core" activities that are informing that decision-making.
This chart is adapted from INCOSE's Systems Engineering Handbook. In the middle, it shows how the Cost to Extract Defects rises exponentially as you get later in the development process (due to the ever-increasing ripple effects of rework). The bars show how much of the lifecycle costs are spent by the end of each phase. The gray shaded area is the most interesting: it shows how much of those lifecycle costs are actually committed by decisions made in that phase.
A Related Story...
The following is an excerpt from Part 2 of our new book Success is Assured. It is the first of a few fictional pre-RFP meetings between the US Navy, a UAV supplier, a jet engine supplier, and an IR technology provider.
[Commander Nathan Harris opened the meeting,] "As you know, we called this meeting because we are very interested in using the new Hawkeye IR tracking device that you developed under a DARPA contract. We want to use it for various situations: tracking enemy targets in battle situations, tracking targets for search and rescue missions, and tracking targets for intelligence gathering. However, to cover different-sized target areas for different periods of time, we need to understand how many devices we will need and therefore how many unmanned aircraft we need."
[Commander Laura Ramirez] added in the real driver for why they had bothered to come and visit IRT: "Our understanding from DARPA is that you guys have a scalable solution and that you have a sophisticated model of how the solution will perform in different scenarios. We want to make sure we understand that, such that we can optimize the specs to fit our mission needs."
[IRT's business lead] David, thrilled to hear that their intent was precisely what he wanted it to be, replied, "Yes, we have developed an extensive causal trade-off map on how it performs, allowing us to quickly make the design decisions required to meet different sets of customer interests."
"Great." Nathan then handed the lead to Mark: "So, Mark, you have the questions..."
"Yes. First, how large an area can one device cover?"
As IRT's technical lead, Joe replied, "That depends on a lot of things. First, how small a target do you need us to detect and from what distance?"
"Well, that was going to be my next question: what is the smallest target you can track from 40,000 ft versus 60,000 ft versus 80,000 ft?"
Joe tried to clarify that there's not a single answer: "We can detect most any reasonably sized target of adequately different temperature from any range, given a big enough receiver and enough power. How big is the aircraft? How big of a diameter receiver can we put on it?
Mark chuckled, "Yeah, that was going to be my next question for you: how big and heavy are your devices? We need to know that to size the aircraft."
Nathan chimed in, "And the size of the aircraft is going to dictate how high we need to fly in order to avoid detection by the enemy radar."
With a bit of a sigh and an odd look over at Laura, Mark added, "That's just one of the circular dependencies that makes it very difficult to figure out what we need to be putting in an RFP for the aircraft companies."
Laura, sounding a bit annoyed or disappointed, interjected, "We were hoping you could help us break out of that."
ABOUT MANAGING UNCERTAINTY
Establishing Certainty Despite Uncertainty
The typical Request for Proposal or Quote contains a lot of information on requirements, of course. However, the customer has a lot more expertise on what they want than on what's really possible. After all, that's why they are coming to you: you are the expert on what's possible to build. Given that, they will invariably be asking for at least a little more than what's possible – not because they want an infeasible spec (they want it to be feasible), but simply because they don't know where the boundary is and they want to get as much as they can get.
So, given infeasible requirements, your RFP/RFQ Response effort will need to decide what Trade-Offs that the customer would find most desirable. But first you need visibility to what those Trade-Offs are; and you need to create that visibility with very little time and essentially no budget (the customer is not funding this yet).
So, the RFP/RFQ Response team is almost surely faced with significant knowledge gaps in:
-
the requirements to be Targeted
-
the Ideas on approaches to achieve those Targets
-
the Capability Limits that will have to be respected
-
the multi-dimensional Trade-Offs that will have to be made
-
what Trade-Offs the customer would prefer, given the sensitivities
On the business side of the RFP/RFQ Response team, the business may be willing to take more or less risk, or accept more or less profit, depending upon the strategic importance of winning that contract. And that strategic importance may depend upon others of the design decisions, which represent additional knowledge gaps in the Targets and Trade-Offs.
On the customer side, there may be opportunity to have a rich dialog with the customer, influencing their thinking, shaping the demand. That extra dimension of flexibility in the selling process represents additional knowledge gaps in the Targets and Trade-Offs (what can we sell them).
On the other hand, if it is a government customer, then there may be strict rules on what can be asked and when, representing significant constraints on the closing of knowledge gaps. Or the forcing of the RFP/RFQ team to start their efforts before they even have the RFP/RFQ to look at, and then evolve their analyses as they learn more, and then evolve more when they finally get the RFP/RFQ.
Depending upon the situation, the RFP/RFQ Response team may face a number of additional sources of critical knowledge gaps:
David, wanting to make sure the typical circularities didn't abort the discussion prematurely, interjected, "Well, I am confident we can help you work through the circular dependencies. However, we may not have all the knowledge needed; we may need to pull in some experts in other areas."
Joe added in his calming analytical voice, "Agreed. But first we need to get clarity on what you are trying to accomplish and what we know and don't know."
Joe was looking at [his assistant] Alex as he said that last phrase, giving Alex the confidence to make his standard entry into such technical discussions. "I've been taking notes in the form of a Causal Map; perhaps it will help." He pressed a couple buttons on the touchscreen mounted on the end of the high-tech conference table and his Causal Map appeared on the two screens at the front of the room. "The shapes marked with a red target are the things you asked for; the rest are the things Joe asked you in order to answer those questions. Do I have this right so far?"
All eyes perused the Map on the screen.
Alex [...] continued, "The Map represented by this cloud shape covers all the circular dependencies in our part of the system; what we want to do here is capture those circular dependencies in that larger system that you are trying to work out, so that we can help you work through those."
Mark gave Laura a skeptical look that Alex was all too familiar with – a look that said, "This young kid has no idea how complicated our stuff is. This is never going to work." Laura's return look also seemed skeptical but possibly more open to seeing where this might go.
Nathan did not see either look as he was hyper-focused on the Map. "Why isn't 'Altitude Cruise' marked with a red target? We normally spec that, so wouldn't it be a customer interest?"
Alex explained his logic: "It sounded like the reason you cared about Altitude was the Detectability of the aircraft; if we can reduce that by shrinking the aircraft, then a lower altitude would be fine."
"True... but Altitude affects other things, such as the range/endurance of the aircraft."
As Nathan said that, Alex added in an additional circle for "Range and Endurance of Aircraft". "Okay, then I'd mark those other things with the red target."
Nathan, starting to get a feel for the Causal Mapping, pointed out some other potential flaws...
ABOUT OUR SOLUTION
Set-Based Models are Key to Optimizing Multi-Dimensional Trade-Offs in the Face of Uncertainty
And that is not all...
Set-Based is widely accepted as an enabler for delaying decisions until you can establish the knowledge to make those decisions. However an RFP Response team doesn't have the luxury of delaying decisions.
So far more important in this case is that Set-Based is also a critical enabler for accelerating learning such that the knowledge is available prior to when the decisions need to be made. Done properly, Set-Based is a powerful enabler for minimizing workload while increasing concurrency, and thus accelerating learning:
-
Set-Based allows you to simplify the analyses to the worst-case, just proving that the worst case is adequate to establish that "Success is Assured".
-
Set-Based allows you to compute using the fuzzy ranges of values you might be limited to early in the process.
-
Set-Based makes visible the sensitivities and limits of the design space in a way that is easily shared across areas of expertise.
-
Set-Based enables different teams to work concurrently even when they are dependent on the other team's decisions; as they converge, they notify the other team who then can use a smaller range of values.
-
Set-Based allows you to determine and leverage the sensitivities even before you are able to work out the precise levels.
-
The earlier visibility to sensitivities allows the team to focus on the most critical decisions, and thus focus their learning where it is most needed early.
-
That early visibility also enables "eliminating the weak", which is a much more efficient decision-making and optimization process than the typical attempts to "pick the best", particularly in the face of uncertainty.
Those set-based models need to support teams of experts from different domains of expertise, both in the model construction and in model usage for optimized decision-making. In doing so, it is critical that the engineers have the ability to navigate the complexities and view the multi-dimensional space from their own perspective.
To support that, behind every Trade-Off Chart or Solver is a Decision Map that serves as a visual guide through set-based knowledge. The Decision Map is intentionally kept very simple such that experts from all disciplines can understand it without training. There are just two shapes to learn: circles represent Decisions to be made; rectangles represent known Relations between those Decisions.
That Map allows the experts to quickly see what might be missing or mis-represented from their own discipline, while at the same time understanding how their decisions impact others' decisions, and vice-versa. The Map can even make visible "unknown unknowns" where you need to seek out expertise that has not been involved up to now.
Even when you are unable to get feedback from the customer on where they want to be on the trade-off curves, being able to clearly present to them the those trade-off charts showing what's possible and what's not can be a huge advantage in the sales process. Given one supplier showing you the knowledge on which a chart is based that shows you what is truly feasible and another supplier that just gives you a quote but little evidence that they know they can actually achieve that, which supplier would you choose?
Further, note that these visual set-based models tend to be highly reusable. Not only for future use, but for the ongoing evolution of the RFP/RFQ Response as the customer changes the RFP and as technology changes. More on that reusability in the next section...
To enable the required multi-dimensional trade-off decision-making, you want the team to be able to see the full sets of what is possible, and the sensitivities of those sets to the decisions that they are making. That is precisely what the set-based models and tools in our Success Assured® software are designed to support.
And fortunately, those same set-based computations that enable that also enable the handling of uncertainty. Rather than prove a single design performs well in a particular situation, you can compute how a set of infinite products would perform in a range of situations. You can then eliminate the designs that could perform less than the minimum your customer is willing to accept. That gives you the subset of the design space where "Success is Assured", despite the uncertainties.
In the same way, that Map allows you to bring in experts on the customer and the operating environment for the product, and make sure that all of the uncertainties are fully captured in the Map, such that you know the resulting set-based computations are covering all the uncertainty.
Further, the Map in our Success Assured® software provides a visual way to configure Charts and Solvers to show the sensitivities in the design space the way you want to see them, at first to further validate the models, and later to help optimize decisions.
Finally, K-Briefs allow the team to use the collection of visual models to tell the learning and decision-making story that they need to be able to tell clearly to each new expert brought into the discussions.
That includes the customer, the expert on what Trade-Offs they would prefer to make. Given complex multi-dimensional trade-offs, it is virtually impossible for them to fully explain their trade-off preferences in advance. They need you to show them the sensitivities and the levels of those trade-offs; only then can they use their expertise to guide you on where they want to be on those trade-off curves.
Fast-Forwarding...
They continued in that same way, identifying what was missing, adding it into the Map, until they identified that there were things they knew were connected, but didn't know exactly how... so, they needed to pull in experts in other areas. At first from an aircraft supplier. Then from a jet engine supplier. Eventually they closed enough of the knowledge gaps to allow them to generate some useful charts. We pick up the story again with Alex explaining the Charts he has generated...
Alex opened, "So, I added [in yellow in the Map shown in the explanation to the left here] the two ratios we discussed yesterday: 'Footprint per Area Tracked' and 'Cost per Area Tracked'. And since those seemed to be the key customer interests that Laura wanted to trade-off, I put those two on the X- and Y-axes of this Chart. But of course, those will trade-off with numerous other things in this multi-dimensional design space. Since we have a major knowledge gap around Radar Signal Level and Survivability and all, I decided to put 'Altitude' on the third axis – on the contour lines shown in the Legend here."
Laura's furrowed brow had returned. "So, what is this telling me is the best design?"
Alex answered, "The white area is the feasible design space if you want 'Altitude' to be 80,000 ft. There are an infinite number of design points in that white design space that all work. The feasible design space at 65,000 ft is anything not shaded out by green, and at 50,000 ft, anything not shaded out by purple. What's best depends on what trade-off you prefer to make between Footprint and Cost. Note that the lowest Footprint is not the lowest Cost, but is pretty close."
Mark further observed, "So, if we want to fly at a higher altitude for better survivability, then we will need a larger footprint and more cost to track the same area. That makes sense. And as we go higher, it appears that impact is increasing non-linearly, since the boundaries are spaced further apart the higher we go. Am I reading that right?"
Alex responded, "Exactly. But that is just one of the other dimensions – one of the other key trade-offs. In this chart I am showing the case for 300 ft 'Takeoff Distance', 2100 nautical mile 'Range to Target', Mach 0.7 cruise speed, and 6 kelvin 'Delta Temperature'. I have similar charts for different values of each of those so that you can start to get a feel for the impact of each of those decisions on both the Cost and Footprint Ratios. For example, if we look at 'Takeoff Distance' at 200, 300, and 400 ft, we get these three charts."
The story in our book continues to work through the multi-dimensional trade space that was computed from the Map shown above left, where the upper two clouds represent the aircraft sub-Map below.
Although that Map surely looks daunting to somebody seeing it for the first time, for the RFP Response team (and the readers of our book) who built it up step-by-step, that Map allowed them to sort through all the complexity of a multi-stage mission for an unmanned jet aircraft carrying specialized surveillance equipment in a very short time, pre-RFP.
Leaning toward the screen, Laura interpreted what she was seeing: "Okay, so going from 300 to 400 ft 'Takeoff Distance' reduces Footprint Ratio and Cost Ratio, but only a little bit – probably not enough to justify needing assisted takeoffs. But reducing it to 200 ft to give us some extra padding increases the ratios a lot – and more so for the higher altitudes. So, if 50,000 ft is okay, then that might be a good trade-off. But if we want to be at 80,000 ft, then that is not a good trade-off! Am I reading that right?"
Alex responded, "Exactly. So, there's a non-linearity with 'Takeoff Distance'; and that non-linearity gets worse non-linearly with 'Altitude'."
Three Layers of Reusable Knowledge
Note that the reusability of your set-based models and the knowledge on which they were based is not just for the benefit of future RFP Responses. This RFP/RFQ Response effort will need to be able to reuse and continuously improve that knowledge as more is learned or more uncertainty is removed, leveraging that more specific knowledge as it becomes available. The K-Briefs (the top level of reusable knowledge) tell the learning decision-making story thus far; within those K-Briefs, the trade-off charts and solvers capture the cause & effect reasoning for the decisions; and the underlying Decisions and Relations capture the knowledge that enable all of that in a reusable way.
Decision Maps
A Decision Map is a collection of related Decisions and Relations that together connect the decisions you can directly control to the customer interests you want to satisfy. The Relations capture the knowledge from the different disciplines that is needed to establish that "Success is Assured" prior to decision-making.
Charts & Solvers
The Charts and Solvers capture how best to see the sensitivities and limits of the design space and how best to optimize your competing decisions within that design space to best satisfy your customers (all the stakeholders). From any Chart or Solver, you're always just one click away from the underlying Decision Map that it was computed from.
K-Briefs
The Project, Problem, and similar K-Briefs tell the story of how the Charts and Solvers are being used to make the required decisions, based on the underlying knowledge. That may include identification of gaps in that knowledge that should be closed prior to further converging those decisions.
Success Assured®
Contact Us to Schedule a Demo today!
Do you have a spreadsheet used on a past RFP/RFQ Response? If so, send it to us and we'll even demo using your own data!
Confidently make decisions you won't need to change...
Contact Us
If you have questions, would like a demo, or would like to schedule us to visit you, please email us at Answers@TargetedConvergence.Com. Alternatively, you may call us at 1-888-LRN-FRST (1-888-576-3778). Either way, we'll route you to the right person.
Or if you prefer, you can send email direct to:
-
Our Sales Team at Sales@TargetedConvergence.Com.
-
Our On-the-Job Coaching Team at Mentors@TargetedConvergence.Com.
-
Our Software Support Team at Support@TargetedConvergence.Com.
-
Our Website Team at Webmaster@TargetedConvergence.Com.
-
Our Accounting Team at Accounting@TargetedConvergence.Com.
-
Our Human Resources Team at HR@TargetedConvergence.Com.
After 10 years in Carrollton, we have moved a few miles south to the prestigious Las Colinas region of Irving, TX:
Targeted Convergence Corporation
320 Decker Dr #254-03
Irving, TX 75062-3999
You can visit (and Like! or Follow) us at our official pages on LinkedIn and Google Maps.
Want to dig deeper on the impacts of set-based analyses and the other enablers of establishing "Success is Assured" on the RFP/RFQ Response process? If so, Part 1 of our new book Success is Assured fully details those enablers and the impact on product development processes. Click here to watch a short 2-minute video about the book.
Want to see the full details of the pre-RFP example discussed above?
No problem -- Part 2 of Success is Assured walks step-by-step through that collaboration between the US Navy, an unmanned aircraft supplier, a jet engine supplier, and an IR detector supplier, using our software to build maps and charts.
To Learn More...
