Tag: Facilitation

The Modified Design Sprint: Simplifying a Tried and True Brainstorming Method

Written by Charis Horner on November 19, 2020. Posted in Articles.

Facilitating team brainstorming is a key skill for BAs in product development. How can we generate innovative, divergent, and executable ideas that meet customer needs?

Jake Knapp, John Zeratsky, and Braden Kowitz dove deeply into this problem and gave a beautiful gift to the BA community: The Design Sprint. (You can read all about it here.) The Design Sprint is a four- or five-day brainstorming session, with structured activities and outcomes taking a team from a big problem to a tested solution.

But what if you don’t have five days? What if you need to make a major decision and you need to do so… now? My team faced this very question and created a new version of Knapp and Co.’s game-changing process: The Modified Design Sprint.

What is the Modified Design Sprint?

The Modified Design Sprint (MDS) applies tools from the original Design Sprint to team brainstorming and decision making on a smaller scale. It uses timeboxing, collaborative ideation, heat map voting, and Decider overrule to mine information from team member’s brains and create a shared understanding. While the original Design Sprint ends with a tested prototype, the MDS gives the team prioritized, Decider-approved, team-backed ideas for further development – and it can be done in as little as an hour!

When should I use a Modified Design Sprint?

You may want to consider using an MDS when:

An effort has a lot of unknowns
You need answers to questions or solutions to problems from a diverse set of people
The team has a lot of competing ideas and you need to pick a lane
There is a lot of work that could be done, but you need to quickly prioritize the most important things

How do I carry out a Modified Design Sprint?

Fear not: The MDS requires only slightly more legwork than a typical meeting – and yields more quantifiable results.

Assemble a team

First, pick a Facilitator. This should be someone good at getting to the root cause, directing conversation, and asking open-ended questions. (Hint: It’s probably you, the BA or PM.) The Facilitator ensures the team accomplishes its goal.

An MDS is not a democracy – it’s a benevolent dictatorship, so you need a Decider. This person can ratify or veto decisions. It might be the CEO, Product Owner, or Team Lead. The MDS empowers the Decider to make fully informed decisions on key issues, emboldened by the team’s expertise.

Round out the team with anyone who has an important perspective for your effort, like other BAs, marketing professionals, developers, researchers, and designers.

Define the Goal and Questions

A successful MDS begins with a clear purpose. Are you trying to prioritize system functionality? Determine the MVP for your product? Decide on a solution for a proposal? The Facilitator and Decider should draft this goal before the session.

Once the goal is defined, you need a list of Sprint questions that represent decisions to make, customer needs to meet, problems to solve, or any other area where you want diverse team input.

Set the Agenda

Once questions are decided, the Facilitator should create a timeboxed agenda. This suggested agenda for a 60-minute session leaves 5 minutes to add wherever the team needs more.

Set the stage (10 min)
Draft Ideas (15 min)
Review Ideas (10 min)
Vote (10 min)
Decide (05 min)

Do the Prep Work

The Facilitator needs to get the room set up before the MDS. There are plenty of virtual tools for this like Miro, Mural, and FunRetro. In an online tool, set up each of your questions as a column, with sticky notes in the rows below. If you’re in person, you’ll need sticky notes, pens, expo markers or voting dots, and a whiteboard. Write the agenda, goal, and questions on the board. Here’s an example of an MDS board in Miro:

Set the Stage

Begin the MDS by reviewing the agenda, sprint goal, and explaining the Facilitator and Decider roles. Then review the question list and ask if anything is missing. If there are blind spots your team was hoping to solve, now’s the time to identify them.

Draft Ideas

Silently, everyone takes their sticky notes and answers the questions on the board. The Facilitator should give time reminders so that team members stay on track.

Review Ideas

This part is tricky; the goal of reviewing ideas is not to determine their value, but to ensure they are understood by the team. Read each sticky note out loud; if anyone needs clarity, they should speak up. Once clarity is achieved, move on to the next sticky note. For the sake of time, the Facilitator should (nicely) jump in if the conversation begins to derail. The next step will allow everybody’s voice to be equally heard.

Vote

This is where the magic happens. It’s time for the team to decide which ideas should rise to the top. There are two approaches to voting:

Heat Map: Each person has an unlimited number of total votes but can vote on each idea up to 3 times. This turns the board into a “heat map”, as the best ideas will have the most dots on them.

