S/W Quality I

1. S/W Quality I Change Control Lesson 6

2. Change Control – Huh? • You might be asking yourself – What does Change Control have to do with Software Quality ? • In the scheme of overall Software Quality, Change Control encompasses: • Controlling and managing changes to the System through PM techniques • Changes to requirements (scope), changes in design, changes in cost, etc. • Controlling and managing changes to the System with the use of tools • Document change control, bug/incident tracking, release control, etc. • In short, Change Control within a system’s development and a project’s management refers to the effective and efficient method of managing change ! • It is a matter of : • Having the correct people and processes in place to document, control, schedule and manage the required change • Having the correct tools in place to help the developers, architects, support personnel and managers deal with change

3. Change Control – Huh? (cont’d) • There is quite a lot of confusion surrounding the ideas of Change Management, Configuration Management and Change Control when it comes to where each of these areas start and stop within a Project’s lifespan. • Some believe that Change Control involves the processes put in place to help avoid (control) any disruptive changes during a project by critically reviewing and approving them while Change Management are the processes and tools used to monitor and control the change if it is approved • For the purposes of this lesson, Change Control refers to the entire process of receiving a change or noticing the need for a change  reviewing and approving the change  folding the change into the project and monitoring it  having the change come into effect within the system (completion)

4. Change ControlChange Management Process

5. Change Management • We already examined this concept in Lesson 02 while looking at the Project Integration Management Knowledge Area – specifically dealing with Monitoring and Controlling Projects and Change Control • Even the best laid plans … • Are bound to change – and such is the case with most PM work • Once a project is underway, it is quite possible that the Project plans, requirements, staffing, etc. come under some sort of change • Typically changes can be grouped into recommended corrective or preventative actions • The key to not derailing the project and being able to complete on time is to • Expect this change and • Have the skills and processes in place to manage it

6. How to handle Change • If we were to break the process of change into multiple steps it would look something like this : • Record and Classify the Change • Assess the Change • Plan how the Change will be Integrated • Build and Test the Change • Release the Change • Close and Gain Acceptance of the Change • If you pause and think about the SDLC as you have learned it, you will realize that the recommended best practices of the SDLC itself define a baseline for controlling change as seen in this diagram …

7. How to handle Change (cont’d) • So what we need and want to focus on is really the process to be followed in achieving change through those 6 steps … • Knowing that a change may originate from the end-user customer or from within the project team, we need to be able to deal with each change • So again the steps to do this are : • Record and Classify the Change • Assess the Change • Plan how the Change will be Integrated • Build and Test the Change • Release the Change • Close and Gain Acceptance of the Change • Knowing what you know about PM and the SDLC can you tell me how you might follow these steps ? What would/could be done in the project to control the change according to these guidelines ? • Here is a flowcharted way of handling this process …

8. How to handle Change(cont’d) • You may now realize that this Change Management and Change Control are nothing more than • Having a predefined and documented process in place for handling change • Ensuring that everyone knows about the process • Ensuring that everyone follows the process during the Project’s life • In theory this sounds easy to do, however in practice it may not be . For example in a survey of 40 IT-based corporations, 60% (that’s 24 of them!) indicate that “their processes to handle change are not effective in communicating and coordinating changes occurring within their production environment”

9. On a side note : • Projects managed in a Agile fashion often times relinquish the idea of Change Control (in the avoiding sense) • They believe that if a customer wants/needs a change, then they shall have it ! How to handle Change(cont’d) • Here are some of the shocking statistics : • 95% reported that - Not all changes are logged • 90% reported that - Changes not thoroughly tested • 85% reported in a - Lack of process enforcement • 65% reported in - Poor change communication and dissemination • 60% reported a - Lack of centralized process ownership • 50% reported a - Lack of change approval policy • 40% reported they had - Frequent change notification after the fact • How can and does this happen ?? • It may be due to confusion between Change Management and Change Control • It may be due to the fact (as stated initially) that Change Control is often a process viewed as a means to avoid changes • And when changes need to occur, project team members cut corners and sneak around the process … • Regardless, there is still the need for a Change Control System for a project

10. Change Control SystemA Process for Managing Change …

