Business Analysis

Image

Software mirrors organizational values, or: an error message annoyed me enough to blog about it.

1 Comment

I just had a moment where several points I’ve been making to colleagues about organizational culture, the myth of software’s neutrality, and poor user experience choices came together in one package. It was the intersection of Conway’s Law, cultural anthropology and user experience design.  Unfortunately, the outcome was… not great.

On my current project, I’m responsible for approving the deployments to the Dev environment.  My project is using Microsoft Team Foundation Server (TFS) for build and release management.  After I approve a deployment, the system provides a response as to the success or failure of the deployment.

For successful deployments, I see this:

Succeeded

Pretty straightforward, right? I can see the request I’d made to the system succeeded, and some metadata about the deployment.

However, when the deployment fails, I see this response:

REJECTED

Uh, what?  Shouldn’t that say “FAILED” instead of “REJECTED?”

This is a perfect example about how the values of an organization slide into the software it produces. From my long experience working with Microsoft products, I know errors are assumed by default to be caused by the user behaving incorrectly with the software, rather than the software failing to meet the expectations of the user.

My expectation is not to have a system “REJECT” my request when it couldn’t successfully complete the requested action, but instead report its own failure.  But Microsoft believes as an organization that users are more likely to misuse their products than their products fail users.  As a result of this attitude, developers frame the status messaging as an assessment of the user’s ability to do things “correctly” rather than the software’s ability to respond as expected to a user request.

There’s been plenty of trench warfare in the UX community about whether systems should apologize for errors, so I won’t rehash that here.  I fall squarely in the camp of being delighted by systems that own their errors, rather than blame me for them.  I was immediately irked at TFS’s rude insistence on leveling its judgement of my deployment request. I’m usually neutral to mildly amused at apologetic messages from the various applications I use that clearly center a user (Chrome and Discord come to mind).

Next time you’re designing or building error handling routines, consider whether your system is both failing its user AND being rude about it.

Done is Better than Perfect

Leave a comment

Hi. I’m Alex, and I’m a Recovering Perfectionist.

I have struggled with the demons of perfectionism as long as I can remember.  Without getting too deep into the gory personal details of my upbringing, suffice to say I was raised to be a Perfectionist.  Not just any Perfectionist, but the Most Perfect Perfectionist.

I learned from an early age that effort was not enough, if it resulted in anything less than excellence.  I was that child who was a superior student, involved in activities, volunteering in the community, working a part-time job while applying to Ivy League colleges.  In some ways, perfectionism helped me achieve, but in many others it crippled me with anxiety and destroyed my self-esteem.

I have spent years working on my own thoughts and behaviors to embrace a gentler way of regarding my self worth and my accomplishments at and outside of work.  I started by setting a mantra for myself:  Done is better than perfect.

Continue reading →

The Conduit Metaphor of Communication

Leave a comment

I find myself telling and retelling this story about the Conduit Metaphor by way of explaining that how we talk about communication is important to understanding where breakdowns in communication can occur in Standard American English speakers.

Michael J. Reddy described in 1979 the Conduit Metaphor used by Standard American English (SAE) speakers. This demonstrates how we think about communication.

Continue reading →

On Being a BA: The Question Behind the Question

Leave a comment

[Part 5 of a 5-part series of posts about ways of being while being a Business Analyst]

I have this handy article about “Disguised Queries” that gives a great metaphor for how to talk about the differences between ‘good’ and ‘great’ requirements.

Asking people to just deliver their requirements to you, fully-formed, in the first interview is untenable.  People frequently can’t think like that.  It’s another reason why we stopped saying “requirements gathering” and started saying “requirements elicitation” — because the requirements aren’t laying about to be scooped up.  You must prize them from people’s minds!

The cool part about the article shows that how we talk about a thing can change, depending on what we need to know about that thing, or do with that thing.

Continue reading →

On Being a BA: People Problems, Not Technology Problems

Leave a comment

[Part 4 of a 5-part series of posts about ways of being while being a Business Analyst]

Oftentimes, we talk about issues related to software requirements as if the problem is technology-related.  But given the time, money and priority to work on something, we can make technology do anything.  Our problems stem from people more than they stem from technology.

We have a client with a process that is documented one way, but in the wild is never done like that.  The systems supporting that documented process aren’t working for the ad hoc process, and thus, the system is blamed for being buggy, or lacking in functionality.

The problem was most likely that we accepted the first thing we got when we asked about the process (the documented version) and didn’t dig deeper.  The management-level people were disconnected from the worker-bee-level realities, and didn’t have those worker bees at the table to tell them otherwise.

Which is not to say we were lied to — although sometimes that happens! — but instead to say we needed to hear from more voices.  We needed to validate the information about How Things Are or How Things Need to Be with the people who are “living the pain” right now.

