Mark Thomas – Interface Technical Training https://www.interfacett.com Wed, 21 Jun 2017 19:26:18 +0000 en-US hourly 1 ITIL – Change Management. Projecting Service Outages for your Change Advisory Board https://www.interfacett.com/blogs/itil-change-management-projecting-service-outages-for-your-change-advisory-board/ https://www.interfacett.com/blogs/itil-change-management-projecting-service-outages-for-your-change-advisory-board/#respond Wed, 24 Aug 2016 16:25:03 +0000 http://www.interfacett.com/blogs/?p=?p=23228 In this video, Instructor Mark Thomas presents how he visually creates a graph to help manage projected Service Outages in order  to effectively communicate with the Change Advisory Board (CAB). Video Transcription: The process called change management is a tough one to get down. One of the things we talk about in the ITIL Foundation … Continue reading ITIL – Change Management. Projecting Service Outages for your Change Advisory Board

The post ITIL – Change Management. Projecting Service Outages for your Change Advisory Board appeared first on Interface Technical Training.

]]>


In this video, Instructor Mark Thomas presents how he visually creates a graph to help manage projected Service Outages in order  to effectively communicate with the Change Advisory Board (CAB).
Video Transcription:

The process called change management is a tough one to get down. One of the things we talk about in the ITIL Foundation class is the whole idea of what the process is, why it exists, and some core activities as a part of the process.

Projected Service Outage / Change Schedule

Two things that the change management process produces are, one is called the Projected Service Outage, and the other is called the Change Schedule.

I had some challenges with the change schedule in an organization I was in. For us, changes were like the Wild West. People were dropping modifications into my production environment at all times of the day.

We had to get some control over how we applied modifications to my targeted environment, so we created a formal Change Schedule with change windows, or these apertures of time, at which we could approve and schedule modification into the production environment.

001-ITIL-formal-change-schedule

To give you a snapshot of what we did, basically what happened in our organization, we ran our our Change Advisory Board (CAB) on Tuesdays.

002-ITIL-formal-change-schedule

What you see here is a running calendar, Monday through Friday, Saturday/Sunday, Monday through Friday, Saturday/Sunday, and so on.

This was a running calendar that we kept track of all the current and future plan changes.

We did our CAB. What we were talking about is upcoming changes. When we scheduled those changes, they went into one of two Change Windows, or Release Windows, that we scheduled on a weekly basis.

The first one we did was on Wednesday night. It was a very small window.

003-ITIL-formal-change-schedule

This was more of a maintenance‑type of window, Wednesday night where small changes went in. These normally were not very highly complex, but they were changes that had to go in, and we could schedule those into this aperture or this change window.

004-ITIL-formal-change-schedule

We also had another window scheduled over the weekend. Notice this one’s a little bit bigger.

005-ITIL-formal-change-schedule

This is where we did larger changes, more complex, and sometimes medium‑size releases would go into each one of these windows.

005b-ITIL-formal-change-schedule

As we would evaluate our Change Advisory Board (CAB), when we were looking at when we needed to deploy certain changes that were being requested, we could now figure out, based on our forward schedule, where we could actually place these changes in and build ourselves that change schedule that we were going into.

That doesn’t mean we can’t violate these windows. Sometimes, changes are required that can’t fit into one of these windows. Therefore, with the proper approvals and the right business case behind it, we could create an additional change window for a specific change.

006-ITIL-formal-change-schedule

Again, we had to address the risks of those, and so on.

If you come to my CAB on Tuesday right, we could actually schedule you into any one of these future windows that was the most appropriate for not only you, and appropriate for the organization from a Risk Management perspective.

This is one of the things that we talk about in the Foundation class for ITIL. Change Schedule, many of the things that we talk about, that we dive a little bit deeper into it so you can take this information to work tomorrow and use it effectively.

Enjoy,

Mark Thomas – ITIL and COBIT Instructor
Interface Technical Training

The post ITIL – Change Management. Projecting Service Outages for your Change Advisory Board appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/itil-change-management-projecting-service-outages-for-your-change-advisory-board/feed/ 0
Three Steps to Conducting Requirements Workshops https://www.interfacett.com/blogs/three-steps-to-conducting-requirements-workshops/ https://www.interfacett.com/blogs/three-steps-to-conducting-requirements-workshops/#respond Mon, 03 Mar 2014 17:26:38 +0000 http://www.interfacett.com/blogs/?p=?p=16924 Whether you are a business analyst, project manager, or software developer, at some point in your career you will most likely be asked to elicit requirements for a new initiative. There are several techniques to accomplish this including interviews, observation, surveys, job shadowing, brainstorming, and requirements workshops to name a few. All of these techniques … Continue reading Three Steps to Conducting Requirements Workshops

The post Three Steps to Conducting Requirements Workshops appeared first on Interface Technical Training.

]]>
Whether you are a business analyst, project manager, or software developer, at some point in your career you will most likely be asked to elicit requirements for a new initiative. There are several techniques to accomplish this including interviews, observation, surveys, job shadowing, brainstorming, and requirements workshops to name a few. All of these techniques consist of three basic elements: prepare, conduct, and follow-up. However, they do have differences – you should have an understanding of what they are and how they are best used.

Select which technique to use based on the following factors:

  • Project scope and complexity.
  • Cost and/or schedule constraints.
  • Stakeholder availability and geographic dispersion.
  • Team knowledge of the subject matter and overall development process.

My personal favorite technique is the Requirements Workshop. This is a structured meeting with the specific goal of capturing requirements. It is used to define, prioritize and hopefully finalize requirements for the new initiative that you’re working on. Requirements workshops typically last between one and a few days. They should also be a highly focused event that is let by a seasoned facilitator. Some benefits and disadvantages of the requirements workshop are identified in the following table:

Benefits Disadvantages
Get to a set of meaningful stated requirements in a short,
intensive session.
 

Having the right stakeholders involved
that will allow for a much easier buy-in.

Requirements are considered, discussed, and understood before going to final approvals

There can be a lot of time, coordination and finances required. 

Getting the right resources in the same room, at the same time with the proper authority to speak on the subject matter.

You may have to run several workshops

If you’re looking for more detailed information about this, and other techniques used by BAs, there’s a great body of knowledge out there that can offer much more insight into what I’ve discussed above. It is called the Business Analysis Body of Knowledge, or BABOK. You can find it on the International Institute of Business Analysis IIBA websitesite

Tips that you may want to remember:

1. Requirements are as good as the sources you use to prepare. Strive to seek meaningful information regarding the subject matter. Some great places to look include: customers, users, internal and external experts/SMEs, industry benchmarks, etc.

2. Get the right resources scheduled for the meeting and get meaningful information to them before the actual session. Do some pre-interviews to gather valuable insight in the subject matter, as well as perspectives that you might not have considered.

3. Don’t forget the cost of conducting the workshops. Work with the project manager to ensure that you have adequately captured the costs. This includes areas such as facilities, time, reproduction, food and so on.

4. One of my biggest pet peeves is when a key resource sends their “designated hitters” to a workshop without giving them the capability to make decisions on their behalf. When this happens, the schedule can be prolonged because these representatives cannot act as the decision makers themselves. Get the word out early that if a key representative sends someone in their stead, they should also send them with the ability to speak for them.

5. Do as much in advance as possible and get information out to the team well ahead of the actual session. This allows team members to clarify any misconceptions, as well as offer a platform of information to work from. In this world there are two types of people: those who can create information from scratch, and those who can only modify information that they have in advance. Assume the people you are dealing with are from the second type.

6. Be careful about scope creep. Many analysts unwittingly add scope to an effort and don’t even realize it. Know the core business objectives and scope, and refrain from adding functionality that is not in the original approved boundaries. If you add scope, there must be additional funding and time to make this happen.

7. Run the workshop professionally and efficiently. Control the flow of the discussions and keep the participants focused on the specific and relevant topics. This means having an agenda beforehand, as well as using visual tools to assist in the discussions. Visual tools can include whiteboards, projectors, templates, etc.

8. Functional decomposition is a great way to organize. When dealing with requirements, it is very difficult to add structure to their organization. Try to get a list of requirements early, then break them down into logical groups at a high level. The intent of decomposition is to break big things down into small things. You can correct and improve the model as you move forward.

9. If you are discussing a scope that is best illustrated using a prototype, then by all means use a prototype. It allows the team to use this as a visual baseline for defining specific functionality. You’re not trying to sell the prototype, simply creating a model that can be altered as needed.

10. Finally, make sure you have a good strategy on tackling the workshop. Below is a representation of the things to consider before, during and after the workshop.

IIBA Steps to Conducting Requirements Workshops

There are many tips, tricks, and techniques to these requirements workshops. What I’ve done in this blog is give you my perspective based on experience. Give them a shot, and build your own list. Good luck!

Mark Thomas – Director of Business Services
Interface Technical Training

The post Three Steps to Conducting Requirements Workshops appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/three-steps-to-conducting-requirements-workshops/feed/ 0
Understanding the Components and Phases of the ITIL Service Lifecycle https://www.interfacett.com/blogs/understanding-the-components-and-phases-of-the-itil-service-lifecycle/ https://www.interfacett.com/blogs/understanding-the-components-and-phases-of-the-itil-service-lifecycle/#respond Wed, 15 Jan 2014 17:55:11 +0000 http://www.interfacett.com/blogs/?p=?p=16576 This post is from our ITIL 2011 Foundation online video training library. Video transcript: Understanding the Components and Phases of the ITIL Service Lifecycle Instructor: Mark Thomas. The key components to the ITIL lifecycle in Service Management is what we call the ITIL Core. We call those by phase names such as the first phase … Continue reading Understanding the Components and Phases of the ITIL Service Lifecycle

The post Understanding the Components and Phases of the ITIL Service Lifecycle appeared first on Interface Technical Training.

]]>
This post is from our ITIL 2011 Foundation online video training library.


Video transcript:
Understanding the Components and Phases of the ITIL Service Lifecycle
Instructor: Mark Thomas.

The key components to the ITIL lifecycle in Service Management is what we call the ITIL Core. We call those by phase names such as the first phase of the Service Strategy (SS) side. These are phases of a lifecycle that a service goes through.

The second phase that we would go through is what we call Service Design (SD). The third is Service Transition (ST) then Service Operation (SO) and lastly we have Continual Service Improvements (CSI).

001-components-phases-of-a-service-lifecycle

Let me tell you a little bit about what each one of these phases will cover more in depth throughout the course.

002-components-phases-of-a-service-lifecycle

SS – Service Strategy‘s focus is on developing the capacity to achieve and maintain a strategic advantage, to refine and create policies, guidelines and process that cross all the ITIL Service Life cycle. So that you see on the schematic that Service Strategy crosses the entire life cycle.

SD – Service Design takes the Service Strategy and creates the design will eventually operationalize those business objectives. The focus is on the design for new changed and updated services. We are putting a new service in, we’re retiring a service or we’re changing something about it.

ST- Service Transition provides the guidance for development and improvement of capabilities for transitioning new or changed services into the live service operation. The activities that we actually put in or retire that make changes.

