Tag: Best Practices

Cooking Up Business Analysis Success

Written by David Shaffer on December 21, 2015. Posted in Articles. 1 Comment on Cooking Up Business Analysis Success

In 1961, the great Julia Child revolutionized the cooking industry with her book “Mastering the Art of French Cooking”. This book cemented Julia as an expert in French cuisine and launched her career as a gourmet chef.

In 1963, Julia used her new found fame to revolutionize the television industry by creating a weekly half-hour cooking program. Her success paved the way for all of the cooking shows on television today.

So what does this brief history of Julia Child have to do with Business Analysis you may ask? Let me explain. Julia’s book was extremely successful because it provided very clear, simple instructions along with supporting photographs to illustrate the final product. This recipe for success launched Julia Child’s career from relative obscurity to international fame.

To succeed as a Business Analyst, you must strive to deliver consistently clear and unambiguous requirements that are understood by all audiences. The most successful business analysts will also create visuals to support the requirements they write. In this respect, BAs would be very wise to follow the formula that launched the success of Julia’s famous book.

I’ve developed a recipe that business analysts can follow that will ensure they will deliver high-quality requirements that are guaranteed to satisfy the business needs of their customers. The recipe is as follows:

Define the problem
Define the Scope
Create an Actor – Goal list
Create supporting visuals
Write detailed requirements

Step 1 – Define the Problem

The very first step in the business analysis process is to define accurately the problem the business needs to solve. It is human nature to rush into a solution. However, a great BA would be wise to keep in mind the famous words of Albert Einstein, who once said “If I had one hour to save the world I would spend 55 minutes defining the problem and 5 minutes solving it.”

In my experience, most people on the project team as well as management, are impatient and want to push forward with implementing a solution as quickly as possible. They fall in love with the solution, not the problem. This mentality significantly increases the risk that the project will deliver a solution that does not fully meet the customers’ expectations. BAs must lead teams to fall in love with the problem, not the solution. So how does a BA slow the team down and concentrate on defining the problem? We need to use a simple template for a well-defined problem statement. The template contains four simple sections.

Ideal – this section allows our customers to define the ideal solution or process. It forces the stakeholders and the project team to define what would be an ideal solution to their problem. The information discovered via this exercise will help determine the actual scope of the project as well as uncover the most important features the customers are expecting. Feel free to use collaborative games or other interesting elicitation techniques to make this a fun exercise for your team.

Reality – this section allows our customers to define the current reality of their situation. Understanding the reality of a customer’s current situation is helpful to understand the most significant pain points in the current process. Empathy mapping is a useful technique for this section since it allows you to understand how users feel and think about the current process.

Consequences – this section is used to define the actual consequences the business may suffer if the problem is not solved. It is critical to define the actual consequences that the current problem is causing. For example, ask your stakeholders if the current problem is causing productivity loss, revenue loss, or is putting the company at a competitive disadvantage. Understanding the actual consequences allows the business to prioritize the project. It also allows the project team to understand how the solution they create will actually impact the business.

Proposal – the proposal section is used to articulate options for solving the problem. Completing this section allows the delivery team the opportunity to provide an initial set of solution options which are feasible. Having your customers and the delivery team have a discussion on potential solution options is extremely important. It ensures both sides are in agreement on the path forward and helps to define further the scope of the project.

Step 2 – Define the Scope

Once the problem is defined via a well-defined Problem Statement the scope of the solution is much easier to lock down. The Scope Statement does not need to be a complicated document that takes a long time to complete. The information provided in the problem statement should allow you to come quickly to an agreement on what is in scope as well as what is out of scope.

Step 3 – Create an Actor – Goal List

Great business analysts are able to understand who is involved in the current process as well as who will be involved in using the new solution. This analysis results in the creation of a list of Actors associated with the current problem. For each Actor identified the business analyst should understand the goal they are trying to achieve. For example, let’s consider a typical web-based application that allows a customer to order products. A realistic Actor – Goal list for this solution would be:

Customer – Search for Product

Customer – View a Specific Item

Customer – Add Item to Basket

Customer – Place Order System – Verify Payment Information

Obviously, this is not a complete list, but you should get the idea. If you write each goal in Verb – Noun format you may simply associate each Actor – Goal combination with a single Use Case or User Story. This exercise allows you to organize the requirements in a way that ensures the most important functions of the stakeholders are accounted for.

