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

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.

Follow

Get every new post delivered to your Inbox.

Join 445 other followers