Best Practices for Tessitura Assistance Requests within your organization

Melissa Payne said:

Do you have a request form you use for your organization?

We've tried to implement a form once or twice years ago, but their use hasn't stuck. I try to get people to use our internal support ticketing system and not just send e-mails, or (worse) stop me in the hall with a verbal request, with varying levels of success. Best of luck to you in herding the cats at your org! :-)

Melissa,

An excellent question.  One with which I certainly have ebbed and flowed many times over the years.  I have finally gotten things to a good flow here, but I also have the benefit of a decade plus with both the software and the organization.  I would love to say that I have a sheet that outlines everything, but we do not do lots of things like that at my organization, so I do not really have anything of that nature.  I merely respond when asked how much time I think it will take me.  And I ALWAYS assume longer than my gut reaction tells me it will take.

And the first thing is, as you say, to set clear expectations.  This sort of project takes THIS much time; this other one this OTHER amount of time.  And, even if YOU finish it early, be careful of actually delivering early.  I am normally a very open, happy-go-lucky sort of person who likes to be awesome at his job, get things done ahead of time and make people happy.  But I have learned for things like this that it is definitely okay to deliver only as promised and not before, even if that would have been possible.

The other side of it is, and this has been harder for me to do given the sort of person I am, is to actually let your frustration show through.  Last minute requests from higher ups who have no idea what it takes to come up with the data/results happen to us all.  But it IS okay to show them how much it is in fact basically ruining your next day/weekend/week/etc... to do whatever it is they want you to do.  And of course, there is always the kicker option that "No, I cannot get that done in the time frame for which you are asking".  Sometimes that is just the honest and best response.  Which can often lead to other, usually better questions about HOW things are done in general and WHY there was such a last minute request for something so big.  Because they ask why you cannot do it, and you start explaining about how all the data relates to itself and the challenges involved, and their eyes go all glassy and they ask not to be drowned in jargon that they do not understand, and you emphasize that this is your job and precisely why we need to have these discussions because just in the way that THEY could not produce a last minute X (whatever is relevant to their job) you also cannot produce this last minute Y for them.

Sorry I have no forms/outlines to provide for you.  But I have certainly dealt with this over the years and do certainly feel you here.  Best of luck!

John A. Moskal II

We call these high-priority, low-warning projects 'meteors'! They burst onto the scene, are very important, very urgent, and have little (or no) warning or lead-up time to them. Meteor mindset is often contagious within an organization. Ultimately, there needs to be a respect for your time as an admin. You are good at your job, but not ominipotent. Each project takes time, especially the important ones.

There won't be a one-size-fits-all response template, but the biggest thing is clarity (of expectations, requirements, and your bandwidth), and consistency. You want to do good work, and that means being thorough and precise. Being thorough and precise requires time. Responding in a consistent, calm, professional manner to each project request will help to build (and manage) expectations on either end of the projects. Good luck!

Here is the process I've put in place at at the Kalamazoo Arts consortium.

I had a lovely offline discussion about this the other day with JAM2.0 and Gawain so thank you for posting. 

I'm the Director of Customer Exp at STC and I look after Box office,  Front of House, Ticketing Systems,  Analytics and Insights, and Database and Apps. I'm also the Tessitura Product Owner here. I've just managed to build out my dream team. 

We have a product team with reps from the engaged business units incl digital marketing,  production etc. They are great folks and are our super users. 

We also have a (loose) agile scrum team that works on things thrown out way consisting of the DBA, me, Analytics Manager, Ticketing Manager, and occasionally special guests.  We have a roadmap Meeting each week. Where we discuss and adjust, and have done daily stand up. 

To get on the roadmap we have a pitch document which we are re writing in madlib format. They pitch the business need, their time saving and we set up a short meeting to scope it. We estimate our labour cost based on the best solution add in maintenance asand then let them know the time frame. 

My boss is hugely into ROI, and protecting the teams from Burnout. It's a great help. Getting that expectation management into the org early and sticking with it is key.

Now when I was at a tiny org it operated on a similar system of handing out buils forms.

We use Jira as a support ticket platform and have everyone trained to "put in a ticket" for everything from adding security rights to new user requests to errors.

For Tessitura ticket builds, I use a Microsoft Forms form that has a shorter version for "This is the same as last build, just more dates" or expands to more questions of it's new or different. In that form I also ask for a link the their marketing Jira ticket, and both Marketing and I work off of that marketing request to coordinate on sales and content. 

I then have that form tied to a "Flow" using Microsoft Power Automate that adds a notification that a form was submitted to several Teams channels and shoots off some emails.

Lastly, we have a 'product catalog' for all of Tech that lists our services and estimated time frames.

