The desktop provisioning palaver

Policy, practice and patience

Workshop Setting and maintaining desktop policy and provisioning equipment and software sounds like something that should be done once and then left to gather dust while people just get on with things in the knowledge that it’s all been agreed.

Perhaps this would be practical if such interesting developments weren’t afoot in consumer device and freebie software land - and if we could lock down human nature indefinitely.

Simply having a policy in place to govern the provision of hardware and software to users isn’t enough. You won’t need to look very far to know this is true to at least some degree in your organisation. You also probably know when the last time a non-standard piece of kit or software caused a user - or you - strife.

On the other hand, when was the last time the policies governing this area were reviewed? What may have seemed eminently sensible and fair two years ago might not be seen as such today. The first place to look when considering a review in this area is the policies themselves.

Despite the lure and impact of consumerisation, setting hardware policy is the easier task to address. Relatively speaking, this involves a review of user requirements followed by any appropriate updates to the existing hardware policy. And that’s kind of it. The challenge is finding the time to do it, and then asking procurement nicely to assess a range of suppliers.

The latter may be a more achievable goal for a larger organisation due to the potential for discounts on bulk orders. In both small and large businesses, however, there may be some user resistance to kit standardisation, depending on whether you are simply tweaking an existing policy or attempting to make some considerable changes.

It’s one thing setting out policy on the hardware side and acknowledging such issues as the creep of consumerisation, but quite another to drive standardisation on the application software side. It may seem like an easy task to identify the core software apps in use, but only an in-depth knowledge of the different groups and sub groups within the user base will help identify the ‘real’ software portfolio in use, and the degree of user sensitivity that exists around particular applications.

Ultimately the problem lies in persuading the users to move from their favourite app to your standard one. On paper it’s a simple list: supported/official vs not supported. It’s all a very human challenge.

In practice, the impact on the business may not be felt until certain things are removed. Thus a fundamental part of the process is to talk to the users and really get to grips with the range of software they actually use to do their jobs versus the software they are supposedly using.

But despite the human factor, it’s worth remembering why we’re trying to get a handle on all this in the first place. As it happens there is a multitude of reasons, motivations and hence justification for not only taking action, but expecting support from on high to do so.

Ultimately the major benefit is saving money. Easily quantified opportunities include better deals on kit through standardisation and bulk orders (subject to the size of your business/order of course). But the big savings lie on the software side, even though it may be the toughest area in which to persuade users to comply with policy in practice. Indeed, auditing, rationalising and then managing as tightly as possible the portfolio of paid-for and supported software applications and the user base is likely to yield cost savings for most organisations.

Softer savings are also up for grabs in that management overheads should be reduced as the number of different devices and software products IT supports in line with provisioning policy are reduced. Needless to say, fewer different devices and software means less stuff to go wrong, fewer suppliers to manage, fewer maintenance contracts and fewer support calls, not to mention reduced security risks from the reduced attack surface presented by a smaller application portfolio.

Tightening things up here will make the IT department’s life a little more straightforward and hopefully free up some welcome cash. Starting the process and maintaining a consistent desktop provisioning regime won’t create a permanent state of peace and harmony – uppity users will crush that dream - but it may at least begin to provide some breathing space and help the IT department get onto the front foot.

However, a word of warning: if making your life easier is the sole motivation, then going through the motions and reducing choice and access (in the eyes of the user) without consultation and plenty of brow-smoothing risks creating a lot of aggro, even though IT probably feels rightly justified in cracking the whip.

The good news, however, is that none of this needs to be attempted at once. It’s not an overnight task - more a program of consult/act/review which could be set in place over an 18-24 month period. That way, tasks associated with the program are not overly time-consuming or ‘oppressive’ in terms of expecting the users to cope with significant changes at once, and senior business management’s interest can be maintained with an accompanying Blue Peter-style savings ‘totaliser’.

Workable policies work because they are designed appropriately. However, getting users’ buy-in requires a different skill set – a blend of diplomacy, bribery and a big stick. Naturally, support is required from business leadership, and, given their love of efficiency and cost reduction, it’s fair to say that you may be able to attract their attention and support by leading with these elements. However, they may also care about the harmony of the workforce and their ability to do their jobs properly. Be prepared to balance the hard and soft metrics.

Putting all this into context then, we’d like to know what you’ve achieved in your IT department in this area. Did any parts prove themselves surprisingly easy to address or, in contrast, a royal pain? ®