What is ITIL & Why ITIL Important For You - With All Insights

Lets Start with Introduction to ITIL

ITIL stands for IT Infrastructure Library

Initiated by UK Government - the CCTA now OGC

◈ (CCTA – Central Computer and Telecommunications Agency)
◈ (OGC – Office of Government Commerce)

Major contributors

◈ The private sector - Inputs are taken from various organizations to develop ITIL
◈ IT Service Management Forum - International Not for Profit promoter

Major Examination Bodies - Peoplecert.

What is ITIL and what does ITIL stand for? Information Technology Infrastructure Library or more commonly referred to as ITIL comprises of the practices need to for IT Service Management or ITSM. Now, your next question-

Why use ITIL Methodology?

It has turned out to be progressively perceived that data is the most essential key asset that any association needs to oversee. Key to the gathering, examination, generation and appropriation of data inside an association is the nature of the IT Services gave to the business.

It is basic that we perceive that IT Services are significant, key, authoritative resources and in this manner associations must put proper levels of asset into the help, conveyance and management of these basic IT Services and the IT frameworks that support them. Notwithstanding, these parts of IT are frequently neglected or just externally tended to inside numerous associations.

Confusion between ITSM & ITIL:

Newcomers or knowledge seekers many times confuse between ITSM and ITIL let’s roll out this confusion from your mind before you can read more o ITIL:

◈ ITSM: ITSM is an acronym for Information Technology Service Management, it’s simply how you manage the information systems that create and deliver value to customers.
◈ ITIL: ITIL (Information Technology Infrastructure Library) is the most recognized and used framework for ITSM.

The challenges we faced in IT Operation

Because of following challenges in current IT operation everybody moving towards ITIL Methodology

◈ Not meeting SLA
◈ Frequent Major Incidents
◈ Constant Fire-fighting
◈ Infrastructure not capable of absorbing new changes
◈ Unplanned Outages/Security Incidents (Major virus attack)
◈ Process failures
◈ Infrastructure not capable of handling load at peak hours
◈ Unavailability of key business application
◈ Unable to measure the performance of services/process
◈ The team working of trial & error method
◈ Lack of Governance structure

Why is service Management important for IT?