Change resistance isn’t typically because something is not technically feasible, it’s because of fear.  Inflexibility isn’t typically about how a business works, it’s about distrust.

The more we listen to the people, the more likely we are to get closer to the primary source of the problem.

  1. Requirements as Art (not Science)
  2. These Aren’t Your Requirements
  3. Requirements are Never Done
  4. People Problems, Not Technology Problems
  5. The Question Behind The Question

On Being a BA: Requirements are Never Done

Leave a comment

[Part 3 of a 5-part series of posts about ways of being while being a Business Analyst]

That’s right, they are never truly done.  We could analyze until the oceans erode the mountains and still not completely understand a problem or capture every potential scenario of a process.  As a recovering perfectionist, I personally struggled with this the most.  If we just had more time then we could truly understand!  Except we need to eventually DO something about our technical issue or business problem.  We can’t spend a lifetime in quiet contemplation of the finer points of claims processing, inventory management or mobile user behaviors.  We have to do just enough, just in time to depict the needs of the clients in an actionable way.

Concrete thinkers really hate this part.  They want to be certain, and BAs live in a world of nuance, uncertainty and ever-shifting priorities.

Our challenge, should we choose to accept it, is this:  Change is inevitable, and should be welcomed.  How can we be effective at getting things done while being flexible about letting things change?

Methodologies and processes do most of the tactical heavy lifting here, but business analysts do almost all of the expectation management.  Understanding how change affects people will go a lot further toward elegantly handling change than understanding how change affects project timelines or budgets.

Other posts in this series:

  1. Requirements as Art (not Science)
  2. These Aren’t Your Requirements
  3. Requirements are Never Done
  4. People Problems, Not Technology Problems
  5. The Question Behind The Question

On Being a BA: These Aren’t Your Requirements

Leave a comment

[Part 2 of a 5-part series of posts about ways of being while being a Business Analyst]

Something I see with junior BAs a lot is an ego attachment to the requirements they produce.  When the requirements change, they get upset.  They are disturbed when the beauty of their creation is unwound by one missing stakeholder who turns up with their pile of messy ideas to add to the mix.  They have an anger response to revisiting approved requirements.

As a business analyst, you facilitate the expression of others’ ideas to feed the work of even more people.  Diplomat, translator, liaison, messenger, advocate, shepherd.  That’s what we do.  It’s not about us as business analysts, it’s about representing your customers’ or users’ ideas to the best of our abilities.

It takes conscious effort to recognize how you are reacting to change, and making a different choice in response.  I try to frame requirements changes as a gift. I’m grateful to my colleagues and clients for helping refine the requirements and making them as accurate and relevant as possible. The cost of change skyrockets once the functionality leaves the requirements phase, so it’s a cost-saving move to change requirements early on.

I like to joke that managing requirements is like taking care of other people’s kids.  We’re responsible for their care and conduct when they are under our supervision, but the qualities of the requirements were never ours… they belong to the parents/clients.

Other posts in this series:

  1. Requirements as Art (not Science)
  2. These Aren’t Your Requirements
  3. Requirements are Never Done
  4. People Problems, Not Technology Problems
  5. The Question Behind The Question

On Being a BA: Requirements as Art (not Science)

Leave a comment

[Part 1 of a 5-part series of posts about ways of being while being a Business Analyst]

There are many ways to express requirements as a Business Analyst.  There are templates and methodologies and analytics about requirements metadata… but all that quantifying effort fails to illuminate that requirements are not concrete things that can be effortlessly pinned down, categorized and defined. That’s why BAs stopped saying we “gather” requirements and instead “elicit” them.

Much of what we do as Business Analysts is to take messy ideas and complex situations and describe them succinctly.  This is what any system that has people as a component (e.g. all of them). We tend to lean on the hubris that we’re performing objectively.  That what we’re documenting is fact, reality, truth.

In practice, it’s more like a painting than a photograph.  Sometimes it’s an out-of-focus photograph of a painting of another photograph.  How close you can get to the primary source of the ideas will dictate how accurately you depict them.

Business Analysis is also a discipline you cannot study in school (this is emerging, but most of us “fell into” business analysis).  It’s experiential.  You get trained on some of those methodologies and templates and make lists of questions to ask and check them off one at a time and you still make mistakes.

Because you need to live through it to learn from it.  That’s really painful for people who are not genetically predisposed to analysis to fathom.  It’s why BAs will often answer every question with a long story as preamble to their reply.  Because there is more in heaven and earth and their requirements, than are dreamt of in their philosophy.

Other posts in this series:

  1. Requirements as Art (not Science)
  2. These Aren’t Your Requirements
  3. Requirements are Never Done
  4. People Problems, Not Technology Problems
  5. The Question Behind The Question