Business vs. IT

I felt like a lawyer. The call was in less than 12 hours, and I was busy preparing my case, consolidating evidence and building my story. To be honest, I wasn’t 100% behind the argument I was preparing to put across, but I didn’t really have much of a choice. I had to believe — how could I convince others if I couldn’t even convince myself?

But at the same time, I really wanted to steer clear on the “us vs. them”. Together with allies “from the other side”, we were working hard on framing it from a collaborative angle. It’d do us all no good if our discussion disintegrated into a blame game.

The situation at hand was a classic business vs. IT situation. Business says “we asked for this”, and IT says “no, you didn’t.” Whatever the case, the project deadlines weren’t going to be hit and nobody wanted to be responsible.

The funny thing is, if you asked me, I’d say no one was responsible (or that we all were). It was one of the first times we were doing anything close to what we were doing, and it was almost expected that hiccups like these were going to occur.

Requirements were defined, and IT made good on those requirements. Business was as clear as they could be on those requirements, but apparently not clear enough.  But how could they be? The project was a little too big and too fuzzy to be executed perfectly from the get-go.

Maybe a more iterative approach might have worked better, with all parties agreeing at the start that for a period of say, two or three weeks, we’d all be in a transition phase, where 70% of the requirements were met and the other 30% part of some type of agile-development, exploratory process, where things didn’t need to work perfectly but problems rectified quickly.

True, we could have spent more time thinking through and defining better requirements. But even if we spent an additional year we might not have uncovered requirements buried deep under others, the discovery of which were dependent on the implementation of the others. Would the need for a parachute have come to pass if planes hadn’t yet been invented? Would these later requirements have come to pass if the earlier ones hadn’t been implemented?

Whatever the case, this was an interesting situation to be in.

Creating on the iPad

Creating on the iPad… it’s just not the same as creating on the computer.

When on the iPad, I’m far more a consumer. Typing is laboured, and sharing isn’t as easy. If I see an image on Facebook or Linked In, and I want to share that with my Google+ followers, it’s not straightforward at all.

Consumption, though, is far easier. I read a lot on the iPad (it’s essentially replaced my weekly visits to the library); viewing images are a joy (whoever invented pinch-to-zoom should be knighted); and browsing through music on the Spotify app is quite the adventure.

The funny thing is that all this consumption without sharing irks me. Every time I experience something I like, I want to share that with somebody. Everybody. But because of the difficulty, I park it in my mind. I bookmark it. Tell myself, “I’ll share that later,” knowing full well it probably isn’t going to happen.

A look through my iBooks app shows pages upon pages of highlighted material and notes, all of which during the time of highlighting and noting was something I was just dying to share, but which I haven’t.

That’s why I’m bitching about it here, typing this on my MacBook Pro, with my iPad’s Spotify app providing beautiful background music.

People Watching

People watching used to be a favourite hobby of mine. Sitting at a café, observing without judging.

Then technology came along. And I don’t observe people so much anymore.

I mean, you can’t observe both the screen and the people around you, can you?

A real pity, really.

Technology has filled all those little spaces that “just being” used to fill. The spaces between the things that needed to be done and the places that needed to be visited.

And unfortunately the spaces where ideas used to roam free and germinate.

Some thoughts on the thinking behind building things

I’m going to write a bit about my thinking process whenever I build things, whether it’s websites, VBA applications, or financial models. I’m not too sure if this is going to be a “oh that’s so obvious why is he telling me this?” piece, but if there’s one thing I’ve learned, one person’s normal behaviour may be another person’s exceptional one.

And I know you’re exceptional. So let’s get on with it.

My thinking process whenever I’m making things people use (i.e. goes into production) goes like this:

First, I ask myself (or the project champion/sponsor/requester): is this a one-off, or will there be many iterations?

If it’s a one-off, I can do away with making things beautiful and/or flexible. For one-off builds (again, whether it’s a webpage or financial model), most things can be hardcoded (e.g. unchanging interest rates, cell references and the like) and documentation doesn’t need to be too detailed (trust me on this though: documentation should still be done. People have a habit of waiting till the day after you forget what you did to ask you how you did it.)

If there are going to be many iterations, then I ask myself, what’s likely to change?

I once built a financial model containing over 30 options from which business users could pick and choose to determine what affected the final number. The model didn’t start of with all the options straight off the bat, and was in fact supposed to be a one-off. But after hardcoding and then manually changing what users needed multiple times within the same day (even though they “were quite certain” on what they wanted early on), I realised the flexibility of options, despite the longer initial development, was worth doing. I built the options on a very granular level so users could say, “I want option #1, #5, and #29” and have the affected numbers come up immediately.

Focusing on what’s more likely to change, and ignoring those that won’t, will allow you to save plenty of time. In that same model, I didn’t bother with ensuring formulas didn’t get broken when headings changed, because I knew they weren’t going to. (But I have certainly done this before; in some applications I’ve written, the source data had headings manually typed in, and almost every other week some variation of what was basically the same thing would get put in. I used regular expressions to ensure anything that looked like a header was treated as a header.)

