Learning the Six Circles of a Client Program

An SMA deployment to a client program… It sounds like a military assignment in support to the home force. Well in some cases it is, but the main difference is that on the outset instead to charging headfirst into a fortified wall it’s best to work from the inside out. Of course, this tactic requires a whole different set of weapons and strategy.

by John Trapane

One course of action is to think of the client program as a series of concentric circles. Gain a knowledge base of each circle as you progress to the outer circle:

  1. The Program Manager or your immediate supervisor: What is their method of management; what is important to them? Are they into the details or do they operate at a higher level?
  2. The client’s company processes: How do they do business? What are their process tools? Are you properly equipped to do the job?
  3. The current infrastructure or program organization: You need to be knowledgeable of the environment in which you will be working.
  4. The program: How is the program designed; what is the mechanical structure? You need to understand the bill of materials (BoM)
  5. The objectives: What are the deliverables? What are the customer reporting requirements, i.e. Contract Reporting Deliverables List (CRDL)?

All of these may seem like common sense but any long-term difficulties I may have experienced on my deployments can usually be traced back to one of these fundamentals especially #4. Building on each circle will make your job easier and you’ll be more successful.

The 6th circle may be the most difficult. We all have the technical expertise to implement on any deployment but understanding and functioning in the client’s political atmosphere is a different animal. It’s the most difficult to recognize and the usually the most difficult to overcome. You are obviously there because the client needs you and your expertise. But there may be pockets of resistance, local team members that believe they can do the job better or are set in a routine and don’t want to change anything. Whatever the case, your biggest enemy is your own arrogance. Your objective is to become a contributing member of the program team. This may require some salesmanship. It’s better to influence rather than dictate.

I experienced this firsthand. I was assigned to support a monthly Subcontract Data Requirements List (SDRL) deliverable of a Statused Integrated Master Schedule (IMS) Report. The local support had structured a system of four consolidated files: Engineering, Test, Production and Operations. This configuration required each file to be separately statused in sequence, then interfaced with the external connections, and then files formatted to get a program Critical Path. The entire process took over eight days, and the delivery was not always timely. I questioned the support team for a more efficient methodology, and they came up with the idea for creating one file (with some gentle nudging) and interconnecting all the functional disciplines, resulting in a file of approximately 2000 tasks. The turnaround time was reduced to three days, and, more importantly, the end customer appreciated the schedule format and the timely deliveries.

All of this may seem fundamental to our deployments but all too often the fundamentals are forgotten only to come back and haunt us further down the road. I know… I’ve been down that road.

If you’re building a team and you have positions you can’t fill, you need to use SMA Talent on Demand (TOD®)! With TOD®, you can find experienced talent, such as John, matched to your exact needs:

cs_gb name=”cta-talent-button”]

Published on April 21, 2020 by

Dick Eassom, CF APMP Fellow