Print Page | Contact Us | Report Abuse | Sign In | Join
The ITSM View
Blog Home All Blogs
This blog, written by itSMF UK leaders and guest contributors, offers service management thought leadership and discussion of industry trends. Please feel free to comment on these posts (you will need to be logged into the website as a member). We look forward to hearing from you.

 

Search all posts for:   

 

Top tags: ITSM16  PSMF  ITSM  Q&A  Service Catalogue  SIAM  business change  Career  DevOps  Podcast  problem management  Release Management  Service Transition  SITS16  Are we the wrong people in IT  Automation  BCS  CGI  Digital Transformation  Event  EXIN  IOE  IOT  ISACA  IT4IT  ITIL  ITSM15  Managing Complexity  Organisational change  Scopism 

The Millennial Shift: How to Bring New Blood into ITSM

Posted By Sandra Whittleston, 08 July 2016
Updated: 07 July 2016

 

Very often when attending IT Service Management (ITSM) events and meetings, discussions focus on the newcomers to our industry. Popular questions include, “where is the new blood and where it is likely to come from?” and “how can we encourage new people into our industry?” Teaching ITSM to young people and older career changers whilst they study on university programmes sends hope for the future because of the way that students engage proactively with the concepts and easily join in debates. This is primarily because they understand the service culture and often have strong opinions, both of which can have a positive effect on how they approach their studies.

 

There is no doubt that young undergraduates learn best when using technology, respond to different assessment types, can socialise, take global stances and use problem solving activities as a way to explore and develop their understanding. These younger students leave university and go into the world of work armed with theoretical knowledge of ITSM and with an enthusiastic and creative view of how they can use this knowledge in their new employment. Indeed, students can often get interviews and sometimes a job offer directly on the strength of studying ITSM on their degree course.

 

Mature students (better described as those with working experience and/or who already have jobs in ITSM) relate stories about how they have become more confident in using the material; often pushing back pre-conceived ideas held by them or their colleagues.

 

Whether they are young undergraduates or part of the more mature group, ITSM lecturers often find students enjoy the ‘journey’ rather than concentrating too much on the destination.
Longitudinal study of ITSM (observation over a period of time) has some benefits here; teaching staff witness the growth of the individual over the timeframe that they study.

 

The diversity in the student demographic is both constructive and challenging. It is often found that mature students engage more proactively with the material from the initial weeks of study as they are keen to apply additional concepts not normally included within the ITSM material; for example organisational change. However, this is not always the case as prior knowledge of ITSM is not always a prime motivator, nor is lack of prior knowledge a de-motivator; much depends on the individual.

 

The prime focus of many business and management events these days is about the value of good service and how businesses can use technology more efficiently with good outcomes for the customer. Aimed at business and IT professionals, these events prove beneficial as talking shops where the old chestnuts of organisational change, effective project planning and understanding stakeholder needs can dominate conversations. The ideology of a ‘service culture’ is easy to understand, but creating it is can be another matter. It seems that whether a person is a young undergraduate or a mature business or IT professional, the issues around creating good service are well understood.

 

It is easy to see why, in today’s service-orientated world, the progression to advanced thinking and understanding is important. This is confirmed by listening to conversations at ITSMF UK conference and events, where there are often enquiries from those working in ITSM about what further opportunities are open to them. For example, some people wonder what they can do after they have achieved ITIL Expert, when they may also have a range of other business or IT standards qualifications under their belt. Some have achieved a Master of Business Administration (MBA) from a university. Still questions remain about further ‘inquiry’ and/or personal or work-based research on service issues.

 

These are pertinent questions. After all ITSM is a practically based discipline and lends itself to further personal or organisational research beyond training or undergraduate education. One route for working students with a quality undergraduate degree, underpinned by other professional qualifications or industry experience, is that they may be eligible for direct enrolment onto a PhD. The challenge for universities is to understand the market need, to develop academic programmes which will be conducive to this, and to have specialist academics or professionals who are equipped to supervise students whilst they research. It could be argued that the ITSM industry needs its own journal where quality papers including sponsored and unsponsored research are peer reviewed and published.

 

