Announcing the IT Skeptic Awards for 2007

This blog entry has been podcast
The IT Skeptic is pleased to announce our annual New Year's awards, inaugurated last year. These awards are presented to deserving figures and organisations in the IT industry in general and the ITSM industry in particular.

This year’s winners are:

The Terminological Debasement Cup goes to Sharon Taylor, ITIL3 Chief Architect, for vague and varying usage of the word “process” in ITIL Version 3, and for describing several processes for the Service Strategy book where the original authors declined to recognise any.

The Marie Antoinette Memorial Cake for Most Patronising Attitude goes to Pippa Bass of the Office of Government Commerce (OGC) for keeping the community "involved" by sending them newsletters; and releasing the ITIL3 books in secrecy to a hand-picked list of reviewers as a "public review".

The Gartner Ribbon for Most Preposterous Statistic goes to McKinsey for saying that “only 34 percent say that they are more effective at introducing new technologies than their competitors are” (like saying "only 34% are tall"). The runner up is Dennis Drogseth of EMA for comparing different populations between surveys.

The Andrés Escobar Memorial Shield for Best Own Goal goes to IT Service Management Forum (itSMF) International for signing a contract to publish the ITSM Library in direct competition with their contract with TSO, causing publication of ITSM Library books to be suspended until the mess could be sorted out. They also receive the Trump Medal for Most Inappropriate Empire Building for the same contract.

The Snake-Oil Championship is won by Ken Turbitt of BMC for promising “ITIL out of the box”.

The Joseph Stalin Award for the Revision of History goes to OGC for quietly deleting the 1.1.1 section of ITIL2 books that referred to ITIL as “public domain” and “publicly available” that “any organisation can use”.

The News of the World Trophy for Services to Journalism goes to Matt Stansberry, Site Editor, SearchDataCenter.com for saying that Alasdair Meldrum “literally wrote the book on the IT Infrastructure Library (ITIL)” and thereby perpetuating the myth that IBM wrote ITIL1.

The Deng Xiao Peng Memorial Spittoon for Services to Democracy goes to itSMF International for whispering the call for nominations for its new Executive Board, eliminating five of twelve candidates on a technicality, releasing the results ahead of time, and then electing the Chairperson in a process contrary to that agreed with the full Board.

The Mata Hari Mask for Nefarious Activity goes to whoever was behind the pseudonym Dr Julie Linden.

The Tony Soprano Memorial Best Friends Steak-knife is awarded jointly to The Stationery Office (TSO) for undercutting itSMF by selling V3 books to major buyers direct around the same time that itSMF was funding and organising the worldwide promotion of those same books for TSO, and to itSMF International for taking a cut on the discount they pass to local chapters of itSMF. Both parties also receive the Angus and Malcolm Young Dirtiest Deeds Ribbon for the same achievements.

The P T Barnum Gold Cigar for the Most Hyped Concept of the Year goes to the UK Communication Workers Union for describing acoustic shock as “a devastating 21st Century industrial injury problem ruining call centre workers' lives and costing industry millions” then extracting over two million pounds from BT and other employers, narrowly edging out last year’s winners the CMDB Federation of vendors for allowing another year to go by without any standard for CMDB federation emerging (they lost first place this year by finally getting a first draft out in August this year).

The Dumbdown Cup goes to APMG for two stupendous contributions: designing an ITIL3 training program designed to maximize revenue instead of learning, and reducing supposedly masters-level ITIL exams to multiple choice format.

Finally, the one you have been waiting for …Envelope please… The Grand Sagan Candle for IT Skepticism goes to Steve Andriole of Datamation for 10 "New Rules" for IT

Congratulations to all our winners and Happy New Year everybody!!

Comments

Understanding process

Skep,

The "expert" critiques on ITIL’s use of process have been interesting and at times amusing - until the recent shot at Sharon Taylor. My opinion of Sharon, of her integrity, and her genuinely noble efforts, is too high to let this pass. So let me offer up a differing viewpoint.

Process is an abstract concept. As a concept becomes more and more abstract, so do the differences by which human beings perceive the concept. Hence the desire to model processes. It is a tool to understand a very intangible problem.