Getting more service-providing departments (IT, design, marketing) into one platform (Jira) has really helped both the requesters and the providers to have one place for all requests.

And of course we still always have "I know this is last minute but..." requests that I handle as I can. I've only ever had to say hard no to one build but that's because I'm too nice. 

In my experience, these requests happen because the basic understanding of what is already in the pipeline is not being communicated effectively. A form is an important part of the process, but education of the process and what is both currently in the pipeline and what is coming in the future is vital. 

We use a system that communicates and allows everyone to see what is happening organization-wide. You can use Excel to do this but if you have the budget, Miro is a great visualization tool to get you started. We plan by fiscal quarter and use three main categories for the visualization: Blackout, Big Projects and Ongoing Small Projects. I'll briefly explain these below.

• Blackouts: During the initial layout of what we call the Project Board, we identify things that are already scheduled on the calendar. For us at the museum this could be large exhibitions, holidays, important dates (like everyone's planned time off or typical times of year/season that are extra busy like budget time or spring break). Anything that might make or impede the ability to complete a task.
• Big Projects: Pretty self explanatory. You would brainstorm what big projects may be coming up. We define big projects as projects that cross departments or take multiple resources (internal and external) to complete or even something that will take more than a set period of time for a resource (our threshold, though not firm is 40 hours). Things like system changes, operational changes, research projects, etc. 
• Ongoing Small Projects: Again, somewhat self explanatory. These are smaller projects like monthly or quarterly system updates that only take a few hours, or data clean up. These are not necessarily tasks that are assigned (through a support desk or a supervisor, but they could be, depending on the level of detail required).

We try to brainstorm these out two years on our Project Board by quarter. 

Here is where the forms come in. We do have both a technical support desk that collects requests as well as a few forms (one for Report creation, one for Ticketed Exhibition builds and one for Promo Codes). These are evaluated by a small, cross departmental team and added to our project Planner (Microsoft Office Planner) or assigned in the support desk solution. 

The point of my rambling is, the Project Board makes it easy to show anyone what is in the pipeline and what is currently being worked on - small and large. When upper management comes in with a last minute big ask, you can take a look at the board and ask which projects they would like to put on hold (as hopefully, you have on your Project Board, the projects they have asked for previously) to slot in their current request. In some cases, they will simply say that they can wait on Project X while you work on the new, urgent request. In other cases, they will quickly determine that the current urgent request isn't so urgent and you can initiate a conversation about where it fits into the Project Board.

Another benefit is that you also now have a great way to look back at all the things that were accomplished for the year/quarter/month. 

hope you find this helpful. Cheers!

It's incredibly important to manage your time load, or you'll burn out. If you are having trouble pushing back  see if you can get a sponsor or executive to back you. I explain that we can't cut corners on testing without major risk of failure in the system

Thank you to everyone who has responded so far. A little more detail about my situation, as the database manager, I'm one of the main users in my organization. FOH uses Tess the most besides me and then there are a few others that use it for some development tasks or setting up events. Luckily I'm part of a consortium that has a help desk, so some larger tasks (like building facilities) goes to them, but it also creates some tension when I get a request last minute and then have to turn around and request that from them. I'm a people pleaser, and I hate telling people no, but it seems like more and more requests are coming in without little thought to how long it might take, so that's where my motivation for this came from.  I will definitely be implementing some of these suggestions in here and being a bit more firm about what I can and can't do when these last minute requests come in, as it's becoming overwhelming and a bit frustrating.

Hi Melissa,

Judging by your response above, I'm guessing you are talking more about the smaller last-minute requests than bigger, long-term projects?

I am also the Database Manager - part of a 3 person team - and we deal with both types of issues. We generally insist on a 5 day turnaround for all requests, but the nature of our industry means that we often have urgent stuff to deal with and have to be able to produce data, solve problems or set shows up very quickly.  However this 5 day turnaround is embedded in the mind of everyone in our organisation and they tend to take it into account when asking for something. Of course we almost always do things much more quickly than this.

Regarding longer term projects, we have a fortnightly meeting attended by at least one Tessitura-friendly representative from each department. At this meeting we discuss upgrades, upcoming sales, issues arising, etc. If anyone has something they would like the database team to address then this is a good place for them to introduce it and for their expectations and our delivery capabilities to be discussed publicly. You also find that what one person wants may not be what suits people in other departments and there may be valid reasons against implementing what they want.

We are a pretty well organised department, but our plans changedaily depending on what the business demands. This is is unavoidable. I also feel the pressure to please everyone, but sometimes it just isn't possible, don't be scared to say no, or at least not yet.