WEBVTT

1
00:00:00.000 --> 00:00:03.000
Hello! I'm Cory Foy, and 

2
00:00:03.000 --> 00:00:06.000
in this Faster Fridays video I wanted to walk through

3
00:00:06.000 --> 00:00:09.000
a technique known as Value Stream Mapping. This is a

4
00:00:09.000 --> 00:00:12.000
powerful technique from Lean Manufacturing which allows you

5
00:00:12.000 --> 00:00:15.000
to understand not just your process, but the delays

6
00:00:15.000 --> 00:00:18.000
queues and time spent in them to find out

7
00:00:18.000 --> 00:00:21.000
what's really slowing you down.

8
00:00:21.000 --> 00:00:24.000
In the upper left hand you can see a Value Stream Map I did

9
00:00:24.000 --> 00:00:27.000
for a client many years ago. This was obviously a 

10
00:00:27.000 --> 00:00:30.000
rough sketch, but we were able to do it quickly.

11
00:00:30.000 --> 00:00:33.000
But what is a Value Stream Map? At its core

12
00:00:33.000 --> 00:00:36.000
it is a way of visualizing the flow of work

13
00:00:36.000 --> 00:00:39.000
in a system. But the power comes from

14
00:00:39.000 --> 00:00:42.000
mapping your actual process, not how you want

15
00:00:42.000 --> 00:00:45.000
it to - or wish it did - work.

16
00:00:45.000 --> 00:00:48.000
Our map begins at an entry point into the

17
00:00:48.000 --> 00:00:51.000
system. Ideally this is the very beginning.

18
00:00:51.000 --> 00:00:54.000
Perhaps where an idea first gets introduced.

19
00:00:54.000 --> 00:00:57.000
We then walk through all of the steps until it leaves

20
00:00:57.000 --> 00:01:00.000
our system, or we get the value we need, in this case

21
00:01:00.000 --> 00:01:03.000
shipping software. It's possible for this

22
00:01:03.000 --> 00:01:06.000
to go even further. For example, a hospital's

23
00:01:06.000 --> 00:01:09.000
value stream may not end when a patient is discharged.

24
00:01:09.000 --> 00:01:12.000
They may want to track post-discharge steps,

25
00:01:12.000 --> 00:01:15.000
follow up appointments, or even readmissions.

26
00:01:15.000 --> 00:01:18.000
Once we have our process, we then look at

27
00:01:18.000 --> 00:01:21.000
the processing time in each step. In this

28
00:01:21.000 --> 00:01:24.000
case we're dealing with people - not machines - so design

29
00:01:24.000 --> 00:01:27.000
may take 2 days of work, but it takes the designers

30
00:01:27.000 --> 00:01:30.000
two weeks to devote two full days towards the design.

31
00:01:30.000 --> 00:01:33.000
Likewise, the development team may spend

32
00:01:33.000 --> 00:01:36.000
two full weeks developing, but it takes them twelve weeks

33
00:01:36.000 --> 00:01:39.000
to get those two weeks - either because of meetings, 

34
00:01:39.000 --> 00:01:42.000
context switching, escalations or other work. Finally,

35
00:01:42.000 --> 00:01:45.000
we ship it, which is a full day deployment, but

36
00:01:45.000 --> 00:01:48.000
our piece is only one hour of.

37
00:01:48.000 --> 00:01:51.000
Now that we have our processing time, we need to look at

38
00:01:51.000 --> 00:01:54.000
our queues, or the places work sits while it's waiting

39
00:01:54.000 --> 00:01:57.000
to move downstream. It's very rare to have

40
00:01:57.000 --> 00:02:00.000
perfect efficiency, so in this case we see

41
00:02:00.000 --> 00:02:03.000
that once an idea comes in, it takes on average

42
00:02:03.000 --> 00:02:06.000
a week for design to start, two weeks for development

43
00:02:06.000 --> 00:02:09.000
to start once design is done, and an average of three weeks

44
00:02:09.000 --> 00:02:12.000
for it to be deployed due to the organization's six week

45
00:02:12.000 --> 00:02:15.000
deployment cycles. So to close this out, 

46
00:02:15.000 --> 00:02:18.000
our processing time - calculated by adding up

47
00:02:18.000 --> 00:02:21.000
just the time spent working, was 97 hours

48
00:02:21.000 --> 00:02:24.000
or about 2.5 weeks of work to go

49
00:02:24.000 --> 00:02:27.000
from idea to shipping. It takes