◈ IT becomes increasingly crucial for business
◈ Downtime on IT causes huge business losses (e.g. Users rush to bank branches when ATM was unable to dispense cash.
◈ Organizations want to move towards ZDT (Zero Down Time) for crucial services.
◈ Most of the businesses are going e-way

Why is ITIL so successful?

1. Vendor-neutral

Vendor neutrality is a business and design approach that aims to ensure broad compatibility and interchangeability of products and technologies.

2. Non-prescriptive

ITIL offers strong, develop and time-tried practices that have pertinence to a wide range of service association. It keeps on being helpful and significant in broad daylight and private areas, inward and outside service suppliers, little, medium and huge ventures, and inside any specialized condition.

3. Best practice

ITIL speaks to the learning encounters and thought the authority of the world's best-in-class specialist co-ops.

What is the meaning of Service in ITIL?

The DevOps Foundation certification provides an introduction to DevOps, this course reduce stresses in communication, collaboration, integration, and automation in order to improve the flow of work between software developers and IT operations professionals.

Types of Services:

1. Core Services:
These Services represent the value that customer wants and for which they are willing to pay.

2. Enabling Services:
These are the services which may or may not be visible to the customer.

3. Enhancing Services:
Enhancing services are not essential to the delivery of a core service, and are added to a core service as 'xcitement' factors, which will encourage customers to use the core service more.

What is the meaning of Service Asset in ITIL?

Service asset means resources and capabilities used by a service provider to provide service to the customer.

What is the meaning of Service Management in ITIL?

It is a set of specialized organizational capabilities for providing value to the customer in the form of services.

What is Value in ITIL?

The basic definition of value is like Value means the product or service which fulfills the customer’s needs and wants.

In ITIL value means

VALUE = Utility + Warranty 1. Utility - Fit for Purpose 2. Warranty - Fit for use

What is Process in ITIL?

The process is organized sets of activities design to achieve a specific objective.

What is ITIL Incident management?

Incident management means an unplanned event in the process which leads to disruptions of the process.

For better understanding let’s discuss an example suppose in an organization on working hours a hardware went off and it leads to disruptions of service. That’s called an incident but in case a hardware failure has occurred in non-working hours that means no disruption of service, that does not mean it’s an incident.

What is ITIL Event Management?

In ITIL event management is defined as the process that manages IT-related all events that occur through IT infrastructure. An event means notification created by IT service, config team or monitoring tool and the whole purpose of event management is to detect events, inspect and roll out right control action.

What is ITIL Problem Management?

Problem Management means the root cause of the event which leads to disruption of service.Many people think that incident management and problem management are same, but it’s the opposite of the same. Incident means event and problem means root cause of the event. On the part of discussing example, the root cause of hardware failure is the problem.

Do you Know ITIL Framework is Updating in 2018?

In the itSMF USA Fusion 2017 conference held in the USA, Axelos announced that they are updating ITIL but there’s no need to worry who have already certified because they will have their current certifications recognized in the new scheme.

What we know till now about ITIL Update 2018:

The core elements of ITIL will remain and will continue to derive from the experiences of thousands of specialists and experts. Research has confirmed that ITIL remains best practice for the ITSM industry.

The update will include practical guidance on how ITIL is adopted in conjunction with practices such as DevOps, Agile and Lean.

Short Review of what Peter Hep-worth announced in Conference:

AXELOS's broad research among the worldwide administration network has demonstrated that ITIL's demonstrated and tried system remains the foundation of the present business hones, significantly encouraging business change. Over a million IT experts in the US depend on ITIL's best practice direction to convey business achievement, and every year associations put generously in embracing ITIL, adjusting it to their requirements, and up-skilling their kin with ITIL capabilities. As an impression of this, the update will keep on including the generally received center standards of ITIL, which as of now convey genuine incentive to associations around the world.

Adaptability and deftness have turned into a need as of late as associations embrace new advancements and methods for working, for example, cloud, expanded levels of robotization and computerized change. That dynamic is behind the ITIL update: it will guarantee that the world's ITSM experts can unquestionably coordinate their basic ITIL learning with these new business rehearses.

ITIL Certification Levels

1. ITIL Foundation Level:

The Foundation level is the section level affirmation which offers you a general familiarity with the key components, ideas and phrasing utilized as a part of the ITIL service lifecycle, including the connections between lifecycle stages, the procedures utilized and their commitment to service management rehearses.

2. ITIL Practitioner Level:

The Practitioner level is the following stage in the ITIL plot. It has been produced to give a stage amongst Foundation and the Intermediate Level and means to enhance the capacity of people to receive and adjust ITIL in their associations.

3. ITIL Intermediate Level:

The Intermediate level accreditation has a secluded structure with every module giving an alternate spotlight on IT Service Management. You can take as few or the same number of Intermediate capabilities as you require. The Intermediate modules broadly expound than the Foundation level and Practitioner and give an industry-perceived capability.

4. ITIL Expert Level:

The ITIL Expert level capability is gone for the individuals who are keen on showing information about on ITIL Scheme completely. The endorsement is granted to applicants who have accomplished a scope of ITIL affirmations and have achieved a balanced, unrivaled learning and abilities base in ITIL Best Practices.

5. ITIL Master Level:

To accomplish the ITIL Master confirmation, you should have the capacity to clarify and legitimize how you have by and by chosen and connected a scope of learning, standards, strategies and systems from ITIL and supporting administration procedures, to accomplish wanted business results in at least one functional assignment.

Major Topics covered in ITIL Certification:

1. Service Lifecycle

2. Service strategy:

Service strategy is the origin or we can say center point of ITIL service lifecycle, which provides guidance to the service provider about its investments in services. Service strategy strongly relies on market approach and it helps IT organization to improve and enhance for the long term.

3. Service design:

Service Design is the acts of arranging and sorting out individuals, foundation, correspondence and material segments of service with a specific end goal to enhance its quality.

4. Service Transition

Service transition creates and maintains coordination between services and service management process and the whole objective of Service Transition is to build and deploy IT services.

5. Service Operation:

The Service operation means lifecycle stage including satisfying user requests, settling service failures, fixing problems and carry out the routine operational task.

6. Continual Service Improvement:

The main function of ITIL CSI is to align and re-align the IT services according to the changing business needs and recognize the opportunities to improve the IT services and implementation of it.

Who should go for ITIL certification?

IT professionals

Business managers

Business process owners

Database Administrators

Delivery Professionals

IT Maintenance

Software Testers

ITIL V3 Qualification Scheme:

Cost of ITIL Certification in India:

ITIL Foundation- Rs. 19,500

ITIL Intermediate Level - Rs. 29,500

ITIL Practitioner - Rs. 29,500

ITIL Expert - Rs. 29,500

( All the above cost are standard prices, you can get the discounted pricing by reaching us )

What salary do you get if you have ITIL Certification?

Top 10 Benefits of ITIL Certification

Organizational Benefits of ITIL Implementation:

Improve resource utilization

Be more competitive

Decrease Rework

Eliminate redundant work

Improve upon project deliverables and time

Improve availability, reliability and security of mission-critical IT services

Justify the cost of service quality

Provide services that meet business, customer and user demands

Integrate central processes

Document and communicate roles and responsibilities in service provision

Learn from previous experience

Provide demonstrable performance indicators

Benefits of ITIL Certification for Individuals:

1. Expertise Recognition:

Once ITIL course and certification added to your skills, then you are perceived for the ability and aptitudes in dealing with the administrations in your association. Both your senior initiative in the association and your partners would value your capacity to deal with the administrations and procedures successfully.

2. Acknowledge Common Terminology:

Since ITIL course gives knowledge into the ITIL structure, you could become more acquainted with the wording that is normal crosswise over businesses and nations. Along these lines, you talk a typical dialect with an assortment of clients.

3. Comprehensive View:

With the ITIL course, you become more acquainted with the fitment of business with IT administration and foundation. Along these lines, you get the chance to comprehend the 10,000ft view and subsequently make a significant commitment to the association which thusly makes you a much looked for after representative in the organization.

4. Better Monetary Returns:

After you have gone to the ITIL course, If you have finished the certification as well, you have better occupation prospects. Contrasted with other non-guaranteed hopefuls, you have an edge in the ITSM circle. In addition, as an affirmed ITIL proficient, your compensation scale likewise gets a generous hop.

5. Better Productivity:

It teaches you the best practices on how to increase the business productivity effective by using best practices under ITIL Methodologies.

6. Value-Based Working Approach:

Help professionals to work purely focused on the needs of the customer and user experience because in conventional method all the force was used to solve the technical issues.

7. Increase your standing in an Organization:

Globally certified with upgraded managerial and technical skills will ultimately be reflected in your performance and result will you will stand out from rest of your peers.

8. Think Out of the Box:

The ITIL preparing plan urges individuals to consider better approaches for working and methodologies for enhancing consumer loyalty. ITIL is intended to enable everybody to concentrate on the requirements of the clients and client to encounter as opposed to focusing a lot on the innovation issues while drawing in with clients

9. Build Trust:

Maintaining better service management helps people to concentrate more on what customer needs and delivering the business outcomes.

10. Low-Risk Effort:

Ordinarily, in your career, it can be something to be thankful for to make a stride back and re-assess some of your objectives and current endeavors to check whether you have to settle on any moves or choices that will influence you in the long term. Speculations, like going for a Master's degree or getting an accreditation, can be unnerving, in light of the fact that you frequently simply don't know whether you hazard sitting idle and exertion on something that may not be all the useful to you in the long-keep running of your expert profession.

Continue reading

Use a Modified FMEA to Mitigate Project Risks

Every project faces a number of elements that risk its success. For instance, a lack of team-member availability, qualified resources, customer information, data, proven technologies, a clear scope – or deficiencies in a number of these areas – represents a risk.

To prevent risks like these from happening, or at least to be prepared when they occur, project leaders and other team members should assess the key risks of any project and determine how they can be addressed.

One format and approach frequently used to complete this risk management is a “light” version of the common failure mode and effects analysis (FMEA). These four steps cover how to create a risk-mitigation plan.

Step 1: Brainstorm Potential Project Risks and Potential Causes

In a meeting early in the process, the project team brainstorms and records potential risks. The leader guides this session with questions such as, “What can go wrong?” or “What might prevent this project from being successful?” These risks are recorded in a modified version of the FMEA (Figure 1).

Concerns from team members or other stakeholders also can be managed as risks. For example, if someone says, “We have tried to work on this issue before,” then the risk “solutions cannot be found” can be included in the project FMEA. This shows that the team members’ concerns are taken seriously.

For each risk, the DMAIC (Define, Measure, Analyze, Improve, Control) phase during which it is most likely to occur is identified. Risks that are not specific to a phase can be assigned to the category “General.”

The team also identifies potential causes for each risk. This will help to better determine corrective or preventive actions during Step 3.

Figure 1: “Light” Version of FMEA Risk Mitigation Plan

Step 2: Rate Potential Risks

Next, the team rates each risk according to its probability of occurrence and its impact on the project using the following categories: 

1 = low probability of occurrence, low impact on the project

2 = medium probability of occurrence, medium impact on the project

3 = high probability of occurrence, high impact on the project

The team discusses each risk until they reach consensus on its rating. Just because someone thinks a risk is a low probability (1), and another person assumes a high probability of occurrence (3), it is not correct to assign it a 2. 

Step 3: Prioritize Risks and Define Mitigation Actions

Team members prioritize potential risks by calculating the product of the probability of occurrence and the impact on the project. They can create a traffic light scale to indicate which risks warrant mitigation actions and at what priority (Figure 2). The matrix will not be symmetrical because high-impact risks are considered more critical than risks with a high probability of occurring.

Figure 2: Risk Categorization Matrix

The team designs a plan for each risk in the yellow and red zones, including actions required to mitigate the risk, who is accountable and a due date. 

Team members should always double check whether the actions are truly actionable and will really help to mitigate the impact or the probability of occurrence of the risk. In the best case, actions fully eliminate the risk. Second best are actions that reduce the probability of occurrence, while the third-best option is to define counter measures that work as a fall-back plan (i.e., if the team cannot prevent a risk from happening, they should still know what to do if it occurs). 

Step 4: Continuously Update and Review Project-FMEA

Assessing risk is not a one-off activity. As the project moves forward, the team continuously updates the project FMEA and checks off the completion status of mitigation actions. An example of a chart at this stage is shown in Figure 3.

Figure 3: Extract from Sample Project FMEA

The team assesses a new probability of occurrence for those risks that are adequately mitigated. Based on this rating, they can calculate and record a new risk status. The team also continues to identify new risks and addresses them as they arise. Deciding how and when new risks are to be addressed is best done during weekly status meetings.

Continue reading

The Difference Between a Project and a Programme

Many believe a programme is simply a larger, longer version of a project. Despite the similarities, they are actually quite different. Briefly, a project is a specific, single task that delivers a tangible output, while a programme is a collection of related projects.

Definition of a project

PRINCE2 defines a project as “a temporary organisation that is created for the purpose of delivering one or more business products according to a specified business case”.

Projects have an end and aren’t designed to last very long. The project manager ensures the project delivers the intended goal, within a defined timeframe and budget.

Definition of a programme

A programme is defined as “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually”.

Programmes are usually long term, sometimes spanning years, and don’t have a fixed deadline. A programme is a framework of related projects aligned in a specific sequence. They have predictable and repeatable elements to minimise or even eliminate risks.

Project and programme key differences

Comparison	Project	Programme
Focus	Content	Context
Scope	Well-defined, limited to an output	Broad and adjustable
Timeframe	Short term	Long term
Components	Small tasks	Projects
Functional units	Single	Multiple
Tasks	Technical	Strategic
Produces	Output	Outcome
Deadlines	Strict	Flexible
Designers	Mid-level staff	Top-level staff
Success	Product quality, timeliness, cost-effectiveness, compliance, and customer satisfaction	Long-term benefits to the organization, ROI or new capabilities

Project vs programme example

Let’s say a company wants to build and market a new mobile phone. This programme would be a collection of different projects, like one for updating the operating system and another for sourcing the resources and raw materials, along with the legal, business and support elements. Programme management would manage the dependencies, so each project gets what it needs.

Project and programme similarities

It’s good for project and programme managers to understand the challenges each has to deal with, as both projects and programmes:

◈ Are temporary

◈ Use business cases

◈ Require a team

◈ Are aligned to strategic objectives

◈ Deliver change

Project managers vs programme managers

Project managers focus on the project’s deliverables, making sure the project reaches its intended outcome on time and within the budget.

Programme managers are usually less hands-on, but must view the bigger picture and visualise the benefits that individual projects will have on the whole programme.

Comparison	Project manager	Programme manager
Role	Monitor and control project tasks	Monitor and control projects
Focus	The project staff, i.e. technicians and specialists	Managing relationships with project managers and their teams, freeing up resources and resolving conflicts
Who they manage	The project team	Other managers
Planning level	Creates a detailed project plan for the resources, cost, timeliness, and delivery	Creates high-level plans used by the project managers both as a guide and to develop the detailed plans

The biggest difference is that projects deal with delivering strictly defined outputs within a specific timescale and budget, whereas programmes deal with delivering outputs that benefit the entire organisation. Put simply, projects involve ‘doings things right’ and programmes involve ‘doing the right things’. Similar phrases, but very different meanings.

Continue reading

Build a Visual Dashboard in 10 Steps

Three years into the Lean Six Sigma deployment at Ball Corporation (the company known for its glass canning jars), the process improvement team began a visual factory initiative. This initiative was intended to develop visual signs on plant floors that not only instruct employees about where to focus their energies, but also depict the health of the company. These visual cues would be the driving force behind Yellow, Green and Black Belt projects. They should not only point to improvement opportunities but also highlight the success of completed improvements. Armed with an idea to build the ultimate dashboard, the team began.

Step 1: Ask Questions

Some questions that were asked and heard:

◈ What should the dashboard look like?

◈ How many metrics should the dashboard have?

◈ How can the data be presented in a way that can be easily tailored to different levels in the organization?

◈ Who will use the dashboard?

Step 2: Tool Selection

Lean is not about spending a lot of time and money implementing new systems. It is fine to begin with a manual dashboard. Design metrics and update them on a whiteboard once a day. It is the impact of the metrics that Ball was striving for, not the flash of a fancy product. Ball already used a reporting system from Cyberscience; as the system included a dashboard tool, the Cyberscience dashboard was selected for use.

Step 3: Dashboard Design Basics

An effective dashboard should:

◈ Be viewed on a single one-page display screen (no scrolling required).
◈ Feature three to seven metrics.
◈ Present data that is as close to real-time as possible.
◈ Include metrics that can be affected by one of the target audiences.
◈ Be simple and easy to read with minimal text.
◈ Eliminate the need for paper reports.

An effective dashboard should not:

◈ Be everything to everyone.
◈ Have more than seven metrics.
◈ Require scrolling to view the main metrics.
◈ Contain a lot of text.
◈ Remove the need for detail reports.

Step 4: Determine the Audience

The team started to jump into developing the dashboard by defining the metrics, but quickly realized that the audience must be defined first. Who should be acting on the dashboard data? For Ball, it was determined that the biggest benefit of visible metrics would be on the manufacturing floor. The manufacturing floor employees would be able to use the dashboard data to drive and realize improvements on the production lines.

Step 5: Develop the Metrics

With the target audience in mind, the next step was to define the three to seven metrics that would be best suited for driving improvements on the manufacturing floor. Several brainstorming sessions on this topic led to the following suggestions of different types of metrics and their frequencies.

Metric types

◈ Safety
◈ Inventory dollars
◈ Defective product quantities or dollars
◈ Sales quantities or dollars
◈ Line efficiency (as compared to standard)
◈ Maintenance and repair spending
◈ Line spoilage costs
◈ Defective material spoilage costs
◈ Schedule attainment
◈ Customer complaints created or closed
◈ Manufacturing downtime

Frequency and detail level

◈ Production day
◈ Week
◈ Month
◈ Year-to-date
◈ Crew

The options were evaluated over a period of weeks with staff at various management levels at both corporate- and plant-level. The final metrics list follows:

◈ Safety
◈ Defective material produced and held (dollars)
◈ Inventory (dollars)
◈ Line spoilage (percentage)
◈ Line efficiency (percentage)
◈ Customer complaints (number)
◈ Maintenance and repair costs (dollars)

The frequency chosen for the main dashboard page was “period-to-date,” in this case, month-to-date. Agreement on this was more difficult to come by than the metrics themselves. Ball has 11 plants and there were many ideas on how metrics should be used for operations decisions – for example, some plants wanted to use metrics by crew, some wanted to look at the metrics by production day (defined as the last 24 hours) and some wanted to look at the metrics by week. In the end, the team confirmed that the metrics needed to drive improvement opportunities, not firefighting reactions. For this reason, month-to-date was the optimal frequency for the metrics. Beyond that, it is expected that once an improvement opportunity is identified, whichever team is working on the improvement will run detailed reports as needed to support the improvement effort.

In addition to period-to-date, the main dashboard page was also include line charts for rolling 12 months, 13 weeks and 30 days.

Step 6: Determine the Levels of Data

The next step was to determine what levels of data were required, which meant returning to the intended audience. Here, the dashboard was being created primarily to drive improvement projects on the manufacturing floor. At the end of the day, the data must be understood by the employees on those plant floors or the dashboard is doomed to fail.

To make this exercise more challenging, there are multiple plants, which each have their own departments and each department then has multiple manufacturing lines. The metrics must have drill-down capability to the line level in order to drive the correct actions on the manufacturing floor.

The dashboard, however, must also have the ability to be viewed – in helpful measures – at various management levels. For example, a department manager will want to see the data at the department level. Likewise, the plant manager will want to look at data aggregated to the plant level. A corporate leader may want to see the data at the division level but still have the option to drill down to view metrics at individual plants.

Fortunately for Ball, the Cyberscience dashboard allows users to manage many levels of data. When implementing a manual dashboard, start with the level of metric that will be acted on or affected by the main audience – in this case, that is the line-level data.

Step 7: Designing the Display – Visual Management

A basic metric format was designed that could display any type of data.

Figure 1: Sample of Metric Display Format

The goal is labeled and displayed at the top of the individual metric box. The number in the middle (1.61) is the period-to-date value. Here, it is green because it is better than the goal. The number at the bottom (0.41) is the variance to the last period. Here, it is red and there is a red arrow pointing up because while this process is outperforming the goal, it is not doing as well as it did during the prior period. With little more than a glance, someone can easily see if there is an improvement opportunity. It is that simple.

Figure 2 is an example of a metric that may spur a Lean Six Sigma project to improve it. In this metric, the process is performing below the goal and is trending down from the prior period.

Figure 2: Example of Metric with Poor Performance

The dashboard application was selected, seven metrics identified, metric formats selected, levels of metrics defined. What comes next? Put it all together and the result is a dashboard complete with views available from corporate down to the lines at each plant – displaying the same seven metrics for each level. Figure 3 shows the full dashboard for one line at one plant.

Figure 3: Dashboard Displaying All Key Metrics (Note: The Defect metric does not have a goal and the Maintenance and Repair metric does not have a variance to the prior month.)

It bears repeating that if a company is implementing a manual dashboard, the goals must be to 1) keep it simple and 2) to use data that can be acted upon by the intended audience.

