The Job: As a ship superintendent at the US Coast Guard Yard in Baltimore, MD, I was essentially a project manager for major depot level repair of ships ranging in size from 110’ Patrol ships to 378’ High endurance light frigates. I was responsible for managing eleven different trades and coordinating a workforce of over 450 permanent civilian employees, not including the numerous sub contractors. (There were 7 of us ship superintendents, and each of us had 1-2 ships and sometimes additional special projects that shared these resources.) The bulk of the work done here was repair and upgrade of existing ships. There was very little pure ‘design’ happening here, but we did have to ‘engineer’ upgrades and improvements because existing equipment was ineffective, not effective for a new mission, or no longer supported. There was, however, workforce management of technical trades to the extreme. A ship is a complex as a small town, squeezed into less than 1 percent of the space. Everything is on top of and interfering with everything else. Every work item of a package affected every other work item. Every ship competed for resources with every other ship. Budgets were nearly fixed and keeping the schedule was critical to the function of the Coast Guards mission effectiveness.
Spec development: Developed coordinated by the ships crew, the ships shore side support infrastructure, the CG YARD, and the larger CG Command structure. Items included renewal of the underbody paint, engine overhaul, replacement, habitability upgrades, weapons systems overhauls, command and control system upgrades, structural repair, major scheduled maintenance to all major systems, the list goes on. Everything that was to be done to the ship had to be documented in the specification as clearly as possible. Many of the parts needed for the specialized systems had delivery times of months. A missing part can be a show stopper. This was also the first time the Ship Superintendent can begin to manage expectations. Each customer is different. Some ship commanders understood the complexities of the ships they were in charge of, and did not take much attention. Others flat out refused to understand why everything couldn’t be done in 10 minutes. Most fell somewhere in-between. The sooner you are honest with a customer, the sooner you can make sure they stay part of the project, the better. There will be miscommunications, and mistakes. Maintaining a personal yet professional relationship means that miscommunications get cleared up quickly and most mistakes are forgiven and resolved concurrently. As a manager, it must be abundantly clear that your primary focus is the job and that everyone working on the job is a close second. Even if one does not possess the slightest iota of natural personal skills, a focus on the job will warrant some measure of followership. Here, we were face to face with all of the major players and it was a perfect opportunity to walk around the ship, ask a ton of questions, write everything down, and show all the players that we were going to work very hard at this, and that we were going to expect everybody else to work hard at this too.
Risk assessment: Some risk was spoken of at the spec development meeting above, but we waited until we had a good draft spec (usually the 2nd or 3rd revision) before doing an official risk assessment meeting. This was still several months before the ship actually arrived. (A note on forethought here, while we did the spec development process and much of the other lead up, we still had other ships high and dry that we were responsible for. Organization is critical, and it is critical to make sure you are prepared for the future, regardless of what ‘fires you are putting out’ right now.) At the Risk assessment meeting, we brought in foremen from every major trade, put a spec in front of each of them (most actually read the spec before the meeting), projected a preliminary schedule on the wall, and went through each work item. It worked out that the foremen would talk about how difficult and how much time each item would take them, and that the ship superintendent would ask questions to find out how much each item interfered with each other. This was critical to sequencing the work. In essence, this team would ‘design’ the repair period, sequencing events, augmenting work items with contractors and extra shifts, discovering what expectations were impossible given the time period. Each item was categorized as green, yellow, or red. Green were well within capabilities, yellow were items of concern that warranted additional resources or time, and red meant we took that work item back to the spec development team (via email or conf. call) and attempted a compromise, either postponing a work item to another maintenance availability, having a contractor do it at the ships home port, or modifying the work item for it to fit into the existing package. Finding solutions to such problems is a communication process because no matter how much one tries, it’s very very difficult to completely understand the customers desires.
Estimate development: Based largely on historical data, a team of estimators would build a cost estimate for the availability. (The YARD did not work like a private enterprise, but charged parts and labor for everything. Cost overruns cost the ‘customer’ more, but coming under ‘budget’ returned money to the customer. A vastly different animal from private enterprise.) The detailed cost estimates were compared to the ‘back of the envelope’ estimates developed at the spec development meeting and communicated to the customer. Those that were vastly different warranted further (sometimes heated) discussion. It’s pretty important to make clear that the spec development meeting estimates are by no means ‘official’ and are not even guaranteed to order of magnitude. But, if one has managed the personalities (primarily through a overt dedication to the job) this process can be very smooth no matter what the bad news.
Scheduling: This process started with spec development, but at YARD we have a scheduling program. Part of the detailed estimate was estimating how many man hours each job would take. This information, with the preliminary work order schedule worked out during the previous meetings, was imported into a master scheduler that had timelines listed for each work item. Work items that could not be done at the same time due to space considerations, or work items that were dependent on others could be set ‘end to end’. The schedulers would work with the ship superintendent to make sure that high risk work items were addressed first. Even before the ships arrival, the schedule would take into consideration the parts procurement and dry dock preparation process. Throughout the entire process, this program would be used to print off a sheet for each trade every day with task listing (down to a minute level, such as “Remove bolts for tank cover” listed as a different item as “Remove tank manhole cover”). These lists often seemed pedantic and silly ‘to do list’ given to people who had been doing their jobs longer than I had been alive, and sometimes they listed things in the wrong order, and they were something that foremen complained about. They were also a very valuable tool. Each task, once done, was marked off as done on these sheets. If the task was started but not done, the ‘days until complete’ was listed. This was fed back into the software and gave an update on how well we were sticking to the plan. The scheduling software often required some ‘correction’ when it happened to show some strange timeline estimates, but it was a valuable master checklist of each task that needs to be done in a major availability. Probably the most interesting aspect of the software is that we cut our estimated time to complete each task in half. Looking at a schedule at the beginning of a 10 week dry docking, it said we would be done in about 5 and a half weeks. It’s a way to dangle a carrot in front of us. If we blow a artificial deadline that keeps us in the real deadline, we use that as a psychological ‘warning shot’ that something may threaten the schedule. We also showed this incredibly optimistic schedule to the customer at the arrival conference (discussed later). Some understood what were doing, others wanted the 4 and a half weeks back. Another potential for some heated discussion.
Negotiation: This process is really always happening. Regardless, there was an official teleconference for negotiation to the final specification revision. Really, this was a line in the sand. After this meeting, there were no more changes to the specification, and the specification was given the status of ‘gospel’. If there were significant changes to the customers desires after this, it was very hard to enact them. Even if the changes were not significant, we held this card that we could stick to the spec regardless. This is again different from private industry, but we really stuck to this for the protection of all the other projects that relied on the CG YARD. Here, we also discussed finances and really communicated any items of high risk we found in the risk assessment above and gave the customer the chance to avoid that risk (and the potential reward) by cancelling, delaying, or modifying the work item. The most contentious work items required ‘prototype’ installs. Sometimes we were given a tasker that basically said “here are the parts, make it work”. This would turn into a higher risk ‘design on the fly’ shipfitting problem solving exercise. These were mentally stimulating, challenging, and fun, but higher risk.
Parts procurement: Discussed above, this process happens throughout the lead up. Some parts were bought by the YARD, some by the ship, and some by the ships shoreside support commands. Very confusing to keep track of ensuring all the parts are ordered and slated to be delivered on time, complicated by the very restricting US codes for government procurement. This is a huge time sink for the ship superintendent, and was the most critical resource for management to consider prior to ship arrival. Here, good organization is paramount. Some ships were more ‘on the ball’ than others when it came to getting the parts they were promising to provide. Some ships required ‘if-then’ threats to prompt action. The lines of responsibility are very often blurry, but when they are clearly defined, one must make sure they stay clearly defined.
Arrival conference: Once the ship arrived at the CG Yard, the first major face to face meeting with the senior command at the Yard and the ships officers was held. If the ‘tone’ for the project was not yet set, this was the place to make final role clarifications, deliver the first update (primarily part procurement process), and discuss the technical aspects of the drydocking process.
Dry dock conference: At the end of the arrival conference, we usually rolled right into the drydocking conference. Without getting into the technical details, drydocking a ship is one of the riskiest things that can be done to a large vessel. A mistake here really can turn a multi-million dollar ship into a very expensive scrap cleanup operation. As such, it is a significant exercise in co-ordination requiring the ships crew, tug operators, machinery operators, carpenters, and engineers.
Drydocking: An all day event, usually. The Ship Supt is on the ship for this (the most dangerous spot) usually communicating with the crew having them operate ships machinery and handle lines for positioning the ship in the docking basin.
Repair operations: Finally, where the ‘rubber meets the road’. Here is where preparation either pays off, or a lack of preparation results in disaster. The most important phase of the Ship Superintendents role is already complete. From here on out, the name of the game is to carry out the carefully constructed plan as well as possible.
Daily progress meetings: These were discussed some above. Each day, usually on the ship if it was possible, we had meetings with a representative from each shop working on that project. We would hand out our scheduling task sheets mentioned above. We would then go around the room and have each trade talk about work happening today and the specifics of the work they plan to do over the next week. Everybody listens to everybody else, tasks that require more than one trade are coordinated here, and conflicts are resolved. These were very good at finding the ‘unforeseen’ coordination challenges a few days before workers were actually competing for the same space, or one trade was brought to a halt by another, or preventing the re-work costs incorporated by ‘walking on wet paint’. The Ship Superintendent was essentially the final decision maker for these conflicts, although just having the shop representatives talk it out for 2 minutes in front of the rest of the team usually led to a good solution. These meetings also involved a representative from the crew and was the first time we discussed ‘items of discovery’. Some work items required inspection of a space or condition that could not be observed during the spec development process before we could determine exactly what had to be done. We aimed to complete all these inspections by the 25% mark, and these daily meetings were the first communications of inspection results to the crew. These daily meetings usually lasted about 8 minutes. This showed respect for everyone’s time. The foremen hated the meetings, but they had to walk around the ships to check up on their workers, and they had to communicate their needs and progress to management. We tried to keep the meetings on the ships so the foremen hand to go see first hand what their people were up to, and give them the most convenient location possible to have managements ear and direction. Even the most ‘anti meeting’ mindset found some support for very brief, to the point, direct communications with all the players. This was also the perfect chance to walk to a specific job with a foremen after the meeting so they could explain it, in real time, exactly what the problem was if it wasn’t made totally clear at the meeting.
Communicating up the food chain: The best way to keep from getting in real trouble with a boss is to feed them too much information. At the Yard, we always had a direct line to our bosses and used it often. We called this the cell phone leash. In addition to this, we also had weekly ‘traffic court’ meetings. These involved all the ships superintendents, the senior Yard leadership, and the senior shop foremen. Each ship superintendent would submit a report (an Excel spreadsheet) with each work item on it. Each work item was color coded green, yellow, red with regard to threat to the schedule and the budget. This was our opportunity to bring more weight down upon the trades that were underperforming, but more importantly this was a chance to tell the bosses who was really coming to bat for you. Some did not take this approach, but I found that when I complimented the trades who were doing their jobs every chance I got, I got more work out of them. Also, when I said I had a problem people perked up. (One of my co-workers did nothing by ‘knit pick’ the workforce. It should be noted that this individual was also very effective, but did about the same with much more effort and sometimes had a hoarse voice.) ‘Traffic court’ also served as a valuable opportunity to take stock of the project on a weekly basis, and to understand what other projects were happening at the Yard. Often it was necessary for ships superintendents to modify schedules with other ships in order to best use labor resources, and these meetings allowed for this.
Constant customer communications: The ‘customer’ was at most of the daily meetings. We would usually reserve two of the meetings to be ‘in house’, so we could deal with internal Yard politics that the ‘customer’ didn’t need to know about. Also worth note here is the definition of ‘customer’. We referred to the ships command and crew as the ‘customer’. Sometimes, when there was disagreement, the ship’s representative would try to play the ‘customer is always right’ card. If the disagreement was strong enough and a compromise couldn’t be reasonably reached, or if the ship’s representative was flat out mistaken (i.e., requesting a ship alteration that was against Coast Guard regulations), we would tactfully remind them that these ships belong to the taxpayer, and that the taxpayer is the ultimate ‘customer’. Obviously this isn’t an option in private industry. Regardless, everybody can and will lose perspective, and as middle management, it is critical to maintain perspective and possibly remind others (even the customer) of what the objective really is.
Inspection-sign-off: This was done for each work item, and sometimes required several sign-offs for each work item. The Ship Superintendent basically had to make sure that the ship’s crew responsible for inspecting that work item actually looked at the work and understood what they were signing. Some people will sign anything without thinking twice. Once this was documented, it was an official ‘we accept’ from the customer.
Customer speaks to your boss: The commanding officer of the Yard was rarely involved in day to day waterfront operations (there were other support functions of the base that required attention as well). Regardless, the biggest fish in this pond would have individual face to face meetings with the senior members of each ship as the arrived, and then again when they left. The customer had free reign to say whatever they wanted about you. Sometimes they were very happy and surprised at the experience, sometimes they were a little disappointed. The important part is that no matter what, we wanted the crews to have no choice but to tell the boss that we were professional, competent, dedicated, responsible, and fair, even if we weren’t completely accommodating. It’s a little like the NY Times test, in that each decision you make should have a good explanation. Mistakes happened because we made the wrong calls, but if we could prove that we though it through, everybody came out in much better shape.
Follow up/warranty: A couple months or so, we had another teleconference with the same players as the spec development conference. Here, we discussed warranty issues, how and when to resolve them, if they are warranty issues, etc. We also did a de-brief of what worked well, and what did not. We tried to use this opportunity to force the CG support infrastructure to further improved their canned specification work items for the future. We would also discuss final costs and collecting further funds or, more often, returning funds to the appropriate commands. We finished off the final checklist
