Analytical and Problem Solving Skills

Is your team struggling with the transition to modern requirements practices? As many teams explore and experiment with modern practices and agile, they often jump to apply tactical methods and techniques. But does anything really change?

Most teams work really hard and don’t see results. Or they find a few early benefits, but get stuck on a low plateau. They often give up and slide back into their old habits. Why? Because they’ve modified surface-level tactics, but haven’t modified mindsets.

I am constantly coming across alleged ‘business analysts’, many new to the industry, sauntering confidently into a project or an organization. Typically, the first thing they do when assigned requirements elicitation is organize a workshop. These people are engaging, charming, energetic, and, in many cases, evangelistic. They are very adept at gaining the undivided attention of their audience.  However, their primary and, in most cases, their only concern is determining what the client wants and what the problem is without a thought to a workable action plan to improve anything. 

Customer journey mapping is a great way to understand your customer intimately to provide insights into providing targeted customer experience that empower the customer positively to drive better business outcomes.  This technique places the customer first with a deep emotional understanding, then looks backwards toward the experiences provided by the operating model, thus enabling good aspects to be reinforced and negative ones to be managed. It provides a complete 360 end to end experience of the customer to be realized driving customer insights, allowing more blue sky approaches to offsetting emotional deficits...

People sometimes say that requirements are about “what” and design is about “how.” There are two problems with this simplistic demarcation.  This makes it sound as though there’s a sharp boundary between requirements and design. There’s not. In reality, the distinction between requirements and design is a fuzzy gray area, not a crisp black line. I prefer to say that requirements should emphasize “what” and design should emphasize “how.” 

A few words to set up the story - my daughter is going to have a cyst removed from her left wrist. It's not a complicated procedure but she will be going in outpatient surgery on Dec 20 of this year. Now here's the business analysis part of the story.

Do you know? If not, should you? I’m using BA as an abbreviation for Business Analyst (really, though, it’s one who performs business analysis regardless of the title) and BOT for “Business Order Taker” (also an abbreviated term for ROBOT). They are different in the way they approach business analysis.

...Why, even with the word Analyst in our title, is the role of BA more associated with requirements rather than analytics? My hypothesis is pretty simple:  If Business Analysts are not required to produce specific analysis related artifacts, then both analytical competencies and requirements efficacy will be diminished.