Step 8: Delivering the Dashboard

The dashboard is done now, right? Wrong. In some ways, creating the dashboard is the easy part. One of the harder tasks in this process is determining how best to deliver the dashboard. The process improvement team wanted the dashboard to be visible, interactive and available for many people to view. Options for displays included tablets, large displays, individual workstations, terminals, etc. For Ball, the selection ended up being a dashboard at every plant on a large touchscreen display. Not only are the dashboards visible but they are also perfect for driving “department huddles,” quick 15-minute kickoff meetings to discuss the state of things from a production standpoint.

Step 9: Training

Because the dashboard displays metrics that are simple to understand, webinars were used as the main training method. With 13 plants located all over North America, Ball found webinars ideal for training multiple people in multiple locations. The team also created a short training guide that was available to everyone. In addition, process improvement team members did some one-on-one phone follow-ups to help users become more comfortable with the tool.

Training was fairly easy, but the adoption of the dashboard proved more complex. The team continues to look for additional ways to enhance the adoption of the dashboard. One of those ways that is being promoted is the department huddle, a quick stand-up meeting for managers and team members to discuss how to address priorities as indicated by the dashboard.

Step 10: Feedback

Feedback is good, but be careful. Initially some of the feedback Ball received was trying, in effect, to make the dashboard all things to everyone. That is not the intent of a dashboard. (Now is a good time to go back and reread the section on dashboard design basics in Step 3.) A dashboard will not replace all detailed reports. Those reports will continue to be needed, but with luck they will only be used to better understand the item that is being targeted for improvement. (For Ball, for example, that may be related a specific production line.)

