Tag: Assessment

Demonstrate Your Value

Written by Adriana Beal on January 7, 2014. Posted in Articles. 1 Comment on Demonstrate Your Value

In 2013, I received many questions about how business analysts can demonstrate the value they add to their organization. I’ve also seen an increased interest in performance measurement for BAs. These two topics are tightly connected, as we are going to see in this article.

The inability to demonstrate the value BAs add to their projects limits what analysts can achieve in their organizations and reduces the opportunities they get to continue to develop their skills. Many BAs find it hard to convince management that they should be involved earlier in business and IT initiatives, so they can help influence direction and reduce risks associated with project scope. Some experience obstacles to even being involved at all in certain projects, which forge ahead without the benefit of a skilled BA to ensure the right problem is being addressed and the right solution is being built. Laura Brandenburg, in this article, mentions another challenge: the lack of funding for professional development, in the form of training, access to conferences and other high-cost learning opportunities.

All these problems share a common root cause: lack of concrete evidence of the value a skilled business analyst brings to organizational initiatives. For example, if you join a company that previously only hired weak BAs who never contributed substantially to the outcomes of software projects, stakeholders might forget to invite you to the discussions during the early phases of your projects. They may also decide to talk directly to developers to define the solution without seeking your contributions, and deny your requests for training, certification, or conference attendance, because they don’t see the potential return on that investment.

But BAs have a powerful tool on their side to help influence management to elevate their role and increase their exposure to enterprise analysis, high-profile projects, and professional development opportunities: performance measurement.

Even if your company doesn’t measure the performance of individual BAs, or does it poorly (measuring things that aren’t directly related to value creation, such as time spent by BAs on each task, number of requirements, requirements volatility), you can establish your own effective performance measurement system. Then, with the performance data collected, you’ll be able to provide solid evidence of the value you bring to your projects and demonstrate the benefits that further investments in your skill development can bring to your organization.

Here’s an example, drawn from my own experience:

Several years ago, I was asked to return to one my clients, a financial institution, to help bring one of their software projects back on track. In the course of the new project, I happened to find, lying on a shelf, a copy of the requirements document I had produced for my previous project. At the time the document was approved, the business stakeholders had offered high praise for my work, but when I opened that copy of the document, I saw many questions from the development team, hired only after I had left for another assignment.

For instance, while the business stakeholders had been satisfied with my requirements describing the “happy path” of a wire transfer being successfully completed, the development and testing teams also needed to know what should happen when an attempt by a customer to submit a wire transfer failed. The expected behavior could be anything from just presenting an error message to the user, to sending an alert to the appropriate account manager so he could immediately follow up with the customer to fix the issue. The right solution could not be built until the desired behavior was clarified.

That experience opened my eyes to an important aspect of my performance that I had been overlooking: writing requirements that not only the business stakeholders found to be in excellent shape, but also the development and testing teams considered to have enough information for them to be able to to build and test the right solution. Providing incomplete or vague information to development and testing teams may cause unnecessary delays when the teams have to list the questions they have and wait for someone to analyze these questions and provide a suitable answer. For that reason, when I saw that annotated document full of questions, I decided to start monitoring my performance in this area.

One of my professional goals became: “reduce the number of questions my requirements documents elicit from development and testing teams”. I defined a target of no more than 3 questions per document for year one and 1 question per document for year two. (This would give me some time to identify the patterns that caused developers to need clarification of my requirements and fix the issues before I started to hold myself to a higher standard.)

With my new goal in mind, I started thinking about requirements not just from the perspective of the business stakeholders (who already were very satisfied with the quality of my work), but also from the perspective of developers and testers. After writing each section of a requirements document, I’d ask myself: “If I were writing the code for this capability myself, would there be something else I needed to know?” And, “If I were in charge of testing this set of requirements, would I know the expected results for all relevant test scenarios, such as entering an out-of-range number, or skipping a required field?” These questions helped me find the omissions in my documents before they were released, drastically improving the quality of the final products from a perspective of the delivery team.

By the end of year two, I had exceeded my goal, with most projects yielding zero questions from developers. From time to time, I still get questions posted to the wiki page reserved for questions about requirements, but I can always map them to one of the following scenarios, which don’t affect my individual performance:

