Visual Modeling: A Critical Skill for Business Analysts is a post from: Practical Analyst

Take “me” as, of course, a hypothetical example.

I think I’m a pretty decent business analyst. I have a bit of experience. I have a pretty good grasp of the fundamentals. I have a pretty good understanding of my business and industry. I’m pretty good with people and technology. I enjoy what I do. The problem is, I want to be a great business analyst.

What does it take to get to that “next level”?

Ok, as business analysts, some of you are going to respond with something like, “first of all, you have to stop using ambiguous terms like ‘great’ to describe your objective.” Well, I’m purposely vague in this case because I’d also like to know, from a group of peers (that’s you), what makes a great business analyst as well as what it takes to get there.

What are the distinguishing factors, in your opinion, between a serviceable to good BA, and a great one?

What are some common characteristics of the best business analysts you’ve ever worked with? What set them apart from the others?

I, of course, have some ideas of my own, but I’d really be interested in seeing some of your thoughts. If you’re a BA, or if you manage or work with BA’s, please take a minute to add a comment or two on what you think makes a great business analyst.

Not only will “I” benefit from your insight, but I know from my interactions with readers of this site that there are many out there who will benefit from your knowledge!

Thanks!

I want to be a great business analyst. Help! is a post from: Practical Analyst

I plan, one day – some day – to become CBAP certified. I occasionally attend and enjoy the free webinars that IIBA provides for its members.

None of those items – useful and beneficial as they may be – is my favorite “perk” of IIBA membership, though.

In my opinion, the best kept “secret” member benefit is access to the on line library of business analysis-related publications. Of course it’s not intended to be a secret at all, but for its value, I just don’t think it gets as much pub in BA circles as I would expect. I aim to change that just a little with this post. You see, to me the library is gold. If you took away all the other benefits, access to the library alone would make the fee for IIBA membership a great bargain.

Here are some of the facts regarding the online library from the IIBA website:

[I]f you tried to purchase these works individually, it would cost you around $15,000 US. A subscription to services that provide you access to all of these works online would cost you around $700 annually. As an IIBA member, you have access to this wide selection of books for FREE! Membership in IIBA is now more valuable than ever.

The online library includes works on a large number of different topics including:

• Agile methodologies and techniques
• Business process modeling and management
• Business rules
• Data modeling
• Enterprise analysis
• Elicitation techniques
• Structured analysis methods
• UML
• Underlying competencies (coaching, facilitation, decision analysis)

There are also books to support chapters and volunteers such as strategic planning for non-profits, basic financial management, event planning, running board meetings, virtual teams, and product management.

As a confessed business analysis junkie, I love to absorb all the information I can through social networking and blogs, but for concentration and development of detail on a topic, I love being able to delve into a good book.

My typical usage of the library is to scan multiple books by respected authors or on topics of particular interest to me. Of those I scan, I’ll pick a few that I think will be really interesting and delve into them in detail, taking notes and then applying and sharing key points of what I learn. The other “read later” books I am able to add to topical lists so I can refer to them at need, or when I have a few minutes to spare.

Anyway, I like to pass on great values to my fellow business analysts, and if you weren’t aware of this one already, I definitely wanted to remedy that.

If you’re already an IIBA member, but just haven’t checked out the library, here’s how navigate to it on the IIBA site: Click on “Professional Development”, then select “Online Library” from the dropdown (have a look at the picture below). That will take you to the page from which you can access the library. If you want to take a little shortcut,   you can just click here!

Over the past year or so, I’ve referred to numerous books in the IIBA online library to assist with training my team members on the fundamentals, learning and improving my BA techniques, identifying potential tweaks and improvements to our team’s business analysis approach, and most recently I’ve been doing some research on establishing a community of practice and  found an excellent book on that very topic in the online library.

Feel free to let me know if you have questions about the library, or about my perception of IIBA membership benefits. Also, I’d be interested in hearing your experiences and thoughts regarding the IIBA online library. Were you previously unaware of the library? Any of you others think this is as cool a deal as I do? Please feel welcome to comment below.

