ITSM Transformations Are Really People Change Projects

When it comes down to it you can buy a feature rich ITSM tool and even great looking documentation but you cannot buy the hearts and minds of your people.

The culture of your organization has a major impact on your ability to deploy IT Service Management processes within your organization

Join Chris and I as we discuss the difference between behaviour and cultural change and why understanding your cultural environment is a critical success factor for your ITSM project.

Culture & ITSM Transformation Projects - Practitioner Radio Episode 21 from ServiceSphere on Vimeo

Show Notes:

• Shout Out to Cary King
• Pink’s Opening Session – State Secret
• Pink12 Pinky “Crooner Pinker”
• Troy’s Pink12 Session - 5 Tips For Cementing Organizational Change
• ITSM Is really about People Change Projects
• HBR Article: Fair Process Managing in the Knowledge Economy
• Most culture literature is found in general business literature
• What Is Culture? (Human Nature, Group, Tone At the Top, Personality)
• Culture (Enterprise, Group, Individual)
• Dealing with culture is not a 1 size fits all approach
• Culture is different between Dev. and Ops groups
• Deal and Bolman Cultural Model – Reframing Organizations
• The Goal is to Change Behavior Not Culture!
• Professor John Kotter – Change Process
• The Kotter Model and ITSM Quick Wins
• ITSM Transformation and The Kubler-Ross Grief Model
• De Bono’s 6 Hats Thinking Systems
• Mountains, Mole Hills & Dead Buffaloes

Troy’s Thunderbolt Tip: Remember that culture and behavior are two different things. Behavior can be adjusted in the short term through careful management. Culture will only change after time has passed and the transformation was proven successful. Focus on short term actions on changing behavior - with an goal of long term culture impact.
Troy’s and Chris’s Thought’s What Are Yours?

“Change from the top down happens at the will and whim of those below.” ~Peter Block’s,

To subscribe to Pink’s Podcasts on iTunes

EXTRA EXTRA EXTRA SPECIAL:

SEE CHRIS AND TROY RECORD LIVE AT PINK12!!!
http://www.pinkelephant.com/Pink12/

Wrong Turns Are Often Based On A Case Of Mistaken Identity or Direction

So you have been asked to setup and establish an IT Service Management improvement program!

Congratulations, you have been in-trusted with a key element of your organization’s plan to improve service delivery, service availability, and customer satisfaction.

Now the key question is: How do you get started on this major task and what critical knowledge do you need to consider from a People, Process, Product and Partner perspective?

At Pink Elephant our decades of experience teaches us that IT Service Management programs are really people change initiatives, but that they are frequently mistaken for an ITSM tool implementation or process documentation project.

Certainly these are both important elements and even critical for overall project success, but in the end neither the process document or the wonderful new ITSM tool you just purchased produce results by themselves.

Because of this case of mistaken identity many frustrated IT leaders have invested significant resources, time and money and received very little benefit or return for their efforts. To avoid becoming an unfortunate statistic it is critical that you start your journey with a good understanding of the goal you are being asked to achieve, and to make sure others especially your manager does as well. 

Join Chris and I as we explore the practical aspects of what it truly takes to adopt ITSM practices and how documenting versus deploying processes are two very different objectives.

Process Adoption - PRACTITIONER RADIO EPISODE 20 by ITSMWeekly

Show Notes:

• Blog Article: Business Operating Model Graphic
• Blog Article: Documenting vs. Deploying ITSM Processes
• SLA’s for ITSM
• RFP, RFI, the insanity for service management
• What does it mean to DEPLOY a process vs Document it (4 MONTHS)
• Blog Article: The Three Perceptions of Implementation
• Why does Pink Elephant give AWAY so much information for FREE on their blogs?
• Levels of “Getting IT in” 1-3 (What do you REALLY want from your consultant?)
• Documenting a process itself, gets you a binder on a shelf.
• People, Process, Product, Partner, the 4 Ps of ITSM
• ITSM Extreme Makeover
• Blog Article: 4 Project Work Streams coming together
• Blog Article: When ITIL Projects collide
• Velocity is different than agility
• Blog Article: Why Bother with baseline assessments?
• Memories are short, if it’s NOT written down it’s not real.
• How do you resource an ITSM project?
• “Not invented here” will kill your process deployments and documents
• Change Agents and enemies, the process sweat equity equation
• Blog Article: The Art Of Building an ITSM Process Design Team

Example Transformation Time Line Graphic

Troy’s Thunder Bolt Tip of The Day:

When considering ITSM process adoption carefully consider the amount of change your organization can absorb at one time. Most organizations can handle no more than 2-3 parallel ITIL process projects as a maximum

Troy’s & Chris’s Thoughts What Are Yours?

“We all want progress, but if you’re on the wrong road, progress means doing an about-turn and walking back to the right road; in that case, the man who turns back soonest is the most progressive.” C. S. Lewis

To subscribe to Pink’s Podcasts on iTunes

I am sure several of you receive the daily LInkedIn Today news of Interest articles. I typically scan them to look for articles that apply to our practice and areas of interest related to organizational transformation. Today’s list or articles was particularly powerful - and a bit disturbing!

I highly recommend that you read the three Business Insight articles I have listed below, though you may not appreciate their edgy titles. Each article deals with how the workforce in the west is shifting from a generalist to a specialist mindset and how the Asian market and workforce has already evolved as the de-facto manufacturing engine of the world.

