My view on Lean IT

Organization Name | Group Name

Lean IT:
Separates Added Value from Waste
Evgeny Nedelko, April 2012

Lean IT: Separates Added Value from Waste

Lean IT provides a clear
connection between Value
All widely recognized for end customer and day
IT frameworks
(ITIL, RUP, Agile, CMM to day work and it is
I, ADM) say HOW to designed to handle
deliver IT projects, but
don’t say WHY uncertainty of individual
The goal of any projects
organization is to
bring more value
for its customers Lean IT is based on 13
at less costs Lean Six Sigma says principles of Toyota Product
WHY, but most of its Development system and
tools are not applicable
for project bounds together Lean Six
activities, which are Sigma tools with traditional
highly variable in their
nature Agile development and
Service delivery (ITIL)
methodologies

Copyright © 2011-2012 Accenture All rights reserved. 2

What is Lean Six Sigma?

Lean Six Sigma
Focus on capabilities of Statistically proven
the people in the process capability
process

Definition of strategic areas for continuous
improvement of business operations
Common
principles and
scientific
foundation
A toolset and methodology for
individual process improvements

Joseph M. Juran W. Edwards Deming


History of Lean IT

- 1890’s Frederick W. Taylor – Scientific Management
— 1910’s Henry Ford and Charles Sorensen – Ford System (Mass Production)
- 1920’s Walter Shewhart (Bell Laboratories)– Statistical Process Control
- 1950’s W. Edwards Deming teaches Statistics in Japan
- 1950’s Joseph M. Juran teaches Management in Japan
- 1948-75 Taichii Ohno and Shigeo Shingo – Toyota Production System
– 1984 Eliyahu M. Goldratt – Theory of Constraints
- 1986 W. Edwards Deming – Total Quality Management
- 1987 Mikel Harry (Motorola) – Six Sigma
- 1991 James P. Womack, Daniel T. Jones, Daniel Roos
- – Lean Production
— 2003 Mary and Tom Poppendieck – Lean Software Development
- 2011 Steve Bell and Mike Orzen – Lean IT

Agenda

· Recognise the Customer Value
· Build the Culture of Learning
· Just-in-Time Delivery
· Other Tools

– Appendix: Thirteen LPD Principles


Two kinds of IT Services

Enterprise Systems: Infrastructure and Telecoms:
• Have a purpose to improve business • Required to support current business
operations operations without clear business value
• Usually are delivered and maintained by • If there is no infrastructure – there are
IT department no business operations
• Product specification is driven by • Procured with minimal customisation
business users from a vendor
• Customised to company needs or • Product specification is driven by
custom built by request Vendor’s marketing or product
development department

The main focus of this
presentation


“Step 0” – Identify Your Customer
Purpose of Lean – To maximise value for customer while minimising the
costs, thus the cornerstone of Lean is Customer
In IT there is a hierarchy of customers
with their own needs
– Other IT Units
– Business Users
– End Customers of the company

Example Voice of Customer*:
– End customers want a stable quality service provided by the company,
with no interruptions during business hours
– Business users need a stable system, that would not require a support from IT
and all potential problems foreseen and prevented.
– Many users want to be able to solve simple incidents by themselves with
guidance of FAQ and Knowledge base, and look for a friendly guidance from
Service Desk on more complex issues
– They want their issues to be solved after first call at clear timeframe,
without need to push or spend their own time on technical decisions
– “Don’t get me to help you, I want you to help me!”
*Adapted from Lean IT (Mike Orzen, Steve Bell), Lean Solutions (Jim Womack and Don Jones) and Sense and Response (Stephen Parry)


Costs and Benefits of an Enterprise System
Below are the typical costs and benefits for an business IT system
Original Estimation

Propagated Errors

Benefits
Actual
of Benefits

Business Benefits

Demand
Improvement
Specify Functional Gaps, Defects
need Gaps, Defects
Incident
Request

Business

Request

Release
Technical Debt
Release

around
Work

Fix
IT
Implement
Implement
Diagnose
Solution
Solution
Solve problem
Preventive Maintenance
Cost reduction

Legend
Benefits / Value Costs / Waste


Examples of Benefits

