BYOD concerns? It's time to dust off the ITIL service strategy book!

It's time to grab the duster to dust off your ITIL service strategy book
It’s time to grab the duster to dust off your ITIL service strategy book

At this year’s itSMF Australia LEADIT14 Conference I am speaking about what the BYOD revolution means for ITSM evolution. I will be looking at each of the 26 ITIL processes and how they will need to change or adapt in the face of BYOD.

Whether we like it or not, BYOD is here to stay

Recent research by Gartner states that by:

  • 2016, 38% of companies expect to stop providing devices to workers
  • 2017, half of employers will require their employees to provide their own devices
  • 2020, 85% of companies will provide some sort of BYOD program

Despite the challenges that BYOD brings, the proven benefits of BYOD can be recognised with a sound BYOD strategy. Increased productivity, increased staff satisfaction, attraction and retention of talent are some of the benefits that can be realised.

The ITSM processes within the ITIL Service Strategy are pivotal in ensuring that you get your BYOD strategy right.

Start with Strategy Management for IT Services

Is the driver for BYOD within your organisation the result of senior managers wanting to access corporate data on their latest device? Or does it align with the organisational strategy and business drivers such as cost reduction, increased productivity, increased mobility, talent attraction and retention, competitive advantage etc?

How will BYOD enable the organisation to achieve its business outcomes?

Once it has been decided that BYOD is an integral part of the organisational strategy, the strategy for the BYOD service can be defined during the Service Portfolio Management process and documented in the Service Portfolio.

Service Portfolio Management

The Service Portfolio Management approach of ‘define, analyse, approve and charter’ applies to the BYOD service as it does to any other service under consideration as an offering to the organisation.

Questions that need to be asked during ‘Define’ include:

  • Which employees, employee groups or user profiles need access to BYOD?
    Does BYOD extend to consultants, contractors, partners etc?
  • What sort of mobility is required and by which employee groups? Are they home based, office and home, on the road?
  • What types of devices will they want to use?
  • What privileges or permissions do they need?
  • What data will they need access to?
  • What is the risk profile of the data?
  • What applications do they need?
  • When will they need access to resources and which resources?
  • What functionality will they need e.g. initiate web-conferences, run reports on corporate data, access HR systems etc?
  • What integrations will be needed e.g. CRM, ERP etc?
  • What is the best way to engage employees to accommodate modification necessary to their devices for security such as encryption or authentication?
  • How will devices be supported? Do we outsource support? Do we ‘time-box’ support in that support only spends so long trying to resolve an issue and after that the user is on their own? Do we only support commonly used devices?

The list goes on.

Service Portfolio Management will also need to look at what will be contained within the BYOD policy. The trick – and easier than it sounds – is to come up with a common-sense policy that allows employees to use their devices without jeopardising security.

The reason I say this is that recent research of 3,200 employees between the ages of 21 and 32 (the Gen Y demographic) revealed that more than half (51%) of the study’s respondents stated that they would bypass any BYOD policy at work. We have to recognise that these workers were raised to consider access to information a right, not a privilege. They are accustomed to being connected to information – and one another – at all times.

There is not enough space in this article to go into detail about what should be included in a BYOD policy but there is much available on the subject via the Internet.

When the BYOD service has been defined, analysed and approved, it can then be chartered. Service Portfolio Management will need to ensure that the provision of BYOD as a service remains viable and where it is not, consider whether elements of the service can be retired.

Financial Management

You’ll need Financial Management to investigate the cost of providing a BYOD service including the Return on Investment  (ROI) and Return on Value (ROV). Whilst organisations may realise cost savings through reduced hardware purchases and perhaps support costs, there may be increased costs in additional security and administrative systems and infrastructure investment.

Organisations may have to provide equipment allowances such as employee interest-free loans for new devices, stipends etc. and allowances for applications purchased for work-related purposes. These additional costs need to be weighed up against the inherent purchase and support cost savings of BYOD along with the ROV of employee engagement, retention, satisfaction, and productivity.

Financial Management needs to consider aspects such as – who pays for the device usage? If an organisation only wants to recompense for work related calls and data, this could put a large burden on the financial team who will have to validate all claims. This poses a challenge to forecast and manage cash flow.

