Joy at work

Spent most of yesterday focused on creating a draft of a slide deck.  Previously I would hurry through creating a deck.  However, now I’m having to slow down…because I will not be the one presenting to the executive committees.  So I will not be there to answer questions or bridge the gap in logic.

Over the decades I’ve loved to give presentations on the fly (Chalk Talks) as they seemed more dynamic, interactive and honest.  You’d get to address the areas of topics your audience had rather than a predefined path and conclusion.  It was more exploring the area together.  At SharePoint Saturdays –though I had a slide deck that covered the topic, I won’t follow a script– I’d typically have more “Actor’s Studio” dialogs with the audience as one reviewer put it.  I prefer dialog to speeches I guess.  However, in my role now, I have to ensure my team gets the message across accurately to Executive Management.  So spending time crafting the story and message is more important as the windows of time is so short.  It goes back to a comment I made on Facebook to a friend.  The joy in a job or role derives from developing the precision in executing it more so than the financial remuneration.

Business Theory

Spent morning looking at Theoretical Physics videos (String Theory, M-Theory, and the like).  I know some of my co-workers will question the value of such and ask how do these relate to “real work”.  However, its that cross domain thinking that brought ideas like OOP, Active Directory, etc. into the IT realm.  With all the business architecture and business theories floating around I’m still looking at how I piece these together into a coherent system that allows for another seeming paradox [logical design that includes emotional factors].  I often see the dilemma that business researchers face: an calculus of design that should work, only to be destroyed by human factors.  Consider products that should have been successful earlier: computer watch –which is now all the buzz; PDA which morphed into the Smartphone; etc.  Technically the predecessors to these should have been successful, but something just didn’t click.  One can point out a lack of a single factor and say without this feature … however, how does one explain the Edsel which was an advance to then current industry products.  There is something emotional -which marketers, social network researchers and now Data Scientists are trying to understand.

I had a discussion with a collogue last week regarding patterns –data science, machine learning, etc.– while pattern matching is useful, its results are not always correct as “we” the observer overlay patterns on what we observe.  These patterns we detect maybe just that a coincidence, not a intentional or guided structure.  In other words: “correlation is not causality”.


-anyway just insights for me to muse over during this morning’s coffee.  How I apply such to the Enterprise Architecture Methodology I’m writing about is still a TBD.

Book Title(s) and messaging insights

Started to rethink the title of current book project this morning during drive into work.  Structure in Threes maybe too esoteric for some.  Considering “Discussions” as that is what all the tools and techniques in the book are designed to provoke.  I had a few colleagues weigh in on all the methods I’ve been documenting.  One comment was that he didn’t think a prescriptive approach to Enterprise Architecture was viable.  I was rather surprised at the comment given all our discussions that these are visualization tools that help decision makers see what they are talking about and/or see the results of decisions before these are put into place.  Just goes to show you that old maxim about remembering only a small portion of what is said is true.  I’ll have to add a chapter up front on the importance of discussion verse prescription to ensure my audience gets the point of the book.

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).

Methods: Designing a new Service

Had a great brainstorming session yesterday with a colleague discussing how to apply DSM techniques to the Service Design activities we’re involved in. [Going to have to update my methods PowerPoint again]  Came up with using DSM to identify and cluster functions across various customer requirements and then a simple prioritization using Risk DSM and Business Impact [ Risk * Business Value = Priority ]

Brainstorming DSM

Clustering activity is initially based on common functions. These are later categorized into one or more basic causes using Fishbone (Iishikawa) diagraming and 5 whys:  Capability, Capacity, Schedule, and other.  The context is total throughput (i.e., “The Goal” ).  This sets the context to prioritize which areas to address first.


Afterwards I when to my whiteboard to draft a model of the service I’m working on using Osterwalder’s Business Model Canvas.  Once I summarized the Business Process models I created before and extracted key components, it became obvious that the context needed to be changed.  The business in a business model context yielded some strange relationship issues.  Once internal supplying and receiving groups became Key Partners everything snapped to the grid perfectly, even then cost structure and revenue stream categories which are often hard to identify in internal business models: especially in IT where chargeback is often applied inconsistently.

Business Model Canvas

Modern IT Portfolio Management: Risk: System Definition

System Definitional Risk

One of the serious risks in Architect side is system definition. This is partitioned into completeness(e.g., maturity level [none to integrated], Validation level [none, author’s bench check……Simulation of requirements], and requirements freshness (i.e., things change, was what was needed specified and validated too long ago….).



Modern IT Portfolio Management: Risk Modeling

Applied R&D for rating interdependency risk almost complete this morning.  Models will work well from my reengineering project at Microsoft.  In the DSM model I adapted NASA’s model that uses interdependency and technology maturity as primary factors.  Multiplying the scales for each factor yields isographic map of the range of risk which is translated back to a simple scalar range for presentation.


Interdependency Risk DSM Model


Get every new post delivered to your Inbox.

Join 455 other followers