Alright Tablites? Welcome to the first in a series of posts that detail how I recently brought Tableau Server into my organisation as an IT Service.
This is part 1 – Initiating your Tableau Server project
It was about 18 months ago that I decided to share the Tablove and bring the application into my organisation as an enterprise level service. We’d have it sitting alongside other infrastructure services such as monitoring, scheduling, storage, server hosting and databases as another tool that application and infrastructure teams could use. The idea was that we’d farm out installations of desktop to user workstations, spin up a resilient instance of Tableau server and empower the user base to generate their content, post to server and share accordingly. I’d also get to realise my goal of bringing in an application that I truly believed would be a game changer. Lovely.
My team would run the service as part of our portfolio and my organisation would gain the benefits typically associated with IT Services – namely the following.
- Greater financial transparency and cost control
- Standardisation and control of user experience
- Improved operational efficiencies such as support, change and incident management
The following series of posts detail how we did that, and the key factors that we had to take into account along the way. As with the commissioning of any new infrastructure service there is much to consider, some of it valuable, some of it just red tape, but all of it necessary for one reason or another. It’s generally a good idea to cover all the bases as the user base in the investment banking world do seem to take a form of delight in exposing any gaps.
Anyway here goes. I’m not going to go into massive detail so if you want more info then do ping me in the comments or on Twitter (@paulbanoub) and I’ll elaborate.
Note that this isn’t intended to be a textbook guide on how to manage a project, it’s more a description of my own experiences and recommendations at my particular organisation.
a. The Sell
Project initiation is always a tricky task. First off you’ll need to convince your manager that your beloved idea is a goer and will bring business benefit. That can take some time and it’s often a good idea to make the request at the end of a live run, to make the manager decision a no brainer. In my case I ensured that we’d been using some of my manually generated viz on a weekly basis for a number of months. My manager doesn’t really give a lot away in terms of what he thinks so I did cheekily make the report deliberately unavailable one week to gauge the reaction. Turns out it showed just how valuable he regarded the reports as the meeting was much less effective without them. That gave me a degree of confidence that I had some buy in prior to asking if we could bring Tableau in as a service. Once I had that then a detailed email highlighting how I thought the business could benefit was enough to convince him that the project had legs.
b. project governance
Next it was time to engage our Project Management office / team. If it’s a project then it has to go through them. Sometimes they’ll play an active part with governance and assistance, other times it’s down to you. That depends on the level of “project rigor” that they class your project as. Rigor level is also directly related to the amount of paperwork hell that you’ll have to go through and how much scrutiny your project will come under from upper management and the project office. High rigor projects typically involve high cost, high risk and span multiple groups or geographies. High rigor also requires high level reporting and stakeholder management tasks which can be a lot of work.
In my case the Tableau service project was deemed as “low rigor”. That meant a fraction of the paperwork, although I still needed to make sure that the project office dashboard was updated with status, issues and milestones on a weekly basis. Very important to fully understand the reporting and governance requirements required by the project office so I’m not missing any of the reports or updates that they need. They’re a sensitive bunch and need to feel involved. Unfortunately low rigor projects don’t (in my organisation) qualify for assistance from a dedicated project manager so I was on my own in that respect.
c. Initial project documentation
Now it was time to fill out two key documents. The “Project Charter” and “Project Approval Request” (PAR) documents. The PAR is a higher level summary of the project and the costs involved and is effectively where the project is sold to the people who sign off the money. Once I got the green light for the PAR then the Project Charter provides the greater level of detail.
- Project background, requirements, scope, drivers and success factors
- Schedule, milestones and risks
- Roles and responsibilities, changes and communication
In my case we were starting small, with a less than 50 licences for Tableau Server. The plan being that when the system was key to the business with all of the appropriate buy in I’d have a case for the expensive unlimited user core licence. That made the PAR a reasonably easy task to get approved, although it still came in for scrutiny. Unfortunately IT is a cost center rather than a profit center and any spend tends to get questioned.
Cost wasn’t as simple as just the number of licences we needed. There are many components to an infrastructure service that may not all be obvious.
- Application licences – in my case the server licences and desktop licences for my immediate area. Our model was that interested users from other teams would fund their own purchases of desktop. Most software licences are perpetual, meaning that you’re allowed to use their software indefinitely.
- Maintenance – Ah maintenance. The often overlooked ongoing cost. Maintenance costs are yearly charges per licence that are needed for Tableau or any other vendor to provide you with support. If you don’t pay the maint then you’re on your own if you get a problem. In Tableau’s case it’s about 20% of a desktop licence cost every year. Often good to detail out how the 5 year picture will look to your organisation. It’s also critical to get this ongoing cost into your budget plan for then next few years so managers don’t get taken by surprise. Also vital to make sure users know what they’re signing up for.
- Recharge model – IT recharge (or chargeback) is a method of recouping IT system costs from the users of that service. It usually takes the form of a regular annual charge and can be based on a number of factors. We went for number of users on our server per department. For more detail on recharge – see here.
- Server hardware – each box has a cost to the business, usually a flat figure depending on the specifications and platform. These costs generally include – hardware, operating system, data storage, datacenter occupancy charges and also any additional services that might come with each server by default such as monitoring, scheduling and backups.
- SAN Storage – If you’ve got a lot of potential data to store then you’ll need a Logical Unit Number (LUN) carving off from your Storage Area Network (SAN). That can be pretty expensive so we decided to keep this to a minimum and expand should the need arise. For more on SAN – see here.
- Disaster Recovery – In most environments you’ll need to replicate your infrastructure to the DR or backup site. In the event of a site failure from either a technical issue or human disaster the IT systems will need to be able to run from the DR site. These costs need to be built into your service model. Some vendors will charge less for a DR licence than for the main production licence.
- Development / QA environments – You may want a development environment to test with. Very useful for trying out upgrades and bug fixes to reduce the risk of outages and risk to the production systems. Development environments tend to have lower costs than their production equivalents, usually because they have lower specifications. Ideally you’d want the environments to be the same specification but this is often an area that management see as potential cost savings. Vendors also usually charge less for development licences and sometimes give them away free. In this occasion we decided not to install a development environment to keep the costs as low as possible. We could always add one later.
For anything cash related it is critical to make sure you’ve got some involvement from your friendly local Procurement team. They’ll take away much of the pain in terms of getting the contracts signed etc and might even negotiate a bit of a discount. In my case that wasn’t really an option given our lack of licence volume leverage.
So – after all that I had a project. With appropriate documentation and approval. Costs were clear and management knew the score – no nasty surprises. Managers hate surprises. My licences had been delivered and I’d had a good few chats with Sarah Bedwell (nee Henselman) of Tableau. She was great and seemed positively interested in building a relationship with me as a customer. That made a change to experiences with many other technology vendors.
Next up is Part 2 – Design of the Tableau Server architecture
Check back in a week or so for the latest episode.
Remember – keep spreading the Tablove.