Tag: Facilitation

Storming the Brain

Written by John Vaught on February 7, 2019. Posted in Articles.

You’ve been to a meeting (or twenty) in which the leader tells you that the group is going to brainstorm.

There are rules to storming, of course, which are things such as:

Put all the ideas out there first
Everyone contributes
Pretend like what you just heard was not a dumb idea

If you find yourself in a meeting like this, you can have some fun by asking quirky questions to appear smart in brainstorming meetings:

Shouldn’t we be asking if this ask is the right ask?This seems like a pivot.
But how is it disruptive?
Is this the future?
What’s the big Win?
Isn’t that putting lipstick on a pig?
How does this fit into the roadmap?
We have the cake, but the cake needs sprinkles. What are the sprinkles?
Is it too disruptive?

Sure, you’re going to get some looks when people figure out what you are doing, but that’s because this is the best way to get creative ideas on the table. Grab a group, throw out as many ideas as possible without any judgement, and then crazy creativity happens. Right?

Not according to this article, which boldly states that “Brainstorming is Dumb.”

But it turns out that brainstorming is actually a terrible technique—in fact, people generate fewer good ideas when they brainstorm together than when they work alone.

Alex Osborn came up with the “brainstorming” method in the 1940s and it has now become ubiquitous; few people are asking if it actually works. Turns out that it has the opposite effect – you turn out better ideas alone than using this method. Paul Paulus, a professor of psychology at the University of Texas at Arlington, has this to say about why:

“Brainstorming is a complex process where people are trying to listen, think, add, collaborate, build. It’s cumbersome, it’s difficult psychologically, and people don’t do it very well.”

You may be thinking – why didn’t someone tell me! Well, they have, since as early as 1958.

If it doesn’t work, for goodness sake people, let’s stop doing it! Let’s get real about creativity – it rarely happens at the drop of a hat or because we throw ten people in a room. Creativity is hard work, and it can take time and deep thought.

So does this really mean that I should ignore everyone else and rely on my inner creative genius? Well, sometimes.

SOLUTION #1: IGNORE RULE #1

One study found that should do the opposite of the one thing that Osborn thought was the most important – feel free to debate suggestions as they come in. Criticism is often thought of as a creativity killer, when in fact the studies consistently find that debate lifts ideas and brings up more and better alternatives and as well as diverse ideas.

“In a way, the power of dissent is the power of surprise. After hearing someone shout out an errant answer, we work to understand it, which causes us to reassess our initial assumptions and try out new perspectives.”

This also says something about the mix of people that are best at having these kinds of debates. Those who are strangers do not have the comfort to truth, but those who are too comfortable with each other do not push into new areas. Some familiarity mixed with some newness can provide a freshness, if you know what I mean.

SOLUTION #2: DON’T CREATE A #2

One study looked at the results provided from three-person groups performing a complex problem-solving task. Using the Osborn form of brainstorming you would think that the group that collaborated the most had ideas that were more than the sum of their parts. Wrong. That group had the most mediocre results; this shouldn’t be too surprising when you consider that group dynamics will often bring results back to the average. The other result isn’t too surprising either – the groups with no interactions had some of the best results; but they also had some of the worst. Working alone produced results all over the map.

Here’s where you need to pay attention: the group that interacted intermittently had the consistently best results.

The right mix of individual effort, in deep work, with some group interaction will generally produce overall better results. I know that didn’t rock your world. Of course, you are thinking, I just wasted ten minutes of my time to read about something I already do.

But here’s the kicker – you probably aren’t using the right mix. Most of us are using the mixer when we should be cooking, and vice versa, ending up with scrapple on your plate…

Your most creative work is when you are blocked off from other people and can truly concentrate. Your best time to contrast and compare to make the ideas better is when you are collaborating.

The Problem = we are entering a world where it is getting harder and harder to block off interactions, so we are consistently putting ourselves into the group that produces mediocre results.

You Are Not Asking Enough Questions

Written by John Vaught on January 30, 2019. Posted in Articles. 1 Comment on You Are Not Asking Enough Questions

If you have kids, when they were around 4 years old you were subjected to them asking a single question that they would keep asking over and over till it would drive you crazy.

One study found that they average about 73 questions per day. What is the main question they ask? You know the answer to this one:

WHY?

Why is the sky blue? Where did I come from? Where did the moon go? Why are those animals wrestling? “That’s a good question to ask your mom, kiddo.”

And the Why’s usually doesn’t stop with the first answer, does it? You might think you gave them a great response, but as soon as they ask it for the second, or third, or fourth time, it gets frustrating:

It doesn’t seem like their questions are ever going to end (hiding doesn’t work, you’ve tried it); and
It is frustrating how quickly you run out of good answers.