The question isn’t about requirements (e.g., “How many search results should be displayed in each page?” when the decision about how to display search results had been left for the UX designer, who might even design a solution with “infinite scrolling”, so there isn’t pagination to worry about);
The question has been answered in the document already (e.g., “Do we need to worry about different levels of permission for different user roles?” when the Table of Contents of the wiki space that stores the requirements already has a section titled “User Roles”);
The question is about a gap in requirements that is known and noted in the appropriate section of the requirements document (e.g., “Pending definition of which file formats the import capability will have to support”).

Now, how can this approach of setting goals and measuring your performance help you demonstrate your value to the organization and justify more investments in your professional development? Here are some steps that you can follow:

Show the results of your performance measurement and improvement efforts to management, accompanied by an analysis of the impact these results have in project outcomes. Example:
“Because our development team is in India, each question raised by a developer may cause a delay of up to 24 hours in completing a portion of the code, due to time zone differences. Clear requirements that eliminate the need to ask questions and wait for the answers mean more productivity for the developers working on the implementation of new capabilities.”
Describe the goals you are pursuing next, accompanied by what value reaching this goal will add to the overall performance. Example:
“My goal for Q1-2014 is to become fully knowledgeable on the business aspects of creating and maintaining promotional discounts for our webstore. This knowledge will help me better understand the business and user scenarios our tools must support, so I can propose better solutions and avoid the change requests that we keep receiving at the end of each development cycle to accommodate missing functionality.”
Ask for whatever resources you need to reach your goals. Examples:
“In order to help me achieve this goal, I’d like to ask permission to start spending 20% of my time in the marketing department, so I can observe their work when they are creating and updating promotions.”
“There’s a conference coming up about new trends in web analytics that I’d like to attend so I can bring some new ideas to the marketing team about how they can better track the results of their promotions. Based on better analytical data, I can help the business stakeholders prioritize future enhancements to our promotions engine to reduce the backlog of our projects by cutting scope that isn’t going to contribute to the bottom line.”

The main pitfall to avoid when discussing the value you bring to your organization is what many professionals do in their resumes and cover letters: talk about alleged personal traits (e.g., “I solve puzzles and fix problems better than most”, “I’m good at taking complex ideas and making them digestible”). You want your discussion about value to focus on clear and objective data that highlight recent accomplishments and show the benefits that your current performance and future improvement efforts can bring to the organization.

If you are a business analyst working on the IT space, you’ll probably be looking for evidence of how your work improves the quality of requirements artifacts, lowers the number of defects and change requests, increases user adoption rates, and/or saves time and money by helping the business focus on high-value features. For a process improvement BA, good measures would provide evidence of the return on investment of your recommendations on quality improvement and process modernization, the number of problems affecting customers or employees that have been fixed by your change proposals, and so on.

With a list of accomplishments backed by objective measures, you’ll be able to offer concrete evidence of the value you bring to your team and develop solid arguments to convince decision-makers to elevate your role and give you access to better information and training resources.

Don’t forget to leave your comments below.

Less Is More

Written by Marcos Ferrer on December 10, 2013. Posted in Articles.

Last month I put my foot in my mouth in a feeble attempt at mocking the thousands of pundits who have the “answer for ObamaCare”. I may have succeeded by being a bigger jerk than any of them – sigh 

This month I apologize by shutting my mouth with the following model. The model shows BABOK™ Enterprise Analysis and its immediate inputs and outputs.

AND, thanks to Dave Offenkrantz, PMP, who cared enough in a ridiculous situation to give me this month’s title and the wisdom behind it.

Nuff said!

Click image to view original size

Don’t forget to leave you comments below.

Sharing Knowledge in a Virtual World

Written by Logan Sanchez on December 10, 2013. Posted in Articles. 1 Comment on Sharing Knowledge in a Virtual World

As business analysts, many of us have experienced the unique challenges and obstacles faced when working in a virtual environment with geographically disbursed teams. In my previous position with a firm that handled invoice financing within the boundaries of the United States and had only limited experience with virtual meetings. However, in my current position, not only am I participating in virtual meetings, many of them cross international and cultural boundaries.

I have since learned that virtual meetings invariably conclude with too few having actively participated and no real assurance that anyone has learned anything. Usually, down the road, mistakes surface confirming the fact that not everyone got it and everything has to be repeated in a subsequent virtual meeting. Boring, and inefficient! There must be a better way to accomplish knowledge transfer.

Developing a New Framework

By asking ourselves what knowledge and experience we have in our respective tool kits, we can consider alternative means of sharing knowledge. One thing most analysts do well is training. We have practical and theoretical knowledge on this subject and if we simply shift our paradigm from sharing knowledge to one of training we may improve the virtual experience.