Tough decision: Set a voting cap, such as 3 votes per column, or 15 votes for the whole board. Each person can only vote on each sticky note once.

Decide

Using the team’s votes as a guide, the Decider looks at each column and picks the ideas which MUST be included. Most Deciders pick the highest voted items, but they can choose other items they believe are necessary. Selected ideas become the “winners” for further development. Unselected ideas can be typed up, tabled, and revisited at another time. Now you’ve got clear direction on key ideas for success.

The MDS can simplify brainstorming to quickly give the team a path forward in difficult ideation areas. Ready to try it?

Sketchnote Sceptic?

Written by Christina Lovelock on October 16, 2020. Posted in Articles.

Visual thinking skills and the creation of visually engaging outputs are becoming more popular and prevalent. Is this a valuable business skill, or a forgettable fad?

What Are Sketchnotes?

The technique was defined and developed by Mike Rohde, and is closely related to other visual disciplines such as graphic recording, visual meeting facilitation and rich pictures.

Sketchnotes combine words and visual elements, to create a record or convey information. The visual elements might include simple sketches, icons and borders. The textual elements can be words or sentences, and make use of different fonts, styles, size and direction. Sketchnotes can be created digitally and by hand – or a combination of both.

The Case Against

Attention seeking?

Sketchnotes often grab our attention, but information filtered through someone else’s brain may arouse more questions than answers. “It’s interesting to see what someone else has learned, but is it helping me learn anything?” The usefulness of other people’s sketchnotes is very variable.

It’s for creative-types!

The professional sketchnote images we see can make us feel inferior. “I wouldn’t know where to start” and “I can’t draw” seem like valid barriers to trying this technique.

All the stuff

As with most aspects of our lives, there are a lot of options. This can translate to what feels like a lot of decisions to make, and “I don’t have the right pens/software/tablet…” can lead to an outcome of ‘do nothing by default’.

Really Listening

People speak quicker than we can write (or draw). If we are concerned about creating an attractive output, this might mean we miss something.

The Case For

Attention seeking?

There is no obligation to share our sketchnotes. We can all experiment with sketchnoting free from the pressures of other people’s opinions. The time may come when we create something to be proud of, and would genuinely be of use to others, but equally the notes are personal and do not have to make sense to anyone else.

It’s for creative-types!

The fact that professional photographers publish beautiful images does not stop the rest of us of using our phone cameras! Creativity is a skill that can be practiced and improved, not a set aspect of personality. We don’t need permission to try something creative, even if it’s outside our usual approach.

All the stuff

Though it would be tempting to believe the right equipment and software would take significant investment of time and money, the reality is that we have everything needed to try it. A pen, some paper, and something to learn or remember.

Really Listening

With the growing amount of virtual input – TED Talks, webinars, online events, remote meetings, we can easily become distracted or attempt to ‘multi-task’. Sketchnoting provides a mechanism to give our full attention to the situation at hand. Distilling the key messages is easier with sketchnoting than traditional notes!

Source: qaspire.com. Image reproduced with permission.

Sketchnote Skills

Listening and comprehension skills are more important than drawing skills for creating great sketchnotes.

People often use visual imagery when speaking, mention anecdotes and use metaphors. By picking out these visual clues, we can enrich the linear verbal information to create a connected visual record. Learning a very small number of icons can build the confidence to add images to notes.

Conclusion

Sketchnotes provide a lasting record of personal development activities; including books, events and training. Over time this builds to a library of knowledge we will be happy to revisit, to reactivate and refresh the learning.

If we let go of the desire to be perfect, and the narratives we tell ourselves about ‘not being creative’ and ‘no good at art’, we can move away from the ubiquitous pages of text and bullet points. We can create engaging outputs that help us remember more, synthesise information and make connections.

Resources

Mike Rhode, The Sketchnote Handbook (2012)

https://rohdesign.com/sketchnotes-1

http://qaspire.com/sketchnotes/

www.meetup.com/TheVisualJam

https://graphicsmadeeasy.co.uk/

The TRIFECTA – Bringing Together People, Process & Technology

Written by Alycia Michels on September 10, 2020. Posted in Articles.

Many of us have been at an organization where the business has identified there is a problem or an inefficiency, but the root cause has not been identified.

Sometimes, people feel they don’t have time to spend looking into the issue and then the problem lingers. Other times, the quick fix is let’s hire more people or let’s buy this piece of technology. You might be nodding your head, but these seemingly quick fixes are usually not the long-term solution.

