Category Archives: P.M. Articles

Articles on Project Management and best practices.

Agile Certification Prep Notes

Origins of Agile: From Defense Contracting and Japanese Industry Evolution

Why Agile?

  • Differed change lists can be troublesome because they build up.
  • Locking the changes creates waste and devalues the project
  • Feature Driven Development as an agile approach can help resolve this problem.
  • Walter Schuhart: Continuous Improvement Cycle
    • Invented in the 1930’s: Plan Do Act Learn
  • Post WW2
    • US decimates Japan and uses them as a labour force
    • Japan suffers a number of setbacks over next 30 years with regards to manufacturing and quality and reacts by adopting new models – Schucart’s PDAL
    • Plan Do Act Learn -> Evolves into IID in 1950-70: Iterative Incremental Development
      1. Lean Software Development came from IID
      2. Critical Chain Methods: Eli Goldrath

IID is broken down into 5 unique models (Royce, 1970, Westcon).

  • Even Royce, the creator of the waterfall methodology is quoted as saying, “No significant project can be completed using this model”
  • He would say that the waterfall methodlogy can be effective it completed numerous times within a project lifecycle.

The first Agile Methods evolved out of IID during the early nineties.

  • RAD and DSDM (Rapid Application Development and Dynamic System Development Model)

 

 

Aligning Agile to Corporate Governance

CorpGovernance

Agile Requirements Gathering

  • Do detailed requirements AS LATE AS POSSIBLE
  • JIT documentation (Just In Time)
  • Requirements are documented in Backlogs
    • Project Backlog
      1. Is the Scope of the Project NOT THE PRODUCT BACKLOG
    • Product/Project Backlog
      1. Is not the scope of the project. There are things there that will not be implemented!
    • Sprint/Iteraton Backlog
      1. Contains tasks similar to the WBS

Agile Documentation

Reasons for Documentation

  • To clarify ideas
  • To communicate something to another person in another place
  • To communicate something to another person in the future
  • Stakeholders require it

Three Principles of Agile Documentation

  1. Don’t document if you don’t have to
    • Challenge the need to document
    • Estimate the cost of documentation and communicate it to the stakeholders
  1. Document as informally as is acceptable
    1. Think about the consumer first
      1. Information needs
      2. Familiarity with the content
      3. Level of expertise of subject
      4. Position within the organization
    2. Are there legal requirements?
    3. How informal is acceptable while satisfying requirements
  2. Procrastinate, procrastinate, procrastinate so you don’t document until you need to.

Early documentation in the project introduces risk

  • Not everyone is on the same page
  • As the project progresses there is more alignment of ideas

Variable Scope with Fixed Budgets and Schedule

Planning makes all the difference -> How you Plan not the amount of planning!

The best plans allow for what-if decisions.

Traditional planning fails in high change environments because…

  • Feature Usage Within Deployed Applications
    • *Statistics show that up to 50% of features are never used in the final output
    • Example: MS Excel has over 400 calculation features, but 99.9% only use the top 10.
  • Undesired or low value features create waste and are highly costly.
  • Traditional planning is based on tasks and do not leave room for lessons learned within the project plan
    • If you learn lessons during the project that tell you the tasks are no longer effective, then what?
    • Task-based plans get so complex they are difficult to update/change
    • Parkinsons’s law
      1. Tasks rarely get completed rarely
    • **Multi-tasking more than two tasks have been shown to decrease efficiency radically, by up to 50%
      1. Multi-tasking can cause risk in the project
    • A task that includes contingency rarely is finished early. The person doing the task soaks up all the contingency to do the task.
  • Delays in task completion roll apply the entire schedule
  • Features in traditional planning are not typically developed by priority

*Source: Chaos Report V3, www.standishgroup.com

**Source: K. Clark and S. Wheelwright, Managing New Product and Process Development: Text and Cases. The Free Press, 1993

 

Contracts: Fixed Price Variable Scope

  • Divide the product backlog on the must haves and nice to haves
    • Must have features are deep-dived and estimated, even managed using waterfall methods: Manadatory Scope with a defined budget.
    • Other items are Variable Scope
    • E.g. 1 year contract for $1.2 million
      1. Mandatory Scope is planned for 6 months
      2. Variable Scope is planned for 6, one month sprints and is based on the product backlog that has the story points assigned
        • At the beginning of each sprint, the client signs a work order for x number of story points
        • Team builds out the features based on priority
        • Client is allowed to trade out features at will as long as the story point count remains the same.
        • If they want more features than what is in 6 months, then sign another work order.

Change Control and Management

  • Formal change requests are required for…
    • Adding or removing an iteration
    • Changing resources/schedules/budgets/feature lists
    • Changes that change the business case objectives
    • Descoping
    • Usually a c.r. is generated at the end of an interation that includes all changes and an updated release plan.

Financial Tracking

  • Using velocity can be used in a similar way as Earned Value. The calculations are made differently but it provides the same kind of measurement

How to Plan Agile

  • The activity of planning is what is important, not the artifact that is the ‘project plan’
  • The Project Plan document is going t change, so design them so they can be updated easily and support change
  • Plan using a multi-diciplinary team
  • Plan throughout the project, not just at the beginning

Types of Agile Plans

  • Release Plan
    • High-level timing of deliverables used to communicate to Business Owners and the team.
    • Does not include any tasks whatsoever.
    • Does include timelines, number of sprints etc.
    • Includes estimates
  • Iteration Plans
    • Task based plan that includes tasks for the team. This is similar to a mini work breakdown structure that can be applied to a Sprint.
    • Includes estimates
  • Day Plans
    • Informal plan that is established during the morning SCRUM

Release Plans and Product Backlog Creation

  • Includes number of iterations and their start and end dates
  • Release start and end dates, and the features that are going to be in the iterations
  • Includes Milestones
  • Includes relationships with other projects
  • Includes initial stories and features for each release (not tasks)
  • How to:
    • Organize the Product Backlog into Releases
    • Lobby the sponsor to address higher risk features/stories first
    • Identify the non-functional requirements and add them to a constraints document
      1. Distribute some of the constraints throughout the Project Backlog in order to ensure checks and balances.
    • Get approval from the Sponsor
    • Estimate the project backlog using story points and include the people doing the work, don’t include people who are not involved in the work.
      1. Ideal Days
        • Estimates can be made using ideal days, but be careful there is no such thing as an ‘ideal day’
        • Estimating in days is slower
        • Estimating in days takes more analysis
        • Easier to explain to outsiders but there is a risk of comparing ideal days to calendar days.
        • My ideal day is different than another person’s perception of an ideal day.
      2. Story Points
        • A pure measure of size
        • Help drives cross-functional behavior
        • Faster than estimating ideal days
        • Estimates do not degrade over time
        • Allow people who are not doing the work to provide accurate assessments of the work
    • Complexity = Effort + Risk
      1. Add risk to the plan to identify: Targeted contingencies for known and identifiable risks
      2. Keep the original estimation excluding risk in order to remove it if the risk is eliminated

