Author: Angela Wick

Empathy At Work: The Secret of Business Analysis Success

Written by Angela Wick on January 14, 2014. Posted in Articles. 1 Comment on Empathy At Work: The Secret of Business Analysis Success

For many people, empathy is a tool for personal or spiritual relationships. We save our empathy skills for people who are struggling with poverty, illness or grief. We don’t apply empathy to those who are happy or content and when it comes to our professional lives, most feelings, including empathy, remain tightly bundled under our business casual façade.

In some professions, like nursing or social work, empathy is an obvious asset. Marketing and advertising professionals rely on empathy as well. But what about project management, business analysis and software development? How can we apply empathy to our professional lives? How can empathy help us bring value to our stakeholders?

Empathy and Business Analysis

Your mother used to say something about walking a mile in other people’s shoes, seeing through someone else’s eyes, put yourself in their position… When it comes to our professional life, applying empathy mantras to our stakeholders can lead to amazing discoveries about our projects.

Take a look at this drawing. It’s a simple representation of an empathy map.

If you understand what your stakeholders are thinking, seeing, saying, hearing and feeling you can:

Proactively and effectively manage issues and risks
Evaluate politics, priorities and motivations
Uncover hidden requirements and bridge requirement gaps
Locate constraints and dependencies

Implementing Empathy

Gathering information for the empathy map can be a bit tricky. We can’t just schedule an “Empathy Map Meeting” and ask everyone what they are thinking and feeling, right?

No! Please don’t schedule an empathy map meeting. Tone and timing are very important. Here are few ideas:

Gather insight before meetings. You can meet with key stakeholders one-on-one before important meetings. You can prep them for the meeting and ask a few questions that would offer insight into their thoughts and feelings.
During a series of meetings, ask the empathy map questions in different ways to gather current versus future state. What are you hearing? What do you need to hear? What are you seeing? What do you need to see?
Watch body language during meetings. What is your project sponsor feeling when she rolls her eyes every time the SME speaks? What is your tech lead thinking if he is shaking his head during an issue resolution meeting?
Don’t be the scribe during meetings. You need to be able to observe and listen to the interactions between stakeholders. You won’t see the eye rolls, frowns, smiles and head nods if you are too busy taking notes.
Follow up after meetings. Take time to personally reflect on stakeholder interactions during meetings and if necessary follow up with stakeholders one-on-one or in small groups.
“What’s in it for me?” aka WIIFM is a question you should ask yourself on behalf of every stakeholder at the beginning of each project, before each meeting and as you design each deliverable. Your communication will be more efficient and you will get faster buy-in and better engagement from your stakeholders.
Write it down. Create a spreadsheet with each stakeholder and empathy map sections. Add to it regularly as your project moves forward. You may never show your empathy map to others, but it will be a great reference tool. When you encounter issues throughout the lifecycle, your empathy map will offer great insight to help your project stay on track.

Empathy and Innovation

Applying empathy to a project will help BAs successfully navigate their basic tasks, but can BAs inspire innovation with their empathetic approach?

Definitely! Empathy and innovation are related:

Approaching all requirements and project tasks with empathy will yield meaningful collaboration. BAs will know the right questions to ask to engage stakeholders and draw out key information. Meaningful collaboration yields innovation.
Innovation often relies on finding connections between two seemingly unrelated ideas or processes. BAs who understand the empathy map for each stakeholder see connections that others don’t. Maybe two stakeholders from different organizations are hearing the same complaints from their team. The BA might be able to bring the stakeholders together to help each other solve the problem.
Innovation requires the full participation of all stakeholders. If an empathetic BA knows that a SME has a great idea, but probably won’t share it because he feels intimidated by the project sponsor, the BA can facilitate a process that draws the ideas out anonymously.

Do you use empathy as a technique? If not, give it a try. Share your experience in the comments below.

Don’t forget to leave your comments below.

Peace at Last: Agile and Waterfall Find Common Ground in Techniques

Written by Angela Wick on December 3, 2013. Posted in Articles.

As the battle between waterfall and agile rages on, organizations continue modify their approach to software development. Very few move directly to a pure agile approach. Instead, they pilot agile processes, create project selection criteria for agile projects, they shorten release times, minimize project documentation, and many are creating hybrid approaches blending both Waterfall and Agile.

