Business Analyst Blogs

The Top 10 Business Analysis Skills for 2012

I like to think of the BA role as a broker of information, getting big picture and details from many different people, groups, executives, subject matter experts, vendors, technical resources, etc . . . what the BA does with all this information and how it gets communicated and repurposed for each audience is opportunity for a BA.

Today's trends are pointing towards the following themes for BAs:
- Business Agility
- Innovation
- Engagement of stakeholders to drive agility and innovation

The needed skills to meet these trends in 2012:

1) Conceptual Modeling Skills
Engage your stakeholders with more meaningful dialog! Conceptual Modeling of the business view of the solution has always been a critical tool to help bring business, technology, and delivery groups together in defining solution scope. I have had many BAs tell me that they do this and show me their conceptual models. What I find when reviewing the models is more of a technical architecture or data context diagrams. Technical architecture and data context diagrams have their place, but the critical skill I am seeing as a gap in BA skill sets is the business view (vs. technical view) of the solution scope, this will be critical to engaging stakeholders and setting the stage for innovation

2) Communicating Details and Concepts
Similar to the conceptual modeling skills is communicating various levels of detail appropriate to the audience. This can be especially difficult when you have various stakeholder needs on the team or in the meeting, and many times multiple views is needed to ensure the right message is communicated to all audience needs. Where I see the gap today is details are not organized to be digestible and understandable to many audiences and there may be a lack of conceptual and context to accompany the details. Without the concept and context information, the details - even when well organized - may not be understood or thought of in with the frame of mind that the BA needs from the stakeholders. Rethink requirements packaging, does the same document need to go out to everyone? Or, can each audience be given a guide as to which pages/sections are most pertinent to them? Just a few ideas to help stakeholders consume what is important to them.

3) Curiosity
How curious are you as a BA? This has always been a critical skill for BAs. Ensuring curiosity in finding the root cause of the problem or opportunity, getting the right audience, usage, context, purpose for requirements requires a strong level of curiosity in BA work. Curiosity will go far in 2012 for BAs wanting to build competency and skills in the world of mobile apps, cloud computing, and continuing agile trends. Curiosity will make some of the unknowns of today easier to work within, a curious mindset will take BAs into communicating the unknown and help organizations innovate.

4) Decomposing the Abstract into Details
I have to call this out separately from Conceptual Modeling and Communicating Details and Concepts. The same themes are in play, but yet executed a bit differently and in different scenarios. Decomposing the abstract into details is also referred to as "critical thinking" and sometimes "system thinking"; taking something large, ambiguous, and abstract and breaking into smaller pieces, patterns, and views. It is about helping others see the details and big picture from different perspectives, helping stakeholders with varying points of view and priorities see where their details and others fit into the bigger picture. It will also help BAs better estimate and work with PMs on the status and risk of requirements.

5) Mentoring and Coaching
As the BA role becomes increasingly more valued in organizations, two things will happen: 1) Organizations will need a career path for Sr. BAs, and 2) Organizations will need to develop internal strategies to develop more talent in the BA role and Sr. level skill set. Mentoring and coaching skills are key for Sr. BAs in both of these strategies. Mentoring and coaching done by Sr. BAs will develop leadership competencies in the Sr. BAs while developing BA competencies in new or more inexperienced BAs in the organization. Sr. BAs who have the opportunity to mentor and coach will develop further leadership competencies needed to elevate the competencies of the BA team as a whole.

6) Communicating Risks
Project Managers focus on risks to the project budget, schedule and scope. A BA needs to focus on risks to the business value of the solution and communicating the risk. BAs are in a prime position to see the details and big picture view; this includes seeing the risks to the project, delivering a solution that does not maximize business value. I find that BAs have an intuitive sense of this, but often struggle to communicate the risk in a way that gets leadership attention. In order to get leadership attention to the business value at risk, BAs will need to develop skills in communicating the true business impact of the risk. This means going beyond communicating in terms of the features and functionalities of the process or software, and going beyond that, there is not enough time for requirements to be done right. It means communicating the impact it will have on the business operation or strategy. For example, when the functionality of a point of sale application has a requirements conflict in the process of accepting payment from customers, the focus needs to turn to the impact of the conflict on the customer service representative's ability to serve the customers and the customer experience vs. the technical details at risk of the requirement. In the heat of requirements and design details, we often let the details drive risk discussions and never get to the bottom line impacts that can really propel leaders to make the right decisions.

