Skip to main content

Author: Marcos Ferrer

BA-elzebub’s Glossary Five – The ‘C’s

My brilliant readers know this piece of fun. Get credit in my next blog by offering more “C”s (and “D’s”) in the comments at bottom.

C: The letter C, as in the acronym CDCTCX. Also used in the acronyms CZSG and CSZG, among others.

C Language: A coding language that does not tolerate ambiguity, just like all the other coding languages (Turing Machine Interfaces). Just like the strength of steel in a skyscraper does not depend on stakeholder preference.

C Level: Description of stakeholders who don’t seem to “C” very much that they don’t want to “C”.

Cache: Another word to not use with business stakeholders. Examples: “You don’t have enough cache to implement that solution” or “We will have to trade cache with the end user systems” or “We can get it done with enough cache.”

Call Center: Primary user interface, when the actual user interface is an afterthought (or designed by “experts” in computer science – see computer science).

Centralization: The solution to overly distributed systems, originally implemented to solve over-centralization.

Change Control: A process to bring the pace of change within the grasp of the businesspersons in charge, regardless of the pace of change outside the organization. See “Wishes and Horses”.

Change Control Bored: Yes, they are.

Coccyx: See CYA.

Code: An illness marked by a stuffed nose – e.g., “I hab a code.”

Computer Science: An extremely advanced topic, understood by all, apparently; at least by all the business people who think they want to tell IT persons what to do (no BA would ever do such a thing – these discussions are negotiations with facts, constraints and additional costs, not political mandates or battles of will)*. You would have better luck with construction Architects, who would simply refuse your business, instead of trying to do what you say, to your ultimate pain and skyscraper collapse. You know who you are, and it hurts your organizations, so stop it and get jobs you are qualified for, like saying “No milkshakes today” and “Have a seat while I measure your foot”.

Consensus: A formal misunderstanding adopted by all for the common good.

Constraint: A choice denied. E.g., “No building above high tide.” Or “No systems that could actually work”. See Kerneled.

COTS: Commercial Off-The-Shelf software, usually found laying around on some golf course, by lucky coincidence (the rep said so) perfect for complex business needs.

Costs: A set of facts typically hidden behind a sales price by vendors desperate to foist them on you.

Cost-Benefit Analysis: An analysis performed to evaluate the value of a particular solution approach as long as it doesn’t offend the ego of the sponsor who found it on a golf course.

Critical-Path: Any path leading to change. Example: “Why are you doing that”? “Because it might work better.” “That’s the wrong way, it’s not how we do it, don’t make me critical-path you”

Crux: The center of an unsolvable problem, or as BAs call it, Wednesday.

Customer: A stakeholder from whom secrets must be kept, for reasons that escape this particular BA, probably because I am not your customer.

CYA: Don’t make me spell it out for you 

Cynicism: A skill that can be useful in analyzing the meaning of certain stakeholder elicitations, if only one could keep up! Example: “As long as we don’t have to implement the website, free Medicare expansion sounds pretty good, let’s finally pass the ACA.”

Enjoy! And give BA-elzebub (not me!) some “D’s” below (Disagreement, Database, Cynicism, Customer, Cost-Benefit, Critical-Path more) should your Cranium Crave Creative Comprehensibility by Chuckling Colleagues 

* “Reality must take precedence over public relations, for nature cannot be fooled.” Richard Feynman, re: the Shuttle Discovery investigation.

“There is a lot more reality in computer systems than there are either wishes or horses.” Anonymous, re: almost any enterprise system you can name.

Don’t forget to leave your comments below.

BA-elzebubs Glossary Four – The ‘B’s

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

BA: See Business Analysis or Business Analyst.

Baseline: 1. A method of slowing progress to fit communal bandwidth; for example, the monthly rhythm of a change control board. 2. A clear, consistent, concise definition of feasible requirements suitable for: a) ruining with last minute executive confusion and “demand” deliverables; or b) for improving with carefully considered change management.

BB: Profession following BA.

BC: See BB.

Benchmark: 1. The mark made on the bench by project teams that watch what others do, similar in value and concept to the “hashmark”. 2. Solution speed comparison tests, as in “Wow, Amazon’s on-line store put us out of business in less than 10 years.”

Benefit: 1. Value that a solution might provide if implemented successfully; 2. The source of stakeholder fear of a solution. Example: “Digital blueprints mean that we don’t have to drive all over the county fetching and delivering blueprints, but driving around is more fun than actually supervising sewer work, on-site, most of the day.”

