If decisions create requirements (as explained in my previous post), then decisions also create ALL the interactions between requirements.  This implies that there is never a constant, always-present, solution-independent relationship between any 2 requirements. 

Perhaps you’ve been involved in populating or using a House of Quality as part of a Quality Function Deployment (QFD) initiative.  The House of Quality diagram has 2 parts that represent requirement-to-requirement interactions, a relationship matrix and a correlation matrix.  In each, a set of symbols is used to represent the strength and nature of the relationship (positive or negative correlation).   Many QFD practitioners assume that these relationships are constant and unchanging, but this is only true when you “freeze” the technology and platform decisions behind the House of Quality. 

A relationship between a stakeholder need and a product characteristic (a user requirement and a system requirement) or 2 product characteristics is always solution/technology dependent.  If you make any significant changes to your technology platform or solution architecture, you blow up the House of Quality.  That’s why QFD is a very powerful method for making continuous, incremental improvements on a stable product platform, but not for inventing a disruptive alternative.

I use an outlandish example to teach this principle by asking:

• “What is the relationship between the learning effectiveness of this workshop (a stakeholder need/goal for the training) and the average body mass of the students?”
• “What is the correlation between student weight and classroom illumination?”

Most folks are politically correct enough to say “none”, not wanting to be accused of promoting a “fat people are stupid” stereotype.  I say there’s a very strong positive relationship and correlation because I’ve made a “Choose Classroom Lighting Technology” decision.  Instead of the ho-hum alternative (fluourescent lamps), I’ve committed to a “Let’s light the least-performing student on fire every N hours” solution.  This seemingly tangential decision ties together requirements (parameters/attributes) that would normally be completely independent.

Some would argue that science as represented by unchanging equations makes universal, solution-independent relationships between requirements.  Take Newton’s second law of motion as represented by F = ma (force = mass x acceleration).  This seems to say that a user need (acceleration) would have a strong negative relationship with a product characteristic (mass).  However, even Newton’s laws have a range of validity; they work within and across a specific (in this case, very wide) operating regime.  These laws break down (have to be amended) for nanoscale particles to account for quantum effects and near the speed of light to account for relativity.  “Choose Operating Regime” is an important decision for any product; it determines which science (equations) apply to your product and therefore which requirements are related.

Whenever you make a design decision, you may create unexpected relationships (cross-constraints) between requirements.  If you maintain a decision-to-requirements trace, you are more likely to catch these cross-constraints and factor them into your downstream decisions.  If you use the more common requirements-to-requirements traceability model, you are more likely to overlook these interactions and pay a price when future decisions fail to account for unexpected constraints.

Every requirement that you will ever face can be traced to an upstream decision; all requirements are derived requirements.  I used to offer students in my Decision Driven® Design workshops a large cash prize if they could name a requirement that I couldn’t trace to such a decision; I’ve never had to pay up on that challenge.  Pull out a requirements specification and do a thought experiment; you’ll quickly see why.  Ask yourself which upstream decision(s) would have to change (i.e. by committing to a different alternative) for this requirement to be invalidated, weakened or made more demanding.   You will always be able to find at least one decision that would blow up each requirement.  If you get stuck on an example, send it my way and I’ll be glad to help. 

Requirements are the inherent consequences that flow from the definition of an alternative that has been selected for implementation.  As soon as the alternative is chosen as the committed solution, its inherent consequences become constraints that could affect (topple over, invalidate) all other decisions in the project.  New requirements are created at the point of decision - at the instant you commit to the alternative.

As I’ve discussed before, the standard V-model of product development leaves the impression that requirements create requirements.  This leads nearly everyone to maintain requirement-to-requirement traceability, when a decision-to-requirement traceability model better represents the true derivation process.  The last time I reviewed the CMMI framework, it reinforced this flawed traceability paradigm.  I’m amazed that there hasn’t been a revolt among systems engineers, given the effort required to maintain this incomplete form of traceability.

If you maintain requirement-to-decision-to-requirement traceability (i.e. capture the decision transform that links any set or pair of requirements) you have the ability to do a comprehensive impact analysis.  You can walk the dependencies and see the ripple effect from changing any object (alternative or requirement).  If you fail to capture the “decision in the middle”, a change requires recreating the derivation process from memory.  This quickly becomes impractical when designing a complex product or system.

The traceability diagram below shows how a “decision in the middle” creates and transforms requirements.  “Upstream” requirements constrain a decision (when translated into evaluation criteria).  Alternatives have inherent consequences, including derived requirements that should be added to the requirements baseline.  Multiply this diagram across all the decisions associated with a product or project and you have a complete view of the requirements derivation process.