Iteration Planning and Team Velocity

  • New teams to agile require longer iterations
  • As the team gains experience, the iteration can be smaller
  • Iteration Lengths
    • Common iteration is 2-4 weeks
    • No magic number but consistency is important
    • Factors to consider include
      1. Nature of the work and the need for feedback
      2. Size of features
      3. Team experience level
      4. Available automation tools

Estimating Velocity

  • Velocity is the number of points per iteration that can be completed
    • Accuracy of velocity in planning stage is not as critical as consistency
    • Consistent estimates measuring velocity over the first few iterations will allow us to prepare a more reliable schedule
  • Simple Method (How many points can my team do during an iteration)
    • We know the iteration length: 2 weeks
    • We know the team: 4 full time equivalents
    • Steps
      1. Identify Capacity: (4 people X 10 days) X (8 hrs per day X 80% Efficiency)
        • = 250 hrs available in a two week sprint.
      2. Select a handful of backlog items that represent the range of work that is involved in the project.
        • Write down the backlog item numbers and have the b.a. do a deep dive into the requirements of the items in order to get a very granual estimate. Consider Design, Build, Test phases to get the total number of hours.
      3. Select the best combination of the estimated backlog items in order to fill the capacity that is available to the iteration (plus – minus 10%).
        • Try to get at least three stories
      4. Gather the story points for all of the backlog
        • Add the storypoints together in order to get the velocity
      5. Double check the math using iteration #1 as an example
        • The first iteration is always the most challenging, so the velocity may not match up. If it doesn’t match up, then you should break it into multiple sprints; choosing the best combination.
  • Advanced Method (In book) is used when you don’t know your resources yet.
    • Look at the most constrained resource role and follow steps 2 based on their capacity
      1. E.g. 50% of a designer

Schedule/Release Planning

  • Involve the team in the exercise
  • Once you have the velocity, you can carve out iterations from the project backlog
  • Always keep [at least] one iteration at the end so there is a buffer
  • Map the iterations out on a calendar and double check the storypoints per iterationm
    • If it is on a large calendar or whiteboard, you can write feature and storypoints on a sticky-note so it can easily be manipulated
  • Check resource calendars and adjust features and storypoints per iteration based on the vacation/holiday schedules of the team
  • Consider the dependencies
  • Identify milestones and then send the team home
  • Stakeholder Management
    • Involve the sponsor and other stakeholders to ratify the plan
    • They can move sticky notes into another iteration as long as they replace it with another one.

Lessons Learned

  • What did we do well?
  • How can we improve?
  • Where did we screw up?

Iteration Planning

  • Do a deep dive for requirements and testing for the first iteration during the release planning stage. This way, the developers can be coding and the q.a. and s.a. team can be working on the very next iteration.
  • This is helpful in siloed organizations that use distinct functional groups.
  • Apply a waterfall method within the sprint and define the critical path

Cost Planning

  • Once you know the cost of one iteration (as described in determining velocity) you can calculate the labour costs for the entire project

Exam Prep

Defined Processes:

  • Processes that we are very familiar with, highly effective if we know the requirements, goals etc.
  • Chances of success in high change projects is lower because of moving targets

Empirical: Less planning upfront, more frequent checkpoints and feedback so client/sponsor can direct the project to stay on target in the face of changing requirements.

Terminology

  • Project Backlog vs Product Backlog
    1. Product Backlog is the life plan of the product
    2. Project Backlog is the scope of a project

 

  • Backlog Grooming: The process of prioritizing the product backlog
    1. Columns:
      1. Business Priority (sponsor)
      2. Dependency (team)
      3. Estimates (team)
      4. Complexity (team)
  • Shadow Backlog: list of features that are not ready to estimate but prioritized, once estimated the feature will be added to the main Project Backlog
  • Defect Backlog: list of defects, once estimated and prioritized they move to the Project Backlog
  • Sprint Defect Backlog: Grows as the sprint’s defects are applied and then shrinks down to nothing as the sprint is completed. Any remaining defects get moved to the main defect backlog and may possibly be added to the project backlog.
  • Use Case: Defines a business need or problem
  • User Story: Describes a step in the solution to the problem
  • Feature: Describes a step in the solution to the problem
  • Technical Debt: A term that describes all of the deferred defects and items to refactor.

SCRUM:

At the end of each sprint:

  • Did we get it right?
  • Is this still what you need?

At the Beginning of each Day, SCRUM Meeting: Three Questions

  • What did you do yesterday / Were there any issue completing your work yesterday?
  • What are you doing today?
  • What are the barriers for this Iteration or the Project?
    1. Document issues in the issue log if they can’t be resolved immediately

Estimating:

  • Story points/Complexity Points
  • Ideal Days (a full one person day)

XTREME Programming: 12 Principles

Requirements Gathering   

What will you use to measure success of features? What is the definition of done?

Collective Ownership  Anyone can work on anything and update anything
Consistent Coding Standards  Tools can be used to enforce consistent standards
Refactoring Continuous refactoring until the code is released. Any can refactor anything.
Continuous Integration Enforces standards and alignment of varied development practices. Tools can be used to check-in, build and keep integration tight.
Commitments and Measurements involve the entire team The team succeeds as a team and is measured as a team. This enforces the
Design Metaphor The high-level design that is done in the planning phase of a project
Test Driven Development Developments write the unit test cases before building and define the definition of done
Paired Programming Almost eliminates the cost of change within a project.Best applied to the most critical areas of a project.
Customer tests the work
Small Releases Build small and often

 

FDD: Featured Driven Development

  1. Develop an overall model (requirements)
  2. Build a feature list (product backlog)
  3. Plan by feature (Business Case)
  4. Design/Build/Test by feature
  5. Iteration based: 2 weeks or less

DSDM: Dynamic Systems Development Method

  • High Level Requirements and Business Case
  • Ratify cases by prototyping
  • Build the rest
  • Deploy
  • Review

Lean – Principles

  1. Customer satisfaction is the highest priority
  2. Provide best value for money
  3. Active customer participation breeds success
  4. Every project is a team effort
  5. Everything is changeable
  6. Domain solutions, not point solutions
  7. Complete, do not construct
  8. 80% today instead of 100% tomorrow
  9. Minimalism is essential
  10. Let needs determine technology
  11. Product growth is feature growth, not size growth
  12. Never push Lean Development beyond its limits

For PMI-ACP Exam review the Lean Philosophy

Earned Value Management

  • SPI and CPI is used to determine EVM and this leads to being able to forecast budget and schedule early.
  • EVM is deterministic.

Storming Forming Norming and Performing – Performing should happen at 20% into the project.

PMI-ACP Exam Particulars:

  • Review XTreme programming
  • Review Lean theory and practice

Systems Development Approaches