Best Practice: NOT what you are doing. Believe it. Diagnose it. Now change it. Repeat. Now you’re getting it – oops, not quite! Keep trying.

Beta Test: Formal term describing a solution that is not ready for commercial release, but is released to a limited number of users who help by giving feedback to the developers. Apple modernized this practice by releasing to all users while dropping the “beta” designation and using the word “free” instead. Microsoft is fighting back by moving to alpha releases but continuing to charge money, giving the illusion of product maturity.

Bit: 1. An information technology word never to be discussed with a business stakeholder. 2. A canned response to common stakeholder concerns. Example: “When the stakeholder objected to the process model, the BA bit them in the ear and the stakeholder dropped the objection”.

Box: A polite word for those in an organization who write the checks for “change consultants”. They do this for their own protection. Example: “He wanted Org X to get out of the box, so he hired the change consultant, but it turned out that he WAS the box, so he fired the change consultant!”

BPMN: 1. A notation for modeling a business process domain for stakeholders who can’t pretend to read but have no trouble pretending to understand a picture. 2. An alternative to sticking with text rendered so large that it can be confused with a picture. See PowerPoint discussion by Edward Tufte.

Brief: A highly compensated, highly expensive way of communicating. The most successful executives are brief in their communications (“of course this will be everything you want”) and in their tenures (“good luck, it was nice working at you”).

BS: Business Synthesis. What did YOU think?

Bug: A critical yet unexpected system feature from a developer. These (widely misunderstood) features help ensure that the developer’s software gets tested thoroughly once it is already released. Testing before release is optional – see “Baseline”).

Business: None of yours, hopeful elicitor :).

Business Analysis: The precursor to Business Synthesis.

Business Analyst: Anyone precursing Business Synthesis.

Business, Monkey: 1. The illegal trade in endangered primates. 2. Any decision made in the “C” suite without any sense of the impact on end users.

Business Requirement: 1. As commonly practiced by business executives, a business requirement is any requirement promoted by a “business” person in the organization, suiting the “business ego” needs of that stakeholder, in direct contradiction to BABOK. Example: “When this is over, we will still be a Microsoft shop, won’t we”? * 2. As defined by the BABOK, a business requirement describes the needs of the organization as a whole, and not groups of stakeholders within it. Example: “When this project is initiated, existing systems must continue to operate without additional downtime, as measured by existing availability reports.”

Business Rules: 1. Code buried deep where no businessperson can find it, known only to programmers, who can’t explain it. 2. Arbitrary wants that are un-code-able, as they cannot be explained. Example: “The system should automatically pick the best employee for promotion.” 3. Actual policies that govern transactions and entity relations of great value. These policies are typically kept out of code so they can be modified on the fly by spontaneous human judgment. Example: “No insurance company should carry more than 33% of all liability” is easily modified to add the phrase “unless the insurance company is run by people who assure us that all is OK and besides they are our friends.”

Button: The solution to everything. Examples: “Can’t we just add a button”? or “Can’t the system just push the button for us”?

Enjoy! And give BA-elzebub (not me!) some “C’s” below (Cache, Cynicism, Customer, Cost-Benefit, Critical-Path more) should your Cranium Crave Creative Comprehensibility by Chuckling Colleagues 🙂

Don’t forget to leave your comments below.

Verify, Validate, De-Vaticanate. The Pope as Change Agent

ferrer March3

Who’d of thunk it? The Pope’s New Year speech offers insight into issues that affect MANY organizations. This courageous leader gave a list of fifteen sicknesses inflicting the Vatican organization.

This month I picked a few of these Vatican issues to discuss. I chose those that resonate loudest with the challenges facing transformational leaders working with “entrenched” dysfunctions. When such leaders clear the way, business analysis can help. Without such leadership, business analysis can only reveal what is “sick”, with no power to “heal.

To help relate the very Catholic analysis to secular organizations I have inserted suggested “secular” word changes in angle brackets .

How many of these are impacting your ability to perform the BA role? How many of these are “sins” of your own?

Pope says beware of:

The sickness of feeling oneself “immortal,” “immune” or in fact “indispensable,” neglecting the necessary and usual controls. A Curia that does not criticize itself, which does not update itself, which does not seek to improve itself is a sick body…It is the sickness… also of those who transform themselves into bosses and feel themselves superior to all and not at the service of all. 

As BAs we must be aware of the “requirements risk” of trying to satisfy stakeholders when business leadership is too busy, too important or too judgmental to participate. There are no business needs where leadership is missing or (worse) serving itself instead of the common good. Such environments will tend to focus on stakeholder wants.