But in reality, the last thing we really want to do is to stop kids from asking questions. It’s a fundamental way they learn and develop. Maybe one of the reasons why our own development as adults slows down later in life is because we stop asking so many questions.

Are we telling our kids, consciously or subconsciously, to stop asking questions?

Now, there is a point later in life that kids start to ask questions again. Anyone have a teenager at home? If you are holding up your hand, let me comfort you with these words – this too shall pass.

For teens, the questions change from being about the world around them to directly about them. Why do I have to do chores? Why can’t I go out with my friends? The questions at this stage are less about how nature works and more about how you work. We get frustrated with these questions because it feels like they are challenging our authority.

But… maybe even these teen questions are good questions as well. Let’s turn it around for you – how well do you like it when someone at work tells you “Because I said so”? Friends, that’s not a good answer in the home or the workplace.

Are we telling our work staff, consciously or subconsciously, to stop asking questions?

Let’s just be honest – we sometimes get frustrated with coworkers asking questions, and probably for the very same reasons we lost our minds when our kids were doing it:

It seems like questions are taking the place of doing work; and
There may not be good answers for their questions.

I totally get #1. You can almost see the fear in people’s eyes when someone starts asking questions in a meeting, wondering if they are summoning the dreadful Analysis Paralysis, the dreaded gorgon that stops us in our tracks and wreaks havoc with our schedules.

But before we jump into action, let’s make sure we aren’t squashing the drive to ask questions. Because sometimes activity is just a way to mask the fact that we don’t have the answers; which gets us to point #2.

If we don’t have clarity around why we are asking someone to do something, then maybe that something doesn’t need to be done.

Here’s a scary equation that often drives people to squelch questions:

Time Cost of Asking Questions = Time Cost of Doing Something

It’s easy to look at that equation and go, “Oh my! We don’t have time for questions! Someone do something, for goodness sake!” But what we don’t think about is the huge costs of doing the wrong things that could have been saved with a small amount of questions:

Time Cost of Asking Questions < Time Cost of Doing the Wrong Thing + Time Cost of Rework

For some reason it is easy to think that asking questions is far less valuable than doing actions – even when we don’t know exactly why we are doing it! Activity does not equal value; creating artifacts or a product that no one really wants drives value down. in fact, asking people to think about what they are doing might be the most valuable thing you can do.

I’m encouraging you to bring out your inner 4-year-old and keep asking why – it may drive the people around you a little nuts but they may just end up thanking you in the end.

Feedback is a Gift! Accepting and Utilizing Feedback

Written by Jamie Champagne on January 9, 2019. Posted in Articles.

How often do you thank someone for the incredible feedback you have just received?

Whether it is about your work product, your ability to conduct a meeting or the way you look? Can you remember the last time you said “thank you” to feedback? Whether the feedback feels positive or negative, be thankful that a stakeholder took the time to give you feedback. While business analysts and project managers are often facilitators, helping others achieve their goals, we work with people who often have “day jobs.” They are having to help our current project or change initiative in addition to doing their regular work. They took the time to read what you had created and gave you feedback. That is a gift!

So why does it feel so hard to receive this feedback when it is negative? It is because you took the feedback towards yourself, not your work product. Yes, you spent 6 hours producing a requirements traceability matrix that you validated with numerous SMEs to ensure all elements were captured. Yes, the presentation was very clear and concise with aesthetically pleasing visuals. But your job as the BA or the PM is to help the team deliver their solution. This is part of getting behind the best idea regardless who came up with them. You do not own the end solution – your stakeholders do. The first step with feedback is letting go of personalizing the feedback.

Once you have let go of your own ego, you can take a moment and be proud that you were able to elicit feedback. Knowing if you are going down the right direction or the wrong direction is better than having no direction. Put on your analysis hat and look at what kind of feedback you received. Was the feedback about the presentation style? Your content could have been correct but came across unclear due to presentation style. Or was the feedback about specific requirements? You might have not discussed the requirements with a particularly knowledgeable SME who knew additional details to include. Be specific on your analysis to clearly articulate what the feedback is focused on.

Then work WITH the stakeholder to make it ‘right.’ Ask the person giving feedback what they would do to make it correct. A different presentation format? Additional requirements? Modify the acceptance criteria? And then literally make the updates right then and there WITH the stakeholder. They get to see you take the gift they have just handed you and apply it. Make the stakeholder part of the solution, not the problem.

This is a great consideration when you are trying to facilitate feedback. Rather than walking into a meeting with chest puffed out excited about how awesome your business requirements document (BRD) is, go in with an attitude of what’s missing. Business analysts practice asking good questions all the time. They often know there are risks with leading questions when you are talking to a stakeholder. If you lead them into an answer, then you will get that answer. You want a different answer, then you need to ask a wider question. If you are wanting feedback on your BRD, do not walk in telling people how awesome it is. In some cultures, they will simply smile and nod at you, giving you the impression you are right. Only the stakeholders are too scared to say anything and will discuss all the ‘wrongs’ only after you leave the room. Walking in with a more open attitude geared towards developing the great solution with those in attendance gives more space for the feedback needed for a successful solution. Do not forget why you need the feedback. The feedback is not about how well you’ve completed the task. Feedback is meant to help your stakeholders define, deliver and leverage a successful solution. That is your ultimate measure of success.

