This site is now retired. It is only a static archive. Some functions may not work any more.

Real ITSM Service Design

Greetings Real ITSM Practitioner!

Here is a little newsletter from CultITSM to let you know that membership of the Real ITSM Group on LinkedIn just passed 300! Not bad for a group that once tried to get to 100 members. Our next goal is of course to exceed the itSMF International group membership of 1369. We've already exceeded 20% of that without being pimped by major vendors or having our logo and address on every ITIL book. Not bad eh?

Here is another extract from the Introduction to Real ITSM for your enjoyment:

A Real IT department will understand that, despite our best efforts, sometimes a new service is unavoidable, usually for political reasons. In this situation, three strategies are followed (the “Three Ds”).

3.1.1 Design for failure
Where possible, design for failure to ensure the service never sees the light of day. There is a multitude of possible tactics. These are some examples:
• Confuse the users so as to develop ambiguous requirements that may be interpreted as IT sees fit (and the user ultimately blamed)
• Tempt the users with impossibly expensive options
• Lead the users into politically unacceptable options
• Ensure the users includes two strong power groups then get each to adopt mutually incompatible design decisions
• Allow users to change requirements at any stage.
• Expand the scope as much as possible so that the project either collapses under its own weight or takes so long the service is irrelevant by the time it is delivered
• Omit as many essential design decisions as possible
• Select a technical architecture incompatible with all incumbent technologies
• Select technologies that are unproven, still in development or - best of all - purely speculative. Vendors can provide these in abundance.

3.1.2 Delay
The IT industry has developed a wide variety of techniques for delaying a new service, so many that it is beyond the scope of this book to survey them all. Common examples include:
• Workshops, stakeholder consultation, community impact reports. See Demand Management, page 80.
• Expand scope (see Design for Failure, page 38)
• Employ external consultants (recall they are almost always paid by the hour – they are on your side on this one)
• Divert resources to “higher priorities”

3.1.3 Divert
No project ends up as originally designed. With care, the result can be entirely different and much closer to the requirements of the IT department.
• Have architects, Operations or outsourced service providers over-rule design decisions and mandate alternatives desired by IT or optimal for job seeking.
• Throughout the development of the service, whittle away parts of the service as excessively expensive or not achievable within required timeframes, especially on the run up to deadlines (see Delay, above)
• Substitute other design or implementation options as “functionally equivalent”
In designing a service, it is vital to take into account Total Cost of Ownership, or TCO. This must of course be maximised to ensure adequate return to the IT department.

From the book Introduction to Real ITSM (see www.realitsm.com)

Please forward this to a friend or colleague who might enjoy it.

Syndicate content