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?

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.

How to marry the classic IT budget and Agile?

I’ve been reading more and more about managing large projects with Agile.  I am wondering how best to optimize the merger of the classic IT yearly budget cycle for large scale projects with the Agile principles and agile project delivery.  There has to be a way to balance the constraints of an upfront budget process with the benefits of agile-ly deployed business prioritized deliverables.  Or in other words, how does one keep the dollars and cents focused people happy and the business project sponsors enjoying the benefits of Agile delivery?

The classic IT yearly budget cycle I’m referring to is one of wild guesses at capital such as servers or software licenses, maintenance, expense and internal plus external resource costs to complete projects that involve IT in the next yearly financial calendar.  Projects maybe completely IT driven with IT as the end customer or projects maybe requested by the business to deliver business value that need IT support in delivering that value.  In either case, the classic budgeting versus agility challenges is the same.  Take the typical project mixing IT and business changes:

New Project Request Form:

Project: A456 Enable Call Center Order Confirmation

Scope: Upgrade the FlimFlam call center system from 5.0 to 6.0 to enable the customer communication widget and change the call center workflow to use the widget and not carrier pigeon to confirm orders with customers.

Budget Questions:

• How much does the upgrade cost?  (easy, ask software vendor)
• How many consulting hours and dollars are needed to support upgrade? (medium, ask software vendor’s professional services for a typical customer upgrade number, then add fudge factors to map over to your company)
• How many hours from your internal shared IT resources to support the entire effort? (hard, don’t have the time to go through the project requirements gathering and design phase or collect all stories, get story points, etc., etc., so take a wild guess based on past projects or other similar work, add fudge factors, add more fudge factors, then double it … you get the idea)

Project Budget Submission Criteria:

? = Capital

? = Maintenance

? = Expense

? = Internal Resource Hours

? = External Resources Hours

? = External Resources Hourly Rate

? = Total External Labor Costs

The budget process demands a number to be provided for each question mark.  You know that certain magic number thresholds, if cross, will doom your project or almost as bad, push it into a category that requires a whole new level of business case and ROI sizing effort. This classic IT project budgeting process doesn’t seem to support the majority of the Agile project delivery process.

Does anyone have any experience or references to best practices in this area of marring legacy budgeting and agility?

When to insert that upgrade dependency

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances to varying degrees of success.  In this article, I’ll outline one which involves linking a sponsored project in flight requiring some technical solution from your team to an upgrade or enhancement your team wants but is struggling to implement on your own.

As mentioned in the prior article, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  If a project is of a high enough priority that it needs to be accomplished and your team has a role to play, consider creating a plausible dependency on meeting the project requirements via the upgrade/enhancement you want to implement.

I’ll take a stab at a typical requirements gather conversation to explain:

Project Manager: “Boss, it is my understanding that your team provides widgets that interface between the FlimFlam system and the billing system?”

Boss: “Yes and my understanding is that this project requires a widget to take the ABC format that comes out of the FlimFlam system and convert it to the XYZ format so it can be fed to the billing system, right?”

Business Analyst: “Yes, that is correct.”

Boss: “Well, I checked with my team and we have two options.  One, is we can directly develop the conversion widget in the current product version we have and that will take 20 days and there will be extensive testing and the possibility for a high number of defects due to the custom coding.  The second is we can upgrade our product to the latest version which contains native support for converting ABC to XYZ.  Thus, the 20 days becomes 1 day to configure the new product.  The new product has been out for six months and used by a number of other customers thus it shouldn’t have any serious defects.  The catch is we have to regression test the five other widgets currently in production.  Our recommendation is the second option.”

And just like that, you’ve articulated a business case that strongly suggests an upgrade you have been wanting to implement but couldn’t get all five interfaces tested and signed off.  This sixth interface project effectively completes both objectives: yours and the projects.

Hopefully you have done your homework and are seriously confident that the upgrade indeed will meet the project needs even if the “native support” is stretching the truth just a bit.  The real key is that you can realistically meet the project needs within the alternative estimated timeframe.  Once the project gains momentum and is marching down your road of upgrading and testing versus custom coding, it is next to impossible to switch the decision as long as you are trending towards meeting if not exceeding the other estimate.  One of the more difficult IT centric challenges is getting another group to test their technology that interacts with your technology when they have no reason to do so except for your need.  This approach uses the priority and urgency of this new project to drive that testing.  “Guys, we wouldn’t need you to test but this other project is forcing us to change thus we need you to validate …”

What happens if they build momentum and go against your recommendation?

The subtle power of “recommending” one particular course is one of risk ownership.  If the project accepts your recommendation, then you own the risk of not meeting the projects needs.  If the project rejects your recommendation for an alternative, then the project now owns the risk of the success and/or failure of your work to a significant degree.  How so?  Well, whenever the project comes back to complain about missed deadlines or quality issues, you have the immediate  response poised: “Well, you remember we recommended option A but you asked us to do B.  Had we done A, I believe we would be meeting your expectations.”  You have various permutations of that response as your get out of jail free card to the immediate complaint.  Clearly, if you enjoy your paycheck, you need to continue to make the project a success.  But, if the project as a whole starts trending negative, you are pretty much in the clear of taking a significant portion of the blame.

What happens if your recommendation turns out to be more complicated/time consuming than you originally thought?