SO – Service Operation manages the day-to-day operation of a service, and provides guidance on the effective and efficient delivery and support.

CSI – Continual Service Improvement provides critical guidance in creating and maintaining value for customers through better design transition and operation of services.

As a former CIO for a large data center operation, we were always looking at our list of services within our portfolio. Services went through the lifecycle phases. For example, if we were launching a new service such as Voice and Data Service, we had to go through Service Strategy (SS). We needed to consider “What is it that this thing really is going to accomplish for us from a value perspective?”, “Do we go into Service Design (SD) for this new service?” “What is it going to look like? “, “What’s the solution, the tools, the architectures, the processes required, the metrics and measurements we’ll use to manage this and to keep track of its health”.

Then, we go into Service Transition (ST), we’re approving these changes, deploying and releasing them, capturing the knowledge for transitioning the new service into the live environment or live operation. Then Service Operation (SO), we actually run and support the service at that point.

We then use this from a Continual Service Improvement (CSI) perspective throughout this entire set of lifecycle phases to help us continually improve, monitor our metric measurements, Key Performance Indicators (KPIs) to actually help us understand that we have mile markers so we can know from an improvement perspective.

The ITIL Official Site, www.itil‑officialsite.com is where you go for the most recent and up‑to‑date information on the components of the Service Lifecycle.

A lot of time folks really get the misconception that this is a waterfall approach. Just like the Systems Development Lifecycle (SDLC) or something similar. You will notice that each of these phases has outputs and feedback that comes from other phases. For example, you’ll notice that Service Strategy has out put into Service Design. Notice that every phase of the lifecycle from that point forward all provides feedback back into the Service Strategy phase.

003-components-phases-of-a-service-lifecycle

Service Design has outputs, it has feedback that comes into that, as well as Service Transition, Service Operation, and notice CSI or Continual Service Improvement, from a lifecycle stand point, touches every one of those phases as well as the services including the processes we use to support the lifecycle as well.

If I asked you a question, “which phase of the Service Lifecycle is your organization in today?”  It’s a trick question; you are really in all of them. If you think about it, let’s take email service for example, email service is currently in Service Operation. It’s a live service that we might be supporting and some pieces of it might be in transition. We might be deploying changes to the email platform. We might be in Service Strategy or Service Design, looking at new changes, the value of new changes, updates and upgrades to the email platform. So you could be in a lot of phases. Again you are looking at this from the view-point of a specific service.

These are the key Lifecycle Phases. You might remember we looked at a slide earlier where we talked about the certification scheme, where we had you go through a foundation course and you go through lifecycle courses. Well here is what we are talking about on the lifecycle courses. Service Strategy, you could go through Service Design, Transition, Service Operation and CSI. Those are the five core ITIL Lifecycle Phases and we will break those down in later videos.

Mark Thomas – Director of Business Services
Interface Technical Training

The post Understanding the Components and Phases of the ITIL Service Lifecycle appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/understanding-the-components-and-phases-of-the-itil-service-lifecycle/feed/ 0
Ten ways to be a more valuable Business Analyst https://www.interfacett.com/blogs/ten-ways-to-be-a-more-valuable-business-analyst/ https://www.interfacett.com/blogs/ten-ways-to-be-a-more-valuable-business-analyst/#respond Mon, 09 Dec 2013 15:59:10 +0000 http://www.interfacett.com/blogs/?p=?p=16247 In many of the business analysis courses I teach, I’ve found a common reason people come to training,  the number one question I get is, “how do I add value to the organization as a BA?” Expectations vary, but at a minimum, organizations expect some common functions from business analysts. First, a BA is primarily … Continue reading Ten ways to be a more valuable Business Analyst

The post Ten ways to be a more valuable Business Analyst appeared first on Interface Technical Training.

]]>
In many of the business analysis courses I teach, I’ve found a common reason people come to training,  the number one question I get is, “how do I add value to the organization as a BA?”

Expectations vary, but at a minimum, organizations expect some common functions from business analysts. First, a BA is primarily a liaison between the business and IT, a BA must also have enough knowledge of the inner workings of the business and IT department to be able to translate between the two, and lastly, a BA must elicit and document a set of useable requirements for the development and deployment of new or changed capabilities.

