Business Analyst vs. other project roles

      No Comments on Business Analyst vs. other project roles

A RACI table I created earlier this year as part of the Business Analysis team’s Service Level Agreement.   The purpose of the RACI and the SLA is to ensure that the other project team members know what the BA team will deliver for them and why, and what their responsibilities are to ensure the BA team can deliver.

Deliverables

PGB

PM

BS

SME

SP

SD

DM

ST

BA

OS

This agreement

I

A

C

I

C

I

I

I

R

I

The BA Team’s Work Plan

I

A

C

I

C

I

I

I

R

I

The BA Team’s Project Approach

I

A

C

I

C

I

I

I

R

I

BARD release 1

I

I

A

C

I

I

I

I

R

I

BARD release 2

I

I

A

C

C

C

I

I

R

C

BARD release 3

I

I

A

C

C

C

C

C

R

C

BARD release 4

I

I

A

I

I

I

I

I

R

I

Abbreviations: PGB = Project Governance Body, PM = Project Manager, BS = Business Sponsor, SME = Subject Matter Expert, SP = Solution Provider(s), SD = Solution Designers, DM = Data Modellers, ST = Solution Testers, BA = Business Analysts, OS = Other Specialists

RACI = Responsible, Accountable, Consulted/Contributes, Informed

The BARD documents are Business Analysis and Requirements Documents.  The releases align to the Initiation, Planning, Development and Closeout project phases of ECCC’s current Project Management Framework.  

We previously called the BARD the Business Requirements Document (BRD), but renamed it for two reasons:

  • Remove confusion with the BRD also required by SSC.
  • To clarify that the document was more than just a list of requirements, it was also an analysis of business needs, with recommendations / decisions for how the business would change it’s services.

The first release of the BARD focuses on identifying why the Business needs to change, and what new Business Services are needed, or what Business Services need to change.   This often helps determine the overall scope and impact of the changes needed.   Business Requirements (as in Requirements imposed on the Business as an organization) are captured in this release.

The second release of the BARD focuses on the Business Objects (typically data sets, reports, etc. at ECCC) and Processes that will enable the services.  This often helps determine if multiple projects will be needed to complete the change, and if multiple IM/IT solutions will be required to enable the change.  Stakeholder Requirements (as in Requirements imposed on the Stakeholder) are captured in this release.

The third release(s) of the BARD focus on modeling out the Business Processes and Business Objects in more detail (Activities, Tasks, Information Requirements, and the Domain Model).   This release is created in parallel to work being done on the Solution Requirements Specifications, and takes in to account how the IM/IT solutions will impact the workflow/process, and may impact how many Business Objects are needed.   There may be multiple third release type documents, typically prioritizing the development of each sub-release to detail what’s needed for the IM/IT solution to be implemented.

The forth release focuses on ensuring alignment with what was designed and built, e.g. final tweaking of business processes to show how the IM/IT solution will be used, addition of data fields to business objects added because an IM/IT solution was used.

I’ll plan to write several future blog entries on the BARD documents, and how we create it out of Sparx EA.

 

 

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.