7) Leveraging the "parking lot"
Are you running your meetings or are meetings and stakeholders running you? Many BAs get into tough situations in requirements meetings and feel that other agendas and personalities are driving their meetings astray. Using a "parking lot" (simple visual list of items that do not fit into the meeting agenda to be followed up on or scheduled into another meeting) to manage and control the meeting agenda, content, level of detail and difficult personalities is a key strategy. Most importantly, make sure that the parking lot is visible to everyone in the meeting. Having the parking lot in your notebook or on your laptop does not show others that you have their ideas and concerns captured to discuss at a later time. Be empowered to take control of your meetings!

8) Change Management
Embracing the BA role as an agent of change will continue to show the value the organization the value the BA role brings to the organization. Projects are about business change; the BA role is about bringing the most value possible in a solution to address the business change. The role of a change agent in the BA is critical to ensuring all impacted parties are ready for the changes needed to accept the solution. Understanding how changes and solutions impact the stakeholders operations, processes, attitudes and behaviors is a key skill in maximizing the success of the new solution and the business value it brings.

9) Asking WHY?
I love the word "Why", but hate to use it. My challenge to readers of this blog is to help one another find ways to ask "Why". Many times using the word "Why" can come across wrong to the other person, it can seem defensive and the other may wonder why (no pun intended) you are asking. Finding different ways to ask "why" can alleviate this dilemma. My favorite ways to ask "Why?": Tell me more about what is behind the need for abc? What does success look like? What would happen if this project does not get implemented? What are yours?

10) Impromptu Whiteboard Drawing
In 2012 when innovation, agility, and engagement are the trends, being able to spontaneously draw will lead to stakeholders to a deeper level of engagement. Getting up to draw shakes up the flow of boring meetings, engages others to focus back in on the discussion, and brings out humor - let humor be a friend. You don't have to be an artist to draw concepts on whiteboards that generate great dialog, discussion, creativity and innovation. It also does not have to be you that does the drawing; ask someone else to draw what they are thinking and your meeting will benefit in many of the same ways. When the drawing yields powerful and meaningful discussion, be sure someone takes a picture with their phone.

No matter that type of BA, no matter what the industry, these skills in 2012 will set your projects up for deeper engagement, innovation and agility.

Don’t forget to leave your comments below

BLOG of a Different Color - Solution Assessment and Validation

Marcos Ferrer

The collectible series ends with this final installment – Solution Assessment and Validation.. Errata pointed out by gentle readers will be reported as found (if found!).

You can get a legend to help read these diagrams by grabbing the first issue of this series (and the rest, if you haven’t already), at http://www.batimes.com/marcos-ferrer/.

Here we go!

Agile Genesis Questions— Why? and What’s the Value?

Robert Galen

Agile_1 Agile_2

An advantage to self-publishing a book is that you can decide when you want to do publish a second edition, not the publisher. I’ve been entertaining the idea of updating my Product Ownership book of late. Mostly because I’ve learned so much since I first published it in 2009. I’ve also changed some of my views since then—so I’ve got quite a bit of ‘content’ floating about my head that is looking for a home.

One of the ideas that I’ve been thinking about a lot lately surrounds the notion of feature value in agile teams. It’s driven by this typical value flow of agile work—

The Product Owner drives the highest priority User Stories (Features)
The team delivers these to the ‘Business’ and gains sign-off that they’ve met their commitment
These features are then pushed to the Customer for use

Agile is terribly wrapped around the axel of value-driving functionality. It is one of the primary responsibilities of the Product Owner, Business Analyst, and Tester (among others) to write stories that connect the described needs to customer value.

The Product Owner is continuously considering the usefulness, the popularity, the compelling-ness of features. They are gathering insights from stakeholders as they craft the definition of each User Story and how it relates to the overall feature they’re defining. One of the reasons for this is simply due-diligence from a business perspective. Another revolves around the base needs of their team.

