As a business analyst, I’m often asked the types of daily activities that I perform and how I can best serve my customer.  First, and most importantly, Business Analysts (BA’s) are the customer’s advocate.  We’re the good cops. We’re the consultants who listen first, speak second and focus on the needs of the customer.  With that said, it is also our job to understand those needs and write testable requirements and associated artifacts to best convey the functionality of the system—both to the internal consulting team and to the customer.

We’re all human and change is inevitable, and that is no exception in a business analyst’s role.  Part of managing change from a BA perspective is to include a formal change request process (often called a CR) after base-lining requirements.  We do this for a few reasons:

1)     System of record.

1. A well-documented CR becomes a system of record for not only the description of the change but also why the change was needed, who requested the change, feedback on the proposed change, but also the historical record trail on when the change was submitted and ultimately, approved (both with the internal project team and customer team.)  Tip:   CRs also help if you are a consulting firm and need to charge the customer for the change and indicate the type of impact that the change will cause. We often refer to this as LOE or Level of Effort.

2)     People leave the project.

1. Without a CR, you may run into a “he-said/she-said” situation if folks leave the project.  To protect all parties (internal team and customer), you really need to document the change and provide details regarding the request for the change.

3)     Not all requirements management tools are equal.

1. Many tools such as Borland CaliberRM and Jama Contour provide BA’s the ability to make comments and automatically version requirements.  But, let’s face it. Adding comments to a change within a tool is something that all of us should do.  But, what if you don’t have an Requirements Management tool?  What if you only use Excel?  How many versions are you going to save?  How will the change be reflected? No matter if you are using a software tool or a manual process like excel, it’s very important to separate out the CR’s as separate artifacts and still document the change (via versioning and a note) within the software if you can.  Tip:  CR specific artifacts should also help with any CMMI documented policies and procedures you also may have, well.

4)     Our memories fade.

1. As BA’s we are not only a fountain of knowledge but the amount of knowledge that we have to consume and retain can be overwhelming.  We all cannot be expected to remember every little detail, so creating a well-documented CR will become extremely valuable, not only when new team members join the project, but as testing, roll-out and post-production support come into play.

Look for the next blog regarding a sample format for a Change Request Form.