Portfolio Management Insights: Opportunity Gap

This morning’s R&D had me reviewing some previous work on Expected Commercial Value calculations.  One of the flaws or should I say weaknesses at lower levels of Portfolio Management Maturity is a the assumption that delaying a project only shifts to the right when a project yields value.  This however is most often not the case.  When evaluating each project’s value for a Portfolio one needs to account for both NPV of funds expected, NPV of funds received, AND also a potential reduction is value received as a result of a short recovery period and project lifecycle.

Consider this first scenario: Buying a new automobile.  While the utility may not change on a new vehicle purchased towards the end of the year its market value certainly drops as one gets closer to the next model year.  Another scenario: The utility value is sensitive to when in the lifecycle a initiative is executed (e.g., having a large shipment of ice cream available for summer in New York vs. fall).

As such Enterprises with more mature Portfolio Management capabilities will consider this factor in portfolio decisions.

Opportunity Gap



Enterprise Portfolio Management insights

This weekend’s brainstorming and reading brought up some interesting insights.  So much so I couldn’t sleep and woke up around 2am with the following visuals in my head.

First of was a refinement? on Govindarajan and Trimble’s concepts about two competing engines within an enterprise in their book Beyond the Idea.  Their proposed model theorizes whay its so hard to get innovations deployed and adopted in existing concerns while startups do not seem to have this internal conflict issue.

Gravity Centers in Enteprise

Second was an idea I’ve been refining over the years; that portfolio selection is not just a single event but a series of filters applied to narrow down the pool to the portfolio member to actively work on.  There are lots of models on sections methods (BCG Matrix) Balanced Scorecard, etc.  What is common to all is a concept of sorting and filtering members into groups, which creates a group of members to actively work on.


Portfolio selection is a filtering process

While these are not likely the final visualizations of the presentation I’ve proposed for an internal conference in February.  The metaphors speak clearly to me; I wonder if they do the same to others?


Modern Enterprise Portfolio Management

Portfolio Management capabilities roadmap (initial) from last night’s brainstorming.  Planning (aspirational) to have Modern Enterprise Portfolio Management materials ready by February for a possible seminar at my home office over a holiday weekend.  The big question(s) will be if any of my colleagues and followers will be: 1) interested in attending a focused seminar, 2) willing to take the trek ~60 miles south of Seattle for a 1 to 2 day seminar.



Enterprise Portfolio Management CMM Roadmap

The nice thing about this research is I can leverage it as source materials for current projects I’m doing at work and for internal technical conferences.

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.

Project Trajectory Analysis and Risk Assessment

Spent part of yesterday reviewing one of the projects I’m on to analyze the risks and trajectory its on.  Part of this analysis brought up adapting an old technique my father taught me when he was managing large defense projects. It relied upon the law of large numbers but still seems valid today given all the interdependencies.  Instead of tracking expenses which are shown in the example, I substituted level of effort (LOE) in mhrs.  Along with the trend line function in Excel I was able to project likely outcomes.  Added to this was the interdependence risk DSM(s) I has previously started using which indicated where the highest risk elements in the project would occur.  I’ve yet to add a social or influence analysis to the tool kit but expect to have that as another DSM.

Lite Weight Project Management Dashboard   Component Risk from interface type DSM

The one significant issue using techniques like such is bringing the team along with the insights: As some people will not get it at first, Others will think you’re being a negative person, and still others will want to argue the validity of the analysis or its inferences.  Presented in the light of discovery rather than blame helps (i.e., mapping out my understanding yields this….is this right?  If so what should we do about it?).  This only works however, if you’re in a ego”less” culture and those you bring up have a vested interest in the successful outcomes.  That is if they don’t see the issue you bring up as core to their success, they are unlikely to care to address the situation, even if its for the greater good of the company (Ref: Tragedy of the Commons Systems Dynamics Archetype).

Knowledge Sharing

Spent the morning writing a summary of current project activity for a newsletter.  The team I’m on is relatively new and we’re just starting to establish processes and procedures for sharing knowledge and letting others in the organization know what we do and how we can help.   During writing my first draft I attempted to ensure it would not sound like some cold grey, boring status report; the kind you read and forget while you’re reading it.  While I’m writing this blog to generate content for a book I’m going to write this year –I don’t consider myself a writer, which is odd cause I’m such a voracious reader– it came to me that maybe more community wisdom would be shared if teams were required to write project histories in a blog rather than status reports.  Writing a project history entry seems to have me consider relating more aspect than: Did x, Cost y, Resulted in z or On schedule, On budget or project is Green, Yellow or Red status.

The history entry has me consider what we through was the problem and approach, what we discovered, how we adapted and what were the results.  If one looks at status reports these always seem to be the bare statistics not the story behind what happened and why.  I find that a terrible lost opportunity.  While I’ve not been a fan of autobiographies or biographies –I find talking to people about how they accomplished something or overcame an obstacle more insightful– as typically the Bios or at least the one’s I’ve read where more colorful status reports, not covering the deep insights and learnings.  This little morning insight may have me reconsider reading biographies a little deeper next time to see if the author really did but their insights down on paper.

Process Modeling

Spent most of last night and this morning creating some generic {high level} Service and Change Management BPMN process models to customize for an engagement.  I’m particularly happy with the way the Change Control Board process turned out:


Change Control Process


Change Management Process


Service Management Process