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

Is Enterprise Architecture Completely Broken?

IASA Question Is Enterprise Architecture Completely Broken?

EA –that is credited to John Zachman– originally was “A framework for information systems architecture” a tool for MIS (aka IT) to “design” the components needed to support business objectives.  This was an evolution from a former methodology “BSP”  Business System Planning –also from IBM– which provide information to MIS directors and Business Executives to plan budgets/investments.  Later this budget prioritization was advanced by Parker-Benson in BEAM (refer to Information Economics).  EA roles became split into two camps:  Budgeting and Design.  The problems arise in that both roles forgot that the architecture role was that of facilitator rather than decision-maker and the primary stakeholders don’t have dialogs with these role holders typically.  This leaves rise to EAs creating visions and actions to create local optimizations.

Of course it is not too often that EAs are placed in a position that has the exposure and influence necessary to fulfill the role’s perceived charter.  Thus often EAs are glamorized programmers or software engineers granted the title after years of hard work in their domain by HR.  This gives them the title but not the scope or enterprise orientation.

More impactful to that position of influence; what CEO, COO or other CxO would grant that power to a non-executive.  While HR has toyed with titles such as CTO and CIO, the role of Chief Architect for enterprise has yet to be established in any meaningful way and has challengers to that title.  Books like “CFO, Architect of the business” are popular fair in the book trade.   And why would a COB/CEO/COO create such a role if they feel their role should be that, even if they don’t have the necessary architecture skills -after all they climbed to the top and are thus “entitled” to wear that crown.   However, it then gets back to a view of what an architect does/is.  Two schools or architecture: Architect as Decision-Maker, Architect as Facilitator/Advisor of Stakeholder’s Vision.

If one looks at chief design roles in other disciplines which have had more time to mature you’ll discover that such roles take years to develop an understanding beyond the mechanics of the discipline and how it fits in context beyond just building something.  This the senior role-holder must have a broader background than just Agile Development, DFD modeling, etc. and needs to step out into understanding the enterprise as a living organism. My recommendation is to study the Cybernetic Hierarchy in General Systems Theory to get beyond “Frameworks” and “Clockworks” through Adaptive/Dynamic Systems to Transcendental Systems.  These later types of systems capture more than frameworks do.  However with increases of information, increased thinking time is required to understand such data; something executives are in short supply of these days.

Follow

Get every new post delivered to your Inbox.

Join 463 other followers