The “Best Kept Secret” Benefit of IIBA Membership is a post from: Practical Analyst

I’ve been very fortunate lately to have had my company send me to receive some leadership training. I really appreciate the investment, and have been trying hard to make it worthwhile by studying and finding ways to apply what I’ve learned.

During one of our sessions, one of my favorite references, Peter Senge’s The Fifth Discipline was cited on an occasion or two. Now, I don’t want to get off topic here, but if you’re a business analyst or work with complex systems and problems, the concepts of “shared vision”, “mental modeling” and, of course, “systems thinking” covered in The Fifth Discipline are well worth your time and study.

Getting back to the topic at hand, though… As a result of the training, I picked The Fifth Discipline up again myself and started reviewing some of my highlights. One particular quote really hit home with me in a way that it hadn’t before. It is the following:

“You can get a great deal done from almost any position in an organization if you focus on small wins and you don’t mind others getting the credit.” – Roger Saillant

To me, that quote is gold. It articulates well the feeling I’ve long had about being a business analyst. While we don’t necessarily wield power of position, we are ideally suited to make a difference when we help our businesses make those incremental changes which, over time, add up to significant wins and success in the marketplace. Because we’re not the leaders in title, it is important that we also don’t mind not necessarily getting the credit.

Small Wins, Defined

So, what exactly are small wins, and why do they seem to add up as well as they do? The balance of this post will include citations and snippets from sources I’ve  found valuable while studying the topic on my own. I hope you’ll find them useful, and will frequent the originating sources yourself for more information.

A small win is a concrete, complete, implemented outcome of moderate importance.  By itself, one small win may seem unimportant.  A series of wins at small but significant tasks, however, reveals a pattern that may attract allies, deter opponents, and lower resistance to subsequent proposals.  Small wins are controllable opportunities that produce visible results.

Once a small win has been accomplished, forces are set in motion that favor another small win.  When a solution is put in place, the next solvable problem often becomes more visible.  This occurs because new allies bring new solutions with them and old opponents change their habits.  Additional resources also flow toward winners, which means that slightly larger wins can be attempted. – Karl Weick from “Small Wins: Redefining the Scale of Social Problems,” American Psychologist, January 1984.

Why Small Wins Produce Results

What makes small wins effective? Here are a few reasonable ideas:

Small wins produce results because they form the basis for a consistent pattern of winning that attracts people who want to be allied with a successful venture. Small wins build people’s confidence and reinforce their natural desire to feel successful. Because additional resources tend to flow to winners, this means that slightly larger wins can be attempted next. A series of small wins therefore provides a foundation of stable building blocks. Each win preserves gains and makes it harder to return to preexisting conditions; each win also provides information that facilitates learning and adaptation.

Small wins produce results because they actively make people feel like winners and make it easier for others to want to go along with their requests. If people can see that a leader is asking them to do something that they’re quite capable of doing, they feel some assurance that they can be successful at the task. If people aren’t overwhelmed by a task, their energy goes into getting the job done, instead of wondering “how will we ever solve that problem?” They then have heightened interest in continuing with the journey.

Small wins produce results because they build personal and group commitment to a course of action… By working at finding all the little ways that people can succeed at doing things differently, effective leaders make people want to be involved and stay involved because they can see that what they are doing is making a difference. Small victories attract constituents, create momentum, and get people to remain on the path.    - from The Leadership Challenge by James M. Kouzes and Barry Z. Posner

The Psychology of Small Wins

Part of what makes a “small wins” approach the way they can ease tension and build confidence:

Complicated issues also induce frustration, stress, and personal friction. Psychologists have shown that individuals become anxious and tense when they perceive a problem as beyond their capability to solve. People typically evaluate their skills, as well as the capabilities of the groups and organizations in which they work, and they assess whether those capabilities match the demands of a situation. If they perceive a mismatch—namely, that the demands of the situation exceed their skills and competences—they become flustered, worried, and stressed. Those emotions make it difficult to actually solve the problem and make an effective decision. Therefore, the socio-emotional challenge is to keep everyone engaged and committed to a decision process by coping effectively with these intra- and inter-personal tensions. A “small wins” approach proves effective when a problem appears overwhelming to people. As Weick writes, “A small win reduces importance (‘this is no big deal’), reduces demands (‘that’s all that needs to be done’), and raises perceived skill levels (‘I can do at least that’).” – from Why Great Leaders Don’t Take Yes for an Answer: Managing for Conflict and Consensus by Michael A. Roberto

Focusing on Small Wins can help us get “Unstuck” and Build Momentum

Developing a Small-Wins Strategy for Growth from Leading Blog tells us how to break free from the paralysis of fixation errors:

Small-wins focus on the here and now. What can we do now and what can we safely ignore or eliminate. It is an antidote to the fixation error trap. It’s easy to caught up in “everything”—the full impact of what is happening and the habits and perspectives that have become so much of who we are—that we become overwhelmed and unable to act at all. Fixation errors keep us from noticing what is really happening, separating us from reality. Reassess after each win and keep moving to build momentum.

Now, About that Elephant…

How many times have projects failed because we try to do too much all at once, and/or prematurely? We take on that 2 year initiative only to find, six months in, that the business landscape has changed in such a way that the value has decreased, or gone away entirely. So many times I’ve chided my stakeholders, project team members or even myself with the old, humorous question:

Q: How do you eat an elephant?
A: One bite at a time!

Each bite we take of the proverbial elephant represents progress – a small win – toward the larger, more significant goal.

Again, from Developing a Small-Wins Strategy for Growth from Leading Blog provides some context we can appreciate as professionals interested in providing solid business solutions:

Begin by breaking tasks and issues down in to manageable pieces; pieces that you can take responsibility for and act on now. If you are not in a position to implement this strategy on an organizational level, adopt it for your team or even individually. Lead from where you are. It’s contagious.

Dan Erwin in his post Why Small Changes Work, and Big Changes Don’t acknowledges that it really is a mind shift for most of us to exercise the discipline and diligence to go after success in “small chunks”.

Successful changes take place in small chunks.  So you’re after small wins, not big ones.  That’s an important change reality.  You succeed on the multiplier effect of small wins.  You’ll lose if your objective is too large.

I hope you’ll benefit from some of these resources the way I have, and if you have comments or other resources to add to the discussion, I hope you’ll chime in in the comments below.

The Value of Small Wins (or, How to Eat an Elephant) is a post from: Practical Analyst

I’m sharing some teaser quotes that I bookmarked during my read of “The Checklist Manifesto” because I think they are good at conveying some of the underlying principles that solution delivery professionals will find interesting, but mostly because I think they’ll push you toward giving the book a read yourself (click on the image to purchase through Amazon). While the snippets are neat, it’s the compelling, real-life stories in the book that bring those principles to life and make it such a great read.

I’ll also include a few words of my own around why the teaser quotes are relevant to business analysts and project professionals.

The Problem

Know-how and sophistication have increased remarkably across almost all our realms of endeavor, and as a result so has our struggle to deliver on them. You see it in the frequent mistakes authorities make when hurricanes or tornadoes or other disasters hit. You see it in the 36 percent increase between 2004 and 2007 in lawsuits against attorneys for legal mistakes—the most common being simple administrative errors, like missed calendar dates and clerical screw ups, as well as errors in applying the law. You see it in flawed software design, in foreign intelligence failures, in our tottering banks—in fact, in almost any endeavor requiring mastery of complexity and of large amounts of knowledge.

Avoidable failures are common and persistent, not to mention demoralizing and frustrating, across many fields—from medicine to finance, business to government. And the reason is increasingly evident: the volume and complexity of what we know has exceeded our individual ability to deliver its benefits correctly, safely, or reliably. Knowledge has both saved us and burdened us.

