Overview |  | Roles |  | Work Items |  | Views |  | CMMI |  | Index |  | Glossary |

Project Portal
| ### Next Steps Prioritize Change Requests |
| Analyze Change Request ( 2 : REQM : 1 : 1.3 ) ( 2 : CM : 2 : 2.1 ) Business Analyst
Activity: Analyze Change Request
Business Analyst
|  |  |  | Build |  |  |  | Stabilize |  |  |  | Operational Management |  |
|  | Participating Roles Responsible: Business Analyst Consult: Development Manager Project Manager Release Manager Solution Architect User Experience Architect Test Manager
### Overview A change request must be analyzed to determine the scope of impact on existing and planned work. Impact must be determined for the architecture, user experience, test, design and development, and end-user documentation. The impact in all of these areas is used to estimate the cost in person hours of implementing the change. This information is necessary before the change control board can meet and approve or reject the change request. # Entry Criteria Change request that is not analyzed. Change request that is not analyzed. Original proposed solution. Original proposed solution. # Sub-Activities
1 | Analyze Impact | Examine how many areas are affected by the change request. Large change requests are likely to impact other areas of the product aside from those directly affected by the change, such as the stability of the product, or time to release. Determine if any dependencies are affected by the change. Are there dependent components or contractual arrangements affected by the change? Try to quantify all areas of impact to assist the change control board. Which components are affected? Which design documents must be updated? What end-user documentation topics must be rewritten or created? More specific data will help when prioritizing and reviewing the change request. Analyze the risk of accepting the change. Are external teams dependent on the code or feature being changed, and could their schedules be adversely impacted? Could assigning resources to this change adversely impact other important feature areas or requirements of the product?
2 | Document Detailed Changes | Create documentation at the level of a functional specification describing exactly how the proposed solution will be implemented. Revise the original proposed solution attached to the change request. Consider creating a Microsoft PowerPoint slide deck for presentation at the change control board review meeting to make it easier for participants to review the change request.
3 | Review Before Submission | Review the change request with other team managers affected by the change request to glean more information. Specifically, consult with the development manager, quality assurance manager, user education architect, and release manager. Share and compare your impact assessment with other team managers to revise and improve your analysis.
4 | Record Details of Change | The details of the change request must be documented so that all team members can update their work appropriately. Identify work that will be cut, new work that will be added, and changes to make to previously specified functionality and features. Use the "Analysis/Impact" fields in the change request work item to record these details.
# Exit Criteria
| Change request that is analyzed for impact in different areas, and that has an estimated cost of implementation.
| Updated proposed solution with specification or Microsoft PowerPoint slide deck.
© 2005 Microsoft Corporation. All rights reserved. MSF for CMMI Process Improvement: 1.00.0000.00 |