But models, as you’ve pointed out elsewhere, are limited representations. The model of an automobile represented in the user’s manual may work for someone seeking to drive the car but is useless for someone seeking to repair the car. Similarly, *any* process definition should be considered an incomplete representation. Instead, process definitions should be considered in terms of their usefulness and falsifiability; of pros and cons.

The predominate definition of process seems to be that of a “set of interrelated activities”. The fact is, however, there is little agreement on what a process is or its key constituent elements. Please don't let anyone tell you otherwise. In the business process realm, for example, you can find several widespread perspectives. Here is a sampling:

**Workflow Perspective
Process is seen as flows made up of activities that have some sort of relationship to each other. Ergo, if activities are not perceived as related, they are not part of the same process.

Here’s the catch:
- processes are what we perceive them to be. So too are "activities" and "interrelated". If an IT manager perceives the activities within “design a service” and “operate the service” as interrelated, then the process activities will span departments. If the next manager's perception differs, however, then this process will be incomplete. Whose interpretation is correct?
- More troublesome, however, is the fact that workflow-related flowcharts show data and materials flowing. This is misleading, as data and materials do not really flow between activities. This is a critical shortcoming I won’t go into here.

**The Data Flow perspective
This is where processes are positioned as data flow entities, an important construct for structured systems techniques as well as object-oriented analysis and design. Many would position this as better than the workflow perspective because it doesn’t make the same mistakes.

**The Systems Perspective
A process is viewed as an entity representing the “transformation of inputs and outputs”. The aim is adding value to customers. The last decade has shown this to be a more useful view than the workflow perspective.

**The Object-Oriented Perspective
This is an extension to the data flow view. You can find it used, for example, in UML. (Jacobson)

The experts on this board seem to have settled on the Workflow perspective, with a heavy dash of early BPR, a movement long discredited. The fact is all the above perspectives (and a few others) are encountered when addressing the manner by which IT goes about improving its business. Therefore, in order to be faithful and remain useful “across industries and across cultures”, ITIL should not favour one view over the other. The final say is, and remains, a work in progress.

Sharon seems to have navigated these competing views and the Service Strategy book explanation reinforces this nicely. Process definitions are left to the local process engineers, as it should be. There can indeed be a Capacity Management process for certain organizations. There can even be a CMDB process. Really. Both can be deemed proper and pragmatic by those who matter most - the local organization. The ITIL guidance is written loose enough so they can adopt and adapt what they find useful. This is a virtue not a defect.

So, can we strip Sharon of the recent award or not? I think the term "ITSM expert" has been much more debased.

Process confusion

- We are not talking about the failures of BPR twenty years ago. We are talking about the BPM community as it exists today.

- There is plenty of agreement as to what a process is. The commonly accepted definition, not addressed in the above post, is that a process starts with an event, delivers a value-added result for some stakeholder, and is repeatable and countable. "Manage Capacity" is not countable. "Prepare Capacity Plan" is. This commonality can be found across the various "perspectives" cited (by the way, a non-rigorous taxonomy that many would take issue with).

-BPM professionals are to be found in influential roles in most solutions delivery capabilities, as well as ensconced in business units. To the extent that the ITIL authors seemingly disregarded the BPM community's general consensus on these matters, it is to the detriment of ITIL's credibility with broader audiences.

- "processes are what we perceive them to be." Processes are what we agree them to be, as collective organizations. Gaining consensus on abstractions is never easy. Does that mean that everyone gets to decide for themselves what the process is? Absolutely not.

- The term "meta-process" is used inaccurately. A meta-process would either be a process for governing processes, or else a generic building block for describing processes. ITIL is in no sense a "meta-process." Calling it a "process framework" is acceptable.

- It would not have required detailed IDEF0 (or IDEF3) artifacts for ITIL to have been much more precise in these regards; that is a red herring.

- The creation of the new "functions" of Technology Management, IT Operations Management, and Application Management only compounded the confusion. If everything had been called a "process" it would have been more tolerable, but these new added "functions" give the sense of some actual method being applied, which does not appear to be the case.

Charles T. Betz
http://www.erp4it.com

Couldn't disagree more

I’m very familiar with this definition. It is derived from one made famous in 1993 by a buddy, Thomas Davenport, while he was at E&Y. He doesn’t mention “counting”. That came later to help laymen get started. Few veteran process engineers treat it with such absolutism, while many never accepted it at all.