Three step decision process to decide what type of methodology to use

  1. Do I need lots of feedback for success?
  2. What is the delivery strategy? Big bang or phased.
  3. Do I need enhanced quality or not?

 

  • Waterfall
    1. Low quality approach, requires a team with exceptionally high skill.
    2. Problematic because there is little opportunity for feedback
    3. A big bang approach because business value is delivered at the end.
  • Iterative (Feedback)
    1. A big bang approach
    2. Takes the whole solution and
    3. like waterfall but with additional points of feedback)
    4. Sooner opportunities for feedback
    5. Like waterfall but overlapping phases, still considered low quality with delayed testing to the end of the project.
    6. Design and Build can be done at the same time.
    7. User Centric Design in order to model the end result
    8. Delayed sign-off
    9. Stronger p.m. resources required. Higher complexity and risk than waterfall
  • Incremental (Prioritization)
    1. Prioritization to realize benefits sooner
    2. Often used in Program Approach
    3. Finish A before B, but when building B, test A.
    4. Four primary benefits
    5. Phased delivery of value: Faster ROI
    6. Potential to efficiently cut scope to save time and money
    7. Dramatically improved quality through continuous testing and regression testing
    8. Reduced Risk, “Early reduction of technical and design risk”
    9. Secondary Benefits
      1. Visibility in project status
      2. Resource leveling
      3. Moral is higher due to higher rewards through achieving success
  • IID/Agile (Iterative and Incremental)
    1. A lightweight version of IID

Agile Manifesto: 2001

IID becomes: Agile which has 4-5 guiding principles

  • Individuals and Interactions over Processes and Tools
    1. Good teams create good projects
  • Working software over Comprehensive Documentation
    1. How to measure success – customer focus
  • Customer Collaboration over Contract Negotiation
    1. Keep the relationship with the client
  • Responding to Change over Following a Plan
    1. There is no perfect plan, so don’t stick to it

That is, while there is value in the items on the right, we value the items on the left more.

 

Take-Aways

  • Concept fo Change Control (CCB) is false. Change Management is possible.
  • Bi-Modal I.T. (Gardner) states that companies need two models
    1. Waterfall or Agile
  • Agile Applications
    1. There are four significant models that can be applied.
  • Agile can proceed with a ROM Estimate but if a hard estimate is required then a waterfall method should be used.
  • Agile requires more planning hours that are spread across the lifespan of the project
  • Barry Banes: Cost of Change Curve:
    1. Agile testing budgets are higher but they save cost of change
    2. Reduces risk and provides higher quality
  • OpenUP: Free Agile Methodology. Eclipse.org
    1. CIBC methodology is based on OpenUP
  • SCRUM: Origins in 1986: “The New New Product Game”
    1. Harvard Business Review
    2. Extreme SCRUM on Amazon: Scaling Scrum to Enterprise level
      1. Using Scrum of Scrum

Adopting Agile: Stealth Methodology Adoption (Book by Kevin Aguanno)

  • Adopt techniques into your existing methods rather than adopting new methods
  • The way you describe them makes all the difference
  • Think of the techniques as tools you use to fix specific problems

ITIL Service Operations and Processes

Service Operation Lifecycle

Objectives

  • Explain the purpose, objectives, and scope of the service operation lifecycle stage
  • Explain the business value of service operation
  • Describe the basic concepts related to service operation
  • Explain the purpose, objectives scope, basic concepts, activities and interfaces for incident management and problem management
  • Describe the purpose, objectives, and scope for event management, request fulfillment, and access management

Service Operation

Purpose

  • Coordinate and carry out the activities and processes required to deliver and manage services at the agreed upon levels
  • Provide ongoing management of the technology that is used to deliver and support services

Objectives

  • Maintain business satisfaction and confidence
  • Provide effective delivery and support of agreed IT services
  • Minimize the impact of service outages on business activities
  • Ensure that access to services is provided only to those who are authorized

Scope

  • The service provided
  • Service management processes
  • Technology
  • People

Value

  • Provide operational data for use by other processes
  • Reduce unplanned labor and costs through optimized handling of service outages and identification of root causes
  • Meet the goals and objectives of the organizations security policy
  • Provide quick and effective access to standard services
  • Provide a basis for automated operations
  • Reduce duration and frequency of service disruptions

Basic Concepts

  • Importance of communication
    • Team and process communications should be supported by formal policy
    • Method and frequency of communication must be understood by all stakeholders
      • Clear purpose, audience, and required actions
      • Periodic review of communications practices

Processes and Functions

  • Processes:
    • Event Management
    • Incident Management
    • Problem Management
    • Request Fulfillment
    • Access management
  • Functions
    • Service Desk
    • Application Management
    • IT Operations Management
    • Technical management

 

 

Service Operation Process 1: Event Management

Purpose

  • Manage events throught heir lifecycle
  • Includes activities to detect events, make sense of them, and determine the appropriate response
  • Provide the basis for operational monitoring and controlCAn be used for automating normal operations as well as detecting early warnings and failures of CI

Objective

  • Detect all significant changes of state to Cis
  • Determine the appropriate control action (response)
  • Provide a trigger to initiate other operational processes
  • Provide means to compare actual performance against designs

Scope

  • Event management supports any service management aspect that needs to be controlled and can be automated
    • Cis – monitoring operational states
    • Cis – Automated updating of status
  • Environmental conditions
  • Software license monitoring
  • Security monitoring
  • Normal activities
  • MONITORING AND EVENT MANAGEMENT ARE RELATED BUT DIFFERENT!

Basic Concepts

  • Three types of events
    • Informational Events
      • Information that can be used for trending and analysis to inform service provider decision making
    • Warning Events
      • Early warning information that can often be leveraged to minimize or prevent any user or business impat
    • Exception Events
      • Abnormal situations or failures that require additional follow-up-actions

 

Service Operation Process 2: Incident Management

Purpose

  • Restore normal service operation as quickly as possible
  • Minimize the adverse impact on business operations
  • What is an incident?
    • Unplanned interruption to an IT service, or reduction in the quality of an IT service, or Failure of a CI that has not yet impacted a service.

Objectives

  • Ensure standardized methods and procedures are used
  • Increase visibility and communication of incidents
  • Enhance business perception of IT
  • Align activities to the priorities of the business
  • Maintain user satisfaction with IT service quality

Scope

  • In Scope
    • Any event that indicates a disruption to an IT service
    • Andy event that could disrupt an IT Service
  • Out of Scope
    • Informational events that indicatenormal service operation
    • Service requests

Basic Concepts

  • Incident Models and Timescales
    • Timescales:
      • Must be agreed for all incident handling stages
      • Will differ based on incident priority
      • Must be based on agreed response and resolution targets with SLAs
      • Captured as targets on OLAs and UCs as appropriate
      • Communicated to all support groups
      • Service management tools should be used to automate timescales based on predefined rules.
  • Incident Status Tracking
    • Incidents should be tracked throughout their lifecycle
    • Properly handled and escalated
    • Accurately reported incident status
    • Captured within the incident management system
  • Major Incidents
    • Incidents with the highest impact – significant business disruption
    • Must be clearly defined and mapped into incident prioritization scheme
  • Major incident procedure
    • Establish a separate team to manage major incidents
    • Led and managed by the incident manager
    • Focused on faster resolution and minimizing impact