In light of those functions, here are my top ten suggestions for BAs looking to become a powerful enabler to successful projects:

  1. Understand the business.  By far, this is the most important of all.  Don’t stop at simply understanding the business model, but how IT works as well.  Spend some serious time researching how the organization interacts, where the key relationships are, and how the business and IT architectures intersect.  Hint – start with the enterprise architecture group, if you have one.
  2. Know how the organization deploys new functionality.  Whether you use the SDLC, Spiral, Agile, or a combination of these, knowing how the organization builds and deploys new solutions is paramount.  Most organizations I encounter use a typical SDLC, otherwise known as a waterfall approach.  If so, you can easily develop a list of the artifacts and deliverables by phase, and determine which ones are the most appropriate for the BA to own.  Hint – many organizations are moving to the agile space, so do some reading on it because sooner or later you will be asked to play a role there.
  3. Get comfortable with elicitation techniques.  Elicitation is the process of drawing information from stakeholders to ultimately create requirements.  There are a lot to choose from, many of which can be found in the Business Analyst Body of Knowledge (BABOK).  My top picks include brainstorming, interviews, surveys, job shadowing, and workshops. Hint – if you’re new to it, find a mentor who can help you get comfortable with the process.
  4. Get good at modeling techniques.  What are the MOST important techniques for a BA?  You guessed it, process modeling and use-cases.  Knowing how to create quality “as is” and “to be” process models is a great skill to have and is often overlooked. What surprises me the most is that a lot of organizations completely overlook the utility and power of use-cases.  Hint: you can find a lot of useful information on use-cases by researching the Unified Modeling Language, or UML.
  5. Learn problem solving skills.  Getting to the root cause takes much more than just getting a team together to discuss a problem.  As a BA, you may be in the perfect position to drive Root Cause Analysis (RCA) because of your unique perspective on the business.  Hint – do some research on the Kepner-Trego model, in my mind it’s one of the most powerful and useful tools in this space.
  6. Know the difference between project scope and requirements scope.  This is where most project managers and business analysts get sideways with each other.  Bottom line, project managers focus on management of the project, while BAs focus on management of the business requirements.  A good rule of thumb that a PM once taught me was this, the BA manages a project within a project, and that is managing requirements.  Don’t get into the trap of allowing scope creep under your nose.  Hint: Plan for change at the beginning of each project.
  7. Get comfortable with requirements prioritization and traceability.  Not to sound negative, but the majority of your projects will end up getting squeezed for time at the end of the project.  What to do?  You have three options:  1. Slip the date (guess what, that won’t happen), 2. Add more resources (guess what, this rarely works), or 3. Remove scope (guess what, if you have good prioritization and traceability, this can work).  Hint:  Removing scope doesn’t mean it goes away; you can always package that scope into an upcoming project or release.
  8. Don’t get caught in the tool trap.  Tool use can drastically improve efficiency, and can also expose process weaknesses.  To avoid this, be sure to treat tool selection, deployment and adoption like any other project – complete with process flows and use cases.  Hint:  Definitely do your due-diligence when procuring a tool.
  9. Get to know your BOKs.  There’s a body of knowledge for just about anything we do in IT.  My top picks for a BA:  Business Analysis Body of Knowledge (BABOK), Project Management Body of Knowledge (PMBOK), Business Process Management Common Body of Knowledge (BPM-CBOK).
  10. Finally, understand how governance frameworks are used.  Many BAs get so wrapped up in analyst techniques they don’t spend time understanding the larger governance landscape.  A good starting point is to get acquainted with some of the more popular frameworks that help with the governance of enterprise IT.  Look at these to help: ITIL, COBIT, TOGAF, and ISO standards.

 

I could run down multiple additional tips here, but these are some of what I believe are the most critical for today’s BA to understand.  The bottom line: You CAN add a lot of value to your organization, and getting there might not be as hard as you think.

Thoughts?  Of course I’m open to any other ideas you may have.

Mark Thomas – Director of Business Services
Interface Technical Training

The post Ten ways to be a more valuable Business Analyst appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/ten-ways-to-be-a-more-valuable-business-analyst/feed/ 0
IT today – IT exists because the Business exists. https://www.interfacett.com/blogs/it-today-it-exists-because-the-business-exists/ https://www.interfacett.com/blogs/it-today-it-exists-because-the-business-exists/#respond Mon, 25 Nov 2013 16:50:42 +0000 http://www.interfacett.com/blogs/?p=?p=16129 ITIL 2011 Foundation Module: Service Management as a Practice Title: IT Today, IT Opportunity Instructor: Mark Thomas – Director of Business Services – ITIL, COBIT and Business Analysis Video transcript: IT Today, IT Opportunity As we start to look at Module 3 – Service Management as a Practice. I think it is important for us to look … Continue reading IT today – IT exists because the Business exists.

The post IT today – IT exists because the Business exists. appeared first on Interface Technical Training.

]]>
ITIL 2011 Foundation
Module: Service Management as a Practice
Title: IT Today, IT Opportunity
Instructor: Mark Thomas Director of Business Services – ITIL, COBIT and Business Analysis


Video transcript:

IT Today, IT Opportunity

As we start to look at Module 3 – Service Management as a Practice. I think it is important for us to look at what we’re dealing with IT today. Some of the current challenges that we’re up against and expectations the business might have from us as well as look at the opportunity we have with an IT. Because there’s a within the Service Management world that we can do to improve our services and really get more aligned with our customers.

[0:30] Today’s IT. One of the things that will not go away within our IT organizations, within the infrastructure in general is change. We will always have change and that’s not going away. We have to make sure that we are using some advanced methods to help us really meet the business needs because that’s why we exist. We’re supporting the business.

There’s a growing reliance of business on IT. We are woven into the fabric. IT services are in the fabric of the business. Without IT, the business cannot succeed in creating those vital business functions that the business needs to be able to survive. Therefore, IT exists because the business is exists.

[1:17] Because the business is dependent on us for delivery of services, there’s a high demand for real business value. If we didn’t provide value, there’s no need to have an IT organization. We need to make sure we’re providing. We get that the cost benefit that what we’re supposed to deliver delivers and it exceeds expectations on the customer’s side.

Greater business and IT integration, we’re not talking about integration meaning we have a meeting per week with our business units. What we’re talking about is really understanding the vision, mission, goals, objectives of the business. Where the organization is going and the IT organization is in line with that. And that we’re constantly integrated providing the services that the business expects at the levels of service they expect availability, capacity, all those pieces that are required there in order to do that.

[2:10] We have to provide high‑quality, cost‑effective services. We are really investing high sums of money in IT system. Therefore, we need to make sure that we’re good stewards of the technology that’s being invested in in order to provide these services.

IT today needs to greater flexibility and faster response to customer needs. We know this is a challenge and a lot of folks talk about IT. “It takes too long to get this changed and I need it yesterday.” There are some processes and part of this whole life cycle phase that helps us plan these in a phased approach so that we’re not so reactive and we’re not finding ourselves under‑capacity because we didn’t expect certain demands that are being put on the IT organization.

