Necessary Roughness

I teach internally written job workflow and tracking software. Business development people write proposals with one part of the program, and operations people use information from the proposals to verify the job design, dispatch the appropriate chemicals, people, and equipment to location, create invoices, and collect job results. Teaching requires not only aptitude in instruction techniques but oilfield experience, job design knowledge, and a little computer science.

Students come to class with a wide variety of operational experience and computer familiarity. We can get people newly hired to 30 years in the company. People can have a high school education or degrees in Chemical, Mechanical, and Petroleum Engineering.

It’s understandable that people without a lot of computer familiarity have trouble initially. They are more than quick to lower their own expectations of what they think they can do, as if they have been conditioned. Most have the required computer skills without realizing it: they know the mouse and clicking, powering up and shutting down.

Part of the trouble lies in that today’s software is event-driven. Buttons, scrollbars, window borders, tabs, and grids give the user all sorts of things they can do. Click a Cancel, Minimize, Start, or something else instead of the Save button in the proper window, and one can lose data or appear to lose data, both of which do not promote user confidence. In the old days of DOS and console programs, the computer asked the users what they wanted to do and provided a prompt. Options were pretty limited, so the chance of getting the “right” answer was much higher.

The more experienced personnel want to be taught “the one way”, when in actually one can enter information in one window, leave it, come back and enter some more, flip a tab, and enter some more information. All of which is “right” as long as the information appears in the right spots. Some get it, but there are tougher cases. For those people I have a handout of the simplest way I know to go about things.

It is important for me to emphasize in class that the software we are using is merely a replacement for what they had been doing before. I get them to think about what happens in the course of their job: they get a phone call, come into the office, pick up the paperwork, review it for anything they need, go to the job, get it done, invoice the customer, and come back to the office. Basic business processes: the same stuff Halliburton has done for over 70 years, give or take a few nefarious federal regulations. They are most comfortable when taught this way.

New hires, though, can have the opposite reaction. They understand the concept of an “active window” and know not to click outside, but sometimes they don’t relate the program’s operation to field business practice. The class goes faster and I don’t have to point out items on the screen, but I find later that they skip the attention to detail that experience hammers into the veterans. They can leave the yard without making sure they have all the information they need for the job. When I point out a commonly made mistake, they think it won’t happen to them until they hit it. They’re bored silly in class while the veterans think the process through. I have to maintain their interest by asking them questions about what happens in the field or by having them design a job right there to be entered into the program. In this way the advanced group can actually be a harder bunch to teach.

Another difficulty stems from the fact that we have one program that intends to meet the disparate needs of our global company. In some areas we have a lot of jobs without much detail, so speed is important. In other areas, like the North Sea and the Gulf of Mexico, a lot of detail is required to satisfy government regulations. When we start training in a new area, personnel may say, “we don’t do that here” or “where do we enter so-and-so?” Our developers, with input from trainers and “product champions”, try to organize the program to require little data but accommodate a lot. It is only been recently where our reports expand or contract according to the nature of the information entered in the program. This was a big win on the part of our developers.

I welcome the challenges in teaching our multitalented work force, with the exception of the travel schedule. Theoretically we should be able to cut this down, as how far an instructor travels doesn’t directly affect how someone learns. With today’s software (Microsoft Netmeeting the de facto standard), I can see someone else’s screen on my laptop. The software is limited in that I can’t resize what is shown on my laptop to show more than one screen, so that I could teach more than one person remotely. If we could obtain screen-sharing software that lets me see the screens of everyone in the classroom, on a big enough monitor, I could write a business case to make training a lot cheaper and save my sanity.