DSM Risk Calculation for IT Portfolio Management

Completed POC using Design Structure Matrix for determining component risks in a system.  This example is more technology based than using process, organization, or composite (aka services) components.  However, the technique works well and will be added to IT Portfolio Management attributes

Component Risk from interface type DSM


Value Calculations:

Value Calculations for Portfolio Management as yielded this initial prototype based upon VA/VE discipline in mechanical products. The approach calculates value as a function of Need Priority and Ability to satisfy need.

Value Calculations

Architect’s Role

Had an interesting discussion yesterday with a peer.  He wondered why I’m still working and working where I am (Principal Business Architect)  when I could clearly take on a higher role.  The answer was quite easy…I enjoy the work and I enjoy helping other see the pros and cons of their decisions, so they can make better decisions.  In this age of multiple shades of grey; Decisions are about trade-offs based upon values.  My job is making the information and those trade-off explicit for the decision maker(s).   Some times that involves diagraming, some times making tools that manipulate and visualize information, some times just discussions acting as a sounding board or asking the difficult or avoided questions.  At the end of the day, when a decision maker or a group is happy with their decisions verses just satisfied that any decision was made (i.e., not really invested in the decision and its outcomes) or realizes they need to gather more information and explore more options as currently defined options are not satisfactory I feel I’ve done my job well.  –no applauses, not awards, sometimes not even a thank you.  But seeing my clients succeed is enough of an emotional high.

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.

Structure in Threes: Complexity and Portfolio Managment

Continued research efforts the past several weeks on applying aspects of complexity analysis to the business design project.  The past few days I’d reached out to N. Dean Meyer to investigate his concepts around businesses internal behavior is similar to the economics models in which businesses operate in.  Just received his book: Internal Market Economics, looking forward to a good read the next few days.

I believe this concept will fit well into the business design modeling and simulation suite I’ve been developing.  Next on my list is a reach-out to Wood, Hewlin and Lah (Consumption Economics), their assertion is around the change in business models in Information Technology from complex custom units to simple mass market services & devices or possibly a bifurcation of the market.  From my observations I believe this bifurcation is only a precision error, and that the market is becoming a broader spectrum of options (e.g., Complex Custom Units, Mass Customization, to Mass Production Devices & Services).

This will eventually lead to different price points in the information technology ecosystem.  Which will yield a more complex environment businesses to operate in and decisions that will be more complex.  Instead of a functional decision and then a cost per feature stage gate process a more nuanced decision process that will need to balance utility, acquisition cost, operational costs, opportunity costs and constraints with the various benefits these enable or inhibit.

Thus the requirement to add complexity analysis, lifecycle analysis (on multiple levels), and benefits management as components of an advanced IT Portfolio Management System -which in itself is a fairly complex decision management system.

For the purposes of piloting I’ve been modularizing each of these concepts into individual models that will be integrated into a single system.  This will allow for each model to be “tweaked” as desired.

The complexity formula I’ve settled on is a mashup of Jacek Marczyk

**Informational Elements and Activity Elements are currently derived fro BPMN diagrams

The complexity model is implemented in EXCEL at present.  The Economics Models are in process of elicitation; hopefully to be completed end of next month.

Benefits Realization

Been a bit busy stoking the home fires of late.  Attended COFES, amazing conversations as usual.  This month I’ve been focused on several areas of applied business architecture research.  IT Portfolio Management, Benefits Management, and Complexity Management.  All three are related to my Structure in Threes project.

  • I continue to develop the portfolio model section by section along with a working prototype.  Started considering the technology and system to offer to the market.
  • Benefits Management this month is really a parallel track, both R&D for ensuring a portfolio action supports Enterprise Goals as well as applied practice for the projects I’m working on at Microsoft.  The past few weeks I’ve been creating a Benefits Dependency Network for one of the subprojects.  I’ll be reviewing and revising that today with stakeholders as well as creating a draft Benefits Management Plan to help ensure the initiatives realize the promised benefits.  Part of that will be a Results Chain Contribution Matrix, a Benefits Distribution Matrix, and a Stakeholder Management plan.  Most of these artifacts I’ll recommend to my group for future projects
  • Complexity Management R&D is part of the BPR/M activities at work as well as Portfolio Management R&D.  Had a great discussion with Dr. Jacek Marczyk discussion elements of complexity.  We’ll have lots more to discuss.  I like his high level model:  Structure Elements x Uncertainty = Complexity.    I had previously separated Uncertainty from the equations I was developing:  Business Process Complexity =  {Information Complexity} x {Activity Complexity} using BPMN models as the base to calculate each factor.  As of yesterday I revised calculations from a standard node count bases to also include network linkages between nodes in each factor.   Later this week I’ll look at how I include Dr. Marczyk’s perspective of accounting for uncertainty.  I think I may also expand on that and use some of Courtney, Day, Schoemaker, and Primozic research into risk and uncertainty.  They’ve a lot of good materials that could apply to the problem space.

Structure in Threes: Budgeting and Planning -observations and muses

The beatings will continue until moral improves, or so goes the typical planning cycle each year.  Although being an observer of the process in many enterprises for 30 years and a unwilling participant at times, I would classify these activities as anything but planning.  These are more like the High School Senior Prom with all the politics and drama leading up to the final ceremonies.  Management spends hours of their as well as staff time building a case to justify their groups existence rather than actually looking at how and what to contribute to the enterprise’s bottom like.  Then having to “re-plan”  funding / headcount don’t match political expectations.

It doesn’t have to be this war dance each year.  Developing a real enterprise portfolio management system could remedy this, however, methodology zealots (aka methodologist, of which I’m sad to say I associate myself with) often get caught up in the minutia rather than the goes.  A joke I’m fond of telling during presentations when asked about strict adherence to any methodology might clue you into my worries about methodologies that too often become dogma:  What’s the difference between a terrorist and a methodologist? Answer: You can negotiate with a terrorist.

Much of the research and design work I’ve done over the years is now starting to converge:  Process Modeling (IDEF0 & BPMN),  Simulation and Analysis of systems (System Dynamics and Viable Systems Models), Digital Nervous System (AD), IT Economics ( ISIS, Information Economic/BEAM, REJ, and VRF) and now integrating financial Portfolio Management Concepts with VA/VE and Systems Engineering Concepts with the focus on designing enterprises like one would design any other product or service.  As I near competition of my basic research for Modern IT Portfolio Management I look forward to thinking about how to deploy and enable adoption.  Now that the basics of a digital nervous system are in place, its time to create the “brain of the firm “which I see is a portfolio management system connected to the DNS driven by people making fact based decisions.

The one caveat to using this approach is taking it too far, enterprises are composed of people as are markets.  And people are emotional, thus making decisions that address attempts at gratification for those emotions.  Thus Portfolio management needs to be applied with flexibility to not only accommodate this phenomena but exploit it in the positive sense.  Then perhaps budgeting and planning will be more of a constructive than destructive activity, creating intrapreuers in the company.


Get every new post delivered to your Inbox.

Join 445 other followers