Essentially, the old paradigms aren’t working when it comes to addressing the complexity of many of today’s problems. With regard to business solutions, I think we’re seeing this evidenced by our quest for “agility” and in the mind shift away from processes that attempt to handle software and systems solutions as “assembly line”-type activities.

Simple Checklists help eliminate “stupid” mistakes:

Substantial parts of what software designers, financial managers, firefighters, police officers, lawyers, and most certainly clinicians do are now too complex for them to carry out reliably from memory alone.
[Checklists] remind us of the minimum necessary steps and make them explicit. They not only offer the possibility of verification but also instill a kind of discipline of higher performance.

[P]eople can lull themselves into skipping steps even when they remember them. In complex processes, after all, certain steps don’t always matter. Perhaps the elevator controls on airplanes are usually unlocked and a check is pointless most of the time. Perhaps measuring all four vital signs uncovers a worrisome issue in only one out of fifty patients. “This has never been a problem before,” people say. Until one day it is.

I think this is the essence of the book. Basically, checklists aren’t the proverbial “silver bullet”. What they do is free us to focus on the hard, complex issues without worry of overlooking the “stupid” mistakes which can be easily overlooked when we’re trying to keep up with so many variables and dependencies in delivering solutions.

To best address problems and risks associated with complexity:

Decentralized decision making

[U]nder conditions of true complexity—where the knowledge required exceeds that of any individual and unpredictability reigns—efforts to dictate every step from the center will fail. People need room to act and adapt. Yet they cannot succeed as isolated individuals, either—that is anarchy. Instead, they require a seemingly contradictory mix of freedom and expectation—expectation to coordinate, for example, and also to measure progress toward common goals.

The philosophy is that you push the power of decision making out to the periphery and away from the center. You give people the room to adapt, based on their experience and expertise. All you ask is that they talk to one another and take responsibility. That is what works.

Think “empowered teams”. Take away almost all the other “stuff” associated with agile (or any other type of) delivery methodologies, and the essence is this: Get a group of smart, motivated people together, let them agree to whatever conventions they think they need in terms of planning/process/ceremony, and, for the most part, get out of the way and let them deliver, and you have a good chance at success.

Cross-functional collaboration and effective communication

In the face of the unknown—the always nagging uncertainty about whether, under complex circumstances, things will really be okay—the builders trusted in the power of communication. They didn’t believe in the wisdom of the single individual, of even an experienced engineer. They believed in the wisdom of the group, the wisdom of making sure that multiple pairs of eyes were on a problem and then letting the watchers decide what to do.

The examples given in the book were around the lead surgeon and the master builder; individuals who, historically, would almost, if not entirely single-handedly make and execute the key decisions with a largely subordinate cast of supporting characters.

Nowadays, complexity and super-specialization has given us circumstances where one person – even a remarkably gifted and high-performing individual – cannot possibly know enough about everything for the “single superstar” model to be sufficient anymore. That’s why we’re seeing such an emphasis on cross-functional teams of members with (largely) equal voices.

Bottom Line…

[Checklists] supply a set of checks to ensure the stupid but critical stuff is not overlooked, and they supply another set of checks to ensure people talk and coordinate and accept responsibility while nonetheless being left the power to manage the nuances and unpredictabilities the best they know how.

Recap

As I alluded to in some of my comments above, what I found particularly interesting, are the similarities between Gawande’s recommendations around basic checklists and collaboration as a means of addressing problems of scale and complexity and the agile principles that we find becoming more and more popular for addressing the same in software/systems delivery methodology.

If you’re not sure if you want to buy the book yet, have a look at this article which served as the precursor for the book, and provides an amazing example of “checklist” principles at work.

If you’ve read the book, please share your impressions with me below. I’d love to carry on the dialog!

Read “The Checklist Manifesto”! is a post from: Practical Analyst