There are direct benefits: and indirect benefits:
• automation of work reduces need • appealing user interface expands
for manual operation the customer loyalty
• improving quality of manufacturing • better control of risks reduces
process reduces scrape and use of potential loss and reputation
materials • better information management
• better control of finances reduces improves quality of overall
write-offs and other loss management in organisation

The result of process automation should not
be staff reduction, but more time to think how
to serve clients better


Examples of Costs

In most of the cases the cost of system implementation can be reduced,
but an impact on operational (running) costs is inevitable

Technical debt is costs that are imposed by the system
These could be direct costs: and indirect costs:
• business outage due to system • impact on reputation
unavailability • operational risks
• loss due to incorrect system • human errors that could be
behaviour prevented by software
• extra costs required for system • training costs required for new users
modification due to complicated
design
• cost of regression testing


Relentless Learning and Improvement
System implementation projects are unique in their nature.
Even when you have a plan, you cannot say whether you run it
in the most efficient way before you try. That is why
it is so important to build learning cycles into your delivery.

Make sure you not only “Plan what you do Plan

and Do what you plan”
Act Do
You should also Check the results
and Act accordingly
Check

To err is human,
but not to learn from mistakes is a crime
Vivek Nayer


Front-load the Development Process
The main waste in any process is rework – developing system
that needs to be corrected due to error or design flaw
• To prevent this - all alternatives should be identified as soon as
possible to allow enough time for evaluation of options and to
identify possible constraints before completing dependent tasks

• Work on alternatives – as SOON as possible
• Make a choice – as LATE as possible


Short Iterations
In quickly developing organisation requirements and priorities change quickly
due to changing market conditions and learning process and better
understanding overtime

• 30% of change requests lose their priority and
10% can get new requirements after one quarter

– This means that 25-65% of original system features become irrelevant for client
after one year of implementation
– This is probably one of the main reason why so many long term projects fail
to deliver satisfactory results

• Therefore it’s important to present the system to client
as often as it is possible and to adjust plans according to
the feedback


Standardise Work Items and Steps
• Always plan a project
It is impossible to distinguish waste • Define a workflow for user requests
from value in the process before you • There are standard steps even for
casual tasks (define what needs to be
identify the sequence of steps done, assign the
responsible, do the task, validate the
performed to achieve expected results result)

• In Agile development, Project
When you split your project delivery iterations (sprints) take 1 or 2 weeks
into a set of similar steps it becomes permitting to collect lessons learned
often enough to identify issues long
possible to compare results of before they become a real problem
• In Scrum, daily meetings permit to
individual iterations and identify reduce learning cycle to one day
repeatable problems


Knowledge Management Tools

– Supplier technology demonstrations
– Competitor teardown analysis
– Checklists and quality matrices
– Learning focused problem solving
– Know-how database
– Lessons learned events (Hansei)
– Program manager conferences
– Business Revolution Teams
– On the job trainings skill matrix, learning focused career paths
– Resident Engineers (RE)
Adapted from The Toyota Product Development System, (James M. Morgan and Jeffrey K. Liker)


Kanban
Whatever planning technique is used to forecast workload of functional groups in the
project, there are inevitable variation causing delays, when one group waits for output
from another, and when a group has not enough capacity to handle all incoming
tasks

Kanban (看板), is the concept of Just-In-Time production, when centralized
end-to-end planning is replaced with individual tasks flowing through the
process, and controlled centrally
Project Manager / Chief Engineer Customers
Group
Support
pull Designers pull Developers pull Testers pull Engineers

Pulling knowledge through the process flow


Alignment through Visual Communication
Visual communication is much more effective than verbal
communication, even though it takes more efforts

• Visual boards are used
– To define and demonstrate tasks and their priorities
– To present current results (plan/fact)
– To promote overall goals
– To provide feedback to team members


Leveled Process Flow

When you have your process flow defined you can see the bottlenecks
and remove them (i.e. level the process)
Uneven load on functional groups can be identified and then mitigated by a bench of temporary
resources (contractors) preselected, but not hired until actual need for extra people


Integrate Suppliers into the Quality System
If you take look on the end-to-end value stream for IT you see that it starts from suppliers
and finishes at the end customer of the company

To remove waste from the flow you need to start from the waste
delivered by supplier, which means that you cannot improve your
process excluding suppliers from scope

Value Value Value

