As an organization grows and adds new people, data management becomes a growing task. Every interaction with clients, potential clients, vendors, agencies, etc. has the potential of touching multiple people. Even if it only touches one person, there it is unreasonable to expect that person to keep every interaction in their memory. Interactions can be kept on paper in notebooks, log books, ledgers, and message pads.
But, it’s difficult to retrieve data from paper, unless you have a photographic memory. And no one else in the organization has access to your data on paper. The sooner this problem becomes obvious, the better. It’s time for a digital system. If an organization-wide system isn’t implemented, everyone will do it their own way: paper, spreadsheets, Google Docs, …
The Move to Digital
By the time management finally gets around to the realization that the organization needs to centralize data, and after management puts off the task because it’s so much work, the organization already has data scattered all over the place in a multitude of ad hoc data systems. It would be nice to think that management will start by having a conversation with staff about their data needs, but that is unfortunately not the norm.
Because talking to the people on the ground is not the norm, whatever system is developed will have so many holes, staff will have to create ad hoc systems on the side anyway. In a tech meeting yesterday evening, I spoke to a gent who told me that the options available in his corporate world were bad and worse.
I have seen this happen in my own career. In my first tech job with a small startup, management decided that it needed a database where everyone could access information about the clients and projects. That was a very good thought. So, one manager built a database over the weekend. That was a very bad move. This manager was a know-it-all who was above needing input from anyone. There was quite a lot of dismay from the tech department when they realized that none of their data needs were even addressed.
To meet the needs of the tech department, I built another database in the same technology after meeting with each person who would enter data or use data. We used both systems, one to appease the manager’s ego and the other to meet the data needs of the tech department. Of course, that meant double data entry. It wasn’t an efficient solution, but it was a solution.
This example shows that going to digital doesn’t necessarily solve the problem of a multitude of data sources that are isolated to individuals.
Enter CRM Software
The idea behind CRM is to gather all the data into one place that is accessible by everyone who needs it. “While CRM software is most commonly used to manage a business-customer relationship, CRM software systems are also used in the same way to manage business contacts, employees, clients, contract wins and sales leads.” ~ Webopedia
CRM software has existed since the 1990s. I have used Goldmine, ACT and Salesforce in different work environments. They all improved organization-wide access to information.
But … But … But
If a CRM is setup without design time and collaboration time, the same issues will cause the same headaches as with paper records. And, ad hoc software will show up in the system to meet those undiscovered needs. I created this model to demonstrate how just having a CRM doesn’t necessarily solve the problem for a chapter-based non-profit. The scenario in this model is that a poor Salesforce setup resulted in other software being added in to take care of the needs of various staff and volunteers.
The arrows were intended to show how the data should flow. There should actually be two models: one to show the current status, and one to show the desired status. In this particular situation, internal and personality issues meant that the discovery project ended with no agreement of what software tools to keep and what the “master source” of the data should be. So, let’s look at a possible process to avoid this gridlock.
Plan without Panic
- Step 1: Determine the organization’s data goals
- Step 2: Talk to people and find out how access to data and reports could make their work more efficient
- Step 3: Model the data
- Step 4: Review the model with management and staff
- Step 5: Adjust the model
- Step 6: Determine whether your choice of software can meet all those needs or whether additional pieces are needed
- Step 7: Map the model to the functions of the software
- Step 8: Implement
Causes of Panic
Watch for Artificial Deadlines
An artificial deadline is a deadline that has no connection to the actual work being done. For example, if you have a trade show coming up in three weeks, and you give your web developer a three week deadline to rebuild a site, the amount of work the rebuild takes is not necessarily three weeks. In fact, “rebuilding the site” is not even clearly defined. This same scenario happens with planning data management.
A startup or an organization in a fast growth cycle will inevitably end up with data chaos to organize. But to analyze and organize, the strategy of snap decisions and executive demands, needs to make way for more thinking time. If the Snap – Snap style of management pressure doesn’t relax, it will lead to sloppy work and structural problems that will become emergencies later.
The correct deadline is “what can we expect to accomplish in three weeks.” And a correct deadline contains contingencies for unexpected delays. For example, a recent server update was not compatible with a custom function on a website. The problem with the server upgrade is not the fault of the website developer, but it changes the nature of the project … and what can be accomplished in 3 weeks.
Identify Demands that Will Send the Project Off-course
Sometimes, a person who doesn’t have to do the work will break the project with unreasonable expectations to fit an immediate need. That person rarely means to cause a problem, but that person doesn’t understand the difference between wanting a tool to be ready for their needs and the work it takes to get to that point. An environment of constant side demands, means that the goals of the project will never be met.
Like an algebra problem, you don’t solve all the data planning in one piece. Jumping around topics is inherent in a project where pieces affect each other, but sometimes it’s good to identify a problem and then set it aside for later to keep the focus on the current topic.
Smarter, Not Harder Has It’s Limits
There is a point to where employees can do a multitude of tasks poorly or a few tasks well. When someone throws out the “work smarter, not harder” clique, keep in mind that this phrase is just a tactic to make unreasonable demands. If the phrase were 100% true, Ford Motor Company could run effectively with one person who has just figured out how to work smarter.
Identify Specs that Are More Internal Politics than Long Term Benefits
The task of data organization requires a clear mind, and an objective process. You may not be able to change the fact that you have to do Task X or you have to do it with Method Y only because a person with more power or influence says so. But, you can make a mental note and a documentation note. If your project documentation includes who made what suggestions and what suggestions were tried, and the results, pressure that is harmful to the project will become obvious.