The articles make provocative statements such as:

1. We have seen the end of the industrial revolution in North America (I would add the West).

2. We no longer have the Manufacturing ECO system and supply chain to sustain many of the middle class jobs our economy has relied on.

3. Generation Ys are settling for what they can get in the way of jobs.

The application of this knowledge is that the Western economy and individual’s jobs will depend more and more on the specialty knowledge and skills they can acquire that will set them apart and make them unique. Also a growing understanding and belief that the status quo of how things are done today is no longer acceptable due to the waste that pervades our Western working practices. Process improvement and the application of Lean principles will help Western companies become more efficient in order to compete with growing global market pressures.

In my personal view, ITSM and other Enterprise Governance type knowledge, skills and certifications play an important role in creating individual and organizational differentiation. This is the premise of the article I wrote last year called: The Rising Wave Of Enterprise IT Certifications - Surf’s Up—Grab Your Board:

As you will read in that article, I believe the rising interest in enterprise IT certifications stems in part from these market shifts. In the West but also in the East individuals are looking for knowledge and their substantiating certifications to give them unique skills and value to help them compete in a global market.

Understanding these trends can help organizations and individuals make the necessary shifts in Attitude, Behaviour and Culture they require to stay competitive and employed.

Avoiding or ignoring the reality of these economic shifts can only be to our peril.

The specific business Insider articles that promted this post are:

Why Apple Makes iPhones In China And Why The US Is Screwed

If You’re An Average Worker, You’re Going Straight To The Bottom

13 Ways The Recession Has Changed How Millennials View Work

Troy’s Thoughts What Are Yours?

Everyone thinks of changing the world, but no one thinks of changing himself.  ~Leo Nikolaevich Tolstoy

IT Service Management Is Not A Closed Loop Value System

To Stay Fresh & Relevant We Must Capture & Manage New Demand

Where Have We Been:

Based on Pink’s research and consulting experience most IT Service Management (ITSM) improvement projects over the last 5 years have focused on the ITIL Service Transition and Service Operations processes. This is not surprising in many respects in that while with ITIL version 3 provided us with a full service lifecycle most organizations are still focused by necessity on improving the basics of service availability.

From the perspective of business risk this is a logical starting place since there is an intrinsic need to stabilize the current environment before an organization has the capacity and available resources to tackle the more proactive aspects of Service Strategy and Design.

However, eventually despite the challenges of economic conditions and constant changes to sourcing strategies IT service organizations need to consider and address the end-to-end lifecycle of demand & supply.

Not that we are not seeing CSI improvement activities in upstream aspects of the value system. Many organizations have current improvement initiatives targeting pre-production / development capability areas such as Project Management, Application Development, Architecture, etc.. But these are largely being run as independent improvement projects which are not linked or prioritized by an overall IT Operating Model strategy. 

This end-to-end view of the full demand / supply lifecycle has been the recent focus of several of my practitioner radio episodes.

• Practitioner Radio Episode 19 - The Strategic Role of An IT Operating Model
• Practitioner Radio Episode 15 - Business Relationship Management
• Practitioner Radio Episode 12 - Demand Management

Where Do We Need To Be:

Within the larger context of the overall demand / supply value system there are major capability areas which play a critical and interdependent part in the customer value delivery story. At a high-level these capability areas can be viewed as Demand Capture, Plan, Build, Run (D,P,B,R) with a overarching goal of Continual Service Improvement.

Sound familiar? Well it should since this is the basic construct of any value generation system or supply chain and it just so happens to correspond to the ITIL Service Lifecycle of (Strategy, Design, Transition, Operations & CSI). In fact when speaking with most IT Executives about ITSM or ITIL I start the discussion at this level before I ever introduce the concept of best practice process frameworks. ITIL in this context is simply one of many useful reference frameworks which support the overall D,P,B,R lifecycle. I specifically wrote “one of many” in that ITIL does not cover everything which goes on in the full lifecycle but does a decent job of covering many of the major aspects of each stage. Other reference models cover application development, architecture, project management, security, etc..

An interesting observation is that we are pre-conditioned in many ways to not think of Demand as the first step in the value chain. For example while I referenced the “Demand and Supply Lifecycle” above this is not the typical order in which we are used to hearing these words.  For most readers the term “Supply & Demand” will be more familiar. However, this sequence is not describing a value system process but rather refers to an economic model that describes how the available supply and cost of goods & services is driven by market demand.

Demand Management:

Once you have begun to tame the twin tigers of production stability & service availability it is time to focus on new value creation. My personal recommendation is that one of the first CSI focus areas should be the front office processes that deal with capturing demand. 

Demand Management has at a high level three primary tasks:

1. Predict demand based on historical usage
2. Influence demand based on incentives & compelling service offerings
3. Receive/Capture demand for new & existing services

The third task requires the creation of clear channels and roles for understanding what our customers require and want versus telling them what we think they need. While this sounds obvious it is not in my experience common practice.

For example: If it is common practice then why is this one of the most frequently stated complaints from the business; “IT Does Not Understand Business Priorities”?

This is problematic in that understanding business demand as it relates to investment priorities and service requirements is critical for effective service management. Consider the following:

1. Not understanding Demand causes IT to deliver services that do not meet business needs
2. Having limited to no input from Demand into Plan is a recipe for not getting the service design specifications correct
3. Not understanding the Plan or design specifications causes confusion in the identification of acceptance criteria for the build, testing and promotion to production tasks
4. Having non-aligned, poorly designed, insufficiently tested and ill coordinated service elements being introduced to the Run / Production environment delivers service outcomes that are unreliable and do not meet business needs

Lean Principles: As an additional consideration to this logic tree add the Lean principle of Pull vs. Push. This principle declares that an efficient value system should only create product inventory or invest in services, which the customer asks for. (After all they are the ones paying the bills)

In essence customer demand (pull) provides the primary trigger for value creation. The opposite of a pull model is an organization, which decides based on its own best assumptions what services the customer will likely want (push).

In this context the (Pull) based value system is working on stuff the customer wants versus building it and hoping they will come (Push). Unfortunately “Build It And They Will Come” only usually works very well in the Hollywood Movie “Field Of Dreams”   

The Three Doors Of Demand

With the recent release of the 2011 edition of ITIL we have seen another step forward in improvement of the demand / supply life cycle. This improvement is represented by the elevation of the Business Relationship Management process and function to Service Strategy. In my view this change places the BRM process and function at the right level to enable it to perform as the strategic channel for receiving new business requirements into Service Portfolio & Demand Management. 

To take this discussion further there are in fact three primary channels or doors for receiving or capturing customer demand.

Business Relationship Management: provides the strategic and interactive aspect of receiving strategic demand and supports future state planning. It also supports Service Level Management in the definition and reporting of service level agreements.

The Service Catalog: Provides a portal for automated self service, Demand Management analytics and front ends the Request Fulfillment process in support of order provisioning.

The Service Desk: Provides the human interface for Request Fulfillment for those customers who prefer not to interact with an automated Service Catalog User Interface (UI)

These 3 doors of Demand are the customer facing channels into the (D,P,B,R) lifecycle. Their existence and relative maturity have a major impact on the customer experience, satisfaction and dependent value generation processes. They represent the front office of an IT Service Provider.

When planning an ITSM roadmap consider that improving the front office can have a significant impact on customer satisfaction providing you have already addressed the production availability issues.

Troy’s Thoughts What Are Yours?

”Spend a lot of time talking to customers face to face. You’d be amazed how many companies don’t listen to their customers.”
Ross Perot

Re-Discovering The Importance Of the IT Supply Chain & Increasing Speed To Value

As a trusted service provider IT is expected to receive business demand and efficiently translate that demand into outcomes their customer’s want. However, for most IT shops there is nothing remotely efficient about this critical task, in fact quiet the contrary!

From this perspective, the mapping and improvement of the Enterprise IT operating model and its underpinning management processes which flow through both the development and operations groups must be a key focal point of Continual Service Improvement (CSI). 

In this podcast Chris and I look at the critical success factors and management of change tasks related to people, process & partners caused by a technology/silo focused culture and how ITSM principles and structures enable enterprise value flow.

Show Notes:

• Quality systems Podcast
• The Strategic Role of an IT Operating Model Article
• The CIO as a Supply Chain Manager
• Theory of Constraints and CSI
• MIT Sloan Enterprise Architecture Book
• MIT Operating Model
• “The normal system is the abnormal system!”
• “Agility is not the same as velocity”
• “WE ARE IN THE BUSINESS OF DEMAND AND SUPPLY”
• Demand Management Podcast
• Service Catalog and Service Desk Podcast
• ABC of ICT Cards
• “What starts as a cost can eventually become a strategy”
• The high level controls within the movie “The Matrix”
• Tribal Culture vs. National Culture…things are going to get sticky!
• Who is it Good For?
• “Status Quo is not scalable”
• What does new leadership do for a business?  Who are they actually serving?
• “The Technology Tower Mentality”
• In the end if you have an end-to-end view before you can make a decision that’s for the good of the company

Example: Level 1 Operating Model Diagram:

 

More Resources:

• IT Operating Model Case Study: How Cisco IT Improved Development Processes with a New Operating Model
• Business Modelling:
• Business Reference Models:
• Business Model Innovations in China: From a Value Network Perspective

Troy’s Thunderbolt Tip Of The Day:

Every complex value system has a natural flow. In order to understand that flow you need to re-discover the end to end supply chain or in other words re-draw the picture on the puzzle box to understand how all the pieces fit together.

Troy’s & Chris’s Thoughts What Are Yours?

“In the absence of clearly-defined goals, we become strangely loyal to performing daily trivia until ultimately we become enslaved by it.”—Robert Heinlein

Quality Management Systems and Process Frameworks Live In A Symbiotic Relationship

Symbioses - interaction between two different organisms living in close physical association, typically to the advantage of both.

Join Chris and I look at the practical application of Theory Of Constraints, Lean Thinking and Six Sigma as the three sisters for Continual Service Improvement.

Show Notes:

• CA World Conference
• Quality Systems and Process Frameworks
• Deming
• TQM
• EFQM
• Baldridge
• LEAN
• Six Sigma
• Theory of Constraints
• Troy’s session at Pink12 & Velocity: the book for the session
• TapRoot
• Pareto Analysis
• Value is the quality that people are willing to pay for
• Theory of Constraints and I Love Lucy
• Chris learns about bottlenecks
• TOC and all Quality systems are THINKING PROCESSES
• SLA’s and TOC
• Muda – Lean Japanese Concept
• Variation Cost Money

