Midwest IT Survival

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)?

The Art of IT Work Estimation

One topic that I am definitely still learning ways to improve is IT’s ability to successfully provide work estimates to those outside of IT in order for them to make business and/or priority decisions.  It definitely seems to be a balance between providing enough information for the other party to understand what is driving the work and at the same time, not too much information or worse, too much technical information that the other party will get completely confused by.

Some general techniques I’ve found to work across the board:

• Use a presentation style (such as Microsoft’s PowerPoint or OpenOffice’s Presentation)
• Make a recommendation
• Put yourself in their shoes

Presentation Style

It may seem like extra work to re-format what you have to say into a slide deck.  But the subtle power of the slide deck or presentation style is in your ability to lead the other party through your information in the way you desire them to be exposed to it.  As you are talking to the slides and they are viewing the slides, you are very much in control of the information that you are presenting compared to a piece of paper with stats or some full of words business case/recommendation.  Now clearly, if you didn’t do the research to gather all your support facts, no amount of talking and fancy presentation is going to convince the other party to go with a half baked approach.  The process of creating the deck on top of the analysis work already completed is yet another opportunity to think through what you are presenting and ultimately recommending.

Make a recommendation

If you have a well constructed slide deck with all kinds of factual data but don’t make a specific recommendation, you are missing a great opportunity to seal the deal.  You open yourself up to greater discussion outside of your control which might introduce new facts or worse, new supposed facts that can derail your original intention of getting a decision within your data.  If you present the facts and quickly arrive at a recommendation based on those facts, then others have to have done research greater than yours to contradict.  With a recommendation, you simplify the decisions the group has to make, which is to accept of reject the recommendation.  If you present facts and hope people are absorbing those facts to propose a recommendation, you may not be rewarded with what you need, rather, boundless discussion.  Thus, your chance of everyone having a more healthy discussion within your constructed bounds and arriving at a decision is greater with a recommendation.

Put Yourself in Their Shoes

Sure, you need an answer from those accountable for making work prioritization decisions.  Yet, your IT world is significantly different than their business world.  If you need a product manager to decide on exactly what features on the list need to be in the next release, try and figure out why each feature was added to the list in the first place.  Was it a high profile customer request?  If so, it is pretty important.  Was it operations wanting an improvement to speed up their work flow?  Important, but it is not compared to a customer request.  Is this a request that has been on the list for multiple releases but keeps slipping?  If so, it probably can keep slipping since it has already been passed over in the past.  If you need an auditor to sign off, try and put together a story that shows constant progress being made over multiple releases to ultimately close out the issue you can’t close in just one release.  Make sure it release further reduces the risk or exposure with data the auditor can take back to their team with confidence the issue is getting attention, risk is being reduced and the exposure will be eliminated in a fixed timeframe.  Having the ability to put yourself in your target audience’s shoes and thinking through what is it that is going through their mind as they are forced to make a choice of a less desirable result than “We are implementing everything everyone asked for in the next release” will help in getting support for your recommended approach.

I think I will write a series of articles on various techniques I’ve found to have more or less success with a given audience.  The above three high level considerations are probably some of the most universally applicable.

Anyone have any other go to approaches to the “we have more requirements to fulfill than we can possibled handle by X” IT challenge that they found work for a variety of audiences they can share?

What about specific techniques that work for a specific group or a specific situation?