Generational Differences

Going back to the question of trying to get to grips with where the next generation of ITSM professionals are likely to come from, it is important to understand how young undergraduates perceive service. As already noted, the concept is not alien to them. It is also important for the ITSM industry to understand the demographic of those already working in the industry, their motivations for further inquiry, and how they currently embrace the service culture.

 

Human resource research identifies the challenges to handling a multi-generational workforce by understanding the preferences, expectations, beliefs and behaviours of each generation*. So how can this apply to ITSM? It could be argued that those with work experience and/or qualifications in ITSM are more than likely to be aged from 34 to 45, a group which has distinctive attitudes to life, work and learning - tending to be salary driven and to see work as an anchor. Research shows that people in their mid to late thirties also place great value on work-life balance, and are less likely to succumb to work pressures than those over 45.

 

Conversely those in their late teens up to early thirties are the techno-savvy, confident and tenacious generation who rely heavily on technology for both work and pleasure and as such have different perspectives on jobs and lifestyle from their older counterparts. Having easily embraced technical inter-connectivity through social media, they are known for their collective action, flexibility and (generally) being street-wise. They naturally challenge long-held views and methods and are not afraid to say so. As such they expect old ways of thinking to be re-evaluated and for others to see that it is the end result that counts, not the perception of when, where or how things are done. In the university environment, they expect their lecturers to not only be cognisant of their view of the world but also to embrace differing views themselves.

 

Whilst these are generalisations, they are borne out by the author’s teaching experience. The prevalent attitudes of these two demographic groups can meld together quite happily, though, not only in the work place but in the way that they are trained or educated.

 

Embracing the Millennials

Understanding the mind-set of the newer generation (often referred to as Generation Y or Millennials) is a challenge for those teaching in universities. It is important for the service management industry to understand it too. Collectively, university staff and ITSM professionals may require a shift in thinking about how to encourage Millennials while holding onto existing values too. The shift must develop naturally from a blend of teaching and learning built on solid educational foundations. Importantly, it must come from positive knowledge sharing across generations, as noted by those developing multi-generational concepts in their workforce.

 

Enlightened ITSM departments will set up mentoring and coaching for these newcomers, passing on war stories and the benefits of practical experience. However, the shift should not just be one way. We should encourage the latest generation to influence and challenge old ways of thinking, readjusting long held perspectives and creating a new thrust in the development of the core material which reflects a ubiquitous service culture. As Gilbert K Chesterton stated, “Education is simply the soul of a society as it passes from one generation to another”. Therefore the soul of ITSM must persist and be passed onto the next generation.

 

Attitudes and values go beyond the generations. They are also affected by social, cultural and behavioural influences, so things are not always clear cut. The new generation, however, will not wait for changes to be introduced by their older counterparts; they will find their own way and they are here amongst us today!

 

We should value the mind-set of the newcomers for what they will bring to ITSM, giving them a status they can relate to: say, Young ITSM Professional. We should create the conditions where an inter-generational community of inquiry exists which is built on new ideas, is readily shared across social platforms, and fosters further debate.

 

Above all we should not be afraid to encourage profound feedback and comment from them as they challenge long-standing views and beliefs.

 

Quite rightly educational institutions should create mechanisms for all of this. Importantly, there has to be an endemic understanding of the challenges that these institutions face as they include ITSM in their academic portfolios. The ITSM community must also reflect and respond accordingly. Collectively education and training providers must work together to create mechanisms for lifelong learning and development in ITSM so that newcomers and those developing their existing careers are exposed to a blend of education, training and experiential learning via dedicated but flexible routes. The term ‘education’ in ITSM must be seen as a generic concept, not purely academic learning.

 


This article first appeared in the Autumn 2014 issue of Service Talk. 

Tags:  Career  ITSM 

Share |
PermalinkComments (0)
 

Release Management - Delivering More and Breaking Less

