White glove service, is a service offered unofficially within a corporation or large company for items that are classified as important from a business or process point of view, but don’t have a genuine importance from a hardcore finance or business impact.

An example of this would be if you had an issue that would stop a project release to production. This is very important to a project and to the leadership team, but does not result in an immediate financial or regulatory cost to the business. Therefore, you could not merely raise it as a Severity 1 issue, and let the existing incident processes manage it.

These needs however are important, but not in a traditional sense, and you need what is often called a white glove service to deal with them.

What does a white glove service consist of?

A white glove service consists of a number of allocated, named individuals. These then take responsibility for issues, they will own such issues and work with the stakeholders or people that raised them to ensure that they are completed.

At no point until the issue is resolved can they let go of it, even if it’s beyond their control, they have to hold on to it until It’s completed.

• They do this by ensuring departmental walls are breached to reach a solution.
• They consistently provide reports to the stakeholders, even if there has been no change to report (often the update period required by a stakeholder is far more frequent than there are updates to provide). Communications, however, must be managed.
• They must be effectively on support call. There is no clocking in and out if an issue is raised, regardless of when it is, they must respond. (It is recommended that there are at least 2 named individuals for each of the 3 main global time regions. Asia Pacific, Europe, The Americas to cater to this).
• They must maintain trust between the different areas of the corporation , if such a person comes seeking a teams assistance, it will be for a genuine reason.
• If the issue is caused by a process or other genuine reason (and not merely poor stakeholder and management planning), they must produce a root cause once it is complete.

Skills needed:

Strong areas of knowledge: it must be at least 2 of the following:

• Business process knowledge and what is important to the business.
• I.T. knowledge in order to be able to negotiate with the various silos within the corporation
• Internal process knowledge, who to go to, where to go to, what processes need to be done in a perfect world,

Things a White Glove service must not do:

• Use up the time of valuable subject matter experts: they must not occupy more time than they save for existing resources, and should stand in for technical and business people on calls to actively free up time to complete requests.
• They must never be seen as a threat, only as an assist. They must never use words like escalate or name drop, or anything that triggers a defensive reaction.
• They must not devalue existing processes and people, to do so will just make the problem worse. They must always be someone who can explain the truth to power.
• Just become a status report proxy, they do not ask subject matter experts to do any admin tasks, they take on such activities e.g. ticket raising, and allow experts to complete genuine work.

How do you get people to do this pain in the butt role in a corporation:

For External Staff Members: Money normally does it for both independent contractors and vendors; they are happy to do this function and do it well if the price is right.

For Internal Staff Members: A stint on the ‘white glove’ service grants broad understanding of your company’s needs at a practical level and shows commitment, this can be used on yearly evaluations, and helps to identify people who should be fast tracked.

Back in the old days, we had very strong development to production demarcation rules, and this was very simple, because there was very little integration. In fact, usually the only time that we had blurred lines was the use of email, where if you got a test email wrong, it would escape into the world and cause never ending troubles.

Then along came the cloud. The cloud comes with its ability to spin up multiple instances of the same type of environment to apparently make the lines between Dev and all other environments very clear cut.

But inside a corporation, you’ll find that this is not the case, because underneath all of your nice, neat environments there is the same infrastructure with the same shared services, so you soon find out that when you request something, what you think is a simple and limited development environment request will actually mean weeks of justification and the full change release process.

The most common of these is firewalls. If you want to open a firewall between you and another environment, such as a vendor service. That is actually a change to a production area and will be treated as such. You will find this will be true of most network situations, and particularly with most data transfers to things in the cloud, which will even for simple proof of concepts require sign off by your security services. So if you are planning that, do not assume that a request for dev access will be instantly acted on, you will have to do the same justifications, as if you were dealing with production.

1. mainly support or those that look after production systems in any way[↩]