DMAIC Tollgates

Hi Gina,

There is some value in the discipline and rigor of requiring tollgates for each stage. However, since you ask, yes – I probably would allow a seasoned, certified belt to combine certain tollgates if it promoted efficiency without degrading effectiveness. It’s pretty common for some of these stages to overlap, so – for example – I could see a Define / Measure combined tollgate, or similarly an Improve / Control tollgate, where the deliverables for both adjacent stages would be reviewed.

Best regards,
Eric

Possible to combine Improve Control tollgates

Both Mr. C’s are spot on of course. I just wanted to add 2 more cents…(probably for others who might be interested in perspective)–make very sure some review has occurred for a project by the end of the Define/Measure phases. The phases often overlap but if the belts’ projects are reviewed with others for financial and strategic importance, appropriate scope, and appropriate team support then you have a MUCH better chance of % success for project completion.

@ginagentile2000 @garyacone @Mike-Carnell @cseider
OH BOY, another forum to talk about “rhythms of reviews” and project work. In my mind and in the strictest sense tollgate reviews are technical reviews between the mentor and project teams. The content of the tollgate reviews are appropriate to management reviews as has been said above. They demonstrate that projects are on schedule to a committed timeline with lessons learned and needed assistance from management to continue. In addition projects are deleted, downsized (project to just do it) or additional needed projects defined and approved. But, project reviews must be in context of the normal business/process reviews and not a “review of the LSS projects” as is often the case. How projects fit into improvement needs of business/process metrics is then clear. Below are some thoughts I have towards what is the normal business/process review rhythm and where project reviews fit in the normal business review process. I am kind towards management in this discussion. This is an excerpt from a larger discussion on how deploy LSS, to pick appropriate metrics and projects and project team deployment so it may seem a little fragmented.

Managers and supervisors must be taught how to manage processes improvement. An LSS deployment, typically mandated from senior management, is probably a good sign that processes are out of control to the business needs. This implies there is some gap in lower managements’ skills or capability to direct and sustain process improvement. Their world is probably one frantic in activity related to fire fights, reporting requirements and overwhelming supervisory responsibilities, especially where the employee to supervisor ratio is high (and they usually are). The leader of the LSS deployment will at first be seen a someone that will fix a myriad of problems and their will be a sense of relief from the supervisors and managers that someone like this has entered the organization. The LSS manager is typically hit with all the nasty little problems that haven’t been solved in years as an offload. This is a big pitfall if not managed. A clear expectation must be set as to what constitutes an LSS project and what does not. It must be made clear that the major role of the LSS leader with respect to supervisors and managers in the deployment is to teach them how to participate in process improvement and then how to keep the gains made by the effort.

Mandatory in the management role for an LSS deployment is to help establish and maintain a rhythm of review. There are three components to the rhythm (Note: in the long run the LSS leader participation is replaced by process owners or appropriate operations people).

• Line Charts: On the LSS leader side Y variable and critical X variable charts will be designed and put in prominently visible positions on the line. Data on Key Y variables and proven critical X variables need to be plotted at least hourly. The rhythm involves supervisors and managers at set intervals to “walk the line” and initial and make short comments on both X variable and Y variable charts, especially for good performance. They need to have some discussion with line personnel as to the variation in performance. Business Unit Managers need to do it at least once per day across shifts; Mid managers at least once per shift; Supervisors two to three times per shift.
• Shift Reviews: On the LSS leader side a system to have Y variable performance quantified and at least a Pareto of known sources of variation displayed needs development. How projects tie to the Pareto is identified. New action register items are documented. An action item register is a list of the corrective action tasks to be completed for just do it items or project findings or needs. They provide the “who, what, where, and when” details of corrective action. The shift review capitalizes on the managers’/supervisors’ and subject matter experts’ ability in making decisions and assigning resources and completion dates around corrective action items in the register. Poor performance to completion dates need to be addressed quickly and with emphasis.
• Weekly Plant Staff/Business Unit Review: On the LSS leader side an organized review of Y variable performance is populated. Projects needing support in championing corrective action, resource shortfalls and recommendations on project deletions, downsizing or additions are addressed based on Y variable variation. This is a good place to allow Black Belts and Green belts to present finished projects/major tollgate work or projects needing high-level support such as capital funding or outside help.

Hope this helps

@cseider The documents do tend to be so!
@ginagentile2000

Scope Stretch – Maybe;Maybe not

If I were to ask, “I have a P vale of .25. Are my findings statistically significant?
I will suggest the answer is, “It depends”

The original question is the same. It depends on the audience and context of the tollgate review.
If the organization holds separate meetings for DMAIC reviews I will suggest the leadership team, bottom top, probably sees the reviews as just another meeting for work some other silo is doing. This has been my experience. There is no context for them.
If everyone has a stake in the game because projects are tied to the important Quality, Waste or Throughput goals that are tied to their bonus, they may be more interested. Even so, if the reviews are more technical reviews than business reviews they will still wander in interest.

So to answer the question in terms of what may be of interest to the mgmt it would be to combine any set of tollgates when sufficient need for some part of the mgmt team to actually get dirty in the project is discovered. Be simple and clear as to what their responsibility to the project is. Is it a need to set up hourly data collection; is it a need to support action register items; is it more capital funding; are more resources needed etc?

A rhythm of review needs to be a mandatory rhythm of review where each of these typical project roadblocks are appropriately handled from leadership, top to bottom.

What percent of projects started, BB & GB, are actually finished and get good support in your experience. In mine, maybe 20% GB and 50% BB because there is no structure for appropriate reviews and mgmt response. When I say finished I mean that a control plan has been defined and actually implemented!

So am I expanding the scope or no?