Making the Most of Working with your Business Analyst Colleagues

If you work with other business analysts, you are fortunate. Together with your colleagues, you can experience greater effectiveness than you could have achieved on your own. (For example, a stakeholder may be more reticent to challenge the policies of a group than he would those of an individual analyst.) Additionally, your colleagues can provide you with a diverse and convenient pool of expertise from which to draw.

Since each analyst brings unique strengths and knowledge to a working group, a heightened level of collaboration will sharpen each of your skills. Making the most of working together will further not only the business needs of your organization but will also contribute to the professional growth of each analyst. Here are some ideas for capitalizing on your strengths as a group:

• Create a virtual encyclopedia or wiki of analyst information particular to your organization, and keep it private among your group. Business analysts often maintain voluminous amounts of information: stakeholder lists, subject matter expert lists, archived emails and documentation, training techniques, previous versions of requirements, and so on. If this information is limited to each analyst's hard drive, fellow analysts are left wondering who has what information, or if the needed data has been gathered at all. Keeping all of this information in an organized, sensible format that any analyst can quickly put her fingers on will increase your efficiency as a group. As far as security settings, there are many reasons to keep this information private. There's no reason for someone who considers himself a subject matter expert on supplies to know he's not on your list of experts at all, or for a salesperson to know you are saving her email from March in case she forgets the direction she gave you at that time. Leaving group documentation open to all stakeholders also opens the door for organizational errors. For example, someone could find an older copy of a requirements document, become confused, and begin using that as the current version. Group documentation should be limited to your group.

• Also, create a public-facing site, and craft it so that stakeholders perceive your group as a cohesive whole. In addition to your private work area, you will want a place where anyone within your organization can find documentation that is relevant to their work. File-naming conventions and storage methods within this area should be uniform. Examples of relevant data to keep here could include the most current, approved versions of requirements; ancillary graphs and documentation to support these requirements; current status reports; project lists; and meeting notes. Training your non-analyst colleagues to refer to this virtual area regularly will save you and your colleagues time in answering countless questions and replying to repeated documentation requests.

• Capitalize on each other's strengths to increase speed and efficiency. If one person in your analyst group has a background in programming and another has a background in business communications, it's a no-brainer to decide who should take the lead on technical specifications and who should be the go-to person for interviewing stakeholders. But consider not only work and educational experience among your peers, but also natural talents and personality traits. Is there one leader who likes to run things? Ask her if she would like to take over maintenance of the wiki. Is there one person who enjoys graphic design? Ask for his expertise with thorny graphs and diagrams. Pooling your strengths will cause your group to work more quickly. There is no need for someone without any Photoshop experience to spend days trying to create a mock-up, or for someone who hates confrontation to procrastinate interviewing a difficult stakeholder, when other resources within your group could handle those tasks quickly and easily.

• Cross-train. If your organization is cutting costs these days (and whose isn't?), you can still get the benefits of a professional conference or seminar by setting up cross-training sessions among your colleagues. Your Photoshop whiz colleague can take an hour or two to teach the rest of you some basic tricks for simple charts (though you may still need him for more elaborate mock-ups). If some colleagues are at a loss during in-depth interviews, let the former communications consultant share a few tricks, and perhaps post some basic interview questions to your group's wiki. The challenge for most over-worked analysts is making time for these types of training sessions. Remember that you would each make time if you were going to a paid conference, and this cross-training will benefit not only your organization but each of your careers in the long run.

• Lobby for on-site training. While it may be cost-prohibitive for your organization to send you and your colleagues to a conference in another city, it may be more affordable to bring a trainer to you. Rather than paying for all of your travel expenses, your organization would be paying one person's travel expenses and professional fee. The more analysts who are able to attend on-site training, the greater the economic return.

• Standardize policies for your group, and put them in writing. Just as your organization has relevant policies in place for all of its employees, a business analysis group should have uniform policies in place to which all analysts adhere. Does one analyst allow changes after requirements are declared final, but the rest in your group refuse them? Do two analysts hold regular status meetings with stakeholders, but the rest do not? These types of discrepancies between analysts are not only inefficient; they are bad internal public relations for your group. Together, you can develop a laboratory of best practices centered on the unique needs of your organization. Put some thought into the policies and practices that make the most sense for your business, get your manager’s approval, and formalize them in writing. This will eliminate confusion and help everyone in your organization know what to expect from your group.

• Work quickly to resolve conflict within your group. Your organized group will have more power and benefits than any one of you would as an individual. But within any group, conflicts will inevitably arise. You may have two analysts who both feel they should monitor the wiki, or analysts who vehemently disagree as to what should be made public and what should not. This conflict is not necessarily a bad thing, since it encourages each of you to think in new ways and from different angles. Work to resolve any conflicts you have quickly, while the issue is still fresh and hopefully small. Standardized policies will go a long way to eliminating conflict, as will a sense of equitable work load. If you feel that a conflict is escalating to the point that it denigrates your group's effectiveness, involve a manager to help devise a resolution. If there is ongoing division within your group, your effectiveness and communication will begin to diminish.

• Establish your group as a Community of Practice. Today, the work of business analysis, information technology, and businesses in general are quickly evolving, with new ideas and technologies continually being introduced. Together with your colleagues, you can develop methodologies to detect these new trends, offer each other feedback regarding how they might affect your organization and work, and implement them when appropriate. Discovering these emerging opportunities could be as simple as passing around industry periodicals and then discussing them, or as formal as periodically attending conferences and bringing back proposals for change. Your Community of Practice can also decide which industry standards (such as those found in BABOK 2.0) would be beneficial to formalize within your organization. See here for more information on establishing a Community of Practice.

• Develop an optimized tool box. In keeping with presenting a uniform image and policies to organizational stakeholders, you may also want to survey which software tools will work best for your group and lobby for their adoption. Does Visio work better than PowerPoint for charts and diagrams? Is SharePoint really your best option for managing requirements? Let each analyst experiment to help decide which tools are most effective. Lobby your manager to enable your group to get any that you don't have, and then use them consistently.

• Brainstorm. This may seem like a no-brainer. Every analyst occasionally has difficulty discovering, devising, describing, or illustrating a solution. When you get to one of these roadblocks, other analysts can come to your rescue. If impromptu brainstorms seem to be taking up a lot of time, you may want to set aside an hour or so of dedicated brainstorming time each week, where one or more of you can get feedback from the rest of the group. Or if you are all immersed in difficult projects, you may want to keep those meetings to just two or three analysts at a time.

Whether you need creative help or professional support or feedback, your business analyst colleagues can be invaluable resources for you. Adopting the practices listed here will help each member of your team to make the most of your combined pool of knowledge, benefitting not only your organization but your individual careers as well.

Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com