Work - Intuitive Business Analysis - Part 2

Intuition is a difficult thing to describe.  My experience with intuition in it's most basic sense seems to be simply a collection of knowledge points that, when combined, trigger some kind of little flag in my mind.  

When I was younger I used to sometimes have very strong reactions to conversations I was having with someone.  The best way to describe it was that the words I was hearing suddenly faded into the background as my brain focused intently on something else that was less tangible.  I would not be able to recall a single word spoken to me during those moments, but I could intensely remember how I FELT.  I later associated these instances with being lied to, but it took me a lot of time and experience to recognize it as such.  It was difficult to learn to trust my "gut instincts" with people when it seemed like such an irrational way to relate to others.  I wanted desperately to be able to accept others at face value, but learned that others sometimes had hidden agendas and motives.  

When dealing with people, I now know that if I feel like something isn't on the up-and-up, I should become suspicious and I start analyzing.  I've also developed a certain amount of reservation when providing information to others, I suppose as a form of self-preservation.  I slowly test people as I come to know them, revealing little things that I know to see if they are a reliable confidante.  If they build my trust over time, then I may come to rely heavily on them as a person I can speak freely with... provided that my intuition doesn't send up some other kind of warning.

My intuition though is at its strongest when dealing with computer systems.  As I've grown older and accumulated more I.T. knowledge it seems to be easier and easier to just know what's wrong when something is broken.  Experience is a part of it, but there is also an uncanny ability to point directly to the source of an issue without knowing exactly why.  90% of the time, I am right on the money.  

For example: I was working on testing an IVR system recently and heard an "Unexpected Error" message that plays when some sort of failure occurs... basically a system error indicator.  I have heard these messages in the past, and each time that I would call back to test the data again to try to reproduce it, I proceed without error... so I assumed it had been a temporary glitch in the test system or some sort of connectivity hiccup with the database.  This time though, I knew something wasn't right.  I had been systematically tracing every step, every change in the databases as I performed tasks in each system as I went along.  There were two web-based applications, multiple mainframe sockets, Oracle database procedures, IVR logic and an underlying shared backbone application at work in this process, so my review and documentation had been slow and painstaking.  I knew there shouldn't be an issue.

I checked the Oracle table and sure enough, the data had changed.  I knew the Update procedure had run and succeeded... but there were a lot of other decision points in the IVR call flow between that update and the next voice prompt.  Any one of those could have caused the error.

I reviewed all of the data as it had existed during the call and didn't find anything that should have caused a failure.  The data was sound and the decisions matched the path I thought I should be on.  My eyes settled on the Oracle update reference and I knew that something had gone wrong with the Oracle update, even though it was successful (according to the data).

After the vendor reviewed my test and the data I provided, they found that a Boolean result path was opposite of what it was supposed to be.  When that update into Oracle was successful, it sent back the correct response... but the phone system developer had mapped the Success flag to go down the Failure path.  The hilarious, evil, devious part of the thing was that once that Oracle table was updated, the test could not be reproduced because the query INTO that table on subsequent calls would turn the caller down a completely different path.  One little keystroke, done years before when the system was developed, had caused an error that could not be reproduced.  It was a hunch... one Unexpected Error out of a hundred that I'd heard in the last couple of years, but this time I knew that something was broken, and I could fix it.

A similar thing happened a few months ago.  This time it was a set of events leading up to a chance review of data that caused me to stumble across it.

We had implemented another phone system about 8-10 weeks prior, and I decided to request a tally of the 'checkpoints' we had built into the system that basically do a count of every time someone passes a certain point in the call flow.  Each one was labeled, and since I had been the Analyst and PM on the project, I knew the call flow inside and out... in my sleep.  (Fifty revisions of a detailed change request literally appeared in my dreams before the project was rolled into Production.)  The system was a nimble gathering of determined information that ultimately resulted in a push to the mainframe where the data was stored.  

The familiar labels and their tally's landed in my inbox and after seeing a dramatic difference between the number of people calling versus the number of people who reached the end where the data is submitted, I decided I would outline where we were losing the callers to see if anything stood out.  When I was finished, most of the dropped calls could be accounted for (transfers, etc) but there was one area that had a drop rate of over 50%!  It was in an area that requested a four digit date to be input, that would then be verified against the Oracle database.  It seemed strange that so many people would enter the wrong date and ultimately be routed out of the system.  

I passed my findings along to the business and then it was on to other things that demanded my attention.  

A few days later, on a separate project, I happened to be sitting with the DBA, reviewing data with him at his desk.  He ran a few quick queries, briefly pulled up a table and scrolled a few times before we moved on to the next... but something had caught my attention.  I stopped him and backed him up to the previous query results, looking at the field that held the date that so many people were unable to correctly enter.  Some of the fields only held three digits.  Three??  But it's a four-digit entry... MMDD.  I knew that the phone system validated the input on the front end, so how could this be possible?

We realized that the Oracle field was a NUMERIC field... which was dropping any date with a leading zero.  The very first record in the table, dating back to years ago, had only three digits.  This explained why so many people were dropping off as they tried to authenticate against this field... up to 3/4 of the dates available in a year wouldn't work!!!  Only dates in October, November and December were technically 'valid' as a four digit date that we were asking callers to enter. 