As software development methods evolve, the BA role and their requirement processes come into question. Organizations begin to ask, “How do BAs fit in?”

Some have BAs do the documentation and for Agile projects what gets documented is anything from photos of sticky note user stories, to formalized user stories with acceptance criteria, to the same requirements documentation as in waterfall but done at the end vs. beginning of the implementation.

Where I see the common thread in the BA role is in usage of key techniques needed to understand the business need and maximize the value the solution brings. Regardless of the methodology, roles, and deliverables, the goal of every project is to deliver value to the stakeholders and organization.

In order to deliver value, project teams need a shared understanding of context, processes, needs, wants, priorities, etc. The elicitation and analysis techniques used to build this shared understanding are the common ground between approaches like Waterfall and Agile.

We can share!

BAs can use agile techniques in non-Agile environments.
Agile teams can benefit from traditional BA techniques.

Here are a few examples….

Process Modeling

This may be a traditional technique, but process modeling can provide huge benefits to agile teams. A visual process model offers shared context across an organization and/or system that creates meaningful dialogue.

Process models help agile and non-agile teams understand:

the process being executed
the perspective of the user or the system
workflow sequence and timing
how users or systems collaborate
dependencies

Process models in an agile environment might look different—they might remain high-level and avoid detailed sub-flows. They might reflect only future state. They might focus on user perspective rather than system perspective. However, even a few high-level flows would help agile team members understand the big picture, which can sometimes get lost in short sprints and daily code releases.

Business Rules Analysis

Critical to any business process being implemented, agile teams need to define business rules just as much as non-agile teams.

The timing and depth of the analysis might be different across methodologies. Waterfall project teams might analyze business rules on the front end of the process, resulting in a large, project-wide business rules document.

Agile teams might consider business rules at the beginning of each sprint or face-to-face, with the process owner as they are coding. Agile teams need to have a plan for addressing business rules that cross sprints or a dependent on code that will be developed in other iterations. Many teams use User Stories and Acceptance Criteria where many of the business rules are documented as part of the Acceptance Criteria to the User Story.

User Stories and Acceptance Criteria

These techniques may be coined as “agile” today, but are great techniques for any type of project.

In an agile project, these techniques inspire a high level of collaboration and just-in-time requirements. They integrate requirements, use cases and test criteria in one simple template. The user stories and acceptance criteria templates are generated with an assumption that details will be gathered through direct, usually face-to-face, collaboration at the time of coding.

In traditional requirement processes, user stories and acceptance criteria might be adopted to shorten the requirement gathering process. In traditional projects, it’s often difficult to determine when requirements are “complete.” Using user stories and acceptance criteria in combination with collaboration at the time of coding, might take the pressure off BAs to nail down every detail before a project moves to development.

Collaboration Games

Collaboration games are often associated with agile development. Even the IIBA currently features collaboration games in the Agile Extension of the BABOK.

However, these techniques can and should be used for any project, regardless of methodology.

Traditional BAs can use collaboration games for requirement workshops, issue resolution, identifying needs and features, prioritization, etc. The games inspire creativity and innovation and help engage stakeholders.

Feature Prioritization

A key input to agile development is a prioritized feature list. In many cases, the feature list is fluid and changes as agile teams work through iterations.

Traditional BAs could share a variety of prioritization techniques with agile teams. BAs know how to gather input from multiple sources and make sure that ALL stakeholder opinions are included and aligned.

Agile teams might rely on a narrow group of stakeholders and might not see connections between organizations that would create dependencies between features.

Functional Decomposition

Traditional BAs use functional decomposition to break complex processes and functions into small, manageable pieces for the purpose of analysis. In most traditional environments, each area would be analyzed and all requirements would be grouped together in one project.

Agile methodology relies on breaking complex processes into small, manageable chunks of work. In this case, the functional decomposition would be the skill needed to identify the sequence and contents of each iteration and may be used to break down user stories. Functional Decomposition helps agile teams see where stories fit into a larger process architecture.

Peace at last…

So, now you see—waterfall and agile can live in peace. They can share techniques.

To deliver value to stakeholders, all teams need people with skills to create meaningful dialog, gather accurate information, inspire meaningful collaboration and align stakeholders.

How do you use your BA skills to add value to an agile team? Share your story below.

Don’t forget to leave your comments below.

Get Support from the Grumpy Old Man