Based on that feedback, the team did add a year-to-date tab and is working on a tab that will show some values for the prior production day. The method for calculating the spoilage metric also changed. Ball did not, however, add any additional metrics to the main page – it still abides by the rules laid out in the dashboard design basics.

Continue reading

Defect Prevention: Reducing Costs and Enhancing Quality

“Prevention is better than cure” applies to defects in the software development life cycle as well as illnesses in medical science. Defects, as defined by software developers, are variances from a desired attribute. These attributes include complete and correct requirements and specifications as drawn from the desires of potential customers. Thus, defects cause software to fail to meet requirements and make customers unhappy.

And when a defect gets through during the development process, the earlier it is diagnosed, the easier and cheaper is the rectification of the defect. The end result in prevention or early detection is a product with zero or minimal defects.

How serious are defects in software development? In the United States, up to 60 percent of software developers are involved in fixing errors, Computer Finance Magazine reported in 1998. This fact alone, without consideration of providing the quality needed to please customers, shows the value of preventing software defects.

Advantage of Early Defect Detection

Data to support the need for early fixes of software defects is supplied by several reports. The National Institute of Standard Technology (NIST) published a study in 2002 noting that the cost of fixing one bug found in the production stage of software is 15 hours compared to five hours of effort if the same bug were found in the coding stage.

