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.\u00a0\nYet countless examples still exist where companies fail in dramatic fashion upon deployment.\nThese transformation failures do not discriminate on technology, industry, contract type, system integrator, or pubic vs. private sector. Look no further to reports on Bridgestone, Sleep Number, Avon, Miller-Coors, and the city of Anchorage, Alaska, to get a flavor for how a project gone bad can damage an enterprise's reputation along with its balance sheet.\u00a0\nOur 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:\n\nThe best practices essentially don\u2019t work.\nThe program leadership was not aware of the practices.\nThe program leadership made a decision not to implement them.\n\nBacked up by 30 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.\u00a0\nIn 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 why they chose not to. Here is our list of the top 10 excuses to not implement a best practice:\u00a0\nNo. 10 \u201cWe thought we had a better way\u201d \u2013\u00a0\u00a0Encouraged by executives to be innovative, project managers develop their own methods as a way to demonstrate expected behavior.\nNo. 9 \u201cWe were afraid of what we might discover\u201d\u00a0\u2013 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 canceled altogether.\nNo. 8 \u201cWe tried this before and it didn\u2019t work\u201d \u2013\u00a0This is the "recent" bias in action.\u00a0 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.\u00a0\nNo. 7 \u201cIt was too hard\u201d\u00a0\u2013 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.\nNo. 6 \u201cWe didn't understand why it was necessary\u201d\u00a0\u2013\u00a0Almost 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\u2019t tell you how many times I have heard the words, \u201cHow can our data be bad? We are running the business on it today!\u201d This is basically denial, or an incorrect feeling that \u201cthis won\u2019t happen to us.\u201d\nNo. 5 \u201cWe didn\u2019t trust our system vendor\u201d\u00a0\u2013\u00a0In 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.\nNo. 4 \u201cThe vendor told us it was not necessary\u201d \u2013\u00a0This one\u2019s the flip side of No. 5.\u00a0 Clients are always looking for the magic bullet, and some vendors are more than willing to sell them.\u00a0\nNo. 3 \u201cOur company is different\u201d \u2013 Let\u2019s call this organizational hubris. This is the belief that a company can overcome any problem that might result from not implementing a specific practice.\u00a0\nNo. 2 \u201cWe could not afford it\u201d \u2013 In this scenario, project leaders 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.\u00a0\nNo. 1 \u201cWe did not have the time\u201d \u2013 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 shortcut the best practice to maintain the schedule.\u00a0\nWith this inventory of excuses not to implement best practices in hand, let\u2019s consider how to leverage it to make better decisions.\u00a0\nFrom an examination of the 10 excuses, we can derive that there are three fundamental reasons the decision to not implement best practices is made:\n\nFailure to understand the business operational risks\nInability to correlate best practice cause and effect\nThe virtual guardrails of budget and schedule\n\nHow can program managers and sponsors reduce the bias to not implement best practices?\u00a0\nHere are five inexpensive techniques that can be implemented:\n1. Make Failure Real \u2013 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\u2019s vacation pictures, and it is not evident that the specific best practices identified led to the result.\u00a0 It has been proven that the avoidance of pain is a bigger motivator than the opportunity for pleasure. \u00a0\nExposing the senior 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\u2019s education).\n2.\u00a0Failure Mode Effects Analysis (FMEA) \u2013 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 (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.\n3.\u00a0Early Identification of Business Operational Continuity Measures \u2013 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.\u00a0 \u00a0\n4.\u00a0Methodology Change Control \u2013 Avendor\u2019s 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. \u00a0\u00a0\n5. Get a Second Opinion \u2013 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.\u00a0\nWhen 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.