Your ‘A’ Team

You see, a primary responsibility for the Product Owner in this sense is to treat their teams as a highly-skilled and specialized resource. For example, a high-caliber swat team. You don’t send a swat team out to police burned out traffic signals or guard child crossings. Not that those activities aren’t important, but the world has many who can do those jobs well.

No, your team is a highly trained and highly skilled group. You need to be considerate of their time and energy. You need to give them work that will challenge them, delight them, stretch them, grow them, and encourage them. In a word, you simply can’t waste them on the mundane or more importantly the non-valuable.

So every choice you make in seeding work into their backlog needs to be carefully considered. Many if not all Product Owners, solely consider the business-side when it comes to developing and prioritizing stories and features. But what about their team’s needs? They also need to consider the impact that the features will have on their teams’ morale, trust of you and your skills, and overall understanding of your strategy.

Too Laissez-Faire

I see the definition of Feature Value to be a much richer landscape than simply saying this feature or story is #23 on the Product Backlog hit parade. Trust me, that’s where it belongs…so now go and execute it.

And I see way too many Product Owners not taking a holistic view towards their prioritization and selection of stories. It’s unfortunate really, because adding an appropriate level of nuance is their job.

There are two key areas that I want the Product Owner’s to improve in—

Explaining the WHY behind each and every Feature. Why is it important? To the organization? And their core business strategies? Why is this team being asked to deliver the Feature? Why has this specific set of User Stories behind the Feature been selected as crucial for delivery?

And

How will the Feature success be MEASURED? How will the Product Organization and Product Owner be measured on the Features worth estimation? What are the critical KPI’s for this feature? How was this data derived? Will usage data be collected from the Product to confirm?

Let’s explore each of these in turn…

What about WHY?

So, I think the first question our Product Owners need to start answering is ‘Why’. Why are we picking this feature? Why do we have to implement the described functionality? Why is the customer asking for it—what problem are they trying to solve? Why have you prioritized it this way—over these other five features? Why is it important? Why can’t we “skip it” and work on technical debt—as the application is becoming impossible to support?

And beyond the questions, which are certainly segues into insight, what’s really important here are the answers. Giving the team the ‘Why’ behind your decision-making and trade-offs is crucial to helping build great applications.

The answer to why can be un-compelling and demoralizing, for example, we’re doing this because our Group VP Bob said to do it. Period! Sure, that’s the answer, but it gives no insights that the team can leverage in producing great products or feeling good about said activity.

Or you can give the team competitive landscape insights and insights into your customer needs analysis that have led you to the conclusion that this feature is in the Top 10 of high-impact needs for your customers. And you can communicate this to your team in the context of the customers’ problem—so that they approach the requirement from a solutions design perspective and not simply implementing what you asked for.

A wonderful resource to help inspire you to the importance of Why is Simon Sinek’s TED talk on the subject of ‘Why’. It’s only 18 minutes, so take a peek…

Value Estimated…and…Measured

Beyond why, the second question to be answered relates to value and measuring it. How do we as Product Owners plan on measuring the value of this feature once deployed? What are the critical success factors in customer usage, customer acceptance, and quality levels? Do non-functional requirements come into play—such as performance and security considerations? And if so, how specifically will we measure sufficient support levels both prior to release and then late, in the customers’ hands?

I find that many Product Owners don’t sufficiently define measures for their acceptance criteria. Very typically this will result in ROI, i.e. in raw sales or in usage & adoption metrics. This is particularly easy to do if you’re product is delivered as a SaaS. But it’s possible to do no matter your product delivery mechanism.

Why do it?

First, it indicates how well the team is truly achieving their business value goals. It’s not some sort of guess, but it’s derived from real usage, adoption, and sales data. And the team should pay attention to this when developing (the target) and when delivering (actuals) functionality.

But more importantly, it also is a report card for how well each Product Owner’s decision-making is determining and driving their valuable team towards delivering business value. Just as the team needs to be accountable for their estimates and efforts, each Product Owner should be estimating (placing items on the Backlog) and being critiqued on how well they guessed at ultimate customer value.

