The role of a ba in a vendor software solution
1 / 26

The Role of a BA in a Vendor Software Solution - PowerPoint PPT Presentation

  • Uploaded on

The Role of a BA in a Vendor Software Solution. Sharon Ashton Mathew Stordy. Agenda. Review Goals & Objectives Technology Decision & Purchase RFI/RFP Contracts/SLAs Building a Solution Requirements Design/Build Test/Train/Deploy Steady State Lessons Learned & Perspectives.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'The Role of a BA in a Vendor Software Solution' - laken

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
The role of a ba in a vendor software solution l.jpg

The Role of a BA in a Vendor Software Solution

Sharon Ashton Mathew Stordy

Agenda l.jpg

  • Review Goals & Objectives

  • Technology Decision & Purchase

    • RFI/RFP

    • Contracts/SLAs

  • Building a Solution

    • Requirements

    • Design/Build

    • Test/Train/Deploy

  • Steady State

  • Lessons Learned & Perspectives

Goals objectives l.jpg
Goals & Objectives

  • Share our experiences from two perspectives, as a Client BA and as a Vendor BA, in case study format

  • To review the unique aspects of the BA role within

    • Client organizations

    • Vendor organizations

  • Review an enterprise software implementation

    • Recognize the current and strategic role of the BA

    • Lessons Learned – How can we “do this better?”

So you need to choose a technology l.jpg
So you need to choose a technology?

What is your Business Case?

  • Assessing your key Business drivers

  • Addressing Business Process improvements and/or efficiencies

  • Technology refresh drivers

  • Ultimately, need to decide buy, build or modify existing

    • Determine your ROI - provide cost estimates

    • Consider exit strategy

So you need to choose a technology5 l.jpg
So you need to choose a technology?

You decide to buy new….

  • Documenting your requirements

  • Identifying vendors

  • Sending out your RFI (Request of Information)

  • Reviewing and determining your “short list”

  • Sending our your RFP (Request for Proposal)

You ve decided to purchase l.jpg
You’ve decided to Purchase

  • The Client BA creates an RFI to assess:

    • Experience level and depth of knowledge of potential vendors

      . . . Credibility is key

    • Product capabilities and alignment with the business case

    • Software development processes, procedures and tools

    • Quality checkpoints and testing approach

  • The Client BA helps assess the resulting RFP’s

    • Key role in business functionality traceability

    • May be asked for input into contractual questions, service level metrics, etc

Vendor ba selection support l.jpg
Vendor BA – Selection Support

  • Formal Roles

    • RFI/RFP process

    • Demo and Evaluation phase

    • Sales support

  • Implied Roles

    • Provide clarity around organization goals or problem statements

    • Identify a viable solution

    • Assessing the risk associated with a prospective sale

    • Address the diverse questions\concerns raised during the sales process

Client ba contracts and sla s l.jpg
Client BA: Contracts and SLA’s

Area’s to watch

  • Cost estimations

    • Business Capabilities

    • Managing the customer’s expectations

  • Communication Plan Items

    • Relationship Meetings

    • Operational meetings

    • Problem and enhancement protocols

  • SLA’s

    • Validating metrics on quality and timeliness

The sdlc system development life cycle l.jpg
The SDLC (System Development Life Cycle)

  • The Project Charter

  • Communication Plans

  • Roles and Responsibilities

  • CMMI certifications etc.

  • PMO’s

    Vendor BA perspective…..every client brings a different

    view of the SDLC, the vendor has to be flexible….The joint

    team needs to look at the project and must agree to a

    process that works for all

Requirements client v vendor view l.jpg
Requirements: Client v. Vendor View

  • Eliciting Requirements – Access to Stakeholders

    • Client – Primary Access

    • Vendor – Secondary Access

      Usually through Client BA, Project Manager, or project


Requirements client vendor view l.jpg
Requirements: Client & Vendor View

  • Documenting Requirements

    • Key Terms and Definitions must be agreed to early on

    • Sign off from key stakeholders critical

    • Use common business language

    • Be comprehensive

Requirements client v vendor view12 l.jpg
Requirements: Client v. Vendor View

  • Sign-Off is used to finalize & clearly define scope

    • Client responsibility

      • Ensure the needs of the organization are met

      • Within budget and on time

    • Vendor responsibility

      • Ensure the needs of the client organization are met

      • Protect the interests of the vendor organization

    • Joint inspections & walkthroughs are critical