Written by Angela Wick on November 12, 2013. Posted in Articles. 1 Comment on Get Support from the Grumpy Old Man

How would you “caricaturize” your organization?

We’ve all been to a fair or festival and watched caricature artists draw distorted people with giant cartoon-like heads and exaggerated features.
If you made a caricature of your organization, what would it look like?

Here are two extreme organizational caricatures:

Grumpy Old Man

Picture Andy Rooney’s bushy eyebrows, a cigar, a scowl and an iron fist.
This organization is set in its ways, not open to change, fixed in routine, dictatorial, risk averse, backward-thinking—what worked in the past will continue to work.
BAs in this environment might have strict procedures, many required templates, limited flexibility and a clearly-defined hierarchy.

Fearless Toddler

Picture a wide-eyed, smiling and wobbly 12-month old, touching and tasting everything without concern for consequences. Each day is a series of experiments with repeating cycles of attempts, failures, learning and trying again.
This organization values experimentation, rewards risk, and is forward-thinking—what’s next and what’s new.
BAs in this environment might be required to define their own roles and procedures, with few internal rules and minimal structure. Priorities might change frequently.

Which caricature describes your organization?

How does that impact your ability to get the support you need to try new tools and techniques?

The Fearless Toddler would welcome your experimentation, but how do you get support from the Grumpy Old Man?

Here are a few ways to help your Grumpy Old Man open up to new ideas:

Cross-Team Training
In many organizations, stakeholders don’t really understand the BA role. The right team workshop can help everyone appreciate possibilities and benefits of effective elicitation, analysis, issue resolution and prioritization processes

This strategy exponentially increases the value of training because resistance is minimized and BAs have the support they need to help their organization move forward.

Something magical happens when BAs, PMs, QAs and SMEs learn new skills together. At one of my client sites, BAs were happily overwhelmed when their business managers pushed them to try four new techniques just days after they all took BA training together.
Take Baby Steps
Start small. Figure out a way to apply new ideas in phases. Find a way to fit new techniques into current procedures. Start with techniques that are a simple expansion of current practices.

If you have a new facilitation technique you want to try, practice it in a low risk meeting with a small group of friendly stakeholders. Ask for honest feedback.
Ask permission
Many people will tell you “it’s better to ask forgiveness later than ask permission now.” However, in some organizations it is not appropriate to try new techniques and tools without approval from a leadership team. In this case, you may need to follow a formal process to introduce new ideas.

Even in less-structured organizations, a simple request process might maximize cooperation:
1. Choose a new tool or technique.
2. Submit a brief proposal to key members of your organization.
3. Describe the benefits of the technique, your implementation plan and how you will report the results.
4. Make sure you include any benefits that save time, reduce cost or minimize risk.
Just do it! Take the risk and try something new.
1. Prepare well, be confident and be willing to fail.
2. Set expectations. Let people know that you plan to try something new.
3. Use time wisely and give stakeholders a way to provide feedback.
Whether you succeed or fail, you’ll learn something valuable about yourself and about your organization. Maybe you’ll learn that your organization is not as grumpy and old as you thought or you’ll learn the old process worked better. You might find support and flexibility or you might find a brick wall. Use your findings to inform future choices and experiments.
Share expert opinions

Sometimes you need a third party to help you advocate for change. You could hire a team of consultants. But if your budget is limited, find expert resources online. Find articles, videos, and other resources.
Build your base

Float new ideas, one person at a time, during lunch, after meetings, at happy hour, in the elevator and by the coffee pot. You will find support.

How do you get your stakeholders wide-eyed and smiling? How do you build support for new tools and techniques in your organization? Please leave your comments below.

Don’t forget to leave your comments below.

Rework is Good!

Written by Angela Wick on October 8, 2013. Posted in Articles. 2 Comments on Rework is Good!

“Rework is good!”

What?

“But I don’t like mistakes. I take pride in the accuracy and completeness of my requirements.”

“Zero defects, that’s my goal for every product launch.”

“Why would I want rework? As soon as my project goes live, I’m done. I get to focus on a new project. I can’t/don’t want to keep going back to old projects to do rework.”

For most BAs, rework conjures negative thoughts:

Requirements Defects = Rework
A low number of defects means we are good at our job and a high number of defects means we aren’t.
High defects can cause the project to fail, ruin our credibility with stakeholders, and damage our organization’s reputation.

