Please login or join to subscribe to this thread
Troubleshooting efforts deal primarily with unknowns, and as such are best governed by processes like the one you detailed. It seems your management wants to feel it has control over the EIT effort, which it why it insists on trying to manage it like a typical project. I don’t see how Scrum or even a simple Kanban board can help you significantly improve your current process. That said, an Ishikawa diagram (fishbone diagram) could help you identify the root causes of your problems faster by helping you categorize the many unknowns you deal with (assuming you’re not already using one).
I don't really feel qualified to comment on how you should handle a nuclear reactor - generally, I have a hands-off policy on things that can burn you through walls.
My initial thinking would be to pursue more Lean centered practices, maybe not full-blown Agile. Lean elements could include Kaizen events to find areas that could be improved, continuously looking for ways to reduce wasted steps in the process. 5S to ensure the place is tidy and organized so you can find what you need when you need it.
A standardized process for how to do things should be created within that.
How about trying more of the philosophy of building quality in rather than testing it in? A high-quality, mature process is characterized by not having the kinds of emergent issues you described. More risk analysis, more Ishikawa diagrams, etc. can help you to identify and proactively manage risks, and improve systems and processes so that they don't create emergent issues during routine maintenance. This is especially important for systems that pose a potential public health and security problem.
Kanban with different classes of work items (e.g. expedite vs. normal priority) would seem to be a good starting point. I'd also focus on forming a whole self-managed, self-organizing team to minimize delays due to missing skill sets or decision making.
First I want to thank you all for your inputs. In order, Mr. Simms writes that my current management model may be the best. And he posited that pressure from management to "control" troubleshooting activities accounts for insistence on using straight - line management (waterfall) techniques. I am in agreement with the latter. Not all senior management are very sophisticated in their thinking when it comes to non-linear high risk efforts with multiple decisions. Some are the "It's simple math! 9 women, 1 month, ya got a baby!" types. But he is right in that kanban cards are not really useful in troubleshooting. Scrum, with some of the time-constrained tools used there may be of some use. One thing I personally use is the Agile Servant Leadership role, as a Nuclear plant is a large complex system. No one leader will have the technical knowledge for cross-cutting troubleshooting, but he might know how to use and teach the use of the tools to perform the troubleshooting.
Mr Render.... Don't be skeered! When ya got Nooklar perfessushnils like us'n runnin' the show, whut's ta go wrong? Seriously, I will research more into Lean concepts to mine for tools and methods and incorporate into my EITs. Right now I am working on number 62 emergent issue requiring a team to address over the past 80 days.
Mr Isom.... You are preaching to the choir. Almost without fail the emergent issues I have to address are a result of ineffective contingency planning. The managers and supervisors discount the risk instead of planning for the worst, and then are caught pants down without work planning, materials available or specialty workforce available.
And Mr Bondale.... I'm not sure at all about hi vs lo priority for EIT Troubleshooting. By definition we are high priority. But the self organizing / self managing is spot on. The problem is, we are very much "in the spotlight", and every blood-sniffing shark is attracted to the smell and delight in pot-shotting the plan and resulting decisions.
There are a couple of things I am looking for that the forum may know of and can point me to. One is a classroom lean/agile/scrum or omnibus course that IS NOT SOFTWARE!
I don't really want an online course, I want to ask questions of live people.
The other I might have to build. I want a computer graphic too that combines PERT charting for critical path and incorporates a decision tree. This would be great for troubleshooting. The nodes would be the ends of activities or decisions and have no duration. The arrows would have the duration and be represented with proportional length. As the troubleshooting progresses, the manager selects the arrows completed and takes credit for the nodes as milestones. Software in the background then calculates the critical path as each decision is made, and tracks changes over time to the critical path.
What do you think? Would it sell?
I can't claim to know of any sources for Agile not dedicated to software for education except for like 1 online course in Kanban. I wish I knew of more, I would take them myself.
Lean should be much easier. I wouldn't be surprised if local community colleges offer classes on it. They may be manufacturing focused, which might not actually be too far off of what you need. ASQ I think offers classes where they will come to you and train your team. http://asq.org/lean-manufacturing/training.html
I worked in this type of environments before Agile exists and we use Barry Bohem´s Spiral life cycle. We used kanban because kanban is an ancient technique that was used and is used in manufacturing and inventory control from long time ago. Remember that Agile is not a life cycle. Returning to waterfall most of the people confuse waterfall with sequential. In waterfall you have feedback loops. So, is about to find the life cycle that best fit for your environment.
Please login or join to reply