I spend my days working as a project manager (and manager of project managers) for web and mobile applications, sites, and other digital deliverables. I spend my evenings and weekends as a martial artist.

During the day I keep projects on the rails. We stay on time, on budget, and focused on business objectives.

Much of my extracurricular time is spent getting punched in the gut during martial arts practice. We alternate on who is the attacker and who is practicing the techniques in order to learn and help each other learn. I don’t enjoy pain, but it’s a kind of moving meditation that gets me out of my head and into my body, and it keeps me sane.

For many years, I thought these two activities had absolutely nothing to do with each other.

One night in class, we studied distraction techniques. I allowed my partner to pull my attention elsewhere and then land a solid punch to my gut. The punch hurt a lot; it seemed so much more than usual. My teacher smiled at me and said simply: “Surprises always hurt.”

A few days later, I was sitting in a meeting about a project that was just starting to go off the rails. We discussed possible workarounds, solutions, and plans of attack to make sure the issue did not actually impact the success of the project, but there are no guarantees in digital development. At the end of the trouble-shooting session, I was asked the big question: “Should we tell the client?” And my immediate response: “Yes, because surprises always hurt.”

Transparency is key to success as a project manager. I am firm believer in sharing progress, success and failure with the client as honestly as possible.

Technology challenges us on a daily basis; it’s always changing and increasingly demanding. If your agency is not making mistakes, then your agency is not taking the risks required to be innovative in the current digital ecosystem. There is a reason why expertise and strengths called “risk mitigation” and “contingency planning” are part of our job descriptions as project managers: risks are taken every day and contingencies are how we mitigate risk to make sure neither human nor technical failures impact our clients.

Transparency is one tool of risk mitigation. For example, towards the end of every project, between development completion and deployment, we perform QA testing. Our testing team runs through the application on supported devices, systems and browsers and logs bugs. Our dev team resolves issues in order of priority, and QA closes them out when verified. The entire process is internal to our team. Usually, the only time most PM’s involve clients during this cycle is when bugs need to prioritized or closed without resolution (i.e. it is an acceptable compromise or as designed). I prefer to export these on a daily basis and share the whole thing with the client, every day until launch, and sometimes post-launch, until the client’s expectations are met. This may seem like too much, but clients appreciate the visibility. It decreases the surprises that may occur when there’s a bug that proves more difficult to resolve.

If there is a serious issue, and I notify the client too late, it’s a surprise, and a painful one. If I were to make the client fully aware of issues that may occur before they occur, and one of them does become a serious issue, then my client is more prepared to handle the problem, both with me and with other stakeholders whom the client may mange internally.

If I take the basic rule that a surprise punch to the gut is exponentially more painful than an expected punch, and map it to client reactions to issues that occur in digital development, the pain looks to be about the same.

At the top and the bottom of the spectrum are the results of not being fully transparent with a client. If I don’t flag a potential issue with a client  there are only two results:

  1. We handle it and nothing happens, so they don’t know (the what you don’t know can’t hurt you approach)
  2. An issue occurs, it’s a big surprise, and there is a dissatisfied client (and rightfully so)

If I do flag a potential problem, there are three possible results:

  1. The problem is resolved and the client is happy (possibly mildly annoyed at the initial risk)
  2. The problem occurs and the client is frustrated but engaged in the problem-solving process (in partnership with the agency)
  3. The problem occurs and the client is unhappy and resistant to the issue having occurred at all (requires escalation)

As rough as these many be, none of these responses is as bad as a surprise problem that could impact my client’s project, reputation or even job. I do not want to subject my clients to that potential.

There are many instances in my career of all kinds of problems. My favorite is, of course, warning/no problem. The client appreciates the transparency, and the team resolves the issue before it ever becomes serious or has impact. This preference has served me well, and I continue to prioritize transparency for my clients as an agency best practice in digital development.

This is also my preference in martial arts; I would much rather anticipate a punch and have it never connect at all. My gut feels the same way.