Vendor ba design l.jpg
Vendor BA: Design

When designing and\or collaborating on a new software

solution, the vendor BA must consider the following:

  • Meeting the needs of the client\solution

  • Development Costs

  • Future Market Potential

  • Future Maintenance Costs

Client ba design l.jpg
Client BA: Design

  • Recognize the strategic role your software plays in the business plan and technology portfolio

  • Understand scale

  • You must get into their “story/business”

Vendor ba build l.jpg
Vendor BA: Build

  • Provide continuing (daily) support to the Dev Team

  • Identify and escalate any misalignment in:

    • Solution direction

    • Resources alignment

  • Implement and coordinate configuration changes

  • Unit Testing support

Client ba test l.jpg
Client BA: Test

  • Functional Testing

    • Data Profiling and its importance

    • Test Strategies, Test Plans, Testing Matrices

    • Test cases

    • Timing of artifacts (test plan, test matrix, etc…)

    • Issues regarding allocation of resources

  • Integration Testing

    • Integrated with every corporate system

  • User Acceptance Testing

    • Alignment with “book”

  • Performance Testing

Bas joint test l.jpg
BAs Joint: Test

  • Automated Testing Tools

    • Synchronizing vendor and client frameworks

    • Sharing of test scripts

  • Perimeter environments

    • Interface concerns

Training l.jpg

  • Vendor

    • Typical role is to train the trainer.

  • Client

    • Typically primary trainer

    • Needs to be cognizant of implementation goals\objects

    • Must leverage client organization’s investment

  • Joint

    • Manage end user perceptions

    • Documentation

    • Delivery

      • Demos, WebEx

      • CBT’s

      • Manuals/User guides

Deployment l.jpg

  • Performance Test

  • Execute upon predetermined “roll out schedule

    • Will you roll out all at once?

    • Will you consider a pilot and if so…what locations?

    • Will your roll out be date driven?

    • What about data conversions?

      The BA is a key expert in all the above decisions

Client ba vendor ba in steady state l.jpg
Client BA & Vendor BA in Steady State

  • Concerns

    • A new team?

    • What will be our “day to day” roles?

    • Enhancements

    • How do I keep my documentation up to date?

  • Communication Types / “Rhythms”

    • Weekly Meetings - Tactical

    • Quarterly Operational Meetings

    • Yearly Strategic Relationship Meetings

    • User Groups

    • Advisory Councils

How can we do this better l.jpg
How can we do this Better?

  • Create a WIN-WIN atmosphere

  • Create a common vocabulary

  • Align Products and Services

  • Ensure teams compliment each other

  • Communicate Often

Patricia shea executive vice president and cio sparta insurance l.jpg

The Business Analyst function is critical to the success of any systems implementation. Their ability to understand the business process and systems design creates a more efficient process and improves the communication within the project.”

Patricia Shea

Executive Vice President and CIO SPARTA Insurance

Todd ellis cio chubb commercial insurance l.jpg

Todd Ellis

CIO Chubb Commercial Insurance

“Many companies elect to strategically source or purchase systems/solutions from software vendors to address critical business needs. To ensure the needs of the business are truly met and mitigate project and financial risk, these companies rely heavily on the role of the Business Analyst.”

David pedersen president of insurity l.jpg

David Pedersen

President of Insurity

“Replacing core systems within an insurance company can be compared to open Heart surgery, whereas consequences for getting it wrong can be devastating. The BA plays a significant role in ensuring the project's success helping the company realize the desired benefits: efficiencies, scale and/or improving customer service. Vendor BAs have the benefit of participating in multiple projects every year and can bring significant experience to any engagement. The quality of that BA to BA interaction between carrier and vendor corresponds directly into the quality and effectiveness of the project. Insurity considers the BA a significant and strategic role which drives our ultimate success as a trusted partner to our customers.”

John pettit president of adaptik l.jpg

John Pettit

President of Adaptik

“BA's are our most valuable form of risk management for a project. Their natural analytical capabilities, vast domain expertise and rich experience conducting multiple software implementations enables them to very quickly ascertain the key project risk factors that will be impediments to the project’s success. They recognize customer staffing/skill gaps, missing requirements, and unrealistic implementation time expectations, as well as issues related to our ability to execute our tasks within the project. This allows us to engage the customer in discussions regarding the projects potential risks early in the project avoiding costly mistakes.”

Discussion l.jpg

  • Q & A