Activities

  • Incident Identification
  • Incident logging
  • Incident categorization
  • Incident prioritization
    • Based on Impact and Urgency
  • Investigation and diagnosis
  • Resolution and Recovery
  • Incident Closure

Interfaces

  • Service Strategy
  • Service Design
    • Service level management
    • Information security management
    • Capacity management
    • Availability management
  • Service Transition
    • Service asset and configuration management
    • Change management
  • Service Operation
    • Problem Management
    • Access management
  • Continual Service Improvement

 

Service Operation Process 3: Problem Management

Purpose

  • Manage the lifecycle of all problems from identification ro removal
  • Understand, document, and communicate known errors and initiate actions to improve or correct the situation
  • Reactively minimize the adverse impacts of incidents and problems
  • Proactively prevent recurrence of incidents related to erros
  • What is a problem?
    • Underlying cause of one or more incidents

Objectives

  • Prevent problems and resulting incidents from happening
  • Eliminate recurring incidents
  • Minimize the impact of incidents that cannot be prevented

Scope

  • Problem Management is primarily within the scope of service operation
    • Proactive problem management supports CSI
    • Problems may be identified in transition activities
  • Reactive problem management
    • Resolves problems in response to specific incidents or events
  • Proactive problem management – triggered by Improvement Activities
    • Identifies and solves problems and known errors before the incident recurs
    • Is performed on an ongoing basis – reviewing and analyzing incident records and trends looking for signs of common causes that can be corrected
    • Conducts major incident reviews
    • Conducts reviews of operational and event logs to identify problems
    • Conducts brainstorms to identify problems
    • Uses check sheets to collect data related to problems

Basic concepts

Key definitions

  • Work Arounds
  • Known Errors
  • KEDB (Known Error Database)
  • Problem Models

Incident vs Problems

  • Incidents and Problems are not the same thing
    • Incidents don’t become problems
    • Incidents are the symptom, problems are the cause
  • Problem Management may be invoked when
    • Incidents can’t be matched to a problem or known error
    • Trend analysis reveals and underlying error
    • A major incident occurred
    • Other IT functions identify a problem
    • Anaysis by a support group reveals an underlying error
    • Notification from a supplier indicates a problem exists.

Activites

  • Reactive
    • Monitoring, reporting, triaging of problems
  • Proactive
    • Investigating historical data to discover root causes

Service Operation Process 4: Request Fulfillment

Purpose

  • Manage the lifecycle of requests from users

Objectives

  • Maintain customer and user satisfaction
  • Efficiently handle requests
  • Provide a channel for requests users and customers to make requests
  • Provide information about services to customers and users
  • Source and deliver the components of required services
  • Assist with informational requests, complaints, comments and compliments

Scope

  • Requests are normal everyday needs of users, customers, and service provider staff.
  • Sometimes handled through the incident management process and tools
    • Requests becomes a special category of incident
  • Sometimes handled through an independent request fulfillment process:
    • Appropriate for large numbers of requests
    • Separate record types to facilitate differentiated workflow and reporting

 

Service Operation Process 5: Access Management Process

Purpose

  • Provide rhe right for users to be able to use a service
  • Execute policies and actions defined in Information Security Management

Objective

  • Manage access to services based on policies and actions defined in information security management
  • Efficiently respond to access requests
  • Monitor access to services to ensure rights are not improperly used

Scope

In Scope

  • Protects confidentiality, integrity and availability of data and intellectual property by executing information security management policies
  • Ensures authorized users are given the rights to use services
  • Is performed across functions – likely with a single point of coordination

Out of Scope

  • Deciding who should have the right to use a service
  • Ensuring the availability of a service or data

Functions of Service Operation

Service Desk:

The single point of contact for users when there is a service disruption, for service requests, or even for some categories of request for change

Objectives

  • Provide a SPOC between users and the service provider
  • Return normal-state service operation to users as quickly as possible (incidents, service requests, and general inquireies)

Responsibilities

  • Logging incidents and service requests
  • Provideing first line response and diagnosis
  • Resolving incidents/requests at first contact when possible
  • Escalating incidents/requests they cannot resolve within agreed timeframes
  • Keeping users informed of incident/request progress
  • Closing all resolved incidents/requests
  • Conducting customer/user satisfaction surveys
  • Communication with users
  • Updating the CMS under direction and approval of SACM as agreed

Structures

  • Local
  • Centralized
  • Virtual
  • Follow the Sun: Location of service desk is moved to local the local working hours. E.g. 8 hrs in north America and 8 hrs in the Phillipines.
  • Specialized Groups

Technical Management:

Provides detailed technical skills and resources needed to support the ongoing operation of IT services and the management of IT infrastructure.

Objectives

  • Plan, implement, and maintain stable technical infrastructure
    • Well designed, resilient, cost effective technology
    • Adequate technical skills to maintain infrastructure
    • Swift use of technical skills to diagnose and resolve technical failures
  • Known as the Subject Matter Experts

Dual role of technical management

  • Knowledge and expertise to manage IT infrastructure
  • Provides the resources to support the service lifecycle
  • Provide balance between skill levels, utilizeation of resources and costs
    • Skills levels, Utilization and Costs of technical management staff
  • Provide guidance to IT operations on operational management of infrastructure
    • Design and documentation
    • Ongoing communication

IT Operations Management:

Executes the daily operational activities needed to manage IT services and the supporting IT infrastructure.

Objectives

  • Provides stability for daily processes and activities
  • Review and improve procedures and activities
  • Apply operational skills to diagnose operational failures that occure
  • Executes the ongoing activities and procedures required to maintain IT infrastructure

Plays a Dual Role

  • Maintain the status quo
  • Add value by contributing the reliability of services

Balances business and technical roles

  • Understanding how technology is used to provide services
  • Understanding the relative importance and impact of services offered

Contains two functions

  • IT Operations control
  • Facilities management

 

Application Management:

Is responsible for managing applications throughout their lifecycle.

Objectives

  • Support the organizations business processes
  • Identify functional and manageability requirements for applications
  • Assist in the design, deployment, and ongoing management of those applications

Practices

  • Well designed, resilient, cost effective applications
  • Ensure functionality supports business outcomes
  • Organization of adequate technical skills to maintain operational applicationsSwift use of technical skills to diagnose and resolve technical failures.

ITIL Service Transition and Processes

Service Transition Lifecycle

Purpose

  • Ensure that new, modified or retired services meet the expectations of the business

Objective

  • Plan and Manage changes efficiently and effectively
  • Manage risk related to new, changed or retired services (There is always risk)
  • Set performance expectations
  • Ensure changes create their intended value
  • Ensure knowledge transfer