Troy’s Thunder Bolt Tip of The Day:

Remember that Quality Systems such as Lean, TOC and Six Sigma are more than beneficial to process improvement. They provide the drive and direction to keep processes fresh, relevant an most important Fit for purpose.

Troy’s & Chris’s Thoughts What Are Yours?

“A man gazing on the stars is proverbially at the mercy of the puddles in the road.” ~Alexander Smith

To subscribe to Pink’s Podcasts on iTunes

Technology Versus Service Management - A Tale Of Two Cities With Complementary But Different Goals

By necessity we design and model services based on systemic relationships. We see the evidence of this fact when we enter an IT Architect’s office space by the presence of complex UML diagrams on their wall depicting the end to end services. However, the moment we move these services to production we manage each component of the overall design as if they live in mythical isolation. 

Gaining the emotional agreement of the various groups within an IT organization that a common management system is a base requirement for optimizing the IT Demand/ Chain is often the first and most difficult tasks. IT Management frameworks such as ITIL, COBIT, CMMi, and TOGAF provide good practice descriptions. However, these frameworks only provide a definition of what can be achieved if they are introduced into a receptive environment. They do not in and of themselves create that environment!

Join Chris and I as we discuss the cultural paradigm shift that must occur before an organization is ready to adopt many of the best practices described by IT Service Management.

Show Notes:

• itSMF UK Conference 2011
• The incident, problem and change dance
• All the Practitioner Radio Shows
• Request fulfillment vs Demand Management
• Pink12 Conference
• Define Culture
• Rob England’s Tweets
• Culture jumping starts from moving from a tech culture to a service culture
• Cultural Roadmap for ITSM Adoption
• Systemic Thinking
• When DONT you need a CMDB or SLA?
• Until an organization wants to manage OUTCOMES a large part of ITIL is out of their grasp
• Stephen Mann’s Value Presentation on “Value” from itSMF UK 11 (PDF)
• Who is my customer? IT user, customer, business
• Lucy’s Advice Kiosk
• MIT Sloan Enterprise Architecture Strategy Book
• Chris’s mushroom trip to a shaman village
• Tribal Culture vs. Nation State Culture
• Preview of Theory of Constraints
• Remember your place in the system, but you NEED to understand your position in the bigger picture.
• What exactly is Troy’s job at Pink Elephant?

Troy’s Thunderbolt Tip of The Day: Remember certain aspects of IT Service Management require an IT organization to shift from Technology Management to Service Management. Until that occurs only certain processes will be in reach of your cultural adoption.

Troy’s & Chris’s Thoughts What Are Yours?

Quality in a service or product is not what you put into it. It is what the client or customer gets out of it. ~Peter Drucker

To subscribe to Pink’s Podcasts on iTunes

Managing and Automating the Order / Fulfillment Process for IT Service Delivery

Providing clear insight into how services are requested and provisioned is a core competency of any Service Organization. This episode of Practitioner Radio looks at how to implement Request Fulfilment front ended by the Service Catalog and the Service Desk.

Join Chris and I and our special guest Martin Erb as we explore this practical subject and how to apply best practices.

Show Notes:

• Guest Martin Erb @servitect
• Request Fulfilment & Provisioning
• Request Fulfillment & Sears
• Amazon & Request Fulfillment
• There is an overall Process but also potentially 100’s for request flows
• Amazon is the modern Equivalent of the Sears Wish book Ordering Process
• ITIL v3 Is about Shopping
• Monitoring the status of Request Provisioning
• Service Awareness Gap
• Cloud (Automated Request Provisioning)
• SLAs and Requests (Expectation Level Management)
• Onboarding New Employees
• Defining Services and Request-able Items
• The App Store = Request Catalog
• Requests & Entitlement
• IT Is not the only Service Provider in the Business Eco System
• Cultural Anticipation of Speed
• Request Fulfillment Blog Article

Troy’s Thunder Bolt Tip of The Day:  Request Fulfilment is a process of many different workflows. There is an overall macro process. However its important to remember that each requestable item has its own mini approval and provisioning workflow

Troy’s, Chris’s & Martin’s Thoughts What Are Yours

Patience is the most necessary quality for business, many a man would rather you heard his story than grant his request. ~Lord Chesterfield

To subscribe to Pink’s Podcasts on iTunes

IT Shops have 3 front doors to handle demand: Business Relationship Management, Service Catalog and The Service Desk

With the ITIL 2011e release BRM has been elevated to stand on its own as the strategy process and role for establishing and managing business requirements and expectations.

Join Chris and I as we look at the evolution of the BRM role through the various versions of ITIL to its current placement as the customer engagement front door for Service Strategy and Portfolio Management.

Show Notes:

• Chance meeting with Gary Case!
• Every Practioner Radio gets copied, why is that?/li>
• Business Relationship Manager
• Supplier Management for ITIL Podcast
• Do you start by training a business person to learn IT or do you take an IT person and teach them to talk business?
• What types of KPI’s do you put around the job of Business Relationship Manager (the secret is in the sales department)
• Demand Management Podcast
• Service Owner vs. Account Manager vs. Business Relationship Manager
• The Evolving Service Organization Whitepaper

Troy’s Thunder Bolt Tip of The Day:  Every relationship can benefit from the wise counsel of a liaison, arbitrator or counselor. The Business Relationship Manager enables clear communication and collaboration between the business and IT.

