Monthly Archives: September 2017

Sep 20

Driving Strategic Direction

Posted on by

I have been branding myself with the tag line “Driving Business Strategy with IT Strategy,” so it seems that I should talk about how IT strategy can drive or enhance the overall business strategy.  My previous post on strategy talked about creating a new product line that the company could sell, and thereby generating an entirely new market.  Although we were building it anyway, it became a new capability driven by IT that changed the overall strategy of the business.

In this post, I want to talk about a somewhat different situation.  A mature and solid, large company that I will not name lest their Reputation Bots swarm me, makes hardware and software components for the Freight Rail industry.  Among the reasons I was hired there was my deep knowledge of Positive Train Control (PTC), a critical project in that industry.  This company did not make PTC components, but did make the locomotives on which they were installed, and many components in the locomotive network interacting with it.  Not only did they not make PTC components, they had made the affirmative decision  to avoid offering those components.

In the course of my other duties, I just happened to learn that a key technology foundation of PTC was being deprecated by the vendor in around a year.  This naturally caused a rather large concern within the Freight Rail industry as it was the backbone of the necessary interoperable communications.  Other vendors to the industry provided the components that used this technology, and they suffered from a terrible reputation for quality and service – two of the strengths of the company I worked for.

The company had avoided this market originally because they did not have the in-house expertise to develop the necessary cards and software – a lack they had remedied over the years – and because they did not want to assume the safety liability – imagine two trains colliding because of a bug in this software and killing dozens of people.  Current vendors in this space were protected from that liability by simply being too small to pay any judgment, so they would go bankrupt.  This company had deep enough pockets to need to pay out any liability judgment.  They were, however, familiar with this level of liability as their engines keep passenger airlines in the air.  The real question was: Would the market generate enough revenue to be worth the liability risk?  I took on the task of finding out.

I will not reveal details, but the total market was over 9 figures in 3 years.  That was enough to justify the liability.  The technical hurdle had been solved over the past 4 years.  It would be a very hard project, but the payoff was there.

As I was building the business case, the original vendor of the backbone technology decided not to revive the product, but to extend the maintenance of it another 3 years.  This did not remove the problem, but it made it less urgent.  When I presented my findings and plan, my company decided to use this development as a reason not to pursue the new product line.

Now, let me set the ambient environment.  They had staffed up based on a projection of 20% or more revenue growth per year for at least 4 years.  Instead, they had just lived through a 20% down year and current revenues were indicating yet another 20% decline.  A 9-figure new product line would have erased all that.

IT had developed a new capability that could generate a previously untapped revenue stream in a critical time when they needed it – IT Strategy driving Business Strategy.  Unfortunately, those in charge of the Business Strategy could not see it.  End result?  Significant layoffs making news.  Their competitors may not be so short sighted.

If you are from the company I carefully avoided mentioning, please do not sue me.  Like those other vendors, I have no way to pay a judgment – and these statements are simply my personal opinion and reflect the official position or opinion of no one else on earth.

Sep 14

Strategic IT Thinking

Posted on by

When I started my MBA, one of the goals was to move from a Tactical thinker to a Strategic thinker.  The career coach they assigned me surprised me by pointing out that all my assessments said I already was.  I thrived in the three strategy courses that Georgia State University had in the curriculum for our Executive MBA class and began to see what he was saying.  I had moved into the strategic realm for a few years by that point without realizing it.  But how do you explain to an interviewer that you are strategic?  Perhaps with stories?

I think the best example is one of my “Bet the company” or “burning platform” stories from a while back.  The software house I was working for at the time, managing a branch office, had a single product.  A vertical software suite for managing fleet and facility logistics and maintenance.  It sat on top of a dying (burning) platform called SPEED II on WANG hardware – has anyone heard of these anymore?  Dead.  In the death throws of this platform, the company could no longer sell its only product line.  It had to migrate, and fast.  The president of the company flew up to my branch and asked me to lead the project to re-platform their application suite onto a new technology.  One that was completely incompatible with their existing platform.  Sales had dropped 90% and they needed a new platform NOW.  So I came down to lead that project.  Still tactical, right?  Yep.

It was a massively complex project and I had about a quarter (in the end a third) of the company working for me on it.  We had to figure out what the dying platform was giving us that the new platform currently could not, how to build those features, then how to automatically convert the very large code base into that new platform.  This is the product that became Xponent – a case tool now in use in 56 countries.  But wait, the goal was just to re-platform the vertical application…