The combination of timing and circumstance made it possible to find and fix the problem.  I was both proud and disappointed in myself.  Proud that we had found it, almost by happenstance... but disappointed that it hadn't been discovered in my own testing of our new system.  For the sake of ease in test cases, I had been instructed that the default date of "1111" was entered into all of the test cases whenever asked for, and it didn't occur to me to question it or use anything else.  In the name of speed in testing, we had committed a Q/A sin.

Intuition is a tricky thing.  Sneaky.  It creeps up on you when you aren't looking for it and sometimes it can "miss the forest for the trees".  More often than not though, I believe it makes connections that seem unrelated to others... and helps me find the true source of how things work.  There is something very satisfying in discovery; in new understanding.  I am glad, all things considered, that I have such a powerful tool at my disposal... even if I can't control it.

Work - Intuitive Business Analysis - Part 1

Like many who enter the workforce, my early "careers" were unimpressive.  I worked in retail, I worked as a waitress, I worked as a fast food restaurant cook and cashier.  Some jobs were better than others... I made a terrible waitress and actually feel sort of bad for those who were unfortunate enough to have me as their attendant.  I had no sense of haste about me, no ability to anticipate their needs and frequently forgot things that were requested.  My mother tells me that I once told a person who asked for ketchup that they didn't need it.  (I don't remember doing it, but she insists that I did... and it isn't really that unlikely.)  

My first real job was as an accounts receivable clerk, making outbound calls to collect on unpaid accounts.  While my manager saw potential in me and recommended me as his replacement when he moved on, my lack of inter-personal skills cost me the final votes to actually gain the position, even after serving in that capacity in the interim.

A murky career as a car salesman/office administrator brought me at long last to the beginnings of my IT career at the age of twenty six.  Over the next five years I accumulated a vast amount of experience in a multitude of areas.  I had no idea how much I was learning.  The company was small when I was first hired, and more than doubled in size while I was there.  A constantly changing work environment where everyone has to wear every sort of hat imaginable was a dream come true for someone with the curiosity that I carried in me.  My ideas for improvement were often implemented and I was exposed to and participated in many facets of the company.  Technical documentation, business analysis, data analysis, development, system testing, project management, release planning, public speaking, training, help desk support, forums management, newsletter editing, contract management... the list of things that I learned is very long.  My successes though eventually lost their luster because I still did not understand the impact that my words could have.

While my list of successes grew and the size of projects that I tackled became more complex... I believe I also managed to become a thorn in the side of upper management.  My tendency to always point out the things we were "doing wrong" was surely wearisome after a time.  The language that I used to describe problems was often out of proportion with the true scope, and I frequently used strong words so as to be taken seriously, perhaps.  I could clearly see the things we needed to change, and I could not easily describe to those around me why I had arrived at my conclusion.  Instead, I used emphatic language to convince my audience of the importance of the change so that they would support my ideas.  The behavior was juvenile and I was rarely aware of this tendency in myself at the time.  Looking back, I hope that I had some sort of positive influence and lasting impact on the business, but if I had a chance to do it again I would go about it differently.  The lesson was learned only as I was on the verge of leaving.

When I finally resigned and moved on to the next step in my career, I was well prepared to meet the challenges of my new career path of Business Analyst.

I distinctly remember my first interview.  Four people sat across from me and asked me questions at what seemed to be a breathless pace.  I barely finished responding to one question when another was asked.  This went on for an intense hour and my head felt as if I had whiplash from redirecting my attention from one end of the table to the other.  Finally, one of them gave a small smirk to another and I knew they had a trick question incoming.  The woman finally said "Is there anything we should have asked you today that we haven't already asked?"

My brain short circuited... this wasn't a fair question!  I was now on the spot, under pressure and frazzled from an hour long barrage of interrogation.  I could barely even remember what they had asked me anymore.  My mind could not think, and I literally had no words.  I scanned my notes.  I felt the heat rising in my cheeks and it seemed like an eternity ticked by.  Just as I began to raise my eyes to the questioner and began forming the hopeless (interview killing) response of "I have no idea." my brain suddenly flew into action and the words that came out sounded like this:

"It seems, from your questions, that experience with mainframe systems is a critical requirement for this position.  While I do not have any experience in this area, I think that perhaps if you had asked me how quickly I can learn a new system I could have told you that I am extremely good at understanding new things.  I am not afraid to research things that I don't understand.  I believe I could learn and be up to speed in this area in a very short time."

I got the job.

In the moment that I stopped thinking about the problem, my intuition identified the one major gap in my credentials and reassured my interviewers that it wouldn't be a problem.  

This phenomenon of instinctively falling into a solution is not unique to INTJ's... everyone has the potential to use their natural abilities and become successful analysts.  For me, being placed in the B.A. role fit my natural tendencies in a very fulfilling way.  I felt like a fish who had been gasping for air on dry land and then suddenly finding itself tossed into a lake.  I am at home in the analysis world, and hopefully this blog can provide some insights that are helpful to others in the B.A. world.  

Part 2 of this entry will provide some specific examples of intuitive understanding, and how it can be harnessed by others as well.

Stay tuned!