Posted By Richard Horton and The Transition SIG, 30 June 2016
Updated: 30 June 2016

 

If you want a one-line summary of the challenge faced by people delivering IT services, you could do worse than “How to deliver more and break less”.

 

Given that there isn't a limitless pile of money available to throw at this problem, and that there are constant pressures to reduce costs, clearly we need to improve our practice if we are going to reduce the breakages.

 

The good news is that there is room for improvement. Despite years when change and release management have been viewed as core ITIL processes, likely to get an organisation’s attention before many others, we still haven’t got these essential elements cracked. Much is spoken about agile and DevOps, but when push comes to shove, many people are still taking a more ‘traditional’ approach to release management, if they have got that far.

 

At a recent Service Transition SIG meeting, we took a look at the sort of challenges that face us in deciding how to do release management, and a range of approaches we can use in addressing them. 

 

We started with our hosts Arqiva, who outlined to us the complexities that they face as they serve customers with competing demands. They have to balance their requirements on a shared infrastructure. And if they mess up, they are acutely aware that the nation will know, as their mistakes have the power to bring down television or radio transmission. Arqiva explained how they have delivered impressive increases in the reliability of change implementation, but still face some challenges in release management.

 

So what sort of models could be applied? There isn't a ‘one size fits all’ here. Some organisations, we discovered at the meeting, focus their release management more at the technical level, while others opt for an implementation scheduling approach. Others might want more of an enterprise overview, coordinating the dependencies which projects look after. We looked at the challenges faced in each case and the potential role conflicts inherent to each approach.

 

We then considered how to bundle releases, whether going for the ‘small and often’ or the ‘big and occasional’ approach (or a mixture). We considered the possible constraints in both cases and what kind of a release plan you might put in place to help alleviate these limitations.

 

Smaller and faster projects tend to be linked with agile, but this isn't necessarily the case. Those using the traditional ‘waterfall’ approach can learn from agile here. On the other hand, if attempts to be more agile are too eager, there is a danger of relaxing the waterfall controls without recognising that agile has controls too. Basically there isn't a shortcut. If you want to improve you have to work at it.

 

Planning is an important area. We considered the factors that can torpedo what might look like a good plan, complete with plenty of contingency, as projects still end up getting put back and put back, with huge overruns resulting.

 

So, now we have set ourselves up to deliver more. Great... but only if it works. How do we reduce the fallout? Approaches to testing are key. A measured approach comes in handy here. Things don't always work first time so why do we assume they will? We want a well thought through approach to testing, including awareness of the risk/opportunity equation, so that we are not just doing endless testing for the sake of being bullet proof, but delivering too late to be of any use.

 

If we understand the importance of good testing we will prepare our scenarios in advance, consider where automation can help (bearing in mind the pay-back period) and, where we are not automating, assign people to perform testing who have both the right skills and the will to do it. And it would be really helpful if we could ensure our environments match as well, so that we are testing like for like and can see the wood for the trees.

 


 


If you would like to find out more about the Service Transition SIG’s work on release management, why not attend one of their regular events which you can find on our event calendar.

 

ITSMF UK also run a series of workshops and masterclasses covering many topics including Release Management.

 


               

 

This article first appeared in the Spring 2015 issue of Service Talk

Tags:  ITSM  Release Management  Service Transition 

Share |
PermalinkComments (0)
 

5 Simple Tips for Effective Problem Management

Posted By Charles Fraser, 23 June 2016
Updated: 22 June 2016

 

Undertaking effective ITIL-based problem management is essential for any IT organisation that wants to deliver high levels of service availability and consistently high quality IT services.

It is however an unfortunate fact that the great majority of IT organisations fail to realise any noticeable benefits from the time and effort they spend undertaking problem management.

This article provides you with five simple and practical tips to help you to set up and maintain effective problem management.

 

Tip 1: Focus your problem management efforts on finding permanent solutions

Forget about using problem management to find temporary solutions.

 