I often get approached by groups that have a problem, but they don’t know what is causing the problem. Recently, I was approached by a group that had spent months trying to improve their operations. They brought in different people to help turn things around, but they still were not seeing the expected improvements. They were at the point, where they were contemplating a new technology solution. While this may sound like a slam dunk for many people, I am a strong believer that you need to figure out your current state before making a recommendation for the future state.

To figure out the current state, it requires bringing together what I call the TRIFECTA. The TRIFECTA is people, process, and technology or some refer to it as the three legs on a stool. The TRIFECTA is essential to having successful business and/or teams. You can have one, but without the others you will struggle to succeed.

People –

You can hire amazing people with great skills and experience, but if you have inadequate processes or technology these people may struggle. When people struggle, they often get frustrated and can potentially quit. You can give a person a canoe, but if you don’t tell them where the water is or give them a paddle and tell them how to use it, they may not make it far.

Process –

You can have wonderfully detailed standard operating procedures (SOP), but if you do not have the people that are invested in following the SOP then it is just words and pictures on paper. If you do have great people and processes, but lack technology you can only scale so far. You can give a person instructions, but if they are in French and you can’t read in French and you don’t have a device to translate them with you are left with a lot of paper that might end up being beneficial to start a bonfire.

Technology –

This is my favorite. “If we just buy “x” system it will fix all of our problems”. I really wish it was this easy, I truly do. However, there is no easy button in life. You can have great applications and software, but if people don’t know how to use it or aren’t bought in on why they should use it then you have this wonderful technology just collecting dust on a shelf. You can buy a bike, but if you don’t learn how to ride it, then you just have a nice a bike.

While pulling together the TRIFECTA might seem like a tedious task, in the long run it often pays off. In the above example, we spent two weeks interviewing team members, mapping out processes, and identifying opportunities. We discovered over 100 opportunities and put together themes for leadership to prioritize. It took a few months to execute the identified changes and technology enhancements, but they have seen improvements across the organization and the process flows hang in the office as a reference and training aid.

Some of you might be thinking we can’t spend two weeks on this because “we have a business to run”, “I already have a full-time job”, or “we will do it later”. Taking the time to meet with teams and talk about the people, processes, and technology that is used in their day to day helps identify problems or inefficiencies. In my experience the root cause is often more than one thing, but a myriad of things, if you don’t talk about them, they can linger.

Some organizations may think that they can throw anyone in and they can do a great job at business process analysis, but it really requires a person with a specific set a skills and behaviors. They don’t have to know anything about your business or process, but they need to be curious and passionate about learning how things work and have a desire to help improve the process. A person that can ask tough questions and help identify where the opportunities are.

Next time you identify that you have systemic issues, pause and think about if it makes sense to pull a small team together to dive in and do some analysis. Getting leadership approval for a team might seem daunting, however if you put together a business case and document the skillsets that would be needed to be successful it will be easier to share the need and vision with your leadership. You may find once you have successfully pulled together the TRIFECTA there is a desire to repeat it in other areas of the business. Having a small team that can be dedicated to business process analysis and improvements is ideal as it allows for these individuals to dedicate their time to work through these specific problem areas. Some of you may already have people in your organization with the necessary skillsets and behaviors that you could leverage to successfully drive these types of efforts. Your leaders may worry that this type of work will dwindle, but having people with diverse skillsets and behaviors can allow them flex with multiple groups like business analysts, lean champions, or continuous improvement teams.

How to Figure the Detail of Process Models

Written by Jamie Champagne on July 24, 2020. Posted in Articles. 2 Comments on How to Figure the Detail of Process Models

I love that a fellow analyst asked me a question as they were having trouble being asked about putting “narrative on their process model.”

We started with the first question – WHY? Simple, yet seriously, we’re so good at OVER analyzing and getting into analysis paralysis that sometimes just trying to figure out what is going on can save others (but especially us!) LOTS of valuable time!

With the first question, the answer was easy – they want more information. Okay, so then the next questions is then about what the PURPOSE of the model is? What are you trying to accomplish with your process model?

Good foundational, IIBA® BABOK® Guide v3 (2015) states that the purpose of process modeling is to provide a “standardized graphical model…to show how work is carried out…as foundation for process analysis.” So are we showing ONLY how work is carried out? Or are your stakeholders asking for much more?

