How to work with IT and not against it - Part 1

Shadow IT is on the rise and it's a bugbear of IT departments everywhere. Yet, a lot of the time, those involved in shadow IT are oblivious to the fact what they are doing even has a name, let alone that it is viewed as a problem.

Lately, I've been focusing and writing a lot about how IT people should improve how they interact with the rest of the business. But I thought it would be fair to make some comment about the inverse arrangement. For those that are outside of the IT sphere, how do you effectively work with IT teams to form a perfect "synergy of cohesion" or in a bit of plain speaking:

"How can I do things in a way that doesn't piss of the IT department"

Now, upsetting IT folk is not the worst thing in the world. In fact, I have played plenty of games of "poke-the-bear" with colleagues over the years. If you have the right relationship, then I say poke that bear!

Try arguing about technologies you know they are sensitive about.

Does your IT guy hate Apple? Why not constantly mention how great your experience with your new iPhone is.

Is that developer a Java dev? Tell him he should be programming in Go.

I even go so far as to take contrary positions on different days. Some days I love Microsoft, other days I hate them. It all depends on what the other person says.

There's no harm in a little chaos.

But, be very careful about pissing off your IT department when it comes to dealing with projects, apps, initiatives and processes. While you may think your IT department is all ethernet cables and password resets, they are (or at least can be), much much more than that.

Working well with your IT team should be high on your list of priorities and if done well, between both groups, should enable you to some amazing outcomes.

Don't let IT people suffer the consequences and pain of others poor choices

Now they don't own everything, or neither are they perfect, but that IT guy who is constantly looking frustrated, is probably like that due to having to deal with the repercussions of poor choices.

He or she is more than likely supporting infrastructure, an application or a setup that is:

• not fit for purpose
• not fit for the environment
• poor designed
• non-compliant
• difficult to maintain

Which one is it? Trick question, it's every single one of these.

Can it really be that bad? Yes, it can and frequently is. Worse still, it's likely that your poor sysadmin is dealing with more than a couple of these poor systems.

A little known fact is that IT vendors will sell anything to anyone, in any company, as long as they pay the bill. During a sales meeting applications will, integrate with everything, are compliant with all known and future standards. Plus nothing ever needs maintenance or rebooting or updates that require a large number of outages, planning, resources or mindless installation wizards.

So how do you avoid that? Easily enough, invite your IT guys and girls into your planning meetings and into your sales meetings. We can assist in making recommendations based on previous experience. We can ask the right questions and call out the bullshit with vendors.

IT team participation in meetings is potentially not one of their strong suits, but given the chance to help in this scenario, you might just be amazed how quickly they respond to your meeting request.

Be aware, your sales meeting might be a little tougher than usual, we may ask some tough questions and it may seem we are being a little unreasonable. However, just know during sales meetings, we aren't looking at the flashy PowerPoint slides or product demos, we are looking into the future. We have a little crystal ball we gaze into and see ourselves in 6-12months time. We are looking at a Friday night, while others are out partying, or relaxing on the lounge, we are looking to see if we are doing those things, or are we at our desk cursing at an application that's not working.

You may have to grit your teeth a little through some tough parts. Your IT team probably won't match the enthusiasm of a salesperson looking to make friends. There's likely going to be some tough question asked in a less than diplomatic way. Things are liable to potentially get a little rough at times. It can be a little difficult to determine if the meeting was a success. There are ways to tell:

• if the sales guy gets out alive and unscathed, things went reasonably well.
• if the vendor promises something is "...in the next version", he's lying and it won't be. Beleive your IT guy when he tells you "he's lying" because our hearts have been broken by so many promises.
• look for great feedback from your team. These will include phrases like "not the worst software I've seen" or "seems like it would be ok" which are in fact great signs of approval.
• If any feedback starts with the phrase "I liked....." then your IT team has accepted the application into its tight social group and will foster it as its own.
• if the IT team walk off laughing looking like they just shared a funny joke.....the meeting was the joke. Time to find an alternative.

Choosing systems are just one part. But it is a critical one where most mistakes are made.

