New-Build Support Profile

[SteveTetch]

I'm not really sure where to post this, so I'll add it here in Scuttlebutt.

I work for a large financial organisation, with a large and geographically disparate IT department. After several years with our old desktop build, (Windows XP, Office 2003, IE6, SafeBoot for laptops etc.) the powers-that-be have launched an updated desktop - still Windows XP based, but with Office 2007, IE8, PointSec for laptops and a myriad of other tweaks and changes. Unfortunately, this build has been put together in a degree of isolation by contracted build architects, with little or no input from, or evaluation by the DeskTop Support engineers who are meant to support it and keeping it running smoothly and efficiently for the Users.

We've asked for some explanatory information and documentation regarding how it's meant to hang together, but we're told that this is of low priority as we'll get to know everything about it by assessing and (hopefully) fixing problems as they arise. I'm a support engineer attempting to work under this restriction and I think it's wrong. On the one hand, it takes time for all of the problems to develop and our service standards and response times understandably suffer as we're faced with a series of issues for the first time. Secondly, it's my contention that learning about something by only fixing it's errors and mistakes is the worst form of discovery, leading to a piecemeal understanding of things, demarcation among the support staff as they get familiar with only particular aspects of functionality and inconsistency in the way any problem that does occur is fixed.

To be sure, the emergence and evolution of a knowledge base does occur, but it's slow and, with the pressure on the engineers to rack up call resolutions and make their time-sheets look efficient, there’s rarely the time (or, it has to be said, the inclination), to document everything that's needed, or to collaborate in sub-editing the documentation of others such that a uniform house-style can be applied.

This is the same way the knowledge base for the build being phased out was developed. I wasn't here during the initial roll-out but can attest to the range of standards and abilities of my fellow engineers who don't have a central data repository to consult. Also, anyone starting new with the Company has a potentially lengthy period of shadowing an existing engineer before they become self-sufficient and this, in turn, leads to the perpetuation of bad habits.

What I'm looking for, then, is whether there exists some kind of industry-standard template for describing how an standard PC system - be it desktop or laptop - should work in an integrated corporate environment. I'm not thinking of a list of known errors and problems and the best fix for them. Rather, what I have in mind is a systematic description of how the various components, configurations and settings hang together to produce a stable working corporate PC.

Our IT department nominally follows the ITIL discipline, but this appears to affect processes and procedures, and not, it would appear system documentation like this. I'm aware that the requirement is somewhat vague, and the relevant content will be different from Company to Company and from build to build, but I'm hoping that a standard template of documentary components exists, from which one can cherry-pick that which is relevant to you and end up with a comprehensively descriptive illustration – a kind of Haynes manual, if you like - of how the system works.

Am I asking too much? Do other large organisations document their systems in this way? Any comments and suggestions would be welcome. Thank you, in advance.

[viking33]

Steve,
I may be way "off base" and completely out dated on this but in my opinion, something as you describe probably does not exist. ( not saying that it shouldn't exist ) The variations and complexity of every Corporation's particular system would make a so called standard "pick list" a complete nightmare, I think. What applies to one would not directly apply to another and there would have to be sub chapters and sub paragraphs to edit and change, etc., etc, etc.
In my other life, I was responsible for and managed what was at the time, the largest Corporate Telecommunications switching computer in the US. Located on the east coast of the US, there was a smaller satellite system on the west coast.
The documentation and information available varied from small\minuscule to large\immense. This was just comparing our two supposedly similar installations!
So, if there IS something out there ( or if you could develop one ) I think it would be a lot more well known to all of you who have to make do with what you are given.
Good Luck. I would be most interested and happy in hearing that I that I am as described in my first sentence. Off base and out dated.

[StuartR]

...
Our IT department nominally follows the ITIL discipline, but this appears to affect processes and procedures, and not, it would appear system documentation like this
...

ITIL includes a book called Service Transition which discusses the importance of configuration documentation and knowledge management.

Here are some quotes from the ITIL books that you could try using to persuade your department that they are doing the wrong thing.

...
Improve the quality of documentation to reduce the number of incidents and problems caused by poor quality user documentation, release, deployment, support or operational documentation
...

...
Provide knowledge, information and data for deployment, service desk, operations and support teams to resolve incidents and errors
...

...
Encourage cross-fertilization of knowledge between transition and operation stages to improve problem diagnoses and resolution time, e.g. workarounds and fixes.
...

That's all I can sensibly fit into this post, but it should be sufficient to give them the idea.

[ChrisGreaves]

"Other Operating Systems (OS X, Linux)" and preserve this thread for posterity?

What I'm looking for, then, is whether there exists some kind of industry-standard template

Might I suggest you contact the ISO people?
They seem to have a standard for everything.
A good start might be the ISO experts within your own company.
If you don't have any I'd be happy to make inquiries amongst my clients; I have at least two contacts engaged on ISO stuff.

[BobH]

In my experience (40+ years in IT), I never came across a standard for system overview documentation (which, I think, is what you are describing). I saw some systems that were very well documented (I even led the development of a few of them. ) but most were either not documented at all or had such poor doc as to be worthless.

The problem with a standard is the diverse nature of corporate platforms and the equally great diversity of users. I should think it nigh impossible to create a meaningful standard and completely impossible to adhere to it cost effectively. Usually there were so many time delays and cost overruns in getting the platform built that documentation was sacrificed to the bean counting gods (who were the first in line to get doc and expected it to be perfect).

Documentation and an understanding of how systems work is essential to decent user support. Perhaps you could develop a business case for justifying the expense of the documentation of - or, better yet, the intensive training of the support desk staff on - the new system. If you can gather meaningful, credible information about the real and opportunity costs of system problems and can show how problems will exist for longer periods and more will be spent by the support staff due to problems taking longer to resolve while support staff learn how the new build hangs together, I'd take a shot at it, if it were me. If you are in a very large organization with a large population of users, it should be fairly easy to build the business case. Expect it to take longer to sell the idea and get approval for better training and documentation for support staff, though.

HTH