Scope

  • Managing the complexity of change
  • Allowing for innovation while minimizing risk
  • Introducing new services
  • Providing a means to change existing services
  • Retiring undeeded services
  • Transferring Services to and from external service providers

Value

  • Enables estimation of cost, timing, resource, requirements and risk
  • Results in higher volumes of successful change
  • Enables sharing of transition assets and encourages reuse
  • Reduces delays from unexpected interactions
  • Reduces effort spent on managing test and pilot environments
  • Improves service expectations for all stakeholders

Processes

Service Transition processes covered by the ITIL Foundation

  • Transition planning and support
  • Service asset and configuration management
  • Change Management
  • Release and Deployment Management
  • Knowledge Management

Processes not covered by ITIL Foundation

  • Service validation and testing
  • Change evaluation

 

Service Transition Processes

Service Transition Process 1: Transition Planning and Support

Purpose

  • Provide overall planning for service transitions
  • Coordinate the resources that service transitions require

Objectives

  • Plan and coordinate transition resources
  • Establish new or changed services into supported environments
  • Establish new tools and technology
  • Ensure adoption of reusable processes
  • Provide clear and comprehensive plans
  • Identify, manage, and control risk
  • Monitor and improve the performance of service transition practices

Scope

  • Maintain policies and standards for service transition
  • Guide each major change through service transition processes
  • Coordinate multiple transitions
  • Prioritize conflicting requirements
  • Ensure service transition is coordinated with program and project management

 

Service Transition Process 2: Service Asset and configuration management

Purpose

  • Ensure assets required to deliver services are properly controlled
  • Ensure accurate and reliable information about service assts exists and is available when and where it is needed
  • Understand the relationship between service assts

Objectives

  • Ensure that assets are identified, controlled and managed
  • Identify, control, record, report and audit configuration items
  • Account for and protect the integrity of configuration items
  • Ensure the integrity of configurations required to control services
  • Maintain accurate configuration information
  • Support other service management processes

Scope

  • Manages the complete lifecycle of configuration items
  • Identifies, baselines, and maintains all configuration items
  • Interfaces with other service management processes
  • Interfaces with external service providers.

Basic Concepts

  • Configuration Items (Cis)
    • Any service asset or component that needs to be managed in order to deliver a service
    • Under the control of change management
    • Examples
      • Service lifecycle CI’s
      • Service Cis
      • Organization Cis
      • Intern/External/Interface Cis
    • Benefits of grouping items into a single CI must outweigh the effort to maintain it. Example: Desktop that includes laptop, monitor, keyboard etc.
  • Configuration Management System
    • The CMS is part of the SKMS
    • Configuration records are stored in CMDBs in the CMS
    • Some Cis (SLAs and Release Plans) are stored in the SKMIS
    • Other Cis (users and servers) are usually outside of the SKMIS
  • Definitive Media Library
    • Secure storage space for all media configuration items
    • Copies of perchased software, copies or software that was developed onsite
    • License information
    • Master copies of controlled documentation
    • Is part of the SKMIS

 

Service Transition Process 4: Change Management

Purpose

  • Control the lifecycle of all change
  • Enable beneficial changes
  • Minimize the discruption associated with changes

Objectives

  • Respond to changing business requirements
  • Maximize value while reducing disruption
  • Respond to business and IT requests for change
  • Ensure that changes are recorded and evaluated
  • Ensure that authorized changes are prioritized, planned, tested, implemented, documented, and reviewed in a controlled manner
  • Ensure that all changes are recorded in the CMS
  • Optimize overall business risk

Scope

  • Service solutions for new or changed services
  • Management information systems and tools
  • The service portfolio
  • Technology and management architectures
  • Service management processes
  • Measurement systems, methods and metrics
  • Out of Scope
    • Organizationally defined
    • Changes to business operations and policies
    • Some operational level changes

Basic Concepts

  • Change Proposal
  • Change
  • Types of Change
    • Standard: pre-authorized accepted procedure that are low risk and relatively common)
    • Normal: Non-emergency and not standard)
    • Emergency: Must be implemented in response to a disruption in service or a potential disruption to services.
  • CAB: Change Advisory Board – A group of people that advises the change manager in the assessment, prioritization, and scheduling of changes.
  • ECAB: Emergency Change Advisory Board – A subset of the change advisory board who make decisions about high-impact emergency changes.
  • Remediation Planning: Actions taken to recover after a failed change or release

Activities

  • Create and Record Request for Change
  • Review RFC
  • Assess and Evaluate the Change
  • Authorize Change Build and Test
  • Coordinate Change Build and Test
  • Authorize Change Deployment
  • Coordinate Change Deployment
  • Review and Close Change Record

Interfaces

  • Service Strategy
    • Service Portfolio Management
  • Service Design
    • IT Service Continuity Management
    • Capacity and demand management
    • Information security management
  • Service Transition
    • Service and configuration management
  • Service Operation
    • Problem Management
  • Continual Service Improvement

 

Service Transition Process 5: Release and Deployment Management

Purpose

  • Plan, Schedule, and control the build, test and deployment of releases
  • Deliver new functionality required by the business
  • Protect the integrity of existing services

Objectives

  • Define and agree release and deployment plans with customers
  • Create and test release packages
  • Ensure the integrity of release packages
  • Deploy release packages to the live environment
  • Ensure that all release packages can be tracked through their lifecycle
  • Ensure organization and stakeholder change are managed during deployment
  • Ensure required knowledge and skills are transferred to users, customers, and operation functions

Scope

  • All processes, systems and functions to package, build, test and deploy a release into live use as specified in the SDP
  • All configuration items required to implement a release
    • Physical assets
    • Virtual assets
    • Applications and software
    • User and staff training
    • Services, including contracts and agreements
  • Out of Scope
    • Authorization of changes

Basic Concepts

  • Release Policy
    • Unique identification of releases
  • Roles and responsibilities at each stage of the release
  • Requirement to use software assets from the DML
  • Expected frequency for each type of release
  • Approach for accepting and grouping changes into releases
  • How the configuration baseline is captured
  • Exit and entry criteria
  • Criteria to exit early life support

Activities

  • Authorize release plan
  • Authorize build and test
  • Authorize check-in to DML (Definitive Media Library)
  • Authorize deployment/transfer/retirement
  • Post implementation review

Service Transition Process 5: Knowledge Management

Purpose

  • Share perspectives, ideas, experience and information
  • Ensure information assets are available in the right place at the right time
  • Enable informed decision making
  • Reduce the need to rediscover knowledge

Objectives

  • Improve the quality of management decision making
  • Ensure reliable and secure knowledge is available throughout the lifecycle
  • Maintain an SKMIS (Service Knowledge Management System)
  • Gather, analyze, store and maintain knowledge.

Scope:

The entire SKMIS

Basic Concepts

 

ITIL Service Design and Processes

Service Design

Service Design Lifecycle Stage