50
00:02:27.000 --> 00:02:30.000
688 hours to actually get it out the door

51
00:02:30.000 --> 00:02:33.000
about 17 weeks, resulting in a 

52
00:02:33.000 --> 00:02:36.000
14% efficiency. But, is that real?

53
00:02:36.000 --> 00:02:39.000
That seems wasteful, doesn't it?

54
00:02:39.000 --> 00:02:42.000
So let's go back and look at that client diagram

55
00:02:42.000 --> 00:02:45.000
and actually sketch it out to see how it was.

56
00:02:45.000 --> 00:02:48.000
In this case, we start with the

57
00:02:48.000 --> 00:02:51.000
request coming in. It then goes through 

58
00:02:51.000 --> 00:02:54.000
Opportunity Assessment, some analysis, a review,

59
00:02:54.000 --> 00:02:57.000
of the analysis, some product team analysis, 

60
00:02:57.000 --> 00:03:00.000
they generate high level requirements - that goes through a review

61
00:03:00.000 --> 00:03:03.000
then the original requesting stakeholder has a 

62
00:03:03.000 --> 00:03:06.000
approval process. Then the requirements themselves get

63
00:03:06.000 --> 00:03:09.000
finished up, it goes through a design stage, the design

64
00:03:09.000 --> 00:03:12.000
gets approved. It goes through architecture submission and

65
00:03:12.000 --> 00:03:15.000
the architecture gets approved. And then...

66
00:03:15.000 --> 00:03:18.000
we can kick off the project! Yes!

67
00:03:18.000 --> 00:03:21.000
We haven't even started developing yet!

68
00:03:21.000 --> 00:03:24.000
But now what we want to do is map out the processing time

69
00:03:24.000 --> 00:03:27.000
and queues in between them. These came from 

70
00:03:27.000 --> 00:03:30.000
the actual teams and executives, and represented

71
00:03:30.000 --> 00:03:33.000
average waiting times.

72
00:03:33.000 --> 00:03:36.000
But even this doesn't tell the entire story, because

73
00:03:36.000 --> 00:03:39.000
in at least three places we can get rework.

74
00:03:39.200 --> 00:03:40.500
For example

75
00:03:40.500 --> 00:03:43.500
at the first review stage, an average of 20%

76
00:03:43.500 --> 00:03:46.500
of requests get kicked back to Opportunity

77
00:03:46.500 --> 00:03:49.500
Analysis once. In the second review, work

78
00:03:49.500 --> 00:03:52.500
gets kicked back to Product Analysis

79
00:03:52.500 --> 00:03:55.500
50% of the time! When we mapped all this out

80
00:03:55.500 --> 00:03:58.500
we found it was 286 hours of

81
00:03:58.500 --> 00:04:01.500
work over 1592 hours

82
00:04:01.500 --> 00:04:04.500
or, 7 weeks of work, but

83
00:04:04.500 --> 00:04:07.500
10 months to get those 7 weeks!

84
00:04:07.500 --> 00:04:10.500
So when we talk about wanting to go faster, we didn't need

85
00:04:10.500 --> 00:04:13.500
to look at engineering. We could drastically improve

86
00:04:13.500 --> 00:04:16.500
the responsiveness of the organization simply by

87
00:04:16.500 --> 00:04:19.500
reducing the queueing time between these steps 

88
00:04:19.500 --> 00:04:22.500
without even having to remove any of them.

89
00:04:22.500 --> 00:04:25.500
So if you want to try this yourself, start with

90
00:04:25.500 --> 00:04:28.500
your own process. Map out the time inside steps,

91
00:04:28.500 --> 00:04:31.500
then the time in-between steps.

92
00:04:31.500 --> 00:04:34.500
Calculate your times, recover from your heart attack,

93
00:04:34.500 --> 00:04:37.500
and then work on clearing those bottlenecks.

94
00:04:37.500 --> 00:04:40.500
Your entire organization will thank you! And if you get stuck

95
00:04:40.500 --> 00:04:43.500
or need any help, don't hesitate to reach out at

96
00:04:43.500 --> 00:04:46.500
hello at coryfoy dot com. I regularly perform

97
00:04:46.500 --> 00:04:49.500
assessments and VSMs for clients in a wide variety of

98
00:04:49.500 --> 00:04:52.500
industries and governments, and would be more than happy to help yours.

99
00:04:52.500 --> 00:04:55.500
Until next time, here's to tracking down your delays!

100
00:04:55.500 --> 00:04:57.633
Until next time, here's to tracking down your delays!