Along the way of building this new platform, I saw how we could make this a marketable tool that would save other software vendors in the same situation.  Our tool could either become an in-house proprietary tool for building the flagship vertical product, or it could become a product in its own right and provide an entirely new revenue stream for the company.  But in doing so, would we enable our competition to beat us at our own game?  I looked at that and decided, no that would not happen.  None of the other software houses played in our company’s market or had the deep expertise to establish a solid enough reputation to sell it once built.  So the company went from one dying product to two marketable products – one slightly crippled as it took time to evolve to the new platform, and a vibrant one with a small but hungry market – and completed first commercial ship of both products in 9 months.  That, to me, smells like Strategy.  And this was a decade before my coach made his “odd” comment.

This sounds like bragging, but the company would not exist today if I had not succeeded in both products.  I do not mean to imply that I am the only one who could have saved the company, it was full of bright people or they could have gone outside.  But the success of my project did save the company.

Sep 07

Crisis and the Blame Game – Stories from the Cauldron

Posted on by

Over my career, like many of you, I’ve had to manage crisis situations.  The “Customer” database goes down and the company cannot process a single transaction involving any customer – online, on the phone, in person…  An earthquake destroys the data center…  Everyone’s had their moment in that critical spotlight.  I thought I would take a moment and illustrate some of the approaches I’ve learned over the years.  I do not hold myself out as a shining example of a crisis manager, but these tools have served me well.

Manage Your Stress

A crisis is by definition stressful, and some people handle stress better than others.  A friend of mine long ago told me a story that I re-play in my mind whenever I feel the stress getting too high.  I also use this story to mentor others on managing their own reactions to stress.

My friend was a part-owner in a software company in South America (that he referred to as a Banana Republic).  They had made the mistake of bidding on, then winning, the job to process the election results for President of the country.  It’s election night, the polls are closing, and the software is not working.  In walks the current President, with his machine-gun toting entourage, saying “I need to know if I’m going to be President tomorrow.”  Then he points out the window, saying “You see all those people in the street with their Molotov Cocktails?  Their pretty interested in the answer too.”

Now I embellished the language a little bit to make it more “pithy”, but the situation was quite real. The potential for a civil war, people will die, if your software doesn’t start working REAL soon.  THAT is stress.  The fact that your company is losing a million dollars a day because the website can’t take customers is, by comparison, NOT.  It also keeps me thinking that I’ll make better, more rational decisions, if I don’t become overwhelmed.  That will resolve the situation sooner as well.

Oh, and my friend?  He “managed” his stress well enough to get the software working so that they had a result 2 hours after the polls closed.  He never did tell me who won. (smiley).

The Blame Game

It is a common reaction (I won’t use the word “normal” for this situation) to begin a circular firing squad in a crisis.  It’s not MY fault, it’s YOURS.  This accomplishes nothing except delaying getting to the solution – even if you have found the right person to blame.  I was on a disaster conference call with that “Customer Database Down” situation where the company was losing about a hundred thousand dollars an hour.  The round-robin blame game started.  When, after two minutes, it was clear that it showed no signs of stopping, I raised my voice on the conference bridge.  “Enough.  It’s all my fault.  I caused this.  Blame me.  Now let’s start figuring out how to fix it.”  15 seconds of dead silence was followed by “well, has anyone thought of this idea?”

Blame has no place in crisis resolution.  Save it for the Lessons Learned session after normal operations have been restored.  Even then, blame the process that allowed the mistake to occur rather than the employee who made it.

Creating Order from Chaos

A crisis easily devolves into chaos unless the team is well practiced in dealing with crises.  If they are, then crises likely happen way to often.  Beyond solving the immediate problem, preventing its recurrence is a secondary priority – but one that is often lost in the chaos.  Attempting to instill order or process during the crisis is often as counter-productive as the blame game, the wide-ranging creativity that results from an unusual pressure situation is needed.  During the fire-drill, however, the critical gaps and flaws in normal processes that allowed the crisis to occur can be glimpsed – and missed if not noted contemporaneously.  These are the best possible fodder for the “Lessons Learned” meeting afterwards.  Don’t ignore them, scribble them down somewhere for later thought.  One or two might turn into a rabbit hole later, but there will be gems in there.

Common wisdom has it wrong – Focus on the problem, not the solution

It is common for a theory of the problem to emerge and most everyone gets focused on solving for that theory.  Some percentage of the time, that theory will be true and the problem solved quickly.  Some percentage of the time, that theory will be wrong and all the time spent on the “solution” will be wasted.  When a team is working on implementing a “solution”, make sure that there are others on the overall team who work on the assumption that the “solution” is false and more investigation is needed.  Look everywhere EXCEPT where the solution team will be looking.  Have no pre-conceived notions.  Assume this is the first-ever occurrence of whatever caused the crisis and that it is something no one on the team has ever dealt with before.

There are many other good tools useful in crisis situations, but I’ve written more than enough for today.  No one wants to go to a blog and read an entire book.  I am also sure that readers of this article will have dealt with other types of crises with other types of tools – or even run into situations where my tools would be worse than no tools at all.  I hope you will share those experiences, I’d love to learn from you.