Midwest IT Survival

Produce a Business Case Deliverable

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

In the second part of this series, we used an example of engineer Bob recommending his company invest some cash and resources into an operating system upgrade. The initial logical conclusion that a sequence of facts surrounding how awesomely technically cool the new OS is would convince anyone to make the investment. Yet, spewing facts isn’t as compelling as it is to:

Relate the facts and figures to senior management’s goals/vision

To do this, structure a presentation into a story following this sequence:

1. Describe the Current State including gaps/challenges/issues/problems
2. Describe the “Optimum” Future State
3. Describe the Roadmap to get from Current to Future State
4. Outline the immediate next steps to get started on the Roadmap
5. Throw anything ancillary or supporting to the above 4 steps in Appendices

In the Bob’s case, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Using the above sequence as a template for Bob:

1. Current State

• Number of servers running prior OS, server count over time
• CPU utilization
• Maintenance costs (total cost of ownership if it can be computed, support contract costs)
• Indicators when “bad news” like special support contract costs, etc. show “doing nothing” is a negative
• Intersection with any other projects that need capabilities provided by your Future State

2. Future State

• All servers running new OS phased in over timeliness
• CPU utilization
• Maintenance costs

3. Roadmap

• Upgrades broken into simple chunks
• Chunks representing some useful grouping (rather than random)
• Testing or other functions supporting the upgrade
• Costs over the duration

4. Next Steps

• $$$ approved to buy hardware
• $$$ approved for 2 resources
• Initial steps within your organization to get a formal project going

5. Appendices

• Data showing why 2 resources are needed, what happens if you get 1 or zero or 12
• Any other data, facts, figures around “hot button” issues that might come up like a trend to out-source or in-source work, strategic vendor partnerships, etc.

Your goal in telling this story is to have a compelling deliverable in the form of your presentation that conveys to anyone that it would be just plain silly not to execute your roadmap. That “anyone” needs to be both technical and non-technical people. I am certain your technical peers are going to be 110% behind anything that involves implementing new, cool technology. What techie holds the position of “nah, I still want to be a Windows 98 shop.” At the same time, the more holes that can be poked in your analysis the more likely your great idea is going to get trampled by the masses and not acted upon.

Sure, others might suggest not putting this much effort into a request that “should just stand on it’s own to support action”. A recent (how timely!) tweet from @rands suggests as such:

And although it might seem highly desirable to be able to convey your technical request in words and have immediate understanding and support, those veterans of large corporate IT shops know there is a big complex organization with overlapping, competing and sometimes contradicting priorities that can easily mount a campaign against your plan. Thus, those quick to dismiss the value of a slide deck deliverable in corporate IT might be missing a critical element of this series: producing a deliverable.

Sure, once you have a deliverable out there others can still mount a defensive. But, you also empower your management with a strong case to move in your direction that can be forwarded along and forwarded up. The more compelling your story, the more it stands on its own as a viable business case to make a strategic company investment the more the financial/business minded in IT will be able to comprehend and support your plan.

So, before you write-off the value of putting the effort into crafting a story deliverable that compels the non-technical decision makers to act on your plan, consider the alternative: a verbal request to spend money on some cool technology? If you are planning to invest a significant portion of your own money, do you want to buy some cool technology or act on a strategic technology investment with data backed returns?

Raw technical data won't speak for itself

In the first part of this series on senior management communication for those more comfortable with grep-ing an exception log or tracing through lines of code to find that elusive bug the conclusion was:

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

Thus, if you were following the argument to support this claim, you appreciate the notion that, ultimately, there are diminishing returns to exclusively honing your technical skills to perfection without making investments in your executive communication skills. Your frustration level will continue to rise as you see decision after decision being made against your common technical sense.

You need to assist senior management with data to aid in shifting decision making to include your technical vision.

In being pragmatic, this “shifting” is more analogous to turning the Titanic than a row boat. No fancy PowerPoint deck with brilliant technical strategy in-line with corporate objectives backed by irrefutable financials will guarantee decisions in your favor. There is an element of decision making that involves emotion that just can’t be trumped by reason 100% of the time [evidence].

As an example, a certain executive may favor one vendor over another. No matter how many Forrester Wave or Gartner Magic Quadrants you quote touting a vendor’s industry recognized superior product, a weaker product from a different vendor can get selected.

I am not saying to give up on collecting data to support your recommendation. But knowing non-logical factors influence decision making, you can appease your engineering brain to some degree, when rejected, with the notion that you exhausted your resources and produced a compelling business case that stands on its own. Plus, you never know if the next re-org will change the senior management decision ownership. You may very well get a chance to make your pitch again with a new audience that might just have a different emotional dynamic that is more in your favor. And since re-orgs occur more frequently the large the organization, you might not have to wait very long. I’ve written about corporate IT leadership change prior.

