Tag: Best Practices

Improve Communication for Better Collaboration

Written by Pam Paquet on September 24, 2015. Posted in Articles. 1 Comment on Improve Communication for Better Collaboration

Hear Pam Paquet speak on handling conflict at Business Analyst World Winnipeg, October 7-9.

In this article she shows us how communication is the key to collaboration.

Ever felt stuck somewhere between a rock and hard place when you need employees to be present and productive yet they want time for personal lives? As a manager, it can seem impossible at times to balance the needs of the business with the wants of the employees. Just think how challenging it is to maximize productivity and sales figures while balancing hours of work to accommodate holiday requests and sick leave.

A certain number of people and person hours are optimum and needed to meet business objectives. Keeping employees happy and healthy is necessary for retention and productivity. In theory, this is straightforward and feasible because both effectiveness and efficiency are optimized. In reality, people can be unpredictable and unavailable because of sickness, holidays and attending to a family crisis. In cases of emergency or surprise, reality trumps theory, and the work may not get done. A simple solution is to hire more employees than needed. Unfortunately, this lowers effectiveness, efficiency, and productivity.

Business success occurs when managers and companies put culture before strategy. So how do managers put people and culture first while meeting business metrics? Three steps are offered:

1. Ask employees about individual needs and preferences. Understand staff and teams better so strategic planning is easier. Ask questions like:

Do you want overtime hours?
When do you prefer holiday time?
Are you available evenings or weekends?
Are you interested in adjusted hours, job share or flex hours?

Although personal questions can’t be asked, it is possible to learn about family and home needs because employees want balance. The goal is to find out strategies so work can complement an employee’s home situation or contribute to balance.

2. Ask employees to create a culture committee. Staff should take turns sitting on this committee so multiple perspectives and ideas are considered. The intent is to create, improve, and enhance workplace culture. Find answers to questions like:

How can we have fun at work
What social activities could we organize?
Does the workplace feel personalized?
How can people connect on a personal level?

The intent is to create ideas and innovative strategies so the workplace can be more than just operations, procedures and metrics. Since employees spend more time at work than at home, create a great place to be most of the time.

3. Ask staff what kind of education would help them personally and at work. Learning is not just about professional development and conferences. Possible topics can include:

– health – wellness – finances
– family – parenting – communication
– nutrition – relationships – interests/hobbies

When employees stay at a company for years rather than months, their personal lives can change greatly and drastically. They can shift from single to couple to single, from independent to parent, from self-sufficient to debt-filled, from free to caregiver. Give staff opportunities to get smarter and better able to function and perform.

These three strategies help to create balance by learning about employee needs. Get rid of damned if you do, damned if you don’t by personalizing business and create a workplace and workload so employees want to be there rather than feel they “have to show up.” Build a company where staff can achieve balance to take care of themselves, their families and the work.

*reprinted with permission from the author

BA-elzebub’s Glossary – The D’s

Written by Marcos Ferrer on September 14, 2015. Posted in Articles. 2 Comments on BA-elzebub’s Glossary – The D’s

Be sure to chip in some D’s of your own, and a few E’s for next time!

D’Oh!: The perfect attitude to take around any requirement error. Makes it easier to fix, especially when the BA takes it for the team.

The next three items were inspired by Ronald 2015-05-19 18:35

Data: The facts collected in the current system – usually the root cause of the need to replace the current system.

Data, Also: The opinion of the sponsor about the facts and how they should be discussed by the BAs, regardless of the facts.

Data, Choose Yours Wisely: Grasshopper.

Data Dictionary: One aspiration of certain social climbing Thesauri.

Thanks to Rich Larson of the BA Times 2015-05-19 15:57

Data Model: An activity that most BAs would prefer to the information designs they actually do. Not all BAs – you know who you are.

Data Base: Piccolo’s Prom dream?

DARPA: Defense Advanced Research Projects Agency recently known for Driver Accident Reduction Pending Automation.

Inspired by Joe 2015-05-19 14:40

Deadline: A term of little meaning or consequence. A date picked with hope, in case hope really matters.

Thanks to to Rich Larson of the BA Times 2015-05-19 15:57

Decision: A behavior performed too fast or too slow by somebody not yourself.

Thanks to Rich Larson of the BA Times 2015-05-19 15:57

Diagram: What we turn to when words fail us. Do not confuse with ViagraMan. Not funny, unless you do it instead of me.

