The Different Types Of Approaches In Organization Change Endeavors

So you have landed into a project dedicated to improving a sensitive area of your organization. What approach will you take or what approach has been decided for you? Here are four of the classics and perhaps the following narrative will help you on your journey.

My buddy posing for a picture on the Twin Falls trail in Issaquah Washington. I  hoping he is enjoying many such trails up in doggie heaven!

IT Driven: It is not uncommon that some people consider IT as a collection of wizards that possess a pocket full of magic. By the sheer design or purchase of a workflow software package, the issues with any related processes will be resolved. As outrageous as that statement may sound, it does ring true a significant amount of time. A new software tool can be a central point for positive change but too much reliance on IT kung-fu alone can create as many problems as it tries to fix. If you are in an IT-centric approach, a business analyst can be a great resource to fill business centric information gaps that help ensure long term success. 

People Driven: This is a bit of the flip of the IT Driven approach described earlier. In a people driven approach, what the people need is placed in higher priority than what can an IT solution deliver. As you can tell from the tone of this narrative so far, this is the approach I consider the best. Unfortunately, this approach can be a considerable challenge to get an organization to embrace. 

In some organizations, the focus is upon finding vendors, sending out multiple RFP communications into the wind, a review of the SOW from the lead vendor (hopefully that review does not start and end with the price) and then giving the chosen vendor the keys to the house. This is a classic risk transference technique because it allows anyone in the organization to blame the vendor. By the way, don't extend too much compassion to the vendor in these situations. Most of the vendors not only know this can happen, the workflow and associated contracts are crafted to mitigate that risk and ensure they profit from the time they invest in the project. 

To be clear, the software vendor / consultant is not the villain in this piece. They are simply providing expertise, craftsmanship and their time to the endeavor. It is the responsibility of the organization to obtain the correct amount of value from it. 

Top Down Driven: The endeavor was inspired by a member of senior management and typically driven by a set of established KPI parameters. One challenge that can be encountered here is the lack of a strong measurement structure for those KPI parameters. So when the project ends, no one is really sure how well it met the original goals. This can be resolved downstream by a quality driven business analyst, product manager or project manager. However, the best approach is to make sure the KPI measurement process is baked into the project during and after it concludes. 

Bottom Up Driven: Typically, this is a mirror image of the people driven approach. The requirements package will tend to have a significant number of "as is" and "to be" process flows. A professional business analyst will align their requirement packages closely to those flows via traceability. The "to be" process flows can easily be translated into test cases and make test measurements more significant. 

© 2016 Dwayne Wright