Troy’s and Chris’s Thoughts What Are Yours?

“We’ve spent the last 30 years focusing on the T in IT, and we’ll spend the next 30 years focusing on the I.” ~Peter Drucker

To subscribe to Pink’s Podcasts on iTunes

All Data Is Not Equal In The Eyes of the Powers That Be!

Ever notice how some days seem to have themes? Well for me today’s theme is related to data management or more precisely the legislated data security, privacy, clearance and compliance requirements that apply to data management. I believe the readers of this article would agree that while the business unit is responsible for data accuracy the IT group and their integrated partners and suppliers are the caretakers and guardians of the digital life blood of any business, government or non-profit organization. 

What made this a theme for me today was the fact that three separate conversations caused me to think about the importance of business data and its relevance to IT Management responsibilities.

Conversation #1: The spark for this article came from a conversation I had with my fellow Pinker George Spalding. George and I were talking this morning about a webinar he is co-presenting with Axios. The subject of this particular webinar is very focused in respect to the implications of IT Management for the Health Care industry. George and I discussed his research into the security and privacy implications of online medical records and client data as it is being shared across state and federal boundaries. Legislation such as Health Insurance Portability and Accountability Act (HIPAA) and the HITECH Act required serious privacy requirements in system design and data management.

Conversation #2: Pink Elephant like many other companies today is exploring the benefits of Bring Your Own Device (BYOD) strategies when equipping our staff with automation. In the face of the growing consumerization of IT and the rampant growth of personal mobile computing platforms a “if you can’t beat them join and influence them” strategy makes a lot of sense. So with this practice in place several of us were tackling some of the finer points of policy related to making this work. Of course the challenge now becomes the reality of corporate data now being spread across devices that do not belong to the company. This was further enforced for me when I read the following baseline article later in the day “Undead Data Haunt the Enterprise” which talks about on-boarding and off-boarding new employees and being accountable for “Burning or Scrubbing” their personal devices when they leave. The reality is that the Network Perimeter is way beyond the corporate firewall’s. Whether we like it or not corporate and legislatively protected data is on on mobile devices, loaded into personal cloud storage services etc. The worst thing about this is that even though the business does not own this device they still have have legal obligation to keep the data safe and secure.

Conversation #3: The final conversation that promoted this article was a discussion I recently had with David Ratcliffe the President of Pink Elephant. We were discussing the dramatic evolution of personal storage. David remarked to me during our conversation that it was amazing that we can walk around with devices in our pocket with enough storage capacity to hold every byte of digital content we create during our working lifetime. That statement gave me serious pause.

With these three conversations in mind I invite you to consider the following observations:

1) Ignorance Is Not A Defensible Excuse

I often speak on IT Governance and as part of this subject matter I try to keep on top of a high level list of legislation that pertains to information systems which house sensitive business data. I refer to this list as the Hair Ball of legislation in that there is no integration and sometimes contradiction of the compliance requirements. As a sample but by no means comprehensive list consider the following

• Canadian Personal Information Protection Electronic Document Act (PIPEDA)
• US Patriot Act \ Homeland Security (Critical Infrastructure)
• Personal Health Information Protection Act (PHIPA)
• Health Insurance Portability and Accountability Act (HIPAA)
• SEC Rules 17a-3 & 17a-4 re: Securities Transaction Retention
• Gramm-Leach Bliley Act (GLBA) privacy of financial information
• Children’s Online Privacy Protection Act
• Clinger-Cohen Act (US Gov.)
• Federal Information Security Mgmt. Act (FISMA)
• Freedom of Information & Protection of Privacy (FOIPOP) Canadian BC Gov
• FDA Regulated IT Systems
• Freedom Of Information Act
• Family Education Rights & Privacy Act (FERPA) (Higher Education)
• Medical Information System Development (Medis-DC) (Japan)
• Authority for IT in the Public Administration (AIPA) (Italy)
• European Privacy Directive (Safe Harbor Framework)
• Sarbanes Oxley (SOX)

The challenge is that we face is that legistaltors assume that the people who manage private and confidential information are aware of and compliant with the laws. In my experience this is not a safe assumption, if fact several of the laws counteract the others. For example, the Canadian PIPEDA privacy act is countermanded by the US Patriot act when Canadian data finds itself on servers within the US. Our challenge is that ignorance is not a satisfactory defense in a court of law.

2) Service Management Processes Must Be Designed & Managed To Account For Security & Privacy Requirements

When the Information Security Book first came out under ITIL version 2 one of the things I remember as striking were the intwined security requirements in all other processes. In fact I like to think of the Security Process as more of a DNA grafting or gene splicing into ITIL rather than a seperate process.

Service Strategy:is responsible for ensuring that business requirements are reiceved via Demand and Business Relationship Management. These inputs have a bearing on Portfolio Management in that it is necessary to understand both the Utility and Warrenty requirements. In this perspective Warrenty will also inlude understanding the security and in some cases the clearance level required for the proposed services and their supporting systems and data architectures. Of course the question here is who holds the accountablity to determin which legistlation applies to the proposed service? While the customer will perhaps have a high level understanding of the compliance requirements it falls to the Service Designer to ferret out the details and how they apply to the Service blueprint or in ITIL terms the Service Package and this brings us to Service Design.

