Business Analyst Blog

When I was a young buck I could not beat this one kid on the block in a 100 yard dash.  I was convinced it was my worn out shoes causing me to lose time and time again.  I pleaded and begged my parents to buy me a new pair of sneakers for weeks.  Eventually they gave in.  I got the pair I needed to take down the champ.  As soon as we got home, I ran out into the street and lined up for the big race.  Guess what, I lost. That is when I figured out it was not the shoes.

So how does this relate to business analysis?  Like shoes I now put less emphasis on the title business analyst.  Is someone with the title of business analyst excellent in the tasks and techniques required of business analysis.  Not necessarily.  We should not focus on the title as much as the role.  Every successful project team does not need a business analyst, but they better be doing business analysis.

Agree or disagree?  Have something to add?  Please share.

We, B2T, often get career advice questions coming in to our blog.  They mostly relate specifically on how to enter the BA profession and advance once in it.  I thought you all would be interested in an article I just read, "It Worked For Me: Career Advice from Top CIOs" by Martha Heller on CIO.com. 

CIOs from FedEX, Campbell's Soup and more talk about the best career advice they received.  The theme is about taking risks and stepping outside your comfort zone.  This is great advice whether you want to be a BA, CIO, Musician or circus clown. 

 I'd love to hear your feedback after you read the article.