Based on this theory and the fact that practical knowledge has taught us training sessions are most effective when subject matter is presented in short focused segments, with each segment geared to specific objectives, coupled with exercises to drive these points home and sprinkle the whole affair with regular breaks. The result looked like this:

A few short modules
- Specifics on module development will vary with the subject matter. Suffice it to say that keeping the length of session in the 30 to 45 minute range seems to offer the best results. The number of sessions will vary with the complexity of the information you are attempting to impart.
Defined objectives and target groups
- Learning objectives are nothing more than a simple statement of what participants should expect to learn by the end of each session. One advantage of this requirement is that a more organized flow of information is achieved and the sum-of-the-parts are more likely to equal the whole. This is a great outcome for everyone involved!
Exercises to encourage participation and strengthen learning
- You need to decide what will be most effective for any given situation; exercises for each module or a single exercise that comprehends the whole. This is up to you and your team. The challenging aspect is to create an actual exercise—not a quiz!

The Test Run

My own team agreed to try the theory out in an upcoming virtual meeting regarding platform changes we needed to implement which would affect our Philippine team.

It is important to note that cross-cultural interactions, virtual or face-to-face, present additional layers of complexity as compared to interactions which do not cross international and/or cultural boundaries.

That said the presentation created was typical of prior sessions, consisting of power point slides demos and pertinent screen shots—only shorter and preceded by an overview of the learning objectives.

The learning objectives, as anticipated, turned out to be beneficial for creating a stronger focus.

In the final session the Filipino team was expected to present answers to the exercises. For cultural reasons, we chose to encourage the Filipino team to work on the exercise as a group. In other interactions you may choose to have individuals respond to the exercises. Filipino culture favors a team approach and individualism takes a back seat to the needs of the group.

Because we approached the sessions in this manner, we crafted the exercise to comprehend all the modules. As mentioned earlier, these exercises are not intended as a quiz. Rather, the exercises should force, or at the very least, encourage our Filipino colleagues to examine they actual process.

The exercises were discussed in the beginning for the express purpose of emphasizing that they were a learning tool and not a test. Although the exercises were completed by the group, it is suggested that the group select a spokesperson to present the results of the exercise in the interest of time.

The Results

The final session was largely the work of our Filipino counterparts who presented the results of the exercises. Although the responses fell short of 100% accuracy, the exercises provided a road map for what needed to be reviewed. The sessions worked out well overall and the platform changes we implemented went much more smoothly than any had gone previously.

Acknowledge the Effort—Offer Praise

How you handle this is entirely at your discretion. The effort should be acknowledged in some fashion and positive outcomes should get some kudos. Again, how this is handled may have cultural undertones.

Evaluation

Our team and the Filipino team regarded the overall experience to be a positive one and superior to previous methods used. Everyone was appreciative of shorter sessions and the exercises were well received by the Filipino team.

We noticed a significant increase in dialogue and more questions were asked using this framework, no doubt because of the concluding exercise.

The Final Analysis

While it is true that all the evidence supporting the validity of this method for sharing information is empirical, that doesn’t diminish the fact that it has worked for us.

It has resulted in a better experience for those providing the information and for those receiving it. We plan its continued use and improvement.

Don’t forget to leave your comments below.

Four Cost Effective Ways to Perform Early Life Cycle Validations in a Software Testing Project

Written by Mugdha Divekar on October 22, 2013. Posted in Articles.

Early life cycle validation is not a new concept in software testing space. It focuses on practices of testing team validating the key outcomes of upstream life cycle phases of software development and testing. But still many testing projects have failed to implement these practices in an effective way. It is primarily due to inconsistent and incorrect manner in which the implementation of these practices has been done. This point of view is based on author’s experiences and describes four most effective ways of implementing early life cycle validation practices in a testing project. This helps the project to achieve better productivity and application quality. It also aims at overall cost reduction of the project as the defects are caught and fixed during very early stages of a project.

Why “Early Lifecycle Validation” in software testing?

Gone are the days when software quality used to be inspected only towards the last phase of its life cycle i.e. say during system testing OR performance testing. Early Lifecycle Validation (ELV) is Or Shift left (as often termed as) a norm which is getting popular in all kinds of software testing projects. In this approach, the focus is on thorough validation of the deliverables of upstream life cycle processes by the testing team. The key benefits of ELV include