Our attitude about rework was shaped by our professional upbringing. We are part of the zero defect, Six Sigma, Total Quality Management (TQM), Capability Maturity Model (CMM), ISO, IEEE generation. Quality control has been, and continues to be, a priority in most organizations.

Does this emphasis on quality and standards limit an organization’s ability to compete and innovate?

Quality vs. Innovation Paradox

I came across an interesting PhD dissertation from 2008 by a guy named Prem G. Raganath. He wrote: “The challenge of achieving an acceptable balance between the freedom to pursue creative work through experimentation and yet deliver a defect-free product is a growing paradox. The fear of failure slows the process of innovation and sends an indirect message to teams that “status quo” is the assured path to growth and success in the organization.”

So, back to rework. If rework is unacceptable in your environment:

Rework and defects = failure
You are afraid to fail
You don’t take risks
Your company stagnates or dies.

Intelligent Fast Failure

Have you read “Innovate or Die: A personal Perspective on the Art of Innovation” by Dr. Jack V. Matson? In the book, Matson discusses a concept he calls Intelligent Fast Failure. He suggests that failure is required for innovation. Organizations need to quickly apply the knowledge gained from the failure to generate new ideas. He wrote, “Each failure is a knowledge building block in fully understanding how to become successful.”

Obviously, BAs prevent rework if possible, but in some environments, rework is unavoidable and maybe the only way to get feedback about products and services.

What if your product or service is so bleeding-edge that:

Your users don’t even know what they want or need
There are no SMEs
The consumers are your SMEs, and you are creating a new concept product
You don’t know who your customer will be
Your customers invent new uses for your products or services
Prototypes go directly to the marketplace?

In these cases, rework and defects provide meaningful feedback towards the evolution of the solution or product. Rework is a good thing!
So, do we call it a defect if it is a learning? A learning of what the market truly desires, would that be a new requirement vs. a defect?

In an innovative environment, rework will be the norm, not the exception:

You can’t do a complete market analysis when you are designing products consumers don’t even know they need, meaningful feedback and rework is necessary.
You can’t create a clear business case when you are operating on the hunches and assumptions of invention.
Gaps in requirements will be commonplace when your SMEs are your consumers and you are learning in a complex world together
Prototypes go directly to the marketplace for user testing and must get meaningful feedback. Without meaningful feedback the prototype has failed.

Innovative vs. Traditional Environment

Here are a few characteristics of innovative vs. traditional environments. Which description best matches your current workplace?

Innovative environment:

Constant pressure to launch new products, new features or new services
Time to market is critical for competitive advantage
Products or services are experimental, new inventions, new to the market place
The consumers may not know they need your product or service
Examples: app design and development, smart phones (both hardware and software), pharmaceuticals, cloud computing, robotics, 3D Printing

Traditional environment:

You are developing or enhancing internal systems or products.
Time to market is dependent on various factors
Standard product/software processes are well-established and routinely followed.
Products or systems are fairly stable, primary functions rarely change.
Examples: Finance, Insurance, Telecom (land lines, long distance, DSL), Retail, Manufacturing, Education, Transportation

Of course these distinctions are not always clear cut. Most industries and organizations have pockets of both traditional and innovative environments.

Many big, traditional companies create innovation centers that use practices like design-thinking or painstorming (evaluate known customer pain points and attempt creative, experimental solutions).

For example, Proctor and Gamble’s Clay Street project (www.theclaystreetproject.com), pulls a diverse group of team members out of their day-to-day work for three months to solve problems, create new products and inspire culture change.

Obviously, some environments are innovative but defects are unacceptable—think medical devices. Defects that lead to human death are definitely NOT a good thing.

Do you work in an innovative environment? Here are a few questions to ponder:

What is your definition of success as a BA?
What’s your organization’s definition of success?
Does your organization expect perfection?
Do you openly discuss failure, rework, defects?
Do you systematically apply lessons learned to next steps?
Can an organization promote quality and innovation at the same time?
Would a more traditional environment build your confidence or stifle your creativity?

Do you work in a traditional environment? Here are a few questions to ponder:

What is your definition of success as a BA?
What’s your organization’s definition of success?
Does your company measure and reward quality/perfection?
Is failure covered up or penalized?
How would experimentation impact your organization? Any upside?
Would a more innovative environment set you free or make you feel like you are failing?

