Author: Marcos Ferrer

Ace the Facilitation. Face Your Fame!

Written by Marcos Ferrer on November 2, 2010. Posted in Articles. 2 Comments on Ace the Facilitation. Face Your Fame!

Let’s face it – the most excellent people skills are rarer than we’d like – even in ourselves sometimes. Even as we try to gain the trust and confidence of stakeholders, we are constantly being judged on our performance. It is rare that excellent documentation can make up for hurt feelings or trashed relationships.

All your thinking, analysis, problem solving will gain you naught, if stakeholders get the word that you are a jerk, or an idiot, or can’t control the jerks and idiots that come to your meetings, or can’t elicit effectively in interviews.

So here are some tips and how to use them:

Set expectations at your elicitations – remember that you are collecting requirements (stated), to turn them into requirements (confirmed), but that decisions to build are completely separate from the discovery process. Be honest with your stakeholders – you don’t make the decisions, you make sure that all inputs are considered in their proper context. Most stakeholders understand that priorities come into play; they just want to know that their input wasn’t ignored, or heard by an ignoramus.
Get your attitude right – get neutral – if you favor some stakeholders over others, participation will decline, buy in will decline, and sniping will increase. It is OK that some ideas rise higher than others, just make sure that you aren’t perceived as a “teacher’s pet”. Make sure that ALL your stakeholders feel like the teacher’s pet.
Do NOT judge ideas, or try to correct them, when offered. Capture them, use them to stimulate further discussion – the secret to comedy improvisation is to always say yes to your partners – be encouraging, not judgmental, and don’t allow your knowledge of potential solutions interfere with your goal of completely understanding your stakeholders – completely!
If your stakeholder refuses to cooperate because your project isn’t important to them, get them to talk about what is important to them. Intersections with your project will arise surprisingly often, and when they don’t, file the stakeholder interview against future projects – as trust builds, you will get them!
When a stakeholder gets angry or emotional in a meeting, use the “attitude ladder” to connect with them rapidly and effectively, and bring them down. The key is to understand that the emotions about the requirements effort can range from completely negative, to neutral, to extremely positive. When a stakeholder goes negative, MATCH their emotion with a little (little) of yours, them bring yours down and see if they will come with you. Example: LOUD: “This meeting is a waste of time. No one asked us if we even wanted this, and we are really busy!” Response: NOT QUITE AS LOUD: “I GET how frustrating this is for you!” CALMER: If we agree to keep it really short, can we focus on the assignment for the short time we take?”
Use humor – always risky, and yet the right joke can take ALL the tension out of a room. Safer to focus humor on yourself, such as: “This meeting is idiotic!” Response: “I resemble that remark – that is why I have to ask all these questions!” Use with caution.
Don’t use WHY. Don’t argue with me, just don’t do it. Don’t ask me WHY, or I will ask you “Why don’t you already know this?” Any WHY question can be changed into a WHAT, HOW, WHERE, WHEN question. Example: “WHY is it important to do X,” can be turned into “WHAT happens without X in place?” or “WHAT will change, given a project to do X.” No, don’t quote “Root Cause” at me – Why are you still confused?”
Prepare, prepare, prepare – put yourself in the stakeholder’s shoes and think of everything you can that might be of concern to them. Don’t use your preparation just to control the encounter – use it to allow the encounter to flow comfortably for the stakeholder. When you are ready for most things to come up, it is not stressful if things wander, and it can be productive. Over- Control is NOT loved, and don’t think they don’t notice when you do it.
Here is a neat link – some homework, for my diligent readers. http://www.leadstrat.com/

Learn How to:

Prepare for a successful engagement/meeting
Gain the groups interest and support from the start
Get executives to transfer their power to you
Keep the group focused
Handle disagreements and dysfunctional behavior
Guide groups to effective business solutions
Reach consensus around a decision
Close the session with clarity and commitment

DO NOT DO THESE IDEAS IF YOU DON’T LIKE BEING POPULAR. Your phone will ring too much.

