Moderm IT Portfolio Management Workshop

Reaching the end of putting together first of several Modern IT Portfolio Workshops.  Will bench check next week 🙂 .  Have a fairly good assessment of major competitive Frameworks from Microsoft, IBM, etc.  As expected each these looks at Portfolio Management as a Zero Sum Gain stack ranking algorithm in isolation.  However, that was the goal behind developing those methodologies so “they could grab the low hanging fruit”.  Next week’s research and development efforts are to further develop COBIT 5’s “Enterprise Governance of IT” concepts and create the alignment workshop materials.  This weekend I’ll get back to diagraming the overall master process, document the interfaces between the processes, artifacts, and outcomes.  I’m using a similar structure to the Strategy and Market Planning process documentation I used before to create that practice.  The major difference this time will I’ll most likely use SharePoint and/or MS Access as the implementation vehicle.  Had considered Azure over the past several years, however, my resources are limited and since separating from Microsoft recently I don’t have the funding / resources to build there.  I’ve a friend who left Microsoft years ago who has his own company and platform that may be a potential, but it looks to be a learning curve I’ll have to go through on my own to use it.

Modern IT Portfolio Management Methodology

I’ve divided Modern IT Portfolio Management into four major activity groups.  Each group has methods associated with it as well as linkage to corporate functions.  This will enable the process to be integrated into how a corporation really works rather than a blistered on event to the IT budget allocation process as so many of these Portfolio Management methodologies are used for. An example the Prioritization Group takes into account Corporate Values, Goals and Priorities, Enterprise Business Continuity, Disaster Recovery, and Risk Management.  This differs from standard approaches in that instead of evaluating “new technology” investments, tis method evaluates the entire portfolio.  The goal is evaluation of ALL investments as these relate to the Enterprise’s mission and determine one of three several actions: Divest, Hold/Maintain, or Invest –its back to the roots of Markowitz’s original treatise on Portfolio Management.  Additionally, where this methodology is differentiating from the rest of the market is the items managed in the portfolio.  The asset classes (Markowitz) go beyond the simple Software and Hardware (physical assets) into abstract assets that could be considered derivatives and other complex investment vehicles.

The downtime away from supporting the Microsoft Communities has been trying,  I really liked helping the field: It was great to hear back from those on the front lines; “thanks that really helped” or “take a look what I achieved with the materials you pointed me to” or “my customer is really is really pleased with the results I got using your approach”.  Getting feedback like that is addictive it makes you want to help more.  However, after a month away I’m at peace with myself and focused on this and others lines of Enterprise Design R&D.  I’ll still take on a few people to mentor each year, but not to the scale I was building unless I determine to start my own consulting firm.  I had considered that several years ago, thinking joining another startup firm to help it develop would allow me the same experience and freedom.  However, the direction the partners were taking verses the stated goal were decidedly different.  Still in touch with those partners and despite some challenges the company is doing fine in its new reconstituted form which I’m happy about.  I wanted to see them succeed, as I want to see other small businesses do.  There is something really cool about a small business.  I think I may be the personalization aspect to it.

Structure in Threes: Integrating Finance and Engineering approaches to Risk

As I continue researching risk elements for designing and enterprise, it is interesting to see how implementing risk management translates differently depending upon your discipline.  Finance focuses on of course financial risk; the various forms risk takes with regard to translating investments into returns in a monetary sense.  While engineering disciplines focus upon risk that effects the degree of achievement to performance goals of a product or lately service.  Both disciplines acknowledge the others concerns but often do not provide the linkage between these.  Finance will often categorize engineering risks into buckets called operational and strategic/business risks.  Engineering will lump the various economic risks into a single bucket called financial risk.

This is mirrored in how Business Continuity/Disaster Recovery(BC/DR) and Enterprise Risk Management (ERM) are implemented in most corporations. The BC/DR practices focus on the engineering risks of project, process and product, while the ERM practices direct attention to the financial aspects of the enterprise.  What seems to be missing is the linkage between the two.  The interrelationship between the two or cascading effects appear to be a neglected concern.  This maybe due to the nature of our western culture or increased specificity of roles within corporations even in white collar positions now.  The role of the generalist or systems thinker has been diminished or dismissed or possibly transformed.  More and more of my systems thinking peers have become entrepreneurs, possibly because they do not fit the new organizational models or appear to be in direct competition with mid-level management.  This is odd in that first line and mid-level management no longer have the time to consider various degrees of consequences of actions and decisions or alternatives, but is the stock and trade of systems thinkers.  This may be one of the root causes to several of the catastrophic failures of the economic system, geo-political relationships and technology achievement misses.

Today’s research continues down the path of system dynamics and identifying the linkages between financial and engineering risk management.  It may turn out that there is no true mathematical formula that links these and the best that can be achieved is to use Bayesian logic to create priorities for a balanced scorecard that reflect enterprise values and then monitor how these correlate to the ecosystem.  Which brings me back to using system dynamic models and validating these with actual performance in the real world.

In my opinion , despite the emergence of BI and Big Data, application at this level is still years away.  The majority of enterprises and thought leaders are still at a primitive level when thinking about exploiting such technology.  Think of how sophisticated and how long it took to apply various influence and behavior models in the marketing community.  Then consider the effects of having too much information, creating an information glut.  While computers are great at dealing with volumes of data, we humans are not.  We still need to deal with the limits of cognition.  Despite all the hype about multi-tasking, the facts are coming out, something is lost when you try to focus on too many tasks at once.  In fact you’re not actually focusing on them at once, you are switching attention between them rapidly (page swapping) and eventually you either reach a limit where you get nothing accomplished or a catastrophic event happens: Texting while driving during the Grand Prix is not a good idea.  What this suggest is that it will take a long time to really sort through BI and Big Data’s potential into something practical verses creating more noise in the enterprise system.

