Identifying, Tracking and Validating Assumptions
By Rumesh Wijetunge
The primary role of a business analyst in a project is to elicit, analyze and document requirements related to the solution being developed. Business Analysts thus get immersed in requirements spending a bulk of their time in a project on requirements management related tasks. Requirements as per the BABOK® are of 4 main types namely, Business Requirements, Stakeholder Requirements, Solution Requirements and Transition Requirements. The business analyst primarily focuses on getting the functional and non-functional requirements of the solution right as those types of requirements create the highest amount of value for the stakeholders. The effect from the context Businesses operate within a certain context. The context consists of the external and internal environment with different interacting entities each with different requirements, interests and impact levels. The context thus creates limitations in various forms and creates problems or opportunities to be addressed through solutions. The problems or opportunities are the actual needs of the business that needs to be satisfied. The business context is complex with a lot of turmoil and undergoes constant change. This uncertainty results in difficulties with regards to eliciting, analyzing and documenting the exact need. Information required may not be accurate, complete and even not readily available resulting in the BA having to make appropriate ‘assumptions’. What are Assumptions? The BABOK® defines Assumptions as factors that are believed to be true but are not confirmed yet. The business analyst is responsible for identifying and managing product-related assumptions whereas the project manager is responsible for the project-related assumptions. The Business Analyst must identify all assumptions that may have even a minuscule amount of impact on the product. Working with the unknown Part of the business analyst’s role is to work with unknowns. It is an intriguing role and at the same time can be a nightmare. The BA must first list down these unknowns as assumptions, track them and manage them when these loose ends become clear. Assumptions when becoming clear might impact even the entire solution. It is the business analyst’s responsibility to manage this progress ensuring that business objectives are being met. Numerous case studies have established that Certified Business Analysis Professionals are capable of handling the end-to-end processes pertaining to managing assumptions and analysing their impacts. With time when more requirements are elicited, analyzed, modeled and documented and when more stakeholders get involved in clarifying doubts these placeholders called assumptions may become an actual requirement in the solution. The solution evolves as and when assumptions become clearer. How to better identify and manage assumptions? Identifying assumptions is a challenge. There are no proven methods for identifying assumptions and mostly it is to do with the intuition and experience of the business analyst. The BA must think out-of-the-box to identify all possible scenarios thus working towards identifying as many assumptions as possible. For example, a business analyst with domain expertise will be able to quickly identify assumptions pertaining to a solution being developed for the banking and finance domain. These assumptions even may be with regards to functionality, business or validation rules. Another great way to identify assumptions is through reverse engineering. The business analyst in collaboration with the development and QA teams can study the solution designs, code and test cases to identify great assumptions that may end up being important and cool features of the solution. For example, the latest technology trends of mobility, Robotics, IoT etc provide great opportunities for innovation. These may start off as high-level assumptions but end up becoming a groundbreaking feature in the future. The Business Analyst must document assumptions along with the associated attributes. These attributes include identified date, owner, impact, associated risk and any other information. Assumptions most often will accompany functional or non-functional requirements. It is thus important to clearly document the dependencies so that future impact can be properly managed. The business analyst must closely manage assumptions primarily with regards to the potential risk and the possible impact it poses. Assumptions carrying high risk with high impact must be closely monitored with moderate to low risk and impact items being managed less diligently. The BA must periodically assess each assumption and check whether it is still valid and whether it is still in line with the business context or the need. Assumptions over time may become invalid and thus be not in line with the business objectives. Such assumptions may be removed or deprioritized and be periodically monitored as required. The BA is responsible for reporting on these assumptions and in keeping relevant stakeholders informed. The project manager and sponsor especially must always be kept informed, as assumptions when true may have a big impact on the triple constraints of the project. The timelines, budget, and scope of the project may get affected as a result of certain assumptions becoming true and these must be closely managed to ensure project success. Conclusion Assumptions are an important component of business analysis effort. If assumptions are identified and managed properly they can have a positive impact on the project. The business analysts role in identifying, documenting and managing assumptions is pivotal to the success of the project. Learn more about assumptions and associated risks by going through the YouTube video accessible from the link below.
Rated 4.0/5
based on 9 customer reviews
Identifying, Tracking and Validating Assumptions
By Rumesh Wijetunge
The primary role of a business analyst in a project is to elicit, analyze and document requirements related to the solution being developed. Business Analysts thus get immersed in requirements spending a bulk of their time in a project on requirements management related tasks. Requirements as per the BABOK® are of 4 main types namely, Business Requirements, Stakeholder Requirements, Solution Requirements and Transition Requirements. The business analyst primarily focuses on getting the functional and non-functional requirements of the solution right as those types of requirements create the highest amount of value for the stakeholders. The effect from the context Businesses operate within a certain context. The context consists of the external and internal environment with different interacting entities each with different requirements, interests and impact levels. The context thus creates limitations in various forms and creates problems or opportunities to be addressed through solutions. The problems or opportunities are the actual needs of the business that needs to be satisfied. The business context is complex with a lot of turmoil and undergoes constant change. This uncertainty results in difficulties with regards to eliciting, analyzing and documenting the exact need. Information required may not be accurate, complete and even not readily available resulting in the BA having to make appropriate ‘assumptions’. What are Assumptions? The BABOK® defines Assumptions as factors that are believed to be true but are not confirmed yet. The business analyst is responsible for identifying and managing product-related assumptions whereas the project manager is responsible for the project-related assumptions. The Business Analyst must identify all assumptions that may have even a minuscule amount of impact on the product. Working with the unknown Part of the business analyst’s role is to work with unknowns. It is an intriguing role and at the same time can be a nightmare. The BA must first list down these unknowns as assumptions, track them and manage them when these loose ends become clear. Assumptions when becoming clear might impact even the entire solution. It is the business analyst’s responsibility to manage this progress ensuring that business objectives are being met. Numerous case studies have established that Certified Business Analysis Professionals are capable of handling the end-to-end processes pertaining to managing assumptions and analysing their impacts. With time when more requirements are elicited, analyzed, modeled and documented and when more stakeholders get involved in clarifying doubts these placeholders called assumptions may become an actual requirement in the solution. The solution evolves as and when assumptions become clearer. How to better identify and manage assumptions? Identifying assumptions is a challenge. There are no proven methods for identifying assumptions and mostly it is to do with the intuition and experience of the business analyst. The BA must think out-of-the-box to identify all possible scenarios thus working towards identifying as many assumptions as possible. For example, a business analyst with domain expertise will be able to quickly identify assumptions pertaining to a solution being developed for the banking and finance domain. These assumptions even may be with regards to functionality, business or validation rules. Another great way to identify assumptions is through reverse engineering. The business analyst in collaboration with the development and QA teams can study the solution designs, code and test cases to identify great assumptions that may end up being important and cool features of the solution. For example, the latest technology trends of mobility, Robotics, IoT etc provide great opportunities for innovation. These may start off as high-level assumptions but end up becoming a groundbreaking feature in the future. The Business Analyst must document assumptions along with the associated attributes. These attributes include identified date, owner, impact, associated risk and any other information. Assumptions most often will accompany functional or non-functional requirements. It is thus important to clearly document the dependencies so that future impact can be properly managed. The business analyst must closely manage assumptions primarily with regards to the potential risk and the possible impact it poses. Assumptions carrying high risk with high impact must be closely monitored with moderate to low risk and impact items being managed less diligently. The BA must periodically assess each assumption and check whether it is still valid and whether it is still in line with the business context or the need. Assumptions over time may become invalid and thus be not in line with the business objectives. Such assumptions may be removed or deprioritized and be periodically monitored as required. The BA is responsible for reporting on these assumptions and in keeping relevant stakeholders informed. The project manager and sponsor especially must always be kept informed, as assumptions when true may have a big impact on the triple constraints of the project. The timelines, budget, and scope of the project may get affected as a result of certain assumptions becoming true and these must be closely managed to ensure project success. Conclusion Assumptions are an important component of business analysis effort. If assumptions are identified and managed properly they can have a positive impact on the project. The business analysts role in identifying, documenting and managing assumptions is pivotal to the success of the project. Learn more about assumptions and associated risks by going through the YouTube video accessible from the link below.
Rated 4.0/5
based on 9 customer reviews
467
- by Rumesh Wijetunge
- 28 Feb 2018
The primary role of a business analyst in a project is to elicit, anal... Read More
How To Generate Requirements From Use Cases
By Abhinav Gupta
In earlier posts, I wrote about user stories that can help capture user’s requirements holistically and encompass the needs of your customers; I also wrote that user stories should then lead to use cases enabling your engineering team to get something concrete on paper for building. This is the third and final post in this series: How to generate requirements from use cases. The simplicity of this task can be misleading. If we, as project managers or product managers, fail to accurately translate our refined and well understood user stories, use cases into requirements; then our engineering team is doomed for failure. Why? Because requirements that were being tracked to completion before shipping were not completely and correctly comprehended, in spite of having good user stories and use cases. Hence, it is very simple but an important step where you should get final requirements correct down to the last detail. I could have used the term “write” or “create” requirements from use cases; like I did for my post of Use cases but I chose to use the term “generate”. Why? Because your product or feature requirements should organically arise out of use cases and you only need to start the documentation process to have them recorded; assuming you have done your job correctly. Before proceeding, I humbly request you to please read and understand earlier two posts on “how to work with user stories” and “Use Cases - How they are different from user stories and how to create them”. And feel free to raise questions to me by replying to the comments or emailing me directly. Now, assuming that you have read those two articles; let us begin on the last stretch of this journey. What are requirements? Please take 30 seconds and try to put in words; what is meant by the term “requirements”? Time yourself! I am waiting. Tough! Isn’t it? Exactly! Because while we all intrinsically know what requirements mean, we are not able to put them into words and whatever can’t be put into words, can’t be explained to the audience. Unless we have a way to put our requirements into words exactly the way we understand them intrinsically, we will not succeed in our goals. To begin with, I define requirements as a clear concise sentence of not more than 10 words specifying the most singular unit of demand. A simple example of generating requirements from use cases: Let’s continue with the same toothpaste development example from my use cases post so that we all are on same page and mutual mental understanding remains. There we had developed a user story for John, our user, who wanted to feel fresh and energized even after 12-14 Hrs. of work day. And based on that, we had developed some use cases; remember? See the post here. Listing some use cases again here for ease. Use case 1: User wants to have a premium quality feel when he/she takes the toothpaste tube in hand before brushing. Use case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. Now let us generate requirements out of those. Always remember, following things while generating requirements: Requirements should be concise and should contain only one demand in them. A single use case should not be giving rise to more than 2, at max 3, requirements. If a use case is able to generate more than 3 requirements then it is a clear sign that this use case is in fact a half-baked user story and needs to be broken down further. If a requirement cannot be expressed in less than 10 words then it is a use case in disguise and you need to relook at your user stories once again All requirements should have priority. We will be using tabular format so that we can maintain requirement traceability. 1) Requirement number has to be unique and will be used to track the requirement in various forums, discussions and work breakdown structures. Recommended format for requirement number is X.Y where X refers to the use case number and Y refers to the unique requirement within that use case. For example: 1.1, 1.2, 1.3 and so on to depict 1, 2, 3 requirements for use case 1. 2) Requirement description as we know is a clear concise sentence of less than 10 words depicting a single unit of demand 3) Use case generated from allows the product manager and engineering team to know which use case generated this particular requirement and suppose, down the line if use case or user story undergoes modification then we will clearly know which requirements are impacted and require a review. So it helps in that sense. 4) Business priority is not to be confused with task priority. Every task that is a child of a requirement will have its’ priority depicting the order in which they should be done. So, let us generate requirements for Use Case 1: “User wants to have a premium quality feel when he/she takes the toothpaste tube in their hand before brushing.” Now, let us generate requirements for Use Case 2: User gently squeezes the tube and he is pleased with the smoothness of the paste flow out of this tube. Now, let us generate requirements for Use case 3: User is able to notice the right amount of paste coming out of the tube every time, he/she brushes. It is never too much nor too little. One gentle squeeze always gives out the right amount of paste required for brushing. And so on you can develop your requirements. I hope you enjoyed this post as much as I did! ☺ All the best!
Rated 4.0/5
based on 20 customer reviews
143
- by Abhinav Gupta
- 09 Nov 2017
In earlier posts, I wrote about user stories that can help capture use... Read More
The Business Analysis Core Concept Model (BACCM)
By KnowledgeHut Editor
The Business Analysis Core Concept Model™ (BACCM™) is a conceptual framework for business analysis outlined in the Business Analysis Body of Knowledge® Guide (BABOK® Guide). The Guide defines business analysis as “the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders”. Business analysis encompasses a wide range of skills, knowledge, and tasks that may vary in form, order, or importance for individual business analysts or for various initiatives within an organization. The purpose of BACCM™ is to provide a common conceptual framework to business analysts so that they can perform and discuss their work in a common terminology that is independent of perspective, industry, methodology, or their levels in the organization. Additionally, the BACCM helps business analysts perform better business analysis by holistically evaluating the relationships among these six concepts and also by evaluating the impact of these concepts and relationships at any point during a project in order to establish both a foundation and a path forward. The BACCM consists of six core concepts: Change, Need, Solution, Stakeholder, Value, and Context. All core concepts are equally important and necessary. There is no ranking among these - no single concept holds greater importance or significance over any other concept. Each core concept is defined by and dependent on the other five core concepts and cannot be fully understood until all the concepts are understood. Let’s review the six core concepts in detail, along with their definitions as provided by the BABOK Guide: 1) Change: Change is an act of transformation within an organization in response to a need. The need can be internal or necessitated by an external event such as a disruption in the market. The aim of the change is to improve the performance of an enterprise through deliberate actions controlled through business analysis activities. 2) Need: Need is a problem or opportunity to be addressed by the business analyst. Needs can cause changes by motivating stakeholders to act. Changes can also cause needs by eroding or enhancing the value delivered by existing solutions or creating the need for new solutions. 3) Solution: A specific way of satisfying one or more needs in a context. A solution satisfies a need by resolving a problem faced by stakeholders or enabling stakeholders to take advantage of an opportunity. 4) Stakeholder: A group or individual with a relationship to the change, the need, or the solution. Stakeholders are grouped based on their relationship to the needs, changes, and solutions. 5) Value: The worth, importance, or usefulness of something to a stakeholder within a context. Value can be tangible or intangible. Examples of tangible values are potential or realized returns, gains, and improvements. Intangible value often has a significant motivational component, such as a company's reputation or employee morale. 6) Context: The circumstances that influence, are influenced by, and provide understanding of the change. A change always occurs within an environment. A context is a wide-ranging term that can include everything from an organization’s culture, mission, and demographics to government policies, competitors, products and sales. In order to successfully implement the change, the business analyst must carefully define and analyse the context within which the change is being implemented. Let’s consider an example to illustrate the BACCM in more detail. The wave of digitization is transforming many traditional industries. A traditional retail business that operated brick and mortar stores for years must now compete with e-commerce companies that provide the same goods to customers but with additional benefits such as convenience (shop from home), wide range of products and attractive discounts (due to the lower cost business models of e-commerce players). In order to respond to this change in market dynamics, a business analysis task can be performed at a traditional brick and mortar retail store using the BACCM. Here is how the six core concepts may be analysed in this example: 1) Change: Provide e-commerce solutions to customers who prefer shopping online. This will require completely new business processes and functions to fulfil online orders. 2) Need: Rising popularity and market share of e-commerce competitors who directly compete in the marketplace with the company, to attract a growing share of customers, transactions and volume of goods sold. 3) Solution: Depending upon the company’s organizational structure, capabilities and time-sensitive nature of the change, the probable (but not exhaustive) list of solutions could be to implement an IT project that enables the organization to set up its own e-commerce store, partner with existing e-commerce players to use their infrastructure for order fulfilment or acquire an existing e-commerce player and merge it with the company’s existing operations. 4) Stakeholder: The stakeholders, in this case, are almost from all functional areas – sales, marketing, IT, HR and Operations – within the organization. 5) Value: The tangible value, in this case, can be increase in sales and increase (or maintaining) the company’s market share. The intangible value can include transforming the organization to a digital future, introduction of new talent and ideas. 6) Context: The context for this proposed change can be the growing market share and popularity of e-commerce players, changing demographic profile of the customers, improvements in the digital infrastructure in the country, entry of foreign players in the market and easier government regulations towards setting up of e-commerce companies.
Rated 4.0/5
based on 20 customer reviews
318
- by KnowledgeHut Editor
- 07 Nov 2017
The Business Analysis Core Concept Model™ (BACCM™) is a conceptual... Read More
7 Common Mistakes Often Committed By Business Analysts
By Shubhranshu Agarwal
A business analyst ensures that the end product meets the requirements and parameters of project's stakeholders. Business analyst holds the responsibility to gather the requirements through streamlined communication with stakeholders and to make the sense of collected information in order to help the project team complete the tasks successfully. The most challenging and wide-scoped task of BA is to give the users what they want instead of giving what they need during requirements gathering. The business analyst is expected to bridge the gap between the traditional and advanced practices of information gathering; it saves the time of all the project team members that they otherwise invest in pulling data from a spreadsheet and then feeding it into the Excel sheet to make it accessible at different points. The certified business analyst works on a very wide landscape with possibilities to commit mistakes unknowingly; and, even the single mistake affects the profitability, team members’ performance, and customer satisfaction. The learning is a continuous process; the following often committed 7 mistakes by business analysts will help you improve your performance: 7 Common Mistakes You Need To Avoid: 1. Requirements Review without Proper Collaboration The requirements review shouldn’t be considered as a task to be completed solely by the business analyst. The requirements review should be done with the proper involvement of concerned stakeholders to validate the importance of requirements against different perspectives. Checking the collected requirements against the related attributes with concerned stakeholders helps to minimize the possible defects before the application stage. 2. Improper Language in Requirements BA often fails in expressing the requirements in proper technical terms from the specific technical viewpoint. Business Analysts are expected to keep the requirements tested and well structured. Business Analysts need to make the requirements - SMART: Specific – Measurable- Attainable- Realizable -Time-bound. Going a step ahead from this commonly used ‘SMART’ approach, you can follow - SMART-CC that adds Complete & Concise also to ‘SMART’ acronym. The organization itself is the primary user of the requirements that you collect and make smart for testing; so, ensure that there is no confusion in understanding by anyone involved. 3. Allowing The Team Go For Designing Without Fixing Requirements: I have been engaged in many activities of reviewing and fixing stakeholders’ requirements; I noticed that numbers of stakeholders start discussing the designs and approach implementation too early without waiting for getting the analyzed and fixed requirements from business analyst. BA needs to squash such practices immediately because such practices tend to overshadow the actual requirements. Before understanding the stakeholders’ requirements, initiating the process designing may harm the project’ success. 4. The Conversation without a Thought Line The proper conversation with stakeholders is the key to complete the project successfully but it needs to be in the line of the perspectives you get after the analysis of business needs and that of the project. Non-relevant discussions put just the blinders to actual requirements and distract the team members from the task causing frustration. The competent business analysts avoid involving too many stakeholders in discussions to get the best solution for a particular issue; all the meetings should be issue based. 5. Taking the Requirements granted 100% Complete & Accurate before Discussing with Stakeholders: The numbers of business analysts feel that the documented requirements are 100% correct even before sharing with stakeholders. The less experienced business analysts have a common notion that the correction in documented requirements means that they didn’t do the job correctly; however, there are no fixed parameters for BA’s evaluation that stop them to change the once documented requirements. 6. Getting Approval for Documented Requirements without the Shared Understanding Some business analysts tend to get fast approval of requirements to expedite the process but a smart business analyst is expected to share the documented requirements with concerned stakeholders to assess their understanding and viewpoints. The common understanding is must to complete the project successfully on the time. 7. Each project has different requirements and success measuring parameters but some business analysts tend to use the most used template of BRD (Business Requirements Document) just to make the task easier. The BRD template, you select to use, may have some irrelevant categories to make your task more complex and time-consuming; if you notice such categories either remove these or mark N/A. The success mantra for accurate business analysis is to ensure that you discuss with all those with whom you should do to share your vision of requirements for designing a collaborative approach.
Rated 4.0/5
based on 20 customer reviews
200
- by Shubhranshu Agarwal
- 07 Nov 2017
A business analyst ensures that the end product meets the requirements... Read More
How a CBAP Certified Professional can Help with Business Analysis
By KnowledgeHut Editor
CBAP stands for Certified Business Analysis Professional, level 3 certification offered by the International Institute of Business Analysis. The importance of this course in the modern world of the ever-expanding businesses can never be stressed enough. There are some requirements and a key feature that one needs to be aware of before venturing into the course. This is the next level of expertise for the already working and experienced professionals. CBAP Requirements The general requirements for the CBAP are: 1) Work experience in handling business analysis - This includes a minimum of 7,500 working hours in ten years. This also includes any project directly handled by the applicant and also the projects that he has worked on as an assistant. 2) The requirement of the knowledge in the field - There are six knowledge areas defined under this system, and a minimum knowledge of at least four areas is demanded. There must make an investment of a minimum of 900 hours in each of these knowledge areas. 3) Development of the profession - There must be at least 35 hours of development noted in the past four years of his work life. 4) References from people of value - For getting enrolled in the course, the reference to at least two people is asked. These people are usually- a career manager, a client or a CBAP certified professional. The organization is giving the course certification checks these references before getting anyone enrolled in the course. 5) The code of conduct issued by the CBAP needs to be agreed upon Certification Benefits The value a CBAP certified individual can offer is indispensable making the CBAP certification high in value in the professional field and highlights both professional and personal recognition to the individual. The best advantage for the individual is perhaps the significant increase in salary among certified professionals. There has been up to sixteen percent increase in salary of the individuals after completing their certification. It is also a great CV builder, adding an edge to the CV/resume that can be a distinguishable factor from other candidates in the business analysis field. The opportunity of development of the profession is immense and the value added to any company that the individual decides to be a part of is indispensable. Program Certification Levels Program certification levels are the steps of progression in the person’s career and are best to be fulfilled in order. Levels are set based on the competency of the applicant where each level has its eligibility requirements. Level 1: This certifies the entry in the business analysis. The individuals entering the profession are the ones that should go through this level. The students and the just graduates are the best candidates for this level. The ones with the transitional phase of career are also good to enroll. The managers involved business analysis indirectly. The eligibility includes 21 hours of work in the last four years and agreeing to the Entry Certificate in Business Analysis Code of Conduct. Level 2: This is for the professionals who already have 2-3 years of experience in the field. This gives formal recognition to their already acquired and developed skill set. The work experience is a prime requirement in this level of certification. It requires at least 3,750 hours of work experience in the last seven years. There must a development in the professional level of about 21 hours in the last four years. This also needs references and agreement to the CCBA code of conduct. Level 3: This is for the business analysis professionals who have been in the business for at least over five years. It demands 35 hours of professional development in the last four years. A work experience of about 7,500 hours is demanded as a requirement for getting admitted to the Certified Business Analysis Professional level. The same references and the agreement to the code of conduct are asked as usual. Level 4: The final level is for the professionals with over ten years of experience in the field of business analysis. They have considered the industry thought leaders in the field of business analysis. They are the experts in the business analysis. They contribute to the evolution of the field. They are the pioneers in the field who are polished to perfection by the Certified Business Analysis Thought Leader course. The CBAP Certified Professional Exam The exam is 3.5 to 4 hours long with 120 multiple choice questions. The emphasis is given on the case study in order to analyze the depth of knowledge and the ability possessed by the candidates. The first step in the certification journey is to get familiar with the ‘A Guide to the Business Analysis Body of Knowledge’ (BABOK guide) book. Thorough understanding of the BABOK guide is essential, a process that requires time and attention. Professional Development Hours Joining a business analysis study group would be the first step; it provides the opportunity to get help with the exam preparations and to discuss with others the professional development hours. Another option is to enroll in a business analysis training course. There are also conferences that qualify for the professional development credits. The professional development hours are necessary if you want to enroll in any level of CBAP certified professional course. The enrollment in the CBAP course depends on the time investment and the budgetary allowances you can make. The timeline for the certification should also be a consideration you make before going for the certification.
Rated 4.0/5
based on 20 customer reviews
185
- by KnowledgeHut Editor
- 02 Nov 2017
CBAP stands for Certified Business Analysis Professional, level 3 cert... Read More
Comparative Overview of ECBA, CCBA and CBAP Certifications
By Shubhranshu Agarwal
The importance of business analyst is growing fast for over the past couple of years; today, having the competitive business analysts has become imperative to complete the projects successfully. With increasing competition, the role of business analyst has become specialized. A business analyst owns the responsibility to transform the company’s operations to profitable projects completion by extending full throttle support to the concerned team. The major factors contributing to the growing importance of business analyst are: Failure rate of IT projects A business analyst bridges the gap between different business units and it departments Outsourcing has become a necessity; and, the business analyst keeps the balance in values Projects are getting more and more complex The special skills of business analyst help the organizations adopt new technologies The business analyst plays critical role in budget allocation Options to Become a Certified Business Analyst: Having a globally recognized business analysis certification helps you boost up your career in almost any business sector. As the big data and business intelligence are getting wide-scale importance in project management, the global demand for business analysts is also increasing. According to a report released by Mc Kinsey Global Institute, the demand for business analysts only in the United States could be 50% - 60% higher than the projected supply by 2018. The shortage of business analysts, as projected by numbers of different reports, gives you an opportunity to become a certified business analyst with bright growth prospects. A number of knowledge training companies in India offer a variety of value-added courses. The more in-demand business analysis certification courses, issued by IIBA (International Institute of Business Analysis) are – ECBA - Entry certificate in business analysis CCBA - Certification for competency in business analysis CBAP - Certified business analysis professional (CBAP) Which One Should You Choose? A Comparison: ECBA is the starting line to plan your career in business analysis. The qualification reflects the knowledge of advanced BA concepts & techniques that help you manage the project successfully. CCBA, the level-2 certification, is suitable for the experienced business analysis practitioners with 3,750 hours experience. The experience doesn’t need you to hold the designation of ‘Business Analyst’ essentially, but your experience should be BABOK® v3.0 Guide oriented. CBAP, the level-3 certification, is suitable for the business analysts with extensive 7,500 hours experience but willing to improve their expertise. Tabulated Overview of ECBA, CCBA and CBAP courses: To have ECBA, CCBA or CBAP qualification, you need intense knowledge of topics besides the adequate experience; here comes the role of knowledge training companies that offer instructor-led certification training to virtual classroom batches to help you pass the written test in 1st attempt.
Rated 4.0/5
based on 20 customer reviews
249
- by Shubhranshu Agarwal
- 13 Oct 2017
The importance of business analyst is growing fast for over the past c... Read More