So, back to the topic of communication and the first fallacy of executive presentations for the technically proficient:

Raw technical data will speak for itself

Fallacy: If you just put your accumulated knowledge down on paper (or PowerPoint) in a logical, fact based sequence, the recommendation will just speak for itself.

Rarely, if ever, have I observed a senior manager approve a decision based on the spewing of sequential technical facts without any questioning.

Bob: “We need to upgrade to RHEL 6 because it more efficiently uses multiple core processors reducing overall OS resource consumption by 10% freeing those resources up for applications to uses. Fact, fact, fact, fact … thus give me two people and $200k to start the upgrade process.”

Those maybe compelling, industry proven, lab test supported facts that indicate some new technical something is vastly superior to what you currently have and the company will benefit greatly, maybe even eliminate some current outstanding problems, reduce costs, and cure cancer … but what problem do they solve or opportunity do they create for the senior manager?

Quickly clarification, “what problem do they solve or opportunity do they create for the senior manager” is not be taken as you need to pander to the whims of the senior manager. This statement should be interpreted as: How do all these facts and figures relate to the senior manager’s goals and vision?

Relate the facts and figures to senior management’s goals/vision

One of the best ways I’ve learned to do this is to structure a presentation into a story following this sequence:

1. Describe the Current State including gaps/challenges/issues/problems
2. Describe the Future State
3. Describe the Roadmap to get from Current to Future State
4. Outline the immediate next steps to get started on the Roadmap
5. Throw any ancillary or supporting data for the above 4 steps in Appendices

In the case of Bob’s desire to convince senior management to invest in an operating system upgrade, consider “telling the story” of ultimately what aligns to senior management’s goals/vision in this example context: computing capability at reduced cost.

Keeping with this logical theme of presenting a story aligning your recommendation to senior management’s goals/vision, the next article in this series will built upon this theme.

Convincing senior management of technical direction requires new communications skills

As a server administrator, you invested in knowledge associated with configuring operating systems to perform optimally and be able to interrogate error logs to diagnose and report problems efficiently. As a software developer, you sought feedback from code reviews and combed forums and blog posts and (depending on when you were in this role) books to improve your code. In your role, you invested in the technical skills that expanded your ability to deliver solutions within your respective discipline.

Being measured on skill-set attainment wasn’t particularly evasive. Your servers were deployed live and they either performed their needed functions in support of applications and end users or they crashed after deployment with a flurry of functional issues reported to the helpdesk. Your code either met the functional requirements and was bug free after being tested or defect reports mounted. There was more direct feedback as to what skill-sets you have mastered and what areas of your respective discipline needed more investment.

Even communicating to your direct manager in these technical roles provided more instant feedback as to your ability to successfully articulate problems, issues and recommendations for improvements due to the frequent interactions between yourself and your manager. And from your manager’s perspective, they were tasked with delivering a service and needed you to execute tasks to meet commitments.

But what about communicating to senior management?

In most cases, you are not directly interacting with senior management on a daily or even frequent enough basis to build implicit trust. You can rarely walk blindly into a budget meeting with senior management and say:

“We need to upgrade all the servers to RHEL 6. In order to do that we will need to buy ten new servers at X dollars each for a total of Y dollars now and we will need two more people to build and swap in all those servers. Of course, we’ll need all the applications to test after each server is re-built. And …”

with senior management responding with:

“Sure Bob, let me get out the checkbook …”

It is almost painful to observe a solid, technical individual attempt to explain a technology need to senior management who hasn’t determined how to effectively communicate that need in a format that senior management can more readily absorb. Equally troubling is seeing a poorly communicated yet real technical need be decided against by senior management based on a weak presentation. You can almost predict the conversation that will happen some number of months later:

“Bob, how come we have to pay this huge support contract on our servers? How come I didn’t know about this earlier?”

“But Sir, I tried to tell you we needed to upgrade our servers before …” This conversation becomes more awkward with each subsequent exchange.

No matter how technically proficient you are in your respective discipline, not investing in effective communication skills will limit your over-all effectiveness in your organization.

So, what steps can one take to make this investment in their communication skills? For one who has focused on learning technology, the shift of focus to learning effective communication skills may seem elusive at first. Thus, consider spinning up a thread in your brain that breaks this down into a logical exercise.

Look for part 2 of this article to dive into some logical steps.