This is where doing your homework comes in.  Before even recommending the upgrade/enhancement dependency option, you need to be extremely confident in your ability to meet expectations.  Going off new features and functions in release notes is a bad idea.  Working from some semi-formal product/solution testing and real engineering evaluation is a much better idea.  If your role in the organization is exceedingly intolerant of the risk failure, then I would venture to say go so far as the only open variable is the need for the formal testing signoff from the external groups.  The closed variables would be up to and including having already technically tested and confirmed the external group owned systems will work in formal testing scenarios (via the systems themselves and/or a stub of their systems touch points with yours).

The ability to link an upgrade or enhancement to an in flight project gives you the ability to help the project succeed as well as accomplish a goal on your list at the same time.  The keys are to be able to plausibly justify the upgrade approach is better than an existing solution coupled with being extremely confident based on actual testing that the upgrade will actually work.

Has anyone used this or a similar approach and had success?

How do I get this IT project started?

I think one of the greatest challenges in IT is to get an IT centric effort off the ground and executed to completion.  How many times have you been in a team meeting where the dialog went something like this:

Boss: “Anyone check out the new enhancement to the project management software we use?”

Bob the Engineer: “Yes, according to the release notes, it now includes a bug tracking module that is as good if not better than that silly third party product we use.  Plus, it is now integrated with the enterprise QA reporting service.  If we upgrade then we can turn off that third party bug tracking software and decommission the server.  Plus, all the PMs can stop manually typing in their project details into the QA reporting tool rather, hit a but to automatically populate the QA tool.”

Boss: “Sounds like a no brainer to upgrade … but how are we going to pull this off?  We need some time to install the upgrade, import the existing data, training and cut all the PMs over plus put together a training guide or something for the business testers that currently use the old testing software … plus, probably a bunch of other details I am not thinking of at this moment.”

Bob the Engineer: “Yah, this would totally help people in the company get projects done quicker without all the manual bologna that goes along with tracking stuff.”

Boss: “No one else is really looking at this but us …”

So here you stand on the precipice of a significant efficiency gain to the organization’s overall project delivery.  So why can’t you just jump on executing this obvious, no brainer improvement opportunity?  If you are part of most “MidWestern-ish” IT organizations, you have a great (or not so great, but your have one) engine for handling the prioritization of business driven requests, but lack, somewhat, the ability to inject an IT centric request.  More than likely, your current prioritization engine would drop this upgrade to the bottom of the list which means no one is going to be able to work on it given all the other high priority business requests.

I’ve been faced with this challenge over the years and have adapted different strategies based on the circumstances.  In this article, I’ll outline one which involves converting the IT request into a business request devoid of IT buzzwords.

As mentioned above, if you are providing some IT services back to the rest of the organization, you must have some formal mechanism to aide in prioritizing the work requests.  [Warning: extended water flow metaphor ahead]  It is impossible for a finite set of resources (IT) to be handling an infinite stream of requests (the business) without prioritization otherwise the organization as a whole will eventually implode in on itself.  Whether it is the example above or a new low cost storage technology or a new development language of choice major revision, one way to get some attention in the proverbial fire hose of work coming at you is to get that work into the business request pipeline.

To accomplish this, besides digging into how requests can be properly formatted to formally enter the pipeline itself, you have to start converting the IT request into a business request.  For example:

IT Version:

• Upgrade the project management software from v1.0 to v1.5
• Decommission the bug tracking software and server

Business Version:

• Enable the overall savings of $12,000 and 240 hours per quarter per IT project by providing technology and process improvements to the project delivery process, total per year savings = $480k and 960 hours less a one time investment of 200 IT hours to implement
• Supporting Data:
  • Assumption = Overall hourly rate for PM and Testing resources working on IT projects = $50 (average salary + average HR overhead + facilities)
  • Current = Averaging 20 concurrent projects each averaging 3 months in duration require 3 QA reporting updates per week consuming 1 hour per update
  • Future = Automate this process to one click, thus 20 project * (3 months * 4 weeks)  = 240 hours saved and 240 * $n = $12,000 avoided per quarter
  • [If you can compute the guestimation of monthly savings on the hardware, depreciation, software licensing and data center stuff (power, cooling, rack space, etc.) of decommissioning a server, add that to the total money savings]

Now, your first reaction maybe, “geez, those two look radically different, how can they be focused on the same goal?”  The key word in the goal sentence that I chose was “convert” an IT request into a business request.  Sure, you can look at some software release notes and quickly run through a business case in your brain that says “heck, these new features are really going to help us get work done faster”.  But non-IT people don’t immediately draw the same conclusion that you just did.  Depending on different levels of non-IT involved individuals in the project prioritization process, any number of perspectives can be drawn from the IT version:

• Why do we need to upgrade?  What we have seems to work fine
• Update = spending money … I don’t want to have to try and explain why I approved spending more money
• I don’t immediately understand this request thus it can’t be that important, next item that I might be able to comprehend …

But what are the two universal business concepts that everyone inside and outside IT can appreciate?  Doing something that will save time and/or money.

Thus, how do you get some attention and focus on your seemingly IT centric request?  Answer = convert it to a business request that somehow legitimizes benefits the change itself provides back to the business.

Anyone tried such an approach and experienced success (or failure and why)?