Thanks to all my discerning readers – until next month, when we talk more of QA, BA, Deming and some reader responses!

Don’t forget to leave your comments below

A Meditation on Root Cause Analysis (and Contest!)

Written by Marcos Ferrer on October 4, 2010. Posted in Articles.

Mark Twain’s book “Fable of Man” offers the following observation related to “root causes”:

“Take the fly, for instance…A few have explained that there was need of a creature to remove disease-breeding garbage……[when] asked to explain what long-felt want the disease-breeding garbage was introduced to supply, they have not been willing to undertake the contract.”

As a BA I am always thinking of root causes, and yet I rarely find a productive audience for the discussion, which is full of pitfalls, potential bad feeling and the illusion of understanding where none exists.

Example Pitfall 1.

Issue: Customer Claims take months, even years to process

Because: Missing data and processing errors cause repeated return/rework

Because: Gary and Marcus and Monika and Eros (etc.) are sloppy, sloppy, sloppy!

To DEEPLY understand why this is flawed read some Deming and some Dale Carnegie. Deming offers more Science, and Carnegie more Art, but both represent world class, proven high performance approaches. ‘Nuff said, just do it. You heard me.

Example Pitfall 2.

Issue: Customer Claims take months, even years to process

Because: Missing data and processing errors cause repeated return/rework

Because: Existing computer system is doo doo.

This is flawed because the existing system represents the organization’s best (to date) collective understanding of how to solve its problems. Real investigation (requirements elicitation and analysis) would be required to clarify this claim. How many of you have watched a working, but hated, system replaced with a non-working system? I have – and stayed out of the project, but like any train wreck, couldn’t take my eyes off of it.

Example Pitfall 3.

Issue: Customer Claims take months, even years to process

Because: Missing data and processing errors cause repeated return/rework

Because: The current system is paper focused (EVERYONE knows paperless is better)

This looks promising! Paperless is quite popular as an instant solution, in the same way that implementing client server, or relational database, or web solutions can be popular. The flaw is that the solution is NOT the problem that we are trying to solve. Can you spell tautology?

Example 4. Contest!

Issue: Customer Claims take months, even years to process (this is a measured fact)

Because: Missing data and processing errors cause repeated return/rework (this is also a measured fact)

Because: Essential knowledge is missing early in the claims process. Claims turn out to be complicated, and there are constraints on outcomes that must be understood early and often as claims are developed prior to decision-making.

Because: Claims processing was broken into a piecework assembly line process, with small incremental processing tasks and constant passing of paper back and forth as needed by each task, and each piece of rework. This was believed to be the fastest, most efficient way to organize complex expert work.

Because: _____________________________________?

We will collect the three funniest responses to the above blank and share them next month, if any, per Mr. Clemens request, are willing to undertake the contract.

Thanks to all my discerning readers – until next month! Ideas or responses welcome at [email protected].

Don’t forget to leave your comments below

The BA and the PM

Written by Marcos Ferrer on August 10, 2010. Posted in Articles.

(With thanks to Lewis Carroll’s “The Walrus and the Carpenter”).

The vision shined upon the project,
Shone with all its might:
It did its very best to make
The plan seem smooth and bright–
And this was odd, since projects grow
From hidden dark of night.

The BA waited sulkily,
Because she thought vision
Had no real meat to back it up
Yet budgets were all done–
“It’s very rude of it,” she said,
“To come and spoil the fun!”

The team was set as set could be,
The keystrokes start to fly.
You could not see a coder ’cause
They busied on UIs:
No time to architect things right
Only time to fly.

The BA and the PM
Were walking close at hand;
The BA wept o’er missed requirements
Such projects were in Stand-
-ish and Gartner and Chaos
Such projects would crash land!

“If seven JADs, each with models
Analyzed half a year.
Do you suppose,” the BA said,
“That they could get it clear?”
“I doubt it,” said the PM,
“The deadline is too near”

“Oh Stakeholders, come walk with us!”
The PM did beseech.
“A pleasant walk, a pleasant talk,
Along the UI veil:
We cannot do what vision wants,
With luck you cannot tell.”