[3:01] There is a diverse range of technologies, I will say that in every organization that I walk in, you will not find a data center or an IT technology organization that’s getting easier to manage. The technology is complex. The technology is very powerful so that we’ve got that challenge that we have to make sure that we’re managing that piece and that’s what we’re supposed to be doing to support the business value.

Are we too reactive? If I’m an organization and I’m really good at managing incidents, handling incidents. I had this happened to me in an organization, we were great. When an incident call came in, we can handle everything and we are really good at it. But when you really think about it, being good at managing the operational stuff like incident management problem, is that good enough? Or, should we actually look ahead a little bit in the lifecycle and try to understand why those incidents are even coming into the organization?

[4:00] That’s what we want to focus on. We’re not planning, we’re not training. In many cases, we’re not reviewing, investigating and working with customer. I shouldn’t say we’re not. I’d say there’s too little time putting into that because we keep putting our fingers in the hole of the pipe and sooner or later. We’ve run out of fingers but when we should’ve looked at why those holes are even there in the first place. Those are some challenges we’re running into.

The IT Opportunity:

001-it-opportunity

Why is it important to really understand those challenges? We have the opportunity with an IT service management and that IT opportunity we have is basically adjust our working practices and embrace a service‑oriented approach. What are services we provide, what value do they provide for the customers and therefore have that approach? We can have some prioritization around understanding how we’re going to integrate with the business. Increase that service quality. Be more efficient so we can control those costs and risks. Adopting that service‑oriented approach for the efficient and effective delivery of IT services to meet the business needs. That’s what we need to do with the opportunity we have in IT today.

 

The post IT today – IT exists because the Business exists. appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/it-today-it-exists-because-the-business-exists/feed/ 0
Main Concepts of the Service Lifecycle https://www.interfacett.com/blogs/main-concepts-of-the-service-lifecycle/ https://www.interfacett.com/blogs/main-concepts-of-the-service-lifecycle/#respond Mon, 18 Nov 2013 19:15:13 +0000 http://www.interfacett.com/blogs/?p=?p=16067 Watch the Video! ITIL 2011 Foundation Module: Service Lifecycle Title:  Main Concepts of the Service Lifecycle Instructor: Mark Thomas – Director of Business Services – ITIL, COBIT and Business Analysis Video transcript: Overview of the Service Lifecycle in ITIL Foundation What are some of the main concepts of the Service Lifecycle in the ITIL framework? … Continue reading Main Concepts of the Service Lifecycle

The post Main Concepts of the Service Lifecycle appeared first on Interface Technical Training.

]]>
Watch the Video!


ITIL 2011 Foundation
Module: Service Lifecycle
Title:  Main Concepts of the Service Lifecycle
Instructor: Mark Thomas Director of Business Services – ITIL, COBIT and Business Analysis


Video transcript:

Overview of the Service Lifecycle in ITIL Foundation

001-concepts-of-the-service-lifecycle-ITIL-foundation

What are some of the main concepts of the Service Lifecycle in the ITIL framework?

The first one is what we called Service Strategy (SS) Governance and Decision-making. Remember, we talked Service Strategy as being one of the initial phases of the Service Lifecycle.

003-service-strategy-concepts-of-the-service-lifecycle-ITIL-foundation

There are some processes in Service Strategy that we’ll cover throughout this course.

[0:29] Processes like strategy management, financial management for IT services, demand management, service portfolio management, and business relationship management.

[0:38] Part of the foundation‑level course actually, in the exam, you will only actually be examined against financial management, portfolio management, and business relationship management. Those are the processes that make up Service Strategy.

[0:52] Some key concepts, such as Utility vs Warrantee. (we’ll talk more about these throughout the course). It’s really all based on that value proposition that we talked about earlier. Governance and decision‑making, what we want to do, who we want to do it for, what value does that provide to our customers within the Service Strategy side.

Next, we have what’s called Service Design (SD).

002-service-designconcepts-of-the-service-lifecycle-ITIL-foundation

Service Design is building structure service integrity. I think of this as the blueprinting phase, when we’re designing from a strategic standpoint what we wanted to accomplish.

Now we’re going to the design phase of the Service Lifecycle. So there’s an aspect like what’s the service solution?, what tools are required?, architectures, processes, metrics and measurements, and so on. There are a lot of processes in Service Design such as design coordination and Service Catalog Management, Service Level Management, Capacity and Availability management, Continuity, Information Security and Supplier Management, these are all key processes within Service Design.

We’ll go further into detail of Service Design later on in this course.

[2:00] Next we put this whole piece together and put it in something called a Service Design Package and then we move it into Service Transition (ST).

004-service-transition-st-concepts-of-the-service-lifecycle-ITIL-foundation

Service Transition is the next phase of preparing for and doing the actual changes like Change Management, Service Asset and Configuration Management (SACM), or config.

Other processes to Service Transition(ST) are Knowledge Management, Transition Planning and Support, Release and Deployment Management (the actual build, test and delivery), Service Validation and testing and Change Evaluation.

In the scope of the foundation‑level course from an exam perspective, you’ll be focusing on Change Management, Service Asset and Configuration Management (SACM), Knowledge Management, Transition Planning and Support, and Release and Deployment Management.  These are the key concepts we’ll talk about in the Service Transition portion of this course.

[2:53] Next we have Service Operation (SO). The change is handed off over to the service operation side, and the service operation, is now running and supporting that service.

007-service-operation-so-concepts-of-the-service-lifecycle-ITIL-foundation