If you want problem management to deliver real and tangible value then you must develop a problem management process that focuses on finding permanent solutions.

 

Only by focusing your problem management activities on permanent solutions will you be able to substantially reduce your volume of incidents. And it is in the reduction in the volume of incidents that the real value of problem management is to be found.

 

It is important to be clear about the distinction I am making between permanent and temporary solutions:

 

  • A permanent solution is where the underlying cause of the incident(s) has been addressed in such a way as to prevent the incident from occurring again

 

  • A temporary solution is one which is employed to get the user up and running again ('as quickly as possible') but which will not necessarily prevent the incident from re-occurring in the future – e.g. temporarily re-routing a user to a different print queue

 

Please note I try to avoid using the term 'workaround'. This is because it confuses everybody. It is confusing because it can be applied to both permanent and temporary solutions. Because of this it is best to avoid this term (stick with permanent or temporary solutions – these are terms that everybody can understand).

 

So, the key to getting real value from problem management is to build a process that concentrates on finding permanent solutions. Only by doing this will you be able to deliver the value (reduced volume of incidents) that justifies the time, effort and resources involved in the investigation of problems and the subsequent deployment of permanent solutions.

 

 

Tip 2: Make sure your problem management process delivers real value

Most organisations that are familiar with ITIL undertake some form of problem management. And with very few exceptions they are wasting their time. This is because they have put in place a problem management process that delivers no real (tangible, meaningful and measurable) value.

 

How do you know if your problem management process is actually delivering value? Well, first of all you need to forget all about the various (irrelevant) metrics that are often mentioned. For example, the time taken to complete a root cause analysis, the number of problems in the backlog, etc. None of these actually indicate, reflect or measure the value of undertaking problem management.

 

There is in fact only one truly tangible and meaningful measure that your problem management process is delivering value – and this a reduction in the volume of incidents. If this is happening you have a worthwhile problem management process. If this is not the case… well, sorry to be blunt but you are just wasting your time. It is that simple.

 

You must regularly (every three months?) review your problem management process to check that it is delivering value and that the volume of incidents is falling. If it is not then you need to stop what you are doing and change. Change your process. Make it better – make it effective.

 

If you want, you can go a stage further and set some specific targets. For example, reduce Priority 1 incidents by 40% within three months (this is a very valid target because it ensures that you are addressing the incidents with the greatest adverse impact), reduce network printing incidents by 60% over six months, etc.

 

Now I am fully aware that other factors can impact the volume of incidents, and a lot of organisations use this as an excuse for not using incident volumes as a measure of problem management effectiveness. I do accept that many factors can impact the volume of incidents, and in some circumstances even with good problem management in place you might see incident volumes (temporarily) increasing.

 

But even with all these potential issues the volume of incidents still remains the single most important indication of the effectiveness of your problem management process. Forget everything else: just make sure you are achieving this and, if not, then do something about it!

 

Tip 3: Make your service desk/incident manager your problem manager

Yes – I know. This is something that ITIL advises against. And I know and understand why ITIL advises against this. But I believe that in this case ITIL has got it wrong.

 

There is in fact a very good reason why your service desk/incident manager should also be your problem manager. But before I go into that I want to be very clear on what the role of problem manager actually involves.

 

Problem manager is not a technical role, and the problem manager does not undertake problem investigations. Problem investigations (both the root cause analysis and the solution identification) are undertaken by an appropriate subject matter expert (SME).

 

The primary responsibilities of the problem manager are in fact administration, co-ordination and facilitation. The specific activities, among other things, include:

  • Reviewing requests for problem investigations to see which are justified
  • Developing the business case for each problem investigation in order to justify the resources required for that investigation
  • Arranging for the appropriate SME resources to be made available and assigned to a relevant problem investigation
  • Producing the terms of reference to be followed by each SME undertaking a problem investigation
  • Overseeing the investigations undertaken by the SME
  • Validating the root cause analysis and the proposed permanent solution
  • Reviewing the effectiveness of the deployed permanent solutions.

 