Structure in Threes: Risk Management as a component of Portfolio Management

Continuing to research risk management as a component of the Modern IT Portfolio Management methodology this morning.  Starting to investigate unexpected loss and uncertainty aspects.  Will be rereading Shoemaker’s “Profiting from Uncertainty”.  Looks like the financial risk management risk research I’ve been doing, is confirming the Real Options application research to portfolios I had previously developed two years ago.  The key element that most of the PMP risk management activities track are around identifying and managing known risk (expected loss).  Typically, this is not the area that causes the most problem unless the risk management plan is just pencil whipped (i.e., just a form competition exercise).

Ensuring that both expected, unexpected, and cascading or interconnected risks are addressed as more than just a side activity is a cultural aspect I’ll need to add to the adoption section of the book.  I expect similar aspects of adoption management I used before for Strategy and Market Planning process deployment will be used here.  I’ll relook at Kotter’s, DAGMAR, and ADKAR models for change next month when I detail out the adoption management methods and chapters.

In the meantime I’ll go back to researching risk today.  On today’s agenda is investigating process failure risk components and cascading risk and failures.  The later, cascading failures, should be more application than primary research, as standard engineering practices such as FMECA, RCA, and FEM have network analysis frameworks that I’ve adapted before with great results..  Right now I really miss all my White Boards.  I’m looking into a paint that turns walls into white boards –it would be great if I could get touch displays the size of walls.  I’d really build a think tank 🙂

Structure in Threes: Risk Management

Early wakeup this morning.  Researching advanced risk management practices for Modern IT Portfolio management workshop.  Interesting to review previous company practices in the area and how disconnected these are from strategic and project planning.  While the simple models make calculations easier, they also lull staff and executives into thinking they’re covered what’s necessary.  Tomorrow I’ll add risk management justification points to why Portfolio Management section of the workshop and continue to integrated the risk components into the Portfolio methodology.

Using SharePoint to enable ITIL: Consequences of unmanaged services

Since technology appears simple to operation the assumption is that it’s simple to build and manage.  What isn’t seen by end-users today is all the complexity behind a product or service.  The consequences of operationally mature, technically naïve stakeholders and end-users are having to justify investments in information technology.  While it’s not unreasonable to ask for such, it’s difficult due to the complexities and variables of how the services are created and used.  Adding to this complexity, the financial measurements and analysis is still an immature field.  Accounting systems only within the past few decades have started addressing services and other abstract assets.  However how to measure benefits still raises strong disagreements between CIOs and CFOs.      

In addition the expectation of I.T. Services is that they are as stable and reliable as other mature services telephone, water and electricity.  As a result organizations have moved past I.T. as a “tool” that is adjunct to how work is accomplished and have or are weaving information technology into the very fabric of the business and in some cases integrating I.T. into the products and services they deliver.  Two examples: First look under the hood of any automobile lately you’re faced with a mass of connections, even that mechanic that tune up your car now plugs it into a diagnostic computer.  Second want to deal with the government or a financial institution, you’re likely to either go online for forms or visit an ATM.  When was the last time you actually saw and spoke to a teller?

The level of integration of computer technology has skyrocketed and with it the dependency upon services hosted on them via various network connections and backend infrastructure, including the people that support all the onboarding, operations and creation of these services.

Thus this dependency has created increased risk.  United Airlines recent reservation systems outage cost them dearly, not only in operations costs, but good will, penalties and legal issues from passengers denied access to their flights.  An estimate of the damage has not been publically announced but you can be sure it was significant.  

Without a good handle on managing services I can foresee a day when a business fails due to service interruption or I.T. failure.  Imagine how long it would take Amazon to crash if its infrastructure failed.  For Amazon, I.T. failure cannot be an option, they don’t have a physical storefront and they are totally reliant on technology to point them to where the closest inventory is to fulfill and order.  I would expect a 12 hour failure like United’s would be deviating to the bottom line.

I.T. Product and Service failures could in the future lose the shield from disclaimers and fitness of use loopholes.  The end user licenses that have been used to limit liability may eventually be used as evidence that the product is unsafe or unfit to be sold or that the company has engaged in false advertising.  Thus I.T. Management may have legal exposures similar to Senior Corporate Executives via SOX and GAAP regulations.  

Some of these service issues have gotten management mindshare and attention; witness the strong efforts around I.T. Governance and service delivery models.  Still other efforts to cobble together some form of service agreements and measurements.

While customers (internal and external) are judging them on their own performance criteria which may or may not match up to Service Level Agreements (SLAs) these organizations have stitched together often on criteria that customers do not see and therefore do not measure against  [i.e., network or server availability vs. service availability –what good is either to measure if they are not in sync to allow me to utilize the service e.g., the server was up 20 hours a day and the network was up 21 hours a day, however combined the complete service that required utilization of both was up only 18 hours (only 1 hour of the network outage overlapped the hours of server outage).  Server and Network availability where reported a poor 84% and 88% respectively, however the Service Availability the customer experienced was a dismal 75%.  That’s a quarter of the time a customer cannot use the service. Think of it as one in four times you go to use your car it wouldn’t work or worse yet, 6 out of every 24 hours a plane flies it just stops –hope you’re not over the Rockies during that window.  

Thus the consequences of having unmanaged and poorly managed I.T. services are increasing.