Business Analyst Questions - Bridgewater Associates Bridgewater would like you to answer the questions below.

Please understand that we receive a large number of applications, and since we're looking for the best people we can find, we often need more information than simply a resume. This isn't meant to be bureaucratic or onerous, so please don't spend too much time on it (no more than 30 minutes). When you finish, please return this document and name it as follows: Lastname-firstname.doc to Serguei.Zaychenko@bwater.com and Allison.Westrup@bwater.com. We look forward to hearing back from you. ~Bridgewater Associates Technology Recruiting

Question 1: Please provide a brief response (a few paragraphs) to the following: Describe a recent project for which you were responsible. What was the goal, and how did you ensure that the goal was achieved? How did you measure your success? What were the roadblocks along the way, and how did you address them? What mistakes did you make? What would you do differently if you were faced with a similar project again? Answer One of the projects that I was assigned to shortly after starting at KPMG was a Pilot program for the Group Audit Collaboration Portal. This was a SharePoint-based system that allowed globally distributed Group Audit teams to share documentation, reports, issues, opportunities and status. My role as the Business Analyst was to elicit and define the full requirements for the system. KPMG had an existing SharePoint platform in place that the team wanted to leverage. After initially performing a gap-analysis, I was able to create a set of requirements with input from Business stakeholders as well as the development team to try to ensure that business requirements and needs could be met. One of the key elements of the system was to be its ability to host and pull data from Microsoft InfoPath documents. This was based on a design previously implemented by the German KPMG firm where they had reporting output to an Excel file. The initial defined scope was that there would be a certain set of Standard Reports which were to be used by all Group Audit Engagement teams along with a small set of customized reports which would be made available to those teams as needed. Our critical success factors were to be able to push out individual Collaboration Sites on a global basis, have the InfoPath reports available for Auditors to access and use with full submission workflows enabled on them, and have SharePoint lists for tracking issues, opportunities and report status per group audit team. Security and User access were also top priorities to ensure that each Collaboration Site was secure from outside users and the different user groups within

each group audit team could only view and/or edit those range of activities and data to which they had access. My first task for the reports was to ensure that I was able to create appropriate management dashboards and summary reports based on the original InfoPath forms. All requirements documents were vetted through the Business stakeholders. The initial scope was laid out and agreed-upon. However, it soon came to our attention that the number of custom reports that business had initially anticipated would not be able to cover our pilot audit teams. This is where my initial mistake came into play. While we were able to accommodate the additional requests for customized reports, I had designed the initial dashboards and reports (in terms of data variables) to be fixed and that did not allow the development team to be able to scale the number of custom reports easily. What we had to do was to re-engineer the initial set of custom reports such that they could then be used to scale out for the additional requests. In my not anticipating the need to potentially scale out the number of custom reports, the development team and I had to do extra work in order to fix that issue. Having gone through this mistake, I realized that it is important to keep in mind that initial assumptions may change and that there is a need to keep flexibility in any system being designed to allow for greater scale that is initially anticipated. In another project where the team was to roll out a desktop-based search engine/knowledge base to a specific group of countries, I saw that the content update URL was hard-coded into the application and designated only for those countries that had requested the application. I voiced my opinion that as this application allows users to receive daily content updates, it will likely be adopted by many other countries if everything works well with the initial set. Based on this, it would be better to have a configurable way to set up how the application receives content updates so that a new build does have to be created for each new country. This was implemented, and we received positive feedback from the original set of countries and very quick requests from additional countries to make the application available to them. With the change in the content updater we were able to roll out the product without any further development changes or builds.

Question 2: Because Bridgewater pays transaction costs to trade (including both commissions and the market-moving cost associated with large trades), we must scale back our ideal trades to strike a balance between the cost and benefit of the trade. You have just been assigned to the project to refactor and extend the cost-benefit balancing module. With this assignment, you are responsible for ensuring customer satisfaction with the final product. The project is staffed with a customer from the business side who is usually very busy, a project manager, a tech lead and two junior developers who handle architecture and some coding, and now you, the new business analyst. As of today, the project is running three weeks late. The business user is concerned that the final solution will not solve her teams problems. The developers and tech lead have been creating the solution to their best understanding of the requirements, but are also concerned they may not fully understand what the business user needs. Please describe what you would do.

Answer My first task in such a situation would be to review and understand the documentation as it currently exists. With a clearer understanding of what was originally written up, I would then see what has thus far been developed to see how it matches up with the original requirements. I would then meet with the Business stakeholder and determine if their expectations now have changed or are still correctly reflected in the requirements as written. If they are different then we need to understand why that is the case. This does not necessarily mean that the initial requirements were written incorrectly, it could be that Business changed its mind. As the Business stakeholder may be very busy, this meeting can be done with the project manager and dev lead so that discussions can happen immediately. This of course depends on the current relationship between the parties. These discussions should provide an understanding of what needs to change going forward and how to best make sure that the dev lead and developers have a solid understanding of what the business stakeholder is looking for. Refactoring and extending the assigned module may require a change in scope. As the project is 3 weeks behind, it is important to determine the minimum requirement that needs to be fulfilled in order to consider the project a success (critical success factors) and to prioritize all individual business requirements for the benefit of development. It would be incumbent on me to work with the project manager to see how (if at all) all requirements can be implemented in the system.