Blog 11: IT Strategy

IT strategy is probably the most often overlooked activity for non-IT leadership in pretty much every organization I've been a part of.  They just don't care.  They want technology to be always available and they want it as cheaply as possible.  IT is a "support function" that only exists to enable the parts of the business that make money.  I think historically, this has been true, but it hasn't been for quite a while now.  Truly successful businesses will recognize that IT needs a place at the table when important decisions are being made.

Yes, I'm biased, having worked my entire professional career in IT.  I understand that most non-IT folks don't fully appreciate what it takes to keep everything running smoothly.  My guess is this is a direct result of the proliferation of consumer grade computing and networking gear over the last 15 to 20 years that gives enough of a familiarity with the technology to make assumptions like my home network runs of a $50 Linksys from Best Buy, why can't the enterprise network?  Or my home cable modem is $75/m for 100Mbps...why do we pay $6000/m for a pair redundant 100 Mbps MPLS circuits?

Now, I certainly don't expect everyone to understand the differences in those two examples and I actually rather like that those questions are asked.  It's never good to become complacent and challenge all parts of the organization to do more with less.  That said, when it comes time to fund IT maintenance activities or replace older technology...it seems like everyone involved is anchored on the lower perception and every budget dollar has to be fought for.

No business function can exist in a silo.  As high of an opinion as the sales team has for themselves, they can't do it alone...no business function can.  But unlike accounting or sourcing or HR, the ability of IT to create business value has been growing exponentially over the last few decades.  IT infrastructure and services permeate not only all business functions, but also represent an interface with external customers. It seems crazy to me that IT is still excluded from strategy discussions in some organizations.

Blog 10: Measuring EA

I love this week's topic because it isn't even specific to EA initiatives.  It's something not a lot of people think about.  Most folks seem to focus on quantifying/tracking a business statistic...but what they SHOULD be doing is validating the action that they THINK is causing the metric to change.

It is a very rare occurrence to have a situation with only a single variable.  More often it more complicated or multiple variables acting in concert, sometimes with odd synergies that can be very difficult to determine.  Did sales increase because the engineers added a new feature to the product or because of the marketing department's new social media add campaign?  Was it both?  Perhaps neither, such as an external factor, such as a distribution issue with a competitor?  It's easy to reduce a complex system down to a simple cause and effect, but my ultimately be a lie.  And you can bet that while both marketing and engineering were patting themselves on the back and each taking credit for a positive trend in the metric, they both will be distancing themselves from a negative trend!

I read Eric Ries's "The Lean Startup" a few months back and he actually talks about this at some length, in the chapter titles "Measure."  True this is specific to measuring success (or failure) in a startup environment, but these concepts translate over to EA.  He says that metrics should be "actionable, accessible, and auditable."

Actionable - the metric should demonstrate a clear cause and effect
Accessible - the reports should be well understood by the viewer and not require explanation
Auditable - the data should be consistent with reality.  The results of an automatically generated report should be the same as a person asking customers questions.

The parallels with EA are pretty clear.  The first question leadership is going to ask when pitched an EA plan is going to be "How will this make us money?"  The second is going to be "How do we know EA is responsible for our success (or failure!)"

Ries, E. (2011). The lean startup: How constant innovation creates radically successful businesses. London: Penguin books.
 

Blog 09: Governance

I don't think I've yet met anyone who enjoys the governance aspect of the business.  It's almost invariably seen as a necessary evil, something that's required that costs more resources than the value it generates.  The documentation involved is often loathed as needless "busy work" probably because (at least in my organization) all of the supporting forms and workflows and meeting rhythms that have been developed to support it.   But what I've noticed about a lot of these support mechanisms, is that once they've been implemented, they are hardly ever revisited.  No one seems to ask the question:  Is there a better way to be doing this AND still be compliant?  So you end up with folks on your PMO's project tollgate calls or IT operations CABs who are more concerned with the administrative minutia, i.e. the letter of the law, while ignoring the spirit.  Something is wrong with your process when something is rejected and has to wait a week until the next call because a file attachment on the form used an improper naming convention.

Stuff like this makes me shake my head.  It also reminds me of the most probably apocryphal story of  the "Five Monkeys."

      
I guess the lesson here, is yes, governance IS important, but never lose site of your goal.

Blog 08: Mergers & Acquisitions

I've mentioned before in previous blogs about how I used to work for a P&L within my current organization that had 24 different ERP systems.  This was not an exaggeration.  They ranged from Oracle, DB2, SAP, a hacked together system using the 1996 version of Apple FileMaker, and my favorite: A 30 year old system written in FORTRAN and running on DEC Alpha hardware that still occasionally throws errors that say "If you see this, call Bob." Bob retired a long time ago.

Most of you are probably slapping your heads, I know I did when I first discovered this. But to understand how their IT got to that state, you have to understand how that organization became an org.  When the parent company decided to make a strategic entry into an industry they had no presence in, they began acquiring companies. Word got out and soon other companies were acquiring smaller firms, in the hopes of making themselves more attractive to be bought.  Let's just say that the integration efforts in those cases was...not good.  So, as you can imagine, this situation is the first thing I thought of when I read the section in chapter 8 on managing EA through mergers and acquisitions.

It wasn't just the IT ecosystem that was fragmented.  The rapid string of acquisitions had a lot of the personnel on edge, as many folks were let go to avoid duplicate roles.  In the IT space, everyone thought that the way their legacy organization handled things was the ONLY way to do things and there exists even today some animosity between employees who were around during the time of the merging.  There was a lot of fighting, a lot of strong, differing opinions. Now, almost 15 years later, they are down to a single ERP.  Basically.  There is still an old OpenVMS system hanging around in read only mode due to containing information that must be available for regulatory reasons.  The more tenured folks still complain that the ERP system isn't as good as their home grown FileMaker solution, but there is peace, more or less.

This is why I firmly believe that effective communication and managing change is the most critical piece of EA.