Skip to main content

Posts

Service Offerings and Agreements

When we think about what services we are going to offer we immediately think of the Service Catalog.  We must also consider what agreements go along with the delivery of those services.  What levels of utility and warranty are going to be expected over the life of our services?   What about services that will be supplied by external service providers; who is going to manage those?  Let’s take a look at which ITSM processes we will need to engage to ensure that we are able to strategize, design, deliver and maintain services that will meet our customers’ needs over the lifetime of the services. In Service Offerings and Agreements (SOA), we look at Service Portfolio Management (SPM), Financial Management (FM), Demand Management (DM) and Business Relationship Management (BRM).  These are all processes within the Strategy stage of the Lifecycle.  We also explore Service Catalog Management (SCM), Service Level Management (SLM) and Supplier Management (SM) processes within the Design st

CSI and the Communication Plan

Timely and effective communication forms a critical part of any service improvement project. To transform an organization and move people and process from just thinking about Continual Service Improvement (CSI) activities to actually allotting time to be able to performing CSI activities, it is critical that all stakeholders are informed of all changes to the processes, activities, roles and responsibilities. The goal of the communications plan is to build and maintain awareness, understanding, enthusiasm and support among all stakeholders for the CSI initiative. A communication plan is much more than just sending out one notification on what is about to happen and should be a series of notifications and meetings to keep people engaged, informed and passionate while incorporating the ability to deal with responses and feedback from the targeted audience. First, we must design how we will communicate and then we must define what and to whom we will communicate. The pla

The State of ITSM: One Company’s Assessment!

Here is an article I thought you might find interesting.  It was first published in itSMF USA's Source EJournal, April 2017.   The State of ITSM: One Company’s Assessment! By Keith D. Sutherland and Lawrence J. “Butch” Sheets Educators and consultants operating in the formal practice of IT service management (ITSM) have largely been doing so since the mid-90s. Even though the best, codified practices of the IT service management framework, ITIL®, is now just over 30 years old, there remains a large number of organizations still in initial adoption of ITIL.  And of those service providers with longer histories of using ITIL, many still have a significant need to increase maturity, or more fully implement their ITIL practice. The need in these companies for structured education, assessments, and roadmaps still abounds, even while multiple approaches for these practices are available for each. Beyond ITIL (and in many cases, alongside), are the many other evolving a

Agile Best Practices in the Incident/Problem/Change Cycle of ITIL

ITIL is not in conflict with DevOps, ITIL supports DevOps with a solid foundation by providing an up to date an accurate configuration of our IT infrastructure. This, in turn, supports the ability to accurately carry out the detection of issues and underlying problems and deliver collaborative, permanent solutions to operational deviations. Further, it engages the Second Way by “shortening and amplifying the feedback loop” to development.  Historically most IT organizations structure their incident, problem and change processes within a very confined view, typically utilizing these processes from an operational perspective and only marginally engaging them at the design stage of the lifecycle.   ITIL should and can be adapted to DevOps practices to proactively define when incidents and problems arise while still in the design phase of the lifecycle.  This means engaging both software development and infrastructure design in a way that allows us to capture these deviations proactivel

Process Practitioner Examples – Roles and Responsibilities Revisited

Assigning clearly defined roles and responsibilities are critical to the success of every process. These roles need to be defined early and reviewed periodically to ensure proper training, communication and education.  A process without clearly defined roles will fail at some level.   There is a very clear distinction in the activities or the roles that are played out by individuals in your organization.  You should determine and communicate who is accountable and who is responsible for the process activities.  A role is like a hat.  One individual could wear two or more hats.  Watch out for titles.  You might have a title such as Service Transition Manager.  What role(s) would this individual fulfill? It all depends on WHO is best suited for the role or task that needs to be performed when it comes to assigning roles. The Service Transition Manager could be accountable or OWN the “Release and Deployment” process but might also be a practitioner and be responsible to perform task

Agile Service Manager

What is an Agile Service Manager? The following is a definition from the University of California Santa Cruz for an IT Service Manager. “The Service Manager has overall accountability for defining the service, ensuring services meet the business need and are delivered in accordance with agreed business requirements and managing the  service lifecycle  – often in conjunction with a  Service Team ” . I also looked up some jobs offerings from around the globe that were described as Agile Service Management and took some pieces from them.  Here are a couple of examples: Has responsibility for defining and creating the global service, developing the reliability and performance of the services in line with the business requirements, and managing the overall service lifecycle within an agile environment. This includes stability, performance, capability, risk acceptance and analysis of the services. Developing a deep understanding of what is important to the service, you will be pri

Behavior-Driven Development (BDD) – An extension of Test-Driven Development (TDD)

Behavior-Driven Development ( BDD) is a process or best practice for the development (and testing) of code. Behavior-driven development is a design and testing practice that is utilized to ensure that the outcomes and the behaviors of products and services are articulated in terms of business value.  It means that we should step aside from the technical aspects of coding, development and testing and consider, in real everyday terms, what the behavior and usage aspects are of the application or product.   We will still require technical skills, insights, automation and more, but when thinking about the defining and development of a product, business and service providers can articulate in PLAIN ENGLISH exactly what they are attempting to achieve. BDD helps design and development practitioners scope appropriate testing for a variety of test types including: Unit tests : A single piece of code (usually an object or a function) is tested, isolated from other pieces Integration