Service Design: is now responsible to ensure that the service design has considered and covered the controls that pertain to (people, process, product and partner). Legal will need to be consulted for input into the legislation requirements relative to access rights, storage policies, IT Service Continuity requirements, Financial Reporting and Data Segregation. Service Design is also responsible for developing the transition and operations procedures required to comply with legistlative requirements.

Service Transition: All Services/systems and technologies are vulnerable when they are undering going change. Several legistlation such as HIPAA and FDA specifically require special consideration, approval and due diligence when changing systems and data under their purview. Transition Processes such as Release & Deployment, Testing & Validation, Change Evaluation will need to have specific security related criteria developed, tested and validated before changes are approved for promotion into production.

Service Operation: Once live special process considerations need to be applied to highly secured or legislatively applicaple services. For example: If an incident occurs on a critical business service with a secret clearance level it will take on a very high priority and be handled only by govermentally cleared staff. Or if it is determined that an Incident is related to a security viloation a special Security Incident Process and team takes over. I have worked in environments where due to data segregation requirements an agency must maintain seperate CMDB’s. 

In Summary, while very few people enjoy this subject it still remains that we are accountable to the business and the powers that be to design, build and deliver IT Services which protect sensitive data and are compliant with the powers that be!

Troy’s Thoughts What Are Yours?

But then, so far as I know, I am the only performer who ever pledged his assistants to secrecy, honor and allegiance under a notarial oath.
~Harry Houdini   

Every organization uses a mixed supplier model to deliver services. How well we integrate our adopted value chain family members is a critical success factor for business value generation.

An organization’s sourcing strategy is a key output of their Service Strategy processes. Being able to execute on this strategy successfully is critical to business success not to mention service delivery harmony.

Join Chris and I as we dive into the challenges and critical success factors of Supplier Management to understand that it is much more than just procurement!

Show Notes:

• Triskaidekaphobia
• Service Portfolio Management Episode 13
• All 14 Episodes of practitioner Radio
• MIXED SUPPLIER MODELS ARE NOT NEW
• Integrating Suppliers Into Process Governance
• Supplier Managers and Olympic Hockey
• Brother from another mother
• Just say no to the term “Outsource”!
• Talk to the Hand
• Service Strategy defines this part of the process, as in WHO does this piece of work
• Out-tasking vs. Outsourcing – TASKS inside my value chain
• Service owners, Supplier management group are both groups that make decisions on out-tasking
• The “C” word – Cloud
• What were we out-tasking BEFORE the cloud?
• Service Asset = Part Resource and Capability
• Procurements Job is to beat your supplier to a pulp, but is this good for business?
• Involving our sourcing partners IN the business process model
• Hollywood prenups and the mixed supplier Model
• Does process maturity make a difference when picking a supplier?
• Just because you speak Spanish as a second language doesn’t mean you can make a burrito.
• The difference between bridging suppliers to your systems or BRINGING them INTO your processes
• Where do BRM people get their skills?

Troy’s Thunder Bolt Tip of The Day: The Role of Supplier Manager is to establish and manage relationships with trusted suppliers in such a way that they contribute positively to your overall service goals.

Troy’s and Chris’s Thoughts What Are Yours?

“A learning experience is one of those things that says, ‘You know that thing you just did? Don’t do that.”― Douglas Adams, The Salmon of Doubt

To subscribe to Pink’s Podcasts on iTunes

The statement “you manage what you know” is even more accurate than the old saying “you manage what you measure!”

Join Chris and I as we look at the strategic process of Service Portfolio management as a critical means for managing and prioritizing the build / run life cycle of value and how to avoid Legacy Hoarding.

Show Notes:

• ITIL 2011e (Changes focused on re-packaging and presentation of information in better ways)
• Service Catalog Book
• Service Catalog Episode
• Service Level Management Episode
• Service Portfolio and the CMDB
• Service Lifecycle Management (Concept, Requirements, Build, Test, Publish, Run, Retire)
• Demand Management Episode
• Service Governance Roles (Service Owner, Service Category Owner?)
• The Service Portfolio is the business case for common processes
• The Service Definition Evolution, (Request - Service Catalog - Service Portfolio)
• Service Portfolio and Project Portfolio
• Service Portfolio Inputs (New Markets, Customer Requirements, CSI of Existing Services)
• Adding Complexity without Retiring Legacy
• IT Hoarders (CIO’s Nightmare)
• Service Owner understands Service Use
• Client Relationship Manager understands Service Demand
• Project Portfolio and Application Focused versus Service Focused
• Service Oriented Cultural Evolution
• Cloud Services and Service Portfolio Management
• Collections of Portfolios
• Service Portfolio The Picture On the Puzzle Box

Thunder Bolt Tip: Service Portfolio Management is in effect the heart of why ITIL even exists. The definition and management of services our customer’s want is the only business case for IT management processes.

Troy’s and Chris’s Thoughts What Are Yours?

“In our view, successful reform is not an event. It is a sustainable process that will build on its own successes - a virtuous cycle of change.” ~Abdallah II

To subscribe to Pink’s Podcasts on iTunes

Not Understanding and Managing Demand results in IT delivering services that do not meet business / customer needs!

Join Chris and I as we dive into Demand Management and discuss how it is the Front Door of Value Generation.

Show Notes:

• Demand Quote: Al Capone: I am like any other man, all I do is supply a demand
• All providers have to manage demand and supply
• Service Desk: Erlang Calculators / Managing Service Desk Demand
• Predicted Demand / Non Predicted Demand (History vs Transactional demand)
• Demand Mgmt requires constant monitoring
• Prince2 & PMBOK & Demand
• Project Management vs Portfolio Management (Service / Project)
• Demand feeds Portfolio Management
• Merger’s & Acquisitions and Demand Management
• The role of Architecture in Demand Management
• The role of Business Relationship Mangers Role and Demand Management
• Demand Management integrations with the Service Life Cycle
• The Service Catalog and Demand Management
• Normalizing Custom Services from SLA’s into the Service Catalog (shaping demand)
• Shaping Demand (Service Desk & Hosting Examples)
• Demand influences through price
• Show Back versus Charge Back (tool for moderating demand)
• Demand Management Tenants: (Receive, understand, predict) & (influence, shape)
• Three Types of SLA’s (Historic, Expected, Psychological)
• Quantified Self – Using Technology to monitor yourself
• Demand Management & 1st line Support
• 4 Entry points in ITIL for Demand Management
• Is A Password a Service Request or Incident?

Thunder Bolt Tip: IT like any service provider is responsible for planning and managing their supply based on demand. Demand Management is in part about receiving and influencing demand based on their clients best interests not their own.

Troy’s & Chris’s Thoughts What Are Yours?

“Ability will never catch up for the demand for it” ~Confucius

To subscribe to Pink’s Podcasts on iTunes

Knowing Who The Actors Are Makes The Storyline Easier To Follow

The primary objective of IT as a trusted service provider and business partner is to manage and optimize the Value Chain of Demand -> Plan -> Build -> Run.

For the most part we understand and execute the various stand alone aspects of this value chain with some degree of success. However it is in the hand-offs between these primary phases that many of our current challenges occurs. For example:

• Not understanding Demand causes IT to deliver services that do not meet business needs
• Having limited to no input from Demand into Plan is a recipe for not getting the service design specifications correct
• Not understanding the Plan or design specifications causes confusion in the identification of acceptance criteria for the build, testing and promote to production tasks
• Having non-aligned, poorly designed, insufficiently tested and ill coordinated service elements being introduced to the Run / Production environment gives everyone a massive headache

Sound Familiar?

Since we cannot boil the ocean tackling all of our challenges at once this article will focus on the hand off from Build to Run. The ITIL Framework has a full set of processes that help manage Service Transition however from a practical aspect I want to focus this article on Release & Deployment Management with its Primary integration to Change Management.

To set the stage for this discussion the following steps represent the primary steps of the Release & Deployment process flow.

1. (Change Mgmt.) Conceptual Approval to build, buy or lease based on the approved design requirements
2. (Release & Deploy) Plan for the release by establishing the right level of “People, Process, Product, Partner and Performance” requirements and production acceptance criteria
3. (Release & Deploy) Build the Release guided by the Design & Plan requirements
4. (Release & Deploy) Test that the Release meets the expected Design & Plan requirements
5. (Change Mgmt.) Based on Release’s attestation that all production acceptance criteria have been met Approve the promotion to production
6. (Release & Deploy) Deploy the release based on the agreed schedule coordinated by Change Mgmt.
7. (Change Mgmt.) & (Release & Deploy) Review & Close if successful

Disclaimer: Now before you get worked up about this not being entirely accurate to ITIL remember this is simple high level conceptual flow of steps that we need to establish before we start talking about the roles in Release and Change Management. Also many of you may argue that Change only comes into play on the “Approval to Promote”. My answer to that is what you are talking about is only Change Control not full Change Management and that in practice not theory your Conceptual Change Approvals may occur in different processes (Project Mgmt. / Software Development / Supplier Sourcing) but are still part of your overall “Change Mgmt. System” (for more information on these subjects see the following articles)

ITIL Implementation Roadmap (Change Management) – Part 4
Change Management from Havoc to Control - Forward Schedule of Change

Finally the two Enablers to Make Release & Deployment work before we speak about resources are:

1. A documented and agreed set of processes, policies and clear description of roles and their responsibilities to overcome the issue of opinion and perception (its not shared truth until its written down and agreed to by all parties)
2. A set of production acceptance criteria and deliverables that have been pre-identified by the various interested stakeholder groups that are grouped by release type and each step in the Release & Deployment Process

ITIL 2011e New Addition Promo: Take a look at the new 2011 edition of the ITIL Service Transition book for a good list of release acceptance criteria by process phase. The author’s did a nice job of augmenting the guidance around this process and of providing a good shopping list of production acceptance criteria for your consideration.

Note: For more information on these two topics check out the following articles & Podcasts:

ITIL Implementation Roadmap (Release Management) – Part 8—Keeping It From Blowing Up On Landing
Practitioner Radio Episode 5 - Release and Deployment

Release & Deployment Roles

Troy’s Personal View: Release and Deploy are two separate phases of the Release lifecycle with very different objectives. Release is concerned that a release conforms to and completes an agreed set of pre-production requirements to ensure that the Release meets the design requirements and is ready to be moved into production in a manner that will not disrupt current service delivery in an non expected manner. Deployment is focused on the packaging and move of the release into the production environment based on the instructions and requirements pre-defined by the release plan.

So with these assumptions in mind lets consider the following roles: (Not Necessarily As Described By ITIL)

