Dependencies...

I’ve been scratching the surface of contingency planning lately and have been asked how an organization can better identify risks that might require contingencies. In many cases, and for many companies, the process of risk identification comes from ‘tribal knowledge’ and experience of senior managers. While these domain experts can provide valuable input, there are other tools that can enable anyone to help identify risks and potentially manage them. One of my favorites is dependency mapping or benefits dependency mapping.

Dependency mapping is used in project management, application development, system architecture, and many more disciplines. There are software packages to help with it, but even a simple whiteboard and post-it-notes can suffice to get started. The concept is simple: what is needed to perform a given step in a process, and where do those items come from?

If you are making widgets, what are the raw materials for them? Where do those materials come from? Once you have the starting map for your process, you can elaborate and add detail. How are the materials delivered? How much of each material is stored on-site? What is the lead-time for deliveries?

As you build the map, you will naturally identify risks. Suppose a sprocket is in short supply or has a long-lead-time; what can you do about it? What if the supply dries up? What if orders for widgets increase by 10%?

Each of these risks, once identified, can then be planned for, even if the plan is simply to accept the risk. As an additional benefit, you should have a well-documented process once the map is complete that can help with a wider range of business problems, such as training, process management, forecasting, and more.

Contingency plans can become business as usual.

In my last post, I mentioned that standard policies can help with contingency planning. Similarly, policies put in place during the COVID-19 (or any) crisis can create needs for additional contingency plans, and become the basis of revised internal policies.

With many states requiring non-essential personnel to work from home, companies that can have put tools in place to allow remote work. Those companies unable to work remotely, which is most of the non-technology-based sectors, have to reduce staff or take other actions. The re-hiring and re-starting of production or service, once the crisis winds down is going to create additional risks with the need for potential contingencies:

• Is the start-up process for production documented with appropriate maintenance, training, and safety checks in place, especially if there is a risk of new people starting up the process?

• How will supervisors ensure their areas of responsibility are operating safely and as required by the business?

• Will the supply process deliver expected volumes and quality of raw materials as production resumes, or will there be constraints on supply? How do you know?

• What will happen if the down-stream distribution is constrained? Will you throttle production or stockpile? If you stockpile, how much capacity is there and when would you throttle production?

As you can see, it is easy to start thinking of risks that will require additional contingency plans. As you develop plans for the risk you prioritize, you should then feed those plans back into your standard operating procedures to ensure you are that much more ready the next time a crisis hits.

What is your approach to contingency planning during or ahead of a crisis like COVID-19?

This crisis is emphasizing the need for business to have contingency plans ahead of time, otherwise, they can only react.  Companies that planned for and allowed remote-work prior to the COVID-19 crisis were able to quickly implement stay-at-home policies while others had to scramble.  These companies also likely had higher employee productivity and satisfaction with a more flexible office/location policy, to begin with.  Look at other 'standard' policies and see how they may be used in times of emergency as well, and you may find your contingency planning becomes a better way of doing business all of the time.

---

How do you think about goal-setting for yourself and your company?

Many people start with trying to make objectives and goals SMART, which is good for ensuring the goal is clearly defined and communicated. However, I think it is more important to start with "WHY". Starting with the why creates a sense of purpose to inspire people to get behind a goal or objective. Once you can communicate why something is important, you can then move into the how and what criteria that make up a SMART objective. If you want to learn more about starting with why I would recommend Simon Sinek's book, Start With Why.

Strategy - Building environmental context

“The best way to predict the future is to create it”

— Peter Drucker

Strategy is an often used word that carries many overlooked connotations.  Everyone says they want to 'do more strategy', but then falter when they roll up their sleeves and look at what is really needed to 'do strategy'.  

Let's take a look back at a strategy and what it took to translate that vision into the reality of a product.

“Apple’s strategy is really simple. What we want to do is we want to put an incredibly great computer in a book that you can carry around with you and learn how to use in 20 minutes. That’s what we want to do and we want to do it this decade. And we really want to do it with a radio link in it so you don’t have to hook up to anything and you’re in communication with all of these larger databases and other computers.”

— Steve Jobs at the International Design Conference in Aspen in 1983

It certainly sounds like Steve was describing the modern iPad, and this was in 1983, the year before the Macintosh was launched, and at least 20 years before the era of mobile computing.  Turning this vision into a product roadmap was no simple task.  Just identifying the capabilities needed to enable this vision is daunting:

• Small form-factor - industrial design and materials

• High performance - computing power that fits within the desired form factor

• Radio/mobile networking to allow connectivity beyond the device

• Standards for interoperating with remote databases and computers

• Sufficient battery life to make the device useful

• Software designed to such an intuitive level that you could learn to use the device within 20 minutes.

Remember, this quote was at a time with the best selling computer was the Apple II and the IBM PC was growing in popularity.  How would you even go about delivering on a strategy of mobile computing before the term even existed?

Dependencies