We have data models and stakeholder RACI matrices and other valuable tools because they’re great at what they’re used for! They each have their own purpose! So ask yourself if you’re ever having difficulty with your process model because you’re trying to do WAY more than model a process?

This is the analysis skill – identify what questions are being asked or needing to be answered and facilitate getting that information to the needed decision makers. If people ask lots of questions about who is doing what on your process, then maybe we do need greater detail on the stakeholder ownership. Perhaps there is no ownership? Or don’t overanalyze and just add a new swim lane if it makes the users happy (and of course understand better!). If people ask lots of questions that revolve around data, do we need a data dictionary and some data modeling or data flow diagrams? This is common when you meet with stakeholders of different levels of focus. Too often process steps, decision points, data elements, stakeholders and end products are thrown at the analyst. Do not feel compelled to write everything on the process model. Write PROCESS on the process model and make notes on the side. Then look at your notes. Are all the notes about data? Then your own notes tell you that you need some data definition. And don’t be afraid to acknowledge that there’s a mix of high-level overview requests mixed in with the “give me the technical details down to the line of code” demands. Just then make your model flow so that each view or screen or page is only showing ONE level. Then with technology today just link it to the page with the lower level of detail. Don’t over complicate it trying to take a full course on modeling software or anything. Simply list high level functions with overall business areas on your main page. Then for each one of those functions, create a “clean page” with just that function’s information. And then you can work WITH your stakeholders to define as much information as they at that deeper level, while keeping everyone on the same page at that higher level. Even better, with this approach, you just created a strategic, overview perspective as well as tactical or operational details. Now you’ve helped multiple groups from starting with a single model!

See what information comes up from the stakeholders on what is missing or needs to be added to make the process model USABLE. You are creating a process model for OTHERS to use. If the level of detail is high and you’re not sure it’ll work – ask! Share it out and see if people have questions. If they have none, then you’ve done what is needed to help others get things done! Analysts process model to facilitate, not own. The model is the stakeholders’, teams’ or client’s. It’s for them to get their work done, complete projects and create great new products. If they ask lots of questions, then help them get the answers. And as you do, always think what is the most efficient and effective way I can get them the answers. Just because they want all the information on the same visual, does not mean that it will help them answer their questions. But to know what to capture appropriately on process models, means you need to know what everyone is trying to accomplish by using your process model. Make it an actionable document. Anything you produce should be reusable over and over again – from decision making to operations and troubleshooting – and by people other than you! That’s the true value!

So next time someone tells you that your process model is lacking lots of information or needs other data and elements added, ask why and get clarity on the stakeholder’s need and what they hope to accomplish WITH your model. Then work with them to help develop a model that answers their questions and supports their decision making.

Applying Maslow’s theory of Needs to Business Analysis

Written by Ashish Adike on June 17, 2020. Posted in Articles.

Having worked on multiple IT implementations and Transformation projects I have often found the evolution of user’s requirements follow the Maslow’s theory of needs.

Adoption of this theory in the requirement gathering process would turn out be fruitful for Business Analysts in efficient Requirement Elicitation from the Users.

Although most of us are aware about the Maslow’s Theory of needs, a quick memory refresh would be helpful:

Maslow’s hierarchy of needs displays the order of human needs in the form of a Pyramid with lowest levels made up of most basic needs moving on to the top of the pyramid with complex needs as depicted below.

Physiological Needs: The basic human requirements to survive would comprise the Physiological needs like Food, Water, warmth, and rest.

Security/Safety: Once the Physiological needs are satisfied, the need for security and safety arises. This comprises of financial, emotional, social security, and health and well-being.

Love/Belonging: These needs are driven by interpersonal relations like friendship, love, trust and acceptance among individuals.

Self-Esteem: The fourth level of needs arise out of the feelings of getting praised by others for self-accomplishments be it professional, academic, athletic, or personal.

Self-Actualization: The final level of needs reflects the realization of individuals to utilize the complete potential, so that they can do the best that they are capable of doing.

Now coming back to our original discussion on following the Maslow’s theory of needs for requirements elicitation, the below framework often works to elicit requirements from users starting from basic system requirements to the complex analytical requirements to explore the full potential of the system.

The 5 evolving stages of requirements are Data Capture, Data Security, System Integration, User Experience, and Analytical Capabilities. As we progress from bottom to top of the pyramid, the responsibility of BA to make recommendations to elicit the requirements from the users increases. Let us look at each of these stages by taking an example of a Salesforce CRM implementation