The Systems Sciences Institute at IBM has reported that the cost to fix an error found after product release was four to five times as much as one uncovered during design, and up to 100 times more than one identified in the maintenance phase (Figure 1).

Figure 1: Relative Costs to Fix Software Defects (Source: IBM Systems Sciences Institute)

Can software defects be prevented by simply logging them into some “defect tracking tool/system,” documenting them and providing fixes for them? The obvious answer is no, though this is the first step toward defect prevention.

Defect prevention involves a structured problem-solving methodology to identify, analyze and prevent the occurrence of defects. Defect prevention is a framework and ongoing process of collecting the defect data, doing root cause analysis, determining and implementing the corrective actions and sharing the lessons learned to avoid future defects.

Principles of Defect Prevention

How does a defect prevention mechanism work? The answer is in a defect prevention cycle (Figure 2). The integral part of the defect prevention process begins with requirement analysis – translating the customer requirements into product specifications without introducing additional errors. Software architecture is designed, code review and testing are done to find out the defects, followed by defect logging and documentation.

Figure 2: Defect Prevention Cycle (Source: 1998 IEEE Software Productivity Consortium)

The blocks and processes in the gray-colored block represent the handling of defects within the existing philosophy of most of the software industry – defect detection, tracking/documenting and analysis of defects for arriving at quick, short-term solutions.

