Vote Your Data Off the Island and Onto the Mainland

As a company grows in size, various information sharing challenges appear that can stifle that growth. One such speed bump sets in a few years into the growth cycle, when the company expands and each department develops its own information needs.

That problem is called “Islanditis.”

The system that supported five or 10 people starts to break down under the strain of 30 to 50 users. The office manager went to a Microsoft Access class and built a whiz-bang lead tracking system that is now suffering file corruption weekly, the sales manager got fed up and loaded his precious leads into a Google spreadsheet, and the stock room clerk bought a package for $500 that allows him to ship products with barcodes — and the list goes on.

Data Disconnect

Data is everywhere, but it is disconnected. Marketing campaigns don’t benefit from the latest product knowledge. Sales prospecting activities are not reflected back to management and other staff, which creates embarrassing overlaps in communications. No one can give the executives a consolidated report because no single system has all the data. Information abounds, but no one can answer the question “How are we doing?” without hours of data crunching from different systems.

We call these disconnected sources of data “islands” and they are a significant source of pain for a growing company.

Islanditis can be complex and difficult to overcome. First, investments have been made in building or buying these individual solutions. There is emotional and political attachment. Territories have been established and investment in automation “turf” is held as precious.

Second, departments and teams have learned how to solve their problems using separate systems. No one department wants to undergo the pain of giving up their tried-and-true solution, even if the new solution is supposed to be better. As they say, “The devil you know is better than the devil you don’t know.” Finally, individual groups, depending on their problem-solving savvy, may not have enough pain in their team to cry for help.

Need to Grow

What happens internally when a system no longer meets the needs of the busy employees? Frustration sets in. Productivity stagnates. Growth stalls. Employees begin creating workarounds to get their job done and these workarounds are sometimes ugly. People may resort to spreadsheets again (an earlier growth bottleneck reborn) to perform tasks that the system doesn’t handle.

A new, integrated type of thinking must be applied to streamline the company’s operations so that they can accelerate again. This time the solution will be larger, will take longer to design, and will result in more significant changes to company operations when it is implemented. It will have to be driven from upper management, where executives know that the risk of perpetuating the status quo is stagnation — no more growth.

At this juncture, someone needs to assess the company’s needs for information processing across the enterprise. Process thinkers — people who see companies as a system of systems — must help stakeholders reach consensus about a new solution in order to overcome the growth hurdle.

Build or Buy?

Whether you are going to build a solution or buy it, you have a project on your hands and both approaches have some common elements:

• Project Charter (goals, sponsor, ROI, etc.)
• Change Management (expectations, process redesign)
• Needs Assessment
• Deployment
• Training

We suggested in our last article that building a custom CRM system would be silly because there are so many good products to choose from. We’d make this recommendation based on the following assumptions:

• Your CRM needs match many other companies.
• CRM is not a competitive weapon for you.

To evaluate how well your needs line up with those of other companies, you’ll perform a needs analysis and then prioritize those features. After you have built this “ruler” with which to evaluate available products, you can measure how close each potential solution comes to your needs. If your needs list aligns well with the feature set of many CRM solutions on the market (say, an 80 percent or better match), then you can feel confident that one of the best-fit packages will serve you well.

Some other activities that will need your time and attention when buying the solution:

• Form the Team. You’ll need one or more technical buyers, financial buyers, and user buyers to round out the team.
• Set a budget range. This might be the point where, for lack of knowledge about your options, you decide to issue a Request for Information (RFI) rather than a formal RFP.
• Manage Vendors. Establish rules for contact and make sure there is a system in place for sharing outbound communications with all vendors still in the bidding process.
• Check References. Ask the biggie up front: Would you buy from this vendor again?
• Score Presentations. Use an objective scoring system so that you avoid the “shiny object syndrome” of buying from the cutest salesperson or the coolest screens.

If the packages available don’t fit your business well or you decide that CRM is a competitive weapon and you intend to make yours better than the rest, here are some items to put on your build checklist:

• Identify all audiences affected and make sure that their needs will be met. Great software begins with a thorough understanding of each role being served.
• Define each and every feature needed for every role. Be systematic about this so that you have high confidence in the results. Projects fail more from lost confidence than lack of technical prowess.
• Prioritize features into phases. Not all features carry the same business value, so don’t try to swallow the elephant whole. Many companies make this mistake and have their project implode because of complexity.
• Identify internal or external resources necessary to design, build, test, deploy and train.
• Design your data model using good names, proper table relationships and with an eye toward flexibility.
• Design navigation that makes the application easy to move around in.
• Consider prototyping, which allows stakeholders to see and interact with applications during the design phase. Today’s tools make this much easier and you will save time and money in the long run for a large application. Many users won’t tell you what you got wrong until they see it.
• Construct the solution in small (weekly or bi-weekly) “releases” so that everyone can see steady progress.
• Treat data migration as a substantial subproject. Depending on how clean your current data is, and how well it maps into the new structures, it could be run as a parallel project and begin as soon as the new data model is ready.
• Test the application as soon as possible. Get business people involved from the beginning to plan how to test the solution in real-world terms.
• Deploy the solution in a planned, controlled way allowing for surprises. Practice the deployment to find missing pieces. Plan for work interruption. If your business is closed on the weekends, deploy on a Friday afternoon.
• Train the users in how the system is supposed to work. Users need to be trained on proper use even if you interviewed them for their needs.

Pursue excellence in the process itself — not just in the finished product. It’s only a slight exaggeration to say of a software project, “the process is the product.” If you go through a good process, you should get a good product.