1. Data Capture:

The first stage is critical and forms the major portion of requirements as this serves as the foundation of the implementation just like the Physiological needs serve as the base for human survival.

In general, any IT implementation would start with a problem statement where the Business has an issue with missing data capture or users spending their valuable time on mundane repetitive tasks which could be automated. It is the responsibility of the Business Analyst to capture the basic needs from users in terms of data they would like to capture, and the level of automation required to perform their everyday job.

In our example of Salesforce implementation, the information that needs to be captured like Leads, Opportunities, Accounts, Contacts need to be captured at parameter level with respective UI forms for data capture along with validations. Also, the automations that govern the system functionality need to be captured. For example, updating a parameter in Accounts from the corresponding parameter on Contact.

2. Data Security:

Once the basic requirements are established with respect to Data storage, User Interface and automations, the security of the data recorded in the system becomes critical just like need for Security in human life.

Different sets of users would need access to different data elements and the level of access in terms of Read/Write would differ as well. The BA needs to carefully gather the requirements of Data Security from users and work on profiling of these users.

In our example of Salesforce implementation, the Sales team would needs read/write access on Opportunity data whereas the Finance team would only need read access to Opportunities to perform forecasting and the Operations team might not need access to Opportunity data at all. There would also be scenario when one Sales Representative would not want other Sales Representative to access his Opportunity data. Hence, the Security of the data forms the next level of User needs in order to feel secure while using the application.

3. Data Integration:

Once the data is recorded in the system and is secure within the system, the next need is to have communication with other systems so that there is proper exchange of information between the systems to complete the end to end transactions. This is like the need for interpersonal relations like friendship between humans.

Different systems serve as the system of record for different data elements within an IT Architecture. Also, in most cases there is always a Master data system where all the critical data gets stored. As a BA it is important to identify the need for the required data for an application to work as expected and identify the downstream systems which would use the data from the application. This information may not be directly provided by the end users, but it is the responsibility of the BA to study the IT landscape and identify the different source and destinations of data.

In our case of Salesforce implementation, the Customer Account information would generally be recorded in the ERP, so Salesforce needs to integrate with the ERP to get the Account information. The Order information from Salesforce was used by downstream order fulfillment application, so Salesforce needs to integrate with this downstream application to complete the Order fulfilment process.

4. User Experience:

Once a working system is in place with the required basic functionalities to fulfill everyday job of the user, the user experience factor comes in which would further drive the requirements to make the system more user friendly and intuitive, hence leading to appreciation of the system by the users. This is like the self-esteem needs of human life.

Now that the basic functional requirements from the user are gathered, it is the responsibility of the BA to drive the requirements for better user experience. This would encompass aesthetic requirements like the look and feel of screens, user guidance while using the system, mobile usability etc. Although this type of requirements might not sound critical during the initial implementations, they turn out to be critical once the users start using the system, and there have been projects purely focusing on improving user experience.

In our case of Salesforce implementation, the choice between using Salesforce classic which is traditional user interface as compared to Salesforce Lightning which has an advanced User Interface would be critical in determining the user experience.

5. Analytical Capabilities:

Once the requirements for a fully functional and user friendly system are established, the insights that the data stored in the system could provide to the user becomes important, as it would enable the user to utilize the complete potential of the system and make business decisions. This is like the need for realization of individuals to utilize the complete potential so that they can do the best that they are capable of doing.

The Analytical requirements would be predominantly in the form of Reports and Dashboards that could be derived from the data stored in a system. With the advancement in Artificial Intelligence, the data could be used to provide suggestions to the user as well. Many a times, the user may not be directly able to give requirements with respect to Analytical capabilities, so the BA needs to determine the KPIs for the business users and recommend the suitable reports and dashboards around the same.

In our case of Salesforce implementation, once the Sales users have a well-functioning Opportunities module in Salesforce, it would be great if they are able to generate reports on the Opportunity pipeline and even better if they have a dashboard depicting the Opportunity Pipeline which would enable them to make quick decisions.

Requirement elicitation is often complex with users not being able to articulate the exact requirements in a proper order. Following the bottom-up approach from the Pyramid would help to a great extent in eliciting the requirements from users, starting from basic to the complex requirements.

References:

1. https://www.simplypsychology.org/maslow.html