Square Root of Change

Back in the early 1990s, I was working in IT at a multi-billion dollar manufacturing company. Ours was a small part of IT, separate from the mother ship. Responsible for about 2000 employees in our area, we had implemented several large projects over a two-year span; all bringing changes to the employees. I was a young IT acolyte, and I thought all change was good, great even. Why were people so grumpy? Sigh. I was so naïve.

Continue reading “Square Root of Change”

The First Step Doesn’t Matter

Businesses are littered with first steps. Attempts to change or improve that never get followed up on. A first release of a newsletter with no second.

Look at your intranet to see what is stale. See what hasn’t been update.
These are failures. You don’t get points for starting something. The first step is not the most important. That first step? It actually doesn’t matter.

Doesn’t matter how big it is. Doesn’t matter what direction it is. The first step just doesn’t matter.

What matters is what happens after the first step.

What matters is that an ongoing process is set up. A clear owner for the second step. A clear timeframe for each subsequent step.

Rolling out a PMO? That first batch of templates and processes doesn’t matter as much as setting up clear ownership, allocating resources, tasks to drive culture change, setting an update schedule, and having expiration dates to force continual review and updates.

Inbox: friend or foe

xkcd: https://xkcd.com/2181/

If your job doesn’t fundamentally depend on your email*, then ask yourself if you control your email or if email controls you. Our Email Is A Monster (Oatmeal). Some ideas to consider:

  1. No matter how focused you are, when that little window flashes up in the corner of your screen or your phone beeps, you have at best a micro-distraction that derails your thinking and at worst a full distraction. Turn off your email notifications and schedule time during the day to open email.
  2. Signal (high priority emails) to noise (low priority emails) in your inbox is a problem. Not all emails are equally worthy of your time. If conditional formatting (like in Outlook) is available, use it. Set a condition for when you are on the CC list. Read those last. Set a condition for when you are the only one on the TO: list. Set conditions for people that you need to respond to right away.

* Customer service type jobs and a few others do require constant vigilance of an inbox so the above suggestions don’t help you. Hopefully you have other techniques to make things more efficient.

Signal To Noise: Managing what comes at you

In telecommunications, the concept of Signal To Noise Ratio has been around for a long time. The basic concept is the signal (what you are trying to communicate) and the noise (all the crap that isn’t the signal) are related. The higher the ratio of signal to noise, the better. High ratio: more signal, less noise. Low ratio: less signal, more noise.

A high Signal To Noise ratio is a good thing. Thinking about the concept, not the math, if we have better signal and less noise, we have better communication.

This post is mainly about receiving communication. This includes talking to someone, email, texting, social media, etc. Some of this is obvious: if you are trying to listen to someone and there is a jackhammer going on five feet away, there is too much noise to hear. If someone texts you with a name you need and wraps it up in 2000 characters of opinions and other useless info, that is bad signal to noise.

But there are some non-obvious ways to look at it.

If you get a lot of unnecessary emails or texts, it will be harder to find those that you want to get. We can keep an eye out for message from people we want to hear from, but we will miss messages. The list of things to read (the list of conversations in your text messages, your email inbox) is something that has a signal to noise ratio.

If we have curated our social feed, we have lower noise and better signal..

Consider a few possibilities

  • Email: be vicious in unsubscribing from things that you don’t actively need. Be proactive in managing your inbox.
  • Social feeds: be aggressive at muting, blocking, unfollowing those that post noise (you get to define that). If you complain about Facebook or Twitter about how much stuff you have to scroll to see anything interesting, then you are following too many of the wrong accounts.
  • Learn the controls available to you. Yes, it is a pain when Facebook, et al, keep changing their feed algorithms and add/remove settings. But learning them takes time. Yes, understanding Gmail’s tab structure and conversations seems overly complicated. However, spending a few minutes trying to figure out how to use them to your advantage will save you lots of time in the long run.

Curate your electronic life. It pays off quickly.

Electronic Bits
Coming fast from everywhere
Are you in control

Helping People Understand Data

We are flooded with data and we don’t understand most of it. While the below HBR tip of the day has specifics about communicating outside the company, I think that the basic concept — helping people understand the data — is a fundamental part of being a Business Analyst.

Photo by Lukas Blazek on Unsplash

The standard mantra you hear is “too much data, not enough information” or “information is data made actionable”. These sayings are all getting at the fact that looking at data does not convey everything that we can learn from the data. Understand what is being looked at, understand the limitations of the data, understanding the assumptions in the data, understanding the cleanliness of the data. That is critical to having a business leverage the data they have.

But data can steer you wrong if you don’t know the information around the data.

When someone is looking at a report, is it easy to see the metadata? When someone looks at a spreadsheet or a PDF output of some sort, can they see where the data comes from and what assumptions are in place?

It is easy to simply slap a report out for the requester to get what they want. Too often, the requester and the report writer miss the fact that someone else is going to use this report six months from now and not have the same background the requester had. Or think differently from the requester.

So when writing reports or creating spreadsheets or otherwise presenting DATA that is meant to be understood, consider adding this information (automatically updated, of course) to them:

  • metadata (date of data, all the parameters, specified and implied filter and sort parameters)
  • Where did the data come from? Can you provide a link back to the original data for detail reports?
  • What are the calculated fields and what are the calculations?
  • Who is responsible for the data?
  • Who do I talk to if I have questions?
  • Do the field names make absolute sense to everyone looking at the report?

Here is another tip, this one is from Harvard Business Review:

Help People Understand Your Data by Making It Relatable
People can’t use data to make decisions if they don’t understand what the numbers mean. To help colleagues wrap their heads around a data point — how big or tiny it is, how important it should seem — compare it with something concrete and relatable. When you’re talking about lengths of time, frame your data in terms of flights between cities, TV episodes, or how long it takes to microwave a bag of popcorn — whatever your audience will know. When you’re talking about size, use places and things that are familiar to listeners. For instance, if you were trying to show a San Francisco audience what 1 million users really looks like, you might mention the San Francisco Giants baseball field, which has 41,915 seats: “Our users would fill the stadium almost 24 times.” Articulating figures this way can keep the narrative from getting lost in the numbers.
This HBR tip is adapted from “3 Ways to Help People Understand What Your Data Means,” by Nancy Duarte

xkcd: Unreachable State – been there, done that…

As a developer, I was so tempted to put messages like this in the parts of the code that should never execute. I did a couple of times, although never this clever. I’m not up on the latest programming languages, but I imagine that it is still possible to have these places of despair. These ‘black holes’ of code where you should never go but if you do, you will never recover.

Continue reading “xkcd: Unreachable State – been there, done that…”