Purpose

  • Realize Service Provider’s Strategy (from previous phase)
  • Design
    • IT Services
    • Practices and Processes
    • Policies
  • Cost effectively design new and changed services

Objectives

  • Effectively design IT Services
  • Minimize the need for improvement over the life of IT Services

Scope

  • Design of services to meet current and future business needs
  • Aligning IT solutions with business requirements
  • Includes
    • Functional requirements
    • Service level requirements
    • Business benefits
    • Overall design constraints

Value

  • Reduced total cost of ownership
  • Improved quality of service
  • Improve information and decision making
  • Improve IT governance
  • Improve alignment with customer values and strategies
  • Ease of implementation of new or changed services
  • Improve performance of services
  • Improve consistency of service

Basic Concepts

  • The 4 Ps: People Processes, Products (technologies) and Partners
  • Five Major Aspects of Design
  • Service Design Package
    • S.T.A.M.P.
    • Service Solutions
    • Tools and management information systems (Portfolio and Catalog)
    • Architecture and technology
    • Measurements and metrics
    • Processes
  • Service Design Package
    • Is produced during the design stage for each new service, major change to a service, or removal of a service
    • Is passed from service design to service transition
    • Is used by service transition to move a service through the stages of its lifecycle
    • Contains all of the information needed about a service at each stage in its lifecycle:
      • Requirements
      • Service Design
      • Organizational readiness assessment
      • Service lifecycle plan

Processes

  • Design Coordination
  • Service Catalog Management
  • Service level management
  • Supplier management
  • Availability management
  • Capacity management
  • IT Service continuity management
  • Information security management

 

Service Design Processes

Service Design Process 1: Design Coordination

Purpose

  • Design coordination provides a single point of coordination and control for the processes and activities within service design to product quality SDPs as agreed.

Objectives:

  • Ensure consistent design of appropriate services
  • Coordinate all design activities
  • Plan and coordinate resources and capabilities required to design new or changed services
  • Produce service design packages
  • Ensure that service design packages are handed over to service transition
  • Monitor and Improve effectiveness and efficiency of service design activities and processes
  • Ensure all parties adopt a standard framework or reusable design practices

Scope

  • Includes all design activity for new or changed services moving into or out of the production environment

Basic Concepts

  • Design coordination ensures creation of a service design package for new and changed services
  • Design coordination ensures handoff of service design packages to service transition.

Service Design Process 2: Service Catalog Management

Purpose

  • Provide and maintain a single source of information about operational services
    • Includes services that are being prepared to be run operationally
    • Ensure availability of the service catalog to those authorized to use it.

Objectives

  • Manage the information in the service catalog
  • Ensure accuracy of the service catalog
  • Ensure availability of the service catalog
  • Ensure the service catalog supports the evolving needs of the other service management processes – includes interface and dependency information.

Scope

  • Provide information about services that are operational or being transitioned into the operations environment
  • Contribute to the definition of services and service packages
  • Develop and maintain service and service package descriptions
  • Produce and maintain an accurate service catalog
  • Identify interfaces, dependencies and consistency between the service catalog and the overall service portfolio
  • Identify interfaces and dependencies between all services and supporting services within the service catalog and CMS

Basic Concepts

  • Two-View Service Catalog: Visualizes the customers and resources of an organization
  • Three-View (multi view) Service Catalog: An extension of the Two-View catalog that considers other organizations, markets or systems

Service Design Process 3: Service Level management

Purpose

  • Ensure all current and planned IT Services are delivered to agreed targets
  • Establish a constant cycle of negotiating, agreeing, monitoring, reporting and reviewing service level performance
  • initiate actions to correct or improve service levels

Objective

  • Define, document, agree, monitor, measure, report and review service performance
  • Initiate corrective measures as appropriate
  • Work with business relationship management to provide and improve the relationships with customers and the business
  • Ensure specific, measurable targets are negotiated for all services
  • Monitor and improve customer satisfaction with service quality
  • Establish clear and unambiguous expectations of service performance
  • Ensure targets that are met are evaluated for improvement opportunities

Scope

  • SLM and Business Relationship Management
    • SLM is focused on warranty and service levels delivered while business relationship management (strategic) is focused on utility
    • Interfaces between these two processes must be clearly defined
  • In Scope
    • Negotiating and agreement of current and future SLRs and targets
    • Documentation and management of SLAs of operational services
    • Document and management of OLAs for all operational services
    • Review of supplier agreements and UCs
    • Proactive actions to improve service levels delivered
    • Reporting of service level achievements
    • Identification of improvement actions
    • Reviewing and prioritizing improvements in the CSI register
  • Out of Scope
    • Negotiation and agreement of functionality or utility
    • Detailed service level work performed as part of other service management processes
    • Negotiation of contracts and underpinning agreements

 

Basic Concepts

  • SLM Related Agreements
    • Service level requirements (SLR)
    • Service level targets (SLT)
    • Types of agreements
      • Service Level Agreements (SLA)
      • Operational level agreements (OLA)
      • Underpinning contracts (UC)
  • SLA Structures
    • Multi-level: Includes customer service and corporate level agreements
      • 100 Services and 8 Customers and 2 Corporations
      • * standard sla’s and 2 special sla’s to address special needs of Corporations
    • Customer Level: One or more services appropriate to a single customer
      • 100 Services and 10 Customers
      • 10 SLAs (based on Customers)
    • Service Level: One per service for this customer or group of customers.
      • 100 Services and 10 Customers
      • 100 SLAs (based on Services)
  • The Relationship between BRM and SLM
    • Focusses on overall relationship between the customer and the service provider
    • Identifies customer needs and ensures the service provider can meet those needs
    • Service Level Management
      • Focusses on warranty-related aspects of the relationship
      • Ensures agreed and achievable level of service is provided.
      • This is all about negotiating the Warranty of the service
        • Capacity, Availability, Security, Continuity

 

 

 

Service Design Process 4: Supplier Management

Purpose

  • Obtain value for money from suppliers
  • Provide seamless quality of IT services to the business
  • Ensure all contracts and suppliers support the needs of the business
  • Ensure suppliers meet their contractual commitments

Objectives

  • Obtain value for money from suppliers and contracts
  • Ensure contracts are aligned to business needs and support SLRs and SLAs
  • Manage relationships with suppliers
  • Manager supplier performance
  • Negotiate and agree contracts with suppliers
  • Maintain a supplier policy
  • Maintain an SCMIS

Scope

  • Management of all suppliers and contracts
  • Adaptive based on importance of supplier
  • Supplier and contract evaluation
  • Development, negotiation, and agreement of contracts
  • Management of disputes
  • Management of subcontracted suppliers

Basic Concepts

  • Underpinning contracts
  • Supplier Categorizations
    • Commodity Suppliers
    • Operational Suppliers
    • Tactical Suppliers
    • Strategic Suppliers

 