As BAs, we are here to add value to the business. Sometimes that means precision and perfection; sometimes that means rework and failure. For those of us trained in traditional environments, can we accept, learn from and even welcome failure? Are we ready to take risks and embrace a culture of innovation?

Please share your thoughts. Don’t forget to leave your comments below.

Filling your Toolbox: Factors that Influence BA Skill Development

Written by Angela Wick on September 17, 2013. Posted in Articles.

Everyone has a career toolbox—a collection of tips, tricks, skills and techniques. The tools accumulate over time:

Some tools come with the toolbox: innate gifts, talents.
We purchase tools: training, degrees, memberships in professional organizations.
Other people buy or donate tools: employers offer training, mentors, experience.
If we are inventive, we build our own tools.

Most BAs have a few standard tools they use frequently, but many of the tools just lay in the toolbox, unused. We don’t schedule time to check inventory, get rid of old tools, determine what is missing or anticipate future needs. We don’t fill our toolboxes efficiently or effectively.

BAs need to fill their tool boxes, but they shouldn’t fill them passively—just accepting the opportunities presented. Instead, BAs should choose, with intention, which skills they add.

Three factors influence this purpose-driven approach to BA skill development:

Awareness
Desire
Support

If individuals and organizations cultivate these attributes, BA skill development efforts will be effective, efficient and will provide lasting value.

Awareness

BAs can’t develop skills effectively unless they understand the strength and value of their current capabilities.

So, what’s the current state of your BA toolbox?

Do you know your strengths and weaknesses?
Which competencies have you mastered?
Which competencies are missing?
Which skills will future projects require?
Which skills will be required for career advancement?
Which skills are valued by your organization?
What business/technology/cultural trends will influence the value of certain skills?

Essentially, you need to be aware of your own capabilities, but also understand how external entities value your skills.

Here are a few ways to cultivate awareness:

Complete a BA skill assessment. You can do this informally by creating a comprehensive list of BA skills from sources like the BABOK and then rating your mastery of each skill on a scale of 1-5 or you can use the IIBA’s competency assessment tool.
Track stakeholder feedback. Make note of verbal and non-verbal feedback you receive from stakeholders. Find patterns and trends that indicate your strengths and weaknesses.
Maximize your annual evaluation process. For those lucky enough to receive meaningful performance reviews—take advantage of the opportunity—get honest feedback from your manager.
- Ask about your reputation.
- Define skill-related goals.
- Suggest new skills that would benefit the organization.
Evaluate training provided by your organization.
- Why is the training being offered?
- How can you apply the skills in your current environment?
- What are the expectations upon completing training?
Compare yourself to others. Choose a few BAs you admire or consider successful. Identify their strengths. Determine if developing similar skills would help you achieve your goals.
Review industry job descriptions:
- Which skills appeal to you?
- Which skills seem to be in highest demand?
- Do you have all of the skills required for your dream position?

Desire

Since the BA role centers on facilitating change in an organization, BAs need to be willing to change themselves too. BAs can’t develop skills effectively without the desire to learn, grow, experiment or improve. Without desire, BA skills get old and begin to lose value.

A BA with desire:

Advocates for training, mentoring or experiences that will bring value to the BA role and the organization.
Takes risks by experimenting with new skills and techniques.
Practices new skills until they see results—do not just try skills once with ho-hum results and not try again.

An organization wishing to cultivate desire:

Establishes a vision for the BA team.
Identifies and communicates the skill set needed to achieve the vision.
Communicates expected results.
Provides answers to: “How will new skills address my pain and challenges in my job?”

Support

Some BAs have awareness and desire, but find skill development limited by the leaders in their organizations.

Many BAs report to technical or business managers that do not have a clear understanding of the BA role. BAs in this position often struggle to obtain meaningful skill development opportunities.

In organizations where skill development is a priority, this is what you might experience:

Leaders encouraging the use of new tools and techniques.
Leaders modeling desired behavior by experimenting with new skills.
Stakeholders, team members, and peers accepting change and encouraging experimentation.
Skill development plans with flexibility to accommodate learning styles.
A strong team atmosphere.
A healthy respect for the lessons-learned from failure.

Can you think of other factors influence BA skill development? Please leave your comments below.

Don’t forget to leave your comments below.