Why your planning sucks… and what to do about it

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”Dwight D. Eisenhower

Over the years, I have the fortune or misfortune to be involved or observe various disastrous planning activities. Most of the time one could tell things were not likely to end well. Why then did these continue to an eventual bad end? Simply because people confused planning with plans.

Plans are the documentation of the activity at a specific point in time, not the end state. Too often plans are viewed as cast in cement, never to be changed, even in the light of an approaching cliff. The question then becomes why? From observations, I’ve conclude that much of it revolves around ego. If I’m the manager I’m supposed to have all the facts and answers. And my decisions cannot be changed as these are personal commitments and a change would reflect poorly on me.

What is needed in management now is like what happened in various design professions “Egoless… programming, etc.

A simple categorization of why changes to plans are needed often reflect aspects that are often not in control of management at the time a one and done plan is made and being executed.

  • Results from activities is not as expected
  • Conditions have changed since the plan was developed
  • Another factor has surfaced or has more impact than anticipated
  • New options have surfaced

All of these infer the need to adapt or adjust one’s plans. So why in business do we continue down the wrong path in the light of these. We’re back to plans vs. planning; cement verse wayfinding. If one adapts the notion of real options in planning, this might address the situation where planning becomes day to day activity rather than a concrete list of tasks to check off. Which may have us focus on desired outcomes rather than actions that we hope provide results.

Business Ecosystem Future –a look ahead

Had an interesting discussion yesterday morning with a colleague. Our discussions already are wide-range and free-wheeling.   This morning was no different. We discussed the nature and evolution of businesses. During that discussion, I brought up how information technology has changed from monolithic applications to small apps and my hypothesis as to why. Part of that rational I believe is due to two factors: First, the IT backlog and its increasing failure to address business needs. While many IT organizations have, or are switching over to “Agile” or “Addle” as several colleagues have called it due to many misfires, I look at Agile as one of many data points proving a change to the Business Ecosystem.

The days of monolithic anything is drawing to a close. Lean the precursor to Agile in manufacturing has been working its way upstream. What this suggests is that small and fast will been the dominate development and construction tactic of this age.

This then means that consulting firms will need to retool also not only learning fast production methods like agile but understanding how to address the complexities of many more loosely coupled components. Apps vs. Applications means that integration often happens between the ears rather than through the database or API.

The critical skills that Enterprise Architects and Consultants will need to develop are in opposition to their training:

·        Synthesis in addition to Analysis

·        Experimentation and tolerance for failure (often called learning)

·        Business Value Management

·        Complexity Management

·        Understanding of Options Theory planning

·        Business Lifecycle Management

This will mean a new type of consulting firm model as the nest in the shallows of a corporation as high priced contingency labor will be unacceptable to leadership, they’ll be looking for just-in-time consulting.

Strategy and Vision Analysis

Digging through some old files this afternoon to find this sketch from ’95.

vision-analysis-workflow

After I had decomposed a Senior Executive’s Strategy and Vision to find some of the major weaknesses and suggest mitigations, he asked me into his office.  He had only put out the document a few hours before.  Mind you I had just joined the company a few weeks before when I sent the critique; other’s had warned me that was a career limiting move.  That this Executive didn’t like criticism.  So when he called me into his office shortly after sending my assessment.  Well you can imagine I figured; it was going to be one of the shortest careers in the company.

To my surprise and delight, he gushed over my assessment.  Saying it was a brilliant piece of analysis and wished others in his organization could do such.  All he could ever get from his subordinates was a weak “Because we’ve always done it that way” or other “I just don’t like it without any rational explanation.  His next request during the meeting was simple,  he asked me how I could do such so quickly.  I pulled out some paper, sketching out my process as I describe how I performed each step, and how each step fed the next in line.

Today I’m still analyzing strategy and enterprise architecture, design and construction; though my tools have matured some what, the objective of each step are still the same.

 

I guess the saying the more things change the more they stay the same still rings true.  Though many don’t realize, most of the new solutions touted are really the same ones from the past, just masked in newer technology

 

 

Started Enterprise Portfolio Management CMM white paper last night.  Expect this will become a finished chapter in Enterprise Design and Engineering book in progress.  Presently collating and organizing materials from all the engagements and methods I’ve produced for corporations over the years into a cohesive practice guide.  This will be a companion guide to the tools suite I am working on to release some time end of year.

enterprise-portfolio-management-white-paper

Enterprise Investment Portfolio Management Level 3 Practices – Alignment

Integrated Portfolio Management

Introduction

One of the most difficult challenges in businesses is alignment, and with increased size the challenge only increases. Add to this corporate version of the telephone game the various contexts that are within modern corporations today and you are lucky to have sixty percent alignment.

A typical scenario that has been externalized is the common critique about management consultants and other associated business management business operations divides. How often does one hear “Culture eats Strategy for Lunch” or something similar. Or from the alternative perspective “If I ask my customer what he wants, he’ll just say a faster horse” thus demonstrating that operations misses the point that businesses and the market have never been static; and competitiveness continues to have a shorter and shorter shelf life.

At the core of this dilemma is that at each level of a corporation the context, responsibility, accountabilities, and concerns are different. And typically do not have a mapping between such. What I theorized is that an Integrated Enterprise Portfolio can mitigate some of this issue.

Such a portfolio not only captures the concerns of each level but provides that mapping so vital to creating alignment between the layers of an organization. This section of Enterprise Investment Portfolio Management: Level 3 Practices –Alignment proposes to define a mapping between the various visualization tools in popular usage such as Business Model Canvas, Benefits Dependency Network, Strategic Capabilities Network, SAFE™ etc.

 

