Standard Operations and Maintenance

Sandy, if you have any more questions, just let me know!

Standard Operations and Maintenance is really something that gets defined in the Service Level Agreement in consultation and negotiation with the customer. It is not really a determination made solely by IT or Operations. It is the customer or receiver of service that helps to establish whether an “outage” has occurred. Because we want to adhere to the terms and conditions set forth in the SLA we want strong controls in place.

I think it is not a question as to whether the Change Management process will be used or not used. It is more a question of the degree of Change Management that will be used. A solid approach would be to establish a clear definition of a Service Change in the organization.

ITIL says it is any “addition, modification or deletion of elements of the delivery of service” [paraphrased]. This is a broad definition and covers just about everything we do in IT.

So, next we need to identify what we actually do in IT to deliver and support services and see if it matches that definition. If it does we need to decide if we want to apply full ITSM control and tracking to that activity (e.g. rebooting a server). This means identifying Configuration Items, applying Incident and Problem Management, and so on through all our established ITSM processes.

Once we have identified the activities we do that constitute Service Changes, we can decide which ones fall under Standard, Normal and Emergency Change types. This will help us determine the degree of Change Management control for that activity.

• Standard: Pre-approved (one time to the Change Advisory Board), low risk, low cost changes, little potential for an “outage”

• Normal: Unique, higher risk, higher cost, greater potential for an “outage”

• Emergency: Cannot wait, serious impact, true emergencies (failure to complete paperwork does not count), “outage” already exists

The bulk of what might be considered “Standard Operations and Maintenance” should be done using Standard Changes. Like for Like (break fix-e.g. swapping network cards) items can be handled as Incidents, which are in effect substituting for a Standard Change.We should use Change Management to establish control, risk management and assurance of the delivery of service (value to the customer), rather than seeing it as an optional process.

ITIL and PMBOK

Thanks for the great question Beverly.

ITIL V3 and PMBOK Project Management are both best practices that fall under the larger umbrella of IT Service Management (or really just overall Service Management). ITIL focuses on the lifecycle of services, while PMBOK focuses on the lifecycle of projects. Services are all of the things we do to deliver value to our customers. In effect services are a type of product. Projects are temporary (short term) endeavors we undertake to accomplish specific outputs. So we can look at projects as one mechanism or vehicle for establishing and delivering services, products, solutions, etc.

The decision as to undertake a project will be made as a result of ITIL Service Strategy and Service Design. The project team may then use PMBOK best practices for accomplishing the goal, objective or output identified during Strategy and Design. Conceptually this places Project Management roughly equivalent to ITIL Service Transition activities (with some overlap to Service Design and Service Operation). Service Transition includes processes such as Change Management, Service Asset and Configuration Management, and Knowledge Management that span the service lifecycle (and so run parallel to Project Management activities), along with Release and Deployment Management (which dovetails closely with Project Management activities).

It is important to remember that the identification of the need or reason for a project is separate from the project work itself. When you keep this in mind, you can see that ITIL V3 and PMBOK are very complementary and fit well into the overall Service Management approach. So begin with ITIL Strategy and Design, then use PMBOK to accomplish the creation of services and their underpinning elements.

Where to start with SACM? Service Asset and Configuration Management

I often get asked the questions, "Where do I start with SACM? How do I implement this process?"

In my experience, this is one of the most difficult processes to implement correctly. Let’s discuss the first activity of the SACM process of Planning.

In this activity, decisions will be made about the scope of what needs to be controlled in your organization. What level of configuration management is required? How will that desired level is achieved? Do you gather information about a service or about specific components? Do you need to control assets which are causing your customers the most pain points? When do you establish a controlled configuration, how do you change a controlled configuration, and what amount of resources are you going to expend to manage configurations? All of these decisions must be documented and formalized within the configuration management plan.

• Configuration Management Plan:
  · Context and Purpose
  · Scope
  · Requirements
  · Applicable policies and standards
  · Roles and Responsibliites
  · Systems and tools
  · Processes and procedures to implement
  · Implementation plan
  · Interface Controls
  · Supplier Considerations

As you can see, there are many things to consider when implementating SACM. My advice is to start small, begin with a pilot project, ensure tht change management exists with a documented relationship between your change and configuration processes. You should also ensure that once you have collected your data, you can and must control the assets. Remember, the better the planning, the more successful the implementation!

Collecting and Analyzing Requirements

Every ITSM framework and standard references the need to meet "customer requirements". Unfortunately, there is less attention paid to the process of collecting and managing those requirements.

I am happy to report that the ITIL Service Design book contains some good high level guidance on "Requirements Engineering" (Section 5.1). Requirements Engineering is defined as

"the approach by which sufficient rigor is introduced into
the process of understanding and documenting business
and user requirements and ensuring traceability of changes
to each requirement."

The section goes on to to describe a Requirements Catalog for documenting and managing changes to requirements. It also describes techniques and tools for gathering, analyzing and validating requirements with customers.

ITIL defines three levels of requirements: Functional, Management and Operational and Usability.

The Service Design book is particularly good for those who do not have a background in the Software Development Life Cycle (SDLC). I would highly recommend it to everyone involved in process design, implementation and operational management.