Decision Tree: Analytical technique complicated enough that the sponsor might get away with the weights selected for the branches, without anyone actually checking them.

Defect: Error NOT of design, BUT of execution, as in “That defect killed the wrong person.”

Delay: A period of time required to complete a project, regardless of the deadline.

Delete, CTRL-ALT: Also know as the “three finger salute”, it is a chance for your PC to die with its re-boots on.

Delete, Create, Read, Update: Analysis technique not also known as DCRU.

Delirium: See deadline.

Deliverable: An object substituted for results.

Deming, Edward: Guru of quality, singlehandedly responsible for YOUR preference (yes, you do) for Japanese cars. Famous saying: “Defects are not free. Someone makes them, and gets paid for making them.”

Devil’s Dictionary: A far better read than BA-elzebub’s poor efforts, by a delightful writer named Ambrose Bierce. Get a copy if you can.

Dirty Write: A form of preserving data integrity equivalent to “What the heck” (see Heck in this edition of the Glossary).

Disaster Recovery Plan: NOT “Don’t let the door hit you on the way out…”

With more thanks to Ronald 2015-05-19 18:35

Discovery: The phase when the project team works out which requirements weren’t.

Disinclination: One of many common reactions to working with requirements as in “It’s too much trouble to climb this inclination of mine.”

Disk Drive: Trip taken when the operations manager realizes that the only good backup is on her personal computer at home.

Disk, Floppy: A condition associated with OLD disks.Diskette: A cure for floppy disks.

Distracted Driving: Human driving.

Distributed Computing: A form of missed requirement, as in “I thought they were doing that over there on the other system.”

Domain, Business: The primary activities of the business, as in “Spying on do customers is do main business of FaceNet.”

Domain, Subject Matter Expert(s): Do main person(s) whose best thinking is responsible for the current state. Also known as “do box” one must “get out of”.

With thanks to steve 2015-06-25 06:45

Dormant: State of requirements or expectations that sleep soundly during elicitation and suddenly wake up hungry for BA-er meat during acceptance testing or thereafter

DoS: Denial of Stakeholder, as in “You can’t talk to THEM.”

Dragon: Adjective describing most meetings, not to be confused with:

Dragoon: The goon causing the meeting dragon.

Drive, Shared: Good luck, I’m sure its out there somewhere.

Duct Tape (aka Duck Tape): One of the big two cures in engineering. Unfortunately, it is completely completely useless in software engineering. You know, “If it’s stuck, spray it with WD-40, if it’s loose…”

With more thanks to Steve 2015-06-25 06:45

Dundant: The first time something occurs. For all the rest of the times, see redundant (and Einstein’s definition of insanity). Redundant things are superfluous, while dundant things are merely fluous.

Duplication of Effort: A real “boy” story, used by IT to avoid extra stress (hey, give them more budget and employees before you complain too much). Example from boy: “Why do I have to pick up my room? It will just get cluttered again!” Example from IT boys: “You shouldn’t implement that software – we will just have to replace it when we fix everything!”

Dubious Philosophy: I once read that it was Socrates who said “To be is to do”, and Plato who said “To do is to be”, but we had to wait for Sinatra to say “do be do be do”.

Dumb Ideas: There are none – leave your comments and thoughts below 🙂

Dear 007, Am I Finished?

Written by Marcos Ferrer on August 20, 2015. Posted in Articles.

Sometimes I get questions from BAs and PMs, and when I can’t answer them, I pass them on to CBAP 007. With an IIBA license to drill, no business analysis issue is too big or too small for this experienced professional. Here is one from July 2015:

Dear 007:

My project manager tells me to “finish the requirements”, but no matter what I turn in, she says it is not finished. When I ask what else she wants, she says she wants everything. When I suggest that everything costs infinity, she says I have an attitude.

She is right (about my attitude). What should I do to “finish” the requirements?

Signed,

More Finished Than She Thinks

Dear More Finished Than She Thinks:

I assume that you, like most BAs, understand that requirements are rarely “finished” in the sense of being complete to the satisfaction of every stakeholder.

The most complete requirements ever written for a cell phone did not include the contingency factors inherent in a pair of boot-cut Calvin jeans worn two sizes too small and stuffed with an understructures oversize phone chassis.

