How to Get Started: Part Five - Planning VI
Well, we're still on the planning phase. And that's not bad. Mo' better planning means mo' better implementation.
Last time I provided a list of things you need to put on your calendar. Let's look at that list again and talk about why you need to attend to each one.
Regular day and time for Steering Committee meetings.
I talked about the role of the Steering Committee (SC) in another post. The SC needs to meet no less than every other week (or twice a month, whichever) during the startup of an agile implementation. You can move to monthly meetings after a year or so, when the program has momentum. Weekly isn't too often. You should meet for four hours each month. In other words, if you meet twice a month, meet for two hours at a time. Weekly, meet for an hour. Devote one of your meetings to reviewing metrics. The other meeting can focus on reviewing recent activities and planning for upcoming ones. That's pretty much the agenda for SC meetings:
Somewhere along the line, you need to announce to everyone what's going on. Some companies already have "all employee" meetings of one sort or another. This announcement can be made at one of those meetings. If you don't have regularly scheduled meetings with employees, you need to plan one.
The announcement doesn't have to be complex or involved. Twenty or thirty minutes should do it. This isn't the time to train everyone in agile concepts and tools. It will be enough simply to talk about what's been going on and what will be coming up in the near future. And make a pitch for their participation of course.
Deadlines for full development of the metrics.
During the planning sessions, you decided on what metrics you'd be using for the agile initiative. Now you have to make charts for all of them. You probably have some of the data ready to go and it's just a matter of making the chart. In other cases, there might be some "data mining" to do first. In still other cases, you might have to actually gather the data. Put deadlines on all these activities or you'll be twelve months into the initiative with no metrics.
Regular all employee meetings to keep everyone updated on the agile initiative.
If you already have a schedule of "all employee" meetings, you're set. If not, make a schedule. There...that was easy, wasn't it.
Several action workshops for 5S and Quick Change.
5S (or 6S, as some organizations refer to it, the extra S being for Safety) workshops get employees involved and energized. And they're easy. In my practice, I've typically done four-hour workshops. In many cases, though, 5S and Quick Change Workshops can be scheduled to last days. Make the workshop length match your ability to schedule. If you need to schedule shorter workshops but more of them, so be it.
Pick an area, a machine, a production line, etc. and go after it, scheduling both 5S and Quick Change workshops. You may not get everything done in the workshops but schedule enough of them so that an area is pretty well 5S'd and you get about a 50% reduction in changeover time. Further improvements will come as teams meet and continue to work on these projects.
Development of a Value Stream Map (maybe two)
Some consultants like to start with Value Stream Maps (VSM) but I prefer the workshops. That said, the workshops have a fairly narrow focus and it's important to get the broader view that a VSM project gives.
There are some good books around as to how to carry out a VSM project. Some descriptions I've seen, however, can make the process seem a bit complicated. One that I read involved a lot of up-front data gathering just to pick a process to map. I generally get a team talking about important products (high volume, high margin, problem product, new product, etc.) and pick one to start with. If it turns out that the wrong product was picked, you can always start over. Pick a product (or product group or family) and go after it.
It is better to pick a product rather than a process flow that multiple products might flow through. In this case, you'll have too many different loops and parallel flows. Just pick one product and you can be confident that what you learn can be applied to other products and processes.
Last time I provided a list of things you need to put on your calendar. Let's look at that list again and talk about why you need to attend to each one.
Regular day and time for Steering Committee meetings.
I talked about the role of the Steering Committee (SC) in another post. The SC needs to meet no less than every other week (or twice a month, whichever) during the startup of an agile implementation. You can move to monthly meetings after a year or so, when the program has momentum. Weekly isn't too often. You should meet for four hours each month. In other words, if you meet twice a month, meet for two hours at a time. Weekly, meet for an hour. Devote one of your meetings to reviewing metrics. The other meeting can focus on reviewing recent activities and planning for upcoming ones. That's pretty much the agenda for SC meetings:
First meeting each month: How are we progressing? (Review of metrics)An "all employee meeting" to announce the agile initiative.
Second meeting each month: What did we do last month? (Review of recent activities) and What's coming up next month? (Plan for upcoming activities).
Somewhere along the line, you need to announce to everyone what's going on. Some companies already have "all employee" meetings of one sort or another. This announcement can be made at one of those meetings. If you don't have regularly scheduled meetings with employees, you need to plan one.
The announcement doesn't have to be complex or involved. Twenty or thirty minutes should do it. This isn't the time to train everyone in agile concepts and tools. It will be enough simply to talk about what's been going on and what will be coming up in the near future. And make a pitch for their participation of course.
Deadlines for full development of the metrics.
During the planning sessions, you decided on what metrics you'd be using for the agile initiative. Now you have to make charts for all of them. You probably have some of the data ready to go and it's just a matter of making the chart. In other cases, there might be some "data mining" to do first. In still other cases, you might have to actually gather the data. Put deadlines on all these activities or you'll be twelve months into the initiative with no metrics.
Regular all employee meetings to keep everyone updated on the agile initiative.
If you already have a schedule of "all employee" meetings, you're set. If not, make a schedule. There...that was easy, wasn't it.
Several action workshops for 5S and Quick Change.
5S (or 6S, as some organizations refer to it, the extra S being for Safety) workshops get employees involved and energized. And they're easy. In my practice, I've typically done four-hour workshops. In many cases, though, 5S and Quick Change Workshops can be scheduled to last days. Make the workshop length match your ability to schedule. If you need to schedule shorter workshops but more of them, so be it.
Pick an area, a machine, a production line, etc. and go after it, scheduling both 5S and Quick Change workshops. You may not get everything done in the workshops but schedule enough of them so that an area is pretty well 5S'd and you get about a 50% reduction in changeover time. Further improvements will come as teams meet and continue to work on these projects.
Development of a Value Stream Map (maybe two)
Some consultants like to start with Value Stream Maps (VSM) but I prefer the workshops. That said, the workshops have a fairly narrow focus and it's important to get the broader view that a VSM project gives.
There are some good books around as to how to carry out a VSM project. Some descriptions I've seen, however, can make the process seem a bit complicated. One that I read involved a lot of up-front data gathering just to pick a process to map. I generally get a team talking about important products (high volume, high margin, problem product, new product, etc.) and pick one to start with. If it turns out that the wrong product was picked, you can always start over. Pick a product (or product group or family) and go after it.
It is better to pick a product rather than a process flow that multiple products might flow through. In this case, you'll have too many different loops and parallel flows. Just pick one product and you can be confident that what you learn can be applied to other products and processes.
Comments