Skip to main content

Author: Marcos Ferrer

Everything We Need to Know We Learned on Sesame Street

Written by Marcos Ferrer on . Posted in Articles.

“Some of these things, are just like the others, some of these things are not quite the same, can you guess which things…” Analysis is the “anti-methodology”, always seeking coherence, relationship and significance rather than exclusion.

Let’s use some BABOK categories to organize stakeholder “stated requirements”. In the process we will see how we can distinguish “requirements” from requirements when we model potential solutions.

Let’s say your stakeholders have stated things like:

  1. We want to reduce data entry errors
  2. We want to increase sales
  3. We don’t want to change the work or conditions
  4. We want easy to use
  5. We want users to write their own reports instead of waiting for IT
  6. We want happy customers
  7. We want to buy this in ONE software package
  8. We want to outsource all software configuration and maintenance
  9. We want large monitors, aluminum cases and wireless keyboards on our PCs
  10. We want to capture name and address and contact info everywhere
  11. We want users to have the freedom to override business rules
  12. We want a consistent high quality customer experience
  13. We want the system to pick the best approach
  14. We don’t want managers interfering with our work (micro-management)
  15. We want easier, better scheduling with fewer disruptions
  16. We want to get rid of old technology
  17. We want direct access to the database
  18. We want reliability, maintainability, scalability and no irritability
  19. We will know it when we see it but no sooner
  20. We must have everything built before release
  21. We must be able to change any business rule after release, so we don’t have to figure them out now.

That’s a nice sample of a typical list – we are ignoring things like “We want the requirements to be what we wrote down in one meeting” and “We want to design the system architecture because we write the checks” and “We want this done better, faster, cheaper”. That is a different list for a different essay. Those statements are not presenting as requirements but are attempting to dictate methodology or the lack thereof.

SO – given BABOK categories that follow, what goes where? Do some statements impact multiple categories? What can you extrapolate from the above to “discover” unstated requirements?

  1. Business Requirements
    1. Business Goals / Objectives
    2. Business Needs
    3. Capability Gaps
    4. Solution Approaches
    5. Solution Scope
    6. Business Case (what matters, how it matters and why it matters)
  2. Requirements [STATED]
  3. Requirements [ANALYZED / MODELED]
  4. Business Analysis Plan
  5. Solution Requirements
    1. Functional
    2. Non-Functional / Qualities
  6. Transition Requirements

One “breakdown” might look like:

Arrrghh – not AGAIN! We are left to think about it until a future blog.  Doesn’t the author understand that thinking is hard?

The answer is yes – the author knows. Thinking IS hard, the brain uses more oxygen and energy than any other part of the body. People who would never think to run 50 miles actually believe that their thoughts go just as far as anyone else’s. The same folk who might admire an athlete without thinking that they should compete with the athlete have no trouble believing that they know as much about creating business solutions as a performer with an actual track record.

Are you a BA thinker, or just a participant – another talker? Are you a modeler, or just a scribe? Your ability to handle this exercise is your answer.

For those of you who do practice modeling / technical BA skill, here is a cool diagram showing ALL the requirements “types” mentioned in the BABOK. Can you use each one in a sentence?

Cool Diagram:
ferrer Dec8

NEXT TIME – SYNTHESIS.

Don’t forget to leave your comments below.

Less Talk, More Walk

Written by Marcos Ferrer on . Posted in Articles.

Analysts are thinking people and don’t always realize the power of the physical body to implement best BA behaviors. We sometimes believe that our thinking can walk us to requirements success; I propose a different, compatible approach – you can walk your way into better thinking.

Let your model do the talking:

Have you ever been a part of the meeting that never ends, the discussion that goes in circles, the misunderstanding that becomes the decision, and the ego clash that kills collaboration?

As a young BA I often tried to hold my own in these discussions, and always felt that I could see the way to resolution, if only they would listen to ME. In trying to talk others into the BA walk, the BA just becomes another loud voice in a chaotic room.

Nowadays when I hear a complex, ongoing discussion, I keep my mouth shut (OK, I try) and work hard outside the meetings to MODEL the issues. Just writing them down can help, because it simplifies REMEMBERING everything.