Effort and cost to fix the defects is less as cost of fixing a defect rises exponentially with each Life Cycle stage
Ensures best in class quality of the system as it ensures good input quality for every stage of the project
Software Development Life Cycle (SDLC )
Detecting defects early in the lifecycle saves in overall cycle time for the project and thus ensure better time to market

Key success criteria

The key success criteria for implementing early life cycle validation approach is –

Collaborative approach – To perform ELV activities, it demands for a collaborative approach of having various relevant teams involved in it like – client stakeholders, business users, development team, architecture team, functional testing team, performance and other special testing teams, help documentation team etc. Every team needs to have a single vision of best in class application quality in optimal cycle time. They should be open to accept suggestions and issues to their work product which are pointed out by some other team members.
Availability of appropriate skill sets to perform these activities – Key people who are going to perform these activities need to possess following skill sets
- Excellent domain and application knowledge
- Very good understanding on the IT technologies that are getting used in the project
Customer willingness to invest on ELV activities – ELV does not recommend any cuts in any existing appraisal activities of SDLC like design reviews, code reviews etc. These are some additional activities that are suggested on and above the basic appraisal activities. Hence it is important to have client willingness to spend extra money on the effort and time needed to perform these activities. The expected ROI on these investments is huge as compared to the investment made to perform these activities.

In absence of any one of the points below, the overall approach for ELV will not be effective.

Various approaches of ELV

There are multiple approaches to perform ELV. But in my opinion, following are the top 4 approaches to implement ELV in the testing projects.

1. Requirements Review (RR)

The testing team can get started on this approach as soon as Business Requirements Document (BRD) and System Requirements Specification (SRS) are base lined by concerned stakeholders from client team/development teams. So before starting on subsequent SDLC phase i.e. design phases there should be a phase to perform thorough review of business and system requirements by testing team. Within QA team, there should be profiles available that can play effective role of “User Proxy” who can wear client’s hat to understand the essentials and details of the system from user’s perspective and hence can think of from user’s perspective. This user proxy should also have very good knowledge about the application under consideration. S/he should also possess skills on domain and overall industry trends. For instance if the system under consideration is for some legal compliance perspective, then the user proxy should be aware details around

Complete knowledge on legal aspects for which the compliance system is made
Industry trends like what other companies/competitors are doing to comply to the same

The user proxy can pick up some more members from the team and perform these activities in a group review mode. Both the requirement documents (BRD and SRS) are thoroughly reviewed from key 3 perspectives i.e. functional verification, structural verification and conformance verification.

Functional Verification – Team ensures that the business requirements give an accurate and complete representation of the business goals and user needs. The same are rightly translated in the form of system requirements. For ex – The team can come up with observations like ones mentioned below

Comment	Implication/Objective
BRD – “All past salary slip should be made available to employees”. SRS – “Last 5 years pay slips should be made available to employees” Clarify.	Need to resolve this right away rather than getting this caught in testing OR production phases
SRS – Mention of financial requirement X is deviating from SOX compliance. Why?	Need to discuss and close this now otherwise may lead to penalty if this would have realized during production

Structural Verification – ELV Team checks the requirements from structural perspective i.e. they check for ambiguities of expression, seek clarification, restate it in structured natural language (say English) and apply “Cause Effect Graphing” or “Decision Table” techniques for better and clear representation. They also consider some natural language related checklist and tools like ambiguity checker to verify the requirements against the pitfalls of natural language.

For ex -The team can come up with observations like

Comment	Implication/Objective
SRS – “If it is transaction x then update relevant corresponding data like EPF, the salary structure etc.”	What is meaning of this “etc.”? Are any more records needed to be updated? We cannot leave this to interpretation of an individual.
SRS – “Accounts are reviewed for discrepancies at the appropriate time”	Need to explicitly and clearly mention of what the appropriate time is.

Conformance Verification – ELVTeam will ensure conformance to requirements management processes in terms of Requirement Traceability Matrix (RTM), requirement prioritization, requirement change procedure, process adherence etc. So the team can come up with observations like

Comment	Implication/Objective
Check RTM and review the traceability from BRS to SRS. For ex. BRS talk about 5 policies but SRS mentioned about only 4 policies.	Need to clarify and sort out the exact number of policies to be implemented
Check if there is any process defined for Requirement Change Requests (RCR).	Primarily to check if is it adequate? Does QA team get any role to play in the RCR management process? When will QA team come to know for any RCR?

