Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
· Home
· Content
· Feedback
· News
· Search
· Statistics
· Surveys
· Top
· Topics
· Web Links
· Your_Account


The five ITIL books can be obtained directly from the publisher's website:

Or as downloadable PDFs: HERE

Current Membership

Latest: FelicaBo
New Today: 37
New Yesterday: 27
Overall: 231749

People Online:
Visitors: 134
Members: 0
Total: 134



Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Related Resources

Service related resources
Service Level Agreement

How to set up
IT Change Management
Process Info-Graphic

NOTE: ITIL is a registered trademark of OGC. This portal is totally independent and is in no way related to them. See our Feedback Page for more information.


Select Interface Language:

Please contact us via the feedback page to discuss advertising rates.

The Itil Community Forum: Forums

ITIL :: View topic - Desktop Slowdowns - What approach to take?
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Desktop Slowdowns - What approach to take?

Post new topic   Reply to topic    ITIL Forum Index -> Problem Management
View previous topic :: View next topic  
Author Message

Joined: Sep 29, 2008
Posts: 2

PostPosted: Mon Sep 29, 2008 11:17 pm    Post subject: Desktop Slowdowns - What approach to take? Reply with quote


Again I am a newbie to this forum. I have been a Problem manager now for 3 yrs.

I have a very specific query re on-going series of problems I have encountered, the subject being desktop slowdowns. I work in a medium size org with around 7,000 desktops delivering multiple apps to distinct business units. This is a recurring issue with users located centrally in a head office environment.

I find it very hard with the distinct support teams all too happy to say their piece of the puzzle is clean. These teams include Network, Client, Windows Infrrastructure and In house application support teams.

Has any one had a similar issues and how did they progress?
Back to top
View user's profile
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Tue Sep 30, 2008 12:40 am    Post subject: Reply with quote

I dont know what has been done

What do you mean desktop slowdown ?

This can mean a lot of things

My first thought is to get all of the team lead running with this and get them to PROVE the root cause is not their area.

Instead of them saying - not me ... some else.. You say.. to each one of them.. The root cause is .... , prove it is not.

DO it in a room with all of them or separately

alternately, with out involving them, put down possible causes.... in a ishikawa diagram ... cause/ effect diagram
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile
Senior Itiler

Joined: Oct 13, 2006
Posts: 116
Location: South Africa

PostPosted: Tue Sep 30, 2008 8:03 pm    Post subject: Reply with quote

Tough one. You're working against the motivation of each team to make their area look good ... and perhaps to avoid difficult work.

I see what John says, and that's important, but that approach can still quickly run into denial: "we have proved that that stated root cause does not apply to our area" or experts say that is normal operation of a network, the desktops should cope with it, or any number of other excuses.

You need to appoint a problem coordinator (could be yourself) and register this as a cross-functional problem that requires end-to-end resolution. What I'm saying here is your process, and your policy and your top management commitment, need to be behind this so everyone feels responsible.

Then, ideally your problem coordinator would be cross-functionally skilled ... but those people are hard to find! At least, you need
  • A very precise description of the problem - not the root cause, because you don't know it yet, but the symptoms. So that you have a definite goal: "if this goes away, we have finished". You must define when the incidents or events occur, who is affected, what diagnostics can be used, etc.

    Otherwise you have a general description that each team can interpret differently, or only address a small part of.

  • Appointed contacts in each affected team, with regular minuted meetings. All functional areas need to allocate time to this outside of routine work - that's one of the classic definitions of "problem" - management deciding that focused effort is required.

  • The team has to understand the end-to-end working and interdependencies. If you don't have a cross-functionally skilled expert, you'll have to create this understanding during the problem determination work.

  • A list of possible causes - brainstormed, evolving - use your favourite problem determination methodology - but involve everyone.

  • Avoid a culture of apportioning blame. The root cause may not be due to someone's error or some badly functioning component - it's more likely to be due to some setting or configuration that would be fine in other circumstances but not yours. Everyone has to work together and contribute.

If you can't get commitment to the above, then you have to be hardnosed and say there is no commitment to fixing this "problem" and it should be taken off the list.
Back to top
View user's profile Visit poster's website
Senior Itiler