Analysis becomes politi-technical (“can we make what the most powerful stakeholders want and not be blamed by the others?”). Business Analysis (“can we advance business goals and objectives with solution changes”) is no longer in play as a guiding pattern.

This is OK if we are changing systems that already serve our mission and need minor improvements. It is not OK when enterprise level transformations are in play. Consider the difference between the following two exchanges:

Exchange 1 (small):

Stakeholder: I want to have ice cream anywhere all the time.
Analyst: Here is a little ice cream that IT made just for us.
Stakeholder: Nice.

Exchange 2 (enterprise):

Stakeholder: I want everyone to eat ice cream everywhere all the time.
Analyst: Here is a little ice cream that IT made to help users imagine the actual dessert that would work for them.
Stakeholder: We can’t let them try it – they will just complain. Give me that serving of ice cream to critique, and then I expect you to produce the rest ASAP.
Analyst: Not so nice.

Pope’s antidote:

The antidote to this epidemic is the grace to see ourselves as sinners and to say with all our heart: “We are unworthy servants; we have only done what was our duty” <”please work with us to be better”> (Luke 17:10).

BABOK antidote:

Step up and “serve from behind”. If there is NO leadership at all (rare, but some “leaders” will command a project then disappear) then just pick up a broom and try to clear some space for a meeting. If there is little or no leadership from above (more common) then do your best to analyze and represent the wants expressed – to communicate IS our duty.

Pope says beware of:

…The sickness of mental and spiritual “petrification (sic)”: namely those who have a heart of stone and a “stiff-neck” (Acts 7:51-60); those that, along the way, lose interior serenity, vivacity and daring and hide themselves under papers becoming “practice machines” and not “men of God” (Cf. Hebrews 3:12).

As BAs we must be aware that physical cogs cannot change (design changes, cogs follow), and humans that have found cog-hood don’t want to change. BABOK 1.6 listed “Sales” as a key BA skill. BABOK 2.0 dropped “Sales” in favor of influencing. Same thing.

Pope’s antidote:

“Don’t be petrified, ask Jesus to help un-petrify yourself” and/or “you are fired” (I am guessing, Francis didn’t say).

BABOK antidote:

If you are not practicing sales skills you should practice ducking and bobbing. Try to help stakeholders find “what is in it for them” if they want anything at all. If you are really good at sales you can earn a lot more in sales (or as CEO) instead of as BA. BABOK is at a disadvantage to Jesus, who could move people with pure love and miracles, at least in His domain. IT projects; I am not so sure WWJD.

There is more from Francis, but not this month. What spirituality helps get you through your BA? Let us know in the comments below.

Have fun, try to laugh and remember – the Pope needs BAs too 🙂

Don’t forget to leave your comments below.

Keep Your Eyes on the Prize

ferrer feb3…IF you can tell what the prize really is. Let’s consider a list of potential “prizes” and the meaning of each for developing requirements.

THE Prize (by definition): Meeting Organizational Goals and Objectives

This ought to be the gold standard for developing requirements. Is it the standard at your organization? Try carrying the organizational mission, goals and objectives with you to share at requirements meetings. Whenever a debate erupts about some requirement, pull the goals out. Ask the group if the existing goals offer direction to resolve the debate. If so, the organization is practicing “BA behavior”.

If the group cannot relate the debate to existing goals, ask for any missing goals that ARE relevant. If the group cannot name any such goals, yet persists in the debate, your organization is normal, and does not practice the gold standard (or the silver or bronze either). The most extreme case of this can be encountered in certain government or academic institutions, who practice the “mushroom*” standard.

Example of the extreme case (fictitious, of course, no one would ever, really!):
BA: “What is your understanding of the organization’s vision, mission and goals?”
Stakeholder: “I try to stay out of that.”

If subsequent sponsor review does not clarify the related goals (or gets negative attention), you can be sure that business analysis is not in play AT AL. As a BA you can start to release the need to practice BABOK and can seek the most useful mushroom standard. You will do better to identify the true “prizes” in play from the list below, while complying with the “ignore mission” culture.

Secondary Prizes for BA “Eyes’es”

1. Meeting Actual Business Needs

This is where the best BAs live most of the time (see “normal” at top of essay). It is dangerous (some stakeholders might notice that meeting actual business needs is a lot like striving for goals), but might slip by, IF you keep an eye on ALL the following secondary prizes. Any of these can destroy good requirements by trumping actual business needs.

