Is your APM strategy a yard sale or a Beauty Pageant?

This and the next few weeks Carl Engel (Elyon Strategies CEO) and I are collaborating on a white paper about Enterprise Portfolio Management. The insight that we should do this came about a month or so ago at a Industry Vendor’s Conference where we saw some serious misalignment in presentations touting Agile and APM as the key to success. Our objective behind such is to give executives insight and tips how-to implement a beneficial portfolio practice beyond just APM.    My strategy creating this paper is to provide the “Cliff’s Notes**” on the Enterprise Portfolio Management practice I’ve been maturing over the decades for various consulting, technology firms and their clients.

During our brainstorming sessions one insight has continually come to the forefront.  The state of the art in APM is drastically behind the state of the industry in financial portfolio management.  Not only that but the practice in APM could actually be damaging to an enterprise.  Here is one insight from our brainstorming session:

Application Portfolio Management (APM)

APM as practiced by many IT organizations and consulting firms typically focuses on one of two strategies: Rationalization of Current or Curation of Potential.  In the first strategy the organization is seeking to ride itself of assets in its portfolio.  In the second strategy picking individual winners or highest winners is the goal.  Both of these objectives are well meaning however, if not accomplished in alignment to an enterprise’s business can prove devastating.

Portfolio Management was originally introduced as a strategy to balance risk and reward in the financial investment industry by Nobel Prize-winning economist Harry Markowitz.  As the concept of portfolio management migrated to IT the second factor, risk, seemed to have been dropped from consideration.  If a root cause analysis had been accomplished you’d likely find many of the serious issues within IT can be traced back to not considering the enterprise risk of the equation.

With regard to the first strategy Rationalization.  Lets consider why one is “rationalizing” the portfolio.  In several engagements I was brought in, was due to acquisition of multiple assets or copies of assets doing the same thing.  The root questions is why?  The other situation was the asset did not perform or no longer performs at the desired level.  The end result of such is these assets are like the tail end of a yard sale. The only thing left to do with them is box them up for charity (unlikely) or putting that ugly lamp into the trash to be hauled away and forget about them.  But why did this occur?  If it was an asset to the enterprise shouldn’t it have been managed as such?

In regards to the second strategy Curation of Potential, there are many books, consultants and firms touting how-to develop effective business cases for initiatives.   I’ve co-developed several of these for corporations such as IBM, Microsoft, and other consulting firms.  Unfortunately despite cautions to the contrary, these are often watered down to eliminate the interdependence risk portion of the equation.  This creates a popularity contest for funds.  This maybe due to self-interest by the initiative promoter, a lack of insight as to the interdependence of the initiative within the enterprise ecosystem or that no one wishes to discuss the potential downside: “You’re just being negative…”  In any of those cases the risk to an enterprise is an iceberg in the ocean the enterprise is sailing through.

The forthcoming white paper will provide some tips on effective Enterprise Portfolio Management, while the training course to follow will delve deeper into how-to establish and mature a portfolio management practice.  This will also help enterprise determine at what level they are and what level of practice is optimum for them.  That is not every enterprise needs to or should be at a Level 5  of capability/maturity.

 

 

 

**Shorter versions of Dummies books for those born later than Boomers

Advertisements

Cloud –hype or a lesson to learn about ongoing technology change

A while back the model was there was a market for just 10 mainframes worldwide, or so the quote goes.  The in order for a corporation to join the big boys, you needed your own.  Decades later I’ve the equivalent of a S/360 processing power in my pocket.  If one follows the technology generations: On-Prem. Mainframe; Department Minis; Timeshare; PCs; Client-Server; then Internet, Now Cloud. There is always a new technology on the horizon (e.g., quantum computing) that will solve the worlds problems and put the kids to bed on time or so the marketing hype goes.

I’m neither a fan-boy or luddite when it comes to new technology.  I believe I’m a pragmatist.  I’ve a set of simple rules when it comes to acquisition and holding onto technology:

  • Explore and examine, but do not commit till conditions point to such
  • When exploring the technology, examine both the technological aspects:
    • does it add new capabilities
    • Is it stable (mature enough, reliable enough, has enough market share to continue a reasonable lifespan)
  • and business application:
    • does that new capability add something to my business
      • Reach to customers or markets
      • Improve customer relationships
      • Allow me to do something new for customer or improve my operations
    • or reduce costs and risks

Which brings me to the latest R&D I’ve been conducting over the past few decades that fits into my larger research project of creating a CAD/CAM system for Enterprise Design, Construction, Operations, and  Remodeling.   That latest research has been all about the overlap between business and technology strategy.  This is something my mentor John Zachman had started decades ago.  By now I can imagine several people’s eyes rolling. “Zachman Framework!, that so yesterday…”  However, those that have seen the decades of methodology hype go by know that the Ontology expressed in the Framework still is relevant.  Its just not the “silver bullet” everyone wants.  It takes some work to understand that the views defined in the Framework are there for a reason: To understand the various aspects of an abstract entity, Enterprise, to be manifested.

Given the hype and technology priesthoods that have developed around various methodologies: TOGAF, DODAF, SAFe, BPMN, etc.. I will not enter into the fray, other than to say these all have some aspect of utility and all address some dimensions in the Zachman Framework. 

Back to Cloud and business/technology strategy:  As of late business models or various levels of business models (Campbell’s Operation Model Canvas**) are become more mature from decades ago and starting to reach across to technology or rather technology has been identified as an enabler to business strategy.  With that as an underpinning to this post.  I post the real question around Cloud and Cloud Hype:

