Big data and analytics projects don't necessarily need to be run by IT. Here are some tips on coordinating with IT while maintaining independence.
Many companies use a centralized data science or analytics department under the direction of IT to head up big data and analytics projects, but there are probably an equal number of that start analytics projects in other departments.
Big data and analytics projects are most likely to be started and managed by individual departments when the analytics solution being looked at pertains to a specific function that department does. For example, marketing might need analytics software that specifically addresses demographic questions for product campaigns, finance might need a portfolio analysis system to assure that short- and long-term investments are properly positioned; or supply chain managers might use analytics software to asses the health of their global markets and suppliers.
In all of these cases, what is most relevant is whether the analytics solution can answer key questions that the business is struggling with in a particular area of expertise.
This is exactly what makes the owning department--and not IT--the most logical area to head up the search for an analytics solution.
The catch to this process is that many managers who are called upon to lead a big data or analytics project lack some of the background in project management and investigation that IT is likely to have. So if you're suddenly faced with finding a big data analytics solution for your department, what are some best practices that you can use to help you with this project?
Before moving forward on any big data and analytics software search mission, you should have a concrete business case that the software is capable of solving. Along with this, you also should identify a return on investment (ROI) that you expect the software to give back. If you are pursuing analytics that can assess the risk of your financial portfolio, the objective should be to show how by identifying risk areas that your company can avoid, your company can avoid financial loss. If your goal is to improve marketing by better pinpointing consumer behaviors and buying references in certain geographical areas, your goal should to improve sales revenues. In almost every case, the company is going to be looking for hard dollar revenue gains or operating cost reductions. It isn't good enough to set a project goal like "reduce paperwork in finance"--unless you can also prove that paperwork reduction will lead to improvements in financial close cycles, cash management and accounts receivables performance.
2. Get support for the project
Support for your analytics project (and what it delivers) should come not only from your immediate supervisor, but from the C-level of the organization and, yes, even IT. The worst thing you can do is to take on the project on your own without communicating with anyone. This is what leads to project disconnects and the boneyards of software gathering dust because someone couldn't get the software to work on their own.
3. Coordinate with IT but don't let them run your project
Because IT can be perceived as an autocratic and show-stopping function that delays software implementation, many end users try to go around IT. This is a mistake. The success of your project is going to depend not only on its ability to perform critical functions for your department, but also on its ability to integrate with other applications that are running in the enterprise. This is an area where IT has the resident expertise, so you should get them to review the project for compatibility with other enterprise software it might need to interact with. IT can also tell you if your vendor has adequate technical support resources for its product. Your goals here should be to make IT a trusted business partner-but at the same time, you need to stay in charge of your project. In short, coordinate and communicate with IT, but don't let them take your project over.
4. Trial the new application
Every company's internal environmental is unique. Consequently, when a vendor shows you a demo that portrays use scenarios for its product, you should still do your own proof of concept to make sure that the product can work as advertised in your own environment. The best way to do this is to invite the vendor to run a trial proof of concept at your company so you can both see if the product can do what you want it to do. During this trial, IT should also be on hand to ensure that the product's underlying technology, security and governance are at appropriate levels.
5. Perform due diligence on the vendor and the contract before signing anything
If you have a legal or contract department, ask them for a review of the vendor's contract. IT is also a good business partner for technology contract reviews, since IT knows the security, governance, performance and support SLAs (service level agreements) that outside analytics vendors should be prepared to guarantee as part of their contracts. If the vendor is entirely new to you, also check on vendor financial stability.
6. Participate in vendor forums and develop a relationship with the vendor
It is important to cultivate an ongoing business relationship with the vendor so the two of you can discuss new needs in the business that the analytics should address in the future. The most effective ways of doing this are to actively participate in vendor conferences, forums and committees that address new product enhancements that the vendor should consider--and to maintain open communications channels with the vendor.
7. Develop a roadmap that goes beyond your original destination
In three words, have a vision. Investing in analytics is a major operational, strategic and financial decision. You have to be able to think beyond an immediate business case or need, or the investment may not be worth it. If your immediate goal is to ensure that your supply chain suppliers are not "weak links" because of operational, political or financial vulnerabilities, what future areas of supply chain risks do you want to know about? The impact of climate change, natural disasters and politics on the supply chain? The impact of a longshoremen's strike on the West Coast?
8. Don't let the technology take over
It is all too easy to get caught up with the technology bells and whistles of the system--and to forget about what the system was supposed to deliver in terms of business value. Technology should always be a secondary focus of your analytics. Getting business results for your company and your department is number one.
9. Create a superuser but avoid becoming a mini-IT
This is a trap that many departments (especially finance) often fall into. Invariably, there is someone in the department who wants more variety in their job, so they volunteer to become the department "IT person." The problem is, you still need this person to do the other work he/she is assigned to do. To avoid this issue, focus on developing a local department superuser who can sit with other staff and train them in how to use the system for the business. Technical issues should be referred to IT or the vendor.
10. Always strive for a "quiet" system
The primary directive of your department is to do the work it is charged to do. For this reason, always strive for a system that just does its job, is always reliable, and requires very little maintenance. Your staff's main job with this system should be capitalizing on its analytic opportunities--not wrestling with it or trouble-shooting it. If your system isn't delivering non-disruptive performance, it's time to sit down with your vendor.