Step 4 – Create Supporting Visuals

Using visualization is absolutely critical to convey requirements. Visuals allow for the proper discussion to occur in order to elicit the detailed requirements from your stakeholders. A picture truly is worth a thousand words. Visuals may include mock wireframes, prototypes, process flows, and data flow diagrams. Visually mocking up the solution allows the BA to obtain feedback quickly and discuss the details of the proposed solution prior to developing it. Taking the time to create visuals and discuss them allows the detailed requirements to fall simply out of the discussion. You will be amazed at how easily the requirements become clear when you are discussing a visual with your stakeholders.

Step 5 – Write Detailed Requirements

Once the problem has been well-defined and agreed upon, the scope has been solidified, the actors and their goals have been considered, and the visuals have been discussed, you are ready to put together the detailed requirements. Each requirement should be associated to a single Use Case or User Story, which is directly associated to a single Actor – Goal. This ensures that each requirement is directly involved in satisfying a goal of your customer and will be adding value to the solution. Requirements should be written in Subject-Verb-Object (SVO) format and be clear and unambiguous. The key to clarity in the English language is the relationship between the Subject, Verb, and Object. If a common sentence clearly defines WHO the Subject is, WHAT they will be doing and to whom they are doing it, then the reader should have no problem understanding it.

Following this recipe for requirements elicitation may not launch you into international fame and a lucrative television show. However, it is likely to set you on a path for success in your business analysis career by establishing agreement and trust within the team.

Strategy Spotlight: Breaking Down 4 Process Levels in Your Organization

Written by Richard Lannon on December 15, 2015. Posted in Articles. 1 Comment on Strategy Spotlight: Breaking Down 4 Process Levels in Your Organization

Everything that happens in your organization and cuts across the levels of organization can be divided into ‘big buckets’ of things that the business does.

Chances are, you have some people in charge of those buckets. Often we see human resources, financial, information technology, and manufacturing processes being part of the list. But what if your organization has other things going on? You might have a whole research and development department that has processes that cut across the organization. If you missed these in the high-level identification of business processes, you might create a negative impact for the company by not representing all the true processes that exist.

There is an impact to understanding that all organizations can be broken down into at least a four-level process model like the maturity model discussed in an earlier blog (5 Business Processes to Your Evolutionary Success). However, there are other process level models that look at the business slightly differently.

Tari Kaupapa from the project office of Massey University outlined a Four Level Process in his paper on “Process Mapping; Process & Guide.” He used the following guidelines to understand and identify the different processes in the business organization:

Level One: is the standard high level and lists the operational levels of an organization.
Level Two: depicts the end-to-end processes across the operational areas.
Level Three: shows the roles and associated steps required to complete a specific process within an operational area.
Level Four: is the documentation of instructions and procedures required to complete steps in the level three processes.

Within this model, everything must link and connect. Failing to do so could have bottom line impacts, due to cost changes and productivity mishaps. It’s also important to know exactly which level of the organization we are dealing with and when. The candid discussion happens when you review your business process maturity levels at the same time as determining what process level from Kaupapa’s model you are at. The best bet is to pick your processes and then figure out with your team what process levels you’re at, which buckets they belong in, how they link together and where improvements need to be made.

Level 2 and 3 are the tactical levels in this model. You’ll need this level information, both for strategic conversation and also to bridge the gap between the strategic and the operational. Whatever happens, level 2 and 3 in your business should be categorized and be part of the level one items–those big buckets that have an impact on the entire organization.

Level 4 thinking is in the weeds and is not for the business leader. Still, it is often customer-facing and is, therefore, important for you to know and understand, especially around how it impacts to your business. Awareness is what is important here.

Every process in your business belongs somewhere. Whether it is about finding Kaizen opportunities (7 Wastes in Your Business), applying a business maturity model (5 Business Processes to Your Evolutionary Success) or evaluating your process levels. Often it comes down to how efficient and effective your business is within the common constraints of time, money and resources, and the need to cut costs while improving productivity.

Focusing on the STORY in the User Story

Written by Robert Galen on November 3, 2015. Posted in Articles.

The user story has nearly become the ubiquitous requirements artifact in Agile contexts. User stories have had much written about them, their format, how to write them, the associated acceptance tests, and more.