Many who adopted Davenport’s definition in the ‘90s have since moved away from it. They know the most common pitfall in improvement programs is the over-emphasis on the process component, or worse, the isolation of the process improvement. (Muller, 2007)

Any process-centric business analysis is inseparable from its models. This definition is a basic model with well-known flaws. For example, it pays little attention to how different representational views can affect process redesign. Many will argue it does not adequately consider true nature of redesign projects. They would offer evidence, such as that garnered over a six-year empirical study, which states that better results are achieved by redesigning the flow of communication or information in process redesign rather than activity or workflows.

This “neat and tidy” definition promotes
- a technocratic view (process design with automation as the goal),
- the sub-optimization problem (the mistaken belief that solving the little component problems resolves the big one)
- and hierarchical orientation (such as IDEF, DFDs, etc).

In practice, these problems are characterized by:
- Efficiency undermining effectiveness as design objectives
- Single threaded processes named as design objectives
- Inability to separate processes which should not (or can not) be modeled. For example, un-improvable processes, those which exhibit meaningless (or unattainable) performance metrics, processes which are situation-dependent, creative processes, etc.
- Introducing “white space” into processes which cannot be modeled.
- Models biased by the underpinning meta-model
- A tendency to create a “cult of measurement” and frame the world through cost, quality and time metrics. What about value creation, innovation, collaboration, learning, strategy, business outcomes, etc.? (Christensen)
- The framing of process domains with hard, fixed boundaries. What process works in a vacuum?
- Replaces functional stovepipes for process blinders. Replacing one narrow view with another that results in no better perspective.
- The value paradox

(These endemic flaws are all supported by peer-reviewed papers and practitioner case studies.)

Clinging to a definition which has been unable to cope with the reality of business processes should not promoted, no matter how “countable” the model. Weary practitioners continue to seek better definitions. Smith and Fingar’s version, for example, has been adopted by IBM, Bearingpoint, Accenture and other consultancies:

“A business process is the complete and dynamically coordinated set of collaborative and transactional activities that deliver value to customers.”

Or the version by Lorino and Tarondeau, adopted by McKinsey, business strategists, and researchers who rely on the resource-based view of strategic management:

“A process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an output which, directly or indirectly, creates value for an external client.”

And there are others. I don’t suggest these are the final answers but to assert there is universal agreement is, well, naive. It is certainly not ITIL’s domain to resolve.

BTW, if there are issues with the prior process taxonomy, take it up with IEEE. They, and other process journals, have deemed it worthy of publication.

Processes are “…what we agree them to be, ...”? Isn’t this the same tautological trap? I.e.:
“Why are these your processes?”
“Because we agreed upon them.”
“Why did you agree upon these?”
“Because they are our processes.”

Don’t’ get me wrong. I love tautologies. They help me sleep soundly at night, secure in my future employability.

Much ado about little difference

That old definition seems to be responsible for every business/IT dysfunction under the sun. Yet it differs from your preferred definitions in some straightforward aspects: 1) being event-driven (and therefore countable), 2) being repeatable, and 3) being somewhat more granular. Your definitions are more abstract and less precise, from which other problems arise (see below). And from these differences, you make tremendous and unsupported leaps to a whole set of large scale abstract problems.

Your definitions focus on "sets" of "activities" without defining what an "activity" necessarily is. To me, this is the wearisome semantics of granularity. One person will say that a "value chain" is composed of "processes," and the next person (looking at the same problem) will say that it is a "business process" composed of "activities." Activities decompose into workflows, or is it vice versa? No consensus is to be found on such matters.

The useful distinction - and opportunity for meaningful consensus - to my mind does not revolve around granularity, which is a persistent problem. The useful distinction revolves around ordered versus unordered.

But let's get back to the original question. This debate started around ITIL's incoherence in defining function versus process. Is this no longer even a viable distinction? (Funny then that v3 cited Rummler/Brache...) The quotes you selected tend in that direction, because if you remove the event component from the definition of "process," it becomes almost impossible to differentiate from "function."

Personally, I think that doing away with decades of process/function distinction is a remarkable direction. For better or worse, there remains a strong differentiation between the two that has not been erased in common BPM discourse, a distinction that ITIL chose to interpret idiosyncratically - and not, I suspect, for the rarified theoretical reasons that you cite, but rather due to lack of familiarity with the basic process engineering literature & principles.