All these observations should be discussed with relevant teams and stakeholders. Also we need to ensure that both business and system requirements documents are updated as per the observations.

Thus this step ensures that the requirements are clear, unambiguous and complete.

2. Design Quality Assurance (DQA) – applicable for both high level and low level design

If the thorough “Requirements Review” phase is carried out then it is assured that the design & architecture team is getting clear requirements on which they need to create design i.e. system architecture (high level design OR HLD) and low level designs (LLD). Once the high level design OR architecture phase is over then the ELV team again comes together to perform design quality assurance i.e. DQA activities. Here it is expected that the ELV team possesses good working knowledge of technology, databases, reporting tools etc. The team can take following approach for DQA

Based on business/system requirements, come up with the list of top requirements and priorities for which we need to verify the system architecture
The architecture team explains the overall architecture of the system to the ELV team
ELV team audits the design to verify that the architecture will provide the intended business requirements of the system.
Some sample design audit questions /observations can be

Comment	Implication/Objective
In the interfacing applications, MyApp should pull in data from 7 databases and 5 systems? But architecture diagram shows only 7 databases and 4 systems.	Check for that and ensure that provision for data pull from all the relevant interfaces.
In the architecture diagram, there is no component shown for “Reporting”. But there is a separate tab for reporting in the SRS.	Is this a genuine miss OR represented the same in a different way?

All such observations should be discussed with relevant teams and stakeholders and ensured the high level design and architecture documents are updated as per the observations.
Thus this step ensures that the high level design and architecture caters to the technical needs of the business and system requirements.

Similar approach can be taken once the detailed design phase is over. In this case the ELV team can plan to do audit of low level design on sample basis. So they will request architecture team to walk them through the detail design of some critical functionality. Some sample audit questions can be

Comment	Implication/Objective
Security aspect – For banking information – Are you taking extra login to retrieve this information for user?	To check security implementation
Trigger based activities – For ex – Email on trading window closure on respective dates–– How are they implemented? From where dates are getting picked up?	To validate trigger based approach

All such observations should be discussed with relevant teams and stakeholders and ensured that the corresponding design documents are updated as per the observations.

Thus this step ensures that the low level design and architecture caters to the technical needs of the business and system requirements.

3. Code Quality Assurance (CQA)

If the “Design Quality Assurance” phase is carried out, it is assured that build team is getting clear design on which code needs to be created. Once the build phase is over then the ELV team again gathers to perform code quality assurance i.e. CQA activities. Here it is expected that the ELV team possesses working knowledge of technology, databases, reporting tools etc. The team can take following approach for CQA

Based on business requirements, come up with the list of top requirements and priorities for which we need to verify the implementation in code
The development team walks ELV team through the key code implementations for the critical functionality and features that the ELV team wants to audit.
ELV team audits the code to verify that it will provide the intended business requirements of the system.
ELV team can also use some Product Quality Analyzer tools which can analyze the code in the statistical way to check the structural quality of the code. Such tools can create detailed report on the health of code from various aspects like maintainability, performance best practices, security related best practices, if the code is written in optimized way etc.
Some sample audit questions for CQA can be

Comment	Implication/Objective
If requirement traceability matrix is complete till coding phase for all BRS requirements	To check the traceability
Coding standards for the underlying language are followed or not? Some evidence? Some filled in checklists?	Assures consistency and best practices of coding are there in the artifacts
Explain the critical algorithm and logic of income tax calculation.	Try to understand basic logic of a key feature

All such observations should be discussed with relevant teams and stakeholders and ensured that the observations are implemented back in the code.
Thus this step ensures that the build phase considers all important aspects of business needs for the system.

4. Group Review of testing scope, requirements and strategies

In the above 3 processes, we saw that QA team reviews the deliverables from upstream processes of SDLC i.e. requirements, design and coding. In this practice, the upstream phase outcomes of STLC are validated by other concerned stakeholders. This is a very simple but powerful step that we can take to ensure that the testing scope, test requirements and test strategies outlined for the system are adequate and in alignment with the desired outcome from the system. We can use the group review approach for the same. All stakeholders from relevant subgroups can perform this activity. QA lead can coordinate this activity. All the relevant docs which capture the test scope, test requirements, test strategies and approach should be reviewed to check

If the testing is going to be adequate
Any obvious issues that these groups can see in the testing approach
Choice of test strategies
Correct understanding of test scope and test requirements

Sample audit questions for such group review can be

