Grouping tasks logically together, explains Tim Alden, Commercial Director at Rusada, means fewer individual steps and better oversight of the whole process

Back in early 1993 I got my first introduction to planning complex engineering projects. I was with a major airline operating 747s and the Pylon mod and section 41 modifications had just been released. The facility had been given a target of achieving 1 million man-hours per year and we hadn’t written a single instruction for the shop floor, let alone worked out how it was going to be achieved.

At our disposal were three computer systems and the technical manuals to achieve the job, a situation familiar to most, I’m sure. The computer systems were the ERP (Enterprise Resource Planning), a technical authoring system and a piece of software for project planning. The challenge was to turn engineering instructions into a streamlined series of steps that would record hours and parts usage and help forecast completion against the plan. Whilst considerable effort was put into planning both the work and the disposal of parts, the actual execution of the work to the plan was not that difficult, and that was down mainly to the fact that it was a prescribed, repeatable series of events that could run almost independently of the main overhaul of the aircraft. It wasn’t a small job, it required the re-engineering of all four pylons and mounts and accounted for several thousand man-hours and several hundred individual sign offs. But, it was predictable.

However, overhauling aircraft, as we all know, is not such a prescribed activity; is it? Keep that thought for now.

With a large department of engineers and access to manufacturer and airline documentation we wrote task cards, we allocated parts for pre-load and we embedded diagrams to boost productivity. And remember, all this was back in the early 1990’s.

Next on the list was to tackle the aircraft check as a whole. Now, Boeing used to code their task cards with letters to indicate tasks that could be achieved in parallel and tasks that had to be completed prior to others, in series. That’s great, but not so great when you have work packs with 2,000 or more tasks. Planning down to task level requires an awful lot of research and an awful lot of maintenance – remember, back in those days, programs were still (Maintenance Review Board) MRB 2 derived and so groups of tasks were fairly stable and, as such, ‘what’ was done and ‘when’ was equally stable. As MRB 3 programs began to emerge, gone were B checks and major checks and in came individually controlled tasks (I am of course excluding sampling, hard time and corrosion program tasks from this generalisation). But back then, we embarked on looking at linking tasks together. It was a complete nightmare; investment in planning far outweighed he benefit in work throughput on the shop floor for two very simple reasons:

1. No two maintenance visits were ever exactly the same because of that group of separately scheduled tasks for hard time, CPCP (corrosion prevention and control program), SI etc., each of which influenced other inspection tasks and, more importantly generated the second item;
2. Defects: these little inconveniences were not part of the plan; sure you can estimate the areas that you think might generate defect work but it is not until that aircraft is surrounded by staging and expensive bits of kit have been removed, torches switched on and sealant scraped away do you really discover when that aircraft is expected to depart.

For a start, let me expand a little on item 1. Say you had gone down the route of linking ten tasks in a small group. On aircraft A, it was fine, worked a treat: critical path? No problem: milestones? Here you are boss.

In comes aircraft B with a different mod state, and out goes task number seven, let’s say. But, task number seven used to be the predecessor of tasks number eight and nine. In a static project management system, looking for tasks, now you have a broken link and all of a sudden what you planned to do on day three gets loaded on day one. Now, if you are lucky, out of 2,000 tasks, you spot these little breaks, if not, your resource requirement very quickly goes very strange.

Now let’s think some more about item 2. Yes, most systems either prescribe or at least allow you to enter the number of the routine task you were working on when you found the defect but how many then ask the engineer which task or tasks out of 2,000 cannot be started until that defect has been completed? So again, planning down to task level is a burden.

Did we come up with a solution? Well, the answer is yes; but I will return to that.

Roll forward a couple of years and I find myself with a cargo airline that also has a reasonably successful MRO business. This time however, the team is a handful of guys doing many things, the aircraft are not tier one supported, the customer base is wide and varied, and source documentation is restricted only to the paperwork or microfiche tapes (remember those?) supplied with the aircraft: it was a very different world where variation was the norm. Planning down to task level in this organisation wasn’t just a burden, it was downright impossible with the lead times and availability of information. I decided the best solution would be to explore the solution that we came up with at the airline.

Overhauling aircraft isn’t a prescribed process – really? Of course it is… that aircraft lands; you do pre hangar checks; you dock the aircraft, take it apart, inspect, fix, put it back together, power it up, function it, push it out and then send it on its way. Start to analyse that a bit further and break it down by system or area and you begin to see a logical flow of work. It occurred to us, then, that it makes sense not to plan individual tasks; but small groups of individual similar tasks did make sense. In reality, teams or individuals working on aircraft tend to tackle a group of tasks at the same time based on two factors,

1. Type of work being undertaken at the time, such as removals, functions or…
2. … availability of the aircraft (in terms of physical accessibility, system status etc.)

When you start to think in this manner, the sequence of events becomes more prescribed; the amount of work involved in each of these groups just varies with the type of maintenance visit being planned. So, we created links between these groups and developed algorithms to import the ERP workorder into these groups and allowed the planning software to display the critical path of the check. Where ‘groups’ were not utilized as part of a maintenance process, those groups contained no hours but the logic of progression and dependence remained. Defects were given their own groups and, as defects were raised, the dependant groups delayed accordingly. Altering the durations affected the resultant capacity requirements. Restricting the capacity altered the durations.

As with all new systems it was initially met with scepticism. However, the first time the output date of the aircraft was flagged as soon as a number of defects were raised in a particular area of the aircraft on night shift prior to the daily progress meeting, more credence was given to the system. The same system works regardless of the source of the data – group jobs together by code and apply the logical plan.

This method was applied for several years and, to my knowledge, is still employed in the airline to this day. I have moved on but I still come up against the desire to plan aircraft maintenance. In my current role I see many RFI’s and I meet many different types of aviation organisation and I’m still asked to provide solutions to help plan down to task level. Why?

Finally, here’s another consideration to add into the mix. Today I was at a service centre, an aircraft was on check and the maintenance visit accounted for no more than 300 tasks including defects. The check was phased and groups of tasks were used to show progress against plan. Then an expensive part that should rotate suddenly stopped rotating with devastating results. The lead-time for replacement is five days. The estimate for replacing the item is perhaps only 40 man-hours. Would a system that looks just at man-hour content in a group of work cater for the fact that the work is now effectively suspended due to ‘waiting for spares’? Do I have a plan? Of course I do. What is it, well now, that would be telling wouldn’t it.