So treat your feedback like any gift you may receive this holiday season – always be thankful that someone has thought of you. Later you can decide whether to keep it, return it, exchange it, get rid of it or re-gift it for someone else but remember feedback always starts with a gift.

A Business Analyst’s CRM Labrynth

Written by Tom Lyttleton on December 6, 2018. Posted in Articles. 1 Comment on A Business Analyst’s CRM Labrynth

C-Suite executive level information systems, report, and dashboard requirements are evolving rapidly with IoT and digitization.

I am often asked to provide business process analysis for corporate CRM solutions. Many times, these requests are to review stalled or a “problem” information system project. I provide these on a one time, annual, semi-annual or quarterly time frame.

Firstly, the review process is best performed by someone not connected to the internal team or any software or vendor of the company. It is well worth the effort and cost to bring a 3rd party consultant into facilitate the elicitations and provide any recommendations. This seems obvious, but many organizations try to save money by performing system reviews internally. Most Subject Matter Experts and team members respond very differently when chatting with supervisor’s vs an outside consultant.
I use an approach that starts with business process analysis integrated with Gemba (the actual place) mapping. Then following the actual process flows from initiation to completion. The process of observing and documenting the actual workflow is very enlightening. I will walk you through it.

You began by sitting face to face with C-suite executives to determine the basics. The basics would include their view of the background of any internal Team’s SME’s (Subject Matter Experts).

If there is an internal team supporting the system, such as an Administrator or Architect, meet with them to determine their approach to providing functionality for the users. Does the Architect primarily have a buy, or build approach? Is there an internal roadmap with documentation of any major customizations or configurations? How do they communicate with end users?

With this high-level view in hand, one would start working with each operational role in the company. I like starting with the persons or processes that answers the phone. Observe and document what happens. (I use MS Visio to provide a living document.) Take note if the CRM system does integrate with caller id to display the caller’s information or into a CRM record, if already in the database?

An inbound call is a request for personal assistance. It may be for an appointment, a complaint, a lead wanting more information etc. Follow all these requests through the organization’s processes, observing and documenting as many steps as reasonable to determine efficiency and potential areas of concern. Does the user’s primary interface, or software home screen, allow them to perform all tasks for their area of responsibility? If not, what functionality is not being provided within the system?

You may observe CRM users entering data in other, disconnected tools, such as an excel spreadsheet or cloud application. Make sure to document these occurrences. Also, document suggestions from the users, defining how a system or process, could be made more efficient, from their perspective. User feedback is critical to any improvement. The best workflows are ones that follow the “Toyota Way”. They are continuously improving and monitoring, to eliminate waste, including waiting time, over processing, motion and of, course errors or defects. The process should be easy to use, intuitive and provide guidance through help screens and notes.

After gathering information from each role in the company, 3 categories of fixes may come to light. User interface issues, missing functionality, and user training.

A work screen for a user/role should be intuitive in that the work tasks should be easily performed and guided by the system. As an example, a role that inputs a new lead should be able to process the information required in an efficient manner and if necessary, with prompts from the system. The input screen should be limited to those fields that are required to move the newly inputted lead to the next step. In most cases, the required are name, email, phone, the lead’s reason for calling code, product type, service, more info etc.

Missing internal functionality is exhibited by using external tools. This is an area for risk analysis on a number of levels. Error, data corruption, and/or duplications are possible issues that may occur as there may be limited cross checking between external tools and an internal to the CRM system, record.

User training and disconnections from the system architect(s) is one of the potential issues with remote development or configuration, the disconnect between what the architect thought was intended and what the user really needed. As an example, a user was not aware that picklist fields were available to select attributes for a new lead. The fields were not placed in a highly visible area nor were they made required fields. Consequently, the user(s) elected to place this information in a text field. This created records that are not as useable or referenceable for other roles or workflow rules. Any system error checking or field validation is lost. This exemplifies two failures, one to train, (Documentation?) the other not providing a simple, easy to use, data entry screen.

We learn a great deal from these sessions. After accumulating all the information found and documenting the current state, we document from the team, all possible improvements. With using the same tools, the potential process improvements are documented, and GAP analysis performed.

The current state model may expose some decisions that were made when other options weren’t available. Perhaps decisions were made as functionality development, vs configuring an existing tool, were done unintendedly without understanding the risks. The model may also expose poorly executed or incomplete modifications and implementations.

