Today’s blog is from David Pires, a Senior Consultant and team lead at InterWorks. David is a Tableau Ambassador and inaugural IronViz winner in Europe who first started using Tableau in 2015. He joined InterWorks in 2017 to help as many organizations with their Tableau deployments as possible. You can reach out to him here.
“You can't teach an old dog new tricks. People who have long been used to doing things in a particular way will not abandon their habits.”
That’s the way the saying goes but I tend to disagree. Simon Sinek famously shared his theory that those who are successful are not so by doing the same thing over and over, nor by focusing on the competition; they are successful by focusing on new ways of adding value to their business and refusing the status quo.
Tableau’s mission has remained the same from inception to this day and that is to “help people see and understand their data.” What has changed is the growth from a small product to a platform capable of integrating with Linux, Windows, AWS, Azure, and anything in between. These are all options administrators have when deploying Tableau in their organizations.
In my experience, both as a Tableau customer and later as a consultant, when it’s time to bring Tableau in, it’s a “choose your own adventure” kind of affair.
- From the ground up, aggressive strategy
- Slow and steady wins the race
- Pilot project followed by aggressive strategy
Let’s look at each of them in detail. We’ll assume that all research has been done and that a decision was made to have Tableau as the enabler in the analytics and BI side of the organization.
From the ground up, aggressive strategy
This type of strategy works best when a limited level of legacy will be ported into the new platform, or the organization is open enough to embrace a change in the way they do analytics. We won’t see many requests for old reports to be built in the new platform, but rather organizations will use this opportunity to review and change the way they use analytics.
It’s also a good opportunity for companies to move into the cloud and leverage the flexibility of platforms such as AWS or cloud-based databases such as Snowflake which run on a pay per usage with incredibly quickly standup times.
The other crucial aspect of this approach is that migration is pretty much nonexistent, and you are building a whole new service which you can model as needed.
An aggressive strategy will have aggressive timelines. Expect this to be a quick effort moving at a quick pace.
I find this type of strategy works best with small to medium-sized companies. This is because those organizations tend to be more nimble and able to adapt to change quicker. That’s not to say you cannot do this at an Enterprise level—you can, but red tape has a tendency of slowing things down.
In this strategy, fully dedicated resources will be required. Depending on the size of the organization, you’ll need:
- Server Admin (manages infrastructure)
- Tableau Desktop Creator (typically analysts focused on creating content for others to consume)
- Data Steward (analyst or IT role familiar with data management, governance practices, and knowledge of how the business uses the data)
- Specialist external resource (PM with Tableau expertise)
Important, too, is the buy in from all parts of the organization—particularly IT. Bringing IT and the business together early in the conversation will ensure the ability to plan for quick execution without delays on provisioning of hardware.
Partnering with an external resource is also key. Ideally, you will be looking at someone who has done this before and can help you avoid getting bogged down by common issues.
Any change in an organization is never as a short as a 100-meter race—and you certainly don’t want to have it last like a marathon. Sit with your sponsors and your team and define realistic goals. Why is this important? You want your senior teams supporting your efforts rather than pushing you towards unachievable deadlines.
Slow and steady
Organizations opting for this type of change tend to fall in two brackets: Those with budgetary constraints and limited capability to invest in a lot of resource in a short period of time, or large organizations prone to greater resistance to change management.
Migration should consider other systems already in place and leverage them as much as possible. There’s a legacy component which will have to be taken in to account. For organizations running on old spreadsheets and looking to make the most of Tableau, a data strategy will also have to be in place. On a smaller scale, Tableau Prep can help speed up the porting of business rules from Excel, whereas if moving towards a fully relational database, a data steward will have to take ownership of the data strategy. This may mean the creation of new views or tables to aid in analysis to be done in Tableau.
There’s no exact science but an 18 to 24-month period is not uncommon for organizations in this bracket to deploy Tableau across the organization. This is not necessarily a bad thing. Sometimes a longer deadline allows the company to manage adoption at a more comfortable pace, resulting in happy end users who feel supported.
In my experience, almost all company sizes can fit into this category—being for a lack of resources, resistance to change, or both.
- Server Admin
- Tableau Desktop Creator (in smaller organizations, this person can double as a server admin)
- Data Steward
- Enablement team (support resources, experts to share best practices, etc.)
- Project Manager
In large organizations with a lot of processes and rules in place, IT is at the center of migration. In enterprise environments we are more likely to see on-premises deployments rather than using cloud. You want the Tableau platform to integrate with most of your other systems. Examples of this may be single sign-on using Active Directory or impersonation using Kerberos. In any case you’ll want to make sure IT takes an active leadership role from day one, providing valuable advice which can save a lot of time and money in the long run.
On the resourcing side, you’ll want to increase the number of data stewards, Tableau Desktop developers and enablement roles depending on the size of the organization.
This is the type of approach where I’ve seen higher rates of success and satisfaction. Typically sponsored by a business unit with the support of IT, organizations look for one key project to use as a proof of concept. Identifying the right project is half the struggle. A successful approach will be looking to add value quickly without having to move many pieces. Can you leverage existing data? Can you solve a business question that has been on the mind of stakeholders for a while?
Once that project is identified, you work toward a successful outcome on an MVP (minimum value project). There won’t be time to test all features and nail all aspects, but you will want to get the majority of your requirements met and, if possible, surpassed.
The second step is to shout from the rooftops. Now that you have identified and successfully worked through your pilot project, it’s time to make a big fuss about it. Showcase it at work, share the insights, share why it worked, and how can others learn from it. From here on, the task should be enablement across multiple business units and leveraging your success to help them grow.
Ideally you will want your project to take between one and three months, depending on the level of complexity. After that, it’s a case of expanding internally using the lessons learned from your pilot project.
This strategy is adaptable to any organization—probably why I have seen the most success in these situations.
- Server Admin
- Tableau Desktop Creator
- Data Steward
- Specialist external resource (PM)
- Internal PM
- Enablement team
Build in time for the project team to dedicate to the project rather than trying to tack it in against the day-to-day activities. The more dedicated time we put towards a successful MVP, the better our learnings will be.
Be prepared to face some push back from colleagues who will tell you their business unit is different. It’s important in this case to back up (with data) the gains that you’ve made. Maybe you removed the need for a manual process or you answered a question that saved the company a large sum of money.
There’s no one size fits all when it comes to deploying Tableau in your organization. You can, however, leverage capabilities across the platform. Cloud is here to stay in the case of Tableau Web Authoring—it’s close to parity with Tableau Desktop. That can be a soft entry to many analysts in your organization.
Make use of the vast amount of experience that can be found in the community. Attend Tableau conferences, join a user group, and ask as many questions as possible. Speak to partners and ambassadors. They will provide you invaluable advice.
On an internal level, make sure to have the backing of senior management. It’s not enough for them to provide budgetary support; analysts need dedicated time to work in and implement Tableau. Work closely with your IT team and involve them from the start to avoid costly mistakes. In fact, the best deployments are those being run by IT and deploying Tableau as a service to organizations.
Whatever way you choose to implement Tableau, make it fun by running hackathons internally, Makeover Mondays, or User Group Sessions. You will reap the benefits of a connected community internally and your users will cherish the opportunity to learn from each other.
Check out this Tableau webinar series to learn more about moving from traditional BI to Tableau—from deployments to governance and more. Take this quiz to see what Tableau deployment might be best for your organization.
This post is part of a series where Tableau Community members share their experiences moving from traditional to modern BI. Read more of their thoughts and lessons learned about escaping traditional BI, a framework for governance, consolidating trust with Tableau Data Server, and scaling Tableau in the enterprise.