Joined: Mar 04, 2008
Posts: 1894
Location: Helensburgh

PostPosted: Tue Sep 30, 2008 8:28 pm    Post subject: Reply with quote

This is really a performance management issue and should come under the remit and skill set of Capacity Management.

I have experienced such issues go on for two or three years until people stopped testing their best guess and started analysing the system end to end, relying on data to point to the underlying problem.

It is quite common for there to be more than one cause or for the slow periods to be caused a combination of factors. The best (but possibly expensive, nevertheless an investment that can pay for itself) way to get to the root is by modelling the system. There are at least two companies in the UK that can provide software for this (and consultancy).

The underlying problem with the speculative (brainstorming) approach is that you are no further forward when you next get poor performance and you have no way of knowing whether it is for the same reasons or not.

Once you have done measurement you have a baseline for the future and if you have a model you can test where future bottlenecks might occur.

The various groups will find it harder to argue with data and the cause(s0 often turn out to be factors that no single group could have reasonably anticipated. Getting all the data together can therefore help to get the teams to work together.
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718
Back to top
View user's profile Send e-mail
Senior Itiler

Joined: Sep 16, 2006
Posts: 3597
Location: London, UK

PostPosted: Tue Sep 30, 2008 8:53 pm    Post subject: Reply with quote

Diarmid is correct. This is Perf Mgmt part of capacity

As the problem mgr, what you should query // etc as part of developing the strategy for finding the solution to this issue

You should break it down like the below point

Each one will spawn a sub question

1 - What services (foreground/background) are being run on the desktops in question.
- which ones are memory hogs
= how much memory / swap space on each machine
<= is there a std for mem or swap space
2 - what admin level of services are running and when....
3 -
1 - what is the network architecture for these affected machines
2 - what is the b/w and capacity of VLANS, LAN and equipment (switches, routers, bridges)


Doing this can help figure out what's what

The usual suspects in this - from my experience is

1 - AV software and updates done on desktop as well as the network / mail gateway. (design issue)
2 = age of kit involved / capabilities of kit
3 - network satuarted / over worked (Capacity mgmt)
John Hardesty
ITSM Manager's Certificate (Red Badge)

Change Management is POWER & CONTROL. /....evil laughter
Back to top
View user's profile

Joined: Aug 12, 2008
Posts: 33

PostPosted: Tue Sep 30, 2008 10:43 pm    Post subject: Oh Capacity is it! Reply with quote

Hi guys,

As a capacity manager, I too have experienced this typical scenario many times and to be honest, I've sometimes seen a problem accepted rather than solved.

Granted, this is a performance / capacity issue and the threads so far have advised some good avenues and tips both from a business and more technical perspective...

However, upon reading the vikings comment on AntiVirus for example being a typical culprit it just sprung one thought not yet mentioned...

How effective is your change log? If it's effective and accurate, maybe get a rep of each area on a conference call and discuss the possiblilty of any recent changes that may have triggered this service issue. OK, maybe the deskstops have slowly deteriorated but it's still worth a try.

Alongside this, you need to follow the vikings diagnostics approach, i.e. who, what, when, how, and hopefully the why will follow, but remember you're the problem manager and not a desktop engineer! You need technical support guys pushing with you and not against you...

What do you reckon guys...
Back to top
View user's profile
Display posts from previous:   
Post new topic   Reply to topic    ITIL Forum Index -> Problem Management All times are GMT + 10 Hours
Page 1 of 1

Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB 2.0.8 © 2001 phpBB Group
phpBB port v2.1 based on Tom Nitzschner's phpbb2.0.6 upgraded to phpBB 2.0.4 standalone was developed and tested by:
ArtificialIntel, ChatServ, mikem,
sixonetonoffun and Paul Laudanski (aka Zhen-Xjell).

Version 2.1 by Nuke Cops 2003

Forums ©


Logos/trademarks property of respective owner. Comments property of poster. Rest 2004 Itil Community for Service Management & Foundation Certification. SV
Site source copyright (c)2003, and is Free Software under the GNU / GPL licence. All Rights Are Reserved.