1. Fundamental of Software Project Management
Team Assignment 3 – K15T2 – Team 07

2. Outlines
Part 1: Change Management Plan
Part 2: Risk Management Plan

3. Change Management Plan
1. Purpose
Change Management Plan is to coordinate changes across the entire project. The plan will address how the project will ensure that the changes are beneficial, determine how the change will occur, and manage the changes as they occur.
2. Goals
Change Management Plan:
Reasonable change activities are planned.
Changes are identified, defined, evaluated, approved and tracked through completion.
Project plans are changed to reflect the requested changes.
Changes are negotiated and communicated to all affected parties.

4. Roles and Definitions Role Definition Support Manager
The individual responsible for managing the Change Management activities of the team, also known as the ‘process specialist’
Change Control Board (CCB)
A group who is responsible for reviewing change requests for approval or disapproval. For Big Goal it is the whole team, and necessary changes are discussed during the weekly team meetings.
Client
The agent representing the client's interests in a particular configuration item.
Originator
The individual with whom a change request originates and the person informed when the change request is closed-out or deferred to the Change Control Board.

5. Change Control Process

6. Outlines
Part 1: Change Management Plan
Part 2: Risk Management Plan

7. Risk Management Plan Purpose Participants Roles and Responsibilities
The purpose of this document is to keep track of the risks that have been identified and prioritized by Big Goal. Since the Big Goal team is taking a risk driven approach to the project, the list of these risks that will be used as a guide to strategy and planning.
Participants Roles and Responsibilities
Project Manager (PM)
Risk Manager/ Plan Manager
Risk Analyst
Project Stakeholders and Vendors

8. Risk Management

9. Risks List Impact: High (H): schedule delay more than one month
Middle (M): schedule delay between two weeks and one month
Low (L): schedule delay less than two weeks
Probability:
High (H): 90% +
Middle (M): 51% - 90%
Low (L): 00% - 50%
Timeframe:
Near: next 1-2 weeks
Mid: next 3 weeks
Far: > 1.5 months

10. Risk Assessment: Cycle 1
Impact
Possibility
Time- frame
Schedule
No plan for class H
Near
Delayed schedule
The release of specification is delayed
Estimate the time is too far from real
Customer
Change Requirements or Addition requirement
Organization and Management
Not fully reviewed documents L
Not determined customer scope
It's academic project (it's ok even project fails)
Team leader cannot control and motivate the team member
Development environment
Not determined development environment M
Requirement
Team does not understand requirement clearly.
Personnel
Unskillful members - TSP
Inexperience in tool of the project
Unskillful members-programming skill
Communication with other team members
Mid
Absent the team meetings
Lack of time on Class
Design and Implementation Design and Implementation
Developing the wrong user interface
External environment External environment
No place available for team meeting
Process
It is hard to follow TSP practices

11. Risk Assessment: Cycle 2
Impact
Possibili ty
Time- frame
Our plan is too aggressive H
Near
Lack of design skill
Many artifacts
Middle
Unfixed functional scope
Communication problem among team members M
Development Environment I

12. Risk Management

13. Risk Management Process

14. Risk Management Process

15. Risks Mitigation
Risk Mitigation Plan for inexperienced in tool o f the project (Nokia Ovi Suit)
Training schedule for using Nokia Ovi Suit
Five of the members took a research about the software Nokia Ovi Suit classes for 1 week.
One member had experience with Nokia Ovi Suit.

16. Risks Mitigation Unskilled members in TSP: Recovery activities
Conducting Launch for learning
Reading TSP materials such as Introduction to TSPi an d Introduction to PSP
It is hard to follow TSP practices
Prevention activities
TSP process training for team members

17. Risks Mitigation Risk Mitigation plan for the lack of time on Class
Review of summary sheet about timetable.
Analyze the timesheet every week.
Ask members about the progress of Studio project
If necessary, the person incharge sends an update after analyzing reasons
Until the risk is much mitigated, the charger reports the status document about the Class time of members

18. Identify and Track Risks
The level of risk on a project will be tracked, monitored and reported throughout the project lifecycle. Big Goal team identifies and tracks risks every week through status meetings.

19. Thanks for your listening !