While there are lots of aspects of implementing a new system, there is one other aspect which I want to mention.

The business needs to determine upfront, how this fits into your service catalogue. The who, what, when, where, hows, of support, responsibility and SLAs. Determine this before you do anything else and save yourself a lot of hassle later.

If you're not sure what I'm talking about read this

Workflows, coding and reporting

Where there's failure there's room for improvement.

Let me go over some guidelines here:

• Any workflow that includes, emailing it on to the next person, or copying and pasting data is inefficient and most likely soul-crushing.
• If you have code of any kind (websites count), that is not in a code repository, you are set up for failure and regret
• Reporting "done in excel" is not in fact reporting. If you have to spend more than 5 mins in Excel to produce this report remember that is 5mins a day you will never back again.

5mins x 5 days a week x 48 weeks a year = 20hours a year. Let's be honest, it's more than 5mins a day isn't it. I'll let you do the maths.

Computers are fast dumb idiots. They will do exactly what you tell them to do over and over and over until they have no more power. After the annihilation of the human race, there will still be a small deployment of Cisco routers from 1998 still routing packets between each other across vast distances, blind to the destruction around it.

Humans, on the other hand, are slow dumb idiots who stop processing data at the first sign of too hot, too cold, pandemics, weekends, nighttime, football matches and bears. However, with brief bear free productive periods we can instil some of our abilities into computers so they slave away during football matches, bear attacks, weekends and other times we don't feel particularly keen on work.

IT people are lazy enough to know that making a computer productive on their behalf is a massive step to replacing themselves with their own robot clones. Any repetitive function that can be performed by a computer can and will be turned into code that can do this for them. We are free to spend our weekends as we please, visiting zoos perhaps with only mild chances of bear attacks.

Automation like this falls between mildly difficult to maddeningly impossible for people who don't believe Java is coffee and not a programming language. Ignorance of Java programming is indeed bliss, and luckily not a requirement for getting something automated.

This is where a partnership between IT and the rest of the business can help to bridge the divide. It starts with an offering of Java in coffee form, in return for automation, which conveniently (from a poetic sense) may be returned likewise in Java this time in code form.

Don't get lost in a Forest

Enough of the imagery, it's time for some plain speaking again.

IT people can automate things. You have stuff you need to automate, even if you don't necessarily understand how or even what.

Do whatever you need to get the attention of your IT team. Then it's time to break out the whiteboard and forget the technology.

You need to start with workflows. Start your diagrams at a level so high you're orbiting the planet.

Data comes in -> Processing -> Data goes out

Forget about excel, spreadsheets or applications. Describe your workflow in the most basic way you could.

Ok, we've got some very broad basics. Now let's come down to a 40,000ft level we're flying our 747 now.

Why does data come in? What frequency does it appear? Where does it come from?

• What do you need to do with it?
• What do you need out of it?
• Where does it go?
• What benefit do you get from the process?

Importantly think about this as abstractly as you can. You get data from a client, a system, an order from a customer. What process needs to happen next? What steps does that take?

Right now your processing is done by Joe in Excel. But don't we want to think about Excel, or Joe, we want to understand the basics of the process, so we can eliminate Excel and retask Joe for something else.

The reason we want to keep it high level is because if we keep talking about specifics we end up automating the Excel piece which might sound great, but that spreadsheet might only be one small part of the process. It might only exist because of self-imposed limits placed on the process.

Freeing ourselves, seeing things more broadly allows everyone to firstly take a step back and reevaluate things, including discovering problems, limitations and potential solutions we never thought about before.

People often get a little irritated when they have a problem and I ask: "What are you actually trying to do?"

"I'm trying to upload this file to our portal and it doesn't work!"

"Yes, but why are you doing that"

"Because John over there needs the file! Just fix the portal!"

"Why don't we email the file to John."

"....oh yeah that would work."

Sure I'll fix your portal, or your internet or whatever, but don't forget what your trying to achieve.

Technology is simply the method of accomplishing a bigger goal. Don't make it stand in the way

In the heat of the moment, it's hard to get lost in the forest looking for the trees.

.....Stay tuned for Part 2 shortly...