Business Relationship Management (BRM)

BRM is crucial in the establishment of a BYOD service and determination of the business need behind why people want to use specific devices. Is it just a new fad or is there a real business driver? BRM should work with the business to look for business efficiencies and technology advances that can make jobs easier or provide benefit to the organisation.

Demand Management

This will be pivotal in determining the demand for the service? Where and when will the demand come from?

At itSMF Australia 

So that is just a taster of how the Service Strategy processes will need to operate to support BYOD. If you want to hear how all the other ITSM processes will have to adapt for BYOD, come and hear my presentation at LEADIT14. We haven’t even touched on Information Security yet!! You can find out everything you need to know about the conference here.

Image Credit

Stop Blaming Release Management!

When releases fail, we often point a finger at the release manager, expecting that person to make the necessary corrections to prevent similar failures in the future.  In doing so, we miss the real target – the service delivery flow.  This flow, with its many inputs, is in disarray in most organizations and the solution seems daunting.  This article proposes that there is a simple, inexpensive, and self-healing approach to improving the flow of service modification.

When a Release Goes Bad

The scene is too familiar.  The service desk, on the verge of panic, is swamped with increasingly irate calls.  The boss is on a bridge line with a host of managers and technicians trying to restore order.  The business units, demanding action, are banging on the CIO’s door and the echoes reverberate throughout IT.

Last night, IT distributed a major release of a critical business application.  Today, users are converging on IT with torches and pitchforks.  The business application update had an enormous impact on productivity and revenue.  The impact continues as the business owner demands that the changes be “backed out” – a request that IT finds exasperatingly difficult to satisfy.

When the dust settles, it is not uncommon to see root cause analysis identify the numerous mistakes made in the “release”.  The list might include:

Table1
Common Issues and Likely Culprits

Who is to blame?  Release management?  Of the 11 mistakes listed, 9 belong to groups outside release management.  Yet, in many cases, release management will still take the heat.  The purpose of this article is not so much to absolve release management but rather to bring understanding to the larger service lifecycle in hopes that the readers can address the true causes of release failures.

Know the River

Release and deployment management is just one part of a much larger lifecycle.  Think of it as a port along a river.  A business service starts out as an empty barge on the business dock.  In ITIL terms, the manager of that dock, Business requirements management (BRM), loads the barge with service requirements.  In the diagram, this is the “Identify” stage.

Service Flow - Stages, Participants, Output
Service Flow – Stages, Participants, Output

The barge makes a number of stops on its way down the river.  Along the way, the manifest of the barge is equivalent to the seldom referenced (but, in some form, always present) service design package of ITIL.

When the barge, stacked with cargo, finally pulls into the release and deployment dock, the only issue should be how to transport the contents of the barge effectively and safely to the appropriate recipients.  One could think of release and deployment as a trucking company.  The truckers did not design or build the cargo.  Nor are they to blame if the item in the package performs poorly.

I recently ordered a manual online.  The package arrived in the expected time frame and was intact.  As I read the manual, I noticed that an entire section was missing.  Should I blame the trucking company?  Of course not.  Likewise, we should not hold the release management responsible for defects over which it has (by design and best practice) no control.

The following table might help to identify the “river ports” where the service barge might be picking up sub-standard cargo.

Service Lifecycle River
Service Lifecycle River

Look Upstream

In order to effectively manage and improve the delivery of a release, we need to focus on three major points:

  • Transition review
  • Service delivery package
  • Project charter
Feeding the Transition Review
Feeding the Transition Review

Transition Review

The objective of the transition review (post implementation review) is simple: Learn from your mistakes.  When an organization first commits to regular PIRs, they may be a bit disorganized.  As inputs and outputs become better defined, so will the overall process.   The transition review is the spawning ground for improvement of this lifecycle.

Service Design Package

Although few enterprises seem to understand the concept of the SDP, it is, in my opinion, a brilliant addition to ITIL v3 2011.  When organizations address the output of Transition Reviews, they inevitably make adjustments to the SDP because it is the mechanism for improving consistency, governance, and effectiveness for the service modification lifecycle.