Business Model Canvas and Agile-like taxonomy

Business Model Canvas and Lean Canvas over the past few years have become many management consultants and executive’s most favored tools. In a one page visual someone can see how a business creates value for both stockholder and customer. Unfortunately, once we leave the world of executive management and strategy we lose both context and concern.

While it is unlikely we can transmit context, the concern can be projected or mapped into another context that lower levels of operational employees can align to.

Business Model Portfolio Alignment

Above is initial draft of this mapping. The Agile-Fall taxonomy in the organizations I’m working with may have other labels but still follow the same hierarchy as well as are still in the evolutionary state.

Anti-value and Process Measurement

 Anti-value

The problem with Earn Value (EV) has applied by many PMs and Enterprises is that often there is not value achieved. What has been done is to expend effort (work) towards a goal which is hoped to achieve value. Too often lately earned value and effort have been used as interchangeable; they are not. These are two different concepts.

It is said “Value is in the eye of the beholder”. However, if the beholder is not the ultimate consumer of the effort I would contend you may or may not have achieved value. It is my assertion that value is in the eye of the consumer external to the working entity.

The example I use is rather down to earth rather than using abstract deliverables. Take an aluminum billet, rough mill it into the shape of an aircraft wing spar. Many PMs would claim some percentage of EV at this point. “See we’ve accomplished x percent of the steps towards creating the spar, so we’ve achieved x percent of EV.

However, if we stop there can you sell this rough spar to the customer or another customer for the cost of the materials plus level of effort employed?   Typically, not. More than likely the enterprise would be selling the rough billet as scrap or salvage rate (cost of the raw material). So really what has happened is the enterprise has created Anti-Value.

Process Measurement

In 1985 Dr. Arno Schmackpfeffer, et al. put forth an article in IBM’s Journal of Research and Development “Integrated Manufacturing Modeling System”. In that he and his peers asserted there are five primitive activities in a process: Make, Move, Verify, and Rest. These activities are the basis for creating value.

Five Primatives

At his point many would put forth the argument that only one of the five, make, creates value. However, that neglects other forms of value creating activities. These again are in the eye of the consumer.

Does “Move” create value? Clearly it must, as people are willing to pay firms to move things for them. Even investment firms use move to create achieve value: Arbitrage, moving goods from one location to another to gain value from the price differential in locations.

How about “Rest or Store” this activity? Does nothing but leave an item in place, what value is in that? How many people lease self-storage space to keep things? So there must be value in rest or store as people are willing to pay for it.

Now what about “Verify” clearly verify adds not value? With verify the consumer of verify is looking to get assurance that what was accomplished previously was actually accomplished. Auditors and Consultants are examples of service providers that engage is such activities that enterprises are willing to pay for.

Summary

I had labeled the above section process measurement as a correction to a previous blog article https://briankseitz.wordpress.com/2013/11/11/structure-in-threes-process-value/  to put it in better alignment with the assertion I have that value is not achieved until someone is willing to “pay” for it.

In 1998 I had taken the five primitives a little further to develop a quick analysis method for BPR/M engagements. This approach enabled my team to analyze business processes to determine what activities could be eliminated to increase process efficiency and value contributions

Process Analysis

 

Business Value and IT Value: a Disconnect

Over the decades I’ve bounced between working within IT and working within other business functions.  The one conclusion I’ve found, despite all the rhetoric and initiatives to the contrary, IT just doesn’t get it.  The latest examples are the two campaigns on the top of the Hype Cycle:  Agile Development and User Experience / Design Thinking.  Yes these are valuable initiatives, but at the end of the day these are contributory to improving IT’s ability to deliver applications and technology services.  Not necessarily business value.

Many of my pervious IT peers and Technology providers would like to argue the point that these deliver Business Value.  My counter to this is simple:  Does a wrench, shovel, chef’s knife, etc. deliver business value?  Only to the mechanic, landscaper, or cook that knows how to use these productively.  The key words here are “use these productively”  This suggest that IT needs to understand how these tools are to be used -beyond the manipulation of data– and measure their contribution to business value based upon the business value the business itself delivers (i.e., a percentage of the business value, not the entire value).

This then suggests a line of research which should be undertaken to establish how to measure that contribution.  Several times I was engaged in such research:  IBM’s initiative on Strategic Capability Network,  DMR’s Results Chain, and more recently using Benefits Dependency Network.  The problem with all of these initiatives was that they were applied backwards (i.e., here is a technical solution how do I map it to a business result)

Over the past decade I have become enamored by Business Models.  I now see Business Models or fully attributed business models as the connection between Business and IT.  That is to be able to explain IT’s relevance to the business.  My current role within my company is heavily focused on managing the portfolio of technology investments (IT projects).  Initially the organization had as its measures a focus on making delivery of the IT service more efficient.  Whether it helped the business be more efficient or effective was not really on their radar.  Which I could completely understand.  IT in most organizations is constantly a whipping boy, with complaints of late delivery, underachievement, and a lack of responsiveness. Even if business functions themselves have contributed to much of this issue.  Its no wonder why IT is focused on improving delivery above all else.

Leadership, to their credit, recognized the problem and moved the activity to a business function.  The results have been amazing, in a short time the focus of the activity has really switched from IT projects for IT benefit to examining business value for the corporation.  While the business value measurement is more educated guess (t-shirt size ranking) than actual metrics, its a great start.  What is missing still –though I’m back to offline R&D on this issue– is the strong tie-in to the business.  As I continue to investigate, I’m now seeing the linkage between business models, strategy and portfolio clearer than when I was working on various planning horizons at IBM Corporate.