Who and what is this report for?

Depending on the needs of the request, you could very well end up spending hours on something that should take only minutes. I have encountered many times someone coming to me for numbers in which I thought details were needed (or would be useful). I’d spend far too long extracting and formatting really granular data, when all the person needed was a “ballpark” figure.

And when you’re sending that consultant who is requesting for your company’s sales figures the information he needs, make sure you’re not giving him more than he needs. Does he really need to see the invoice numbers? Or customer IDs? Or costs?

Designing for maintenance

A few years back while taking the train I saw an engineering student’s lectures notes on “designing for maintenance”. I’m not from an engineering background, but because I happened to be mulling about on what software to use for a website I was developing, the concept of designing for maintenance struck me like Eric Clapton’s fingers on a guitar string.

Beautiful. Smooth. And oh-so-right.

The two main pieces of software that I had been considering were pretty distinct. One had a very developer-friendly, Linux feel. The other had a very polished, user-friendly Apple feel. The former catered to my nerd needs, while the latter catered my aesthetic aspirations (an aside: the very word ³aesthetic² is surprisingly pleasing to the eye and ear).

Though at first I was kept in a 50/50 bind between the two, after getting exposed to this idea of “designing for maintenance”, I realised that I really needed to go for the more polished and user-friendly one. Though I was helping to develop the website, I wasn’t going to be running it or doing the day-to-day maintenance of the site.

I think that maintenance of software (including spreadsheets) is something that’s missed by far too many people. If you know you’re not always going to be around to maintain the software, make sure it’s easy-to-understand and that everything’s well documented (even if it’s in an e-mail). Keep in mind that it isn’t all about you, but rather about the end-user, too.

Well, that’s about what I have for now. Would love to hear your thoughts on this. If you have any.

Business vs. IT

I was reminded today in a book I’m reading on visual analytics that the purpose of any analytical project is ultimately to make better decisions. Coming from a mixed business and IT background, I have had my fair share of IT vs. Business conundrums.

With my IT hat on, I’m always thinking about efficiency, optimisation, ease-of-use, and resource management. What questions are being answered, what problems are being solved, or what the ROI (to a certain extent) isn’t always on the forefront of projects (though almost always who’s the requester is).

With my business hat on, I’m always thinking about what business questions to solve, what information needs I have, and just plain old “getting the answer”, which IT isn’t always the most willing to help retrieve. I don’t care about how long IT takes (so long as its done yesterday) and how much effort they need to put in or how optimised the process is, I just want my questions answered so I can make better decisions. Isn’t that what technology-driven analytics is supposed to do

But, coming from a mix of business and IT backgrounds, I know the problems both sides face. IT needs more emphasis on understanding business needs, while business needs to understand IT constraints.

My current role has me more as a “business” person, and I don’t know if that’s a blessing or a curse. A blessing in that I’m given a lot more face time in business and finance discussions, allowing me an almost voyeuristic view of how the business makes its money. A curse in that IT treats me as any other “business” user who’s request trigger-happy and who doesn’t understand the IT side of things (and therefore who should be ignored most of the time).

It’s tough convincing IT to talk about the things that could potentially give pretty decent ROI when they don’t trust you.

“I’m one of you,” I tell them.

“Yeah, you sure are, buddy,” they reply, smiling, handing me a ticket number.

On theory, practice, and Snowflake Schemas

Just the other day I learnt that the data warehouse I was working on was designed using a Star and Snowflake schema. I’d known enough about them to know that this meant the data was set up on fact and “dimensional” tables, but not much other than that.

So the moment I had some time I went online and looked up definitions, and realised that they were pretty much the way many of the bigger databases I’d done up looked like. I’d been using this schema for the past four years (at least) without my ever realising it. It was like in Le Bourgeois gentilhomme when Jourdain remarks

Good heavens! For more than forty years I have been speaking prose without knowing it.

Which reminded me of something else I read about in Taleb‘s Antifragile: that academia often comes after practice. You can do something your whole life (practice), have it labelled and described as something in theory (academia), and after a while forget that it’d started not as a theory but as an unlabelled, undescribed bit of practice and not as a theory.

Personally, Taleb’s spelling this out gives me much reassurance that we don’t always have to understand something theoretically in order to do something (an activity) well. If I want to run well, or swim well, or program well, it doesn’t necessarily have to follow on from learning the theories of aerodynamics, water viscosity, or binary.

Getting Real by 37Signals

In what must be one of the most serendipituous moments of my recent life I hit upon 37Signals’ Getting Real TOC page after doing a search of a string of text that randomly entered my mind. (The whole book’s available online for free? Wow!)

I’d first read Getting Real in its physical form (borrowed from a local library) and liked it so much I even quoted it in one of my earlier posts on making plans.

Though largely to do with software development and start ups, I find its lessons thoroughly transferrable to plenty of other domains in life.

Analytics Adoption: Evolutionary vs. Revolutionary Technology

In this post about analytics adoption, I’d like to start with a short story.

