Having led more than my fair share of technology and software implementation projects in different types of organizations, I’ve often referred to the term “disco ball” as a way to capture a trap that can jeopardize your implementation. Leading a project from discovery to selection to implementation, I have always been aware and concerned with the trap that many before me have fallen into around trying to enable all potential or possible functionality from a new system right off the bat even though the organization might not be ready to handle it.
The urge to make an impact and possibly over-promise at go-live is a strong-one. You, your team, and the company is geared-up for an investment and you want to show how much better things are going to be and how much bang-for-the-buck you get with the time and money you have invested. But, giving in to this sort of trap really can jeopardize the whole project. Enterprise systems and business software are projects lend themselves to this kind of trap. When a company is looking to find a new back-office system to cover the needs of the growing business, it makes sense to look at what you need currently for the business and also to the future on what the company will need in the next 3-5 years with a software partner and functionality around items like CRM, HCM, and financials. When you look to the future for needs, you are probably going to buy more than what you need currently and a common urge from everyone involved is often to show how awesome everything is going to be for everyone as soon as you possibly can. Don’t do it.
When you fall into the disco ball trap, you open up more risks on your project and take on more challenges than your organization is probably able to handle. You can easily get mired into larger business process questions and waste time on areas that are related and in the scope of need for the future, but not required in the immediate radar. You can open up more questions than answers and more problems than solutions. People often refer to this as scope creep, but I see it as a different animal. The difficulty is that the functionality is often in scope for the longer-term goals of the project and what you may ultimately want from the technology or software system, so scope creep doesn’t really seem appropriate. “Disco ball” is useful term in that it conveys the want to have something sparkle and impress but it can also be a major distraction.