As for acceptance tests, we’ve moved beyond writing them to articulating them as “executable tests” in tools such as Cucumber and Robot Framework.

All of this evolution has been great, as is the focus on the collaborative aspects of the user story.

But I’m starting to see something troubling in my coaching travels. I think we might be focusing too much on the user story as an Agile requirement artifact. Instead, we should be taking a step back and considering the user story as a much simpler communication device.

That is simply as a STORY, and much less as a written story, but moreso as a story told face-to-face.

Imagine

In fact, as I’m writing this, I’m envisioning the quintessential storytelling scene where a group of scouts is in the woods, surrounding a fire, late in the evening. And the Scoutmaster is recounting a story to them. It’s usually a scary story, intended to entertain, but also raise the angst of the listeners.

As the story continues the scouts lean forward. Their pulse increases and they begin to hear noises in the surrounding woods that raises the hair on their arms. They become a part of the story. It becomes real to them, and they can envision the words. In fact, for a short time, the story becomes their reality.

I believe this is the sort of intention that Kent Beck had for user stories when he initially created them. It wasn’t a requirement, but instead it was an engaged conversation between the team and their client.

It was intended to get the client or stakeholder to sit down with their team and share their vision in a storytelling fashion. It was intended to be collaborative, with ideas being shared, and questions being asked. As the discussion unfolded, the team would become intimately familiar with the client’s challenges or problems that they were trying to improve.

And instead of telling the team what to deliver, they simply shared their perspectives. And the team would respond with empathy and understanding around how to implement things to help their client. In fact, they also started thinking of the experiments they might run to narrow any gaps in their understanding.

If that was the original intent, let’s start to look at some of the aspects of potential storytelling within agile teams.

Put The Client First

The more we can envision the client and their context, the better the team will be able to implement solutions that will solve their challenges and ultimately surprise and delight them.

Tell stories about your clients. What is their motivation? What is their environment? What is their experience level? Who are they – specifically? And importantly, what problems are they trying to solve with their requests?

Related Article: 50 Ways to Write a Great User Story

Find out what excites them and what doesn’t. Don’t just explore their immediate needs, but try to understand their future challenges and where they might be in a year or more.

The Kano Model talks about three basic categories of customer needs:

Delighters or Exciters – the WOW factor in a product or application.
Basic Needs or Must Have’s – these are “table stakes” for the product.
Performance or Linear – the more of it, the better.

These three types of customer needs are mapped against how satisfied the customer’s reaction to them are AND against the execution and quality delivery dynamics of the team.

Better than talking about the client, invite them into your team. The more direct the communication, the better. And using a model such as Kano to explore their reactions to features, priority, impact, and need can be powerful. Not only in deciding what to build and when to build it, but the conversations around Kano are even more powerful.

Here’s my reference to Kano – http://www.agilebuddha.com/agile/faster-time-to-market-or-lower-cost-of-development-is-a-delighter-anymore/

The Backstory

Quite often there are a series of reasons why your clients are asking for a software feature. Some of them are driven by business needs. Others are more contextual, for example, an older system is so aged that it no longer meets their needs. Or they need the functionality, but in an upgraded, more maintainable “package”.

Often the backstory is unsaid, and you’ll need to “tease it out” of your clients, stakeholders, or customers.

You also need to push through the first reaction, which is often – I need it because I need it. You’ll need to patiently “dive deeper” into their thought processes and motivations.

One effective way to do this is observation. Asking the customer to show you what they do today, which might give you insights into why they are requesting something new. For example, if they show you that their current process is slow or unwieldy, then speed and simplicity will be paramount.

Another way to explore this is by demonstration. Showing them simple paper and code prototypes that cost very little to build, to get their reactions and feedback. No matter how we do it, we have a responsibility for exploring the drivers behind our customer’s requests.

Now I want to switch gears a bit and explore some of the crucial tactics of our storytelling.

Tactics of Story Telling

A Good Introduction

Often it is quite useful simply to get to know your customer. What is their name? What is their job title or role within the company? Another point is their experience level? Before jumping in to say – how do you want this function or feature designed, stop and get to know them.

And this includes introducing yourself and sharing what motivates you as well. Come to a place where you’re simply getting to know one another to improve your ongoing relationship. Spend some time together and, most importantly, observe, ask open-ended questions, and deeply listen.