In the majority of organisations there is rarely the justification for a full-time resource to act as problem manager. Therefore it is often combined with another role. The first, and very important point, is that you must appoint somebody to this role. You will not be able to undertake effective problem management without somebody acting as (an effective!) problem manager.

 

Now back to the original point. Why do I disagree with ITIL and recommended that you combine the roles of service desk/incident manager and problem manager?

 

Well the reason is simple. The primary goal of the problem management process is to reduce the volume of incidents (see Tip 2). So you want to ensure that the problems prioritised for investigation are those that will deliver the greatest benefit – i.e. will lead to the biggest reduction in re-occurring incidents (or will eliminate the most 'damaging' incidents). Makes sense so far?

 

So - who is best placed to decide which problem investigations will deliver the greatest benefit? Who is best placed to decide which problems will justify the resources required for investigation?

 

It is clear this has to be the person who stands to benefit the most (in the IT organisation) from the reduction in incident volumes, and the person who has the greatest visibility and understanding of current incident trends and volumes.

 

This is clearly the service desk/incident manager. This is in fact the IT role that has the greatest vested interest in ensuring that you are undertaking effective problem management. And this is why the roles should be undertaken by the same person.

 

There is no 'conflict' between these roles; there are only shared goals and benefits. So combine the roles - it is the only sensible option.

 

 

Tip 4: Get on with it – you do not need specialist resources or tools 

Some organisations hesitate to put problem management in place because they believe they lack the 'resources' to undertake problem management – i.e. the required people and an integrated incident/problem management system.

 

This is nonsense. You do not need any special resources in order to undertake effective problem management. You can do it perfectly well with the resources you already have.

 

People

 

Unless you are a large third-party IT service provider you do NOT need to set up a dedicated problem management team, full of technical experts to undertake problem investigations. This is in fact completely the wrong thing to do.

 

The SMEs you allocate to undertake the problem investigations will in fact come from your existing IT departments and teams. The key is to make sure that the time and effort they spend on problem investigations is fully justified. This is a responsibility of the problem manager (see Tip 3). How much time will the SMEs need to allocate to problem investigations? Well, this depends on the nature of and the number of the problems you decide to investigate.

 

The bottom line is that you can start problem management with the staff you currently have.

 

One important point to note: please be aware that a significant proportion (the majority?) of problem investigations will be non-technical in nature. The great majority of incidents are caused by failures in process, procedure, human error, etc. Problem investigations are often more about finding out why a procedure failed than why technology failed. So an SME is not necessarily a technical resource.

 

Toolset

 

You do not need to spend money on specialist tools/systems for problem management. There is absolutely no need to dynamically link incident records to problem records, and problem management is not dependent on an integrated incident/problem toolset.

 

And contrary to what is commonly believed, there isn’t any real benefit in the service desk being able to access the problem records. 

 

So, to be clear - you do not need any special resources to start undertaking effective problem management. Just get on with it.

 

Tip 5: Don’t worry about distinguishing between pro-active and reactive problem management

Who cares where problem requests come from?

Does it really matter if they come from undertaking regular trend analysis of incidents, or if they are generated automatically as a result of a Priority 1 incident being logged? No - from the perspective of developing an effective process for the investigation of problems the source of those problems is largely irrelevant.

Many organisations set up overly complicated problem management processes because of the perceived need to have separate procedures for proactive and reactive problem management. But the distinction between proactive and reactive problem management is an unnecessary complication. You do not need two separate set of problem management procedures.

Now it is undeniably important to carefully identify how, when and from where potential problem requests originate, and how they are to be submitted to the problem manager for consideration. For example, who has responsibility for analysing the incident trends, how often should they be analysed, how are they to be analysed, etc.? If a problem request is to be raised after a specific event (e.g. a high-priority network failure), then how is this to happen. All of this should be defined and clearly documented within your problem management process documentation.

But from the point where the problem request is submitted to the problem manager the process for considering the justification for that request, accepting and prioritising the investigation, assigning the resources to the investigation, validating the results of the investigation etc., is the same irrespective of the source of that request.