“The time has come,” the BA said,
“To talk of many things:
Of business rules and process too
Of re-en-gi-neer-ing
And why root causes were left out
And whether screens DO things.”

“But wait a bit,” Stakeholders cried,
“Before we have our chat;
For most of us are scared of change,
Don’t make us talk of that!”
“No hurry!” said the PM.
He smelled a sly way out.

“A Use Case now,” the BA said,
Is what we chiefly need:
Its what it does, not how it looks
That gives our project speed
Now if you’re ready, Stakeholders,
We can work out the true needs.”

“But not from us!” Stakeholders cried,
Turning a little blue.
“Asking us to think so hard
About the things we do!”
“The project’s fine,” the PM said.
“Don’t let BA bug you.”

“It seems a shame,” the BA said,
“To play them such a trick,
The vision could be made to work
If we just work on it!”
The PM said nothing but
“You think the screens are slick?”

“I weep for you,” the BA said:
“I deeply sympathize.”
With sobs and tears she analyzed
Important gaps of largest size,
Wrote them down, turned them in
And then kissed them goodbye.

“Oh Stakeholders,” said the PM,
“You’ve had a pleasant run!
You told us what to build on screen
We kept you happy, weren’t it fun?”
“Couldn’t care less!”, as they confessed
The system pleased no one.

The Business Case for Business Analysis

Written by Marcos Ferrer on July 13, 2010. Posted in Articles.

Apologies to any economists – the real value of BA is probably way higher than I could determine in 1000 words. There is probably a multiplier just from workers watching crazy process insanity disappear from their daily lives.

To see the big picture sometimes we drill down. I give a specific example (completely fictional of course – this is not you, so don’t call please). In this project BA 007 was asked to help introduce BA practices into a water utility’s IT project practices.

The usual “fire hose” of information was sprayed on 007 for the first weeks. As 007’s intelligence base grew, one of his early questions was “How much money is currently spent on IT projects and infrastructure per year?” The response was: “Oh, we have that, it’s around $3,000,000.00”. No documentation available, but, what the heck, eh?

So 007 continued to analyze the information he was getting, patient and secure that his question had been, or would be, answered. As an initial business case for implementing BA for IT projects began to emerge, it became apparent that the out of pocket costs looked something like the following:

12 SMEs on staff acting as BAs
8 person team doing requirements for ERP enterprise project
100 stakeholders engaged part time at any given time (about 10 full time equivalents)
70 Contract IT personnel
Average IT Infrastructure investment of $3,000,000/year

Total 100 personnel out of 2700 employees @ $75K/year on average = $7,500,000/year

At this point, 007 starts to suspect that the $3,000,000 only covered total annual infrastructure costs (hardware, software, support and maintenance), and that the client was not counting payroll or overhead costs for projects (not unusual in a government environment). Given the 35% failure rate across all water utility IT projects (we ignore those that were merely “compromised”), the “lost money” to failed projects seemed more like $2,625,000 per year, or $26,250,000 over 10 years.

The costs of BA (requirements) failure above are incomplete and incorrect – they do not include overhead like office space, supplies, PCs, office equipment and other resources wasted on failed projects (promotion of the guilty, punishment of the expert, rock bottom morale, employee turnover and more).

The cost of retraining personnel for improving the BA function at the water utility was calculated to be 20 BAs plus 20 IT personnel, Each receiving 8 weeks of training in year one, 4 weeks in year two, and two weeks per year in subsequent years. Classes were estimated at $3500/week including travel, and salaries/benefits at $75K per year on average.

It was also estimated that increased/improved BA activity would require twice as much involvement from stakeholders – 20 full time equivalents instead of 10.

These costs to invest in BA came to about (40*(8+4+2+2+2+2+2+2+2+2) person weeks * ((75,000/52) +3,500) per person week)
= $5,536,385

PLUS 10 more full time equivalents @ $75K * 10 years
= $ 7,500,000

TOTALING:
$ 13,036,385

