In the other two blog entries in this series, we gave hints and tips for the agile Business Analyst up to the stage of documenting business requirements. In this entry, we will address the follow-up to that phase of the project life cycle with a few more tips.

• Once the requirements document is approved and signed-off, assist the team with the next step – System Design and Test Script/Test Case development work.
     • Be prepared to answer questions regarding the requirements.
• Take the role as liaison between the user community and the technical team.
     • The BA is the communication broker between the users and the IT team. As an ambassador of business and functional knowledge, you must be able to convey the business requirements clearly to both the Developers and the Quality Assurance Analyst.
• Participate in Change Management Board Meetings.
     • Document and track all the changes taking place.
• Participate in User Acceptance Testing (UAT).
     • In many cases, BAs don’t get involved in UAT sessions. However, from my experience, BAs must be prepared to play an important role in UAT to address the user testing phase.

Remember, Business Analysts do not merely document business requirements.  They also serve as liaisons and communication brokers between the technical team and the user community. Doing things right from the beginning will reduce the likelihood of making wrong steps during project development.

We wish luck to all the Business Analysts out there. Thanks for taking the time to read our blog entries.

In our last blog entry, we gave some suggestions of how the agile Business Analyst should lay the groundwork prior to gathering business requirements. In this entry, we will give some tips for the agile BA covering the next couple of main project stages.

• Gathering Business Requirements
     • During your first meeting with business users, gather the High-Level Requirements.
     • Always keep your discussions within scope of the project.
     • If any requirements are out of scope, document them for future enhancements.
     • Diligent users seeking to do their jobs right typically want everything. But remember not all the requirements are critical to business – some could be just ‘nice to have.’ Negotiate with business users and other stakeholders to identify the requirements that will add the most value to the business.
     • If you receive conflicting requirements from different business users, call a meeting to address the gaps. Get the users to justify and prioritize the requirements based on importance and criticality to business.
     • Never offer technical solutions for current issues on the spot, but rather document all issues and take them to your technical team for discussion. Then come up with solutions that can be shared with the business users.
     • Document all the points and send them to the business users after the meeting. This will ensure that the points are correctly conceived, and, if any are wrongly captured, that the business users will have the opportunity to correct them.

• Leading Joint Application Development (JAD) sessions
     • Realize that it will be next to impossible to get developers and other team members, as well as other stakeholders, together all at once to sit in a room and brainstorm about system design.
     • Be willing and able to play the lead role in administering, managing and facilitating JAD sessions.

• Documenting the Business Requirements
     • When you develop the business requirements document, spell out the details clearly, without any ambiguity or vague points. Use simple words to describe the requirements.
     • Present the requirements with diagrams, flow charts or pictures. Remember, “a picture is worth 1,000 words!”
     • For effectiveness, use Use Case or UML diagrams to present the details.
     • Use MS Visio to present the workflow models or business processes clearly.
     • Provide both ‘AS-IS’ and ‘TO-BE’ models, so that business users can compare and understand the differences.

In our next blog entry, we will wrap up this series with some tips for the agile Business Analyst during the stages that follow the documentation of business requirements.

The objective of this series of three blog entries is to share our working experience through some tips for the agile Business Analyst. Like those in some other IT roles, Business Analysts play a significant role in ensuring a smooth project implementation. If you consider the multiple phases of the Software Development Life Cycle (SDLC) or Project Life Cycle (PLC), the business requirement gathering phase is the very first phase in the project pipeline. A precise and concise set of business requirements are the strength, backbone and foundation of the project implementation activities. Business Analysts are the people who face the firing squad of Business Users, Developers, Quality Assurance Analysts and other project team members, as well as other Stakeholders. They get involved in the early stages of the project, remain with the project as it evolves from one phase to another, work as a liaison between business users and developers, are fully accountable for the accuracy of requirements, produce documentation, and the list goes on.

First up, we will cover the preliminary stage, in which we do all of our groundwork prior to gathering the business requirements, along with some general hints and tips for the agile BA.

• Do your homework 
      • Take time to research the company history, business background and stakeholders.  This knowledge will increase your confidence when addressing the company’s business users or other stakeholders.
• Be prepared 
      • Develop questionnaires related to business processes, business user expectations, etc.
      • Prior to a meeting, send the agenda to business users so that they can be properly prepared.
• Be creative
      • Open yourself up to unconventional solutions.
• Communicate well
      • You are an ambassador representing the IT group. You must be able to communicate well not only with your teammates but also with business users, managers and everyone with a stake in the project.
• Break the rules 
      • Don’t take this to mean that you should literally break any of the company rules or policies. What I’m trying to say is that you should break the traditional way of capturing business requirements by incorporating new techniques, tools and methodologies in your requirement-gathering activities.
      • Explore options to present requirements in a strategic way that others will understand.
• Control the interview sessions
      • Always stick to your agenda and questionnaire topics.

In our next entry, we will continue through the project stages of gathering and documenting business requirements.

“Unified” organizations bring it all together.  Their needs for integration of data across business units and standardization of processes are both high.  Dow Chemical is an example used by the Enterprise Architecture as Strategy authors.  Dow cross-sells products within regions, so it needs excellent data integration, and it sells the same products, via standardized processes, in more than 175 countries around the world.  Sixty percent of Dow’s work processes are standardized and five of its eight global processes are housed in a shared-services organization.  Dow has achieved enormous bottom-line efficiencies by focusing on both data integration and process standardization…as well as shared services!

Of course there are hybrid situations as well.  Some companies employ one model for certain functions and another for others.  Once you’ve established where you fit in, or where you should fit in from the standpoint of your operating model, defining process and IT strategies becomes much easier. 

We would like to hear your thoughts and ideas.  It could be interesting to discuss some more examples of where public and private sector organizations fit in, and why.  Where does your organization fit into the MIT framework?  What about companies like Wal-Mart and Dell?  And what about public sector organizations?  How about universities?  Or utility companies?

The “Replication” model on the lower right is for organizations whose success depends on efficient and repeatable processes, but not on shared customer relationships. McDonald’s and other franchise operations are clear examples of this type of organization. Repeat the process meticulously and make sure that the experience is consistent at each company outlet and you’ve got a winning formula for success!

TD Bankworth, also described in the Enterprise Architecture as Strategy book, represents a financial services organization that found a Replication framework to best support its growth strategy. The organization transitioned from a Diversification to a Replication model because the latter enabled it to make efficient and effective acquisitions, and to get new branches up and running quickly.

Stay tuned for the next post, and last in this series, which covers the Unification Model.