Motivation

I’ve watched actors prepare for their roles or scenes in plays, and a topic that often comes up is “their motivation”. The actress explores the role and the events and experiences leading up to the current situation or context.

Often the actress tries to connect the situation to their experience and history so that they can better understand and express the moment for the audience.

Another way of describing this is the WHY behind the request. In his book Start With Why, author Simon Sinek explores how effective leaders start with the why behind their goals. In other words, exploring what they’re trying to achieve. I think effective Product Owners do the same thing, instead of simply making a request for a feature; they first start with the reason behind the request.

Visualization

I’m an avid reader of Science Fiction and Fantasy novels – particular the fantasy genre. One of the things that set great authors apart from good authors is their ability to develop a world that you can visualize. Often they are developing an entire world full of cultures, races, geographies, families, histories, characters, and a dichotomy of good versus evil.

As I read, I can often visualize the world, both the things that the author has established, but also start to add my imagination to the environment and context.

User stories need to invoke the same. They need to encourage the reader or listener to leverage their imagination. To ask questions based on what’s already been shared. Or better yet, to make suggestions about how something might unfold or look to the user.

Whiteboards are particularly useful in this. I love it when during storytelling the team gathers around a whiteboard some various individuals start drawing and visualizing options.

Filling in the Blanks

Often a good story doesn’t simply give you the plot. Instead, the plot unfolds with twists and turns. In fact, in a good whodunit, you rarely know who the villain is until the final pages. You’re left trying to “figure things out” during most of the story.

It’s this mystery or intrigue that often makes the story compelling to the reader (or listener).

I believe one of the reasons that user stories are intended to have holes or are “intentionally vague” is to encourage the listeners to fill in the blanks with their experience and intuition. This is a powerful way to activate the whole team’s creativity.

Excitement

A good story should draw the listener into the moment. It should catch their attention and ultimately, generate some energy and excitement.

And you don’t have to generate that excitement all at once. I think stories are often iterative in nature. You start telling it, and you run out of time. So you let the listener “stew on” or think about the story for a while. Let them start to make it their own story, which is ultimately the goal of the storyteller.

Empathy

I think of empathy as putting yourself “in the shoes” of another. It’s not simply a role-play or a thinking exercise. It’s a deep and committed effort to put on the mindset of your customer.

Often interviewing and observation can help here. I remember when I was at iContact all of us in the engineering team would spend 2-3 hours per month sitting with our customer support staff listening to customer calls. Amongst many benefits, it phenomenally increased our empathy for our customers AND our support staff.

And it improved our product quality too.

Success

One of the cool things about acceptance tests or acceptance criteria is that they help define what done and what success looks like for a user story. That’s a very useful concept.

Often in our storytelling we want to not only share what we want but even more importantly, what we don’t want or need. This clarity of boundaries can help the team stay focused towards a solution and not fall into the trap of gold plating.

Next Steps

Of course each story should result in actions and follow-up. Or I should say that it inspires action. There should be a visceral sense of what to do next and momentum to go out and start implementing it.

In fact, when we deliver the story, we should also include the backstory that we heard that led us to the implementation or solution. And that’s just the closing of one chapter of the story.

Wrapping up

As part of my writing efforts, I often tell or share stories. One critical aspect to it is that they have to be real and relevant.

But I have this feeling that it’s one of the best ways to convey information to my readers – to make my lessons real, and to have it resonate to the readers “real world”.

I’m not saying I’m the best storyteller. I’m certainly not. But the act of storytelling is one of the richest ways to communicate that I’ve found.

I hope I’ve inspired you to look at your user stories in a different way and to increase your attempts to tell your stories.

Stay agile my friends,

Bob.

PS: after I write this, I discovered a brief article by Brian Hoadley on LinkedIn where he explored – Understanding the Importance of Narratives in My Work. While it’s UX-related, I think it nicely compliments this article

Five Really Good Reasons to Map Business Processes

Written by Chelsea Gaillard on September 25, 2015. Posted in Articles. 1 Comment on Five Really Good Reasons to Map Business Processes

Process Mapping is a group activity performed by teams of subject matter experts that gather to draw step-by-step diagrams to document how work is processed (see Figure 1). This invaluable tool is mostly used by consultants and business professionals to capture the current state of business operations in preparation for business improvement initiatives.

