The Big Bang Vs. Incremental Change Debate
By Bill Bittner, President, BWH Consulting
It is a constant debate among IT and business managers. Does it make more sense to implement major change all at once (aka Big Bang) or do it incrementally?
Big bang advocates say there is no other way to introduce major change to an organization. When a fundamental modification to the foundation of the IT environment such as its operating platform or network connection is required, there really is no choice but to bite the bullet. Only by conducting a coordinated switch will the job get done properly.
Incremental change in this situation, say big bangers, is akin to “cutting a dog’s tail off one inch at a time.”
Advocates of the incremental approach say large-scale change is too risky. By dividing a project into many separate, easily verifiable phases, the project management can be confident that things are moving forward. This is also a big benefit for the user area because it allows time for the training required for the new solution.
The challenge, however, is that the technology itself probably represents the fastest changing piece of the puzzle. If you lay down the technical environment today for an incremental set of application changes over the next five years, it is possible and even likely the environment will become obsolete before you finish. Of course, this may also prove true in a big bang approach if it takes a great deal of time to implement.
Retail IT projects tend to have much larger training and personnel issues than other businesses. For store applications in particular, the sheer number of people and the geographic areas where they are dispersed makes training, which is an absolute necessity, a challenge.
Training is critical because, if not done adequately, a company can quickly lose the expected benefits associated with the change. When it comes to service personnel, there is probably adequate training in place because stores have to deal with ongoing turnover in those positions. Problems, if they crop up, may be in store and department management that are focused on what is deemed more immediately pressing areas. If all levels of store management are not brought into the training process, then they may, in essence, impede progress, preferring to do things as they had been done before.
Moderator’s Comment: Does the big bang or incremental approach make more sense for retail applications based on your experience? What do you believe
are the keys to successfully creating change within retail organizations?
I personally believe both approaches have their time and place, but I am naturally afraid of projects that are expected to take more than a year or require
change in processes within more than three departments. If the project meets either of those criteria, I immediately want to consider ways to introduce it incrementally.
There is one very simple approach to retail applications that I think can ease implementation. The real money saving applications are those that yield some
benefit at store level, whether reducing cost or increasing gross profit dollars. The leverage on these applications is huge because the benefits are multiplied by the improvement
at hundreds or even thousands of locations. So the way to introduce these applications is by location, source, and category.
Software vendors should design their applications with this phasing in mind. This allows the retailer to choose the stores, vendors, and categories they
first want to implement and then roll out the solution as they gain experience. If it is truly an “ERP” solution that is meant to manage the whole cash to cash cycle, then it
can do it a single DSD vendor. Implementation problems will be limited to the one area and the role out can continue when all the initial problems have been addressed. This also
reduces the scope of the change because, by starting with DSD, the issues with self-distribution are postponed until the items sourced from the distribution center are addressed.
–
Bill Bittner – Moderator
I didn’t do the survey this time because there was no “all of the above” button. So here’s a few dislocated ramblings about change:
All change happens in an instant. That means there’s no such thing as incremental change.
‘Awareness’ and a ‘Readiness to respond’ are the prerequisites to having people engage change and most organizations spend virtually no time on either one, preferring instead a ‘drop the bomb’ approach. Then they wonder why people aren’t grateful. When people plan the battle, they don’t battle the plan.
If the sub-conscious mind-set of the people involved doesn’t change, change won’t last. Ask any dieter. Change your thinking; change your results. That’s how it works.
If your organization is flowing within and throughout, there really is no such thing as change at all – there is only dynamic flow and growth. “Change” is typically a movement from one static state to another.
I have observed that, in many cases, the “Big Bang” approach of technology replacement simply becomes unavoidable because systems and applications have been allowed to become so hopelessly obsolete that incremental change is not a practical solution. In one retailer I’m familiar with, mission-critical applications dating from 25 years ago are still running on mainframes, with data-entry front-ends built from Access and Excel. These applications are not only very fragile and inflexible, but the only real alternatives are to leave them in place or “blow them up” with complete replacement. All too often this situation results from an “if it ain’t broke, don’t fix it” mentality, or a rigid insistence on showing an ROI on every IT project, or both. Many times the return from investing in ongoing technology upgrade to stay current cannot be shown from immediate operational savings, but lies in the future avoidance of the high costs and risks associated with very large Big-Bang replacements that would otherwise become unavoidable in the absence of such investment. Retailers would be very well advised to view regular systems refreshes and upgrades in order to take advantage of technology advances as “maintenance” expenditures necessary to maintain the value and usability of the IT infrastructure, in the same way that repairs and renovations are seen as necessary to maintain the value and usability of buildings, and simply create budgetary funds that can be spent on such projects without the need for a “business case” justified by savings or revenues.
Big Bang often = “bet your job.” Incremental is safer, employmentwise, for a good reason: everyone can learn about the unexpected without having everyone under stress. My experience is that end-to-end testing is rarely done thoroughly, so unexpected results often occur. Chain retailers are blessed because they can test a new store system in 1 location or a few locations instead of having to roll out 500 locations at once. Headquarters systems are riskier to install because they often can’t be rolled out incrementally with ease. That’s why they need end-to-end testing under heavy volume. For example, Mercury Interactive makes great software volume testing tools.
There is always a risk in the ‘Big Bang’… it is like taking a newborn… you want him to run, eat and go to college all at the same time. We have been implementing an ERP in our network and it has been a nightmare to say the least. When the vendors are marketing their systems, they all sound marvelous… auto-replenishment, instant P&Ls, etc. Before the system users are fully trained, in the live environment, there is a lot of garbage in, garbage out. There is a very real article by Stephen Addison, CISA in Information Systems Control Journal, Vol.4,2001.
Bill addresses an interesting point; providing benefit to the customer early in an IT engagement. This often leads to questioning the benefit of completing the project and would the additional benefit be worth the expense. Fixing the “low hanging fruit” needs to be communicated early in the proposal stages with a customer to align expectations.
The most effective approach is pursuing parallel paths. Maintain the existing systems while the new project is under construction. As phases are completed, training can be provided to users and depending on the project, implementation can be phased in as well. This offers benefit to the customer throughout the engagement. If the phased in approach is not applicable, the new system can be “cut over” after the completion of installation and training. This approach is standard outside retail in communications, automotive and other verticals.
Technology adoption is always a matter of incremental change, even if it is a big bang. You have to have an early adopter. That early adopter will be in one department. That early adopter will have to have a visualization that lets them sell the application to the rest of the organization.
This precludes an executive sponsor. The need for an executive sponsor hints at 1) the politicization of the requirements, 2) the subsequent requirements volatility, which is the main reason for the failure of any new application effort.
This also means that rather than write one ubiquitous application with a single data model, you write for one adopter at a time. When you do this, each adopter’s functional unit culture is respected and the consequent politicization and requirements churn goes away. This, however, runs counter to old notions of efficient development. We are in a new age where code can be free or cheaper, so production efficiency is less the goal than operational or use efficiency.
Applications should not change the way things are done in the work domain. They can change the way things are done in the implementation domain in a way that has zero impact on how things are done, unless you are doing completely new things. ERP is characterized as integration, but it ends up changing the way things are done by the shear effort of trying to bend the prefabricated ERP system that doesn’t fit. This is where enterprise systems fail.
There is a huge focus on the user interface. This is misplaced. If the application was developed in a culturally respectful manner, then the underlying conceptual model is fit to the users and the interface becomes less problematic. With a less problematic interface, training needs are decreased.
Further, training schedules also schedule value capture by the organization. This means that as more training is received, then more value is captured. The price-to-value paradigm was created as a demand that cash flows tie to the value received. This is where you make timed payments for the software as the value is exploited to greater extents. The value will arrive in a stair-step manner, so the costs and payments should be delivered in a like manner.
Agile methods, particularly something called FDD, can be made to deliver requirements as packets of value. Agile inherently delivers small pages of requirements, and it does so in a tight feedback look with the user. This is ultimately an incremental manner of delivery. It is also a slow, incremental way to learn and train.
These concerns can be exploited to create a successful and cash flow effective way to insert technology into the enterprise.
The issue is not either/or, rather the concern should be the impact of any change on the various constituencies: customer, consumer, employee, supplier, etc. We often confuse how to change with the need to change. Often companies know something needs to change but are afraid to pull the trigger, whether the squeeze is rapid or slow.
Procrastination never serves the need to stop doing one behavior and begin doing something else. The above comments present viable arguments for “big bang” versus “incremental change.” I think the bigger issue is the decision to do something rather than the best way to make a change.
On this topic, I always cite two examples from the supermarket industry: 1) UPCs were invented in the 60s (they began as bulls eyes instead of bars), were endorsed by the supermarket industry as a nationwide standard in the 70s, and there are still retailers without scanners and products without barcodes today. 2) A nationwide survey of the amount of time the CEOs of U.S. companies had been employed by the companies they led revealed that supermarket companies – by a very wide margin – headed the list with the longest span of employment.
Change comes slowly to the supermarket channel. Fortunately, the IT days are gone when companies had to commit to exclusive platforms with multi-million dollar price tags. Today, it’s de rigueur for successful hardware/software providers to include total platform integration. Smart.
But – there’s always a “but” – the communication backbones installed in most retail locations just can’t carry the traffic. I know of chains where basic IT proposals from widely-accepted third-party providers (like Catalina Marketing) have been tabled for three years or more because the stores just can’t handle the bits & bytes. The solution just over the horizon is wireless “hotspot” installations. Heck, here in Sacramento we’re about to approve citywide wireless access. This will accelerate retail connectivity significantly, along with the new processes perpetually introduced by suppliers.
I think that there are a couple of points worth noting. One, I think that Mr. Bittner accurately points out in so many words that ‘it depends.’ That is to say, that each approach has a time and a place.
Another writer talks of the importance of training and its difficulty in a dispersed retail environment – how true. Further note, in regards to training, is the quality of training and its priority within and organization. Sadly it is usually an afterthought. This is even worse when it’s a customer-centric application. We’ve all been there haven’t we? Waiting in line or at a service counter when the associate says “This is new, and I don’t know how to…” or “This is new and they never told us…,” or make up your own line.
I would also think that as much as top down support for change is an absolute requirement, bottom up support is equally as important. In order for there to be success, there have to be cheerleaders at both ends of the spectrum and essentially value at both ends. Which leads me to my last point.
Why change? I think this is a critical question that isn’t always asked and answered in the best way possible. The most important question always is “How will this benefit my customer?” or “How will this help me to better serve my customer?”. At retail if you aren’t focused on your customer in IT, you are not likely focused on the customer at your stores. IT can carry the largest capital budgets outside of construction in most retail organizations. It’s even more crucial to ensure that those dollars are spent wisely and in ways that directly benefit the consumer. They absolutely must be aligned with the overall strategic goals of the organization. They should be focused; the realization of each project should be directly measurable against those goals. If not, there should be an extremely compelling reason otherwise. Whether its big bang or incremental, change for the sake of IT alone has little if any value whatsoever. Change for the sake of creating a better experience for the customer should be the focus – always. When that is the case there is no such thing as an IT project – period. And, there should never be such a thing as an IT project at retail.
If within this IT program lies the purchase scanning data, and any other shopper information, you definitely need to have a consumer/shopper advocate that understands the numbers, trends, and segmentation.
I am purposely not suggesting a consumer packaged goods marketer for such needs. For the CEO and senior executive staff have to buy-in, commit and visually show their support daily, reading and becoming familiar with the analysis. Then, you bring in a consumer packaged goods marketer. Hmmmmmmmm
Two key questions must be asked to determine if big-bang is right: First how much customer loyalty currently exists and how will the loyal customers respond? If the opportunity exists to double market share or volume, and loyal customers make up less than 50%, then big-bang is best. If loyal customers make up more than 50%, or the ability to double sales or share does not exist, then it becomes more of a “fuzzy” answer which needs closer review. (One example would be the entry of a major new competitor to the market which would increase the need for a big-bang change.)
Other questions to ask concern managing expectations. Going with big-bang requires consumer awareness to occur and in so doing, the risk of setting up expectations that cannot be delivered can become a huge risk…or major benefit. Key in managing expectations is understanding that you’ll have them if you do big-bang or slow change; in either case you must be able to manage them. Risk is, with slow change you don’t always pick up the little changes in expectations because they occur so slowly.
Overall, in today’s retail environment, my vote is for big-bang. The marketplace is changing too fast for most retailers to do anything less.
In a recent (August 11th) Supermarket News article, CIO Zeke Duge coined the term “Mini-Bang” to describe the architecture-based IT strategy that is driving success at Smart & Final. In simplest terms, this approach relies on enterprise integration technology, creating a highly flexible IT architecture that will support the dynamic needs and growth of the business. The resulting ability to rapidly deploy emergent “best in class” applications and functions is becoming a necessity in a world of constant change … so count me in favor of “incremental change” (albeit, constant!) assuming, of course, the foundation for seamless integration and rapid deployment has been put in place.
We have actually researched this issue for 40 years, and we have found that if the change affects operations or finances in a significant way, that BOTH incremental and radical change are highly UNLIKELY to produce the outcomes desired. The reason is that the underlying system that determines what decisions are made and how is ultra-stable and will continue to produce the same decisions and the same results unless it is changed.
I frequently encounter the theoretical debates surrounding radical vs. incremental change, change from the top vs. change from the bottom, participatory change vs. unilateral change. Unfortunately, these theoretical debates distract us from the data that we have cataloged literally several thousand times: that real-world, significant change in business organizations almost never produces the desired results, and that the reason is that the system responsible for how organizations actually work is never (yes, literally never) effectively engaged and modified.
Does this correspond with the real-world experiences out there? What do you all think?
More often than not, the big bang approach doesn’t work as well as changing out systems one or a few at a time. Stories of companies having serious challenges with major systems overhauls have been fodder for the tech pubs for more than a decade. The retail and manufacturing industries in particular have suffered – look at Nash Finch and Oshawa’s with their scrapped ERP implementations in the late 1990s and Hershey’s problems with three vendors just prior to the big Halloween season a few years ago. More recently, Overstock.com tried to complete a big bang in eight months rather than the 18 months suggested by its vendors. The results haven’t been pretty and it will probably take the better part of a year to get back on track there. There’s a reason why you hear less about failures of systems being implemented incrementally – they don’t make as good copy as a systemic failure.
The difference between incremental and radical change is either slight or it is cultural. The move from traditional to ABC cost accounting was cultural. It was a paradigm. You couldn’t get there from the other. You couldn’t forecast it. You had to envision it.
When it is visionary, then radical is necessary. It’s a whole new world. When it is standardized, normative, prescriptive, then continuous is necessary.
Issues of performance can be dealt with in training and systems through the notions of incremental value delivery, price to value, and delivered long before JIT. Ultimately, an application’s success, in performance terms, relies on encoding the user’s conceptual model, so that the application is intuitive. This means that training in the application’s conceptual model should be delivered to the programmers first, rather than not at all. Users don’t have to educate the programmers. The users learned their jobs at college, in books, and on the job, but on the job was the thin end of their training.
Concepts typically originate outside the business. Their intake is a matter of enterprise learning. Part of being a learning company is transferring that learning to the programmers, the users, and finally into performance. Widen the band of this education effort to reduce the risks.