The processes that form the integral part of the defect prevention methodology are on the white background. The vital process of the defect prevention methodology is to analyze defects to get their root causes, to determine a quick solution and preventive action. These preventive measures, after consent and commitments from team members, are embedded into the organization as a baseline for future projects. The methodology is aimed at providing the organization a long-term solution and the maturity to learn from mistakes.

Most of the activities of the defect prevention methodology require a facilitator. The facilitator can be the software development project leader (wearing another hat of responsibility) or any member of the team. The designated defect prevention coordinator is actively involved in leading defect prevention efforts, facilitating meetings and communication among team and management, and consolidating the defect prevention measures/guidelines.

The five general activities of defect prevention are:

1. Software Requirements Analysis

Table 1: Division of Defects Introduced into Software by Phase
Software Development Phases	Percent of Defects Introduced
Requirements	20 Perecent
Design	25 Percent
Coding	35 Percent
User Manuals	12 Percent
Bad Fixes	8 Percent
Source: Computer Finance Magazine

Errors in software requirements and software design documents are more frequent than errors in the source code itself, according to Computer Finance Magazine. Defects introduced during the requirements and design phase are not only more probable but also are more severe and more difficult to remove. Front-end errors in requirements and design cannot be found and removed via testing, but instead need pre-test reviews and inspections. Table 1 shows the defects introduced during different phases of the software development life cycle.

From the studies made by various software development communities, it is evident that most failures in software products are due to errors in the requirements and design phases – as high as 64 percent of total defect costs (Figure 3), according to Crosstalk, the Journal of Defense Software Engineering.

Figure 3: Origin of Software Defects (Source: Crosstalk, the Journal of Defense Software Engineering)

Hence, it is important to have a proper process of analyzing the requirements in place to ensure that the customer needs are correctly translated into product specifications. Perhaps two or three iteration of interactive sessions with the customer can be of great help in verifying the understanding of the developer about actual requirements.

2. Reviews: Self-Review and Peer Review

Self-review is one of the most effective activites in uncovering the defects which may later be discovered by a testing team or directly by a customer. The majority of the software organizations are now making this a part of “coding best practices” and are really increasing their product quality.

Often, a self-review of the code helps reduce the defects related to algorithm implementations, incorrect logic or certain missing conditions. Once the developer feels they are ready with the module code, a glance through the code and understanding what it does compared to what it is supposed to do, would complete the self-review.

Peer review is similar to self-review in terms of the objective – the only difference is that it is a peer (someone who understands the functionality of the code very well) who reviews the code. The advantage is that of a “fresh pair of eyes.”

3. Defect Logging and Documentation

Effective defect tracking begins with a systematic process. A structured tracking process begins with initially logging the defects, investigating the defects, then providing the structure to resolve them. Defect analysis and reporting offer a powerful means to manage defects and defect depletion trends, hence, costs.

A defect logging tool should document certain vital information regarding the defect such as:

◈ Correct and complete description of the defect – so that everyone on the development team understands what it is and how to reproduce it.

◈ Phase at which it is found – so that preventive measures can be taken and propagation of the defect to next phase (software build) is avoided.

◈ Further description of the defect by screenshots.

