4th key for a successful PAM project define the process for resolving errors up front

We published a white paper on how to have a successful PAM deployment and we have identified 5 key success factors to consider in the early stages of your project to ensure its success. In today’s article, we’re focusing on the fourth step that consists on defining the process for resolving errors upfront.

In managing a large PAM implementation project, it can be a difficult decision: stick to your timeline and achieve your goal on meeting critical KPI targets, or take care of an unforeseen and annoying error that isn’t necessarily urgent but will have to be dealt with at some point. On the one hand, the organization has already bought into the KPIs, and they are expecting consistent and demonstrable progress. On the other, this error has the potential to become even more impactful the more you ignore it. What is the best path forward?

When dealing with a situation where some unexpected bad news threatens to derail an otherwise positive progress report, it is almost always advisable to deal with the bad news in an up-front manner. It is understandable to downplay the risks of temporarily ignoring an issue for the sake of meeting already agreed-upon KPI targets, but, generally, it is a best practice to accept a slight delay in order to resolve the issue.

To make your decision much, much easier to take if this situation ever arises, make a concerted effort to set expectations at or even before the project launch: there will be unanticipated problems, and it will be the policy of the project managers to address these problems as they arise, not to delay them until a future time. Make sure all stakeholders — but
especially senior management — understands that PAM solution implementation is more complex than the typical IT project and that the priority is to do it well, not just to do it quickly. And on your project timeline, it can be very useful to write in bold letters that the timeline is provisional and likely to change. If your project is already underway, it is never too late to communicate this message to stakeholders.

The situation you are trying to avoid is one where a short-term fix winds up turning into a long-term nightmare. For example, you might find out that a certain region or business unit can only deploy an older version of your PAM solution, and you might be tempted to let them go ahead so that you can make your KPI targets. The issue is that you
introduce a new set of risks and complexities, and as time goes by and as more of the organization is onboarded on two different versions, the risks and complexities will only grow.

In software development, the cost of choosing an easy but incomplete solution is called “technical debt.” In this concept, the “debt” winds up accruing “interest” as long as the debt remains unpaid, and depending on the situation, the interest rates can be extraordinarily high. In the world of cybersecurity, we can consider the cost of “implementation debt.” A small shortcut can result in massive amounts of work to address the issue further along in the project. By identifying and addressing errors up-front, you can wind up with a smoother and sturdier solution down the road.

To read about the rest of our steps to obtain a successful PAM deployment project download our white paper here: https://ignimission.ac-page.com/en-ignimission-protec-white-paper

Read other articles related to Privileged Access Management here: https://www.ignimission.com/blog-pam/