Structure in Threes: Modern IT Portfolio Management Investment Strategies

Like financial investments using investment classes to allocate across the portfolio to attain sub-goals. Consider the Balance Portfolio strategy that many financial advisors have given to financial investors. In such strategies different types of investment are employed for sub-goals. At the highest goal one is attempting to achieve the maximum return for the level of risk an investor is willing to take.

IT Asset Allocation Matrix One

In the IT domain, I propose the three types of investments are Innovation, Optimization and Operation. And like financial investment each has risks associated with the change and the risk associated with doing nothing (opportunity costs). These three classes represent the spectrum of significant change (innovation) to moderate (optimization) to maintaining the status quo (operation).

For businesses in previous decades changes to the market and ecosystem where slow. As such innovation to address these changes could be limited to only serious immediate threats and funds reserved to optimization which increased revenue streams or reduced cost. Operations was then second in priority as optimization could reduce operating costs.

As the years have progressed the rate of change in markets and the ecosystem have accelerated leading the need to adjust the balance of investment in the portfolio, first allocating more to optimization, innovation and reducing operational investments. Now as hyper competition has arrived, enterprises are again looking to change investment allocations to becoming more innovative. The issue arises in that further reducing operational costs may create areas of high risk due to the creation of single points of failure –which may not be known. This could place an enterprise at a point of catastrophic failure as the cascading effects of this single point of failure ripples through the corporation.

This underscore the need to balance investment goals with risk management in the IT arena.

Modern Enterprise Portfolio Management –Window of Opportunity

Over the past years IT Leadership and Vendors have dabbled in what they have called “Portfolio Management”.  The process has been primarily a budgeting activity to date with the goal on how to allocate funds to be spent on new development projects and cash reserved for continuing operations.  Typically at the end of much gnashing of teeth and hand wringing a spend plan is created and executed on.  Attention to the portfolio or rather collection of projects and technology is quickly switched to monitoring how money in the budget accounts are spent.  For those organizations that have advanced in accounting practices tracking as to if the projects have completed are reviewed on target or if projects exceeded original forecast and the IT Asset has been acquired or created.

While the financial maturity of IT organizations has increased over the years I would not say these practices constitute Portfolio Management unless tracking creation and acquisition of technology is considered the enterprise’s goal for a portfolio which could be managed by a simple inventory management system.  To me Enterprise Portfolio Management suggests, like financial portfolio management, an activity to balance investment return and risk.

In financial ecosystems, return is based upon the increase in value of the assets acquired and risk is the possibility of those assets decreasing value.  In the typical enterprise scenario IT asset value is typically measured in terms of depreciation (i.e., decreases in value).  Does this sound like an investment management activity?

What needs to be changed in IT Portfolio Management is expanding to account for the value side of the equation.  However, typical ROI approaches within most IT organizations are little more than forecasts based upon hopeful assumptions and soon forgotten once budgets have been approve.  Just before Y2K several thought leaders had push forward towards this concept of tracking enterprise project value:  Strategic Capabilities Network (William A. Tulskie, Jr., Sugato Bagchi) , Benefits Management (John Thorp), and Benefits Dependency Network (Cranfield University) to name a few.

However, unless a visionary CEO and CIO had the insight to establish such practices it was easier to just continue with a budgeting approach. Even when a value management approach was introduced it was often not established at an high enough organizational level to have the needed information and impact. This may be due to the maturities of the practice, organization, and the confidence of the CFO that often sees this as a challenge to his/her role and authority.

As newer enterprises have started to take dominate position in the economy,thought leadership in business and a recognition that business models gaining mindshare in executive offices, an opportunity exists to advance the state of the art in Enterprise Portfolio Management.  However IT needs to stretch its understanding of where value is created.  The portfolio that needs to be managed is the capabilities the enterprise uses and will need and the associated technology assets used to enable these.

The practice of managing a multi-layer/dimensional portfolio is where this blog continues to document research and results of practice.

Agile: Users Stories

Had some interesting discussions around User Stories in Agile.  Unfortunately I see far too many “developers” focus on technical aspect that results in acceptance criteria immediately. Real authors take time to write stories and edit them on a semantic vs. syntactic level.  This is you write a User Story like regular author you’d  have a story with begining problem, journey, and an end that has the problem solved.  Then examine whether the actual story provides value.  Then finally looking at how to measure success (acceptance criteria) or rather measurement strategy…if the solution that is built really meets the spirit of the story rather than an artificial measure that doesn’t related to the value or operation or only the operation of the story.

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.

Age of the App

Rogers and Moore’s customer adoption curves illustrate the results of several factors in apparent opposition; Value and Risk.  This two primary factors have been used to explain customer purchasing behavior as well as clustering customers into groups based upon purchasing time within a product’s lifecycle.  These simple models, which have proven useful to traditional marketing and sales organizations, but may need to be adapted to today’s new market dynamics.

Markets are becoming saturated with feature-rich products that promise value at the end of long implementation and adoption curves.  This had placed the majority of revenue in vendors pockets while placing the majority of risk in customers hands.  However, with the introduction of cloud and other same units of functionality such as smart phone apps, customers are rethinking purchases and demanding value capture for purchase much earlier, almost immediately upon purchase.  This shifting dynamic is requiring companies to rethink new revenue models based upon consumption economics.  This places more risk upon developer as the majority of revenue is generated through utilization charges not a single purchase, but has the potential to create a longer and more staple revenue stream over time.  This concept was introduced by Chris Anderson’s book The Long Tail.

This suggests that businesses will need to rethink how products are produced and adoption encouraged.  No longer can a vendor rely on a long list of features to attract and retain a consumer base.  Vendors will need to focus more on the value customers receive easily which suggests an increase focus on customer experience as Pine and Gilmore suggested in their book.  Making customer experience a primary design consideration infers a new way of thinking; an outside in design approach as advocated by UX gurus Alan Cooper and Bill Buxton.  This promises to be a more radical shift in software development than switching to Agile development.   But the signs are clear, the age of the App has come and vendors that wish to thrive in the market will learn how to capitalize on this approach and trend.


Structure in Threes: puzzle pieces

The last couple of methods –for the design and reengineering businesses –fell into place last night as I was walking through an internal presentation deck for a conference my team and I are presenting at.  Expect to start harvesting blog and presentation materials for book this coming month.  Interesting coincidence that book writing effort kicks off this coming month along with other life events.

The two additional methods will focus upon measuring the impact of the changes to the business model.  In Stafford Beer VSM visualizations, a system two and three dashboards.

As I continue to explain the design practice, I’m seeing another set of practice methods surface.  I’m a strong advocate of whiteboard usage in meetings and think SurfaceHub will enhance user experience once it becomes adopted in meeting rooms as standard equipment –I can see it replacing whiteboards and can’t wait to have four in my home office.  Added to that approach for collaborative efforts is a variation of TED Talks.  I think the process of explaining an idea in constrained time and answering questions helps sharpen the idea, as the questions force one to think through aspects of the idea that were fuzzy or ignored before.  I’ll have to prototype/pilot this concept next team meeting.

Structure in Threes: Control Systems

Started rereading materials around control theory and systems.  Much of current texts focus around electromechanical models of control systems.  However, I’m seeing strong affinity to organizations controls.  I’m seeing Stafford Beers work strongly aligns with those models of having operations, management, regulator/coordination structures, the environment and metric/measurement systems as the basis for a simpler servomechanism like model:  Environment, Operation, Management Control/adjuster, Sensor/metric device.  The questions then become whether open-loop or closed loop systems


Get every new post delivered to your Inbox.

Join 464 other followers