I can remember at times being frustrated at the lack of involvement in requirements validation on the part of some of my business stakeholders. It bothered me that we were doing this work for them, and they didn’t seem to want to take the time to give us the feedback we needed.

Then it struck me. One of the things I liked least about my job was doing peer reviews on my teammates’ big, thick, documents of declarative requirements. I didn’t like how long it took me to actually read and then piece the information together to the point where 1] I actually had some notion of the “big picture”, and 2] I could actually give meaningful feedback. And I’m a business analyst!

How about a little empathy?

When forced to “eat some of my own dog food”, I realized that the problem is usually not that the stakeholders didn’t want to engage as much as that we were making communication way too hard for them. Think about it – if we’re asking these business stakeholders to take a few hours of their time to digest and try to understand a long, detailed document, then another couple hours to sit in a meeting to talk about it, only to have to repeat the process 2 or 3 times until we’d beaten them into submission and extracted that signature, then they’re not going to be the most willing participants in the process.

In many cases, some of these business stakeholders were involved in more than 1 IT initiative, so multiply that time and effort by 2 and sometimes 3, and now you can understand why we were having such a difficult time getting stakeholders to willfully engage.

I think the golden rule can be effectively applied here. We BA’s would be well served to not to ask our audience to review something that we would dread reviewing ourselves. Perhaps the easiest way to get customers to engage in the requirements process is to make it easy (or easier) for them to do so.

With that in mind, here are a couple pointers that have served me well in preparing deliverables for stakeholder review:

1. Use visual models to facilitate understanding

Visual models minimize prep time required and present the material in a format that is easy for stakeholders to understand. One thing that has worked well with my team is to distill the functional requirements/user stories/whatever into a few slides of visuals with process flows and mock-ups with callouts showing conceptually how the requirements would be met in the system.

This gives the stakeholders a chance to see the requirements in a context they understand without having to go through the jigsaw-like exercise of piecing together a cohesive view of what we’re trying to accomplish from tens or hundreds of hierarchical requirements.

2. Work from the summary, but keep the details handy

Despite the ease of using the visual summary, some stakeholders will want access to the “fine print”. Sometimes questions will arise that aren’t covered in the summary slides. In this case, I would make sure to have the detailed documentation handy for reference and to add depth to the discussion as necessary. If stakeholders want to review the full documentation, I am always glad to provide it.

We’re not trying to hide the details, just trying to ensure that we focus on the most important items instead of getting hung up on the nuances “shall” vs. “must” and other insignificant semantic or technical issues around verbiage and document organization.

Reviews can be a positive experience, and one that stakeholders look forward to participating in. It requires more work on our part, but as facilitators of knowledge transfer, it is incumbent on us as BAs to make it as easy and productive as can be for our stakeholders to engage in the requirements process and provide meaningful feedback.

What are some ways that you or your team have made it easier for your user and business stakeholders to engage in the requirements process?

Business Analysts, Be Kind to your Stakeholders! is a post from: Practical Analyst

If you’ve been following me or this site for long, you know that I love to talk and write about business analysis. I enjoy discussing ways that people, processes and tools can be intelligently applied to solve business problems. With that, it’ll come as no surprise that I really enjoyed spending some time here recently rapping with Yaaqub Mohammed (aka Yamo), host of TheBACoach.com and Business Analyst Podcast.

Yamo and I share an interest in promoting dialog around business analysis and in providing tips, tools and techniques to assist BA’s in their craft. As it turns out, our little chat became the 14th episode of Yamo’s podcast, and I understand many business analysts have already listened in and found some benefit, which pleases both of us.

If you haven’t already, I’d encourage you to go check out his site, listen to our podcast discussion and take in some of the other business analysis resources he has made available.

Of particular interest to me was the free e-book, “The five pillars of a great Business Analyst” that Yamo is providing as a gift to those who sign up for his free newsletter. I’ve read about half of it so far, and think it’s a solid resource for analysts wanting some additional insight on how to be successful.

