Troubleshooting and Marksmanship

They both end in ING – so what do Shooting and Troubleshooting have in common?

Part 1 of 2

As a digger I recall the first time I went to the rifle range. Until that day, the rifle we stored in our locker was pretty much the thing I lugged around on my right arm when we did drill on the parade ground. Weighing 4.76kg, or 6% of my body weight, it was a mostly unwelcome appendage during drill.

Our first range practice (live shoot) took place after a couple weeks of weapon handling training, starting with the basics and working through more basics. With an emphasis on safety. Our first range shoot set the tone for my shooting for many years, we marched to the range in winter at Wagga Wagga (Kapooka) and then prepared our rifles. It was cold. I fired my first round with a sense of anticipation and dread, and the kick of the rifle was significant. A few rounds in and my rifle had a stoppage, my Section Commander turned my weapon’s gas setting down to 0, meaning that all the recoil was now coming back through the butt of the weapon. For an experienced digger, no issue – for a week 3 recruit, having half my cheek scratched off, my shoulder bruised and my ego decimated – an issue. Needless to say, I was barely proficient with the rifle.

Fast forward 8 years, now a Sergeant in the Small Arms Replacement Project team running transition training for the Steyr rifle and Minimi machine gun. A Marksman and a proficient Master Coach, teaching small arms techniques for rifle and machine gun.?

We’ll get to shooting and troubleshooting soon …

As a 19 year old digger, who was getting lessons on shaving, ironing, weapon handling, drill, first aid and physical training – no training on Marksmanship principles would have been effective. There was no capacity to take in the key information and learn the skills required to be an effective rifleman. The knowledge dump was too large, and mentally the tank was close to empty.

This is an important point to make. How do you conduct familarisation training with new staff, trainees or graduates? The issue I often see is that the SME tries to teach the most critical elements of the environment, service or solution first. Familarisation or training staff has to provide building blocks of knowledge, and each time a new piece of the baseline is added, it has to relate back to the core overview of the service, there has to be context.

When I instructed technical courses, as soon as I mentioned 3x acronyms that someone did not know, relate to or have context – they were gone. So, I always tried to teach context and the relationship with the services or technologies we had already covered.

During my time in the battalion, we had very few Small Arms Coaches, and diggers were either a good, average or satisfactory shot. In 84 I went to the UK, and they were highly proficient at shooting, with Coaching embedded in their Units. There coaching and shooting skills were significantly better than us, certainly with rifles, but machine gun handling and shooting they were classes above us.

OK, so let’s talk about words ending in ING.

There are four Marksmanship Principles. Now I learnt these as a Corporal, I understood them as a Sergeant, and I became an effective coach; yet in between there were many average days shooting on ranges in NQ and NSW. ?

The Position and Hold must be firm enough to support the weapon.

With the rifle, the soldier ensures that the rifle is supported with the forearms close to vertical as practical. When prone (lying down) this provides bone support for the rifle, not muscle support. The non master hand is pure support, cradling the stock of the rifle (the Steyr and British SA80 weapon it is a handle). The master hand pulls the weapon back into the shoulder, so the rifle is locked by the master hand and secure in the meat of the shoulder. The body is aligned as close as possible behind the rifle so that there is maximum support during the recoil of the weapon.

With a machine gun, the critical skill was to lock the wrists. The non master hand wrapped around the butt behind the trigger, and the wrist locked inwards. The master hand wrapped the trigger guard, and the wrist locked inwards also – but the opposite direction. This secured the machine gun as it fired bursts of 2-3 or 5-10 rounds. Now it’s not like TV – practically only the first round is an aimed round, every other round in a burst is dependent upon the hold of the weapon to determine the proximity to the first round. Hence, the significance of locking the wrists whilst pulling the weapon into the shoulder, with the body aligned directly behind the gun was critical.

Our diggers were capable with a machine gun to at best 500m. In Germany, the unit I was posted to ran an annual range shoot and quite a number of their gunners were effective in engaging targets beyond 800m. It was all about training - we didn’t effectively train our diggers well post Vietnam, because we had a misapprehension that firing 5-10 round bursts was an effective way of engaging targets.

How does this relate to service management?

What are the fundamentals of managing services, troubleshooting, sustainment, problem management? There are a number of core components that support effective service management, and consequently underpin issue and problem resolution.

Documentation is essential, but it’s got to be consumable and relevant. One thing that always struck me about IT in Defence, specifically DMO back in the day, was the requirement to provide detailed engineering documentation, project documentation and sustainment documentation for all Applications and Solutions. It felt like we were going through the engineering requirements for a fighter jet or a Navy ship. Now I appreciate the requirement and security controls required by the ISM, but you have to question documentation that no-one will ever read. Yet it was maintained religiously every minor software or release update. Maybe it was just me.

If I look practically at documentation that is required, I generally consider a core set of documentation to be a Solution Overview, especially critical as new services or applications are added to a Solution. Detailed and High Level Design, with the HL Design being used in the Solution Overview to give a clear relationship between systems, interfaces and dependencies. Build and Configuration documentation are critical, as the Build may be required in a full DR scenario, or to provide a dev or R&D environment for assurance. And then some contentious areas.

What documentation is required to sustain a solution. An Operations Manual or Runbook is essential and requires a checklist of critical tasks to maintain the solution, Daily Weekly Monthly Quarterly and Annual Checklists and SOPs which clearly detail actions required to sustain the system. Administration, Management, Maintenance and Monitoring models, that consider the appropriate level of Alerting for incidents, and Alarms for Performance or Capacity. And templates for Changes to sustain the environment, hopefully defended as Standard Changes for repeatable actions that are defended by detailed SOPs. Business Continuity processes for recovery of elements of the system.

Lastly, Support documentation. Vendors have significant documentation, but the issue is what is unique about our environment? Solution? Security controls? We have not built a SOE on Windows 2022 out of the box, nor have we implemented switches or routers with a base config. Support documentation must include Key Solution risks, dependencies, checks, dashboards of critical and dependent services, and a list of Actions On if the most likely failures occur.

Support documentation does not require engineering documentation. It provides the appropriate level of knowledge for a skilled engineer to understand the solution and dependencies, understand the key threats, and know the likely Actions for incidents that have repeated, or need to be considered as a solution threat. As we encounter issues for a system or application, add them to the Incident KB, and capture the root cause, the alert received, what was successful and unsuccessful to resolve the issue. ?

The last thing anyone needs to deal with under pressure of a P1 or P2 fault is reverse engineering a solution or an application. What are the moving parts? What are the prerequisites for successful service? What are the alerts or alarms configured? What has been built, configured and change controlled, and why? What automated tools have been developed to verify levels of the capability? And what checks should be done to verify the context of a change? And significantly, what does the SME believe are the three biggest threats to the service – and what Actions would they take to check the service?

Cross skill by getting Backup SMEs to implement changes, support upgrades, or be the hands on keyboard for Business Continuity testing. Service documentation has to give a clear understanding of the solution, the configuration, sustainment actions and tools to support the solution.

Configuration and Change management are key tenants of an enterprise capability. But I am comfortable with the by the book offering of those capabilities.

Efficient Service documentation, Change and Configuration management are essential to provide service management and underpin troubleshooting.

One down, three to go … ?Part 2 to follow