The real issue is how or should you take advantage of such. If you’re just switching technology to “modernize” that’s fine.  If the cost of maintenance or business continuity risk due to end of life is a significant threat changing technologies is a simple model (i.e., you’re replacing you car because you can’t get anything more out of your Model T).  That does suggest however, it will be running business as usual.

That, in my opinion, is short sighted as few businesses are in an environment that enables that.  Today business as unusual is the norm.  There is so much volatility and change going on in the space we call enterprise that operating a business is now more an effort of managing complexity and change than executing a simple production line was twenty or thirty years ago.  As such prior to committing to such a change it behooves Executives to ask the questions beyond the easy just replace On-Premise with On-Cloud for a supposed cost saving, how will I exploit the technology to improve my business besides just keep it operating another day?  As well as ask what are the trade-offs I make with such choices:

  • Dependencies/Risks on a service provider
    • Will they be around tomorrow
    • Will the service change
    • Besides Security and Data Ownership, can I extract such to a new provider should I decide to
  • Will/Can I integrate a broad spectrum of services together (primary vendor and others) with moderate or less effort, or is it really a closed system
  • How long will it take to covert?  Will the conversion take more time than the technology is likely to be in place

The thing I tell my clients continually, there is no free lunch, there are always trader-offs.  Some immediately, Some during an event, and Some eventually (i.e., in the future).  It is up to your executive team, not the technology providers or operators within the company, to understand these implications and impacts.  -And if your team does not have the confidence in making these decisions get a Business – Technology Strategy Consulting firm to assist.  This is not a technology strategy consulting firm (i.e., how to install, configure, and operate), but one that focuses on how-to use the technology for business as well as what are its implications to the business.

**full disclosure I’m working with Andrew Campbell on a tool suite to evaluate Operating Models similar to the evaluation tool suite I built for the Business Model Canvas community

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 Portfolio Management

Updated the CMM and Capabilities Roadmap yesterday still have a few more items to add.  The roadmap is slowly coming into shape.  Hope to have presentation and tools ready by February conference

Modern IT Portfolio Management CMM

Like the original CMM this version for Portfolio Management has 5 levels.  Taking a page from the CMMI work I did in the Marketing Domain for IBM/Samsung, et al. It will contain an assessment tool to help enterprises do it themselves.

I’ve been developing a CMMI for Enterprises Architecture similar to the Software CMMI.  Enterprise Portfolio Management will be the first subsection of the EA CMMI which will be part of the Structure in Threes book in works. Modern IT Portfolio Management CMM Capabilities

Internet of Things

During yesterday’s drive home and this morning’s drive into work I considered the latest Hype-cycle meme “IoT”, the Internet of Things.  That magical connection of every device to…  While we’ve had IoT in many forms prior consider X10 which many a RadioShack customer “wired” their house with, then PowerBus, etc.  Then as microcomputers truly became ubiquitous, home started getting wired for TCP/IP and later WiFi.  Now the amount of Wifi Hotspots around businesses and homes is staggering.  At an apartment a few years ago I was amazed to find no less than twenty-three private networks within range, no doubt all connecting various devices beyond a PC and providing services such as video and audio media.

Now as the term “IoT” comes into play I wonder if this and the “app” crazy has created the ecosystem that is the digital equivalent of what we all complain about airlines and hotels these days?  a la carte pricing and thereby cause the consumer and business to be the systems integrator.  The question become does “IoT”, “App Stores” and consumption economics become the perfect storm to devalue Information Technology and the complexity involved in integration.

I as this questions as more business executives question the value of enterprise and other technology architectures while in the same breath can’t understand why the pieces don’t fit together easily in just a flew clicks.  I wonder if that CxO’s car stops dead in the desert out of range of a cell tower will her or she be lost forever, given the likely inability to fix the technology they’ve asked for and become dependent upon.   About to decades ago and reprised the thought a few years ago, that one day businesses are likely to fail due to technology failure.  As this decade reaches the halfway point, I see that risk increasing beyond the obvious threat of hackers.

Methods: Designing a new Service

Had a great brainstorming session yesterday with a colleague discussing how to apply DSM techniques to the Service Design activities we’re involved in. [Going to have to update my methods PowerPoint again]  Came up with using DSM to identify and cluster functions across various customer requirements and then a simple prioritization using Risk DSM and Business Impact [ Risk * Business Value = Priority ]

Brainstorming DSM

Clustering activity is initially based on common functions. These are later categorized into one or more basic causes using Fishbone (Iishikawa) diagraming and 5 whys:  Capability, Capacity, Schedule, and other.  The context is total throughput (i.e., “The Goal” ).  This sets the context to prioritize which areas to address first.

 

Afterwards I when to my whiteboard to draft a model of the service I’m working on using Osterwalder’s Business Model Canvas.  Once I summarized the Business Process models I created before and extracted key components, it became obvious that the context needed to be changed.  The business in a business model context yielded some strange relationship issues.  Once internal supplying and receiving groups became Key Partners everything snapped to the grid perfectly, even then cost structure and revenue stream categories which are often hard to identify in internal business models: especially in IT where chargeback is often applied inconsistently.

Business Model Canvas

Modern IT Portfolio Management: Risk: System Definition

System Definitional Risk

One of the serious risks in Architect side is system definition. This is partitioned into completeness(e.g., maturity level [none to integrated], Validation level [none, author’s bench check……Simulation of requirements], and requirements freshness (i.e., things change, was what was needed specified and validated too long ago….).