Wrapping Up

I apologize for meandering a bit in this post. The critical points relate to Product Owners having two critical responsibilities—explaining the why behind their decisions (their thinking) and measuring the effectiveness (value realized) of their decisions. And then having the responsibility to learn from their measures and decision-making results, reflect on their actual performance and continuously improve.

And by Product Owners, I don’t just mean the PO proper. I also mean the Business Analyst, Tester, virtually anyone who contributes User Stories describing what will be built and how we’ll measure it.

Simply put: Focus on the Why and Measure the Value

Thanks for listening,

Bob.

Don't forget to leave your comments below.

The 21st Century Business Analyst

Kathleen Hass

From Tactical Requirements Manager to Creative Leader of Innovative Change

I think the 21st century will be the century of complexity.

—Stephen W. Hawking

Welcome to the new series of articles on the BA as the 21^st Century Creative Leader. It was a perfect storm. As we entered the second decade of the 21^st century, we found ourselves struggling to adapt. All over the world, people faced environmental and economic turbulence, financial calamity, a stubborn recession that seemed to resist recovery, intractable societal troubles, high unemployment, increased poverty, and uncompromising complexity. The fiercely competitive global business ecosystem was changing so rapidly that we were confronted with complicated situations we had never seen before.

It is no coincidence that the business analysis profession is taking hold to address many of the 21st century business challenges. Business analysis is all about understanding the needs of organizations, helping them remain competitive, identifying creative solutions to complex business problems, bringing about innovation, and constantly adding value for the customer and revenue to the organization. My fear is that the business analyst will remain a tactical, project-focused role for too long, and organizations around the world will not leverage the often underestimated and undervalued creative talent that is bottled up in our business analyst workforce.

Creative Leadership – What’s All the Fuss About?

We know that creative leaders are top performers, but how are they different? It is becoming obvious that we need creative leaders from all levels organizations to capitalize on complexity and use it as a competitive advantage, not just one or two individuals at the top who are leading the way à la Steve Jobs. CEOs of leading companies lament the fact that they do not have the creative leaders that are needed. [i]

Where is the cadre of creative leaders going to come from? Could business analysts become the creative leaders we need to spark innovation? To be sure, they work with teams and individuals at all levels of their organizations. Our 21^st century challenge is this: to arm business analysts with the knowledge, skill, credibility, and confidence needed to awaken creativity throughout their organizations. We can then calm the storm, at least as it affects our businesses, and look ahead to a dramatic increase in the number of innovative changes set in motion through expertly facilitated creative sessions.

Creative Leadership – Is it Embodied in the Business Analyst?

What should business analysts be doing to hone their creative aptitude and to foster imagination and originality in their organizations? Business analysts can participate in the development of creative leaders across their organizations by deepening partnerships with their stakeholders, especially employees and customers. As they focus on relationships, business needs, operational agility—the hallmark of business analysis—BAs can focus on innovation at every turn and instill a universal understanding that everyone is creative. To accept the challenge, business analysts need to learn to be courageous, prepared, and willing to make deep changes to their organizations’ business change model and to their approach to business requirements.

Creative Leadership – It’s a Team Sport

Project leadership is no longer just about the project manager or even just about the project manager and the business analyst. Combining disciplines leads to success, and complex 21^st century projects should be led by a highly seasoned, multitalented team consisting of strategic thinkers and creativity enthusiasts. The complex project leadership team ought to comprise the best resources available, including experienced and creative project managers, business analysts, solution architects and developers, and business visionaries. This leadership team collaboratively makes managerial and technical decisions about how to capitalize on the complexities they face to foster creativity.

Who Will Benefit from Reading This Series?

This series presents a new model for all members of project leadership teams in general, and business analysts specifically, to learn how to capitalize on complexity. We will delve deep into the behaviors of business analysts in their functions as expert facilitators and creative leaders and offer guidance not just on managing complexity, but also on leveraging it as a competitive advantage. In addition to business analysts, this series is an important resource for project, program, and portfolio managers; solution architects; business process owners and managers; functional managers; senior IT technologists, BA consultants and BA Practice leads.