23/04/17

CKIT521 - Managing the Software Enterprise

[MANAGING CHANGE IN IS]

Change in IS Development Project (ISDP)
According to Lehman (1980), change is integral and continuous in ISDP. System
requirements changes and system is fault-prone are two key causes of change during
software development (Ince, 1994). Also more knowledge about the clients need, system
enhancement and maintainability requirements can cause changes to existing software.
These changes, if not properly handled, affects the triple constraint (time, scope & Cost)
and quality (Moghaddam, 2012).

Figure 1: (PMBOK, 2013)

Scope deals with project deliverables, schedule is time required for project completion,
budget is total cost to project completion and quality deals with customer satisfaction on
IS projects (PMBOK, 2013).

In order for these changes to not hinder ISDP, Integrated change management process is
adopted to review, manage and control changes.

Change Management (CM)

CM is process designed to document, plan, implement and control changes that might occur
in IS projects (Lehman, 1980; PMBOK, 2013). These are procedures that are defined and
implemented to handle all changes that might occur and hinder success of IS development
projects

CM Objectives
CM ensures

1. That documented procedure is followed

2. That impact of change to software and project is assessed diligently
3. That completion and accuracy of project scope before/after change implementation
is verified (PMBOK, 2013)

1|Page
CM Steps
Steps in change management are highlighted below

Figure 2: (Sych, 2011)

1. A change is identified and a request for change is raised

2. The impact analysis to software cost-risk & entire project is analyzed (PMBOK,
2013)
3. The change is approved/Denied
4. If change is approved, then project plane is re-baselined and change implemented
(Moghaddam, 2012)
5. Reviewing, monitoring and reporting the change

CM Control
Controls that were put in place to ensure that the CM process is adopted and standardized

1. All changes must undergo the CM process

2. All changes must be detailed and logged in Software Problem Report (SPR)
3. All changes must be evaluated for impacts to software and project and prioritized
4. All changes will needs to be approved/denied before change closeout
5. All Approval/Rejection should be properly documented
6. Upon closeout, all project baseline must be updated to reflect the change.
7. Change Control Board (CCB) must be put in place

Integrated Change Management Process (ICMP)

The planned and controlled sequence of activities carried out based on steps highlighted
above in order to apply change management to a project (Lehman, 1980). CM is defined,
documented and implemented to ensure order, discipline and waste minimization during
ISDP. The Project Management Institute also encourages the use of ICMP in managing and
controlling changes that could occur in projects (PMBOK, 2013).

2|Page
Figure 3: (BMP, n.d.)

The procedures are

1. Identify the problem and log in Software Problem Report (SPR)

2. Conduct a technical review of change and impact to software ISDP
3. If change is valid and critical, then approve else hold for later review or archive (
BMP (n.d.)
4. If archiving, inform change originator and close-out change
5. If change is approved by review committee then change request is raised

3|Page
 6. Determine if CCB is required for approval based on magnitude of change
7. If not, implement, verify change has been implemented and update project plan
8. If yes, CCB will review and analyze change request and impact analysis and give its
approval (iri. & Rakovi, 2010)
9. If CCB approves change, implement, verify change has been implemented and
update project plan
10. If not, archive change
11. Inform all change originator, stakeholders and close-out change request
12. Changes should be closed-out, documented in SPR and communicated to all
stakeholders when properly implemented

Change Control Board

Change Control Board (CCB) is constituted to make strategic judgments and includes all
stakeholders who are impacted by the project and will periodically have meetings on
approving or rejecting changes (iri. & Rakovi, 2010).

Conclusion
In conclusion, CM plays a contributory role to the success of IS development projects.
Project control can be lost if a clear process for change management is not defined
(PMBOK, 2013). According to Collofello & Buck (1987), 50% of all ISDP errors were due to
changes made previously, so it becomes more essential to ensure a planned and controlled
CM such as described above is in place to help review, evaluate, monitor and implement
changes and also enhance risk assessment (iri. & Rakovi, 2010) for a successful ISDP.

References
Lehman, M. M. (1980) 'Programs, Life Cycles, and Laws of Software Evolution', PROCEEDINGS OF THE
IEEE, 68(9), pp. 1060-1076.

Ince, D. (1994) Introduction to Software Quality Assurance and its Implementation. New York, NY:
McGraw-Hill, Inc.

Sych, A. (2011) IT Change Management Software. [Online] Available From: https://novosolutions.com/it-

change-management-software/ (Accessed: 21 April 2017)

Moghaddam, A. G. (2012) 'Change Management and Change Process Model for the Iranian Construction
Industry', International Journal of Management and Business Research, 2(2), pp. 85- 94.

PMBOK (2013). PMBOK Guide, 5th ed., Newtown Square, PA: Project Management Institute.

iri, Z. & Rakovi, L. (2010) 'Change Management in Information System Development and
Implementation Projects', Management Information Systems, 5(2), pp. 23-28.

4|Page
Collofello, J. S. & Buck, J. J. (1987). 'Software Quality Assurance for Maintenance', IEEE
Software, 4(5), pp. 4651.

BMP (n.d.) Step 4: Invoke Configuration Control (Configuration Management Plan / Procedures) [Online]
Available From: https://novosolutions.com/it-change-management-software/ (Accessed: 21 April 2017)

5|Page