COEPD – Center of Excellence for Professional Development Happy Learning
You need to accept change in business after a point of time where the same Business process, rate or production does not exist in the same form so we adapt and evolve with changes. Business analyst need to understand the business and accommodate the request of changes by the organization to the existing implemented process. Biggest challenge for BA is to study the complete project and make the changes without affecting the current project scope of any department modules.
To implement the change business analyst need to understand reason, impact and effort required. We can accommodate small changes which was a vision in previous implementation but for the big change requests in the project after making business analysis with project stakeholder’s and getting a clear facts it can be included in SOW.
Lets take an example for Agile Change request process and Sequential Waterfall Change request process for comparisons.
Examples: –
Agile Change request – Ecommerce projects
Agilist BA understand envolve that early investment in detailed documentation is waste of effort so in Ecommerce projects the BA will gather enough requirements envisioning to identify the Ecommerce project scope and first develop a high- level schedule and estimate for High priority requirements first.
Without active stakeholder and product owner(Business Anlayst) involvement the e commerce software development is at risk, sketch effective Mockup & prototype diagrams which captures a viable architectural strategy for the development team so that the impact of several changes in technical platforms are not not affected in the agile change process. Ecommerce Stakeholders have control over the budget, scope, and schedule and get concrete feedback on a regular basis from time to time before the sprint release. In Agile process there the Change request are also in form User Stories which are called as enhancements of next features print release. When Feature is developed the enhancements are future done in the next iteration sprint. Agile Unified Process (AUP) follows good rule of thumb is that a requirement must be implementable within a single iteration sprint not having major changes for the future. Complex change requirements which are approaching the top of the Agile stack on high & low priority and new change work items can be added in any next sprint iteration. Scrum suggests that you freeze the requirements for the current iteration to provide a level of stability for the developers in Ecommerce projects. If you do this then any change to a requirement you’re currently implementing should be treated as just another new requirement in the new sprint.In Ecommerce marketplace changes plays a major factor in ecommerce projects perhaps a competitor will release a new products which implements features that our organization product doesn’t have and hence change request becomes a very important factor for such projects in Agile mode to look into major business changes on the promo’s, version upgrades, design model and advance technology features for Mobile App, tablet App & Browser changes. Change request documentation processing work is less and quick in Ecommerce projects. Agile Change request supports mainly the Dynamic Business process Models where changes happens often in weeks & months.
Sequential – Waterfall Change request – Banking Projects
Banking projects have detailed BRD, FRD and SRS through a series of phases/ milestones and initial is requirement gathering and analysis is done in very effective way. New business analyst who comes in for making the change request can easy understand the flow process before having incitation for changes going through the existing documents because these type of banking product projects run for years and resources change from time to time. For current change request to the bank product we need less or no wireframes or prototypes because in banking projects its very rare on changing the major functionalities but requirements changes such as Interest rates, Loan rates or Legislation changes. Perhaps new legislation requires new features, or changes to existing features, in banking software product. The main focus is to see if the end user’s banking operational environment is stable. Risks of Change request schedule is very important factors are but low when compared to Agile Change requests significant changes requests in requirements during the bank project are high but unlikely to change since more time is given during the requirement phase. We should notify to customer & banking stake holders during requirements gathering, especially before final approval, that requirements’ changes in banking projects using the waterfall model can be very costly. There is only one phase or version release so after implementation a change request can happen. There is a board called “CCB – Change Control Board” which includes all project stakeholders which decides what can be implemented and how these changes can be implemented from both Clients or from what changes takes place in Banking such as recent changes in the Swift codes which is major Change request. In banking market the changes happens every quarterly / termly / Annually on interest rates and loan rates keeping mind the impact analysis to measure change to conclude on final Change request effort for implantation. Sequential waterfall Change request supports mainly the Static Business process Models where changes happens after Yearly and decades.