Don’t even ask about rubber gasket temperature requirements for Space Shuttle boosters – they WERE included as requirements, but ignored by project management in spite of their completeness (“But Reagan is sending a teacher into space and giving a big speech – it’s a deadline!”). Deadline, indeed, but not a requirement.

SO, I assume that the words “finished” and “everything” means something different to your PM than they do to you. Let’s try a few definitions – if one of these fits you may realize what to do.

Does finished mean? :

I (the BA) can’t tell that anything is missing
She (the PM) can’t tell that anything is missing
We (the other Business Stakeholders) can’t tell that anything is missing
They (the Implementation SMES) can’t tell that anything is missing
It (the solution as implemented) can’t tell that anything is missing (everything” works)
Notice that none of these definitions involve anyone saying “I can see that X, Y, Z are missing” which would be more helpful.

Now for a definition that helps. Completeness is best defined at a GIVEN LEVEL OF DESCRIPTION. In the BA profession, we look to BABOK for the correct categories and levels of description. In this case, requirements have the following levels of description:

Business Requirements (High-level statements of key business needs, approaches and strategically justified capabilities that must be met regardless of stakeholder wants)
Requirements[Stated] (stakeholder wants and concerns not necessarily analyzed)
Solution Requirements (functional, work to be done)
Solution Requirements (non-functional, qualities of any solution to be implemented)
Transition Requirements (temporary needs and efforts, until “full” implementation)

“Our business has a need to deliver legal documents to its customers every day on less than one hour’s notice,” might be a COMPLETE business requirement. Make sure to comb your requirements and collect all the “high-level” actual business needs (as opposed to personal preferences, see below). You will discover some “low-level” requirements that imply high-level requirements, and vice versa. Separate them (analysis) into their own groups, rewrite them to fit their level and category. THEN IT BECOMES EASIER TO SEE WHAT IS MISSING AT THE HIGH-LEVEL. This is where MOST IT project mistakes get made and is the most important to get complete.

“I want a car so I can make those deliveries for the business” is COMPLETE in the sense of being a stakeholder requirement [stated, not analyzed]. Make sure that you comb your “requirements” and collect all the “not-really requirement” statements and put them into an “elicitation” document for further analysis. The “requirements” are not finished, because they are not analyzed, but COMPLETE in the sense of being everything the stakeholders said).

