http://blogs.pinkelephant.com/index.php? en p.bernard@pinkelephant.com Copyright 2010 2010-08-25T12:54:15+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/common_sense_is_better_than_nonsense/ http://blogs.pinkelephant.com/index.php?/itilv3/common_sense_is_better_than_nonsense/#When:12:54:15Z When it comes to defining let alone understanding or explaining what the IT department is or does many are baffled or scratch their head. Unlike the lyrics from a popular song by Bob Dylan from the 1960s, the answer is not blowing in the wind. The answer is quite simple. IT is a part of an organization. Its a simple matter of common sense. Common sense – noun sound practical judgment that is independent of specialized knowledge, training, or the like; normal native intelligence. Origin: (in the English language) 1525–35; translation of the Latin sēnsus commūnis, which is itself a translation of the Greek koinḕ aísthēsis Since it appears the Romans borrowed this expression from the Greeks, we could extrapolate the Greeks may have borrowed it from earlier civilizations. Why, we could even argue that every civilization had and used common sense! I am on a roll! Let me go out on a limb. I claim that information technology has been around since the invention of the written language. This is currently acknowledge to be around 6,000 thousand years ago. There are current discoveries that could push that number back but let us not speculate or argue and this is not what this entry is about. The technology has changed since then; from using rocks, clay tablets, papyrus, vellum, paper, to the current computer interfaces we are using today. No matter when, no matter what needed to be recorded, the information had to be « managed ». Fast forward to today and people are still arguing about what IT is. As I said before, IT is « a » « part » of an organization. Every function in an organization uses some form of technology to store information. IT has never been apart from the organization even if some people claim the opposite. The difficulty is that technological advancements fast outpaced the management of the technology and of the information captured or created (see Moore’s law). This created a few decades where technological wonders be it hardware or software were more anticipated then what we could realistically do. The management aspects quickly lagged behind. As more and more people became computer-savvy and started using computers in their lives outside of work (shockingly, there is such a thing as life outside work) they realized that computers, computer technicians, programmers, and developers were OK to have around but that they did not necessarily knew how to manage the IT department. I have been involved with and in IT since 1984. One of the mistakes made was to ask people who were great at their job to become managers. In insight, this was a bad idea and it was poorly executed. This lack of managerial experience and knowledge was a significant contributor to the chasm between IT and the business. Mind you, I am not blaming the people who accepted the « promotion » to a management position. So eventually, people started to think about managing IT better. Being IT people, they tried to invent a solution. Some people eventually sat together and came up with “best practices” for IT. It was a good idea. I was not involved so I can’t speak for the original « creators » of those practices but they already existed in the business. The above preamble could have been written much more succinctly. I did not do so on purpose as I want to make a point. The point is this. Look around you. Look at what the people in the other parts of the business are doing. I can and I will provide, in upcoming entries in this blog, examples of the existence of all of the activities in ITIL v3 in other parts of the business. Because what we do in IT is no different that what the business does. It is simply a matter of common sense. Stop trying to re-invent the wheel. Stop to smell the roses. Have fun. Turn off your mobile device for a day. Go play in the park, read a book, relax. Like my former colleague, Jim used to say, « Have fun out there ». 2010-08-25T12:54:15+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/there_is_no_itil_v4_coming_your_way/ http://blogs.pinkelephant.com/index.php?/itilv3/there_is_no_itil_v4_coming_your_way/#When:23:54:27Z Social media is a great thing; don’t get me wrong. However, it is an excellent way to spread incorrect information, falsehoods, legends, myths, half-truths, etc. Recently I have read in a few places “ITIL V4 is coming”. This is NOT the case. As the “Hitchhiker’s Guide To The Galaxy“by Douglas Adams (1952 - 2001) indicates on its front cover “DON’T PANIC” As I mentioned above, the ITIL V4 news is one of those incorrect information, falsehoods, legends, myths, and half-truth. Yes, the ITIL V3 core books are being updated. However, no one is writing ITIL V4. As I often say, when in doubt, go to the official source. In this case the source is the Office of Government Commerce (OGC) Read the following document explaining exactly what is being done, why, who is doing this, what is in scope and what is not in scope. Scope and Development Plan: ITIL® V3 Update By the way, the qualification scheme will not change. The Examining Institutes, Qualification Board and the Senior Examiners will review the syllabuses/syllabi based on the new version of the appropriate books once the books become available. So, in the mean time, and deliberately misquoting the great Frank Sinatra “STOP spreading the news, ITIL V4 is not for today” I leave you with the following closing song lyrics from a Canadian television show called “Wayne & Shuster”. The duo aired on the Canadian Broadcasting Corporation (CBC) between 1954 and 1990 in various shows and specials. “Well I see by the clock on the wall, that it’s time to wish you one and all… goodbye, so long…? ... farewell, adieu… Be good (Stay Well) Bye Bye (Keep Warm) Relax (At Ease) Take Care (Stay Loose) Adieu mon vieux. A la prochaine. Goodbye ‘til when we meet again!” 2010-08-09T23:54:27+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/personal_rant_about_people_complaining_about_the_itil_v3_scheme1/ http://blogs.pinkelephant.com/index.php?/itilv3/personal_rant_about_people_complaining_about_the_itil_v3_scheme1/#When:15:05:54Z There is much negativity presently in various blogs and social media sites about the ITIL® v3 scheme. First, and sorry for being blunt, «It is what is it is». Second, I am a senior examiner working with a great group of fantastic people. These people only want to create the best examination scheme possible. Third, and for your information, coming up with the appropriate syllabus for each course in the ITIL® V3 qualification scheme was not easy. We, the senior examiner panel; came up with many great ideas but at the end of the process, we could not use them all. The scheme was reviewed and approved by the Qualification Board. The board is composed of members from each of the Examining Institutes (EI), ITSMF International, The official Accreditor (APM Group), and the Chief Architect for ITIL® v3. Many people are involved in this. Fourth, please consider the following: • The ITIL v2 qualification scheme covered just two [2] books (Service Support - 306 pages & Service Delivery - 373 pages) each with five processes plus the Service Desk and a bit of Security Management   o This meant twelve [12] topics to cover in 2 to 3 days depending on the Accredited Training Organization (ATO) • The ITIL® v3 qualification scheme covers five [5] books covering five [5] phases, 26 processes and four [4] functions   o Stratgey (264), Design (334), Transition (262), Operation (262), Continual Improvement (220)   o This means 35 topics, which I admit cannot possibly be covered appropriately in just 2 to 3 days.   o This means some topics had to be left out.   o If I trust my calculator, that’s 679 pages for the previous scheme vs. 1342 pages for the current scheme to cover. That’s twice as much material. Here are some examples of complaints: Foundation level and the Manager Bridge Level Many people complain that the Manager Bridge is a much better Foundation course than the Foundation course itself. Look, the syllabus for the Manager’s Bridge course requires 30 hours of contact time while the Foundation syllabus requires 18 hours of contact time. Neither course covers all processes and all functions. They are different courses. The target audience and the intended results are vastly different. The Manager’s Bridge is aimed at people who already possess their IT Service Manager certification. The Foundation is aimed at anyone new to the framework. About the Intermediate Levels There is a lot of stuff crammed in a short time. The Lifecycle courses require 21 hours of contact time while the Capabilities courses require 30 hours of contact time. Show up to class prepared. Being prepared makes your learning experience as well as those of your fellow students so much easier and so much more interesting. It also makes it that much more interesting for your instructor as well. The Lifecycle syllabuses/syllabi «strongly recommends» 21 hours of pre-course reading to be done “prior” to getting to class. Look at the syllabus, all of the sections to read have been identified for you. By the way, the capabilities syllabuses/syllabi recommend 12 hours of pre-reading time. About the Accredited Training Organizations (ATO) The syllabus is only a guide providing a list of the material to cover. Each ATO is free to present the material in the format and order they wish as long at they cover the entire syllabus. By the way, it is also up to the ATO to decide which diagrams to use or not. The ATO must meet their EI’s strict requirements regarding the organizational processes, the course material, the instructors, and the instructor notes. For intermediate level courses, instructors must have a minimum number of years of experience and hold both the ITIL® Expert certification and the certification for the course they are teaching. Of course, there are organizations offering online (computer-based) courses. The EI do have specific evaluation criteria for theses types of courses as well. Becoming an (ITIL®) Expert In order to be an expert in any field or discipline, one must put in effort and time; what people refer to at «sweat equity» or the «heavy lifting». One does not become an expert by attending an introductory class on a particular topic. In the case of ITIL®, read the books! Read the books! Read the books! Discuss the topics with others, make them you own, identify where they are in your organization, read blogs and whitepapers. You should attend a set of courses covering the entire spectrum of the framework. Look to the syllabuses/syllabi for details of what is covered in each course. About the exams Finally, the examiners do not go out of their way to «trick» people with a «nasty» examination scheme. There are no «trick» questions. There are no «trick» answers. There are no situations where the difference between the best answer and the second best answer is only one word or a misplaced comma. If you firmly believe that you can do a better job at writing exam scenarios, questions, answers and relevant rationales, please contact APMG and apply to become an examiner. Creating exam questions is not as easy as it seems. About statistics If you are looking for the number of people that have achieved a particular qualification, for example, the number of people who followed the Manager Bridge route versus the ITIL® V3 route to become and ITIL® Expert please contact your Examining Institute and/or APMG.   2010-07-19T15:05:54+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/personal_rant_about_escalation/ http://blogs.pinkelephant.com/index.php?/itilv3/personal_rant_about_escalation/#When:19:21:05Z I have been working in the IT industry since 1984. I have seen my share of technologies; both software and hardware come and go. I started my IT career answering the phone as part of a group called simply «the desk». Whenever we needed specialized assistance, we would first consult with someone in a specialist group and if we could not resolve the issue together, I would simply «transfer» the issue record. In those days, and in that company, it was on a paper form. As I moved from company to company, I noticed the term «transfer» was used when specialized assistance was required. We rarely escalated anything to Management but we did keep them in the loop. Management became involved (i.e. escalated to) only is someone was uncooperative or if we needed someone to sign-off on an unexpected expense. It was not until I became aware of ITIL® that I became familiar with its two types of escalation, functional and hierarchical (or hierarchic). There is nothing word with using the term escalation. It is only my personal preference not to use it. What’s the difference? Conceptually there is none. However, it causes all sorts of headaches. Functional escalation is too often interpreted to mean asking someone more important that the previous level, which is not the case. Functional escalation means that someone with skills and knowledge that are more specialized needs to be involved. The analogy I use is travelling. Let us assume you are going on a cruise vacation. 1. You use a cab to get to the airport 2. You transfer to an airplane 3. After you land, you transfer to a bus to get to the dock 4. You then transfer to a ship for your cruise vacation You used specialized modes of transportation to get to your destination. You transferred from one to another. You were not escalated to an airplane, bus, or ship. So what’s the point? The point is this. When you are designing processes and you come to a decision point regarding functional escalation, make sure that people do not think that functional escalation means to someone better or more important that the previous level. Functional escalation is about transferring the «record» (a.k.a. «ticket») which could be an event, an incident, a problem, a request, or even a change to someone with skills and knowledge that are more specialized. From a personal experience, I had much fewer issues with the various levels of support when I worked in an environment that used «transfer» instead of functional escalation. Final thought Since ITIL® uses functional escalation, use functional escalation. The purpose of the above is to help you clarify the difference between functional and hierarchical escalation. By the way, you can use the above example free of charge to explain the concept of functional escalation. 2010-07-05T19:21:05+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/why_the_confusion/ http://blogs.pinkelephant.com/index.php?/itilv3/why_the_confusion/#When:18:43:07Z I noticed recently on various IT-related blogs and discussion threads that some people seem to have difficulty differentiating between the following three items Change Management Release Management Project Management Here is a bit of advice, go to the literature first. There is plenty of it. First, Change and Release Management are usually terms used within IT, specifically, ITIL®, ISO/IEC 20000®, COBIT®, and MOF®. Second, Project Management, although used by IT personnel, is a generic business term. The Project Management Institute (PMI®)(1)  and PRINCE2® (Project In Controlled Environment)(2)  are used throughout the world by organizations of all types and sizes for the execution of their projects. A project does not necessarily include an IT component while Change and Release Management are processes used by IT to manage efficiently and effectively changes and releases. There are situations where a Request For Change (RFC) may require a Business Case to initiate a project. There are other situations where a project team will submit RFCs to IT to handle various IT elements. Here are the «text book» definitions for Change, Release, and Project Management. The ITIL V3 Service Transition book(3)  defines Change Management as 4.2.1 Purpose, goals and objectives The purpose of the Change Management process is to ensure that: • Standardized methods and procedures are used for efficient and prompt handling of all changes • All changes to service assets and configuration items are recorded in the Configuration Management System • Overall business risk is optimized. The objective of the Change Management process is to ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. The ITIL V3 Service Transition book(2)  defines Release Management as 4.4 Release and Deployment Management Release and Deployment Management aims to build, test, and deliver the capability to provide the services specified by Service Design and that will accomplish the stakeholders’ requirements and deliver the intended objectives. 4.4.1 Purpose, goal and objective The goal of Release and Deployment Management is to deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations. 4.4.2 Scope The scope of Release and Deployment Management includes the processes, systems, and functions to package, build, test and deploy a release into production and establish the service specified in the Service Design package before final handover to service operations. Project Management PRINCE2® defines project management as «The planning, delegating, monitoring, and control of all aspects of the project, and the motivation of those involved, to achieve the project objectives within the expected performance targets for time, cost, quality, scope, benefits, and risks» Furthermore, PRINCE2 define a project as «“A temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case» Summary: The most significant difference is that a project team is temporary in nature and that people will return to their regular «job» after the completion of the project. Meanwhile a process is «permanent» in nature and is designed to ensure that different people across the organization execute a set of activities in a consistent manner. By the way, Project Management includes processes while processes do not include projects as part of their activities. Note to all IT folks; please remember that no matter what you use, change, release or project management, that what we do in IT is first and foremost about the business, not about IT. One final thought - Stop using the «Why make something simple when you can make it complicated approach». It will make your job easier. (1) http://www.pmi.org (2) http://www.prince-officialsite.com (3), (4), & (5) © Crown copyright 2009. Reproduced under license from OGC 2010-06-21T18:43:07+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/itil_v3_and_the_fifa_world_cup_2010/ http://blogs.pinkelephant.com/index.php?/itilv3/itil_v3_and_the_fifa_world_cup_2010/#When:13:40:45Z During the Beijing Olympic games in 2008, I mapped various events to processes and activities found in ITIL v3. Today, the FIFA World Cup 2010 «The Beautiful Game» kicks off. Instead of the processes, I will attempt to map (jokingly) the five phases of ITIL v3 to football) I am talking of the real football game. Strategy phase: For countries that are long shots to win it; play fair, do not complain too much when you lose and do the best you can. For countries that are among the favorites to win, unfortunately only one will win it all. I am hoping there is no controversy Design phase Service catalog = merchandising / souvenir catalog SLA = fans need to promise not to turn to hooliganisms and rioting OLA = referees need to be on the same page Availability / capacity and ITSCM = ticket scalpers Information Security = don’t lose your wallet Supplier management = don’t buy from counterfeit merchandise Service Transition Change = switch allegiance when your team is eliminated Configuration management = it is easy to identify fans Release management = party responsibly Service validation and testing = be patient and remember to thank the people of the host country Evaluation = appreciate the tournament and the games Knowledge management = nothing to say here, the fans of the game know, period Service Operation Incident management = players should not fake injury Problem management = the same players should not always fake injury Event management = GOOOOOOOOOOAAAAAAAAAALLLLLLLLLLL! Access management = no ticket, watch the game at a local refreshment establishment Request management = more refreshments, please! Continual Service Improvement Hey Canada is in 63rd place out of 207 nations – watch out world, here comes Canada – don’t worry, Canada (and I am Canadian) has a very (and I mean very) slow-paced but methodical long range improvement plan. Little baby steps. Little babay steps. At the improvement rate we are going, we’ll be there in the 22nd century… Teams I have to cheer for (not that I am not cheering for the other ones) N.B. The listing is not necessarily in order Italia - my 2 little nieces (ages 5 and 6) are Italian France - French ancestry Portugal - brownie points with the owner of Pink Elephant England - brownie points with the other owner of Pink Elephant Mexico - can not betray colleagues Brazil - can not betray colleagues South Africa - can not betray colleagues USA - can not betray colleagues Uruguay - can not betray colleagues Denmark - can not betray colleagues Netherlands - can not betray colleagues Australia - must support friends Ivory Coast - must support friend Ghana - must support friend New Zealand - must support friend Algeria - must support friend Enjoy the tournament 2010-06-11T13:40:45+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/about_service_archetypes/ http://blogs.pinkelephant.com/index.php?/itilv3/about_service_archetypes/#When:12:22:34Z I was recently part of an email conversation regarding the concept of Service Archetypes. Someone wanted concrete, real life examples on how service archetypes are used by IT Organizations when they are developing a Service Catalog. In order not to offend anyone and to make it simple, I have consolidated the answers from the various respondent under the name « Response » and the person asking for clarification under the name « Inquiry ». Before I start, I would like to extend a big thank you to all my colleagues who were part of this discussion. Inquiry Do you have examples on what service types fits into the lines of service column? I am referring to Figure 4.4 in the service Strategy book. I know the Lines of service are a high-level categorization of services in the Catalog. I know that Email, IM, VOIP, and Video falls under Communication. I would appreciate specific examples on the following Lines of Service. Specifically, I am looking for which services fit into the following categories of lines if service. Managed Services: o Remedial Services o Custodial Services o Administrative services o Evaluation Services o Transformational Services o Creative services o Communication Services Response One of the challenges that I have had with the archetype representation in the Service Strategy book is that the authors did not provide any definition of the archetypes. The way I have handled this in the past is to suggest that this description is one mechanism for describing broad service categories, which facilitates mapping the business asset with the appropriate service. I think you can use your imagination (unfortunately that is all we have to go on) to suggest that a managed service might be the network, a remedial service might be backup and recovery, custodial services could be event management/monitoring, administrative services might be service costing and charge back and so forth. Inquiry Thank you but it still does not provide real life examples. Response Building on I answered would to deemphasize the exact names on this slide (unless they are on an exam question) and focus more on coming up with categories you are more familiar with. For example: o End User Services o Telephony Services o Data Center Services o Office Productivity Services o Application Development Services o Project Management Services o Collaboration Services Business Services: o Power Generation o Online Banking o Refining o Distribution o Warehousing Inquiry This is starting to make sense but still I am not too sure this really provides me with real life examples. Do you have more examples? Response The key is the concept rather than the actual names you find in the literature. Here are some thoughts: Managed Services: o Hosting o Network o Office Automation Administrative services o Accounts Receivable, Accounts payable (Financial Management) o CRM (Customer Relationship Management) o HR (Human Resource Management) Evaluation Services o Consulting o Business Analysis Transformational Services o Project Management Creative services Communication Services o Instant Messaging o E-mail Inquiry Thanks a lot for the information you have provided. This is extremely helpful. One last question on archetypes – can you provide an example of two services and their archetypes and then map them to the Service Assets? In addition, there is confusion on my part on how to define archetypes and their purpose. I am sorry the Service Strategy Book is too vague to understand. o Are these activities of the line of Service, or capabilities of the line of service or what is the relationship the archetypes have to the line of service? o In addition, are the archetypes IT archetypes or the business archetypes? o How do I accurately describe an archetype? Response Hold on, Hold on, you mention one question, yet you ask three! Let me attempt to answer all questions below. The Glossary in the Service Strategy book defines Line of service as a Core Service or Supporting Service that has multiple Service Level Packages. A Line of Service is managed by a Product Manager and each Service Level Package is designed to support a particular market segment. Figure 4.4 in the Service Strategy book uses Lines of service as the identifier or “Name” of the service. In the diagram they are: Name of the service What the service can do for the customer o Access/Rental Service   Lease, License, Provide o Managed Service   Manage, Operate, Maintain o Remedial Service   Recover, Resolve, Repair o Custodial Service   Store, Protect, Monitor o Administrative Service   Process, Fulfill, Record o Evaluation Service   Analyze, Assess, Audit o Transformational Service   Modify, Transform, Transport o Creative Service   Design, Develop, Engineer o Communication Service   Connect, Integrate Of course, the above list is not complete. 1. The name of the service and line of service are synonymous 2. The archetypes are the “sub-services” or activities provided by the service Let me use a non-IT real life example – Plumber Remedial Service a) Unclog drains b) Repair faucets Transformational Service a) Replace existing toilet, sinks, baths, or faucets b) Install new toilet, sinks, baths, (where you had none before) Inquiry That does help and maps it to terms I and other ordinary people use. 2010-05-31T12:22:34+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/official_number_of_processes_in_itil_v3/ http://blogs.pinkelephant.com/index.php?/itilv3/official_number_of_processes_in_itil_v3/#When:13:19:16Z Since the launch of ITIL, there are has been differences of opinion regarding the number of processes in ITIL V3. I have contributed to this confusion by saying that there were 24 processes. The reason is that my colleagues who wrote the CSI book never intended for two topics to be referred to as processes. These topics are Service Measurement and Service Reporting. The original intent was for these topics to be sub-processes within each process. By the way, many organization have provided various lists with anywhere from 24 to 34 processes. Let me set the record straight (and eat some crow in the process – pun intended). I recently confirmed the actual number and names of the processes with Sharon Taylor who is the Chief Architect for ITIL v3. The official number from the Chief Architect for ITIL – Sharon Taylor is 26. Here is the official list per book with their appropriate name Service Strategy – 4 processes 1. Strategy Generation 2. Financial management 3. Demand management 4. Service Portfolio management Service Design – 7 processes 1. Service Catalog Management 2. Service Level Management 3. Availability Management 4. Capacity Management 5. It service Continuity Management 6. Information Security Management 7. Supplier Management Service Transition – 7 processes 1. Transition Planning and Support 2. Change Management 3. Service Asset and Configuration Management 4. Release and Deployment Management 5. Service Validation and Testing 6. Evaluation 7. Knowledge Management Service Operation – 5 processes 1. Event Management 2. Incident Management 3. Request Fulfillment 4. Problem Management 5. Access Management Continual service improvement – 3 processes 1. The 7 improvement process 2. Service Measurement 3. Service Reporting By the way, Sharon did confirm that Return on Investment for CSI is not a process TOTAL – 26 PROCESSES 2010-05-05T13:19:16+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/executives_partners_and_empowerment/ http://blogs.pinkelephant.com/index.php?/itilv3/executives_partners_and_empowerment/#When:14:46:03Z The executives are involved in many activities and have to play many roles. They cannot do everything by themselves and require employees to executive the myriad of activities required to run a smooth operation. In order to do this people must be empowered, have the appropriate level of authority especially when dealing with external partners. However, before we tackle this topic we need to look at all the players involved with an organization. Ownership It is understood that the ownership of the organization greatly influences the culture and practices of said organization. Let us use the most common types of ownership namely sole proprietor, private corporations, publicly traded organization, non-for profit organizations and all levels of government and agencies. What they all have in common? Someone is ultimately accountable for the actions and results of the organization. At this time, we are not looking at compliance or governance for we have to look first at the structure of an organization including its suppliers and partners. Partnerships Every organization has an organization structure and architecture. In addition to this, organizations rely on other organizations for products and services. A partner or a supplier might be an internal group or a separate legal entity. Internal partners and suppliers can be a different department within an organization located on the same floor or in the same building or it can be another office (including other retail locations), a warehouse, a manufacturing facility, or even a franchise. Looking at external partners, we have four basic categories such as strategic, tactical, operational and commodity suppliers. A strategic partnership is a signification relationship that involves senior managers sharing confidential strategic information to facilitate long-term plans. These relationships would normally be managed by senior management and/or executives A tactical partnership is a relationship that involves significant commercial activity and business interaction. These relationships would normally be managed by middle management. An operational partnership is a relationship that involves suppliers of operational products or services. These relationships would normally be managed by operational managers. A commodity supplier provides low-value and/or readily available products and services, which could be alternatively sourced relatively easily (e.g. office supplies) Vendor or Sourcing Strategy The ownership or executives of an organization must decide, define, document, and communicate the partnership strategy to the people involved with the selected or potential partners. Outsourcing is the moving of a value-creating activity that was performed inside the organization to outside the organization where it is performed by another company. A service strategy should enhance an organization’s special strengths and core competencies. Each component should reinforce the other. Change any one and you have a different model. In its most basic form, a sourcing strategy looks at the following - What to source - Sourcing structure - Multi-vendor sourcing - Relationships - Sourcing governance - Roles and responsibilities So what often happens? People have their hands tied on both sides of the partnerships because of miscommunication, poorly defined roles and responsibility, lack of delegated authority, lack of empowerment, poorly worded contracts, missing clauses because the customer did not know exactly what they wanted and made too many assumptions. Additionally, both sides may use the contract as a club to bash the other when something goes awry or they may hide behind it as a shield to defend their position often using phrases like “we did what’s in the contract.” Where is all this going? To run a smooth operation the personnel on both sides of the relationship must be empowered, and have the appropriate level of authority. However, what is authority? The Merriam Webster online dictionary (http://www.merriam-webster.com/dictionary) defines authority and the following terms as [The] power to influence or command thought, opinion, or behavior [The] freedom granted by one in authority (right) Synonyms: Influence, power This leads us to empowerment, which is defined as follows [Giving] official authority or legal power to act on one’s behalf Being empowered by a higher level of manager to have the authority to make decisions on their behalf is one thing. Because with authority, comes accountability, which is defined as follows [The] obligation or willingness to accept responsibility or to account for one’s actions The delegation of authority must be communicated and explained to the personnel. Providing clarity of roles should help prevent resistance. Additionally, it should contribute to fewer issues between partners or quicker, more effective and efficient resolution of issues should any arise. A few final notes Yes, there are organizations where the above ranges from “this works very well” all the way to “are you kidding?” Yes, there are politics and favoritism in any organization. No, organizations do not always communicate who is in charge Yes, senior managers and executives are often reluctant to relinquish power or to delegate authority. Yes, people will make decisions and beg for forgiveness after the fact instead of asking for permission in the first place. Yes, people are often reluctant to accept authority. Yes, people are often critical of any authority – these people are usually the naysayers about anything and everything anyway. Yes, people will protect their area of influence and refuse to acknowledge someone’s newly received authority. Why is it so difficult to do any of the above? One it is human nature, and two, it is usually embedded in the culture of the organization. This is why so many initiatives to improve “how” an organization does things often fail. It is called resistance to change and it is present at all levels. Without real and accepted empowerment and delegation of authority, organizations will have a hard time changing the way they do things. So, before embarking n any process or service improvement initiate, take a good hard look at how the organization operates because changing the culture of the organization will be the arduous and longest component of your initiative. 2010-04-30T14:46:03+00:00 http://blogs.pinkelephant.com/index.php?/itilv3/executives_and_public_relations/ http://blogs.pinkelephant.com/index.php?/itilv3/executives_and_public_relations/#When:14:26:44Z The executives are involved in many activities and have to play many roles. They cannot do everything by themselves and require employees to executive the myriad of activities required to run a smooth operation. Let us set aside the sarcastic comments and innuendoes about a particular individual, organization, or situation. Let us instead concentrate on the positive shall we. In my previous blog entry, I started to look at the concepts of market and option spaces. [NOTE: I was away on business for a week and I had to deal with a death in the family, so please accept my apologies for not posting entries over the last few weeks.] I wish to explore three aspects. They are Public Relations, Ownership, and Accountability. I will concentrate in this entry on Public Relations. PUBLIC RELATIONS Handling public relations is about being the face and voice of the organization. Of course, there are people who specialize in these activities ensuring the protection of the image, the brand, the appearance of the person, accuracy of details and preparing for the meeting, event appearance, etc. Corporate representation Of course, executives must represent the organization to the public, customers, partners, legislators, and other external people. However, executive should not forget of one the most crucial audiences, the organization. A lack of internal communication often leads to perception issues, which in turn can lead to real issues. The issues include contradicting orders, rumors, gossips, overlapping or duplicate projects, morale issues, etc. Yes, I am generalizing here but one of the most important components of most frameworks, methodologies, and even common sense is communication. Walk to the self-help section of a bookstore and look at the various books about communication. This topic must be quite important and many people must think that we need help in how to communicate. However, the point I wan t to make is about executive being visible inside the organization, communicating on a frequent basis and genuinely care about what goes on in the organization. In my personal observations as a consultant over the years I noticed better employee morale and less resistance to change when the executives were visible and approachable, those” who walk the talk” so to speak. Speaking engagements Whenever an organization embarks on a major project, be it restructuring, new product launch, or deciding to use best practices, the most successful organizations were those whose executives were visible on a regular basis and spoke to the people in the organization as the most important people in the world. I have sadly seen or heard about executives announcing to the organization something like “We are doing ITIL.” There were no further explanations as they immediately retreated to their ivory tower. The internal speaking engagement must be approached by executives, as they would address prospective investors or large customers. Major accounts If the organization is not considered a major account, for the executives, I don’t know what is. I fully understand that impressing prospective investors and customers is very important and does require projecting an image of quality involving luxury items. The potential returns can compensate many times the use of those luxury items to impress people. However, why treat you employees differently? Provide them with the opportunity to acquire the knowledge, skills, best practices, culture, and tools needed to succeed. I know that times are tough and that money is tight. In my humble opinion, executives should do what it takes to win over their biggest account, their employees 2010-04-16T14:26:44+00:00