“What do we need to do to make this project successful?”
Over the years, I have distilled six themes that ultimately determine the success or failure of a project. Each one of these could be a book, so my intent here is to provide talking points based on expert-level experience.
Before we start
The first thing I always emphasize is determining what success looks like. Simply installing software that functions, but never gets user adoption is not success. Having software that users love that does not improve business process is not success. Software that costs more to maintain then it generates in incremental revenue is not success.
Success is functioning software that is adopted by users and enhances business processes while increasing revenue and minimizing costs.
That’s a lot. It’s no wonder that so many CI projects don’t achieve that level of success.
Here are the six factors that must be present for your CI project to succeed.
1. Where is the data?
Most organizations start CI projects trying to define a data structure that will be used in the marketing process as if once that definition is set, everything will work perfectly from there. That’s never going to happen.
The truth is that data needed for marketing is always fluid in an organization. There is:
- Customer data.
- Transaction data.
- Web data.
- Real-time data.
- Analytics data.
- Inventory data.
- Financial data.
And in the emerging connected world sensor data, speech data, search data, cloud data, and on and on and on. Some of this data is structured, some of it is unstructured. Some is of it is big. Some is relational. Some is still in Microsoft Excel.
Successful projects start with manageable pieces of this massive data puzzle. Choose the data you need to take targeted action immediately. You must be able to identify key records that you want to target. If you are going to market to individuals, determine how individuals are defined in your data. If it is an email address, find out how the email address is stored. Yes, you will probably want to market at different levels. That’s okay.
The biggest mistake you can make is thinking that all the data questions that have to be answered before the project starts. Your marketing data sources will never be complete. The structure and the content will always be shifting. The core will remain stable, but there will always be changes. Three years ago, no one was wondering how streaming GPS data was going to be used in a marketing database. When you start you CI project, keep in mind that there will always be changing data requirements. Look to solutions that allow for those type of changes.
Technology is great, and it should be used to enable processes. But when processes are so inflexible that technology has to be customized, or key capabilities are not used, or the technology is flat out ignored, just to accommodate those processes, success is difficult to achieve.
The first step in implementing a CI solution is to examine your processes. Which ones can change? Which ones cannot? And when you find those that cannot change, an objective assessment needs to be made as to why those processes cannot change. So many good solutions have been crippled because of tribal tradition. Or habit. Or the way it has always been done. Or (one of my favorites) the process was put into place to accommodate (insert your favorite obsolete technology), which was abandoned years ago.
Bottom line here is if you are going to install a modern software system, all your processes are subject to change. Your system, and your success, will be limited by your most inflexible process.
To achieve success, you need to build successful processes. You then are using software to enable a process. Change is hard. Find an external change agent to be your advocate when beloved processes need to change.
3. The right people
When you start down the road of improving your customer intelligence systems, you do so because there is a consensus that improvements can be made. Let’s be frank, a lot of things might just not be working right, or you just cannot do what you want with what you have.
That is most often not a people problem. We have already talked about data and process. But what about your people? They are probably overworked and stressed. They are going to need help getting new systems online. They are going to have to map old processes, figure out where the data lives, learn new tools, and countless other tasks on the project plan. Oh, and they will also need to do their regular jobs. On time. Without mistakes.
I cannot tell you how many project plans I have seen where there are several, key resources, with 80 percent of their week dedicated to the project and another 80 percent (you can do the math) of their week dedicated to business as usual. These people are clearly the right people for the job, but they are in an impossible situation.
To be successful, organizations must provide their people with the time and authority to succeed. The most effective way to do this is to partner with experts. Experts in the tools being installed. Experts in data design. Experts in the industry. Demand, and be willing to pay for, great implementations. Too many times, I have seen projects that settle for inexperienced implementers to save some money. Don’t fall into that trap. The costs of a failed implementation far outweigh the high price of true experts.
4. Executive commitment
If you are a member of the executive team, this section is for you. If you are trying to get commitment from upper management, this is what they need to know. Since you could use this in an executive presentation, I’ll do it this way:
There will be bumps in the road. Schedules will slip. Scope will change. No can anticipate everything.
Integrate with old, existing systems only when necessary, not just because is “in scope” or “out of scope.”
Balance that with clear definitions of what is “in scope” and what is “out of scope.” The areas that your people are trying to figure out are your grey areas. Are they necessary?
If the process is unnecessary, it is time to end that process.
The people on the project team are the experts. Listen to them.
The people on the project team are the experts. Have their backs.
When the team decides where the project should start and when it should end, you need to enforce those points.
The most successful projects involve some scope change, some disagreements, some rework and additional costs. Management’s role is to commit to seeing it through, but not let it get out of control.
Successful CI implementations are built around excellent communication. Some would consider it over communication. Whatever mechanism your implementation follows, (I have seen email, standing meetings, messaging apps like Slack, shared storage and daily briefings) make sure everyone participates and makes frequent updates. Successful projects don’t get out of sync because one team has changed an assumption and no one knew about it.
Successful projects do however, have disagreements, arguments, fights, egos and blame. The key here is how those things are resolved. Everyone on the project has to be willing to communicate.
This communication has to flow up and down the management chain. If the project team feels like they have commitment from management, and the time and authority to succeed, those negative parts of human interaction will be worked out. I have seen time and time again, when professionals are treated like professional, amazing things happen. There is no need to cast blame if no one fears that management is going to come in and kill the project because of a one-week time slip. No one is jockeying for position if the whole team knows what is going on all the time (information is only a weapon if a select few have it).
When communication is healthy, no one fears being the messenger and problems are raised quickly and solved quickly. When everyone knows the timelines, there are no surprise deadlines.
Some of this sounds obvious, but I have seen many projects get stalled simply because someone didn’t know they had a deliverable, and while everyone else was waiting for that deliverable, other things came up. Before we knew it, two months had gone by and no one was doing anything. True story.
In order to have a successful project, I follow this simple rule of communication:
Tell them what you are going to tell them. Tell them. Tell them again. Ask if there are any questions. Tell them what you just told them. Repeat.
At this point, you may have chosen your CI vendor and partner, or at least have it narrowed down. Which brings us to the final element required for a successful project.
6. Supporting Technology
CI projects are a bit different than many IT projects in that they are both a back-office tool and a customer-facing tool. This means that there are lots of dependencies on other pieces of technology, and lots of supporting technologies required.
What hardware is being used? What is the OS? What database technology is required? How do we integrate?
I cannot stress enough how important it is to use the most current, modern, fastest and most powerful supported hardware. I have never seen a truly successful project on repurposed hardware. Sure, some of them installed and configured well, but performance or the need for constant patching made user adoption rates very low. Follow the vendor recommendations. It is much easier to deal with too much capacity than too little. If this is a cloud conversation, the guidelines are really no different. The hardware is just in the cloud.
When evaluating operating systems and databases, there are two strategies. Pick one.
The first strategy is to go with what you know. If you have a lot of Windows OS experts, or a lot of Oracle DBAs, leverage that expertise. (see section 2 on the right people)
The second strategy is to go with the technology of your future. Are you moving toward Linux and open source databases? Are you consolidating across platforms? Are you adopting integration standards?
Whatever you choose, the critical factor is commitment. If you go the route of modernizing or standardizing, realize that there will be other systems that might have to migrate as well. There will be additional cost in retraining, or finding new expert resources. This is especially true when talking about the databases. Going back to where we started, data is crucial to CI projects. So is the supporting technology. And the people.
This list of success factors is by no means all encompassing. There are lots of other factors. This list looks at six major elements that contribute to a successful CI implementation. My experience has shown that you cannot complete a CI project successfully if even one of these areas is subpar. You can hit deadlines and check off deliverables, but in the end, projects that missed even one of these factors risk eventually being abandoned all together, or even worse, become the dreaded shelf ware.
I trust that you found this useful in the sales cycle and as something to use to answer those tough questions about success. In a future post, I will cover how SAS is the vendor that can best help in all of these areas