I have to admit that Change Strategy and Change Management are topics that don't inspire me as much as elicitation, requirement management or even testing. In my experience, the business analyst isn't given much control here but it certainly is a topic a professional business analyst should know. As I was trudging my way through the BABOK third edition, I found myself in the 6.4 section on Define Change Strategy.
It is a well written section but the scope of discussion has always been someone else's job in my past endeavors. However, I began to pivot my thinking as I was absorbing the .4 subsection Change Strategy. I'm working on a project where the project sponsor and project manager are trying to reimagine and communicate the scope based upon available budget and schedule. However, the scope they have outlined for this portion of the project isn't realistic and potentially will cripple the acceptance of the product by its users. The sponsor doesn't have the juice to require the users to embrace his multiple million dollar software solution. The divisions can still leverage their existing third party products, Excel spreadsheets, Access databases and so forth.
After rereading the .4 Change Strategy section, I began to wonder if the recommendations listed there could be used to change the reimagined scope of my project? I have a mental image of cranking some big rusty switch so that the train will head away from the closed tunnel and towards an alternate track that will lead to the destination described in the project charter. There is a bullet list in this section and we can experiment on what a proposed reversal of purpose might entail.
• organizational readiness to make the change
This becomes the project sponsors readiness to make the change. Many of the viewpoints can be easily pivoted to apply to that objective.
• major costs and investments needed to make the change
• timelines to make the change,
• timelines for value realization,
• opportunity costs of the change strategy.
You may want to build a companion benefit analysis or value stream. If you build a decent data model, you should be able to calculate a cost-benefit analysis and even a payback period based upon different variables.
• alignment to the business objectives
Chances are, you already have this task accomplished. In fact, what you are trying to do in this exercise is get the project realigned to meet the established business objectives. You may need to display how the current path of scope definition introduces more risks that it mitigates. That budget and schedule are not scope but constraints applied to methods to achieve objectives.
These are just thoughts I had, not sure to what degree I will act upon them. It is quite possible that I would get shutdown by my supervisors before having a chance to execute these steps. However, just the notion has increased my mental engagement in reading this material.
© 2015 Dwayne Wright