Time Zone Differences

 When stakeholders work in different time zones, scheduling phone calls and conference calls is challenging. Project team members may be asked to work different hours from those which they are normally accustomed. The PM and BA need to balance the needs of the project with the needs of the team members. Different requirements elicitation techniques may be used even though they are not the ideal. For example, if your developers are in India and your business stakeholders are in California a teleconference will require someone to work in the middle of the night. Instead of talking with them all together, the BA may instead meet with each group separately relaying the communications back and forth. Remember to plan extra time for this work (and for your sleep!). When the BA relays messages she is often required to go “back and forth” between the two groups several times before all questions are answered and resolved.

 When you schedule group meetings try to alternate meeting times to equally inconvenience all stakeholders. Although your development team may be contractors they are still your stakeholders and being an excellent business analyst means assisting with communications and supporting all stakeholders. 

Nationality/Cultural Differences

When you are assigned to a team with members in a different country or from a different cultural background, do some research to learn about communication differences. As businesses become more global, there is universal recognition that working with people from other cultures presents unique challenges. There are many resources to help a BA get familiar with the basic cultural differences. Read web sites, take a class, learn the basics about the country where your stakeholder resides. Find out when national or religious holidays occur. These may affect stakeholder availability. Find out about working hours norms (i.e. do people put in overtime after work or on weekends, is working on a Sunday completely unacceptable?).

 If you are able to travel to your stakeholders’ country, read travel books to learn as much as you can about the history and current issues of the country. Be prepared to meet people with the customary local greeting (i.e. handshake, bow). The more that you know about the customs and habits of your stakeholders the faster you will build relationships and establish lines of communication. Offer to explain your customs and history also. Working with people from other cultures is a great opportunity for learning so allow your natural curiosity to facilitate project success while also enriching your personal experiences.

What are some of the challenges you face?  Please share any tips you have for working with virtual teams.

Kupe

These are both important topics for project managers and business analysts. As Bill points out, the big software vendors like SAP and Oracle traditionally focused on large companies as their customers but are now realizing that small or medium size companies have the same needs. As a business analyst in one of these small to medium sized companies, you need to be prepared to discuss the costs and benefits with your stakeholders. Software vendors will sell to your business stakeholders, convincing them to purchase rather than build software applications.

BAs have not always been involved in software selection decisions so if you hear about an evaluation process in your organization, try to get involved. Requirements are critical for selecting the best package and should be done before vendor evaluations. When the business doesn’t have a clear, shared understanding of what they need, they will select a package which looks good and is well presented. The underlying functionality, design, and/or performance may be lacking. We need business requirements (data, process and business rules) along with high level functional requirements, non-functional requirements and transition requirements to make the best selection. The IT group should also have technical requirements for vendor packages. All of these requirements should be presented to the vendors in an RFP. Ask vendors to respond to your requirements rather than choosing the best sales demo!

Schwaber differentiates Scrum from traditional methodologies and he asserts that Scrum is not prescriptive (Scrum does not describe what you should do in every circumstance). Sutherland and Schwaber admit they did not invent Scrum ideas. Both remind us that Scrum is a framework of best practices, which have been proven for years. Above all, keeping project work collaborative, honest and visible so that the team (and everyone else) knows exactly what is going on is representative of an agile self-organized team. Scrum and other agile processes focus on the practice of inspect and adapt allowing adjustments to be made as needed to keep the project moving toward the desired goals to produce business value with working software. Schwaber said more than once that Agile and Scrum rely on intelligent people doing the right thing at the right time. You can listen to Ken or Jeff talk about Scrum on You Tube. If you are interested in learning more about agile without leaving your desk, there are a number of instructional (and humorous) videos on You Tube about Agile and Scrum. Check it out. Please share your BA experiences on agile projects.

All the best,
Angie

Kupe Kupersmith, Director of Client Solutions, was interviewed by Laura Brandenburg, Bridging the Gap, to discuss his views on the challenges BAs face in selling their value and how to overcome them.

I was recently talking with a project manager who insisted every BA must be a business domain expert. I disagreed, suggesting a strong BA can learn the business by asking the right questions and studying the work. As we discussed this further, he agreed the BA should learn the specifics of the business and doesn’t necessarily need to be hired with industry knowledge. We realized our disagreement was really over WHEN the BA learns the business. For the project manager, he expects the BA to come to the project with the knowledge already in hand. He expects business requirements are already understood and the collecting of requirements (PMBOK® task) will be very straightforward. He does not have money or time in his project budget for the BA to learn the business. He wants the BA to immediately begin the Product or Solution scope and functional requirements.