Yes, it is a basic definition. As such, it still has utility in that it is how the vast majority of working process engineers I know approach the problem today. Your comments move in a theoretical direction I find difficult to operationalize for solutions delivery. Where are the new methods to replace the old? Where is the event perspective, if 'countable' is no longer a criteria?

It's interesting you cite Davenport, given his latest work. Where would business intelligence be without discrete, repeatable transactional events that can be aggregated into the terabytes of data underpinning his Competing on Analytics? A close reading of the implications of "third wave" BPM would scare any BI professional to death. What becomes of the data model when the processes are infinitely variable?

One of my responses to the over-prioritization or siloing of process (a problem I *do* agree with and have seen in practice) is to use integrated architecture tools that allow the simultaneous, interlinked definition of process, function, data, systems, and organizational models. But this requires analysts who are comfortable moving between all these perspectives, a rare breed.

I also agree that much business activity does not lend itself to an event-driven or transactional model. But I doubt very much that an event-driven approach inherently results in a "technocratic" orientation. Again, quite an unsupported leap.

"better results are achieved by redesigning the flow of communication or information in process redesign rather than activity or workflows." -> To me, that is all part and parcel of process engineering/re-engineering; I would be hard pressed to distinguish between "redesigning the flow of communication" AS OPPOSED TO redesigning "activity or workflows," doing one in the absence of the other. A wholly academic distinction, of little use to practitioners.

IDEF is not wholly hierarchical; it does have a decomposition aspect which superficial analysts may focus on, but it is capable of networked many to many relationships among nodes across the processes. (And, you need to distinguish between IDEF0 and IDEF3 as well). DFDs are the same; a method of decomposition into networks - neither strict containment nor linear processing implied. Today, both are still used where appropriate as tools, not as paradigms.

Re: metamodel bias. A metamodel is simply a language. And yes, languages bias. What's the solution? Are we going to find a brave new world of describing process without a language to do so?

Single threading (where avoidable) is an error of process design, and multithreaded process solutions are common (cf. the basic process notational constructs of "fork" and "join"). An event-driven approach certainly does not lead to single threading, which would be more an issue of process engineer competence, understanding of design patterns, etc.

There *is* an interesting advanced debate around whether processes are repeatable. BPML and UML v2 handle this issue to some degree through the recognition of process interrupts. But repeatability is still a valid criteria and not necessarily indicative of a technocratic bias.

Re: agreement on process = tautology. Since this is a daily part of my life, I'll gladly admit that the tautology is pretty much it. Trying to inform and influence that endless loop is why I study, attend professional meetings, etc. But at the end of the day, the tautological consensus (whether on process, data, or system) is critical to running a shop, and whether it is "right" or "wrong" is less important than that it exists. See Martin Fowler on ApplicationBoundary. And I'm comfortable with it, cf. Mannheim's "intersubjectivity."