So avoid the unnecessary complication and ignore the irrelevant distinction between pro-active and reactive problem management. Develop a single end-to-end problem management process.


 


If you'd like more help with Problem Management then why not attend one of our workshops? For more information visit our events page 

 

Tags:  problem management  Tips 

Share |
PermalinkComments (0)
 

Is it Time for ITSM to be Counted as a Professional Discipline? Part 2

Posted By Barclay Rae, 16 June 2016
Updated: 15 June 2016

 

In Is it Time for ITSM to be Counted as a Professional Discipline - Part 1 I discussed how ITSM is still seen by many as purely ITIL-focused or relevant only to internal IT operations. In Part 2 I continue to explain why ITSM needs to grow up.

 

What Needs to Happen? - Continued

Here are some key areas for development:

The ITSM industry needs a broader definition of itself and the roles within – this needs to be supported with a wider range of education and training, plus ongoing professional development. The definition can also extend beyond IT – to include other ‘service’ areas, back office functions and departments such as HR, Finance, Marketing, Estates etc.

The industry must have a single, consistent approach that recognises people and organisations in competence and excellence. This should include organisational accreditation, career development in a number of areas and recognition of real experience as well as qualifications.

The ITSM world should work together to unify its various groups and organisations - otherwise it looks like an amateur ‘cottage industry’. There should ideally be a singular body who see themselves as a common community which spans technical, functional and process areas and also levels of management (including executives).

 ITSM needs to promote, explain and market itself as a distinct discipline much better and bring the different parts of the sector more together, with success stories amongst target markets with the active support of senior people.

The business case for delivering value from ITSM must also be clear to other parts of IT organisations, not just the ‘Service Management guys’. This is essential in order to achieve the value from collaboration and to really deliver ‘end-to-end’ service delivery.

The value of Service Management should be clearly articulated as (1) to manage delivery expectations for customers and (2) minimise risk for the service provider. It’s a win-win – or should be – for customer and provider.

 

What Skills are Needed Beyond ITIL? 

There are 2 main areas of expertise and knowledge required – these are some examples:

Market and industry-wide knowledge – awareness and skills in a variety of other frameworks, e.g

COBIT – this is a model for governance based around a wider set of processes than those in ITIL, although these are defined in a more systemised and integrated taxonomy. ITIL has more ‘stories and anecdotes for reference, whereas COBIT can be better measured and tracked.

DevOps/Agile – ITIL is often criticised as being too inflexible and slow. It is still couched in the 80s/90s IT world and agile methodologies speak to a younger audience, many of whom would not recognise a mainframe. DevOps is a fusion of Agile and a collaborative controlled approach and is gaining significant traction as a useful set of values rather than a rigid framework.

Lean/Kanban – these are additional alternative approaches to how to make change work – using principles for reducing waste and also for work management and prioritisation. These have been used for some time in ITSM projects and add significant value to the practical side of implementations. 

Prince2/PMP – ITSM requires change and this needs to be managed – there has always been a need for synergy with Prince2 and other Project Management models, although this has not been delivered with any formal structured integration. It’s essential however that anyone taking on an ITSM initiative must be able to manage a project and - ideally more than that – deliver organisational change.

IT4IT – this is a new initiative developed by strategic thought leaders in ITSM and service architecture, as well as being sponsored by some major blue chip organisations.  Like DevOps it recognises the need for an integrated and collaborative approach and sets out to look at transformation from a holistic perspective, based around business collaboration.

SDI/HDI – The Service Desk and Helpdesk Institutes in the UK and US provide a number of services and vocational standards for those involved in these teams. These organisations and their standards (individual and site based certification based on EFQM) have a defined audience (the wider ITSM world is more dispersed) and provide useful practical input to the industry – this could be further integrated.

