IT Business Model Dynamics

This past decade IT organizations have been challenged by executives to demonstrate business value. After years of budget crunches and pushes to show ROI on every line item Executives are questioning whether their IT organization provide value to the business or should these organizations be dissolved in favor of purchasing cloud services.

The problem for IT is as a function they have not focused on identifying and creating business value. This may have to do with its origins as a service and expense. Thus understanding how IT contributes to business value has not traditionally been a high priority as much as dealing with ever increasing demand and a shrinking budget to service such.

However, for IT to contribute to business value the organization needs to overcome three major problems: Alignment, Prioritization, and Interdependency.  Solving for these design constraints can be challenging.  However, if one applies system engineering methods a optimization of the business model and its implementation can be achieved.  This though is not a design once, build one, operate forever endeavor.  As with the Enterprise conditions change and IT organizations will need to be more agile in more than creating IT functionality.

Structure in Threes: Business Design and Reengineering

The last round of brainstorming tightened up my thinking around the methodology.  Like all engineering endeavors I needed to identify the beginning point for creating the enterprise.  Most of the business model approaches are just that.  They document the existing and while that is necessary, is that sufficient?  When I’ve attended workshops focused on business models, often it ends up around optimization rather than innovation.  The strategy and planning methodology I devised and fielded for other corporations was purposely limited, because at that time these corporation’s business models were deemed untouchable.  Even though several people could see its useful life was coming to an end.  Secondly, reengineering a business model it difficult for most in management positions…their mentality is around optimizing the status quo.  Not a blame, it how they were successful and how they are managed in most corporations today.

The brainstorm I had the other day was along the lines I had decades ago when I suggested a practice that would design and build corporations custom for an entrepreneur.  Thus one has to look at what that means.  What would be the design parameters used in doing such.  The past month I came to the conclusion that businesses should be designed around the customer rather than businesses trying to find customers around them.  That insight brought me to using Peter Mark’s (Design Insight) tool Customer$APPEALS (C$A) to determine the design parameters for the “product” I’m building; an enterprise.

With C$A as a base one can use that to weight investment is the various aspects of the business model and value chain the enterprise participates in.  With that as the starting point my methodology has evolved to the following:

Business Model Design -bks (2)

As of this positing I’ve tested this approach in two reengineering project that look to be successful and expect to do another pilot at another two corporations: one already in process and looking for another to pilot.  This “methodology model” will be one of several “views” in Structure in Threes” book and workshops I’m developing in spare time.  Expecting to have first workshop ready by summer.

Business Model Enablement

One of the problems with Enterprise Portfolio Management (EPM) is its’ limited focus.  EPM to a large extent has been dominated by technocrats that act as though the entire enterprise is populated primarily by hardware and software; that is people exist to serve hardware and software needs rather than the reverse.

One can hardly blame management for this perspective and behavior when you consider the management systems in place such as financial systems have not evolved much since the middle ages.  Financial systems are “thing” based, listing such artifacts as depreciable assets.  While executives give lip service with such fraises as “People are our most important asset”, the majority of systems account for people as liabilities. When was the last time you saw a balance sheet listing the value of the people employed within the corporation?  This seems rather odd considering H/W and S/W requires people and their skill and knowledge to operate, maintain, and gain benefit from these other assets.

This brings me back to business models, currently the rage within executive and VC circles.  In the Business Model Canvas activities and resources hold a key position.  Its though these two components that value is realized as per the company’s value proposition.  Yet often neither the activity or resources boxes account for the people component –expect as either partners to engage with or customers to engage with.

Yesterday’s R&D activities has me investigating corporate capabilities and the associated competencies of people that enable these capabilities which are used to enable the business model.  Several years ago I developed a competency model that was associated with the process activities for a major function within corporations.  I see revisiting that work in light of business models will likely produce the alignment between people, portfolio, and business model that I’m looking to address in this round of R&D.

IT Planning and Agile

Some of the new organizations I’m dealing with are going crazy with “Agile”.  The Hype Cycle  is in full force.  Soon Agile with be advertised to put the kids to bed on time, solve world peace, and feed the world.  The problem I see is not with Agile its with its close cousin “Addle” which is often what I see organizations implementing (I.e., the worst of each methodology glued together).   I will point out that I am neither a zealot for Waterfall or Agile; its a tool and like other power tools –notice the woodworking reference– it should be used carefully.  Too often I’ve seen Agile be used for an excuse for poor or no planning and/or poor development practices.

If one reads the original materials, nowhere does it say don’t plan.  Actually it indicates you need plans, just not at the level of precision and scope previously and wrongly drummed into people’s heads.  Agile suggests or recommends planning in short enough horizons such that the problem doesn’t change before you finishes planning (accuracy) and to a granularity (precision) that is enough to get the job done.  Another way to look at it:

If my problem was to cross the river and you spent five years planning to build a bridge, by the time you actually built the bridge I may have cross the river with a boat and now I’m faced with climbing a mountain (problem has changed).  If I want something to sit on I may want a chair, but it may not need to be designed and constructed to 1 millionth of an inch tolerance –which would cost a significant amount.  I could probably get by with 1/32 of an inch, produced at lower cost but yielding the same level of performance I desire.  So in the end Agile is a balancing act that I believe still requires planning; just different types of planning and a whole lot of thinking.

 

IT Planning Methdology

Started putting together a tutorial deck this morning for an Enterprise Architecture Methodology which is more business based than IT.  Having watched IT over the years get lost in the technology details I though it was about time to create an approach towards really designing Enterprises; the thoughts I had years ago when I presented at the IBM Application Institute and AIAA Operations conferences.  Why couldn’t you design an Enterprise (not just the IT) the way you design any other product.  Years later, several “internships :-)” in other roles within the corporations, and researching various methods from multiple disciplines I’ve started to integrate these into a design methodology:

IT Planning

The above approach has business model as the root where other aspects are details to that end.  That is IT Planning is based upon enablement of the business model, Market Planning, etc. all come from that common root.

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….).