Each of the capabilities mentioned had a significant dependency chain before it could be realized.  It is clear, looking back, that Apple was already moving in the direction needed for some of these areas. Other areas were moving with the broader technology and market cycles of the time.  

• The Macintosh came out in 1984 and moved the standard on software design and user interaction.

• Over the next decade, computer performance increased and internet connectivity protocols were embraced to enable remote interaction of data and services.

• 2G networking gave way to 3G supporting higher bandwidths (relatively speaking) in the 1990's and Wi-Fi standards were adopted in 1997.

• Moore's Law marched on; performance increased while power demands per processor-cycle dropped.

• Battery technology improved

Whether each of these dependent technologies was being actively managed or not — only the Apple team knows— it is clear that as the capabilities came into being, Steve Jobs had a vision on how to bundle these technologies to create the type of device he touted in 1983.  

The iPhone was launched in 2007, and as they say, "the rest is history".

CONTEXT IS CRITICAL

How can your product strategy gain such context now, rather than in the future?  Each of the areas needed for this mobile strategy were articulated or implied in Steve’s statement.  By taking each area or capability, it is easy to list the brief history (where it's been), the current state (where it's at), the reasonable future state (where it's going) and then most importantly why it matters (...So What?).

For example (the 1983 view):

Standards for interoperating with remote databases and computers

Where It's been:

1. Computers were stand-alone machines with discrete computing programs running on their own, local data.
2. Relational Database Management Systems (RDBMS) do not have a standard query or access models.
3. Relational Software, Inc. introduced the first commercially available implementation of SQL (Structured Query Language) for the VAX computer (Oracle V2) in 1979.
4. TCP/IP was adopted as the stanadard for military computer netwroking in 1982.

Where it's at (1983):

1. SQL on IBM platforms (System/38, SQL/DS, and DB2) is commercially availabale.
2. ARPANET migrated to TCP/IP in 1983 (Jan 1).
3. Multiple Remote Procedure Call (RPC) models and implementation are in existence.
4. X.25 packet-switched networking provides large global coverage.
5. Frame Relay networks are begining to be deployed to connect local area networks (LANs) to wide area networks (WANs)

Where it's going:

1. Remote data access will contine to evolve, but standard data access will be acieved through some standardized implementation of SQL.
2. TCP/IP will become the standard for computer networking; higher level protocols such as Frame Relay and X.25 will be implemented on top of TCP/IP
3. Remote Procedure Call standards will be established to improve interoperablity.

So What?

1. SQL standards must be implemented in data access models of products.
2. Company engineers need to support definition and implementation of Networking standards built on-top of TCP/IP.
3. Competing approaches for remote procedure calls and data transport across TCP/IP based networks must be monitored, or company must be involved in the definition of such standards.

This structure of looking at the context of the key attributes of the market and the product allow clear action to be taken (as demonstrated by the "So What" section of the breakdown.  Performing this level of analysis for your product and market takes time and effort.  This is the hard-work of establishing a strategic foundation.

The good news is that once this assessment of the market and product needs is completed for the first time, it is straight-forward to update it during your strategic planning cycle.

Start with 'Why?'

The "So What?" of the context clearly articulates why this area matters for the overall product roadmap, and what actions should be considered.   While I doubt Apple was worried too much about interoperating with remote databases in 1983, it is very evident that it was a focus for NeXT computer over the next decade as they created their valuable Enterprise Objects Framework (EOF).   Coupling EOF with the HTTP standards (built on top of TC/IP) gave rise to NeXT's WebObjects, the first object-oriented Web application server in 1996.

Of course, for any non-trivial strategy, there will be too many "So what's" so additional analysis will be required.  Starting with the question of "Why does this outcome or action matter?" will help prioritize the strategic focus for the company.   Parsing through the "So What's" from your mapping will lead to deeper analysis as you work to find proof-points for trends and opportunities for your product.  Once again, this is not glamorous work.  Your shorter list of hypothesis should be formally framed and then tested (if possible).  In today's information age, not seeking out some level of data to confirm or refute strategic hypotheses is only being lazy.  

As data is compiled and reviewed, it should reflect back to the "why".  Why does this data matter?  Why does this support the market trend we are anticipating?  Why does it identify a risk for our product?  Why? Why? Why?

Now, Start Doing, But don't forget 'Why'

At a certain point in your analysis, you need to stop asking questions and start deciding what to do about it.  Remember the context is putting the topography on your business map.  The prioritization and data collection of "why" is picking a path through the terrain.  Assessing your competitions’ capabilities and intentions, as well as your own capabilities informs you what obstacles you will need to overcome as you journey down this path. Now it is time to start taking steps toward your goal.  Too often, this is where companies set all of their prior thinking aside, make a rigid plan, and start executing.  But transitioning to executing can be perilous.  Whether you think of project execution as an OODA loop or a Shewhart cycle, it is key that you reflect back to the "Why" you are doing something on a regular basis.  

2CConsulingLLC can help you build context around your product and marketplace, as well as assist in turning that context into specific, actionable plans to realize your strategic goals.  Contact us today.

Identify the Goal : II

So why is it difficult for a company to decide on its objectives?

Often times, it is because there are so many possible options and objectives that seem 'reasonable'.

Let's take our example from my last entry....

Hypothetically, we are developing a strategy for a software company that is established in a relatively mature market; i.e the desktop application market. For illustration purposes, we are the number three provider of our class/type of software. We have  approximately 20% market-share. The leader in the category has ~50% share. The second largest provider commands a ~30% share.

So, what constitutes victory?

• Is it increasing market share above 25%?

• Is it attaining the number two position in the market place?

• Is it attaining the number one position in the market?

• Is it establishing a monopoly in the market?

We could continue listing options, but the fact that four come immediately to mind should suffice.

So which should we pick? I'll give you a hint; what we pick doesn't matter... Yet.

Before we can settle on what our definition of victory is, we need to understand both our capabilities and our competitor's capabilities and intentions.

A Capability is a Measure of the ability of an entity (department, organization, person, system) to achieve its objectives, specially in relation to its overall mission.

Having an honest assessment of our own capabilities will help us narrow plans to those actions that we are confident in being able to complete.

Having a realistic view of our competitors capabilities will allow us to determine both their possible intentions as well as their ability to carry out those intentions.

The last area of focus, before determining what victory or success looks like is to assess the marketplace and business environment.  Depending on the regulatory environment, it his highly unlikely that achieving monopoly status would be a good thing.  Similarly, emerging technology trends may limit or diminish our capabilities, so we need to account for them in our plans.  

Creating a synthesized view of the environment, our competitors capabilities and intentions, and our own capabilities will let us agree on a goal, and start building a strategy to accomplish it.

Identify the Goal

Now, from my prior post, it may appear that I don't find anything useful regarding strategy development on the web. That's not true. At least not totally true.

I think there are some corner's of the net that have very interesting work and links. Of course, context is required.

Before we dive into game theory and its relationship to strategy, let's make sure we are all operating in the same context.

Firstly, strategy assumes you are in conflict with another entity. This could be organized conflict, such as war or a direct competitive endeavor. It could be more general conflict such as fighting market trends. Regardless of the focus of the conflict, it is this opposing entity that you are developing stratagems against.

Secondly, strategy implies, that you are concerned about an overall plan, not a single tactic to achieve victory. "Shoot first" is not a strategy for winning a war or battle or even a gun fight. The plans and activities that ensure you will take the first effective shot in the fight would constitute a strategy.

Thirdly, you know what victory looks like. It is impossible to plan if you don't know what the overall aim or objective is. In the military, it might be the defeat of the opponent. But it might also be creating a state in which the opponent can no longer inflict material damage against your forces. Or it might be inflicting sufficient casualties on the enemy that they cannot entertain battle for the next generation. Knowing what the ultimate objective is, in detail, is critical.

So let's apply this thinking to a business.

Hypothetically, we are developing a strategy for a software company that is established in a relatively mature market; i.e the desktop application market. For illustration purposes, they are the number three provider of their class/type of software. They have 20% market-share. The leader in the category has 50% share. The second largest provider commands a 30% share.

So, what constitutes victory?
 

• Is it increasing market share above 25%?
• Is it attaining the number two position in the market place?
• Is it attaining the number one position in the market?
• Is it establishing a monopoly in the market?

Deciding what the desired outcome is, is the first step in developing a strategy. Unfortunately, for many companies, it is not so simple.

Strategy Development

It's amazing what a quick Google Search of business strategy turns up. Where are the deep thoughts and exchange of ideas that the internet is supposed to foster? Behind a login prompt and request for payment, mostly.

But developing strategy is not rocket science.  

Is it difficult? Yes. But only because it requires hard thinking (which we typically don't want to do).

What makes it hard? The fact that the devil is in the details. Creating and executing effective strategies cannot be done with superficial analysis or argument by analogy. It requires real honest-to-god heavy lifting to be effective.  

And maybe that is why people want to charge for advice and services on strategy development.

Maybe it's just because they don't want people to truly understand.

Over the next few posts, I'd like to collect may thoughts on strategy.

Let's start with the fundamentals. From the dictionary:

strategy |ˈstratəjē| noun ( pl. -gies) 
• a plan of action or policy designed to achieve a major or overall aim : time to develop a coherent economic strategy | shifts in marketing strategy. 
• the art of planning and directing overall military operations and movements in a war or battle. Often contrasted with tactics (see tactic ). 
• a plan for such military operations and movements : nonprovocative defense strategies. 
ORIGIN early 19th cent.: from French stratégie, from Greek stratēgia ‘generalship,’ from stratēgos (see stratagem ).

"To achieve a major or overall aim"-- this is an important concept. If you can't state what your objective is, you don't have a strategy to achieve it. How often have you been in a business setting and asked yourself "why are we doing this?" It might just be because you don't know what your true aim or objective is.