With the gap analysis complete, the Business Analyst can provide further clarity by evaluating potential improvements for effort vs gain to the organization. Many times, they will find that an easy, fast, configuration wins in this area. In turn, this will improve team and user’s morale. I like to prioritize those.

Present 3 possible solution and/or improvement paths for the stakeholders to debate where there isn’t a clear single path. It is critical that the stakeholders determine which path to take. Change management will be monumental without user buy in, ahead of any proposed changes. The fact that the users have been involved from the discovery process on, helps immensely.

The Independent Business Analyst must remain unattached to the decision, assuming as much of the risk or reward as possible to be exposed to the decision makers. Document the decisions and deliver the report.

Agile Business Analyst Mindset

Written by Dip Bhattacharjee on December 4, 2018. Posted in Articles. 1 Comment on Agile Business Analyst Mindset

The paradigm shift from waterfall to agile methodology has put traditional business analysts at cross-roads.

Like any other disruption – Business analysis as a profession has been challenged as never before. Business analysts sometimes struggle to answer the following question of how is the agile world different from the traditional methodology of business analysis and how to adapt and respond to this change.

Let us first look at why and who is a Business analyst. A business analyst is someone who helps solve Enterprise problems – someone who bridges the gap between Customer and Technology. Business stakeholders seek those Business analysts (s) who can efficiently perform Enterprise analysis, conduct elicitation to bring out the real business need and deliver a solution which will solve those business-critical problems.

To respond to this paradigm shift and still be the trusted partner to our Customers and Business stakeholders, we ( business analysts) need to introspect the roles and responsibilities as well as the mindset that we bring to the table when we work in the Agile world. In traditional project delivery methodology, Business analysts are responsible for documenting business requirements and develop the functional/non-functional specifications and heaps of other documents and processes. Obviously, over a period of time, Business analysts start to feel that they the real owners of the project. To technology team Business analysts are face and voice of Customers. Without a doubt, this approach means heaps of responsibility on the shoulders of Business analysts and makes them an integral part of the project, but at the same time, there are few major pitfalls of that approach as described below.

Firstly, there is more than required dependency on the Business analyst(s) for a successful outcome of the project which sometimes may be demotivating for other team members. To add to that requirement put forth by traditional BA(s) to the team are documented in a way that it not only specifies the “WHAT” but also that is documented in a way that guides the “HOW” of the solution. which may not deliver the best Customer outcome(s)

As stated the four values of agile delivery are:

Individuals and Interactions Over Processes and Tools. …
Working Software Over Comprehensive Documentation. …
Customer Collaboration Over Contract Negotiation. …
Responding to Change Over Following a Plan.

What that means to for Agile Business Analysts is People, Interactions, Collaboration and ability to adapt and change. How that will help us deliver to business goals.

Firstly, the willingness to adapt and learn. A business analyst has to deal with a new set of problems on a regular day to day basis and no two business or Customer will have exactly the same problem, nor they want exactly the same solution. At the least, the stakeholder expects a better solution. A key to achieve a successful outcome for a business analyst is to have those interactions with Customer and understanding the real need as well as facilitate discussions which will help deliver a better end result for the Customer. A mindset which focuses on the willingness to learn and change – will have key traits of Respect, Collaboration, and interactions, which in turn will help deliver better customer outcomes.

Secondly, People and Interactions. A traditional approach to business analysis is focussed around processes and documentation – what is not documented does not make its way to the solution, and that is the last thing that we would like to deliver as a valued outcome. They ( Customers ) want us to read their mind and deliver a solution which would solve problems which were not documented. A mindset which is people focussed over processes – will focus more on interactions and understanding the real needs as opposed to documentation – as well as work as an enabler who helps facilitate positive and healthy interactions inside and outside of team – thereby bringing in more brain power and valuable insights into each and every discussion. This translates into a healthy team culture, where people will take ownership and be open to ideas and interactions. A people-focused Business analyst will restrict themselves from dictating what and how but transform them as an enabler of how to achieve a better customer outcome. A big win of this mindset is getting insight into real Customer need and deliver a solution which not only meets business criteria but also delivers a value to our Customers

Lastly but not the least, responding to change. Any business problem is subject to change over a period of time, be it not being a problem anymore or change of priority or how to solve it. A key to success for an Agile business analyst is to understand this pertinent fact that requirements can change over time and hence deliver is short chunks to not only deliver quick wins but also de-risk the outcomes and at the same time have the willingness to respond to changing situations. This is a change of mindset over traditional approach but also enables the Business analyst with the flexibility of dealing with changes in a more collaborative manner.

To summarise, given the world we are in today, the skills of traditional Business analysts still hold good but it is about customer-centric delivery, where our outcomes must meet or exceed the expectations, and a true way to do deliver on that promise for an Agile Business analyst is to adapt to agile mindset.