You’ll want to get caught up listening to his past podcast guests, and be sure not to miss the next few. Ellen Gottesdiener and my old BA-blogging pal Laura Brandenburg are names you may recognize that have been on the ‘cast so far, as have several other analysts; each with valuable insights and interesting stories to share.

Follow @TheBACoach on twitter for lots of other brief tips, discussions, and links to other interesting BA-related content.

If you get a chance listen to the podcast interview, chime in below and let me know what you thought!

Check out “The BA Coach”! is a post from: Practical Analyst

Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do

- Steve Jobs (1955 – 2011)

Stanford Commencement Address, 2005

Also…  Steve Jobs Best Quotes from WSJ

Steve Jobs – Do great work; love what you do is a post from: Practical Analyst

I have a few basic themes  or “words to live by” that shape my everyday walk and talk as a business analyst and a manager of business analysts. I’ve tweaked a few words here and there over the years and will continue to do so, but the underlying concepts have remained fairly consistent.

I’m sharing them here in case there may be others who would benefit from reading them, or may see the value in putting together a similar list for themselves. So, here goes:

1. I will do my best to understand the needs of my customers and communicate them in a way that makes it as easy as possible for:
1. Delivery team members to understand what is required to design, build and test successful solutions.
2. User and business stakeholders to engage in the requirements process so they can understand and provide feedback on what is being planned, designed and built.
2. I will strive reduce confusion and wasted effort resulting from lack of understanding of business processes, rules and data.
3. I will welcome and carefully consider constructive feedback.
4. I will give positive reinforcement liberally and constructive feedback carefully and only with the recipient’s best interests in mind.
5. I will conduct my business with integrity and in a way that clearly demonstrates the value of business analysis and earns the trust and respect of the user community, business stakeholders, and IT counterparts.
6. Each day I will strive to do each of the above better than I did yesterday, and plan to do better yet tomorrow.

What items might you include in your personal objectives, or “code of conduct” as a business analyst?

My Business Analyst Code of Conduct is a post from: Practical Analyst

I was recently looking at some of the new requirements modeling/management tools, and some of the other technologies that seem to be making manipulating technology more and more accessible to the traditional business stakeholder, and I caught my self wondering: How long will the industry support a distinct business analyst role?

New tools are making it easier and easier to capture and communicate ideas. Increasingly, a moderately tech-savvy business stakeholder can reasonably be expected to drag-and-drop his/her way to an initial design given the ease of use of tools currently available. For management of enterprise business rules and intelligence, rules engines and data warehouses with simple syntax and GUI-based tools have put the actual implementation of new application rules and creation of new reports in the hands of the business consumers themselves.

In these cases, no business analyst is required as an intermediary to carry needs to developers for implementation or to serve as the “translator” of business speak to tech speak and vice versa.

It seems we’re becoming less and less dependent upon wordsmiths to convey ideas. In theory, for less “revolutionary” tech projects, a business sponsor could theoretically sit down with a someone who was adept in rapid/rough prototyping and equipped with the right tools and bang out a basic flow, requirements and UI without as much of the preceding planning, analysis and deliberation.

My goal is not to dispute the value of business analysis. As a BA myself, I am absolutely convinced of the value of having a strong business analysis competency in an organization, and I think business analysis will continue to be sought after and rewarded. My question is this: how viable is the distinct “business analyst” role over the long term?

Will we see it absorbed into or combined with other roles (i.e. project management, solutions or information architecture, UI design or into the line of business) as modeling and design tools become more accessible and usable and business stakeholders become increasingly tech savvy? Will the role evolve or dissolve? What skills are going to be valued in the business analyst of 5-10 years from now, and how will they be different from today?

I have some thoughts of my own, but I’m not making any bold predictions at this point. What I’d be really interested in is hearing what other analysts have to say on the matter, so please do comment and share!

What Does the Future Hold for the Business Analyst Role? is a post from: Practical Analyst