SIAM – Service Integration and Management - this is a new concept, based on an old one – i.e. the need to co-ordinate and manage a number of IT suppliers in a single ‘supply chain’. The ‘new’ element is the idea that multiple outsourced suppliers need to be managed by one (SIAM) management layer, so that a single service view is managed and delivered across the supply chain. This uses ITSM concepts in a more commercially focussed way and is gaining credence and adoption.

ISO 20000 / 9000 / 38500 – these are various certification standards for organisations, with ISO/IEC 20000 being based on ITIL, plus some areas of management and control. ITIL is often confused as a standard which can be ‘implemented’ and ‘certified’, although this is not the case. ISO2000 has not achieved the levels of adoption that were expected although it remains the nearest any organisation can come to being ITIL ‘certified. The ISO 9000 series is centred on customer service and as such a useful starting point. ISO38500 is a governance model for organisation around IT and is a useful model for the integration and fusion of business and technology goals, as well as being an executive blueprint for the management of an IT function.

 

Personal and Management

Overall ITSM requires strong people skills in order to drive through change and make it sustainable – management, organisational skills, influencing skills, communications, project management, business understanding and focus.

ITIL has tended to define roles in operational terms rather than those required for the transformation, and often the change roles were given to those better suited to operational/business as usual functions – often not enough to really affect change.

Other key skills needed

Presentation and promotion – Organisational ITSM change requires a number of people to make e.g. small changes in the way they fill out forms, or communicate with customers. The best way to make this work is by presenting and motivating them to do it and not by bombarding them with directives, processes and documentation. ITSM projects also need to be well communicated across organisations with a good focus on message and target audience, not technical detail.

Sales and marketing – these key skills are needed to define benefits and ‘sell’ these to business leaders and users across organisations. Normally this is not a natural skill for IT people and many ITSM initiatives fail due to lack of clear focus on message and communication of expectations and results.

Business and Financial Management – there is a need to define business gaols and build these into business plans and budgets.  This can also be an area where projects fail, not because of lack of need but lack of presentation of need, risk, value etc. Good commercial skills are also needed for developing, negotiating and managing external suppliers and contracts to deliver a successful ‘joined up’ service, rather than a sum of parts.

Management, Relationship & Interpersonal skills – Influence and motivation are essential elements in successful ITSM – this can’t simply be based on autocratic management. Managing and developing people to want to deliver better service is the goal and this needs keen skills in team building, personal motivation, influencing and collaborative working 

Project Management – budgeting, planning & personal effectiveness skills are needed to make change happen, this also needs a strong sense of self-motivation, self-confidence, time management, leading by example, organisational skills etc.

Successful ITSM requires participants to have good understanding and knowledge of their own organisation, key contacts, stakeholders and sponsors, as well as having a good amount of ‘clout’ and respect across the organisation. They need to be experienced in perhaps more than one area to be able to really see how to deliver ITSM. 

 

Summary 

Many organisations are using ITSM for work management beyond IT. In these cases the IT organisation is becoming the department that says ‘yes’ – a solution provider not a blocker.

In this way IT can further transform itself and add value – if this is not grasped then ITSM will become another obsolete museum piece.

ITSM is actually a potential game changer for IT, not an albatross around its neck…!

The challenge for individuals working in ITSM is to step up – develop their skills beyond ITIL and the ‘silo’-based department, stop seeing other teams, departments and industry areas as ‘them’ and start to engage and work together in positive collaboration as ‘us’.

The challenge for the industry is to unite and see the real potential for ITSM as a business enabler, not a best practice.

We need more practical and enlightened collaboration across frameworks, training organisations and established communities to support this move.

We need as an industry to move away from ‘them and us’ – IT and ‘the Business’, Operations and Development, Service Desk and other support teams.

If we must have ‘them and us’ – then let that involve natural selection. Let ‘them’ (competitors) have best practice, whilst ’we’ (our whole organisation) deliver business value.

 

Click here to find out more about our plans to develop and advance ITSM as a professional discipline.

 

 

 

 

Tags:  PSMF 

Share |
PermalinkComments (0)
 

SIAM and How to Deal with the People Side of Organisational Change