“Bicycle couriers average 12 miles an hour in city deliveries, vs. 7 miles an hour for cars. Feasibility ANALYSIS suggests outsourcing delivery to couriers (or we can buy the stakeholder a bicycle instead of a car).” This might be a COMPLETE solution requirement (functional) – DELIVER LEGAL DOCUMENTS. Collect all the actual work functions implied in all your requirements, and list them in one place. It becomes easier to see what is missing (e.g., PREPARE PACKAGE WITH CORRECT DELIVERY INFO, and CONFIRM TIMELY DELIVERY WITH CUSTOMER). To be complete, list all the IMPORTANT business processes, and let the less important arise as needed (e.g., we need to ASSIGN DELIVERY TO COURIER SERVICE as a critical business function, but we can decide to implement this assignment via text message as we negotiate with the courier service. Is the requirement complete, if this “text message” spec is unresolved? Not really (see the beginning), but it is LOW risk and focus belongs on other higher level issues (e.g., how to MEASURE delivery performance objectively, once assignments are made).

“Delivery in less than on hour” was already stated as a business requirement – it is (for this simple example) the COMPLETE solution non-functional requirement – a service level guarantee. Can you think of any functional requirements that would help guarantee that service level? Put those above – group like with like.

Finally, transition requirements. Who has to be informed, trained, won over? Do we have to convert data from the secretary’s Rolodex to a label print system for the courier packages? What is the implementation plan (oh project manager mine). The project plan (think about it) is largely “transition requirements”, and should lump upon the head of your PM as much as on you.

IN short, if you use BABOK categories, you avoid level mixing, confusion, and you gain the ability to see what else belongs at that level. If you do it right, you will perceive redundancies between levels. This is normal, and shows traceability and shows that requirements are related across levels (that is why it is so easy to mix them up and get confused about how complete they are). An example of a seemingly redundant requirement was “Delivery in less than an hour”. At the business level, it is a service strategy defined by a performance level. At the non-functional level, it drives measurement, verification and other functional requirements. By putting it in both places as appropriate, COHERENCE is achieved, which helps stakeholders in perceiving completeness.

ALWAYS START BY FILLING IN THE HIGH LEVELS TO MAXIMUM COMPLETENESS. IF there is no time to “finish” a lower level, you might not even start it. Don’t spec the detail steps of MANAGE USER PRIVILEGES just because you can – stick with high value high-level critical business processes such as VERIFY TIMELY DELIVERY, and try to “complete” the success scenarios. If you have time, go for the top 3 alternate scenarios. At each step, decide how much you can accomplish and put BABOK boundaries on the work so the completeness can show.

THEN when your manager says to “finish” the screen color requirement, you know which requirement and what is missing.

Je suis finis – et vous?

Please comment below – let me know what you DIDN’t get, so I can finish it 🙂

Use This Simple Technique to Quickly Understand an Organization

Written by Clarence Worrell on August 20, 2015. Posted in Articles.

As a Business Analyst, your work is generally concerned with developing an understanding of an organization, and then communicating that understanding in ways that are efficient and actionable. Use this simple technique, outlined below, to quickly understand the aspects of an organization that are typically of interest to a BA.

MODEL OF AN ORGANIZATION

The technique assumes the following model of an organization:

The organization is engaged in a business
The organization offers products
Product development, production, sales, delivery, maintenance, etc. are accomplished through processes
Processes may include tools, techniques, and deliverables
Processes may be supported by technology

The figure below that illustrates this model:

Using the example of a city public library, let’s examine the model in more detail.

ORGANIZATION PERSPECTIVE

The model is general and applies to organizations at all levels. For example, it can apply equally to any of the following:

A city public library
A branch of the library
The library’s payroll department
The library’s IT department
The IT department’s database team

Each of these organizations is engaged in a different business. For instance:

The city public library is in the business of providing library and information services to residents of the city.
The branch library is in the business of providing a subset of these services to a community within the city.
The payroll department is in the business of issuing paycheques to library employees.
The IT department is in the business of building, operating, and maintaining technology for the library. This technology supports processes (like inventory), tools (like employee email), techniques (like Dewey Decimal System cataloging), and deliverables (like employee paycheques).
The database team is in the business of building, operating, and maintaining databases for the library. For example, it might currently be working on an upgrade to the library’s DBMS.

PRODUCT PERSPECTIVE

One organization’s product can be another organization’s process. Or tool. Or technique, deliverable, or technology.

For instance, the library might purchase new bar code scanners for its inventory management system. From the library’s perspective, the scanners are tools. But from the scanner company’s perspective, the scanners are products.

The scanner company likely has processes for development, production, sales, delivery, and maintenance of bar code devices. For instance, one of its tools might be an automated order entry system.

Let’s say that the scanner company has engaged a consultant to help improve its order entry process. From the scanner company’s perspective, the order entry process is, unsurprisingly, a process. From the consultant’s perspective, the order entry process is a product. And so on.

THE TECHNIQUE

The technique is this – Make a table using the following template, which is based on the organization model. Fill it in with information about the organization. Discover this information using whatever techniques are at your disposal (observing operations within the organization, conducting interviews with employees of the organization, studying documentation, etc.). This may or may not be easy to do, but the “doing” is the most important part; it is where you will organize and clarify your thinking about the organization. (However, the resulting artifact may itself be useful, as described later on.)

Following is a partially completed table based on the public library example:

SOME USES OF THE TABLE

Scenarios in which this technique could be useful to you, as a BA, include:

You are starting a new job, either with your current employer or with a new employer: Use this technique to assess what you need to know in your new position.
You are assigned as a consultant to a new client: Use this technique to develop a high-level summary of the client’s “as is” organization.
You have just hired on with an IT startup: Use this technique to identify what processes, tools, and technologies are currently in place, and which ones need to be defined.
You are job hunting: Use this technique to define the gap between an advertised position and your own competencies; this is a variation of assessing training needs.
You are asked to assess the training needs of your team. Use this technique to define the gap between team member competencies with respect to your team’s products, processes, tools, etc. Simply expand the table to include columns for each team member. Enter an assessment of each team member’s competencies and clearly assess where the training needs are.

An example of a training needs assessment, using our library example, could like like this:

From the training assessment table, we can surmise the following:

Arjun has the greatest training needs. It looks like he may be new to library work. It also looks like he is new to Scrum.
Anna has need of training in the Conference Room Reservation System (maybe she has previously specialized in the Inventory Management System).
All three team members are in need of training in use case modelling.

THAT’S IT!

The model and technique are pretty straightforward. I’ve found it useful in various settings but also have gotten into seemingly circular arguments about it. For example: “Why isn’t there an arrow from Technology to Products? Technology supports Products, right?”
If you find that the additional arrow helps, by all means use it. In my thinking, though, each Product is ultimately a Deliverable of some Process. Since Deliverables are supported by the Technology, no arrow is needed.

In any case, I’d like to hear your comments about (and criticisms of) the model and the technique! I hope you find it useful.

Even Business Analysts Need Love

Written by Marcos Ferrer on June 29, 2015. Posted in Articles.

Attention all stakeholders of the solar federation. My personal life has recently tuned me into pain in a way that makes me realize that the BA’s professional life offers great pain. “NO!”, you say, yet here is a list of hurts you may well have inflicted on a BA if you think about it carefully.

Don’t do these things:

Don’t kick the BA off the project just because they made a deliverable that looks like requirements to you even though you didn’t read it (sponsor, sponsor, sponsor). Your (anyone’s) deadline allows only the beginning of organizational learning. The loss of the BA guarantees the end of learning, never mind the teaching that must follow for change management success.

Don’t hire a BA if you know better than they do. You will annoy yourself while amusing the BA, which will only annoy you more.

Don’t give requirements as if they were dictation. If a BA takes your requirements EXACTLY as you give them and does not present an “analyzed” model showing what the requirements might REALLY be, it might even be that your BA does not like you.

Don’t dislike the BA. At worst they are only messengers, and at best they can get you results that you actually want.

Don’t withhold pay. Because may BA assignments are “temporary” (see above), many BAs are consultants/contractors/temporary. Making them wait long periods to be paid is not good for them, you OR them.

Don’t keep the BA in the dark. They can see how silly you look in the dark

Don’t yell at, or curse at the BA. Yeah, really. You know who you are, and so does everybody else on the project. Recriminations are not requirements. Not.

Don’t not read the requirements.

Don’t not read the email. Yes, it is OK for an email to have more than one sentence.

Don’t gush over the diagram just because it is nice. Be specific in your gushing, as in “I really like the fact that I can see ALL the redundancies across payment types” or “The pink really highlights just how risky a full cutover is, and how it pays to set up three teams.”

Don’t be impressed with nice looking diagrams unless the content is robust. The cuter the graphics, the less likely the analyst spent time on re-factoring process, the more likely the analyst spent time on re-factoring the format.

Don’t bring everyone to every meeting. The amount of work progress made in a meeting is inversely proportional to the square of the number of people. Eight people will accomplish 1/16 of the work that 2 might. Enforce the rule by accomplishing actual work at every meeting. This will help you keep meetings small.

Don’t accuse the BA of “blowing your scope”. It isn’t your scope, it belongs to the business. Besides, you got the scope wrong in the first place by rushing to solution, then broke everyone’s spirit by preventing any improvement once the team understood what the scope actually meant.

Don’t rush to solution. Plan the different approaches, from simple/cheap to complex/low chance of success. Use each simple approach to advance the solution by REALLY learning from it. REALLY.

Don’t have the BA walked out the door immediately, even when you must let them go. They don’t have access to sensitive systems functions (are they sysadmins or BAs?) and if what they know is dangerous to you walking them out is no way to make friends, and you are going to need friends (see 1st item above).

Don’t ignore maintenance of the highest level descriptions just because “everyone knows that”. If you are engaged in enterprise systems transformations, everyone is going to go from 5 people to 10 people to 40 people over a couple of years, and then to 20,000 overnight. Be ready for everyone – there will ALWAYS be new people, and a failure to model the highest levels of business requirements and process is the number one cause of failure – the big mistakes happen at the top levels of description.

Don’t insist that BAs produce meeting minutes – better they should produce models that represent business thoughts and decisions so stakeholders can see what they said. The alternative is to build based on the say as seen in the minutes. Then you will hear stakeholders say “I can’t say I see what this does for me.”

DO learn along with your BA, who is learning your needs and combining them with others that you don’t have time to learn. So many voices channeled through one, neutral, zero attitude model for all to reflect upon. Bliss, you think?

Don’t forget to tell me what you think, since you read this far, your opinion is already 1st percentile. Comments below 🙂

Don’t forget to leave your comments below.