Wednesday, March 9, 2011

Big vs. Small Changes


Big changes, possible or realized surround me these days

One of my recent complaints on a personal level has been the lack of big changes in our government. Without getting too much into my personal politics, which is not the focus of this blog, I think it is fairly agreeable that our current two primary party systems lends itself to minimizing big changes. This happens because the two parties almost always take opposing views and drive compromise before implementation. If that doesn’t happen, the party that is in control normally gets replaced every two, four or at the outside eight years, and swing policy back the other way.
I have shared my desire for bigger governmental change with friends and colleges, to which I receive a 50 / 50 response. Half agree and half say it’s good that big changes are not taking place.
Regardless of your stance on each of these issues, this current situations brings up an interesting question about how, when, and if we do big vs. small changes.
I have never been one to be afraid of big change, I believe I thrive on them. Why then, am I more hesitant to see big change in our products at Ministry vs. wanting to see big change in our government? Maybe it’s that this change feels like its being driven by forces outside my control; although most changes are ultimately driven by outside forces. It could be that I feel responsible for my customers in the same way that I hope our government feels responsible to their communities.
I think it all comes down to the level of understanding of a change. It’s easy for me to sit in the “cheap seats” and read a few articles about something. Then want to government to fix “it” in a big way by doing “X”, when, in reality, the devil is in the details.
Looking at something I understand more, the possible replacement of our API systems in Ministry.
I agree with most of the forces that think this will ultimately come to a positive result for us. However I have lived through this type of change before and understand the negative side. It can take a long time to recoup the ROI of manpower and capital for the implementation. Most calculations to estimate this are greatly lacking in information and paint an overly optimistic picture. End users will feel "pain" in the form of the almost inevitable support issues, downtime and loss of procedural efficiencies that will manifest over the short term after such a change.
Still there is a point where all those negatives and even a possible five or ten year ROI still has to be accepted. Either because your hand is forced, or small changes have reached the point where they can’t take you forward anymore, and all you’re left with is a big change.