Decision-Requirements Trace

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Based on feedback from clients, I’m in the process of defining an intranet option for Decision Driven® Strategy.   This option will enable you to deploy the power of the Decision Driven® Strategy web application for strategic decisions and roadmaps inside your company’s firewall. 

The intranet site option will be based on a “bring-your-own web server and database” model, but will include the capability to seed your database with our proven strategy decision pattern.  You’ll have the option to create multiple internal user groups that point to variants of the decision pattern that you can adapt to different parts of your business.

If you’re interested the Decision Driven® Strategy intranet site license option, please contact me at fitch@decisiondriven.com.  I’d love to hear more about your web server and database preferences so that I can create the appropriate implementation bundles.

John Fitch

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

The second Using Decision Patterns webinar is planned for Thursday, October 16, 2008 from 10 AM - noon USA Eastern (GMT - 5:00).  I picked the AM time so that folks from Europe could participate over a VoIP connection near the end of their working day.

During the Using Decision Patterns webinar, I will shine the light on various parts of the strategy decision pattern, highlight a specific application (decision baselines, competitive analysis, systems engineering, innovation, roadmapping, kaizen, etc.) and demo how to support this application with the tools.

If you’re interested, send an email to strategy@decisiondriven.com with your contact information (name, organization, preferred email address) and a brief description of your area of interest.  I’ll use that information to tailor the sessions to the audience.  You’ll receive an email invitation to a GoToMeeting session which will give you 2 audio options (a not-toll-free conference call number or Voice-over-IP).

I look forward to enriching your ability to use decision patterns!

John Fitch

There’s no quick fix for accelerating the development of a new product.  That’s because your organization has a baseline (existing, current) capability for product development that is comprised of a mix of existing solutions, people, process/methods, tools and knowledge assets.  If you haven’t been investing in your new product development (NPD) capability roadmap then there is no magic accelerator pedal to mash on when you want to speed up a specific project.

Which NPD capability investments can yield the greatest payoff in reducing time to market? 

Capability #1: Control requirements volatility with decision baselines

Nail down the product’s requirements baseline. The fastest and best way to stabilize requirements is to understand the upstream customer and business decisions that created these requirements (all requirements are derived requirements!).  If you have a set of proven decision patterns, you can quickly reverse engineer these decisions and build an explicit decision-to-requirements trace.  You can use this trace to confirm the requirements derivation with the customer, identify fuzzy or open decisions that could lead to requirements volatility and work through these decisions with your customer early in the project.  This can dramatically reduce the flow and severity of requirements changes and save much time by preventing engineering rework.  See my August 25, 2008 post for more on this capability.  

Capability #2: Platform engineering

You most likely have a portfolio of existing products and solutions that can deliver 20, 50 or 80% of the functionality required for a new product that you have in mind.  Your teams may do a pretty good job of incidental reuse of hardware and software components, documents or models based on a “been there, done that” approach.  However, that’s a far cry from the speed you can gain from architecting a highly configurable, scalable platform comprised of designed-for-reuse assets.  A well-designed platform doesn’t just document the structure, behavior, requirements, interfaces and configuration options associated with each asset; it also documents the decision rationale behind the platform design.  This allows a product team to quickly revisit the decisions behind the platform, confirm that their product concept fits within its scalability limits and identify the specific functions that are beyond the scope or performance reach of the platform.  This focuses the team on the “vital few” open decisions that must be made on the project, typically “Choose Technology for Function X” decisions.  See my June 11, 2008 post for more on this capability.

Capability #3: Never make a decision from scratch

Decision patterns are the key to both capabilities describe above.  These same decision patterns can be used to enable massively-parallel, aligned and efficient thinking when forward engineering the product.  Team members save time when their decisions are visible and consistently well-framed as “fundamental questions/issues that demand an answer/solution”.  A decision pattern includes the typical criteria that should be considered for each type of decision; this saves time in defining and prioritizing the attributes of a successful solution and reduces the chance of missing or redundant factors that skew that decision analysis.  The criteria create a knowledge pull that highlights important unknowns that need to be known before a decision can be made with confidence.  Team members gain learning cycles by using the same decision-making process across multiple decisions; they become faster, more innovative and confident thinkers.  Higher quality decisions reduce downstream rework.

I created the Decision Driven® Strategy web service to bring the power of decision patterns to new product development.  If this sound intriguing, give me a holler.

John Fitch

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

