Business Analyst Blog

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

Traceability is a necessary component for complete and accurate requirements. Traceability is used in many aspects of requirements development and management. A simple definition is that "tracing requirements" means that we show relationships or links between different requirements components. Examples include:

Which data requirements are used in each process?

Which business objectives are supported by each business rule?

Which technical requirements are derived from each business requirement?

This is one area where a requirements development or management tool can be very useful. But even with a tool, tracing requirements can be complex and time consuming. An effective BA plans for the types of relationships that are going to be documented and maintained before getting started with requirements elicitation. It is easiest to "trace as you go" and the only way to accomplish this is to know ahead of time what type of tracing you are planning to perform and maintain.

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?"

As Business Analysts we rarely have formal authority over anyone we work with on our projects.  To give our teams the best chance for success we have to work collaboratively with all of our stakeholders.

I just read an article on CIO.com that I think you will enjoy.  In their article, "How Good Are You At Collaboration and Influence?," Reynold Lewke and Steve Kelner, discuss why collaboration and influence are key competencies for successful CIOs.  The concepts covered apply directly to BAs as well. At the end of the article they ask questions that will help you assess your companies and your own readiness for collaboration.

Are you ready?!

I attended a Certified ScrumMaster training class this year delivered by Lithespeed.  The class was very valuable, and I want to share a tool, trade-off matrix, to help set customer and team expectations.  In my opinion this is a tool that should be used on all projects early in the planning stage.  Here is an example of a trade-off matrix.

By documenting this at the beginning of a project, the project sponsor and all project stakeholders (including project team members) have a clear view of what project success looks like.  In the example above success is implementing all features, within a budget close to $500k and somewhere within 3-6 months.  In addition the sponsor is OK with 2 large bugs a month. 

You may find that a project sponsor wants everything “Fixed.” By using this matrix to illustrate the triple constraint it helps drives your discussion explaining why there needs to be a trade-off. 

I plan on using this to help define success.  Please share any tools you use.

Some people cannot understand why data requirements are important. There are a lot of Business Analysts who say they have never collected data requirements and do not understand why they should.  Here is one small example from my experience. I was doing some business analysis consulting at a state agency that was just beginning to use the RUP methodology and the Business Analysts were busy using use cases to document most of their requirements.

One story I heard when I first arrived on my assignment was that they had written all their uses cases in great detail and had an approved prototype. The developers had done their testing, and they were really trying to rush to get everything ready to go to production when someone discovered a big problem that delayed the project for several months. During User Acceptance Testing, it was discovered that new data was now being collected from the users of this application but this new information had no where to go. The database did not know about the new data requirements. No one had collected the data requirements for the application - only the use cases. The data could not be stored. No one had modeled anything for the DBA.

To keep the project from being delayed, the IT group suggested that the business keep track of the data manually. Another option they suggested was that they could just create notes in the application with the new information until such time that the data requirements could be collected and the data models designed. The business folks were livid that such a silly mistake could be made. The project was delayed and no one was satisfied. Do you have any stories about why capturing and modeling data requirements is important for requirements elicitation?

A BA's understanding of how business stakeholders do their work is very critical to gathering the right requirements to meet their business goals. A BA, like a detective, investigates until he or she has uncovered the details about how the business operates: the good, the bad and the ugly. It's true we need to understand the business vision and high-level business goals but the BA also needs to elicit a detailed understanding of the business processes. If not, this leads to missed requirements, rework, increased costs, and unsatisfied stakeholders. Some BAs may have experience in the business area under analysis while others do not. Whether you start with lots of insights or are completely new to the industry, there are a variety of ways to gain this understanding. Depending on the situation some apply better than others:

• Existing documentation (document analysis)  
• Job shadowing/observation
• Facilitated requirements work sessions
• Interviews
• User task analysis or process walkthroughs
• Surveys
• Conference calls using collaboration tools
• Prototypes
• Focus groups

These along with some others are mentioned in the IIBA BABOK^TM. The better understanding a BA has about the essential business operations, the more effective he/she can be in assisting the business to create more cost-effective, time-saving, and powerful solutions.  Write and tell us about which techniques work best for you and why.

I read a very good article by Alistair Cockburn (no online link…sorry…dead tree magazine, by subscription only) that discusses the likelihood that many stakeholders use "game boards" to direct their activities during requirements elicitation. Quoting (with proper attribution!):

"[W]e really can't understand what is happening on the project without taking into account the side games that people are playing at the same time."
^{Better Software Magazine, August 2007, pg. 33}

The concept here is that everybody, including and especially stakeholders, use "game boards" that can be predicted using activity theory. As an example, a project sponsor may be (quoting again) "…playing on game boards centered around career growth, relationships with peers, and relationships with other communities (user communities, business partners, etc.). The outcome of the game called build system X is evaluated by the sponsor with respect to how his position changes on all those other game boards."

My question for y'all is, "How often do we move beyond the things we need to know about the project at hand, to understanding what it is that makes our stakeholders tick?"

Thoughts?

Update:

Thanks to Mr. Cockburn for providing an online link to his article in comments .