OK, those of you who do real business cases know just how flawed this is, but, as 007 likes to say, $26M – $13M gives a LOT of room for refinement. Go ahead, add inflation to personnel costs, add in lost benefits to the “merely wasted” money, add any complexity you want – 007 defies you to show that BA investment can ever lead to a negative ROI.

Have fun, and I’d love to get your feedback!

Don’t forget to leave your comments below

The Earth may be Flat, But at least the Project is Round

Written by Marcos Ferrer on June 1, 2010. Posted in Articles. 1 Comment on The Earth may be Flat, But at least the Project is Round

Careful now – can’t give any names, or particulars -since the following can’t possibly be a true story, I present it as humor, which it might be J. Names and details have been changed to protect the innocent – if you recognize yourself, it must not be you. You wouldn’t do this. No one would!

Just before last Christmas, BA 007 got a call from a body shop called “Carrion Solutions, LLC”), based in North Kakalaki. They really liked his resume, and the 20-minute phone interview that day, and wanted him to interview with their client (which we will call “Vermin International, Inc.”) immediately.

Sanity prevailed (for the moment), and the interview was postponed until January 4^th, with the caveat that the job might start shortly afterward. The interview took place on January 4th, was grueling, yet satisfying. Vermin agreed with a best practices approach involving prototyping and use case modeling with as-is and to-be context diagramming, along with iterated validation with stakeholders and IT.

The Earth, it seemed, was round, at least on this project team. After working with many Flat-Earthers these last few years, 007 was looking at a chance for a quantum of BA bliss!

As it happened, the job started two days later, with a bang. It turned out that 30 Minions had done a report on Vermin’s client, The Better Man’s Beneficent AdmonishNation. As usual, the report was far from flattering, and the heat was on for quality requirements for rapid implementation – lot’s of money, lot’s of management attention, rapid decision making, plenty of stakeholder involvement. Goodness!

The project kickoff meeting at the BBBA was a hit. The client approved the best practice approach. Sensing urgency, 007 had an as-is diagram ready the same week, ready for review and initial validation with the client (BBBA).

Vermin management refused to allow the diagram to be reviewed with BBBA, without explanation (remember, 007 works for Carrion, which contracts with Vermin, which contracts with BBBA). During subsequent attempts by 007 to share and discuss the as-is with Vermin and/or BBBA, Vermin repeatedly cancels the meeting, simply doesn’t show up at the meeting, or uses the entire meeting to present other topics.

Now BBBA wants the diagram (Duh, you think?), and after a couple of weeks, Vermin agrees to let them have it, but no validation meeting is allowed. (There were two meetings allowed with 007, both of which the BBBA liked, felt were extremely productive, and resulted in mucho validationo).

The above process was then repeated for several weeks with other best practices such as clarity of scope (Vermin’s response to any discussion of scope) use case modeling (completely ignored by Vermin), and Business Process TO BE (Vermin already had a solution based on BileNet?).

After two months of this, 007 was in a jam. His originally identified goal of specifying as many as 40 use cases was shot, with a new goal of specifying 10-15 of the most important/complex use cases, as revealed by the use case model, which Vermin still refused to allow to be reviewed or validated by BBBA.

At this point, 007 used a brilliant tactic – the daily scrum! After a couple of weeks of “socializing” the increasing urgency of proceeding with the use cases, 007 shared with the team that the lack of regular validation sessions with BBBA had finally become a hindrance to completing the requirements by the deadline, and that assistance from Vermin, and time with BBBA, was needed to proceed. The offer of use case review was especially timely because the GUI team was begging for some kind of requirements “taxonomy.” They had long lists of GUI requirements that were, of course, out of context, and would benefit from a use case “taxonomy”.

The response? 007 was told to “Shut Up”, and that his “Round Earth” theories couldn’t help their “Flat Earth” requirements.

So shut up he did, turned in his drawings of the solar system, and left the project, but he advises his gentle readers to keep an eye on 30 Minions, just in case.

Have fun, and be sure to let me have your comments.

Don’t forget to leave your comments below