◈ Names of those who uncover defects – so everyone knows who to contact for a better understanding of the defect.

4. Root Cause Analysis and Preventive Measures Determination

After defects are logged and documented, the next step is to analyze them. Generally the designated defect prevention coordinator or development project leader facilitates a meeting to explore root causes.

The root cause analysis of a defect is driven by three key principles:

◈ Reducing the defects to improve the quality: The analysis should lead to implementing changes in processes that help prevent defects and ensure their early detection.

◈ Applying local expertise: The people who really understand what went wrong are the people present when the defects were inserted – members of the software engineering team. They can give the best suggestions for how to avoid such defects in the future.

◈ Targeting the systematic errors: There may be many errors or defects to be handled in such an analysis forum; however, some mistakes tend to be repeated. These systematic errors account for a large portion of the defects found in the typical software project. Identifying and preventing systematic errors can have a big impact on quality (in terms of defects) for a relatively small investment.

With these guidelines, defects are analyzed to determine their origins. A collection of such causes will help in doing the root cause analysis. The defects are classified based on their types. A Pareto chart is prepared to show the defect category with the highest frequency of occurrence – the target. An example of defect classification in a Pareto chart is shown in Figure 4.

Figure 4: Example of Defect Classification in a Pareto Chart

Root cause analysis is the process of finding and eliminating the cause, which would prevent the problem from recurring. Finding the causes and eliminating them are equally important.

Each defect category and the causes making those defects happen can be represented using a cause-and-effect diagram, as shown in Figure 5.

Figure 5: Cause-and-Effect Diagram for a Defect

The cause-and-effect diagram, also known as a fishbone diagram, is a simple graphical technique for sorting and relating factors that contribute to a given situation. A team usually develops the cause-and-effect diagram in a facilitated brainstorming session. Once the root causes are documented, finding ways to eliminate them requires another round of brainstorming. The object is to determine what changes should be incorporated in the processes so that recurrence of the defects can be minimized.

5. Embedding Procedures into Software Development Process

Implementation is the toughest of all activities of defect prevention. It requires total commitment from the development team and management. A plan of action is made for deployment of the modification of the existing processes or introduction of the new ones with the consent of management and the team. Some of the other activities in this phase of defect prevention are:

◈ Monthly status of the team should mention the severe defects and their analyses.

◈ Fortnightly or monthly (based on the project schedule) meetings to make the team aware of the systematic errors/defects, their symptoms and solutions.

◈ Embedding the defect prevention measures in software development life cycle processes.

◈ Learning from the previous project’s root cause analysis of defects should be used as the baseline for future projects.

◈ Monitoring the defect prevention progress. Is the number of defects decreasing? Is the development team learning from past mistakes?

Finally, defect prevention is not an individual exercise but a team effort. The software development team should be striving to improve its process by identifying defects early, minimizing resolution time and therefore reducing project costs.

Continue reading

Case Study: DMAIC Project Improves Hospital's On-time Completion of Administrative Tasks

After graduating from medical school, the majority of medical students enter a medical residency program where a significant amount of clinical training occurs. Medical residencies provide a significant value add for the resident as well as teaching hospitals that host the residency programs. During residency, residents are increasingly exposed to a variety of clinical specialties, practices and tasks as well as a multitude of administrative items that must be completed in order to document their ability to perform clinical functions on patients. Additionally, hospitals are able to offset physician shortages by using residents for care and have the ability to generate significant revenue from hosting a residency program.

Despite the benefits of residency programs, there are inherent risks that the hospital assumes by using residents to provide care. Beyond the obvious risk of adverse patient outcomes and sentinel events (an unexpected occurrence in a healthcare setting that results in serious injury or death), there is also a more prevalent risk related to completion of required administrative tasks. While adverse patient outcomes are a serious threat, their likelihood of occurrence is low and ability to detect is high. Residents do not perform care on patients without the supervision of an attending physician. Residents also frequently ask questions to crosscheck other physicians as a part of the learning process, mitigating the risk of adverse outcomes and sentinel events.

Administrative tasks, however, are typically seen as having little-to-no value add by both residents and attending physicians. They are frequently pushed to the bottom of to-do lists when the prospect of a surgery or a rare clinical case presents; there is little ability to detect when they are not completed until it is too late. Not completing an administrative task will likely not result in a serious patient safety event, but there is a high likelihood of tasks not being completed, limited ability to detect when they are not completed and, ultimately, the potential of losing revenue from the residency program when an external audit yields that administrative tasks was not appropriately documented.

Lean Six Sigma (LSS) tools show promise for improvement opportunities across the healthcare industry. A midwestern community hospital in Ohio started a Six Sigma program in 2012 and since then has used the methodologies across the majority of hospital functions—clinical and non-clinical. In a recent project, the Orthopaedic Residency program used the DMAIC (Define, Measure, Analyze, Improve, Control) methodology to increase their on-time resident task completion rate. This article shows the benefits of using LSS methodologies to generate significant improvements with limited resources and funding.

Defining the Problem

To help focus the team, the project lead started with a project charter to define the problem they were trying to solve for as well as the goal they were aiming to achieve.