Yesterday I had the opportunity to talk to the Entrepreneurship class at Rose-Hulman Institute of Technology, my alma mater.  I split my talk between “Using Decisions Patterns to Accelerate Your Business” (which I’ve touched on often in this blog) and more personal tips based on my journey as an entrepreneur.  My thanks to Dr. Tom Mason for giving me the chance and for an engaging conversation about what’s happening in engineering and entrepreneurship education. 

Given that I’m a bit road-weary from the round trip (~ 8 hours), I thought I’d cheat and fill my blog with some of the tips I shared with the students.

Differentiation Strategy - Value Proposition

• Whatever your business idea, you really need a secret sauce that can separate you from direct and indirect competitors.  It’s easy to get enamored with your new idea and think it to be more unique than it will be seen in the eyes of your customer.  Get some part of your product out into users hands early and often to confirm that you really have the basis for differentiation and a unique value proposition.

Passion for your product

• Launching a new business will inevitably lead to some very long and dark days in the process.  You need a genuine passion for your product to carry you through and to motivate your team in the tough times.

Plan your exit strategy from Day 1

• It’s hard to think about abandoning “your baby” when it’s fresh and new.  Even if you do have a plan on how you will leave your business, it’s easy to miss the off-ramps.  They seldom occur according to your plan and may come well-disguised in some other form.  Be on the lookout.

Wear many hats, but know your limits

• Every business has at least 3 high-level roles: Create - Implement - Operate.  These roles demand different thinking patterns and very often different people.  The entrepreneur may have to fill all 3 roles at various times, but few people are wired to excel at them all.  Don’t be ashamed to get some help.

Time to capability is everything

• Commit yourself to a life of continuous learning and innovation.  Every time you do something new, allocate 5% of your time and brainpower to think about the process you are using and to harvest patterns or lessons learned that you and other can use in the future.  There’s a compound interest effect from continuous learning, so don’t wait until your product is perfect - get it out there quickly in basic form and get early, frequent learning cycles.

Humility

• Entrepreneurs need to learn how to fail well; transform their inevitable failures into learning and growing opportunities.  They also need the humility to be willing to do whatever it takes for their business to succeed - stretch themselves and work way beyond their comfort zone.

It’s hard to make a business off of early adopters

• Even though you want a highly-differentiated product, if you are too far out on the bleeding edge you may overshoot or outrun the market.  You really don’t control the formation of markets - they evolve at their own pace that you can influence very little.  So if your product depends on a few early adopters for survival, you’re in for some tough early years.

Network, Network, Network

• Knowledge grows as you (use + share + link) it.  The value of your business is driven by relationships, so don’t let the do-it-yourself mindset that makes you an entrepreneur prevent you from continuously networking with potential partners, customers, suppliers, industry groups, etc.  You really don’t know in advance when a new relationship may open an important new door for your business. Get out of the lab!

Thanks again to the Rose guys and gals!

John Fitch

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

If you frequently generate business proposals in response to customer requests (e.g. RFPs, RFQs, RFIs), then you can benefit greatly from the use of decision patterns.  Every proposal proposes a solution to a customer’s problem (e.g. use cases, mission scenarios, requirements, needs … ).   The “essence” of this solution and the thinking behind it can be understood and communicated as a Decision Network.  This is true whether you are offering a complex “new-to-the-world” system, a hardware/software product, a set of one-time or ongoing services or any combination of these elements.

Here’s how I would exploit the proven solution design decision patterns within my Decision Driven® Strategy web service to produce better proposals:

• Create an initial solution baseline.  Blitz through the solution concept decision pattern and capture your initial “favorite” alternative as the answer to each of the top-level decisions.
• Identify 5-10 high priority decisions where your answer (favorite alternative) can be used to communicate the advantages of your approach.
• Quickly score your alternative against 2-3 other solutions.  If you understand your competitors’ favorite technologies and designs, include them in the scoring so you can indirectly expose the weakness of their approach (without naming names).
• Identify the 5-10 decisions where your answer needs some work; where it would be perceived as mediocre or deficient relative to potential competitors.
• Innovate 2-3 new alternatives for your weakest decisions, then evaluate these new solutions against your initial favorite and potential competitor alternatives (indirectly as technologies or design concepts).  Pick the best of the best as the basis for your proposal.
• Use the decision analysis results from these tasks to frame and populate the technical proposal.  If you can show your customer that your solution provides the best answer across the top 10-20 decisions with supporting rationale, you’ll have a very convincing and easy-to-follow story.

By focusing the proposal effort on your team’s thinking quality (not just writing and salesmanship), you will also jump-start your project execution and increase the likelihood of delivering on your value proposition.

You should also consider these more advanced uses of Decision Driven® Strategy and decision patterns:

• Reverse engineer the customer’s decision model implied by their RFP/RFQ/RFI.  Use this model to better understand their mission and the source of their most challenging requirements/constraints.  Consider whether you can propose a solution to a higher-level decision (problem), i.e. give them an innovative answer to what they need, not just what they asked for.
• Build a roadmap for each of your decisions to show how your solution design (your alternatives) could evolve through a series of releases.  Demonstrate that your solution is really a robust platform that anticipates and can grow and adapt to their changing needs and new technologies.

Proposals are a decision-making and decision-management fire drill.  Many decisions have to be made quickly and in parallel with limited time, resources and information.  Attack them with a proven decision pattern and scalable decision management toolset and you will improve your chance of creating a winning proposal.

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

It’s always helpful for your business to have a plan of record; a baseline plan that your entire organization can see and align their efforts against.  However, if you are pushing the envelope of new technologies, new products, new markets and new business models, the plan of record quickly becomes ancient history.

Business situations with high uncertainty and volatility demand a dynamic, agile strategy and planning capability.  You want your plan of record to include more than the execution plans for your decisions; it should capture the rationale behind your decisions so new information can be quickly assessed for its impact on the plan as a whole.  Some new data may overturn existing decisions and drive a switch to a new alternative (or one previously rejected); other data may be absorbed without toppling over any decisions within your strategic baseline.

If you have a set of proven decision patterns like those I provide in my Decision Driven® Strategy web service, you can quickly capture a decision baseline of your top 20-50 strategic decisions (fundamental questions/issues that demand an answer/solution), the alternatives you considered and your rationale behind the plan of record.  This information gives you a dynamic Thinking Breakdown Structure from which to quickly assess changes; a platform that supports strategic and operational agility.

Volatile and uncertain situations call for a greater emphasis on time to market and time to capability.  You can’t afford long projects that never deliver any useful capabilities.  A decision baseline can be used to support massively parallel and aligned thinking that can accelerate these ideas into reality so you have a robust set of solutions that you can employ quickly when conditions change.  Time to capability is everything!

John Fitch

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.

I currently see 500+ hits on this blog each week, with interest spread across as many as 100 topics each week.  Because comprehensive decision patterns such as those I deliver within Decision Driven® Strategy and Life are a new and disruptive technology (with many diverse applications), I’d like to provide my readers with the opportunity to go deeper and learn more.  To do this, I plan on offering a free 2-hour webinar at least once a month. 

During the Using Decision Patterns webinar, I will shine the light on various parts of the strategy decision pattern, highlight a specific application (decision baselines, competitive analysis, systems engineering, innovation, roadmapping, kaizen, etc.) and demo how to support this application with the tools.

Given the global nature of my readers, I know that there’s no ideal time for a webinar.  I plan on experimenting with various days and times and seeing the response.  The first Using Decision Patterns webinar is planned for Wednesday, October 1, 2008 from 7-9 PM USA Eastern Daylight Time (GMT - 5:00).

If you’re interested, send an email to strategy@decisiondriven.com with your contact information (name, organization, preferred email address) and a brief description of your area of interest.  I’ll use that information to tailor the sessions to the audience.  You’ll receive an email invitation to a GoToMeeting session which will give you 2 audio options (a not-toll-free conference call number or Voice-over-IP).

I look forward to enriching your ability to use decision patterns!

John Fitch

People don’t understand what engineers do.  Say “engineer” and a layperson thinks:

• Nerds
• Nerds with pocket protectors (I haven’t worn mine in years!)
• Nerds with pocket protectors and electrical tape holding their eyeglasses together (… decades!)

Sophisticated laypersons think “Dilbert!” while feigning their understanding of the humor.

My pastor has dropped a few hints that he thinks of engineers as head-down, straight-line, boxes-and-arrows, divide-and-conquer, by the numbers, by the book folks, about as far from the intuitive, creative, holistic, expressive class as you can get.

He’s wrong!  Engineering is a gnarly profession.  Great engineers wade through the amazingly complex interactions of the natural world, package this science into useful technologies, match these technologies to ill-defined and unruly problems and create a new layer of interactions to explore with every decision they make.  They keep track of the whole while they are inventing or wiring together the parts.  They do all this in the face of lots of uncertainty and “I need it now”, “It costs what?” and “I changed my mind” pressures, while patiently explaining their rationale to folks who gave up on math at fractions and long division. 

If you can read this, THANK AN ENGINEER!  Or one of those software geeks! 

Please sign up for our next Using Decision Patterns webinar.  It’s free!  See the What’s Happening panel on the left for details.