At another company BAs are also expected to learn the business before their project work begins but when I asked if they are given time outside a project to perform this analysis the answer was no. All of a BA’s time must be allocated to a project. They expect BAs to learn the business in their spare time or on their own time.

I believe these attitudes reflect a lack of understanding of the complexity of our business domains. When an IT manager thinks a BA can learn a business area in his or her spare time, the manager assumes the business processes are simple or straightforward. Very few are. As BAs we need to constantly be educating our management (supervisory and project managers) about the sophistication of our business users and their work. We need to help the IT organization appreciate both the complexity of the business areas and the importance of capturing this complexity in business models. Only our deep understanding of the business will assure our projects deliver true business value.

Learning the business and representing it in business models and requirements is a critical success factor for every project. Business models are reusable, increasing productivity on future projects. They also need to be updated as the business changes. I would recommend an IT cost center for BAs to spend time learning business domains outside projects rather than within the context of a specific project. BAs who spend time with the business people on a regular basis also see opportunities for improvements and may suggest new projects.

When are you given time to learn your business?

BAF 2010 is the first inclusive, cross-specialty conference for all aspects of Business Analysis. Ensure you see the big picture: How Enterprise Analysis, Business Rules and Business Process are all related to BA and each other. Designed to help senior practitioners hear about innovative, state-of-the-art techniques by world-class practitioners.

Please join B2T Training at this event in Washington, DC, October 17-21, 2010. Our Co-Founder, Chief Curriculum Strategist, Barbara Carkenord, will be presenting “The BA 5 Musts of COTS Project” and Angie Perris, VP of Client Solutions, will be presenting “Mastering the Business Analysis Mentor Relationship”.

Click here to Download the paper. 

Is your company utlizing senior level business analysts the way Barbara points out? Please share your comments.

Regards,

Kupe

Organizations that are successful implementing agile approaches typically agree to support one main Agile Manifesto principle which is to value ‘individuals and interactions’ over ‘processes and tools.’ Agile is not a departure from principles that BAs have always embraced. We absolutely agree that it is difficult to elicit the best requirements without direct interaction with the domain subject matter experts and developers!

One major principle of agile is collaboration. Agile employs team collaboration in a variety of ways. First in agile approaches complete visibility is necessary. Whether the team works in a single war room or virtually using a SharePoint site, visibility into the progress of the project is a critical element. This really helps eliminate miscommunication around what is being worked at any given time. Additionally each agile project uses a prioritized requirements list to keep clear and visible the order that requirements must be worked addressed (in Scrum this is called a Product Backlog). Led by the product owner (project sponsor, product manager or key domain SME), everyone on the team participates in determining how many of the prioritized requirements will be included in the upcoming iteration.

Requirements are developed using collaboration. These requirements, often called user stories, will be briefly described at first on sticky notes or index cards (this can be done virtually) and they get detailed through more conversation with the users or user reps when the requirement is to be coded. Early user acceptance testing, and product demos (again another collaborative activity) really help everyone on the team understand whether the requirements are being correctly translated. Failing requirements are visible early in the project rather than waiting until the end of the project lifecycle during user acceptance testing on a traditional, plan driven project to find serious issues.

One more collaborative technique is the daily stand up meeting which many agile projects employ. This is a quick meeting with the entire team to ensure that everyone has visibility about the progress of the iteration. Project issues are discussed to inform everyone on the team and bring focus together to solve them quickly. In addition, everyone knows what each person is going to be doing on that day and how they will work together.

You may be asking what elicitation techniques a BA would use on an agile project. Interviews and facilitated user story workshops are most common but observation, document analysis, surveys, focus groups and prototypes are also common. Early user acceptance testing will be used to confirm that the requirements are correct.

BA’s may perform elicitation activities prior to the Iteration planning. This is sometimes referred to as Iteration zero (0). Again the key concept here is to make sure the business people or users are engaged as much as possible throughout the agile lifecycle. Compared to traditional projects the level of requirements detail known prior to the start of the iteration is less. It is on a smaller scale and typically requires fewer analysis techniques due to the tight timelines. One risk the BA faces on agile projects is that during the iteration if the business people are not available, the BA may need to represent the business and make requirements decisions. To do this the BA must have a deep understanding of the business. It is highly recommend that the BA work closely with the business to make available the appropriate SMEs during the time user stories are being detailed and tested for confirmation.

Agile and the BA – Part 2 will discuss how a BA can best be prepared to work on an agile project. I hope you will share your comments, experiences and concerns about agile projects. Collaboration works!

All the best,
Angie

Download my interview at http://www.requirements.net/

Let me know what you think! Thx, Barb