The Release Builder: This is the term that I like to use for the folks in IT that actually do all the Plan and Build activities of a release. This could be a Network administrator introducing a new switch, an application developer coding a new piece of software, a server admin provisioning a new physical or virtual server and even a Project Manager who is in a sense a Macro builder coordinating the activities of many others. It is the Release Builder or a group of them that are actually doing all the work in various streams of pre-production type technical processes triggered by customer demand. The Release Builder is and always has been the role that does the lion’s share of work. Release Management is focused on ensuring that the various builders from different internal and external groups follow a set of pre-determined Release activities. Who does the Deploy tasks however is often a question each organization must consider. In some cases this could be done by the Release Builder, in others due to a legal requirement to ensure “Separation of Duties” the people developing the release cannot be the same folks that deploy it into production.

The Release Manager/Coordinator: Since releases can and do originate from many different groups both internal and external to your organization it is important that each pre-production group wishing to introduce a release into the production environment follow the same process, policies and guidelines for Planning, Building and Testing a release. The role of the Release Manager is to work with the Release Builder in determining what level of Risk and Complexity the release represents and then to communicate to the Release Builder what the Release Acceptance requirements and deliverables are for each stage of the release. These requirements are then executed and performed by the Release Builder and validated by the Release Manager. So in summary the Release Manager is a governance or quality oversight role that ensures that the right level or due diligence & requirements are applied to each release based on an accepted process and a proactively developed set of acceptance criteria that are applied based on the release risk and complexity.

The Release Tester: While the release is Planned and Built by the Release Builder it is good practice to have the testing done by a separate role from the builder due to the obvious conflict of interest. ITIL rightly separates Testing & Validation as a separate process that can potentially be part of each of the Release process phases. However, for the sake of this article we will focus on the Test phase following Build. The Release Manager will work with the Release Tester in much the same way as they do with the builder in that they will ensure and validate that the right level of testing is done based on the pre-defined testing requirements for the release prior to its promotion to production. The functional role of the Release Tester can often be found in various parts of an organization. Sometimes testing is done by a dedicated testing or quality assurance group. At other times the testing role is given to another function such as a production support group or another non involved developer. The primary consideration is that the tester be separate and distinct from the builder.

The Change Manager / Change Advisory Board (CAB): Following the completion of the Testing tasks the Release moves forward to receive authorization by Change Management to be promoted / deployed to production. This is done according to the Change Approval requirements defined in that process by your organization. Major changes may required Executive Approval + CAB, Medium changes by a CAB and Minor by Change Manager. In the case of a Standard or Pre-Approved change it is assumed that the Standard Change process also has incorporated the required release assurance tasks. The role of Change Management is to approve and coordinate while the role of Release & Deployment is to assure and deploy. So picture a CAB meeting where a certain change is being reviewed for approval to promote. The Change Manager / CAB will look to the Release Manager to attest to the fact that all Release Plan, Build, Test tasks have been completed by the builders and testers to the appropriate level predetermined by the Plan stage. In short Change is about approval/coordination and Release is about assure/deploy. Many organizations without a Release and Deployment process place all of this burden on Change Management and overwhelm the process with both goals way to late in the release cycle.

The Release Deployer: Following the approval by Change Management to promote the release to production someone actually has to carry our the deployment tasks and move the release to production. Who does the deployment tasks can vary based on service and technology domain. In some organizations there is a specific group that will schedule, bundled and deploy releases for major applications. In other cases the Release Builder may deploy the Switch or Server to production following the Change approval to promote. How and by whom Releases are Deployed into your production environment by both internal or external groups is a key decision and policy point that must be defined as part of your Release & Deployment Management process. In reality the Release Deployment roles will most likely follow several different approaches within the same organization.

Now that the cast has been defined and the stage is set for you to tackle Release & Deployment Management it is time to define who will take on each of these critical roles required to ensure production stability while introducing change.

Troy’s Thoughts What Are Yours?

 
“Out of intense complexities intense simplicities emerge.” ~Winston Churchill

Join Chris and I as we un-pack Availability Management as a Process and discuss how it is part design and part operations.

Show Notes:

• The last episode number 10
• ITIL Implementation Roadmap (Availability Management)
• SLA is the outcome of Service Level Management
• The Availability report is the deliverable of the entire Availability Process
• The product is NOT the means to do something
• Google Dashboard of Availability
http://www.google.com/appsstatus#hl=en
• Evolutions vs. Maturation
• Forget the IT can you have availability for Financial Operations?
• System vs. Application availability based on RISK
• Availability is closer to Problem Management
• Earning your ITIL Pins
• Design part of Availability can be done by a SEPARATE GROUP
• TIP 1:  Take the Availability report and feed it INTO a problem analysis discussion (MINI BOLT)
• Breakfast with Pink
• The dance of demand management
• The ITIL exorsist
• Reactive vs. Proactive
• What is the ACTUAL day job of a “Service Architect”
• Martin Erb is Pink’s Service Architect on Twitter
• White Collar vs. Blue Collar ITIL

Troy’s Thunder Bolt Tip of The Day: Availability Management is not just a report you run every month to satisfy Sr. Leadership. The report is only one output of a full process in the same way an SLA is the deliverable of Service Level Management

Troy’s and Chris’s Thoughts What Are Yours?

Engineers like to solve problems. If there are no problems handily available, they will create their own problems. ~Scott Adams

To subscribe to Pink’s Podcasts on iTunes