Forces that influence increasing IT Economics maturity

The maturity of resource allocation of most IT organizations are typically less than the resource allocation maturity of the enterprises that host these.  This is not a surprising finding given people and groups usually adopt the norms and behaviors of the context they are surrounded by.

For an IT organization to increase it’s Economics Maturity it needs to address the concerns of its host.  This suggests stakeholder analysis and managing expectations is of significant importance, possibly more importance than the level of precision of the actual economic justification.  Texts on decision analysis  indirectly discuss this phenomena.

One strategy to mitigate this issue is to choice the appropriate level of methods for both decision and organizational decision maturity.

Many organizations often in an effort to expedite decisions either choice methods that are too simplistic.  This can result in decisions that don’t address the nuances of the problem or are not repeatable as inputs and influences to the decision are not explicitly, hidden in pockets of subject matter experts or decision makers.  The other alternative are decision processes that are overly complex.  Initially the rational of these complex processes is to provide a comprehensive system for making decisions.  Where this often goes wrong is that the process becomes the standard and dogma for all decisions.  Thus creating a bureaucracy for decisions.

A possible remedy for this unintended consequence is to develop a  series of decision processes at different levels of complexity and guidance as to when to use which.   While it can be argued with the information technology one all encompassing process can be created and automated thereby reducing the overhead in these processes making them easier to execute.  The problem with such a strategy is that it neglects that the decision maker still needs to understand the attributes and variables to make an effective decision.  For a complex decision there are not only multiple variables but typically require time to digest the interaction of variables.  Using a similar process for simple decisions places undue delay.

Another strategy is to create a decision team composed of the stakeholders, guide them through the development of the economics case themselves.  This has several benefits.  First it helps raise the knowledge level of the group.  Second it help build confidence in the methodologies used  as they develop experience.  Third, an open discourse explicitly raises concerns of stakeholders to be addressed.

Visual Thinking

This morning I started reading “Turning numbers into Knowledge” by Koomey; an interesting book gear more towards academics and researchers than typical knowledge workers.  When I say geared, it’s the style and tone of writing more so than the information contained within.  The book presents a how-to organize your problem solving.  The small amount I’ve read so far had me thinking about the problem of problem solving and if in the scheme of issues it ranked high on an organization’s the Pareto List of critical items to address.  Combing through my various graphical notes

–I typically create diagrams and sketches for notes rather than text; I had found visual note taking and thinking to be more information intensive than typical text when I was studying architecture.  This was later reinforced by a business associate, Eileen Clegg; I met at the Congress on the Future of Engineering Software (COFES) several years ago.  Her company Visual Insights is a welcomed regular fixture at this annual event.  I think the one year she missed attendance there were several people, myself included, asking why.  Many of the Engineering and Engineering Software community’s best; the most creative, innovative and productive are visual thinkers.  I can’t recall a single member of this esteemed group that didn’t have to have a whiteboard or some graphical tool suite in order to think or relate information during our conversations.

At first I thought it was because these were complex topics with lots of detail, which each could be.  The diagrams and pictures though were for the most part very simple, no more than a few simple lines, circles and arcs, etc.  However, like the Chinese saying “One picture is worth a thousand words” these minimalist sketches were very dense in the information they chaptered and represented.–        

 I bring up graphical notes as to indicate that during my career, as I’ve taken notes, I have captured in my graphical journaling much more details than just the issue that was to be address at the time.  Many times I would capture the process of how the group solved the problem or made the decision.  The various projects I’ve been involved with regarding reengineering processes for Rockwell, Boeing, Microsoft, IBM, Samsung and a host of small companies has introduced me to multiple graphical techniques.  Even as I write this post this morning I find myself drawn to mindmap my thoughts as opposed to writing out these ideas.  Writing –as skill I’m trying to improve upon these past few years—is basically one dimensional while my thinking in multidimensional so relationships between concepts are lost in translation as I peck out the words.  Thankfully Hypertext had been created, so I can come back at a later date and establish those relationships.  This has become a long way around and may still have some missing links between my initial thoughts and the insight below, but I’ll come back at a later time and address that bridging issue.

 What I discover –again, which was the rationale for creating Intellectual Arbitrage Group—was that most problems companies are addressing are the same.  What makes them appear different is the context in which they live.  The majority of the activity people in organizations perform is not really deep problem solving but daily searching and translation to the context they’re working in.  Some of the interesting issues around that is identifying the core solution set.  Often because problem/solution pairs are not well documented, people will take the closest solution metaphor at hand to use.  This from my findings is one of the root causes of project failure as opposed to technical failure.  So the end results of many projects are technical success but not achievement of business objectives.

 The cause of this misalignment and how to avoid such will be the topic of future post as I continue to diagram out a working Information Management Methodology.