Some processes in Service Operation (SO) are Event Management, Incident Management, Problem Management, Request Fulfillment and Access Management.

We also see the introduction of something called Functions or Units of Organization, as a part of the Service Operation, which are supporting that live service as it is today.

Next we have the Continual Service Improvement (CSI).

005-continual-service-improvement-csi-concepts-of-the-service-lifecycle-ITIL-foundation

There’s one process called the 7‑Step Improvement Process, a lot of very neat, very powerful models from an improvement perspective such as the PDCA or the Deming Model.

[3:50] I want you to notice something, though. Every one of these phases that we have, which includes those processes and the key concepts. They have this central nucleus, this central theme, or this area, this Service Knowledge Management System (SKMS).

006-service-knowledge-management-system-skms-concepts-of-the-service-lifecycle-ITIL-foundation

IT organizations cannot perform our duties without a means of collecting, storing, having knowledge and information available for recall. That we don’t have to learn the same things over and over again. We call this the Service Knowledge Management System (SKMS).

[4:22] There’s a lot of details in here. We haven’t covered these yet, these are part of the course. But it’s interesting. I want you to make sure you remember that the SKMS, or Service Knowledge Management System, really is that central glue that holds all these phases in these processes together, so we have consistent information, consistent data, consistent knowledge, and wisdom. We’ll talk about what those components are in a later video.

[4:46] Those are the main concepts of the Service Life Cycle, so you can see, this is a very big model, very big framework, and we’re going to take this piece‑by‑piece coming up…

For more ITIL Video Training visit the complete course ITIL 2011 Foundation.

 

The post Main Concepts of the Service Lifecycle appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/main-concepts-of-the-service-lifecycle/feed/ 0
ITIL – Building a Service Catalog in 4 steps, Part 3 https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-3-of-3/ https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-3-of-3/#comments Mon, 29 Jul 2013 14:58:19 +0000 http://www.interfacett.com/blogs/?p=?p=14381 In the first two parts of this blog series, we reviewed the four steps we used to deploy and manage our first Service Catalog. Part 1: Get something out there. Step 1. Part 2: Refine the information. Steps 2 and 3. Now I’d like to outline some key takeaways that might help. Step 4. Once … Continue reading ITIL – Building a Service Catalog in 4 steps, Part 3

The post ITIL – Building a Service Catalog in 4 steps, Part 3 appeared first on Interface Technical Training.

]]>
In the first two parts of this blog series, we reviewed the four steps we used to deploy and manage our first Service Catalog.

Part 1: Get something out there. Step 1.

Part 2: Refine the information. Steps 2 and 3.

Now I’d like to outline some key takeaways that might help. Step 4.

Once you get this going with you Service Catalog, you have to stay on it. After all of this, we certainly had a lot of work to do in other process areas, notably Service Level Management, Incident and Request (honorable mentions include Event Management, Access Management, Availability Management, and Capacity Management). However, without a working catalog to help our customers (and us) understand what our value was, we couldn’t touch these processes.

There are many approaches to launching your first catalog, and they all have merit. The important aspect of how you determine to do this is driven by your customer needs balanced with the resources available.

Thinking back on this endeavor, I’d like to share with you my top ten points to remember about your service catalog:

  1. Get something out there now: you can modify this based on demand patterns and customer feedback, but having the catalog visible to the customers is key
  2. Managing the Service Catalog is a process: design it, launch it, and manage it like any other Service Management process (and use Business Analysts to assist)
  3. Think of the catalog as the “3 Ring Binder” in your hotel room: make it visible and understandable to your users and customers
  4. Remember, this is published to your customers: think of them when you are building it and get their input, remember that the portal must be easy to navigate
  5. The catalog is not simply a list of applications: Services are what the customers are paying for (think Email versus Exchange)
  6. This is not a “one and done” effort: the catalog will always be changing; therefore integrate it with other processes such as Change Management
  7. Identifying and assigning roles is paramount: know who does what, and how they do it (RACI charts are often helpful here)
  8. Self-help will be a huge winner: allow your customers and users to complete their own requests through the use of forms and workflows
  9. The catalog cannot survive without other processes: integrate change, release, incident, request, and others to build a complete customer focused capability
  10. Looking for examples? Try higher education institutions

I hope this series has been helpful. My goal is not to dictate a standard industry approach to launching a Service Catalog, rather to offer an example of my first experience. Remember, you design your launch by using several influencing factors: 1) what’s best for your customers, 2) leverage your capabilities and resources, and 3) take action!

Mark Thomas – Director of Business Services
Interface Technical Training

The post ITIL – Building a Service Catalog in 4 steps, Part 3 appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-3-of-3/feed/ 4
ITIL – Building a Service Catalog in 4 steps, Part 2 of 3 https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-2-of-3/ https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-2-of-3/#comments Fri, 26 Jul 2013 16:43:57 +0000 http://www.interfacett.com/blogs/?p=?p=14353 In part one of this blog series, we discussed Step 1 to my first Service Catalog (Get something out there!).  In this part, I’d like to share with your our final three steps.  Step 2:  Refine the catalog with meaningful information. Once we had a basic catalog launched with key services, we found our first … Continue reading ITIL – Building a Service Catalog in 4 steps, Part 2 of 3

The post ITIL – Building a Service Catalog in 4 steps, Part 2 of 3 appeared first on Interface Technical Training.

]]>
In part one of this blog series, we discussed Step 1 to my first Service Catalog (Get something out there!).  In this part, I’d like to share with your our final three steps. 

Step 2:  Refine the catalog with meaningful information.

