Gathering requirements for large-scale enterprise projects impacting a multitude of business processes and systems across an organization poses a unique challenge for Business Analysis (BA) Professionals. If you are lucky enough to work in a mature organization with a defined project and resource structure, the pain of coordinating activities with other BAs may be somewhat alleviated. If you are part of a more informal environment, the challenge of staying in synch can be a daunting endeavour for sure. In alignment with the BABOK^® Guide v3, this article provides common sense tips for BAs to effectively manage requirements with other BAs on large projects with a "Parent" and "Child" structure.

 

Let us use a simple example. According to company policy, any field referenced as "Maiden name" must now be changed to a new field entitled "Former Last Name" on all forms and systems. Although this is only one field, it impacts various data entry, data transfer, and reporting systems. What if each of the impacted systems and related business process have different BAs assigned? What is the best way to coordinate with each other and with the stakeholders?

 

It may sound simple, however, over the years, I have seen these types of projects fail on some level. There is always at least one BA representing an "essential" system who was inadvertently left out of the loop. And in worst case scenarios, this can result in the entire project coming to a screeching halt until changes for all impacted systems are "Go." As a result, below are a few tips that may help BAs avoid pitfalls common to larger initiatives with many BAs assigned.

 

Someone has to run the ship. One or more lead BAs should be assigned to all enterprise projects owning the "Parent" level within the project hierarchy. This will ensure that all impacted business processes and systems are clearly identified and that all project BAs at the "Child" level are assigned and accountable. The lead BA should also cover logistics such as where documentation will be stored, how changes will be communicated, and what the clear deliverables for each system or business process will be. The lead BA and project BAs should work together in order to determine the best way of laying out and organizing the requirement structure for each project. For example, should requirements be organized according to business processes or by systems or a combination of both?

 

As stated in the BABOK^® Guide with respect to the maintenance of requirements, the BA will need to ensure “accuracy and consistency throughout and beyond the change during the entire requirements life cycle.”[i]  If you do not have a robust business analysis tool, you will need to create a centralized and organized structure for "Parent" and "Child" BRDs. These documents should clearly cross-reference each other with the level of detail differing depending on whether it is "Parent" or "Child" BRD. For example, the "Parent" BRD should capture the high-level summary at enterprise level while the "Child" BRD drills down on specific requirements at the detailed system and business process level. The "Parent" BRD should also reference all of the BAs involved in the project, roles and responsibilities as well as the specific system or process they will be accountable for at the "Child" level. Using consistent naming conventions and references across BRDs will also help to maintain organization throughout the course of the project (i.e. centralized data dictionary at the "Parent" level). Also, be sure to avoid duplication and redundancy. For example, the "Parent" BRD may have detailed information regarding the "Business Need" that does not need to be repeated for each "Child" BRD. Cross-referencing can be applied effectively with a simple use of "refer to Parent BRD" where appropriate. (I know a lead BA who actually creates the template for "Child" BRDs with this type of information already pre-populated for consistency across the program).

 

The importance of maintaining traceability across the "Parent" and "Child" requirement structure cannot be emphasized enough. This clearly supports the BABOK^® Guide statement to ensure “that requirements and designs at different levels are aligned to one another, and to manage the effects of change to one level on related requirements.”[ii]  Again, if you do not have a tool that provides automated traceability, then all requirements in the "Child" BRD will need to be manually mapped to the "Parent" BRD to ensure coverage across the enterprise. This will help immensely if a requirement at the "Parent" level changes. Once this structure is in place, the project BAs will have an easier time identifying the source of the change and updating their "Child" BRDs accordingly. If your current BRD template does not have a column for traceability to the "Parent" BRD Requirement – just add it. Example Below:

"Parent" BRD

Req. #	Requirement
Requirement A01	Effective January 1, 2019, field "Maiden Name" shall be changed to "Former Last Name"

 

"Child" BRD

Req. #	Requirement	Traces from Parent BRD
Requirement B01	System A shall change "Maiden Name" to "Former Last Name" on Customer Screen	Requirement A01
Requirement B02	System A shall change "Maiden Name" to "Former Last Name" on Verification Screen	Requirement A01
Requirement B03	System A shall change "Maiden Name" to "Former Last Name" on Customer Report	Requirement A01

Identifying stakeholders is a tricky one – especially if they overlap across business processes and systems. A clearly defined communication plan for all assigned BAs should in place well before the project begins. You want to ensure that multiple BAs are not communicating the same status to the same stakeholders in a redundant manner. In many cases, it makes sense for the lead BA to have the master list of stakeholders and the assigned project BAs who will be communicating with those stakeholders. Also, the lead BA can help to mitigate any conflicting stakeholder issues that may occur across the enterprise. In addition, project BAs need to be diligent about reporting any issues up to the lead BA – since it may impact deliverables at the "Parent" level. In the case of the stakeholders, it is imperative that their time is used efficiently. For example, if a certain stakeholder needs to be consulted for several systems represented by different BAs, the BAs should hold a combined elicitation session rather than separate ones. This approach should be covered when finalizing your “Elicitation Activity Plan” whereby the logistics, scope, techniques and supporting materials are clearly defined – particularly as they relate to stakeholder engagement.[iii]  This prevents the stakeholders from providing the same or similar requirements repeatedly to the various BAs assigned on the same project.

 

Working on large initiatives involving many systems, business processes and BAs will be extremely effective if thoughtful effort is expended during the planning stage. It is well worth the endeavor to devise a solid strategy and structure for the lead and project BAs to adhere to. Throughout the course of the project, it is also imperative that communication between the lead BA, project BAs, and stakeholders remains open and is not trapped in a silo. Furthermore, documentation, traceability and stakeholder management must remain clear and consistent on all levels.

 

For business analysis professionals, collaboration skills are second nature as we constantly mediate issues between stakeholders and a wide array of project resources. Large projects involving many BAs provide us with a rare and exciting opportunity to effectively collaborate with each other to achieve successful results. With careful consideration, we can use enterprise projects to build upon and improve the BA network while contributing to the collective good of an entire organization. During these times, the phrase "strength in numbers" comes to mind!
 

 

[i] BABOK^® Guide v3, Section 5.2.1, “Maintain Requirements”, page 83 - 86.

[ii] BABOK^® Guide v3, Section 5.1.1, “Trace Requirements”, page 79 - 83.

[iii] BABOK^® Guide v3, Section 4.1.1, “Prepare for Elicitation”, page 56 – 65.