Popping into my layout room the other day with no real purpose in mind, I spied a note on one of my staging yard switch panels. The note was reminding me to relabel the panel to clear up an inconsistency between adjacent yard panels.
I have three staging yards (left) along one wall of my layout room stacked one above the other and the 4-yard panels for the three staging yards are similar for each yard. Each panel has a rotary switch to choose the proper staging track. This makes picking a staging track pretty straight forward for my operating crews at the Pittsburgh & South Pennsylvania (P&SP) RR.
So why the note? It seems that for some reason unbeknown to me, I labeled this panel for the middle yard, Wheeling Staging, showing yard track #1 on the wall side of the shelf, whereas the other two yards had track #1 as the first track on the aisle side of the shelf. This inconsistency had not caused major problems but it had caused confusion from time to time if an operator failed to look at the yard panel track diagram before picking their track with the rotary switch, hence the note to self to fix it someday.
I try to remove inconsistencies from my railroad’s infrastructure when I see they create confusion. Operators are busy enough minding their schedule and deciding whether they have the authority to make their movement.
Making the change was rather easy. I used a piece of an old credit card to remove the dry transfer labeling (left) from the track and rotary switch areas and I repainted the rotary switch area.
I waited a day to let the new paint around the rotary switch area dry. The dry transfers were applied and then over-sprayed with dull cote (below) to protect them.
Total time to make the change; about two hours of puttering around. Another inconsistency was cleared from the P&SP.
For this article, I have used the term “informal operating systems” to differentiate less structured approaches from prototype-based operating systems. Steve King has used the term “fun run,” but I feel that term, while easily understandable, does an injustice to both approaches to operations. Those interested in prototype-based operations would not participate if they were not having “fun,” and those, who prefer a more relaxed experience, still want to learn about how the prototype does things. Consequently, I find the term “informal operating systems” more useful and less pejorative.
In Part 1 of this article, we learned that adopting an informal operating system does not always result in the relaxed experience desired. In Part 2, we want to figure out how to establish some basic organizing principles for informal operating sessions and then find ways to communicate those principles to crews (in order to give them the information they need to do their jobs).
Basic organization: To avoid chaotic situations, any operating system must have some basic level of organization; however, the effort to organize operations can seem quite formidable, full of big issues to be addressed – kind of like the big task of getting a coal drag up a steep hill without helpers. I would like to make some suggestions to make that process a bit less intimidating.
First, remember model railroading is not a matter of life and death; it is our hobby.A layout can still be fun even if the operating system is not organized as completely as we might want it to be.
Second, getting organized is a process. I suggest you take it one step at a time:try decisions out, see what works (or doesn’t), make adjustments, and move forward from there. (Repeat as necessary.) If you do that, you will find yourself less intimidated. (Remember friends can also help you see things from a different perspective.)
How do we figure out what step to tackle first?My suggestion is to start with a series of six fairly straight-forward questions that focus on the trains you want to run. This approach sidesteps big issues such as the railroad’s purpose, goals and objectives for sessions; an appropriate level of traffic management; a sense of time as it relates to the session; and a system of car forwarding. Once you get operating, ways to address those issues are likely to reveal themselves.
The following is a sort of Abbott and Costello list of questions. (Remember “Who’s on first?”)Hopefully, this list is a bit less crazy.
Why does this train run?
Who runs this train?
Where does this train run?
When does this train run?
How do you run this train, and how do you coordinate its work with the work of other trains?
What happens to the cars in this train?
How can you come up with answers? Before you actually ask the six questions, what process will you use to find the answers? First, it is best not to concentrate on possible consequences of your answers. Remember you don’t have to get the “right” answer the first time. Second, you do not even have to come up with your own answers. Through the years, model railroaders have developed numerous ideas for addressing these matters; you do not have to reinvent the wheel. Let us take a quick look at some ways you can find possible answers:
Research: You can learn what the prototype and other modelers have done from reading articles in model magazines. I recommend articles about both model and prototype operations. Learn how modelers and prototype railroads have dealt with these questions. Some of the articles may be useful; others not. Try out what seems best. Note that this research may result in your reading articles advocating more formal prototype-based operating systems than you are looking for if you are considering informal systems. Read some of those articles anyway to get a good idea of the organizational issues prototypes and other modelers have dealt with.
Your operating experiences and preferences: What have you experienced in sessions on other people’s railroads? What did you like (and wish to include in your system)? What did you not like (and wish to avoid)?
Your crews’ experiences and preferences: Talk with the people most likely to be crew members, and find out what they prefer.Take that information into account, but do not let it override your ultimate goals and objectives for operating sessions. (SMD member Don Florwick began operating with a crew who preferred informal sessions, but that wasn’t what he had envisioned for his railroad. He used those informal sessions to work out the bugs and then moved on to a more formal TT/TO system.)
Once you have some tentative, first answers using steps A – C, you can then move on to steps D and E. Remember that finding answers is a process; so don’t be frustrated if your first efforts prove unworkable. Set unworkable answers aside, and try again.
Trial and error/beta testing: Start using the rough answers you have. Be patient. (SMD members Pete and Jane Clarke spent years operating their HOn3 East Broad Top, constantly refining their system, until they arrived at the system they use today.) Do not be afraid to make changes to correct things that are not accomplishing what you want.
Feedback from your crews: Remember they have different expectations and experiences from yours. Take advantage of that fact as you refine your answers (and eventually your operating system).
Elaborating on the six questions: Now, let us look at the questions again in more detail, and figure out how to find answers and communicate them to your crews.
Why does this train run? What is its purpose? What does it do? What customer(s) does it serve? Since your railroad is different from everyone else’s, the trains you run will be unique in some way.Each of those trains has its own special role in developing the overall concept of your railroad’s purpose and the operating session’s goals and objectives. Answering the “why” questions will also give you an idea of how this train fits your railroad’s overall scheme.
Once you have determined each train’s purpose, the best way to share that purpose with the crew is with a brief train description at the beginning of the train instructions. A sentence or two should suffice – something short enough for the crew to read before beginning their run.(Remember the hubbub that accompanies the start of every operation session).
Who runs this train?This is a two-pronged question.
Was the layout designed for one/two operators or for a large group? The answers lie in the design of your layout: for instance, the size and capacity of the aisles, the kind of railroad, the number and spacing of towns served, and the expected number of trains to be run in a session. After you have answered these questions, you can use those answers to determine how many crew members you need for your sessions and how many you can accommodate.
Once the crews arrive, who gets assigned to a specific train (or job)? Will you assign by arrival order (first there gets first choice), by experience (such as assigning veterans to dispatching and yard master positions), by sign-up sheet, etc? You have to decide and let your crew know in your orientation briefing.
Where does this train run? Where does it start from; where does it terminate?Where does the train have to go in order to do its job? Where does it interact with other trains?Your answers to the “why” question will point you in the direction of answers to these “where” questions. After you figure out answers for one train, move onto the second, third, and so on.Since this question relates to the “when” question, you may have to revise the answers later on.
For crews, “where” questions should be addressed briefly in the train description (especially where the train originates, works, has meets, and terminates). Somewhat more detailed answers can then be provided in the body of the train instructions. (Remember, at the beginning of the session, it is best to keep the amount of required reading minimal.) Additionally, crews need help orienting where they are within the layout room. They need schematic layout diagrams/maps (giving place names and yard locations along the main line), location signs at those places, as well as more detailed diagrams/maps indicating where specific tracks and industries are. It is crucial that the names of these places be consistent with names used in paperwork.
When does this train run? For informal operating systems, time is perhaps the most complicated question because getting away from the pressures of time is one of the main reasons for taking the informal approach in the first place. Unfortunately, you have to address the time question. Easy prototype-based answers like clocks and timetables are likely to be too formal for you and your crews; so you must come up with a way to determine when a train should be on a given track.(Otherwise, collisions will happen.)
To do so, you will probably need some sort of rough schedule. That can be developed before regular sessions begin and later reflected in the instructions given to crews. (They may not ever need to consult the schedule.) To develop a rough schedule, you should start by making a list of trains in the chronological order you want them to run. Then, you will need to find out how long it takes to run each train in order to figure out when and, consequently, where that train will meet other trains. These are trial and error investigations that you can make before regular operating sessions begin. (Be aware that there may be more stress than desirable during this testing period, but keep in mind that you are trying to find ways to eliminate that stress when you move on to your regular sessions.)
Over the years, we model railroaders have come up with quite a few ways to address the time issue without going to the lengths to which the prototype goes. Among the options we have tried are verbal authorization (mother, may I? sessions), sequence schedules (trains in chronological order), operating scripts (think of Frank Ellison’s comparison of operating sessions with scripts for plays), and train instructions. Some of these work better than others as discussed in Part 1. (Regardless,, there are numerous options to choose from. I plan to discuss some of them in future articles.) To my way of thinking, how you answer the time question is crucial if you want to develop a relaxing, informal operating system for your railroad.
Your best way to give crews time-related information will be the detailed train instructions (following the initial description of why and where the train is run). Be clear and complete.Remember crews won’t see the schedule.
How do you run this train, and how do you coordinate its work with the work of other trains? Start by focusing on each train separately. Figure out how it should do what it is supposed to do. Then factor in how the operation of other trains will affect the one you are considering and make adjustments. Beta testing and trial & error are good ways to develop detailed, coordinated answers for these questions. Again, detailed train instructions are the informal way to communicate this information to crews.
For crews, “how” becomes a two part question:
How a crew runs this train is best conveyed by the train instructions. The level of detail in the instructions relates to the kind of session you want: one that expects train crews to read lengthy, instructions with lots of rules to follow or one that is more relaxed and open. Bulleted directions, grouped under headings for each of the places where events happen, are one way to simplify train instructions and to make them easier to read one at a time.
How a crew coordinates its train’s work with the work of other trains relates to the places (where) and times (when) trains must interact with each other: passes, meets, and multiple trains working in the same location. You want crews to have a basic familiarity with what is happening during the session (especially as it relates to their train) without having to consult a complicated timetable. Again, good train instructions can provide sufficient information and clear up any required matters of train superiority. Unexpected situations can then be handled by train orders (verbal or written).
What happens to the cars in this train? Clearly, you will need some sort of car forwarding system. We model railroaders have quite a few of these from which to choose: car cards and waybills, switch lists, color-coded tacks, car-for-car exchanges, etc. Based on your experience and preferences, choose the one that seems best suited to what your railroad does, then try it, and see how it works. Try another system if the first does not work out. Revise as necessary.
For some kinds of traffic (passenger trains and unit trains, for instance), train instructions alone may serve; however, for general freight traffic, you will likely need a more detailed system giving crews specific directions about where to spot and pick up cars as they run their trains. In setting up a more detailed system, try to keep the information you give crews as brief as possible: type of car, reporting marks, number, and destination may be all the information they will need.
Conclusion: The questions I have suggested are one way to focus on the trains you wish to run and to use those trains as a start to organizing the larger operating system for your railroad. As I said earlier, this approach sidesteps the big issues, but beginning to operate is likely to reveal ways to address those issues.
One important thing to note about the process of answering these questions is that the answers you come up with do not necessarily have to be shared in their totality with your crews – for instance, the rough schedule you developed to answer the “when” question. Your crews probably will not need to refer to that schedule during the actual session – especially if they have train instructions telling them when and where to meet other trains. In other words, your railroad can have a whole layer of “complicated organization” of which your crews can remain blissfully unaware.
With these questions spelled out, we have come to the end of this article and, hopefully the beginning of your quest for the operating system that is right for your railroad. What we have discovered is that setting up an informal operating system is a bit more complicated than we might have imagined. We have realized that just because we want to run trains in a relaxed fashion, we still have to address some basic organizational questions in order to give crews the information they need to get their “jobs” done. The prototype had to answer these questions; so do we. Your goals may be different from the prototype’s, but by answering these questions, you can develop enjoyable, relaxing sessions for your crews (and in the process, give them opportunities to experience and learn more about what prototype railroads do). You want your crews to operate in a calm, “professional,” capable, and relaxed manner.
If you decide an informal operating system is right for you, you will probably want to know about specific alternatives to prototype procedures. Some of these alternatives may not be widely known. For instance, you may have experienced the often chaotic “Mother, may I?” type of session and want a more “professional” type of session. (In this case, perhaps, a “dispatcher, may I?” approach will work better.) Or you may be familiar with formal train orders (prototype-based), but not aware of fill-in-the-blank train orders (more informal).
For this article, I have used the term “informal operating systems” to differentiate less structured approaches from prototype-based operating systems. Steve King has used the term “fun run,” but I feel that term, while easily understandable, does an injustice to both approaches to operations. Those interested in prototype-based operations would not participate if they were not having “fun,” and those, who prefer a more relaxed experience, still want to learn about how the prototype does things. Consequently, I find the term “informal operating systems” more useful and less pejorative. (At the recent NMRA National Convention in Salt Lake City, there was a clinic titled “Operations without the Aggravation.” I find that also an effective way to label less formal approaches.)
Over the years, we have all been harangued by articles and clinics touting the benefits of prototype-based operating systems (TT/TO, track warrants, etc.). The main reason given is that prototype railroads have developed, tested, and refined these systems for many years in the real world, addressing the many situations that come up when operating a railroad. Why would anyone want to re-invent that wheel? Clearly, developing an operating system is not a simple task. Why not use a system already developed and tested?
While this argument is very convincing, it ignores an important fact – prototype operations are very different from model railroad operations. First, prototype railroads are businesses; model railroads are part of our hobby. Second, prototype railroading can be deadly serious; model railroading is supposed to be fun. Third, prototype railroaders are trained professionals; model railroaders are, for the most part, interested, sometimes informed amateurs. Whatever system of operations we choose, whether prototype-based or other, must address these differences.
The goals for prototype-based versus informal model railroad operating systems:
Prototype-based operating systems:
To experience operating the model railroad as closely as possible to the way we might experience operating the prototype,
To have an enjoyable and challenging experience with people knowledgeable about railroads,
To meet the session’s challenges with the tools developed by prototype railroads, and
To replicate the work prototype railroads do.(Creativity is not OK.)
Informal operating systems:
To experience the model railroad in a railroad-like fashion,
To have an enjoyable and relaxing experience with other people interested in railroads,
To pretend we are professional railroaders (somewhat like re-enactors) and, from that effort, to learn things about prototype railroading, and
To find solutions to the situations that come up without having to make efforts that are too much like work. (Creativity is fine.)
While these two sets of goals are not completely different, the emphasis certainly is different between them. Those differences greatly affect the operating system appropriate for a given model railroad. It may have been designed for prototype-based operations, and then again, it may not have been. Crew members may be interested in the challenges of prototype-based operations, or they may be more interested in a relaxing, enjoyable time spent with friends and acquaintances. The prototype being modeled may be a heavily trafficked mainline, or it could be a backwoods branch with two trains a day. Each of these sets of circumstances warrants a “custom” approach.
Prototype railroads understand that fact and address different situations with rules customized for each region and each operating district. “One size fits all” does not work for the prototype; unsurprisingly, that approach does not work for all model railroads either.
Problems with prototype based operating systems: Crews not interested in prototype-based operating systems have voiced numerous complaints. The following are some of the characteristics of prototype-based operations that superintendents might want to avoid:
Too much paperwork: During the often hectic flow of the session, it is often impossible to find time to read, much less deal with, a sheaf of papers, especially when the piece of information needed is buried where it cannot be found easily.
Hard-to read paperwork: The effort to make keep instructions and information easy to handle, often results in making them unreadable except with a magnifying glass. Also handwritten entries on forms are often illegible.
Rule books – too much to remember.
Clearances: Written clearances are an example of excess paperwork.
In-depth pre-session introductory material and long verbal orientations – again too much to remember.
Timetables, clocks and fast time: Crews want to watch their trains, not the clock (too much like work). Besides, a timetable is not easy to read while trying to run a train.
Reporting requirements: Having to pick up the phone or radio every few minutes can be quite distracting.
Complicated train instructions: Brevity and simplicity should be the main goal. Crews should be able to find what they need to do easily.
Train orders written in “railroad English:” Prototype railroaders would understand; model railroad crews might not.
Car forwarding information: Whether car cards, switch lists, or other systems are used, there is often much more information than needed. Also, carrying a large stack of cards around is always a challenge.
Undoubtedly, there are other problems crews might have with prototype-based operating systems, but the above list will suffice for now. (As will be discussed below, some of these items are essential for running a railroad.)
Problems with informal operating systems: After considering the numerous problems common to prototype operating systems, it is tempting to conclude that, by adopting an informal operating system, we can address all those issues and eliminate the things to which crews might object.
However, informal systems come with their own set of problems – a couple of them major. 1) By adopting informal procedures, we have essentially discarded the administrative organization that works so well for managing prototype traffic.
2) Crews may not have the information and directions they need to do their jobs. Between these two problems, it is almost certain that difficulties will arise. The following are some of the potentially maddening situations that develop when using informal operating systems:
Sessions degenerate into confusion: This is perhaps the most serious criticism of the Mother, may I? operating system. Crews (sometimes behaving like spoiled children) all cry out for the host’s attention at the same time. As the number of problems encountered multiplies, the volume of cries increases. The host has far too much to deal with; the session becomes a confused mess.
Situations get resolved without taking into account the railroad’s overall objectives: This problem arises when crews take it upon themselves to resolve a conflict by gentlemen’s agreement – such as the problem of too many trains in one location. The resolution may be quite creative; it may be quite satisfying. But, if the through freight gets held up by the local, that resolution is not the right one.
Worst of all, the crews involved miss an opportunity to experience how the prototype might resolve a similar problem.
Crews blithely unaware of anything but their own train: That might work on a backwoods branch or a one-train-a-day shortline, but when more than one train is running, crews need to be aware of other trains and to coordinate their efforts with those of other crews. (This issue also comes into play when crews have to share aisle space.)
Operating systems that do not address all aspects of operating the railroad: For instance, some layout owners consider having a car card system to be the same as having an operating system. That approach does not consider traffic management, and the car cards lack much of the information crews need to do their jobs. Crews have no sense of time, no information about other trains, no understanding of the superiority of trains, and no authority to use a specific track (in fact, no instructions about which track their train should be on). Confusion reigns. Of necessity, figuring out how to do a given job becomes the primary effort for the session. Enjoyment comes in a distant second.
The result of these situations can be an atmosphere of “chaos,” an atmosphere not conducive to having a relaxing, enjoyable time. Because crews do not have the information they need to do their jobs, they feel uncomfortable. They cannot enjoy themselves – the main reason for adopting informal operations in the first place.
What have we learned? Prototype-based operating systems come with quite a few rules and procedures: things that crews looking for a relaxed operating experience might object to.Adopting an informal operating system seems like a good way to avoid those objections. But informal systems often cast aside the organization needed to run a model railroad and often fail to give crews information needed to do their jobs. The result can be chaotic, quite the opposite of the relaxing, enjoyable experience desired.
Adopting an informal operating system does not have to degenerate into chaos if some effort is put in place to establish basic organizing principles and to give crews the information they need to do their jobs.
Part two of this article will endeavor to discover ways to correct the deficiencies of informal operating systems and will open discussion of the enjoyment possible when adopting such informal systems.
The Liberty Bell Convention will offer operations on the New Jersey Free-Mo HO scale modules throughout most of the convention weekend. While participating in operations or just viewing the modules, you’ll be able to admire the fine craftsmanship and modeling of the two module sets presented by the New Jersey Free-Mo group. Also, you’ll learn of the historic and prototypical significance of each module set.
Bill Grosse’s “Yardville” module features a look at the Pennsylvania Railroad’s presence in this small New Jersey town circa 1955. Part of the original Camden & Amboy line that successfully ran one of the first steam engines in the country in the 1830’s, Bill has represented the area very well with his modeling of local industries and customers along the line with superb details and interesting features of Yardville. If you like switching and spotting cars, Bill’s module offers plenty of operational opportunities that will challenge your skills and provide lots of fun and excitement.
Mike Prokop’s “Linden Street Freight Station” module is a late 1950’s replica ofthe Reading Railroad’s facility on the Camden, NJ waterfront. Built to almost the exact prototype of the Reading property, this module operates just like the real thing. It features car float operations loading and unloading coal and freight cars. Coal is switched onto two raised trestles for truck transfer with freight spotted at the station and public delivery siding for processing. Transfer runs in and out of the facility offer additional challenges to operations. Mike’s Free-Mo module set was featured in the 2019 issue of Model Railroad Planning. If you have a copy, check it out and come operate on it in person.
One last note…when Mike and Bill connect up their modules, they generate plenty of traffic and car loadings between Camden and Yardville that keeps operations moving at a brisk pace. So, whether you’re an experienced operator or a beginner interested in learning and jumping into this fascinating part of the hobby, come operate on the New Jersey Free-Mo module setup. More details and information about operating times and format will be available in future newsletters and at the Liberty Bell Convention.
Hi guys,
I was out in the Cincy Ohio area this past week – running trains on two great EBT layouts. While there I was asked if I’d help spread the word of this up-coming event.
I’ve operated on both the EBT layouts (what a surprise) and have seen at least 2 of the others. All are excellent layouts. While it’s a long drive, I’m sure anyone who goes would find it well worth the trip.
Pete Clarke
Richard Stern’s Santa Fe.
Don’t miss SWOOPS, 2019! The SouthWest Ohio OPS weekend
20 Great Railroads, many nationally known
3 days/2 nights of operating fun, camaraderie, and the chance to gather ideas for your own layout.
I have three staging yards (left) along one wall of my layout room stacked one above the other and the 4-yard panels for the three staging yards are similar for each yard. Each panel has a rotary switch to choose the proper staging track. This makes picking a staging track pretty straight forward for my operating crews at the Pittsburgh & South Pennsylvania (P&SP) RR.
Making the change was rather easy. I used a piece of an old credit card to remove the dry transfer labeling (left) from the track and rotary switch areas and I repainted the rotary switch area.
I waited a day to let the new paint around the rotary switch area dry. The dry transfers were applied and then over-sprayed with dull cote (below) to protect them.