However, process mapping can also be very beneficial in helping to increase productivity among staff, implementing or decommissioning systems, streamlining processes, and protecting knowledge capital. Let’s take a look at how process mapping is used in business improvement initiatives as well as how it can be used to help in other areas of a business.

Figure 1 – Cross-functional Process Map Example

1.Launch Business Improvement Initiatives

The strategic plans and goals of a company often drive the need for change. But before making changes it is prudent to establish a baseline from which to make improvements. Taking the time to understand how a process is currently working allows you to:

Leverage best practices from existing processes
Capture lessons learned – learn what not to repeat
Measure the effectiveness of improvements
Ensure that you are fixing not shifting or creating problems
Optimize existing processes rather than creating new processes from scratch

Look at process maps as an investigative tool helping you to understand the root causes of problems. It also supports the transparency needed to learn about how work is completed and encourages team innovation from an “all-in” stakeholder perspective for improving processes. If you take the time to understand what is and what is not working, you will be less likely to repeat mistakes of old.

2.Increase Staff Productivity

Process mapping can help organizations eliminate confusion and chaos among staff helping to increase productivity. A properly trained staff that operates like a well-oiled machine increases the type of productivity that leads to profits. However, in many organizations poor processes and a lack of training and communication leads to chaos that produces poor performance and low employee morale.

Process mapping requires a “parley” of sorts that brings all interested parties to the table to hash out how work is done. At the table stakeholders are identified, roles and responsibilities of each group are clarified, and sequential steps of the process are documented and then ultimately negotiated to optimize work processes.

Process maps can also be used as training aids for employees and easily converted into standard operating procedures that describe step-by-step details on how to perform each task identified.

3.Implement New or Decommission Old Systems

Technology changes as frequently as our need for it. Staying competitive requires that we use the latest technology to maintain a competitive advantage and carry out the strategic goals of the company. This frequent change requires a constant need to assess the systems being used in production and to perform administrative duties. System updates, installations, and the decommissioning of systems can be very costly if impacts to groups and processes are not considered. Implementing a new system without first identifying all user groups and how they use it may fail to meet the needs of the business. Decommissioning systems prematurely can leave user groups without a way to process or produce data that could cause operations to come to a grinding halt.

Detailed process maps can provide a deep and wide understanding of how businesses us their systems. As processes are described, and systems identified you are inadvertently collecting an inventory of all systems used, as well as learning about who uses them and how they are used. This information provides IT with the pertinent information necessary to meet the technology needs of a business.

4.Quickly Streamline Business Processes

You can also use process mapping to identify “pain points” experienced throughout a business process. Tagging steps in a process about the problems that occur can help you focus on specific areas for improvement.

“Lean” tools can be applied when analyzing maps to seek ways to streamline the process. Lean is a business methodology that involves using a set of tools that assists in the identification and steady elimination of waste in processes. Manual processes, redundant work, bottlenecks, and rework are just a few activities that can be classified as waste. Process maps make it easy to identify these activities because each step in the process is documented clearly with notes and symbols of how the process is being performed. Consideration for elimination should be given to steps that are considered waste and do not add value to the development or production of the end product

5.Protect Knowledge Capital

Knowledge capital is an intangible asset but is just as valuable as the physical assets of a company. The definition of knowledge capital is the skill set shared by employees on how to perform tasks or steps necessary for the support of production. Often the details of how tasks are performed between and within groups are not documented. Losing this vital information due to turnover or other absences could lead to work stoppages, slow production, or lead to chaos damaging the effectiveness of operations.

Process maps capture all the vital information necessary to keep operations functional. Functional areas, roles, responsibilities, systems and inputs and outputs of a process are documented providing clarity on how the critical processes to the operations of a business occur. The process maps also serve as a communication tool educating staff from a 360-degree view of how things work increasing the value of the knowledge capital thus providing a competitive advantage. In the absence of critical staff, these process maps are available to backup staff to keep operations running smoothly.

Process mapping has many effective uses, but they are most effective when used as living documents that can be reviewed and updated regularly to monitor and improve business operations. Best practice is to learn the universal standards on how to develop process maps, document critical core and supportive processes that keep the business operational, and establish a “continuous improvement” team that can meet quarterly to continually improve processes. This will ensure that your business is optimized at every possible level. Happy mapping!

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