Posted By Administrator, 08 June 2016
Updated: 07 June 2016

 

Posted on behalf of the SIAM SIG – People and Change Working Group

Here in the SIAM SIG we've been working on a new project. We wanted to know what the key issues are that SIAM practitioners face today. 

We canvassed our members and had fantastic feedback. Overwhelmingly the response was that the big three issues for ITSM organsiations are: 

·      business change

·      managing the people side of change impact

·      achieving culture shift 

To research how much impact these issues have and how organisations can deal with them, we created the People and Change SIAM SIG working group.  

The group consists of SIAM practitioners, SIAM vendors, consultants and clients from across the ITSM sector.

In February this year, after pulling together their own experiences and knowledge of managing change and the resulting impacts, the group presented back to the SIAM SIG. 

Below is a write up of that presentation.

 

Managing Organisational Change

ITIL suggests that we put our people first. And rightly so.  All SIAM implementations involve a level of transformational change. Without the support of its people, a SIAM programme may not achieve its goals. 

There are many methods to deal with the impact on people as a whole. But these methods can lack understanding of the impact on individuals, and of the organisation’s underlying corporate culture.

A key message in managing organisational change involves understanding the individual impact of transformation change such as that required in SIAM.

The message is well presented in Spencer Johnsons book “Who moved my Cheese”. There is also a video on YouTube you can watch which sums up the message from the book 

 If you're short on time then start from about the 7 minute point.

After understanding this key impact upon individuals, implementing Organisation Change Management by adopting methods such as Kotter’s 8 steps can be more effectively undertaken. 

Once we have established a team for change or a team to be part of a new SIAM model, we should concentrate on building a new effective team. As part of this process we can leverage techniques such as “service animals” or “what Colour am I”. In essence it’s about understanding. Know your people, know your goals and be successful.  More details of these techniques are available for those who attended the SIAM SIG event on 29th Feb on the DropBox link which was distributed after the event.

 

ITSM People and Change

In the afternoon of the SIAM seminar, the working group facilitated a Work Café session on people and change. It was a great afternoon, and everyone was willing to get involved and add their own experiences and suggestions. The aim of the session was to look at the impact on people across the 4 understood operating models of SIAM:

·      retained SIAM

·      outsourced to Independent provider SIAM

·      hybrid SIAM (retained + independent)

·      tower led SIAM

For each model we looked at the biggest challenges, but also potential solutions and ideas to mitigate against these challenges. We also looked at other considerations that didn’t fall in to any of the 4 models. Moving from one model to the next, everyone had the opportunity to contribute to the observations and ideas. At the end of the session, we all had 3 votes to nominate what we felt were the greatest challenges, and a vote to nominate the best idea.

Of all the issues discussed the top 3 were:

  • Lack of understanding of roles and responsibilities. (Particularly highlighted for Hybrid and Independent models but noted as an issue affecting all SIAM implementations)
  • Retention of staff during times of uncertainty
  • Inappropriate contract negotiation and exit criteria

 There were some great ideas & suggestions, but unsurprisingly, the idea with the most votes was:

  • Clarify roles against industry standard definitions and develop a RASCI matrix. (Responsible, Accountable, Supporting, Consulted, Informed)

After a great event, the People and Change working group are looking to develop guidance around the issues and ideas identified on the day including how to achieve culture shift.

 

Stay tuned for more from the working party and the SIAM SIG soon.

Attending the SIAM SIG and benefiting from the great work they do is a member benefit. Click here to find out what other benefits you could receive as an ITSMF UK member. Alternatively, if you'd like to give membership a try contact the office on 0118 918 6509 and talk to us about our free six week trial.  

 

Tags:  business change  Organisational change  SIAM 

Share |
PermalinkComments (0)
 
Page 6 of 12
1  |  2  |  3  |  4  |  5  |  6  |  7  |  8  |  9  |  10  |  11  |  12

Premier Gate
21 Easthampstead Road
Bracknell
Berks RG12 1JS

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us