The wife and I got ourselves each a Samsung Galaxy S4 over the weekend. Though it’s a great phone, we couldn’t help but feel that there was a distinct lack of a “wow” factor.

We both moved to the S4 from the S2. Back in its day (about two years ago) it was the latest and the greatest, and though technology has come some way since then it’s still a very capable phone. I remember when we got the S2… boy, did we feel like country bumpkins moving into the city. Everything was wow, wow, wow.

Even I, a self-prosessed can’t-go-a-day-without-the-computer-nut, could go a day (a day! can you imagine??) without touching my computer because everything I needed to do on it I could do on the phone. It was amazing to be able to send free text messages, and access e-mail and Facebook on the go. I didn’t know what I was missing until I tasted the data-plan-backed mobile life.

But having had such a capable phone already, the S4 comes to us an evolutionary and not revolutionary move. Sure, things are snappier, bright, faster, and larger. But that’s about all they are. It hasn’t been the same habit-changing killer app.

Evolutionary vs. Revolutionary Technology

Now, the S4 may be a evolutionary technology step for me, but for plenty of people who haven’t yet made the move to a relatively capable handset like the S2, it could well be a revolutionary move. The thing is that where a user is in the lifecycle of technology adoption makes a big difference to how that technology is perceived.

I would imagine that the biggest winners in analytics ROI (i.e. dollar returned per dollar invested) would well be those who have been avoiding it thus far. Because there’s such a huge gap to be bridged between no analytics and some analytics, even the smallest investments in analytics could give huge returns. (Whether it scales or not is another story for another day.)

And with the recent improvements in analytical processes/methodology, software, and thinking (a very important point here), things are far cheaper — and not just in terms of money, but of time, executive buy-in, and ease-of-adoption.

User requests are like hunger pangs

“So, when is the [request] going to be ready?” he asks me, the fourth person to ask in a one-week period.

This, I think to myself, is probably real hunger.

“I’m working on it,” I reply, which means I’m waiting it out to determine how important the request really is. The moment I can confidently say it’s a valid “need”, a real hunger, I move it into my high-priority queue and start work on it.

It’s not that I don’t wish to help, but system/application/report requests have a tedency to come in hugely inflated, seemingly much more important than they really are. More a reaction to an itch than a true life-saving need it’s thought to be.

I like to think of requests that come into my queue as a type of hunger. There is real hunger: the haven’t-eaten-for-days-and-starving hunger; and then there’s perceived hunger: the after-dinner craving for Pringles hunger.

When a request is of the “real” hunger variety, no matter how long you try to wait it out it’ll always be there (and the people who are requesting it won’t let you forget it’s there!)

“Perceived” hunger requests, on the other hand, tend to go away like after-dinner cravings when you give it a little time.

One problem with giving in to these “perceived” hunger requests is that, like the afore-mentioned Pringles, once you “pop you can’t stop” – these sorts of requests tend to come one after another. And it’s difficult to know when to say no because each request isn’t really that different from those that came before it.

A precedent, once set, can bind you to a cycle of petty requests (“why did her request go through and not mine?”) for the life of the project.

So my advice is: wait and see. If it’s really important you’ll be sure to know.

Which reminds me, it’s time for supper.

What do you do? I’m an analyst.

“So,” my wife’s friend asks, “what do you do?”

I pause for a moment, prepare to say “business analyst”, but then decide not to because I didn’t think she’d understand what I did. I look at my wife and ask her, “what do I do?”, hoping she’d have a better answer.

My wife looks at me, then at her friend, and says, “he’s a business analyst.”

I look at my wife’s friend and she looks back at me. Silence. She gives me a puzzled look.

Food’s here. We eat.

The “what do you do?” question has probably been asked since the dawn of awkward social situations. Since when wives demanded husbands go out on social gatherings with their friends.

But despite it being such a predictable question, it’s something I never really had a satisfying answer to.

It wouldn’t have been so awkward if I was a firefighter, doctor, teacher, butcher, or astronaut  You know, easily definable occupations we all wrote about as kids and coloured in colouring books.

“Business analyst” just doesn’t fit neatly into pre-conceived notions of what a job should be like. It’s rather new-ish, relatively abstract, and not quite defined the same everywhere. Different companies have different meanings for the term.

But I came across an interesting post that contained a little nugget on what a business analyst does. The post is about building a web analytics team, but I think the article is really about building any analytics team, web analytics or not.

From the post: by Jim Sterne, founder of the Digital Analytics Association, about what an “analyst” does:

The magical person called ‘the analyst’ understands all the data and how it is captured and how reliable it is. But they also understand what optimisation is about and what the business process looks like and what the business goals are. The analyst is that magic place in the middle where they understand the desired outcome, they comprehend the big picture and can look at Big Data and ask the right questions. It is the creative part. But they also have to be really good at communicating their insights out to the marketing people and the business strategy folks because if they have a great insight and they don’t know how to communicate it, it doesn’t matter.

Here’s as good a description as any I’ve seen about what an analyst does. Unfortunately not quite the elevator pitch of a business analyst that I can give.