Once we had a basic catalog launched with key services, we found our first big issue.  Customers started calling us with two important pieces of information:  1) they loved the new site, and 2) they noticed that we forgot a few things.  Now I found out that the little ‘favors’ we did for certain customers were no longer just favors, they were service expectations.  Many of these were legitimate services that we didn’t document in our first round, but how do we manage all of this?  We had to determine how to add/change/remove services and their details from our catalog in an organized fashion.

Believe it or not, this was easier than I expected.  Most likely because we already had mature change and release process as well as defined roles for each service.  Leveraging our service owners and change management, our Service Catalog was essentially updated on a release schedule, meaning that as we documented new or changed services with our customers, a new release of the catalog was deployed, and of course this was approved by the appropriate change authority.

Like before, here are my notes from this step:

001-illistration-Building-a-Service-Catalog

  • Define the process for adding, removing, and amending services in our catalog through change and release management
  • Leverage our service owners to own the identification, scoping, and updating of services – they will represent service changes in the CAB (Change Advisory Board)
  • Since we really don’t have Service Levels agreed yet, let’s get some targets defined with input from the customers so we can use this in our upcoming Service Level Management program

Step 3:  Automate where possible to allow customers to perform self-help. 

This was probably the biggest eye opener for me.  My original plan was to shop for an integrated Service Management tool that offered workflow to support our self-service capabilities and replace our aging ticketing platform.  What I found was that we had an in house capability to build a catalog first, without a costly investment – it was SharePoint.  Lucky for us, we had a closet SharePoint expert on staff who led the charge here.

The plan was to build the catalog in SharePoint first to work out the bugs, then use that as a blueprint to launch the catalog into a newly selected integrated Service Management tool (I’ll explain more about selecting an integrated Service Management tool in a later blog).  This later proved to be a big success for us.

Besides launching a customer view of the catalog, building self-help capability to our portal was one of our most talked about capabilities (according to customer feedback).  Our users loved it!  Where did we start?  Moves – Adds – Changes.  Now, customers could request new user set up (or move, or retirement, etc.), by literally filling out an online form that triggered a series of work orders, all of which culminated in a successful transaction.  Of course, these had to be verified and approved by the appropriate managers.  If there’s one thing our team did to make the Service Catalog a success, it was adding self-help.

Some selected notes from this step:

002-illistration-workflow-Building-a-Service-Catalog

  • Get our BA’s involved, we want to make sure there is a process behind the tool (complete with requirements and use-cases)
  • Determine the right metrics and reporting functionality we need
  • Add the “technical view” to the catalog, information relevant to IT in supplying the services
  • Formally link this to the Request Fulfillment process

Step 4:  Continually improve, update and modify the catalog contents. 

It’s one thing to do a bottom-up approach like we did, but a complete new perspective to start looking at this is from the top down.  Our toughest challenge was to understand where these services really fit in the overall portfolio.  Some would criticize that we took the wrong approach, but considering the cultural and managerial aspects of this company (we had to move quickly), I feel we did it right.  In order to continually improve, we had to look at the overall structure, and how this fit into the organization.  Essentially, we built our portfolio from the bottom up.

This phase was iterative, and is still going on today.  Our plan was to essentially follow the Deming Approach (Plan, Do, Check, Act) to continually build on the early successes of the Service Catalog Deployment by making appropriate changes that add value to the customer, and make IT a part of the team, not just a group of tech-heads on the first floor.

Part of this phase was the selection and implementation of a full Service Management tool that allowed us to fully integrate and leverage all of our Service Management processes.

Finally, some selected notes from this phase.

003-illistration-pdc-workflow-Building-a-Service-Catalog

  • Measure, report and adjust the catalog (i.e. what self-services are customers using?)
  • Understand our capabilities then attack Service level Agreements (include OLAs and Underpinning contracts as well)
  • Build an IT Service Portfolio that includes services from the catalog, as well as those in the pipeline (we worked with the PMO to do this)
  • Continue to integrate processes, and conduct a successful tool implementation
  • In the future, look into how we identify and manage costs

Now, we had what we felt was a great foundation in place that we could continually update as services were added or changed.  This allowed us to move on to other key processes.  Next we’ll finish building our Service Catalog with Step 3 – Take Action. In this third and final blog of this series, I’ll outline what I feel were some of the most critical aspects of this project.

Mark Thomas – Director of Business Services
Interface Technical Training

The post ITIL – Building a Service Catalog in 4 steps, Part 2 of 3 appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-2-of-3/feed/ 1
ITIL – Building a Service Catalog in 4 steps, Part 1 of 3 https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-1-of-3/ https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-1-of-3/#comments Wed, 24 Jul 2013 15:20:05 +0000 http://www.interfacett.com/blogs/?p=?p=14322 The Service Catalog has, in the last few years, been one of the most popular starting points for most Service Management initiatives. For some companies, it is also one of the hardest things to do. A few years ago I was asked to run the Service Desk for a client on a temporary basis. It … Continue reading ITIL – Building a Service Catalog in 4 steps, Part 1 of 3

The post ITIL – Building a Service Catalog in 4 steps, Part 1 of 3 appeared first on Interface Technical Training.

]]>
The Service Catalog has, in the last few years, been one of the most popular starting points for most Service Management initiatives. For some companies, it is also one of the hardest things to do.

A few years ago I was asked to run the Service Desk for a client on a temporary basis. It turns out this presumably short gig became a 6 month long engagement. What I quickly discovered was this “Service Desk” had no defined processes, roles, service levels or even a list of basic services they provided to their customer groups. I’d love to give you a complete run-down of everything we did in the short six months I was there regarding the processes we launched, but with the buzz around service catalogs these days, I thought it best to start with telling you how we launched this company’s first.