Comment	Implication/Objective
The chosen tool by QA for test automation is “X” and technique for automation is “data driven”. But the tool should be “y” and technique chosen should be “keyword driven”	This is input from one of the group review members based on her experience in similar other project wherein they faced issues in tool X and “data driven” methodology. If this Fagan inspection has not happened, this team would also have faced similar issues with their choice

With this review, the possible issues and hindrance will come out and QA team will have a chance to correct these things in the very beginning of the STLC phase rather than these issues traversing through various STLC phases and discovering at a very late point in time. Also involvement of every individual subgroup ensures that there is enough and correct testing approach for each part of the system.

Conclusion

As we have seen that software quality can be dramatically improved by adopting these simple but powerful techniques mentioned above and as summarized in the diagram below.

We can catch these defects at much earlier stage of SDLC OT STLC rather than catching them towards fag end of the process. We have also seen the sample ROI of performing these activities. There has to be a collaborative approach adopted by all the concerned stakeholders to make it effective. We have seen its benefits in project that implemented them in our organization. These benefits from the select case studies are as below

Improved test case preparation and execution productivity in the range of 19-34%
Defects detected using ELV techniques – ranging from 600-750 defects (which otherwise would have got detected only at the time of QA)
Cost of quality saving in the range of 300 K USD to 3. 4 M USD
About 99-99.8% of testing effectiveness ensuring extremely high quality of product/application when it reaches UAT/Production stag

Effort and cost incurred to conduct these activities is exceptionally low and was in the range of 10-40 K USD thus fetching us very high returns on the investment

Hence these methods are observed as most cost effective methods of early life cycle validation in case of testing assignments.

Don’t forget to leave your comments below.

References

Infosys validation methodology

BA CoE – The Value Differentiator

Written by Vipul Agrawal on October 1, 2013. Posted in Articles.

Need of a BA CoE

While the Business Analyst’s (BA) role interfaces to multiple organizational stakeholders during the execution of a project, very rarely do they interact with other BAs unless the project is big enough and needs multiple BAs. The ‘solo’ nature of the role creates a challenge towards cross functional area development, skill enhancement across business analysis and business domains. High level of collaboration is required to address these challenges; this collaboration can be achieved through a community which is focused on skill development and upgrade.

Additionally, the same community can be structured to provide a unified ‘Business Analyst’ view to the various stakeholders and also to nurture talent within the community thereby earning the tag of BA CoE – Business Analyst Center of Excellence.

The CoE thus becomes the notional ‘owner’ of the BAs, responsible for team formation, team development (both in skills and numbers), BA allocations and load management, evaluation and overall reporting to the universe of stakeholders.

Effective Center of Excellence

The focus of the CoE has to be in multiple areas of activities, ranging from capacity management to ensuring adequate availability of skilled BAs for training and development, knowledge management and capability building of all members of the CoE, thus providing a consolidated status to the CoE and plans to the senior management and stakeholders.

Towards achieving its objectives, the CoE needs to focus on the following areas:

Capacity Management: BA requirements for the complete planning year
Capacity Utilization: Optimal utilization of pool resources, based on complexity and sub-domain
Training and skill development: With distinct skill sets and knowledge levels across the BA CoE, it needs to ensure that training and mentoring is made available to all the members on a near continuous basis. The training focus should cover
- Fresh graduates being trained as BAs
- Junior BAs introduced to business domains and mentored on BA skills
- BAs trained on business domains prior to involvement in projects
- Senior BAs and BAs trained on mentoring skills
- Based on requirement, specialist certifications within the identified domains
Knowledge Management: Creating and maintaining a strong knowledge repository for the BA CoE, which can be leveraged for greater productivity as well as knowledge enhancement
Productivity Enablers: Effective, practical and simple to use BRD, FSD, Use Cases etc. templates are the productivity enablers for BAs. They use these templates at various stages of their day-to-day project and reporting activities. The BA COE should be the ultimate owner of all these templates.
Performance Management: BA CoE should facilitate the performance target setting and, coordinate the evaluation for the diverse groups across business and technology in ensuring measurement of quality delivery

Avoiding the Trap of Resource Pool

More often than not, a BA CoE is operated as a resource pool; where the focus is on end-user interfacing and delivery at the expense of capability building. Organizations have a tendency to measure the success of a BA CoE based only on the number of BAs deployed on productive engagements (internal or external). The success of BA CoE should also be measured by key productivity drivers like capability building and knowledge sharing.

Don’t forget to leave your comments below.