Top 10 Excuses to Not Implement Best Practices and 5 Things to do About it

Over the past 30 years, a great deal of research has been conducted on IT-enabled business transformations.  As a result of this research, leading best practices for implementation have been identified and improved upon.  However, the fundamental essential elements have basically remained constant over this period regardless of the technology or the industry.

Yet countless examples still exist where companies fail in dramatic fashion upon deployment.

These transformation failures do not discriminate on technology, industry, contract type, system integrator, or pubic vs. private sector.  Look no further to our blogs on Sleep Number, Miller-Coors, and the City of Anchorage Alaska to get a flavor how a project gone bad can damage an enterprises reputation along with its balance sheet.

Our research indicates that these big project failure rates have remained essentially flat over the last 30 years.  This would indicate that some combination of these three factors is true:

• The best practices essentially don’t work
• The program leadership were not aware of the practices
• The program leadership made a decision not to implement them.

Backed up by thirty years of academic research and our own investigations into these project catastrophes, we can safely rule out the first factor.  And while it is a fact that in some cases the program leadership was not aware of a specific best practice, this is typically the result of one of the actors or vendors not making the client aware as a conscious decision.

In order to develop an approach to improve the probability that companies will make the decision to implement a best practice, we first need to dig down and understand the reasons with regards to why they chose not to.   Here is our list of the top ten excuses to not implement a best practice:

#10 – “We thought we had a better way”

Encouraged by executives to be innovative, Project Managers develop their own methods as a way to demonstrate expected behavior.

#9 — “We were afraid of what we might discover”

This excuse typically comes into play in testing or formal reviews.  The Program Leader fears that the execution of the best practice may result in the need for additional work that could send the project over budget or get it cancelled altogether.

#8 – “We tried this before and it didn’t work”

This is the ‘recent’ bias in action.  The Program Manager remembers a project failure in which the best practice was implemented.  It does not matter if the project failed for other reasons, the best practice was cognitively tied to the failure.

#7 – “It was too hard”

In certain cases it may be practically impossible to fully execute a best practice.  As an example, consider running parallel tests on a new ERP system where inputs and transactions need to be duplicated across the organization.

#6 – “We didn’t understand why it was necessary”

Almost everyone understands the best practices associated with backups and disaster recovery (probably due to some really bad personal experience).  However, the need for best practices, particularly in the area of change management and data cleansing are less obvious.  I can’t tell you how many times I have heard the words, “How can our data be bad, we are running the business on it today?!”  This is basically denial, or an incorrect feeling that “this won’t happen to us.”

#5 – “We didn’t trust our system vendor”

In this situation, the client perceives that the product or service provider is just trying to take advantage of an opportunity and the so called ‘best practice’ is really a best practice to make money.

#4 – “The vendor told us it was not necessary”

This one’s the flip side of number 5.  Clients are always looking for the magic bullet and some vendors are more than willing to sell them.

#3 – “Our company is different”

Let’s call this organizational hubris.  This is the belief that a company can overcome any problem that might result from not implementing a specific practice.

#2 – “We could not afford it”

In this scenario, projects perceive best practices as a portfolio of potential insurance options.  Budget is limited so Project Managers are forced to pick and choose which best practices to implement and which ones to take a chance on.

#1 – “We did not have the time”

This is the self-inflicted wound!  Project Managers have a propensity for reporting on project budget and schedule as the most important metrics of the program.  Once established in the minds of the steering committee, these managers will short cut the best practice to maintain the schedule.

With this inventory of excuses not to implement best practices in hand, let’s consider how to leverage it to make better decisions. 

From an examination of these ten excuses we can derive that there are three fundamental reasons the decisions to not implement best practices are made:

• Failure to understand the business operational risks
• Inability to correlate best practice cause and effect
• The virtual guard rails of budget and schedule

How can Program Managers and sponsors reduce the bias to not implement best practices? 

Here are five inexpensive techniques that can be implemented:

#1 — Make Failure Real

Companies spend a lot of time studying success stories as a means to derive best practices. This can be a lot like looking at someone’s vacation pictures and it is not evident that the specific best practices identified led to the result.  It has been proven that the avoidance of pain is a bigger motivator than the opportunity for pleasure.  Exposing the Sr. Executive team to real disasters and having them envision what it might be like for your company will get them asking the right questions (this is the reason they show those DUI crash site movies to kids in driver’s education).

#2 — Failure Mode Effects Analysis (FMEA)

FMEA is a structured process into the discovery of potential failure points and the determination of what actions can be taken to prevent failure. Having a professional facilitator of this process (every large company likely has one in its quality department) take the targeted business operating areas through this process will result in the likely identification of best practices as a means to reduce the possibility of failure. 

#3 — Early Identification of Business Operational Continuity Measures

The earlier a project starts to report on implementation and operational readiness, the higher the probability that decisions will be made in favor of preserving operational integrity.   

#4 — Methodology Change Control

A vendor’s prescribed methodology along with its assets and people are essentially its product. When a vendor or a client deviate in some fashion from that methodology, a process of change control should be put in place that evaluates the costs and risks associated with that change.  Changes to the methodology should always be backed up by quantifiable evidence that the step is not needed vs. a subjective evaluation.

#5 — Get a Second Opinion

A trusted advisor can be the best insurance policy you can take out when it comes to the implementation of best practices. An unbiased and experienced third party can offer insight into decisions that coming from a vendor or even from your internal team.  Early independent program reviews assist project teams to expose risks and the identification of specific treatments to mitigate those risks early.

When the operational continuity of the enterprise is at stake, the decision to not implement a best practice is a decision that should not be delegated to the discretion of the Project Manager. Developing a real sense of the business risk and insuring that these risks are properly treated and mitigated is one of the most important responsibilities of the project sponsor and executive steering team.

Read more about UpperEdge’s Program Execution Optimization services and subscribe to our blog to read more about how to maximize your program execution.