Value and Importance High Operational Suppliers Strategic Suppliers
Med Tactical Suppliers
Low Commodity Suppliers Operational Suppliers
Low Med High
Risk and Impact

 

 

 

Service Design Process 5: Availability Management (part of warranty)

Purpose

  • Ensure that the level of availability plans delivered matches the agreed availability needs of the business
  • Meet current and future availability needs of the business

Objectives

  • Produce and maintain availability plans
  • Provide advice and guidance about availability issues
  • Ensure that service availability matches agreed targets
  • Assist with the diagnosis of availability-related problems and incidents
  • Assess the impact of changes on availability
  • Ensure that proactive measures are in place to improve availability

Scope:

  • Reactive Activities: Monitoring, measuring, analysis and management of all events, incidents and problems involving unavailability
  • Proactive Activities: These involve the proactive planning, design, and improvement of availability

Basic Concepts:

  • Principles
    • Component availability: Aspect of a specific element within a service
    • Service Availability: At the core of customer satisfaction and business success. It involves all aspects of service availability and unavailability
  • Aspects of Availability
    • Availability
      • Ability of an IT service or other configuration item to perform its agreed function when required.
    • Reliability
      • A measure of how long an IT service or other configuration item can perform its agreed function without interruption.
    • Maintainability
      • A measure of how quickly and effectively an IT service or toher configuration item can be restored to normal working after a failure.
    • Serviceability
      • The ability of a third-party supplier to meet the terms of its contract.
    • Vital business functions
      • Part of a business process that is critical to the success of the business.

 

 

Service Design Process 6: Capacity Management

Purpose

  • Ensure that the level of capacity delivered matches the agreed capacity needs of the business
  • Meet current and future capacity needs of the business

Objectives

  • Produce and maintain an up-to-date capacity plan
  • Provide advice and guidance about capacity-related issues
  • Ensure that service performance meets agreed targets
  • Assist with the diagnosis of capacity-related incidents
  • Assess the impact of all changes on capacity
  • Ensure the implementation of cost-justifiable proactive measures

Scope

  • Monitor patterns of business activity
  • Undertake tuning activities
  • Understand agreed current and future capacity needs of the business
  • Influence demand for services
  • Produce and update a capacity-related incident plan
  • Proactively improve service and component capacity

Basic Concepts

  • Business capacity management: The business capacity management sub-process translates business needs and plans into requirements for services and the IT infrastructure.
  • Service capacity management: The service capacity management sub-processes manages, controls, and predicts the overall end-to-end performance of operational services delivered by the service provider to its customers.
  • Component Capacity Management: the component capacity management sub processes manage, controls, and predicts the performance individual IT components in support services.

 

Service Design Process 7: IT Service Continuity Management

Purpose

  • Support the overall business continuity management process
  • Ensure that the service provider can deliver minimum agreed business continuity-related service levels.

Objectives

  • Produce and maintain a set of IT service continuity plans that support overall business continuity plans
    • Complete regular business impact analysis exercises
    • Conduct risk assessment and management activities
    • Ensure appropriate continuity mechanisms are put into place to meet or exceed business continuity requirements
    • Assess the impact of changes on continuity plans
    • Work with supplier management to negotiate for any necessary supplier recovery capabilities
  • Provide advice and guidance on continuity-related issues

Scope

  • Agree with the business the scope of continuity activities
  • Conduct business impact analysis activities
  • Conduct risk assessment and management activities
  • Produce an overall ITSCM strategy
  • Produce and ITSCM plan that is integrated with other continuity plans
  • Regularly test and improve continuity plans

Basic Concepts

  • Business impact analysis
  • Risk assessment

 

Service Design Process 8: Information Security Management

Purpose

  • Aligns IT security with business security
  • Ensure confidentiality, integrity and availability of assets, information, data and IT Services

Objectives

  • Ensure confidentiality of information
  • Ensure integrity of information
  • Ensure availability of information
  • Ensure the authenticity of business transactions and exchanges

Scope

  • Focal point for all IT security issues
  • Business security policy and plans
  • Current business operations and security requirements
  • Future business plans and requirements
  • Legislative and regulatory requirements
  • Security obligations within SLAs
  • Business and IT risks and their management

Basic Concepts

  • Plan
  • Implement
  • Maintain
  • Evaluate
  • Control

ITIL – Service Strategy Processes

Service Strategy Processes

Service Strategy Process 1: Service Portfolio Management

Purpose

    • Ensure clear definition of services that are linked to business outcomes
    • Ensure the service provider is offering the right mix of services
    • Track the investment in services throughout the service lifecycle to ensure desired returns are being achieved

Objectives

    • Provide a process to enable and support investigation and decision making on which services to provide
    • Maintain the definitive portfolio of services provided
    • Provide a mechanism for evaluation of how services enable achievement of strategic objectives
    • Control which services are offered, under what conditions, and at what level of investment
    • Track the service investment throughout the lifecycle
    • Analyze which services are no longer viable and should be considered for retirement

Scope

    • Scope of Service Portfolio Management
      • All services currently delivered
      • All services under consideration for delivery
      • All services that have been, or will be, withdrawn or retired

Basic Concepts

  • Service Pipeline
  • Service Catalog
  • Retired Services

 

 

Service Strategy Process 2: Business Relationship Management

Purpose

  • Establish and maintain the relationship between the service provider and the customer
  • Identify customer needs and ensure the service provider can meet those needs over time.

Objectives

  • Prioritize services based on understanding the customer’s needs
  • Ensure higher levels of customer satisfaction through meeting customer requirements
  • Identify potential impacts to services offered
    • Changes in customer environment
    • Technology trends
  • Establish business requirements for new or changed services
  • Work with customers to ensure services deliver value
  • Mediate conflicting requirements
  • Establish formal complaint and compliment processes

Scope

  • Because business relationship management is concerned with customer satisfaction, it…
    • Spans the entire service lifecycle
    • Depends on clear and understood relationships with other service management processes
  • Other processes are concerned with customer satisfaction; they are just focused on more specific process activities and actions
    • Key example: Business relationship management and SLM

Basic Concepts

  • Formal procedures for handling complaints and compliments
    • Log and route appropriately
    • Ensure follow up actions are taken as necessary
    • Ensure response to customer

 

 

Service Strategy Process 3: Financial Management for IT Services Process

Purpose

  • Secure appropriate funding to design, develop, and deliver services that meet the strategy of the organization
  • Ensure the service provider does not commit to deliver services it is not able to provide
  • Identify the balance between cost and value
  • Maintain the balance between supply and demand

Objectives

  • Define and maintain a framework to identify, manage, communicate and optionally recover the costs of providing services
  • Secure funding to manage the provision of services
  • Evaluate the financial impact of new or changed strategies
  • Facilitate good stewardship of customer and service assets
  • Manage and report on expenditures related to the provision of services
  • Execute and adhere to organizational financial management policies
  • Account for the money spent on the delivery of services and forecast the financial requirements needed to continue to meet commitments