2. Serve the “Solution Approach” Regardless of Merit

Don’t get me wrong; the solution approach may be brilliant and relevant to business goals. It’s just that in the absence of clear business goals, any approach has little to guide it as decisions are made. The decision IS the approach, and everything becomes about “looking good” (see “looking good” below).

BA: “What was the most important consideration before buying ABC software?”
Sponsor: “It’s the best – everyone’s using it – You just stick to making the requirements work.”

Translation: My friends like it. When it fails, it will be a BA requirement failure – you failed to get the requirement – if you were a better BA, you would have gotten it from me, and you would have gotten it right.

3. Serve the Solution Scope

“You said you wanted all data in one query – you didn’t say it had to run at lowest priority!”

Only do this to people who scream when they get things wrong by jamming them down your throat. The others are no fun, and will just want it fixed without learning anything. When compelled to serve scope, don’t squeeze any in by working harder. It just encourages scope creeps, and makes managers think deadlines are reasonable. ‘Nuff said.

4. Serve the Business Case

No goals, no business case. That was easy. How does one estimate benefits without clear goals in mind? Costs are easy, and often the business case goes like this:

“We want X solution, it costs Y, we can afford it”.

Why we want X is left for another day, say after the sponsor is promoted.

5. Pleasing the “Fox” or Foxes

This is always a strategy when clear goals are missing. Sales persons (who have little or no attachment to facts in their incentive plans) talk of “finding the fox” – the TRUE decision maker, regardless of who is taking sales calls.
If you can identify “the fox” in your organization you can find the “true” requirements (whatever the fox wants). Someone hired a BA (you, remember?). Is the hirer the fox or are there other “foxier” foxes that are looking to outfox your immediate leader?

This is not always easy to do. Foxes are foxy and do best when they have dens to hide in, and there is often more than one fox. Once you find the fox your strategy is easy. Do what THEY want, and let the fox stir the mud with difficult stakeholders that take too much time to please.

5. Look Good

Any goal based requirements confusion can be obfuscated and postponed to problems after deployment, when the BA is long gone. This requires use of little or no text (no one reads, and will not pretend that they believe text) but lots of diagrams (most organizations have permission to pretend to understand diagrams, but NOT to pretend to understand text – I don’t know why this is).

The most brilliant diagrams are full of extraneous graphics and detail. Little “Lego” like end user figures, pictures of dollar signs, company logos and colorful, attractive icons labeled “NEW STATE of ART SYSTEM”.

These diagrams are not brilliant for requirements (who does what and how), nor for subsequent development (see “Tufte” for more clues on this). They ARE brilliant for “looking good” and creating warm feelings among stakeholders, as long as you don’t have to deliver.

6. Relax

Above all, don’t make it your job to pursue requirements for business goals not shared by stakeholder consensus. There are several ways to do this.

  1. Become part of the problem by looking for issues instead of solutions.
  2. Share the risk by coding the requirements instead of analyzing them. That way everybody hurts, and they call you Scrum instead of treating you like scum.
  3. Become the lowest common denominator, so everyone is pulling you forward instead of vice-versa.
  4. Set your own personal goals and vendettas, like everyone else (see BA-elzebub’s Glossary on “Agenda” definition can be found here)

* Keep ‘em in the dark and feed ‘em…you know, mushroom food.

Don’t forget to leave your comments below.

CBAP Was Always ‘UnPretty’ – Do You Have the Courage to Embrace Synthesis

“Certified Business Analysis Professional” (CBAP) always seemed a little awkward for a professional designation. Those of us who got it early actually worked directly with people to take the test (no on-line then). I had some low fun teasing the exam team (Cleve Pillifant and team, thank you again) about the acronym. It was low of me since the exam team was available and the decision makers were not (shout out to Kathleen Barrett, hope you are doing well). To those whose eyesight is fading, the “B” can even be mistaken for an “R”. This is no big deal and is common enough (case in point “PMP”).

Now things change, because it is increasingly obvious that ANALYSIS (breaking into parts) is only half the battle (the easy half). The harder “half” is business SYNTHESIS. * Synthesis means taking the parts stated by stakeholders (requirements [stated]) and organizing them into possibilities by reducing confusions and artificial constraints (“but we built what they told us to build…whimper, snivel”).

Modeling IS simplifying. Simplifying requires doing something MORE, NOT LESS. Some of you will understand the statement “If you want it shorter it will cost more.” We know this is true because stakeholders are very reluctant to “simplify” the information they can offer. We also see this is true because we must reconcile wants across silos – often very committed silos.