Even better is to characterize the discussion in BA terms (goals, objectives, business needs, capability gaps, strategic solutions approaches, and scope and business case. Showing these things in pictures AND words means that visual and textual cognition is covered.

What about “hands on” cognition?

Do walk-throughs where the group does the work:

No model helps if no one “reads” it. One of the funniest things you will ever see is a confused group suddenly presented with a “pretty” diagram. “Oh, I understand that better” they will say, often oohing and aahing UNTIL YOU ASK A QUESTION about the concepts in the diagram. If you watch closely you will see them look back at the diagram for answers, not having really looked at it closely before, and not having read any of the words on the picture.

When working in any group, walk them through the model, step by step, letting THEM explain it. This process will far exceed the ability of YOUR thinking to move people, will give them REAL involvement, and will position them to explain the concepts to others.

What about bad ideas wasting time – doesn’t the BA have to stop this?

Be the “yes” woman:

Anytime a facilitator (as a BA, you see yourself as a facilitator instead of a decidadator, yes?) tries to stifle an idea before it is worked out by the group, the idea can become “locked” in the mind of the proposers.

A classic example is Roe v. Wade – most states were (slowly) moving towards freedom of choice (no letters or comments – this is NOT advocacy – prove you can read by finishing the paragraph) for women, recognizing that childbirth was a serious commitment and physical risk for women. When the Supreme Court stepped in and interrupted the state-by-state debate, the debate became locked in place, to this day.

Compare Roe v. Wade with the recent Supreme Court decision to let the state courts and legislatures keep working on the gay marriage issue. If we get to the point where 50 states have all decided that equal opportunity actually matters, THEN IT WILL MATTER, and the court will have let the country decide.

Whatever your political opinions, if you say “yes” to stakeholder ideas, and THEN MODEL, the strength or weakness of the ideas becomes visible and easier to understand. The group is then able to make good decisions OR shoot themselves in the foot ON PURPOSE, with the best information available, since no ideas are discouraged.

Stop telling everyone about your knowing – seek the facts:

We all know what’s going on, until we look. Anytime there is a disagreement about facts, it is a sign the facts aren’t know. Stop promoting your opinion, and recruit help in finding the facts.

Facts are harder work than opinion. You can add value to the group by being willing to admit what is known AND what is NOT known. Much of the info might even be in the current system – get IT involved.

Drive requirements from process, not data (nor interface, which is slow listing of data):

Ever seen the system full of data that no one can use? Some reporting systems are like that – you can choose ANYTHING to include in your report, with NO CLUE as to WHY you would ever care.

Data is STATIC – a list of data has NO BEHAVIOR – not even if listed on a GUI mockup. The behavior is process, and the only processes that count are the ones that get work done, NOT the ones that “draw screens”.

When work processes drive requirements, the requirements tend to lead to accomplishing the work of the organization.

If this is wanted, it is a big win. What if it isn’t wanted?

Don’t confuse your attitude with your stakeholder’s attitude:

As a change agent, BAs love change. Even stakeholders who want change don’t love change (mostly). Remember that the work you enjoy is painful for your stakeholders, and join them in the pain, even as you offer slivers of hope.

Explore with your stakeholders instead of talking at them, and you will BE the BA.

Be Patient:

One reason that you are a BA is because you are good at understanding and organizing ideas. Don’t be upset or impatient that it takes others longer – at best you become the “superhero” that delivers things faster than a group can, so the group can RIP ON THE WORK after the fact instead of before (expensive). At worst you will be so frustrated that you will not be welcome at all.

The walk to perform is to continually return to the highest-level descriptions, over and over, even as you drill into the next levels down. Repetition of the “main message” is not a waste of time but actually creates bonding at the common level of understanding (a good complement to this blog is “The Four Obsessions of an Extraordinary Executive” by John Lencioni).

When the top-level descriptions are better understood, the next level discussions are much more productive.

Take leadership (and other) training and give leadership (and other) training.

A BA who has nothing to learn also has nothing to teach. Stop it now. If you get a chance to teach, take it, it will open your eyes about what you REALLY know (not much) and what you can offer others (a lot).

Thanks for being a reader – the world is your oyster!

Don’t forget to leave your comments below.

BA-elzebub’s Glossary Three – The ‘A’s

Written by Marcos Ferrer on . Posted in Articles.

My brilliant readers know this piece of fun. Get credit in my next blog by offering “B”s in the comments at bottom.

A, CY: Don’t make me spell it out for you 🙂

AAA: See Alcoholic Analysts Anonymous.

Aardvark: Unlikely boundary to BA-elzebub’s Glossary (see “AAA”).

Absolute Zero: Numeric, one byte datum probably not created by accident, but maybe.

Accuracy: Not the same as precision, nor validity (usefulness or applicability). Don’t make me Google it for you!

Acronym: ASCWTEACOTTIAFWSATD (A short clear way to express a concept or thought that insiders are familiar with, such as this definition).

Adipose: Part of a satisfied stakeholder’s state, as in “Adipose and anti-sad.”(YOU Google for “happy” synonyms)

Aeon: Amount of time it takes to deliver “everything” as asked.

Afferent: A better word to use than “olfactory” when describing a project. Example: “When we started this project it was relevant, but now it is positively afferent!”

Agenda: A personal secret goal, distinct from, and more important than, the purposes of the meeting.

Agile: Quick enough to dodge reading, duck writing, and stick to binary ‘rithmetic.

Agreement: A formal misunderstanding adopted for the common good.

Ahora: Cuando quieren la sistema (See “Ayer”).

Aim: Business activity typically following “Fire, Ready”.

Aimless: See “Aim”.

Airball: A word from basketball. Also, what an ‘airy cat ‘acks up at ‘ome. Why, what were YOU thinking?

Ajar: The only word (Scrabble Dictionary EVIL) beginning with “Aj”.

Akinesia: Motionlessness due to a paralysis (of analysis? – See “Analist”).

Alcoholic Analysts Anonymous: Likely boundary condition on BA-elzebub.

Ambiguous: Examples:

  • Can Can
  • Quality Test
  • Assumed Risks
  • Technology Constraints
  • User Friendly
    Also, one who is able to “take guous or leave it.” Not to be confused with Bi-guous or Bi-guouscurious (The “B’s have begun!). 

Analist: Any list longer than people will actually read.

Analysis: Thought.

Analysis, Business: Somehow different from thought.

Analysis, Business, Monkey (MBA): See “Software Purchased on Golf Courses.”

Analysis, Data: Plural form of “Analysis, Datum”.

Analysis, Enough: Would choke a horse (See the artwork “Body of Work” at top).

Analysis, Strategic (nee Enterprise): “Find what’s broken that can’t be spoken.”

Analysis, Business, System: Fixing golfware at 50X the cost of “Analysis, Business.” Also – definition of “pay me later” in the popular colloquialism.

Analysis, Psycho: For that special “someone” stakeholder.

Analyst, Psycho: “Stake” holder for that special someone.

Analytics: The idea that increasing the amount of “garbage in” will – what exactly?

Aorist: Tense in ancient Greece, indicating a past activity that is done, with no reference to any structure, beginning, middle or end. Example: “The Ionian Peninsula Project (ancient Greece), made me nuts” (Tense – see how it works ). In this “tense” the event is one whole unit, all over and done (perfective). As opposed to “It made me nuts not knowing how the ionian Peninsula project was doing last Julius / Augustus” (imperfective) (You can look it up! Thanks Wikipedia!)

Aorta: The second word starting with “Ao”, including all its variants.

Aoudad: The third word starting with “Ao” (that’s all folks – beat “Aj” by two).

Approach, Solution: With great care, always asking it to “Put the spaghetti down and step away from the door.”

Aqua: Standard windows color, the use of which is almost always over-use (See “MAN!, Aqua, AGAIN?!”

Architecture, Network: Cisco Kid, was a friend of mine (please, no calls, I try).

Architecture, Software: See “Vaporlayer-ware”.

As-Is: A factual state of operations with as many versions as there are stakeholders (See “Az-Iz”).

Askew: Major requirements gap, as in “I’m not goin’ askew”.

At-Last: Project deadline that can always be reached (See “Expectations, Managing Without Getting Caught” for other examples.

Automation: A business solution approach that is worth doing (one that doesn’t move your cheese).

Auto-automation: When computers design and build computer systems.

Auto-auto-automation: When computers design and build self-driving cars.

Auto-auto-auto-automation: When cars design and build self-driving cars.

Auto-auto-auto-auto-auto-automation: When cars design and build self-driving cars for themselves (ba-da-BOOM! cymbal crash – yeah, really, it’s true, deny it if you can in the comments below, AND/OR get credit for defining the successor, which DOES EXIST :))

Autocrashtic: The voice telling you where to turn while you drive, having crossed its fine print when you agreed to the GPS’ license.

Automated: Obsolete, needing improvement.

Automatic: Not as automatic as you think (See “Automated”).

Aver: To state a requirement with plausible credibility –
Example: “Programming in modules will increase reliability.”

Averse: To state a requirement with plausible rhyme-ability –
Example: “Programming in modules will stimulate nodules.”

Avoid: A requirements gap resulting from sponsors cancelling meetings.

Awake, Network: Hypothetical ability of certain energy saving network printers.

Awesome: Last ditch attempt to influence a sponsor. Example: “Aw, some stakeholders are better than none.”

Ax, Can Hurt to: “The BA asked the CEO “why”, and got the ax.”

Ayer: Cuando quieren los requisitos para la sistema.

Az-Iz: A distant product owner with as many aversions as there are stakeholders (see “As-Is”).

Enjoy! And give BA-elzebub (not me!) some “B’s” below should your Brain Burst Bubbling with BA-slanguage Bonanzas of BA-rbarisms 🙂

How about definitions for Baseline? Button? Best Practice? Box? Benchmark?

Don’t forget to leave your comments below.

Requirements Come in Many Forms

Written by Marcos Ferrer on . Posted in Articles.

ferrer sept23sm“What’s in a name? That which we call a rose 
By any other name would smell as sweet.”
– William Shakespeare, Romeo and Juliet
“You say po-tay-toe, I say po-tah-toe……..You say to-may-toe, I say to-mah-toe…..
let’s call the whole thing off!”
– George and Ira Gershwin, Shall We Dance or Quit This Project?
 
Requirements come in many forms. For concepts slipp’ry ‘twixt our brains
Goals and visions, points of pain. Needs and wants, gaps versus norms
Approaches, scope and upside gains. Costs and plans, assumptions named

A business case, with risks in place. Analysis to gray cells whisked
Away in meetings, don’t explain. Don’t make us think – it’s HARD in rhyme
And only then transitions? — tsk!

Look and feel pushed to design. Test quality at rollout time
And if performance is not so keen? Don’t forget the root cause blame
Change requests, poor user training. So many words, what DO they mean?
– Marcos Ferrer, CBAP

Let’s use the BABOK 2.0 requirements definitions to decide what words mean (yay standards). BABOK recognizes 5 major requirements types:

  • Business Requirements
  • Stakeholder Requirements
  • Solution Requirements Functional
  • Solution Requirements Non-Functional (don’t tempt your users to agree here)

Transition Requirements

We’ll take a simple, yet frustrating example. An executive wants to organize all of the workers tasks around how much time it takes to do the task. The idea is to do more tasks by doing the quick ones first (don’t laugh – if you haven’t run into stuff like this you are a lucky BA, but may lack skill from lack of exposure).

What is wrong with this requirement? If your answer is “nothing”, you don’t have to read the rest. If you aren’t sure, keep reading. If you can articulate exactly what is wrong and why, you should be writing this blog.

Let’s break this requirement out into BABOK categories, across ALL the requirements types and levels.

Step one: What is the executive’s “requirement” in BABOK?

First and foremost, it is a “stakeholder” requirement, and requires some kind of analysis (thought) to make it into a “real” requirement. According to BABOK the “requirement” is “stated” and/or confirmed (“You really said that? – OK, got it”)

Step two: What kind of analysis?

We might consider breaking the statement down into more detail – what are the tasks and how long does each one take. This is the naïve analyst (naïve IT analyst) approach, and will lead to a failed implementation if not stopped immediately.

The business analyst approach is to consider the business requirement that is driving the stakeholder “requirement”. SO, what is the business requirement analysis that might help fix the stakeholder “requirement” (save it or build it – you are running out of time.

Maybe the business requirement is a vision: “Let’s do shortest tasks first so we can get more work done.”

NOPE – that doesn’t help – restating the stakeholder requirement as a vision leaves us where we were, and even BABOK says that “visions” are the least likely “requirements” to be ongoing / valid as stated.

Maybe the business requirement is a business need: “We need to do shortest tasks first in order to get more work done.”

ICK – again, restating the stakeholder requirement as a “business need” didn’t move the ball – we are still stuck with organizing tasks in an “overly simple” (to be kind) way OR getting into a fight with a stakeholder.

Maybe the business requirement is a capability gap: “We can’t get enough work done because we are not able to organize shortest tasks first.”

Phooey – this doesn’t help, because even though it is true (we are not able to figure out which tasks are shortest, and hence can’t do them first) it is not clear that filling this gap will result in a winning system.

Maybe the business requirement is a business solution approach, as in “Let’s get more work done by doing shortest tasks first”.

Hmmm… this might be better, if only because it shows that:

  1. We want to get more work done (or at least the executive does).
  2. We can use the approach of doing shortest tasks first.

NOW we have some analysis – we broke the stakeholder requirement into TWO parts – a business solution approach and another part. The other part – is it also a requirement?

BABOK offers solution scope business requirements, as in “The business solution shall get more work done.”

Nope – I have seen such requirements, and yet calling them “solution scope” is off.

BABOK offers business case requirements, as in “Organizing tasks to do shortest first will accomplish 10% more tasks in the same amount of time.”

This sounds like what the executive is imagining, but notice that the statement above is NOT a business case and hence is not a business case requirement. The statement is a “justification” statement with no evidence or analytical cost vs. benefit computation. It is, as stated, simply another stakeholder “requirement” – a statement of stakeholder thinking minus any serious attempt to prove feasibility or estimate payback.

To make this into a “business case” requirement would suggest making an actual business case, including feasibility (what are the shortest tasks – what happens if we try them first – what are the longest tasks, and their relation to the short ones?). I for one am in favor, and yet I know that if I insist on a business case it sounds like I am questioning the executive’s thinking, who (theoretically) is responsible for due diligence before writing checks for projects.

Again, NO GOOD, unless:

  • We don’t like the executive and want to be mouthy (demand the business case and avoid the executive by getting fired or whatever)
  • We intend to build whatever we think without discussing it and hence risking conflict
  • We intend to build what the executive seems to have asked for (that’s right – when IT builds what you tell them to build it might mean that “you asked for it” and how words don’t mean what they mean, be trilingual! and what’s more that the IT team figures you deserved “it”.
  1. You are an IT genius even though you chose to go into “people work” like management, or sales and got B’s (C’s?) in math.
  2. IT doesn’t like you enough to do what is right even though you won’t listen
  3. IT knows from experience that if you see any deviation from your exact instructions you will pitch a fit, and they gave up trying years ago., and are prepared to

We are out of business requirements, and surely we don’t want “Let’s do shortest tasks first to get more work done” to be a Solution requirement (functional or “quality” non-functional) or a Transition requirement.

What is the answer? How do you present the stakeholder requirement to “Let’s organize the system around “shortest tasks” first in order to get more work done.” In such a way that it opens discussion instead of shutting down communication and trust with the (very excited at the brilliance of her idea) executive?

Answer in the comments below for a chance to write your own blog in this very space (yes, with editorial help) and have fun, fearless BA readers!

Don’t forget to leave your comments below.

Business Analysts: Born or Made?

Written by Marcos Ferrer on . Posted in Articles. 1 Comment on Business Analysts: Born or Made?

The short answer is both – shortest blog ever or ??? IF you know BOB F., please let him know he can claim his prize from me for his excellent answers presented in my last blog.

Back to our topic.  I for one have often blamed :)* my mother, Kathleen Ferrer (nee Morgan, September 26, 1923 – June 26 2014), the only person who both bore me and made me. I often thanked her for my life and her influence, and will miss her very, very much.

I thought I would try to investigate the common experiences or characteristics that lead one to an ongoing BA career.

So, here are some data from my life, left blank for the moment. Fill it in on paper or in your head if you wish, AND EVEN BETTER – Click here to link to the survey:

Then contribute YOUR experiences and characteristics (anonymously) to help all of us BAs and BA wannabes know – Born or Made?

All participants will receive a summary of the survey results if wished 🙂

Date of Birth: ______________

Gender: ______________

Age learned to read: ______________

Who first taught you to read? ______________

Age first fell behind in math: ______________

Who taught you most of your math? ______________

Number of houses growing up: ______________

Maximum distance between any two of these houses in kilometers: ______________

Minimum distance between any two of these houses in kilometers: ______________

Most advanced Business Analysis certification or degree achieved:

CCBA
CBAP
Other Business Analysis certification [give the acronym]: ______________

If your own experience suggests a new question relevant to your path to BA, please add it in the blog comments below. Nice to hear from you, readers are so rare in today’s world, and writers more precious yet 🙂

————————————————————————————-

:)* Blame, in my blogs, is always a joke. My true belief is that blame is a stone-age behavior in an information age culture, and is just as useful in that evolving culture as the sheet music to the song “In the year 2525” would have been during the Cambrian explosion. I could, of course, be completely wrong.

Don`t forget to leave your comments below.