ITSM Professor

There are many frameworks and standards that define best practices for achieving quality IT service management (ITSM) - ITIL, ISO/IEC 20000, COBIT, CMMI, DevOps, Knowledge-Centered Support, etc. While each describes processes and controls (what to do), none provide clear, step-by-step methods and techniques for actually designing, re-engineering and improving processes (how to do it).

IT organizations must not only do the right things, but they must also do the right things right. CPDE takes a practical step by step approach to developing and implementing ITSM processes across the entire lifecycle of IT services. It ensures integration with project and program management and the application and software development processes as well. Allowing for strategic, tactical and operational alignment across the entire organization. CPDE is well suited to utilize these different best practices and additionally play a significant role in the DevOps movement that is taking hold in IT organization…

As a noun the official definition of the word inclusion is defined as the state of being included or being made a part of something. When a book covers many different ideas and subjects, it is an example of the inclusion of many ideas. When multiple people are all invited to be part of a group, this is an example of the inclusion of many different people. There are many certification classes available for DevOps, Agile and ITSM. All of them will speak of Inclusion.

When considering inclusion in a DevOps Continuous Delivery Pipeline, service providers frequently miss the inclusion of some very necessary elements. In order to ensure real value, and cost-effective solutions fast, it is back to basics. Consider the inclusion of the following:

Best Practices and Methodologies: These are the answer for how to. It is not just one best practice, methodology or standard that will get you there. “There” is where you are trying to go. Consider methods such as DevOps, ITSM, Agile, Lean and standard…

Originally Published on the DevOps Institute Site
It has become a truism within the DevOps movement that embracing DevOps is much more about making a cultural change than about adopting new processes and technologies.

But changing an organization’s existing internal culture can be profoundly difficult. As Peter Drucker famously noted, “Culture eats strategy for breakfast.” All the best-laid DevOps plans in the world might not make a bit of difference if you can’t get your team to shift its mindset.

As a DevOps leader, managing this cultural change will likely be one of your most frustrating — but ultimately most rewarding — challenges.

Here are five tips from DevOps experts to help manage that change:

1. Cultivate the 5 leadership traits that lead to high performance.
Pick up any self-help book, and you’re sure to read some variation on the mantra that you can’t control whether other people change, you can only control yourself. It might be trite, but it’s true.

Fortunately, as a DevO…

I looked up “Process Design” and found:
“The activity of determining the workflow, equipment needs and implementation requirements for a particular process. Process design typically uses a number of tools including flowcharting, process simulationsoftware and scale models.” 
Hmm… that is good but “So What”?  Why should a service provider care about process?  I have heard some say that process is secondary to automation.  Okay, sounds good, but then we have to consider, “What are we going to automate?”
Every Certified Process Design Engineer knows that when it comes to process we are talking about activity.  The key is that we need just enough process and just enough governance to meet requirements.  Process design contributes to our ability to balance speed and agility with stability.   Having good process design allows for a smooth service belt that delivers value to customers and also gives a service provider the ability to meet business and customer demand at a cost that won’t break t…

Originally Published on the DevOps Institute Site

One of the most interesting trends in DevOps adoption is the evolution of the IT silo into the cross-skilled squad. This is not just a semantical name change. Most IT teams today are comprised of like-skilled individuals such as a Scrum team of developers. The modern squad takes a slightly different approach, is more static than dynamic and is more product-focused than project based. Squads are built around T-shaped professionals –where each member has a specialty competency, but all members have a broad scope of skills across multiple disciplines. A high performing squad essentially has all of the skills needed for the product or feature to which it is assigned and is not generally constrained by the availability of an individual resource. There is enough breadth of knowledge inside and outside the squad to shift more activities to the left so as to allow them to move more quickly and with more agility. While the squad model originate…