{"id":1985,"date":"2009-04-09T10:42:46","date_gmt":"2009-04-09T17:42:46","guid":{"rendered":"https:\/\/svapm.org\/?p=1985"},"modified":"2019-08-07T14:31:46","modified_gmt":"2019-08-07T21:31:46","slug":"practical-change-management","status":"publish","type":"post","link":"https:\/\/svapm.org\/?p=1985","title":{"rendered":"Practical Change Management"},"content":{"rendered":"<p>That requirements will change is a given.  How you plan for and manage that change is crucial.  Think about what you want to accomplish with your change management, what you want to protect yourself from, what you want to avoid, and then put in place the practice that makes sense for you.<\/p>\n<p>Having a tool that will<br \/>\n\u2022\tallow anyone to enter a change request<br \/>\n\u2022\tmaintain information associated with the change to help with its evaluation<br \/>\n\u2022\ttrack the request<br \/>\nis a good start, but not sufficient.  <\/p>\n<p>You must also have a process in place to<br \/>\n\u2022\treview and triage change requests, evaluating both their importance and impact (to schedule, ultimately)<br \/>\n\u2022\tplace the accepted requirement changes (or new requirements) into the requirement baseline for the proper release<\/p>\n<p>The triage and evaluation are usually done by committee, with some preliminary evaluation done by someone who understands the change and\/or the impact.  The \u201ccommittee\u201d part of this practice makes it look complicated and heavy, but having a review team (usually called something like \u201csoftware change review board\u201d or SCRB) meet regularly isn\u2019t all that onerous.  We used to meet once a week, but there were times when there weren\u2019t change requests, only bug reports (which were handled by a similar process\/team), and so we didn\u2019t meet.  When more frequent meetings were necessary, we held them.<\/p>\n<p>The team should consist of a representative of each stakeholder group.  In our case, we had QA (running the meeting), Engineering management, Technical Support, and Product Marketing evaluating changes.  It\u2019s very important to have input from those who can evaluate the effort needed to implement a change and the impact on the rest of the system.  Often there will need to be a tradeoff between doing this change or new requirement and doing something else.  So that means that engineering representation is very important.  Product Marketing is the organization that will be able to evaluate the importance of the change to the ultimate customer.  So their input is important as well.<\/p>\n<p>But if it makes more sense, you could create a process that has only engineering meeting regularly, with the other disciplines weighing in on request.  Again, evaluate what makes sense for your situation, and if you find a need to change the process later, do that.<\/p>\n<p>When there\u2019s no need to meet, don\u2019t meet.  When you do meet, make sure that the meeting is managed so the discussions don\u2019t go off track and so that detailed evaluations can be done offline.  Emergencies don\u2019t need to wait until a regularly scheduled meeting.  Just call a meeting (or handle it via phone or email, as an exception).<\/p>\n<p>Don\u2019t let the notion of a \u201cprocess\u201d be a reason to not manage changes.  Think of the real purpose of this \u2013 to avoid &#8220;scope creep&#8221;, to be sure that changes aren\u2019t introduced without a really good reason, to understand and evaluate the change, to see how making the change affects the schedule or the integrity of the product, and if the change is accepted, to get the right wording into the requirements baseline and let the appropriate engineers know what to do.  <\/p>\n<p>When you address these issues, you\u2019ll have the right practical change management.<\/p>\n<p>Anita Wotiz<br \/>\n<a href=\"http:\/\/www.duckpondsoftware.com\">www.duckpondsoftware.com<\/a> (see the Consulting tab)<br \/>\nInstructor, UCSC Extension in Silicon Valley<br \/>\n<a href=\"http:\/\/courses.ucsc-extension.edu\/ucsc\/public\/category\/courseDetails.do?method=load&amp;courseId=3282140&amp;selectedCategoryId=1000075&amp;selectedProgramAreaId=1000171&amp;selectedProgramStreamId=3785123\">Software Requirements Engineering and Management<\/a> (next class Aug 2009)<br \/>\n<a href=\"http:\/\/courses.ucsc-extension.edu\/ucsc\/public\/category\/courseDetails.do?method=load&amp;courseId=3349574&amp;selectedCategoryId=1000075&amp;selectedProgramAreaId=1000171&amp;selectedProgramStreamId=3785123\">Software Project Planning, Monitoring, and Management<\/a> (next class Oct\/Nov 2009)<\/p>\n","protected":false},"excerpt":{"rendered":"<p>That requirements will change is a given. How you plan for and manage that change is crucial. Think about what [&hellip;]<\/p>\n","protected":false},"author":18,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"give_campaign_id":0,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[2,1],"tags":[39,204,33,11,38,50],"class_list":["post-1985","post","type-post","status-publish","format-standard","hentry","category-leadership","category-miscellaneous","tag-best-practices","tag-change","tag-common-sense","tag-implementing-project-management","tag-project-management","tag-requirements"],"aioseo_notices":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1985","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/users\/18"}],"replies":[{"embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1985"}],"version-history":[{"count":1,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1985\/revisions"}],"predecessor-version":[{"id":14218,"href":"https:\/\/svapm.org\/index.php?rest_route=\/wp\/v2\/posts\/1985\/revisions\/14218"}],"wp:attachment":[{"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1985"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1985"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/svapm.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1985"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}