Hi, great article. I would be interested in hearing from folks that have experience of how all this ITFM fits in with the Federal or State governments Planning Programming, Budgeting and Execution Systems (PPBES) and the Capital Planning Investment Control (CPIC) processes and systems. Thx Ron
I totally agree with this point of view.
I would just like to add to the list of alternatives the ISO/IEC 20000 standard. This change in the ITIL 'solution' could be a good driver for Companies to move to ISO/IEC 20000, which is based on ITIL, more complete than ITIL as it includes an SMS and allows the ISO Certification of the Enterprises.
The winner was:
Angel M Rayo from Spain.
1. 19th Nervous Breakdown © M. Jagger/K. Richards
2. Midnight Rambler © M. Jagger/K. Richards
3. Under My Thumb © M.Jagger/K. Richards
4. Angie © M. Jagger/K. Richards
5. Play With Fire © Nanker Phelge
6. The Last Time © M. Jagger/K. Richards
7. It’s only Rock ’n’ roll (But I like it) © M. Jagger/K. Richards
The winning entry has been randomly selected from correct answers received. The name of the winner will be posted as soon as I have their approval to do so.
All processes in ITIL follow PDCA cycle. This is a Close loop control model and is a self sustainable process. PIR is part of this cycle to ensure that the "Check" process is taken care to give a lead to next activity. The benefit might be small / big; but, unless we complete this "Check" activity we can not even know how big / or how small is the benefit. Normally i have seen in most of the cases we only fill in some badly designed templates to ensure the compliance. Most of the times the templates are so badly designed that it becomes an overhead to the Project Teams. But if we design the templates in an optimized way and users understand why we are doing this then we can certainly try to derive the bebnefit out of it. Knowingly or unknowingly also, if we start following PDCA cycle it gradually makes our system robust enough to prevent failures thru small small improvements in the whole process. Also it makes life easier to take corrective actions in case of some failures (if any).
Let us take an example of a Planning process. One Manager told to his boss that he dees not want to do planing because 100% of cases he had seen is that all plannings fail and never meet dead lines/budgets and it again needs rescheduling and rebaselining. His reporting Manager told him - that is the reason for having the Planning process, so that you are able to understand your mistake / or good planning. The moral of the story is all plannings fail does not mean we will not do planning.
Similarly PIRs does not yield tangible/substantial benefit does not mean we should not do PIR. Rather we should see how to make use of it to strengthen our Change & Release Management Process by using the learning of Success and Failures from the releases done in past. We can make trend analysis by catagorizing the Success or failure reasons and work on A class categories to prevent those failures and repeat the Good Practices.
Spot on Sean! This is one of the points where ITIL has fallen very short.
Actually, outside of the IT discipline, people do this much better all the time, but they call it Risk Management. Once you start implementing a true Risk Management process, you'll see that PIRs are actually risk definition activities that can be handled in the RM process. ITIL has made rather a mess of this, by distributing this over many practices like Capacity mgt, Availability mgt, CSI, Problem mgt, and many more - and then ignoring the coherent handling of all improvements in one single process that is integrated with the other process
The ISM Method has solved this. The Dutch new standard for ITSM has created the underlying process model for ITIL and one of the (only) six processes is risk management (called 'quality mgt' in ISM). Check http://bit.ly/ISMbook to read all about hat solution.
Snowden doesn't actually say best practice is bad. It is quite useful when the required decision has a clear cause-effect relationship. Cynefin doesn't make any judgements about which decision domain (Simple, Complicated, Complex, and Chaotic) is best. The point is in understanding which domain and its accompanying model applies based on the type of decision required.
If the decision is whether I should enter a change record for some action I need to take, that decision is simple. ITIL would say the best practice is to decide which actions require change records, and make it a clear cause-effect decision.
Deciding the type of change (standard, emergency, major, minor, etc...) should also be well defined by a best practice. It could certainly be considered a good practice, however.
Now determining the systems and customers impacted is usually more complicated, and appropriately would fall into the Complicated decision making domain. It fits the sense-analyze-respond model identified as a Complicated decision. I apply my expertise, analyze the CMDB for relationships, and ultimately identify the impacted services. Cynefin says there should be good practices from which decision makers can choose from to help make these decisions.
Complex decisions are probe-sense-respond decisions. In the ITIL world, decisions about strategy often fall into this domain. In the Change Management context, deciding how to actually carry out the change will frequently be a Complex decision.
I like the way that Cynefin requires us to determine which domain a decision falls into, before deciding what framework to apply; otherwise we are in the domain of disorder. Even Chaos is preferable to disorder; however, we have to identify that we're in a state of disorder before we can determine which framework to apply.
I don't see this at all incompatible with best practice and/or good practice, which Snowden rightfully identifies as important to distinguish. It's only a problem when we process people try to apply the domain(s) we're comfortable with (Simple and Complicated) to ALL contexts. But the same could be said about those who prefer to act as if every decision calls for Complex (or even Chaotic) decision models.
I agree - I have the same conversations in the Agile space - the current crop of Agilists believe that Agile was 'born' in 2001 and cite themselves as being in Agile since the very beginning - 2001! Too bad the rocket scientist were actually doing their version of it 1950's, IBM was teaching it in the 1960's in Los Angles and are you ready for this?
The term waterfall was coined in 1985 in DoD standard 2167 by some DoD folks who stopped at the second page of Dr. Winston Royce's 1970 paper http://leadinganswers.typepad.com/leading_answers/files/original_waterfa... See also http://www.georgeallenmiller.com/2008/10/16/dr-winston-royce-the-plight-...
Dr. Royce was actually describing Incremental - that is if you read beyond page 2 of his paper! Waterfall, the mess and failures it begat was a "mistake" and in the mid-1990's DoD rescinded 2167 and added incremental to the new standard and then in 2001 dropped waterfall in its current standard. There are seeming new Agile methods and certifications cropping up everyday.
The Scrum guys want you to believe that any work that is not directly related to developing a software feature is 'waste', that once the ScrumMaster's get hired you can fire all your PMs (they write articles about this), and now there are two Scrum "religions" competing for mindshare (Scrum.org and ScrumAlliance.org).
Hence my remark that "There are lots of good things out there of equal value or of some value - on any topic or issue that you may face." People need to start thinking for themselves more which also means being able to see different and equally valid ways of addressing needs which can include finding existing methods, supplementing their weakness with parts from other methods, and adapting to it their circumstances.
I have also used the term "Generally Accepted Practice" previously so thanks for reminding me of it's value in capturing this issue.
Many people agree that "Best" is not the best word. Back in 2006 I said don't call it Best Practice. You just inflate expectations and attach a note to your backside saying "kick me". I much prefer the term Generally Accepted Practice. http://www.itskeptic.org/node/16
But it won't go away. It must mean something: they like the reassurance of that word: "we're doing the right thing". People like simple answers. they don't like to think, to adopt and adapt, as ITIL has been telling them to do for nigh on twenty years.
So at one extreme we have the mindless adopters who don't adapt.
At the other extreme we have the mindless rejecters who won't adopt and have to invent. It is frustrating to see the Agile and Scrum and DevOps communities proudly (re-)inventing "ceremonies" and "procedures" which are pure ITIL. it would be cute watching them grow up if it weren't such a waste ... of generally accepted practice.
Very well said, excellent reasoning. ITIL's definition on service assets is confusing absolutely true.
While writing this column, I was very skeptic to write the definition of Service Asset as "Service assets are any investments or costs spent by an organization on any tangible or intangible resources and capabilities."
Because I knew, that this question would come up and you have hit me with it .
I actually wanted to quote "Service Asset as any investments or costs spent by an organization on any tangible or intangible resources"
But I was afraid to change the definition provided by ITIL, and wasn't sure how all the ITIL experts would take it.
I agree, but the ITIL documentation is again confusing stating: budget, HW, SW, information, organization, processes, management, knowledge and people as Service Assets and then not having an Asset Management process managin them.
By the way I think the only role that sensibly could manage all thees assets is the IT manager
You are correct, general business definition for asset management is different.
If you go with the general definition its confusing ;)
But as per the ITAM best practices defined by http://iaitam.org/ and http://www.itassetmanagement.net/category/it-asset-management/
Scope of IT asset management involves only below mentioned assets:
Software and its associated licenses
And I feel that's good enough; Because for managing other assets like processes, knowledge, and information there are many other best practices.
This last post doesn't clarify for me. There is a distinction between the general business definition of asset management and what is written there and then........ There is this list of (strategic) Service Assets being: budget, HW, SW, information, organization, processes, management, knowledge and people which are apparently not managed by Asset Management......
Good question Nick!
Configuration management plays a very important role in the Asset Management Practice.
Configuration management is primarily responsible for identifying, tracking, controlling, and auditing the IT operational assets.
(For e.g: Servers in data center are being used by different services and businesses, so these servers have to be identified, tracked, controlled, and audited for effective and efficient services)
Configuration management would govern 4 aspects IMAC (Installation, Movement, Addition, and Change) on IT operational assets.
Asset Management is the practice which covers how an asset/ server is requested, how the asset/ server is procured, how it is stocked in inventory, how and when it should be retired/ disposed
Configuration management takes the charge between Stocking the assets and Disposing the assets.
Hope I have clarified it, if not buzz me on my mobile.
what's the relationship between service asset management and configuration management?
Its good that there is a minor update on some aspects of Service Asset Management. Thanks for it.
But with this minor updates on Asset Management, "ITIL v3 2011 - SACM" cannot be called as a complete and matured Service Asset and Configuration Management Process.
As Service Asset Management is humongous concept which involves Asset Requisition, Asset Procurement, Asset Inventory, Asset Maintenance, Asset Reporting, and Asset Disposal.
On all my intention here is to say that "Service Asset" is loosely used. It would have been better if it was just "Configuration Management" in spite of "SACM".
Thanks for the link provided, and will place a request.
Is this article based on the 2007 edition of ITIL Service Transition?
In the latest (2011) edition, I added section 126.96.36.199 Asset Management which talks about
o Fixed assets and fixed asset management
o How a service provider can contribute to the asset management business process
o Software asset management
o Secure libraries and secure stores
o Definitive spares
o The definitive media library
o Decommissioning assets
I do agree that there could have been a lot more, but this was a minor update. If you think that more asset management content is needed then please create an account at http://best-management-practice.com/changelog/ and submit a request
Management is...letting go.
Management is...pragmatism over the ideal.
Management is...knowing how to adjust the path and not lose sight of the goal.
Management is...enabling rather than overbearing.
Management is ....knowing the 5Ws of management reporting
Management is..... saying NO when it's needed.
Management is.... understanding that processes don't touch people until they're procedures.
Management is..... married with governance
Management is Governance
Aale: Very well written and also very indicative of what can actually happen and why in many of today's organizaitons. Surprise! It's not all about IT! But...
It does beg a question about the clear lack of transparency and trust in the described environment and seems to imply that IT cannot handle business realties. In this case, instead of simply avoiding IT and what they were "selling", Geentech could have engaged them in supporting them in areas where there was actual business value.
On the IT side they could have asked themslves why there was such push back from the Greentech division, instead of continuing to push ITs clearly flawed agenda, and could have engaged Greentect in a more collaborative approach in trying to understand the real needs of their client.
This would have been the transparent thing to do for both sides. Form the story line it seems that Jen see himself as part of the "hero culture" - he has to "protect" the feelings of his people so he takes the heroic stance of "I will leave first". I think that it is paternalist to adopt the notion that people in general cannot handle the truth or that things should be hidden, Being fired (even on-mass) without knowing why can be catastopic to the indvidual. Being told the busines reasons - even when you may not agree with them - is still in my mind the transparent and humane thing to do in this circumstance.
Having been through a mass firing myself and knowing why helped me to put it behind me quickly. Seeing others who did not know why they were included in their mass firings caused a great deal of personal and lasting stress for them that took months and in some cases years to overcome.
I find the situation presented is of the hierarhical management model and I think there are better ways run organizaitons that enables more collaboration, transparency and trust.
Management is.... thinking for yourself, using frameworks when you need them for inspiration.