Problem Statement: From April 2018 through June 2018, 38 percent of resident tasks (62 out of 163 opportunities) were not completed on time and were, therefore, delinquent. This is bad because these tasks are requirements for the Accreditation Council for Graduate Medical Education (ACGME), the Medical Education Department and/or the Orthopaedic Program. If resident tasks are not completed on time it can result in the resident being dismissed from the residency program.

Goal: The primary goal was to decrease the resident task delinquency rate from 38 percent to 23 percent by September 30, 2018.

Business Case: Risk reduction is the primary business case in that by increasing the on-time completion rate of residency tasks, we are effectively reducing the risk of residents being dismissed from the program. The healthcare facility pays approximately $144,000 annually per resident. If a resident is dismissed from the program, the hospital loses that money.

Additionally, by increasing the on-time completion rate we are increasing resident and program coordinator job satisfaction. This, in turn, ensures the sustainment of the program by effectively reducing the time spent remediating poor performance and reducing the risk of resident dismissal.

Project Scope: The process begins with the new resident orientation and ends with the six-month resident checkpoint evaluation.

Team Roles: The team consisted of the orthopaedic residency program director, the residency program coordinator (who used the project to meet the requirements for completion of her Green Belt certification), the program’s research director, the chief orthopaedic resident as well as the attending orthopaedic surgeons and orthopaedic residents. Additionally, a Black Belt within the organization provided oversight on completing the DMAIC deliverables for the Green Belt’s certification.

A SIPOC (supplier, inputs, process, output, customer) analysis and Kano model were both used in the Define phase in order to identify the customer base and the customer preferences, respectively (Figures 1 and 2). The SIPOC analysis in Figure 1 identified the primary outcome metric, the customer base and a high-level overview of the current state of the process. Figure 2 shows the Kano model that was used to identify customer preferences.

Figure 1: SIPOC Analysis

Figure 2: Kano Model

Measurement and Analysis of the Data

A data collection plan was completed first to identify which administrative tasks were the primary focus of the project. The team determined that the tasks required of the ACGME were of primary focus since those would be the focus of an external audit conducted by the ACGME. Data was then collected to determine the baseline delinquency rate for each of these tasks as well as the combined delinquency rate for all tasks (Figure 3). The primary outcome metric for the project was the combined delinquency rate, which was determined to be 38 percent (62 out of 163 opportunities) between the measurement period of April 2018 through June 2018.

Figure 3: Number of Residents Not Completing Tasks by Task Type

The team brainstormed potential root causes associated with a delinquency rate of 38 percent and used multi-voting to identify the primary root cause (Figure 4).

Figure 4. Results from the Multi-Vote on the Potential Root Causes

The results of the multi-voting activity indicated that the primary root causes were the following:

1. Tasks were too tedious and time consuming.

2. Too many requirements existed.

3. There was no accountability structure in place.

The team determined that the organization has little control over the first two root causes, so, in turn, chose to identify solutions that would address the lack of an accountability structure.

Process Improvement

Once the root cause was identified, the team performed a second brainstorming activity to develop a list of solutions that would help enhance accountability. A risk identification and mitigation plan was then put together for each of the solutions in order to help determine which of the solutions carried the lowest risk if implemented.

A visual display board was chosen as the improvement solution given that it was quick and easy to implement with little-to-no risks associated with it. Additionally, visual display boards are commonly used in process improvement projects because of their effectiveness with sustaining long-term process improvement initiatives. The team chose to use a combination of colors, numbers and symbols to indicate progress. There are several individuals on the team who are red-green colorblind and would not have benefited from color alone as an indicator of progress. Figure 5 shows the visual display board implemented in the orthopaedic didactic lecture room. Residents have daily meetings in the lecture room and are therefore able to see their progress each day

Figure 5: Ortho Task Master Visual Board

Achieving and Maintaining Results

Following the development and implementation of the visual accountability board, the team finalized its control plan to ensure long-term sustainability of the improvement. The control plan outlined various crosschecks as well as defined timelines for when – and how – to react based on the level of delinquency for each administrative task.

The team felt that all of the tasks required by ACGME were important, but some tasks cannot be made up if the deadline to complete them has passed. As a result, the control plan established firmer reactions for falling delinquent on those tasks when compared to tasks that could be made up should a resident fall behind. Once implemented, the team collected control data to monitor the success of the solution. After the improvement data was collected, a chi-square test determined if the results were significantly different from the baseline results. The improvement results (shown in the table below) showed statistically significant improvement in three of the seven categories including the overall delinquency rate, which was the primary outcome metric for the project.

Goal achieved! The primary goal was to decrease the resident task delinquency rate from 38 percent to 23 percent; the project in fact surpassed that goal with a post-implementation delinquency rate of 20 percent.

Comparison of Task Complete Rate Pre- Vs Post-Implementation
Task	Baseline Delinquency Rate	Post-Implementation Delinquency Rate	Statistically Significant
Test Master	17%	9%	No
Total Tests	24%	23%	No
Skill Master	44%	32%	No
Evaluations	23%	23%	No
Duty Hours	35%	20%	Yes
Case Logs	35%	7%	Yes
Total Delinquency Rate	38%	20%	Yes!

The project sponsor highly regarded the significant change in delinquency rates for the duty hours and case logs tasks because these are two tasks that need to be completed in residency as well as private practice.

Continue reading