11. Change Control System (CCS) • A CCS is a formal, documented process that • describes when and how official project documents may be changed • describes when and how ongoing project work may be changed. • describes who is authorized to make changes and • describes how to make the changes • A good CCS must • anticipate and plan for changes to come • accept and investigate change requests • plan for and integrate changes into an existing project • monitor the progress of changes • CCS’s tell us who can approve changes … • Some CCS’s assign this responsibility to a single person (the PM or Project Sponsor (a member of the Senior Executive whose budget this project is mainly coming out of) • Others recommend a Change Control Board (CCB) • Most CCS’s assign responsibility to different entities (people or teams) depending on the change • Please read the supplemental information in the Lesson References

12. Change Control From the Project Management Viewpoint

13. Change Control and the PM • We’ve just reviewed and recognize a recommended 6 step process in dealing with and managing change and we also now know that each project needs its own CCS … let’s examine this a little closer to see how things happen in the real world … • Uncontrolled change is one of the biggest foes of a PM • That's why a solid change management process (CCS) can be a PM’s best friend • Putting this kind of process in place enables you to deliver … • What the customer has requested (SCOPE) • In the timeline required (TIME) • And within the agreed-upon budget (COST) • The Triple Constraint ! • There – the connection has been made – the reason why PMs (and companies for that matter) need to have a documented CCS is to help manage the triple constraint balancing act … • Without change control, the project scope becomes a moving target and you are at risk of missing one or more of your project success factors • The ability to manage and control change, particularly that of project scope, is a key to reaching goals and a typical performance indicator for a project manager • Project change is inevitable and you must be prepared to deal with it when (not if) it happens !!

14. Change Control and the PM (cont’d) Balancing Change Management and Bureaucracy • One challenge for PMs is balancing the need to control project change while avoiding undue bureaucracy • The question is: Where is the tipping point? • Because every project is unique, the point at which change control stops adding value and turns into red tape will vary from project to project • Some of the stakeholders, or even the project team members, may feel that putting a CCS in place is the PM’s way of avoiding the dreaded scope creep … and that the PM is unwilling to be flexible and do what is best for your customer and the business • It's important to dispel this perception • Let them know that what the PM is doing is exactly the opposite -- implementing an efficient process for consistently evaluating requested changes • If making the alteration is deemed a good idea, then the processes in place to respond when needed The Project Change Management Plan • This is part of the job of the PM to have such a plan (like the Scope Management, Time Management and Cost Management plans) – the PM must document the CCS!

15. Change Control and the PM (cont’d) Putting a CCS into place and using it … • A PM should put their CCS into effect as soon as you create a baseline for key deliverables - such as the business requirements and schedule • The project team and stakeholders — and anyone else affected by changes in the project — should review and endorse the change management plan before you put it into play Assessing Requested Changes • Small changes that have little impact on the overall success of the project shouldn't entail the same rigors as those made to requirements or critical-path schedule milestones • The CCS must state when a formalProject Change Request (PCR) is required • For example: • What are the thresholds for schedule and budget changes? • Are there changes that always require a change request? • What alterations can the change management process skip?

16. Change Control and the PM (cont’d) Assessing Requested Changes (cont’d) • More about the PCR’s • One caution here … often it's lots of small-scope changes that do the damage, rather than the big, obvious ones • A PM should consider this when defining the PCR criteria • For example, your CCS should define different change request (CR) categories • Major changes • These should be documented as a PCR • Affect requirements or work items on the critical path, delaying significant milestones or the overall project end date by a certain time percentage or duration. Major change criteria should be defined for each project. • Require additional funding (in dollars or percentage of budget). Again, the amount should be defined for each project. • Minor changes • These routine changes don't require a PCR • Don't significantly affect the plan. They don't extend the completion date of milestones or tasks with project dependencies • Have no negative financial impact. No project budget variance will occur as a result.

17. Change Control and the PM (cont’d) Tips on Evaluating PCRs • The CCS should also include information about how change requests are evaluated • It's vital that the criteria for this evaluation be determined before it's needed so that time is not wasted reaching consensus • Setting these parameters will help balance change with overall business goals and benefits • Here are some typical questions to consider when evaluating a change request: • Does this change add to or alter the business requirements? • Is there a work-around, or is this change necessary for the overall success of the project? • Does this change require an increase in funding? • Will this delay the project end date? • Even though this change may have a negative impact on this project, does it result in significant business upsides that make it worthwhile? • Does enacting this change now make more sense than delaying it? Will the delay end up costing the company more money in the end? • Have all the affected stakeholders been considered, and do they endorse the change? • Are there contractual ramifications to consider? For example, will commitments with outside vendors be unfulfilled because of this change?

18. Change Control and the PM (cont’d) Approving PCRs • It's also important to define who can approve - or can't approve the requested changes • It's common to define various authority levels so routine changes can be dealt with efficiently, while significant changes receive the needed level of managerial attention • As was stated previously – sometimes we turn to the PM (individual) and sometimes we turn to a Change Control Board (CCB) – a team of technical, PM and Executive type people • In general : • When a PCR affects the scope of the project, you should consider it as a business decision that requires approval from the project sponsor • When scope is not affected, generally the PM has the power to approve the change within certain limits • For some projects, CCBs are created and convened on a regular basis to consider and approve change requests. There may be different change control boards in the organization, which handle various types of change requests (i.e. a technical change control board might look at technology issues only)

19. Change Control and the PM (cont’d) Approving PCRs • One easy way to summarize the guidelines for approving change requests is in a table like the one below, which is based on a typical project …

20. Change Control and the PM (cont’d) Approving PCRs (cont’d)

21. Change Control and the PM (cont’d) The Big Pay-Off • Project teams and PMs are always anxious to get to project execution … sometimes at the expense of effective planning • It's tempting to take shortcuts and assume you'll figure things out as you go. • Having a well developed CCS in place, before changes occur, will have big payoffs and better overall project results • By creating, documenting and agreeing on the CCS ahead of time, it takes the subjectivity out of change control and will enable the project team to handle fluctuations efficiently and effectively • A well thought out, detailed CCS that has been accepted by project team members and stakeholders will save project scope, time and money … … something that PMs never have enough of 

22. Change Control We need tools !

23. Tools to Help in Change Control • Okay – so we’ve just spent some time talking about • What Change Control is and what Change Management is • The need for a process to manage and control change • Now let’s turn our attention to the tools that can help us in this process • Specifically let’s look at what tools we as S/W Engineers may come across during a project’s life that are part of its Change Control System • Let’s briefly look at • Incident / Issue reporting and tracking • Software and System versioning and release control

24. Change Control Tracking and Reporting Incidents and Issues in the S/W

25. Incident and Issues • Keep in mind that Incident and Issue Tracking software is not only used for bug reporting, but can also be used for reporting, monitoring and controlling an enhancement (a change) being made to the system • Any good tracking and reporting software is aware of this fact and lends itself to your needs • Let’s have a look at a comparison of various tools out there that allow us to do this • Within the work I do outside of teaching, I have been exposed to many of these tools • JIRA at NCR , Tracs with my American Wholesale Lockbox work, and a less robust CRM with my Hospital work • You may recall from SEF and SAaD last year that tools like this play a big factor in the successful support of a system after initial release – when it enters the maintenance phase of the SDLC • If you’d like to review the SEF Lesson on Maintenance … here you go !

26. Incidents, Issues and Enhancements • The key to controlling and managing the reported defects in the S/W or the implementing of a change request - is an effective tracking system • As with any project, the key is to ensure you have the right tools for the job • Some key features to consider are : • A system that allows for the end-user to report the issue in enough detail to truly capture the situation that lead up to it • A system that allows for developers to report on their findings while investigating the issue • From a PM side of things, you would also want a system which allows for Issue Reporting and Issue Resolution reports to be generated

27. Change Control Controlling your S/W Releases –Version Control Systems

28. Version Control Systems • From large systems and projects (teams of hundreds of developers, architects, managers, support personnel) to much smaller systems and projects – there will always be a need to control and track the evolution of the system and the software • Bug fixes and improvements to existing software • Implementation of customizations to software • Actual implementation and development of software • In practice, you will often find that VCS’s are mostly used and heavily depended upon in the Maintenance Phase – seems to go hand-in-hand with defect tracking/resolution • Here is a comparison of some version control systems • But through effective PM techniques, VCS’s are also used in the process of Change Control and Change Management

29. Version Control Systems • As we learned last year in SEF, the purpose of revision control systems (version control systems) goes beyond simply managing the source code for a project. It can also be used for • Project documentation • Project Plans, Specifications, Status Updates, Minutes from meetings • Cost reports, Design Proto-types, etc. • Marketing materials • Installation programs, configuration files • The list goes on and on …

30. Change Control Summary

31. Hopefully the content in this lesson has opened your eyes to need for Change Management and Change Control within PM • In essence, these areas are used to manage and monitor • Changes in the scope of a project • Changes in the timing of a project • Changes in the cost of a project • The Triple Constraint discussed in Lesson 1 ! • Generally the processes of Change Control and Change Management are larger project-based processes but … • as a S/W Engineer, you always want to be aware of the use of such processes and follow them for any project you work on – don’t cut corners ! • (more importantly) be equipped and able to use tools to help in this management