Project Charter

In most shops, the service modification lifecycle begins around a table of senior managers.  The beginning of a project needs to be less about hierarchy and more about process because this is not a hand-off; this is a flow.  Four players are critical to the project charter.

  • Business relationship manager – understands business requirements.
  • Service portfolio manager – understands the pipeline and service catalog.
  • Service level manager – understands issues that might impact service levels and process.
  • IT architecture – understands the importance of a consistent framework.
Deming's PDCA Organic Flow
Deming’s PDCA Organic Flow

With these, the organization understands business requirements, process, and infrastructure within the context of service delivery.

Completing the Circle

With the project charter, service design package, and Transition Review, we have completed the deming circle (Plan, Do, Check, Act).

Most shops fall short in planning and checking because these activities are poorly governed and too loosely integrated into the overall flow.  As Yoda would say, “Without plan, no do; without check, no act.”

Start Small but Start Smart

When a release fails (especially when it fails in a spectacular way), the fault generally lies in the process.  If, as I assume, this is common knowledge, why do these broken processes persist?  Because most enterprises perceive that process optimization costs too much money, takes too much time and does not meet more immediate business objectives.This reticence is understandable given the typical consulting approach.  A consulting firm will probably suggest starting with a comprehensive assessment that forms the basis for a massive proposal that drains resources from business-critical initiatives.

Instead, insist that any partner (consultancy) starts simply.

Enable the Flow to Manage the Activities

The degree to which this lifecycle is managed is inversely proportional to the likelihood of failure.  The simplest way to manage a lifecycle is shown above in the Deming diagram.  The idea is to implement the organic lifecycle flow and let the flow improve the subordinate activities.To accomplish this, we need to implement the flow with the associated roles.

Step 1 – Establish and Empower the BRM Role

The business relationship manager role usually exists in some tainted form.  We need to plug this role into the organic flow.  This role seeks to understand the needs of the business but, just as important, collaborates on those requirements throughout the service lifecycle.  As mentioned above, the BRM is critical to project initiation.

Step 2 – Establish and Empower the Enterprise Design Coordinator Role

The enterprise design coordinator is really the key to success.  There are three main tasks for this role.  Aside from coordinating design and build activities at a high level (not an application development manager), this role also a) ensures that the input from the BRM is adequate and b) ensures that the service design package is complete and accurate.

Step 3 – Establish Policies and Procedures for Transition Review

The release manager (hopefully already in place) will collaborate with the BRM, design coordinator and stakeholders to create policies and procedures for transition review.  The guiding principle for transition review should be that it examines service transition output (incidents, issue logs, metrics) to identify opportunities for process improvement.

Step 4 – Establish SIP Procedures

The output from the transition review will sometimes include a service improvement plan.  The organization needs a standardized procedure for initiating and implementing an SIP.

Step 5 – Do it and Keep Doing it

We have created the organic flow.  We only need to execute it.  Each SIP will improve the effectiveness of the service modification lifecycle.

Note on Change Management

Change management, from an enterprise perspective, plays a significant role in controlling the flow of the service lifecycle.  Most organizations perceive change management from an operational rather than an enterprise perspective – an outgrowth of legacy implementations of IT change requests.  This narrow focus deprives the organization of the true power of this governance process.  I would have enjoyed weaving into this article the benefits that a cohesive and integrated change management process could provide but it deserves a separate piece.

Conclusion

Release and deployment relies, for its success, on a number of upstream processes.  Business relationship management and design coordination, both new to ITIL v3 2011, are key to managing the upstream service lifecycle.  Though they may seem unfamiliar, everyone has implemented these processes to some degree but few have implemented them effectively.  This oversight poses a risk because any enterprise that does not consistently manage the entire lifecycle does not control the operational outcome.  In other words, every release is a roll of the dice.

Feeling lucky?

The Beauty & Simplicity Of Common Sense Business Relationship Management

itSMF 2014