Re: taxonomy. IEEE cite please, and of course appearance in a peer reviewed journal is not necessarily indicative of anything; some rather ignorant things have been written by academics about real world enterprise IT. (I've had to set the record straight for CACM on metadata for example; check back about 2 years and you'll see my published corrections which were accepted by the academic authors.) The taxonomy is flawed and non-rigorous (OO process perspective as an extension of DFD? 'Used' in UML per Jacobson? Historically untrue and idiosyncratic characterization that wouldn't pass muster with any SDLC, OO or UML expert...), but I won't bother further with it.

Wishing that this was the Well and everyone had to disclose their true identities.

Charles T. Betz
http://www.erp4it.com

BPM awareness

Charles - you're absolutely right with the observation that BPM has grown into a valuable field of its own, and that references to 'the BPR disaster' are completely outdated.
The systems approach to process management is now widely acepted as the way forward. Unfortunately this is not accepted in the ITIL books. It missed in V2, which can be qualified as a temporary glitch, but it still missed in V3 - and that is a more serious issue. Especially since V3 is claimed to build on the progress made in V2, and *less* instead of *more and better* information is provided on processes. We tried to compensate that as much as possible by splitting the lifecycle information from the process/function information in the much disputed ITSMF book on ITIL ("Foundations of IT Service Management based on ITIL V3").

Processes are indeed what we *want* them to be. There are many ways of creating a trigger-based sequence of activities that lead to relevant business goals. Some of them are good, others will be better, and we may even conclude that some are 'best' (and hopefully document them in ITIL V4 or some other publication). I believe that - with IT service providers - the core processes have become quite commoditized, and it's high time to standardize them. The initiatives that the ISO organization is taking on the extensions of ISO 20000 may just provide that.

The documentation on a number of processes in V2 was quite adequate and provided great value. Unfortunately, the list of documented core processes was rather incomplete and there was a serious confusion with 'functions'. This confusion has grown in V3. Qualifying ITIL as "a process framework" is therefor imho not correct. ITIL provides a series of practices at the level of procedures and work instructions, and the process framework (in BPM terms) is definitely missing. But then again, the introduction in the books always showed clearly that ITIL never claimed to be a process framework. So most people have been looking for the wrong thing.

Where does that leave ITIL? Simple: a very useful reference framework of practices that are relevant in IT management organizations. Its scope is limited to technology-related service management, and it focuses at the service provider domain. If you can put it in position in your wider "information management framework", and you combine it with your process architecture and your understanding of matrix organizations, it can be of great value - just like many other sources of information. But it would be nice if ITIL V4 would provide the vision base that enables the reader to recognize how to apply the ITIL practices in their end-to-end information management architecture. In the mean time, I'm sure that this information gap will be provided in other publications soon enough.

Jan van Bon
http://www.linkedin.com/in/jvbon

BPM Sheep-Dipping

Let’s think about this for a moment.

The evidence for BPM is reminiscent of the evidence for, say, the CMDB or an L. Ron Hubbard book. The most visibly touted BPM success recently went bankrupt. And it has been a long time since any new major industry projects have been launched.

Depending on the study of choice, indications are that industry interest in BPM has trended *downward* since 2003/2004. Frustrated with shady vendor shenanigans, lack of industry adoption and with what the Skeptic would call the “terminological debasement” of BPM, thought leaders broke away with BPM 2.0, a radical redefinition nicknamed “process without programming”. Vendors lament that industry doesn't care and are hastily repositioning products for SOA, a movement trending upward during the same period of time.

Is this really the shining example ITIL should look up to?

lessons learned

Perhaps BPM is not a shining example ITIL should look up to, I certainly am not one to judge that. However, if the BPM community has made some mistakes maybe there are some lesson learned there.

I'd like to know what those are. I get that 'we have all been here before' feeling, but at a basic level what happened (or is happening) to the BPM "community" that the ITIL community can learn from?

There must be SOME value there.

John M. Worthington
MyServiceMonitor, LLC

We appear to be talking about different things

We appear to be talking about different things.

I am talking about BPM in a narrower sense as a disciplined method and community of practice, comparable to (arguably a part of) enterprise architecture, which also encompasses data architecture & systems architecture. Some call it process architecture, and the practitioners I work with daily call themselves "process engineers." When I worked at Accenture, "process" was one of the disciplines incoming consultants were tracked into.

As an analysis method with decades-old, evolving track record (encompassing the various perspectives of workflow, data flow, etc), process analysis is used as part of the solutions development lifecycle to understand the business' operational model and inform the automation strategy for the portions of that model to be supported by IT application services. In its Six Sigma and related aspects, it plays a critical role in continuous improvement efforts. In such roles, it is no more a fad than is object oriented design, data architecture, or application architecture. It's just part of the solutions development toolbox.

And it's not just the process architecture perspective that has much to offer ITIL, which has also gone astray in terms of data architecture and applications architecture as well - the v2 CMDB fiasco, the overly broad definition of "change," and many other gaffes come to mind.

BPM has other meanings, including a grandiose meaning as a management "movement" and as a class of industry tooling, and in these guises is subject to the usual hype cycle. You seem to think that its current position (probably heading into the "trough of despair," though I haven't looked lately) is somehow relevant. Sensibly scoped, it will (as other fads have) emerge into a useful role; I know of multiple production BPM implementations that serve business needs quite well.

Positioning BPM as somehow alternative to SOA is questionable; there is plenty of commentary on how they are complementary, and very much two sides of the same coin. BPM process choreographies invoke SOA services. And SOA has its own challenges, with many questioning the evidence for *its* value.

Some notes on BPM 2.0: The Smith/Fingar "third wave" pi-calculus challenge is old news, controversial at the time, and it would be a stretch to say that the broader BPM community has yet embraced their ideas. Neither of them was a player when BPMI was merged into the OMG, a move orchestrated over their opposition.

In this and other posts, some seem to be critical of any technique that isn't a "provable" silver bullet to boost the bottom line. That's too high a bar. To me, BPM is just one more tool in the box, along with data and systems architecture analysis techniques. When you need any of these tools, there is no substitute. Provability is there in the mathematical foundations of Petri nets, relational calculus, and so forth, and even to the extent of software engineering project metrics (success/failure, budget over/under, defects, etc).

But looking for certainty of business success through the use of any of these is a fool's errand. I wouldn't purchase stock based on whether a company is using BPM any more than I'd purchase stock if they had crackerjack data modelers, SOA capability, CMM certification, Agilistas, top notch data centers, or what have you. None of it "matters," per Carr. If you want to know what management practices provably boost profitability, see McKinsey. Of course, when management decides to emphasize accountability, goal setting and tracking, and some operational basis for doing so is sought, then we're right back to BPM -- perhaps first in its rendition as Business Performance Management, and eventually in its original meaning.

There are no silver bullets.

Charles T. Betz
http://www.erp4it.com

BPM, ITIL & ISO

I've been poking around for an 'industry standard' BPM credential (perhaps BPM credential is not the right word); most of what I've seen are 'certifications' tied to either products or proprietary methodologies...in fact, it appears that the fragmented nature of 'BPM certifications' may be the path ITSM is headed for?

Anyway, I'd be interested in more on ISO's plans for ISO20K extensions...when, what, etc. Why wouldn't the ITSM community be interested in blending ITIL, et al into generic business quality societies (maybe like the ASQ and/or thier Intl' equivalents)?

It certainly seems that this community, with all the ISO 9000 experience, etc. has a lot to offer the ITSM folks. Not seeing any of that from itSMF or anyone else right now...leaving it at 'six sigma' may not be enough.

Interesting that sometimes the ITIL programs do not benefit from the BPM initiatives, even when there are six sigma trained staff right down the hall...

John M. Worthington
MyServiceMonitor, LLC

the buck stops

I too have a high opinion of Sharon, but the buck stops with Chief Architect. I think the move away from a process-centric approach in V3 was the opportunity to use "process" strictly and consistently, whatever definition was settled on. But it is evident there is no one consistent interpretation of "process" across the books, and the ultimate accountability for that has to rest with Sharon.

That's my view of it, anyway. I'm happy to debate this one. What do other readers think?

Not just process...

Skep,

I agree with your assessment of the situation.

To assert that Sharon's "integrity" is at question here is a red herring. That's not the issue. This is not personal and (taking it personally) only diverts attention from what's worth discussing.

It's also worth noting that this is NOT the only area of the books where such inconsistencies exist. If it were, then we could attribute this to Skep being overly critical.

I think that this is unfortunate for everyone, becuase it leaves it upon the reader to determine how to (properly) interpret it. Once you've made that jump, you're history... it's now on you (the reader).

A little rigor goes a long way. Well-managed and open (pre-publication) review programs can help provide that.

kengon

red herring

I'm not sure why ITIL had to make a stand on process. Despite the 3rd-party press clippings, ITIL has never been a process model. At best it was a meta-process model. A tradition maintained with version 3. The same goes for governance, project management, business process and software/systems development. These frameworks exist elsewhere and are not the purview of ITIL. Someone shouldn’t pick up ITIL expecting a treatise on business process management.

Services and service management, on the other hand, is its domain, and it has certainly taken a stand on those abstract concepts. So much so that some have winced, pining for the simplicity of v2. You don’t see CMMI or COBIT taking the time to rigorously define “service”. Nor should they. They’ve a big enough challenge within their own domains.

I can’t imagine what the reaction would have been if ITIL had gone down the process engineering rabbit-hole with, say, IDEF diagrams. I suspect anything short of that would still provoke concerns about process ambiguity. ITIL is not a BPR handbook. It’s about service in an IT context. Readers may have to reach elsewhere for a greater understanding of process (or governance or program management), but isn’t that generally the case for all frameworks?

Nor am I certain the same perspectives should be mirrored across the books. The books are written for different audiences. Would you really pick up CSI for its process definitions? That's sort of like a dilbert-esque process for "thinking out of the box". Instead, I’d think you'd read CSI for its guidance on embedding PDCA into an organization. Not only are these two very different constructs, but process rigor works against the very premise of CSI: challenging the existing assumptions about how business is performed. Take this perspective into Service Operations and you are shown the door.

Somewhere along the line, ITSM practitioners developed a fixation on process and forgot there is more to organizational capabilities than process and functions. Now that I think about, the empirical evidence for process-led improvement as a whole is quite weak. Wouldn't that make for a post worthy of the name ITSkeptic?

As far as Red Herrings go: Anytime you put together a list and include descriptors such as "Pablo Escobar", "Stalin", "Soprano", "patronizing", "snake-oil" and such, you are casting a underlying message of underhanded nefarious activities. I doubt Sharon, Pippa Bass, or Messrs Turbit and Stansberry deserved such treatment. Julie Linden, perhaps.

Unfair descriptors??

Visitor,

In my opinion, the comparisons that Skep chose provided color, contrast and his own blend of edgy humor. I did not take them literally, nor do I think anyone else should. Of course, in publishing the list in this fashion, that's the risk the Skep takes.

From my perspective, the assessment is still a valid one. By virtue of Sharon's role, I believe that she has a responsibility to those who appointed her to the role and to those who consider themselves part of the stakeholder base (of which I consider myself part of).

As the "head honcho", she deserves to be held to a higher standard in performing in that role by those she represents. Indeed, when you take on such a leadership role, I think you're signing up for just that.

What would be unfair would be to hold someone else to account for their performance that is outside of their role/responsibility or ability to influence. In this instance, it is clearly not the case.

The other instances here, as I don't have any specific knowledge to refute it (or enough interest to research it), I'll support Skep's position until he decides to change it.

Cult of personality

Forgive me. I see better now.

You perceive yourself as an ITIL stakeholder, therefore Sharon is public property. Never mind that she works for OGC, the rightful owners of ITIL, not you and I. She is now a figure, not a flesh-and-blood person. She can be caricatured, scrutinized and criticized in a way private citizens are not. I didn’t see this as clearly until now. I'll try to be a better sycophant.

New, Improved Sycophant...

1. Yes, I do consider myself an ITIL stakeholder. The works that OGC commissions have an effect on me and many that I work with. I am extremely interested in the outcomes and whether the impacts of what gets produced are good/neutral/bad, relative to what we are trying to accomplish.
2. Your leap of logic "therefore Sharon is public property" is absurd. I never intimated that. I appreciate that she is a real person with feelings. From my limited interactions with her, I believe that she's a generally good, forthright and honest person.
3. Any criticisms that I might suggest/support re: Sharon would be solely limited to her role and responsibilities related to the ongoing development of ITIL. It just so happens that she's the only one that has the job. Should I start criticizing the Skeptic (or even you) for not doing her job?? Not likely.
4. I'm not even going to (directly) address your sycophant remark.

comes with the role

Now you're getting emotive, which is a shame as you contribute some of the best comments on this blog right now. I did not compare Sharon to any unfavourable figure or caricature her in any way. I did accuse her of terminological debasement, and as Chief Architect of ITIL3 I think that is a fair cop, if you accept the argument that ITIL3 uses "process" in a sloppy way. Yes, scrutiny and criticism come with the role. If you think Sharon is above scrutiny and criticism then you are the sycophantic one.

Having it both ways

Skep,

I’ve enjoyed your blog - truly. In the beginning, you positioned it as a provocative battlefield of ideas. Throw in the colorful rogues gallery of contributors and you filled a gap no one knew was missing.

The last couple of months, however, have taken on a different tone. The edges are sharper and more personal. Attacking ideas and attacking people are not the same. You can debate ideas, you cannot debate personal attacks. American politics knows this all too well. That’s why the smart ones never run for office.

No one likes to be personally ridiculed publicly, enshrined forever on Google. When good people shy away from tough jobs because they’d rather avoid lists like this, we all suffer. The debate becomes one sided and, ironically, you become the monster you are seeking to slay.

When I tried to veer the debate back to the ideas, this was the response:
"I don't have any specific knowledge to refute it (or enough interest to research it), I'll support Skep's position until he decides to change it."

Is this not a sycophantic response? Is this not the very same ITIL-cult philosophy you rail against?

You can't have it both ways.

criticism of a person and personal attack

I am criticising individuals, yes, but

  1. I have (I thought) detailed why those criticisms were justified.
  2. I think you are failing to distinguish between criticism of a person and personal attack. I remain sensitive to preventing personal attacks on this site. These Annual Awards are allowed to get a bit barbed, like a celebrity roast or the telegrams at a wedding, but I hope I can walk that fine line. I do hear your concern. If I get more negative feedback (which I haven't yet), then next year I'll consider making the Awards only to organisations not individuals.
  3. Stuff goes on that is not nice, that is not well-meaning volunteers doing their best. We're playing for $5 billion per annum stakes here and some people don't play fairly. Sometimes I'd like to be criticising individuals more: the stuff I've named people for is pretty innocuous.
  4. Sharon letting the word "process" wriggle around is of course not an example of anything nefarious, but I never suggested it was. I doubt Sharon's opinion of me has changed one iota as a result of that Award - I hope she's mildly amused as most people would be.
  5. Ken won't be happy with his Award but he's in sales: we develop a thick hide. If anyone has a right to be a bit miffed it is Pippa Bass who for all I know isn't like that at all and quite possibly didn't even write the quote attributed to her. I'm not sure why you are focused on the mildest of the named Awards
  6. Some of these Awards date back eleven months and last year's were pretty sharp-edged too, so I don't see I've changed "recently".

I hope you will continue to enjoy the blog, and to be part of the "colourful rogues gallery" of contributers.

Works both ways...

"Is this not a sychophantic response?"

No, it's not. I don't care enough about the issues you took with Skep's comments to research them further. If I find out something at a later time that would have me alter my position on something, then I reserve the right to do just that. Adults are capable of doing that.

I have many disagreements with Skep. Most I don't blog about here, because I don't enjoy arguing (especially with Visitors). Many issues I do respond to and I intend to keep doing so. I'm not going to pray at the "Skeptics Temple" or lick his boots.

If you think that your most recent posts are examples of bringing the conversation back to ideas, then you are only misleading yourself. Bring some real ideas, instead of your emotionally charged baggage, and maybe this can go somewhere.

*You* are the one who needs to realize that you can't have it work both ways.

I'm officially done with this thread. Hope you have a great 2008.

I disagree about the Awards being unfair

Excellent comments about the limits of ITIL's domain. The whole fixation with process does indeed interest the Skeptic.

I disagree about the Awards being unfair. While Taylor and Bass are no doubt nice people, anyone who chooses to take a position at the top of the pyramid also chooses to take responsibility. We are already debating whether ITIL debases "process". I will strongly debate with anyone who denies that OGC's attitude is patronising and paternalistic and non-collaborative.

And as for the Stalin Award, quietly deleting the words "public domain" from ITIL was Ministry of Truth stuff. Next year I'll make it the George Orwell Award, OK?

Read my critique of Turbitt's paper and if you still think it did not deserve the "snake oil" tag then let's debate that too. I was disappointed by it and expect better of both Ken and BMC. I stand by my critique.

Um.. what else... Soprano. itSMF volunteers ran a worldwide promotional campaign for TSO's commercial product that in any other industry TSO should have organised and funded themselves. TSO repaid the favour by offering itSMF a discount of I think 35%, then offering some major Big Four buyers a direct discount of 40% [first revealed on this blog], i.e. they deliberately undercut them. itSMF International then did the same thing to the chapters it purportedly represents: it did not pass the full 35% on so that local countries could not compete with International's own bookstore. If that is how nice people behave then I'm not sure what constitutes dirty deeds.

The only thing I would change in the Awards is that the Deng Memorial Spittoon should have gone to Brian Jennings personally as Chair of itSMFI.

Yes the Awards do get a bit more snide than I normally do (some would dispute that) but that is the nature of such Awards.

The Award for the Best Awards List Goes To...

The Skeptic.....good job and thanks for keeping us entertained!

Syndicate content