Simplifying includes breaking concepts down (user friendly means more than a smiley face on screen) with analysis. It works by re-assembling concepts into understandable high quality summaries (models) with synthesis. More than ONE synthesis will be needed. One is for people who will read and follow the complexity. One is for people who won’t be able to pretend they are following unless the words are put into polygon shapes. “I’m visual” is the refrain, but more than four or five polygon shapes quickly reveal that the shapes have “words” anyway, and confusion reigns among the “visual”.

For productivity the experienced analyst understands that working in text can be faster than working in diagrams (at least for analysts that like working in text). An ideal situation is one where a technical writer engages the stakeholders in diagramming simple text while the analyst produces complex text.

Many diagrams are just fancy vague lists. Perfect examples are Visio and PowerPoint “flat” diagrams). As a productivity technique, drawings are easily outpaced by anyone who can create or follow an indented outline.

Here is a sample text “analysis” using the puzzle from the last blog (Everything We Needed to Know We Learned on Sesame Street):

  1. Business Requirements
    1. Business Goals / Objectives
      1. We want to increase sales
      2. We want happy customers
      3. We want to get rid of old technology because…
      4. More?
    2. Business Needs
    3. Capability Gaps
    4. Solution Approaches
      1. We want to buy this in ONE software package
      2. We want to outsource all software configuration and maintenance
    5. Solution Scope
    6. Business Case (what matters, how it matters and why it matters)
  2. Requirements [STATED]
    1. Every want is stated only, not modeled, verified or validated.
    2. All are vague – unspecific – need improvement
  3. Requirements [ANALYZED / MODELED]
    1. No want has been analyzed / modeled
    2. Even business objectives are unclear –
  4. Business Analysis Plan
  5. Solution Requirements
    1. Functional
      1. We want users to have the freedom to override business rules
      2. We want the system to pick the best approach
      3. We want to capture name and address and contact info everywhere
      4. We don’t want managers interfering with our work (micro-management)
      5. We want to reduce data entry errors
      6. We want direct access to the database
      7. We want users to write their own reports and not wait for IT
      8. We want easier, better scheduling with fewer disruptions
      9. We want large monitors, aluminum cases and wireless keyboards on our PCs
    2. Non-Functional / Qualities
      1. We want easy to use
      2. We want a consistent high quality customer experience
      3. We want reliability, maintainability, scalability and no irritability
      4. We will know it when we see it but no sooner
  6. Transition Requirements
    1. We must have everything built before release
    2. We don’t want to change the work or conditions

We may not agree on whether the above is “correct”. I think we CAN agree that it is not useful, complete or free of conflict. There are unspoken relationships (e.g., relation of “solution requirements” to goals / objectives). There are potential conflicts right next to each other. One example is when stakeholders want direct access to the database vs. fewer data errors.

What can fix this? SYNTHESIS! Are you a business analyst only, or a business synthesist* as well? Creativity isn’t just gums bumping – talk is cheap, watcha got that a project team could follow, that could make sense to those who cannot code ambiguity, confusion or wishful thinking? Most importantly – which statements deserve more focus, and which less? Which statements represent the highest requirements risks? What is missing for effective objectives? What would your process model begin to suggest?

Can any of my readers write a single paragraph describing a workable approach? Can anyone resolve the apparent conflicts by addressing high-level business issues? What do the stakeholders mean and can it be built to the joy of all? Hint: Start by synthesizing “bottom feeding” requirements into “top priority” business needs related to goals and objectives.

And remember – you can’t skip any steps in BA world for true enterprise systems. Pay it now or fail it later. Think of all the BA work (yes, its hard, that’s why stakeholders don’t do it) as leading to a quality groomed backlog. Good process, followed by good interface design followed by quality development is unbeatable.

When we “do what stakeholders want” we are not serving their goals. Not unless they happen to be information systems experts. You might as well try to build a skyscraper for a toddler – “I want the 50th floor to be ALL ice cream” they scream.

Remember to say yes, and to place ice cream fountains everywhere on 50. Make it the centerpiece of the project, so no one will forget which stakeholders insisted. Allow all the stakeholders to pick flavors for prioritization. Above all synthesize the other 99 floors with FAST elevators to 50.

Mo’ later, thanks for reading, don’t get lost in the trees OR the forest.

* Do I have to spell it out for you 🙂 ?

Don’t forget to leave your comments below.