sidz832002

 Profile Answers by sidz832002 

• Jan 12th, 2010

 

Firstly, I would keep track of each and every change that is occuring. I would even stoop down to the level of creating a spreadsheet which contains the following elements:

Column 1: Proposed Change

Column 2: Date and Time

Column 3: Which person Proposed this Change

Column 4: Requirement Number

Column 5: Original requirement  Text as on Day 1.

These columns could be in a different order. It might be a robust exercise to maintain such a record for all the requirements but bare in mind that if the requirements are changing rapidly, It could be because of a system defect or limitation and not a business decision. since the Business Users more often than not nail down their requirements with detailed discussions. Its the technical shortcomings that prompt a constant change in the requirements.

Ruchita

• Aug 5th, 2011

 

As a business analyst, I would prepare a protocol which indicates that after certain period of time, no changes in the requirements would be entertained as that would effect the entire system and get it signed off from the users.

Ruchita

• Aug 5th, 2011

 

Prepare a protocol which says that changes wont be entertained after a certain period of time and get it signed off by the users.

Milind Choudhary

• Nov 9th, 2011

 

Change in requirements is a common element in project these days, especially when it is Agile or Iterative way of development. Therefore, it is imperative for a BA to manage requirements. One of the most important element of requirements management is also to manage change.

I would suggest to have a change process defined at the beginning of the project. One can define templates and the actions and responsibilities of both internal and external stakeholders. This process should be communicated and mutually agreed upon with the customer.

Thereafter, any change referred by customer should be recorded in these templates. However, change could have one or more of the following actions:

1. Change affects the current system and therefore time and cost is impacted
2. Change affects the current system requires time but can be absorbed in the same cost
3. Change does not affect the system but is an extension, should be estimated separately

BA has to perform impact analysis with the Tech architect to understand the change impact.

Abhishek

• Mar 28th, 2012

 

Changes are important part of business improvement process.

A) First and foremost the change needs to be classified. Ie:
1) Is the change a functional or technical in nature?
2) What is the value of change in terms of time saved and convenience?
3) How often is the impacted functionality used?
Classify as: Must have, Required, Nice to Have

B) Impact Analysis: High, Med, Low
C) Estimate
D) Prioritize and decide

Vimal

• May 11th, 2012

 

In my view, change requests are part and parcel business improvement and business analyst has to understand what changes that users are requested and he should also analyses impact of the proposed change. If any change requested by user which is mandatory, then we have to implement the change in next release of product and make sure that the change should not affect/hinder the normal performance.

Samraat Jadhav

• May 21st, 2012

 

Use Requirement Management Tool for change management

sureshvegi

 Profile Answers by sureshvegi 

• Jul 23rd, 2012

 

initially we will take singn off from the client on the documents,in that it will be made clearly that whether the client will propose the changes in middle of project or he will never propose changes in mid.if they agree for propose their changes when ever they need ba has to except it and should analyze those requirements and has to find any risks in changing those requirements,and after finding we have to inform to client about those sequences and increase of project time and budget ,if clients agrees for that we can go through it.but it is very tough task.and BA has to made clear about the requirements to design,development and testing teams,he has to conduct joint sessions with all the teams and explain wat the requirements their client needs.he has to be with them along the project still project sign off take from client.

Ben

• Apr 28th, 2013

 

I think you should set hard deadlines, and once that deadline passes no new submissions to the plan can be made. That way everyone knows when the work needs to be finished by and things dont keep changing all the time. If you have to keep managing change things will be in constant chaos.

Ramesh Naidu

 Profile Answers by Ramesh Naidu 

• Aug 14th, 2014

 

Customer suppose to change requirements. most of the customers are may not be aware on what they want actually. as a business analyst we have to identify the nature of the customer and as per that we have to mold as per customer point of view. we have to give a clear idea to them, if they missing any requirements or changes in the requirements. Now they got awareness on business process what we implementing.

we have to follow some techniques here :

1) Keep listing what client says
2) write it down in a paper in every discussion
3) compare the changes in every discussion
4) explain the nature of work what we follow
5) give a optional way to customer what we need from them
6) took a requirements by brain storm, interviews from real working person
7) ask n number of questions on domain related
8) if you follow above steps, you can get maximum requirements from client.
9) final day you have to intimate no more changes in particular time period. if you want it, you have to take care of commercials and time bound.

G Rameshnaidu
Business Analyst

patelmitesh07

 Profile Answers by patelmitesh07 

• Sep 20th, 2014

 

Most of the businesses stepped into the agile methodology to improve their system, so request on requirement change definitely comes in picture.as per my knowledge we should rectifies the below areas prior to action on it.

1) Priority of the change request(can be categorized by Critical,High,Medium,Low)
2) change Type
3) Business Impact
4) Risk (at business perspective,technology perspective and other)

if request is critical for example, high volume of business user impacted then worth to proceed for fix by making quick decision on implementation.where actual expertise required. else change will be implemented with the scheduled release plan.

If were talking about the system going to implement with waterfall model then following items will be consider :

1) whats change ? whether its a small and can reach deadline by doing such without big efforts or its major change which impact the existing implementation and will be time consuming.
2) revised efforts
3) delay in release due to enhancement.

amarsinghchauhan

• Dec 1st, 2014

 

You should update your according to changing products sales after sales service claim selltement and reinsurance you should provide resent knowledge to team mates

Awais

• Dec 19th, 2014

 

All the changes should be properly managed through change control procedures

Sree Lakshmi Kurra

• Feb 13th, 2018

 

a. Keep project tasks different from feature requirements.
Project management software tool JIRA can be/was used to manage and track projects. This project will be treated separately from the on-going project activities. This separation will help us identify which requests can be implemented as a part of project without delaying final shipping or causing cost outruns.
This will also help in recognizing the track changes in the project

b. Implement a change approval process and change log.
This is a Good way to record and track all change requests in a change log. This log becomes a centralized source of information. Also inform stakeholders about how, once the change of requirement is submitted, the communication process with the dev team will have to take place to make a decision.

c. Online communication and collaboration tools (web conferencing, file sharing and message boards) can be used to make sure that the stakeholders and the analyst are on the same page.
Keep a track of everything (proposed change, data and time, who proposed this change, requirement number, original requirement as of day1)