Network Neutrality – Heads Up!

Network Neutrality preserves your right to communicate freely online. The term Network Neutrality was coined in 2003 by a Columbia University media law professor named Tim Wu.  Back in the day it was referred to as “Open”.   Network Neutrality is a principle where internet service providers and government regulators must treat all data  on the Internet the same.  This means that you cannot discriminate or have differential charging and costs based on user, based on content, website, platform, application, equipment type, or mode of communication. It’s because of Net Neutrality that small businesses and entrepreneurs have been able to thrive online.  Our fair and level playing field is at risk.  Big phone and cable companies and their lobbyists filed suit against the FCC guiding principles for Network Neutrality.  Internet Service Providers (ISP’s) have much to gain financially if they can discriminately charge for varied services that are currently free.  Free Press jumped in an

Service Offerings - Activities for Service Portfolio Management

Service Portfolio Management (SPM) is a process that is defined by ITIL best practices in the Service Strategy Lifecycle Stage.  The initiation of activities for Service Portfolio Management is often a result of changes to strategic plans or the identification of a service improvement plan and are triggered by a proposal that must have executive approval to proceed.   For existing services, Service Portfolio Management considers investments that have already been made along with new investments required.  The combined may result in the service being too expensive for what the business will achieve.  Investment decisions will need to be made.  There are many possible procedures and workflows to fulfill all the details of this process but overall the activities can be clearly understood with four high level process activities. Define – In this stage of the process SPM must document and understand existing and new services.  Every proposal for a new or changed service must be accompa

Work Holistically

I TSM best practice frequently suggests working holistically.   This is particularly true when defining a strategy and architecting a design solution but when you think about it, this holistic viewpoint should permeate every investment, improvement, and action in the entire value stream from thought to end of life for every service or product deployed. At a high-level thinking holistically involves looking at things from a people process technology perspective but cannot leave out our partners and suppliers.  No service, process, or functional team stands alone.   Changing one element of a complex system will impact others.  This is a real challenge because no one team can know everything about all aspects of the system.  Therefore, working holistically requires a balance between specialization (functions and departments) and the coordination of complex integrated process activities.  It is only then do we get a clear picture of the lifecycle of a service and any hope of managing

DevOps Testing – Do it Right

One of the key principles of DevOps stresses that we need to fail and fail fast.   A key part that frequently gets omitted.  That key element of the principle is that we fail fast so that we can LEARN. When we learn it is always best to act and to share.   In the spirit of learning and sharing here are some consequences of not performing DevOps testing properly that might help to mitigate some of your challenges. Consequences of NOT doing DevOps testing properly – challenges and thoughts Culture Conflict Culture Conflict can exist between business leaders, developers, QA testers, infrastructure/tools staff, operations staff or any stakeholder in the entire value stream. When there are unclear roles and responsibilities for the testing of a new or changed service or product, a friction begins.  This friction propagates conflict.  Be aware.  Make management of organizational change a priority. Test Escapes (False Positive)           False Positive Test Escapes occur when

Cyber and DDOS – What is it?

We saw in a recent blog from “The Professor” how cybercriminals could create a network of controlled computers to propagate a “BotNet”.   One of the malicious reasons for these powerful networks of control is so that the hacker can perform “Distributed Network Attacks” (DDA’s). We all have experienced this at some level and the outcome is not good for enterprise, corporations, or businesses of any size.  DDA’s create disruption even to our own home operations.   A DDA is sometimes referred to as a Distributed Denial of Service or DDOS attack.  This virus or network of virus’s attacks behind the scenes to take over system resources.  A DDOS could attack switches, hubs, routers. It sometimes will flood the network backbone with nuisance transactions with the intention of sucking up all the bandwidth that might otherwise be necessary for day to day operations. DDOS can bring to a screeching halt the web sites for processing claims, or even shopping cart interfaces for the purchasing o

Portfolio Management & BRM

The purpose of Portfolio Management, when applied to Provider investments (especially, IT investments), is a central mechanism to an overall Value Management approach by making investment allocation explicit against strategic choices such as how much to invest in potentially high value, but usually risky initiatives versus safe but low-value activities. The Service Portfolio represents the complete set of services that are managed by the service Provider.  It is used to manage the entire lifecycle of all services and is defined by three categories of services.  The service pipeline represents service that is under consideration (purposed) or those that are currently in development but are not yet ready for deployment or consumption by the business partners. The next category is the service catalog which represents all live services or services that are available for deployment to the business partners. The final category is retired services.  This represents the services that are

DevOps Test Engineer Question…What is the difference between Static Testing and Dynamic Testing for Continuous Deployment?

Every organization that delivers products or services will need to shift their ideas for how they plan, build, test and deploy a service that is resilient and for one that truly delivers value for both customers and the internal business.  Continuous Integration, Continuous Delivery, and Continuous deployment are all supported by Continuous testing.    Continuous anything will not be assured of success without Continuous Testing.   Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Shifting left ensures that the test takes place early, up front in the pipeline of delivery, NOT after the development.  Testing after development is too late because then we do not have the time, money or resources available to re-engineer, re-design or to re-develop appropriately.   When we test after the development of an application the best we can do wit