Following on from my trip to itSMF Norway last week, I wanted to share with ITSM Review readers my thoughts on Andrea Kis’ presentation on “The Beauty & Simplicity Of Common Sense Business Relationship Management”, along with some of the key pieces of advice that she presented.

This was a great presentation because it didn’t matter what part of IT you worked in, or even if you didn’t work in IT at all, the message was still applicable to you (even in our personal lives). Andrea explained the importance and benefits of creating a relationship with everyone that you meet. She also discussed how we MUST stop referring to IT and the business as two separate entities.

Advice from Andrea

Key takeaways and advice from her session included:

  • Don’t refer to BRM as a process or a job title. It’s neither, it’s a skill
  • Don’t underestimate how something very small can lead to a much larger problem. One small relationship issue between two colleagues can easily cause much larger issues for your overall service delivery
  • You can’t implement BRM, it’s something you must practice every day
  • The focus must always be on the relationship from the viewpoint of the customer. Just because you think the relationship is working smoothly doesn’t necessarily mean that they feel the same
  • The little things matter. When delivering hard decisions if you have a relationship with the person you are delivering said decisions to it will be easier. They will trust you
  • Always lead by example

The advice didn’t stop there though, and we will shortly be publishing an article on BRM direct from Andrea herself.

Other points of interest

What I found particularly interesting in this session was that nobody in the room seemed to be aware that BRM was in ITIL v2011. This confirmed my belief that we place too much emphasis on what we have always done (incident and change) and too little on new ideas.

Andrea finished off her session by naming the six competencies of relationship building. How many do you follow?

  1. Inspire
  2. Influence
  3. Develop (relationships)
  4. Initiate change
  5. Manage conflict
  6. Establish teams and collaboration

As a piece of bonus advice for anyone reading this, I asked Andrea “if you could only provide one tip when it comes to BRM what would it be?”. Her response was “JUST DO IT. Stop questioning where to start and just do it”.

Think you’re good at relationship management? Did you stop for coffee on the way to work this morning? If so, do you remember what the person who served you your coffee looked like?

itSMF Estonia Conference

estonia
A few faces from last year’s event…

We are excited to announce that we will be the Official Media Partner for the 8th itSMF Estonia Conference on 11th December at Swissotel Tallinn.

The event brings together ITSM practitioners from the private sector – banks, telecoms, energy sector, software companies, etc. – and the public sector for mutual experience sharing.

While the majority of the delegates are from Estonia, a sizable number of delegates from neighboring countries (the Baltics and the Nordics) and the rest of Europe are already confirmed to attend, after hearing feedback from their peers about last year’s event.

What you can expect

  • One full day of presentations, all in English, from well-known and respected specialists and practioners from both Estonia and abroad, covering topics including, but not limited to: Business Relationship Management; Problem and Knowledge Management; getting value from proper approach to services and processes; the future of the service desk; and the beyond cool way Estonian public sector provides IT-enabled services to citizens
  • A special presentation from the CEO of AXELOS, Peter Hepworth, sharing his vision on the future of ITIL
  • An international forum with Axelos, where the aforementioned vision will be discussed and delegates have an opportunity to ask questions, voice concerns and provide input

There is also the opportunity (at a small additional charge) to attend two pre-conference workshops (on 10th December) run by industry-renowned Barclay Rae:

  • ITSM Optimiser – making the most of ITSM (an interactive workshop that looks at current and new trends and practices, providing attendees with new ideas and options on how to make the most of their ITSM operation, processes and tools)
  • Memorable Metrics – producing reports that are valuable and actionable (this session identifies issues with current IT reporting (particularly operational reporting) and provides practical suggestions on how to improve and develop really useful reports and metrics, targeted for different stakeholders)

Our very own ITSM Research Analyst Rebecca Beach will also be in attendance. If you would like to schedule a catch up and/or one-on-one meeting with her at the conference please contact her directly. We are interested in hearing from all attendees whether you are a vendor, end-user, consultant or other!

We hope to see you there!


Event Summary

WHAT

itSMF Estonia Conference

WHERE

Swissotel Tallinn

WHEN

Wednesday 11th December (with pre-conference workshops on Tuesday 10th December)

BOOKING

Booking rates start from just €45, find out more