Scope

  • Alignment with organizational financial management practices
  • Requires specialization in finance and IT
  • Main processes
    • Accounting
    • Budgeting
    • Charging

Basic Concepts

  • Justification for significant item or expense using a business case
    • A good business case has five main sections
      • Introduction
      • Methods and assumptions
      • Business impacts
      • Risks and contingencies
      • Recommendations

ITIL Lifecycle: Service Strategy

ITIL Lifecycle: Service Strategy

Purpose:

The purpose of the service strategy lifecycle is to define the perspective, position, plans and patterns that a service provider needs to be able to execute to meet an organization’s business outcomes.

Objectives

  • Establish an understanding of strategy
  • Clearly identify and define services
  • Define how value is created and delivered
  • Articulate how services are delivered and funded
  • Establish a clear model for provisioning services
  • Document and coordinate how service assets are used to deliver services

Scope

  • Includes generic service management principles and processes
  • Applies to internal and external service providers
  • Two aspects covered by a service strategy:
    • Defining a strategy to guide how a service provider meets business outcomes
    • Defining a strategy for how to manage services

Value

  • Links service provider activities with critical business outcomes
  • Enables clear understanding of the services desired by the business
  • Supports flexibility in response to the changing business environment
  • Quantifies services through a profolio
  • Facilitates communication between the service provider and its customers
  • Aids in effective service provider organization

Basic Concepts

Outcomes

  • The result of carrying out an activity, following a process or delivering a service
  • Includes intended and actual results
  • Customers seek outcomes without ownership of associated costs and risks

Types of Services

  • Core: Basic functionality
  • Enabling: Provide access to core services
  • Enhancing: Provide differentiation

Value Creation through Services

  • Business outcomes
  • Preferences
  • Perceptions
  • Establish a baseline (current state) and add Utility and Warranty in order to create Value.

Risk Management

  • Identify and Control Risks

Governance

  • Is a single overarching area that ties IT and the business together.
  • Defines common directions, policies and rules that both the business and IT use
  • Applies a consistently managed approach throughout the organization

Service Automation

  • Process and Tools must be in place prior to automation
  • Benefits
    • Imrpoves utility and warranty of a service
    • Imrpoves management of capacity
  • Areas
    • Design and modeling
    • Service catalog
    • Pattern recognition and analysis
    • Classification, prioritization and routing
    • Detection and Monitoring

Service Strategy Processes

  • Service Strategy Processes covered on the ITL Foundation syllabus
    • Service portfolio management
    • Business relationship management
    • Financial management for IT Services
  • Service Strategy Processes not covered on the ITIL Foundation Syllabus
    • Demand Management (output is Pattern and Business Activity)
    • Strategy management for IT Services

How does ITIL Support the Delivery of a Service

How does ITIL Support the Delivery of a Service

ITIL History:

  • UK government was seeking a way to deliver services and sought input from a number of vendors.
  • They recognized the similarities between vendors
  • ITIL V1 was the consolidated view of these practices
    • 40 processes
  • 2001: U.S. refines the approach in 2001: ITIL V2 is born
    • 10 processes and 1 function
  • 2007: May 31, 2007 ITIL V3 is born
    • Focused on delivering services as a part of a lifecycle
    • Repeatable, continual growth based on 5 stages
      1. Service Strategy
      2. Service Design
      3. Service Transition
      4. Service Operations
      5. Continual Service Improvement
  • 2011: 5 Core books are republished, and the ITIL framework is updated
    • ITIL has now dropped the version number, and as such is referenced by year – not version number.
    • In 2011 additional processes were introduced.
    • ITIL has been established for over 10 years.

Best Practices

  • IT service organizations are constantly challenged to improve their ability to deliver quality services at prices customers can afford.
  • Best practices are developed and often shared.
    • Public frameworks
    • Examples: ITIL, PMBOK, Six Sigma
  • ITIL is not a standard.
  • Businesses have proprietary knowledge. ITIL can contribute to proprietary knowledge.
    • Often embedded within the organization
    • Difficult to duplicate
    • Usually undocumented
    • Customized for specific needs
    • May require purchasing or licensing
  • Public Frameworks
    • Validation can occur across a diverse set of environments
    • Broad reviews can be conducted across organizations
    • Knowledge is more widely distributed
    • Training and certification is often available
  • Sources of best practices
    • They are no good unless you can leverage an enabling activity
    • Usually it is people who enable a best practice
    • ITIL is all about adapt and adopt – through the use of enabling.
      1. Sources (Generate)
      2. Drivers (Filter)
      3. Enablers (Aggregate)
      4. Scenarios (Filters)

 

Challenges of IT Service Management

Common Challenges

  • Organizational capabilities are developed to overcome challenges
  • Services are intangible and difficult to measure, control, and validate
  • Demand is tightly coupled with customer assets
  • There is little or no buffer between the service provider and the customer
  • Service output and service capacity have perishable natur

How Are Services Delivered

howAreServicesDelivered

  • Assets (Resources and Capabilities) See Above
  • Processes
    • Characteristics of Processes
      • Measurable
      • Delivers specific results
      • Value to customers and stakeholders
      • Responsiveness to specific triggers
  • Functions
    • Service Desk: Is the single point of contact for users when there is a service disruption, a service request, or even some categories of requests for change.
    • Technical Management
    • IT Operations Management
    • Application Management

Process Roles

  • Owner (Process)
    • Being accountable for the process meeting stakeholder and business objectives
    • Defining the process strategy and assisting with the process design
    • Sponsoring, designing, and managing process changes and improvements
    • Ensuring the appropriate levels of documentation and communication
    • Periodically reviewing and auditing process compliance and performance
    • Addressing process related issues and reviewing opportunities for process improvements
    • Ensuring process resources have required knowledge to perform activities
    • Periodically review process trategy
  • Manager
  • Responsible for operational management of the process
  • Working with the process owner to coordinagte all process activities
  • Ensuring activities are carried out as required
  • Appointing resources to the required roles and managing process resources
  • Working with service owners and other process managers
  • Identifying process improvement opportunities for inclusion in the CSI register
  • Working with the process owner and CSI manager to prioritize process improvements
  • Making improvements to the process implementation
  • Practitioner
  • Carry out one or more process activities
  • Understanding how the role contributes to the delivery of services and value creation
  • Working with process stakeholders to ensure their contributions are effective
  • Ensure process inputs, outputs and interfaces for their activities are correct
  • Creating or updating records related to the activities performed
  • Service Owner
  • Being the single point of accountability for the delivery of a specific service
  • Representing the service across the organization
  • Ensuring that the ongoing service delivery and support meets agreed customer requirements
  • Working with business relationship management to understand customer requirements
  • Ensuring consistent and appropriate communication with customers
  • Assiting in defining service models
  • Assisting in the assessment of proposed changes and improvements to the service
  • Identify service improvement opportunities and discuss these with the customer
  • Liaising with process owners as necessary to ensure IT processes are effectively supporting the service.