Business End
Suppliers Waste IT Waste Waste
Departments Customer


Organisational Matrix
Analysis Lead Development Lead Testing Lead Support Lead

Group
Designers Developers Testers Support Engineers

Group

Group

While functional teams balance resources, take care of their people and best results for
each process step, the Project manager as a Customer’s advocate pulls all requested
changes through the process flow

This matrix create two career paths – for Experts in functional teams and
Managers serving customer groups


Organise to Balance the Matrix
One of the most typical problem in IT
organisations is silo thinking. There are
Developers who don’t care of User support, there
are User support who ignore Business
Analysts, Testers don’t talk to Analysts.
Similarly the CRM implementation project doesn’t
take care of the ERP implementation project, and
IT Security don’t care of anyone at all

Lean IT says that IT management should
constantly balance the project management
matrix
…there should be people responsible for alignment of
individual projects and…
…there should be people responsible for alignment of end-to-
end delivery flow


Other Lean Tools

• Flow chart
• Projects Prioritisation
• Cause & Effect "Fishbone" Diagram,
5-Why Analysis
• Set-Based concurrent Engineering
• Decision Analysis and Resolution


A3 Thinking

A3 Report is a Project Charter
covering the following topics: Principles of the A3 system:
Objectivity
• Problem side (left half of a page): Distillation and visualization
– Background Results and Process
– Voice of Customer Alignment
– Current State (metrics, VSM)
– Root Cause Analysis A3 Reports cannot be drafted in isolation by a
person working alone in their room
• Solution side (right half of a page):
– Project Team It’s essential that the A3 Report
– Action Plan
should be updated throughout the
– Project Targets vs. Actuals
project life as long as
– Effect Confirmation / Value Delivered
understanding of the facts changes


Poka-Yoke
Poka-yoke (ポカヨケ) is a Japanese term that means "mistake-
proofing". Its purpose is to eliminate product defects by
preventing, correcting, or drawing attention to human errors as they
occur
– Checklists
– Standard, detailed test plans
– Part quality matrices
– Architecture patterns
– Reusable components
– Standardized execution processes
– Test driven development


Adapt Technology to the Problem, not the opposite

“The biggest epidemic in IT is that we
routinely pick solutions that are
bigger & more complex than our
problems.”
Torbjörn Gyllebring

– Technologies must be seamlessly integrated
– Technologies should support the process, not drive
it
– Technologies should enhance people, not replace
them
– Specific solution oriented: not a silver bullet
– Right size – not king sized


Appendix: Thirteen LPD Principles
Lean Product Development is driven by thirteen principles originating from Toyota PDS
1. Establish customer-defined value to integration.
separate value-added from waste. 7. Develop towering competence in all
2. Front-load the product development engineers.
process to explore thoroughly alternative 8. Fully integrate suppliers into the
solutions while there is maximum design product development system.
space.
9. Build in learning and continuous
3. Create a level product development improvement.
process flow.
10. Build a culture to support excellence and
4. Utilize rigorous standardization to relentless improvement.
reduce variation, and create flexibility
11. Adapt technologies to fit your people
and predictable outcomes.
and process.
5. Develop a chief engineer system to
12. Align your organization through simple
integrate development from start to
visual communication.
finish.
13. Use powerful tools for standardization
6. Organise to balance functional
and organizational learning.
expertise and cross-functional
As per James M. Morgan and Jeffrey K. Liker, authors of The Toyota Product Development System,
Integrating People, Process and Technology (2006, Productivity Press)

Learn more

Lean Six Sigma CBT training on myLearning
• https://mylearning.accenture.com/accenture/lang-
en/management/LMS_ActDetails.asp?ActId=546942

“Lean IT: Enabling and Sustaining Your Lean Transformation”
by Steve Bell, and Mike Orzen (available online)
• http://skillport.books24x7.com/toc.aspx?bkid=36963

“Sense and Respond: The Journey to Customer Purpose”
by Stephen Parry, Sue Barlow, and Mike Faulkner
• http://www.amazon.co.uk/dp/140394573X


My view on Lean IT

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Destaque

Destaque (20)

Semelhante a My view on Lean IT

Semelhante a My view on Lean IT (20)

Último

Último (20)

My view on Lean IT

Notas do Editor