When I was in South Africa last fall, a systems engineer told me about an organization called INCOSE. I was not familiar with it but he told me that they had many of the same goals as the IIBA so I decided to take a look.

 Some information from their web site (http://www.incose.org/):

The International Council on Systems Engineering (INCOSE) is a not-for-profit membership organization founded to develop and disseminate the interdisciplinary principles and practices that enable the realization of successful systems.

Mission
Advance the state of the art and practice of systems engineering in industry, academia, and government by promoting interdisciplinary, scalable approaches to produce technologically appropriate solutions that meet societal needs.

This organization was founded in 1990 and has over 5000 members worldwide. They have numerous chapters, a body of knowledge and a certification program. I reviewed the body of knowledge (G2SEbok) and it contains many of the same topics as the BABOK.

So the question is "What is the difference between a BA and a Systems Engineer?"

2008 promises to be a great year for business analysis! We have finally hit our stride - lots of people in our companies are beginning to understand what we do and the value that we bring to the organization. The IIBA has certified over 200 CBAPs in it's first year and is working to make the exam more accessible for everyone.

And there are suddenly many training, consulting, and software companies who now actively advertise their business analysis products. They have all recognized what we have known for years - business analysts are smart, focused, creative, and enthusiastic about helping their business run smoother and be more successful. Maybe we should declare 2008 The Year of the BA!!

Over the last few months I have been in more discussions than I can count about the role of the business analyst, project manager vs. business analyst, where the business analyst fits in on an agile team, and which roles are needed to make a successful team.  They have been wonderful passionate conversations.  With each discussion I kept coming back to the same conclusion…it's all about teamwork. 

When I look back at what made some projects challenged and others widely successful it came down to all team members doing what was needed to reach the goal regardless of their role.  I don't know about you, but I never had the luxury of the having the best in class PM, BA, development team, and QA analyst.  Since that was the case my most successful teams would discuss what needed to be done (tasks) to accomplish our goal and who on the team was the best person to complete or assist with that task.  I would say 85-90% of everyone's tasks fell in line with their role.  The other 10-15% was filled with tasks that individuals were more qualified to accomplish.  This 10-15% is what made those teams great.  When team members have the attitude of "what can I do to help the team" you'll have more success.  Chances of failure increase when team members bring an attitude of "that task is not in my job description."

This point was illustrated beautifully by Lee Scott and Dawn Solem of VSP in their presentation Business Analyst & Project Manager - The Strategic Partnership to Project Success at the PW & WCBA conference in Anaheim last month.  Thank you Lee and Dawn.

Defining roles have its place, but to be a successful team you have to figure out how to use everyone's expertise and skills regardless of roles. 

Please add your thoughts and comments!  

I wanted to share a great presentation from the Project World and World Congress for Business Analysts conference in Anaheim this month. Russ Pena from Sun Trust presented their professional development framework. His organization has recognized the importance of the business analyst role and built a career path with 4 capability levels. Each level has a unique title and describes how much supervision would be needed at the level along with the typical type of work done by each BA. The levels are intermediate, advanced, lead and expert. The organization encourages employees to plan for and build their own career goals and gives them direction and support. The BAs are in the IT organization which has recognized the importance of consistency in job roles and expectations.

 It was great to see an organization embracing our profession and investing in our future!

Click here for the presentation: Implementing a Professional Development Framework

I attended the Project Summit/BA World in Boston this week. Once again it was great to be with so many individuals who understand the importance of business analysis work. Most of the same challenges that we have been talking about for a couple of years still plague organizations: lack of understanding of the roles of PM and BA; not enough time allowed for analysis and requirements development; difficulty getting time commitments from business stakeholders; and lack of authority and career growth opportunities for business analysis positions.  Although many people still say “users don’t know what they want,”  more and more people are recognizing that business analysis work is the key to helping users understand what they need and how best to solve their business problems.

I spoke with a few forward thinking managers who see the BA role as one that will improve our organizations significantly. They talked about the role of the business analyst being the person who looks at the project within the context of the big picture. BAs ask the ”why” question before diving into a project and want to make sure that the project result will be in alignment with the organizational goals. This broader perspective is one that PMs sometimes do not have. They are given a project and work to get it done. The BA is the person who raises the red flag when the objectives of the project seem outside of the enterprise objectives or don’t make good business sense. A business analyst who sees the “forest” and the “trees” is a very valuable resource whose expertise and skill set are really coming into the fore front of many organizations.

Even though development tools and techniques have improved drastically I still hear from corporate application users that the systems their IT department built or purchased for them lack usability.  We all know that projects are still failing or challenged based on the triple constraint (Time, Budget, Scope).  I wonder if the addition of a fourth element, usability, would put more numbers in the failed category. Teams often claim all the features were delivered.  True, but if ease of use is missing was the feature really successfully delivered?   

Would Apple profit as much if they did not incorporate usability requirements and testing in their iPod and iPhone product development?  Let me answer that for you. No! Successful companies around the world conduct focus groups and usability testing to help differentiate their products from their competition.   

At our last IIBA meeting in Atlanta, the speaker, Dave Altman, asked how many people work in an environment where there is a usability lab or any usability activities taking place.  1 person out of 40 raised their hands.  These 40 people represented 10-15 large companies in the Atlanta area.  As IT professionals why are we not focusing more on this important step?  In my opinion money and time is wasted if we implement solutions that lack usability even if the triple constraint is met.   

There is a lot of talk lately on why business and IT are disconnected.  Most of the talk is around aligning strategies which I believe is the first step.  Provide usable solutions and you’ll see that gap shrink even more.

As BAs and UX professionals we need to push for more time and money for usability testing.  It is our job to help provide workable solutions to meet the business need.

After recently attending a couple of conferences with business analysts and project managers, I noticed a common theme about the topics presented this year. Many speakers devoted their energies to discussing the importance and complexity of effective project communication. This topic was articulated in a number of presentation topics such as: how to work with virtual teams, how to manage stakeholders, how to elicit business requirements, how the BA and PM can work in harmony, designing a sure-fire stakeholder strategy, how to leverage your emotional intelligence, communicate, communicate, communicate, how to understand stakeholder needs, etc. The topics were each different but had common threads highlighting the need to focus on improving our soft skills to better understand the individuals we work with on our projects. The goal to achieve excellent project results begins when we know how to build good relationships with fellow team members and stakeholders through careful listening skills and attention to diverse personal styles.  I think the topic is popular because so many of us still struggle to handle communication successfully. How you need to communicate changes from project to project whenever you have new stakeholders depending on their attitudes, culture, and preferences.

Business analysts are able to adapt their communication style to their audience to effectively communicate requirements.  It is often said that business analysis is part science and part art. The science focuses on hard skills such as learning different analysis tools and techniques. The other part is the soft skills which include communication, facilitation, conflict management, persuasion and negotiation, leadership, etc. These skills are sometimes thought to be easy to master.  Often overlooked are the clues about stakeholder personal styles and preferences that could help us to develop closer relationships with our project stakeholders. Business analysts who plan for stakeholders’ diverse needs and concerns are likely to communicate more effectively than those who do not.

How difficult are the soft skills for you? Is this an area where you think you need help or do you feel like this is the easiest part of business analysis?

Do you have any tips for successful communication?

For more on this subject please see the bridge – Fall issue 2007

We are seeing a lot of success with agile projects when an experienced BA is on the team. We have completed two iterations of a project internally using an agile approach and our business users are very happy with the results. They are also happy with the fast turnaround time. Agile is really just about scoping a very small set of requirements and quickly producing a software component that answers the need. All of the same analysis skills are required: elicitation, analysis, problem solving, communication, verification, and validation. The work is just done on a smaller piece of functionality and the team is 100% dedicated to the project.

Initially some agile experts downplayed the need for a BA on these projects. They assumed that experienced developers could also do the business analysis work. But as we know, not all developers can or want to do business analysis. With a BA on the team, the developer can do what he or she does best - code.

Share your agile experiences here - good and bad. Let's help each other show that we add significant value to these projects, just like all of the other types of projects we work on!

Coming soon - a B2T White paper: "How does a BA add value in an agile project?"