What’s a Service Catalog?

You can find a lot of frameworks and models that outline what it is and how it fits, but I found the most comprehensive publicly available framework was ITIL®.  As one of the most valuable tools in your arsenal, the catalog should provide a single source of information pertaining to the operational services provided by the IT service provider. It should be easy to find, understandable, up to date, and available to authorized users and customers. I liken it to the three ring binder that sits on the nightstand in my hotel that tells me about room service, laundry service, how to get to the gym, shuttle service, wake up calls, etc. The IT service catalog essentially does the same thing.

In developing our first catalog, our methodology boiled down to four key steps as described below. There are many approaches depending on what you’re trying to accomplish, but considering the time, people and money we had available, it worked for us.

ITIL – Building a Service Catalog in 4 steps

Step 1: Get SOMETHING out there for my customers to see and use that is valuable.

There’s a lot of ways to approach this, but we determined our initial scope as the specific services that the service desk provided – not everything, just the popular services.  Since we were on a short timeline, our goal was to identify only a fraction of the services, but we wanted to make sure that those services on our first cut were meaningful and valuable. The popular service management books all said that I was supposed to do this in conjunction with customer input. We did this initially by looking at the last six months of tickets (calls to the desk) and quickly found out that the majority of what the customers needed from us were right there in the tickets. Remember, this was our first cut, so we didn’t want to overwhelm ourselves yet, so we didn’t worry about having multiple views at this point (i.e. customer view and technical view).

What we built was a simple taxonomy that outlined the key services in an organized and logical format (see below) that allowed customers to click on the service they needed information on. From there, they were taken to a detailed information page that outlined everything they needed to know on this initial site. So far, so good.

Our current ticketing tool did not have the capability to add a catalog. Our goal was to replace it in the future with an integrated Service Management tool, but that didn’t help us at this point. We decided to use what we had available with our SharePoint resources to launch this as one of the focal points of our IT portal.

SharePoint ITIL – Building a Service Catalog in 4 steps

Looking back at my notes, here are some comments that we made in various meetings during this step.

Illistration ITIL – Building a Service Catalog in 4 steps

  • We need to determine key roles: Who owns the actual catalog? Who owns the services?
  • Collect incident and request ticket information to build our initial taxonomy (we found that approximately 80% of the services we provided at the Service Desk were right in front of us in the past ticket logs)
  • Look at industry sites to see how they organized their catalogs (higher education sites have some good examples)
  • Make the first one a static catalog, we’ll add workflow later
  • Build this on a platform that we know how to manage (yes, we did this in SharePoint, and it worked beautifully)
  • Market the site through our business leadership and get it on our IT portal

Once we completed the launch of our initial service catalog, our next step was to refine, automate, and continually improve the site. Look for these in my next blog, Building a Service Catalog in 4 steps, Part 2 of 3.

Mark Thomas – Director of Business Services
Interface Technical Training

The post ITIL – Building a Service Catalog in 4 steps, Part 1 of 3 appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/itil-building-a-service-catalog-in-4-steps-part-1-of-3/feed/ 1
Video – What’s new in COBIT5? The benefits of Governance of Enterprise IT (GEIT) https://www.interfacett.com/blogs/video-whats-new-in-cobit5-the-benefits-of-governance-of-enterprise-of-it-geit/ https://www.interfacett.com/blogs/video-whats-new-in-cobit5-the-benefits-of-governance-of-enterprise-of-it-geit/#respond Wed, 17 Jul 2013 14:20:01 +0000 http://www.interfacett.com/blogs/?p=?p=14249 ITIL and COBIT instructor Mark Thomas discussed the new features of the latest release of COBIT5 by ISACA. COBIT 5 has new rich capabilities that are useful for organizations of all sizes. Some of these include: A new Expanded Goals Cascade that address Stakeholders needs and builds an end-to-end business perspective.  This helps satisfy objectives … Continue reading Video – What’s new in COBIT5? The benefits of Governance of Enterprise IT (GEIT)

The post Video – What’s new in COBIT5? The benefits of Governance of Enterprise IT (GEIT) appeared first on Interface Technical Training.

]]>

ITIL and COBIT instructor Mark Thomas discussed the new features of the latest release of COBIT5 by ISACA.

COBIT 5 has new rich capabilities that are useful for organizations of all sizes.
Some of these include:

  1. A new Expanded Goals Cascade that address Stakeholders needs and builds an end-to-end business perspective.  This helps satisfy objectives from a top-down approach from Stakeholder to process and enablers.
  2. Five new principles for the Governance of Enterprise IT (GEIT). These new principles drive the development of the governance framework of your organization.
  3. Seven Enablers that drive governance within an organization to help complete tasks. One of those enablers is processes.  There are 37 processes within 5 domains of the framework.  Unlike COBIT 4.1 (which had four process domains), the newest release adds a new Governance domain that helps distinguish between Governance and Management.
  4. The integration of ISO 15504 into the Process Capability Assessment. This new capability creates a more robust framework to better measures processes.
  5. An implementation guide that outlines the steps and perspectives in implementing a governance framework.

I hope this information is helpful. As always, please feel free to share your thoughts.

Mark Thomas – Director of Business Services
Interface Technical Training

The post Video – What’s new in COBIT5? The benefits of Governance of Enterprise IT (GEIT) appeared first on Interface Technical Training.

]]>
https://www.interfacett.com/blogs/video-whats-new-in-cobit5-the-benefits-of-governance-of-enterprise-of-it-geit/feed/ 0