Posts Tagged ‘consultants’
In an episode of the popular American TV show ER, an alcoholic patient with political connections is moved to the top of a liver transplant list. One of the staff’s doctor’s voices his outrage after catching the patient sneaking in a few drinks prior to the operation. The doctor doesn’t believe that the patient is worthy of the transplant, as he’ll just destroy another liver better served or someone else–i.e., a non-alcoholic.
I often think about that episode and related questions:
- Is the hospital enabling the alcoholic’ dependency?
- Would “tough love” send a message that the individual has to change his behavior–or face death?
- Is there an incentive for people to cease engaging in destructive behavior if they know that they themselves will have to bear the consequences?
The same holds true for the world of data management. In Why New Systems Fail, I write about how many times consultants have to save the day for their clients–or at least try. When things break bad, organizations often call in people like me to save the day. And sometimes we do. (As a result, some of us consultants have a Superman Complex, although I like to think that I usually keep my ego in check.)
So, we show up and try to fix things. I can’t help but wonder: Are we consultants enabling our clients’ difficulties? Are we really solving their problems?
Note that I am not advocating refusing to do the work that clients are paying us consultants to do. I am simply going to make the argument that, by constantly bailing out employees and organizations with lax data management practices, consultants may in fact be enabling the very problems that organizations are hiring us to solve.
The Usual Suspects
In my experience, most data management and quality problems stem from:
- poorly trained or lazy employees
- poor documentation for business processes
- inadequate internal controls
- redundant or overly complex internal systems
- a culture that tolerates errors
- poor performance management
- weak senior leadership
In other words, rarely do discrete and external events such as a software bug or rogue end user cause major problems. The seven culprits identified above do not fall into the “easily fixable” category, at least in the long term. As such, the consultant(s) that triage the situation do very little to prevent the same problem(s) from recurring.
In fact, by heeding our clients’ calls, we consultants might even be increasing the chances of recurrence. Why? Because we show that we can often work our magic and return things to normal states without the organization or its employees making any fundamental changes to their behavior, processes, or systems. While consultants aren’t cheap, depending on the engagement, a $200,000 USD cost may in fact be less expensive than changing the organization’s culture or replacing ineffectual CXO’s–much like getting a new liver is “easier” than entering Alcoholics Anonymous.
Look, it’s always tempting to believe that the solution is an external entity, be it a consultant, acquisition, or piece of technology. Why do you think that, particularly in the United States, sales of weight loss products are growing by so much? It’s just simpler to try and find salvation in a pill than watching what you eat and exercising a few times per week.
The burnt hand teaches best. Sometimes, organizations that experience major data management problems ought to try and solve them on their own.
What say you? Are there merits of not fixing organizational data management problems?
I recently had a discussion with three friends of mine about Master Data Management (MDM). Jim Harris is a professional writer and data quality expert. Dalton Cervo and Mark Allen are long-time data management professionals in the middle of writing their first book, MDM in Practice (John Wiley & Sons, June 2011.) In this post, I cover one of the main problems that people and organizations face when implementing an MDM solution. I call this The Vacuum Effect.
The four of us agreed on the need for MDM, particularly at large organizations with multiple systems and complex data management requirements. You can only do so much with temp tables and other technological Band-Aids. We had little doubt that organizations can manage their data in vastly superior ways by adopting MDM tools, under the right circumstances.
Cervo, Allen, and Harris each pointed out something that many technology vendors neglect to mention during the sales cycle (and many organizations do not want to hear): MDM does not exist in a vacuum. MDM is no panacea. Consider the following organization:
- Its data is very inconsistently defined.
- A major gap exists between IT and the lines of business (LOBs)
- Its data quality is poor in most parts and downright awful in others.
- Data stewardship? What’s that?
- Standalone spreadsheets and databases are the norm.
- There’s no semblance of data governance.
MDM to the rescue? In short, no.
Yet, some organizations continue with a formal RFP process, ultimately selecting an MDM tool without having address the core issues causing so many of its problems. In a way, MDM is no different than ERP, CRM, or other powerful, enterprise-wide applications and technologies:
They can only truly be effective with fundamentally sound business practices supporting them.
Many of us want to believe that there’s a single technology (or technologies) that can solve all of our problems. Let me set the record straight: there isn’t, and MDM is no exception to this rule.
If your organization is not mature enough for an MDM solution, take a step back. Evaluate the problems, begin a data governance program, address data quality issues, and bridge the IT-business gap. Starting an MDM project sans making these improvements is bound to fail, sullying the organization’s opinion of the technology and wasting a great deal of money in the process.
As I have seen before in the ERP world, often an organization that fails to address these issues blames the product, vendor, consultants, or all of the above–anyone but themselves. Perhaps it will go on to select a new MDM solution, believe that they had just backed the wrong horse. Don’t fall prey to The Vacuum Effect.
Think golf: A golfer with a horrible swing shouldn’t just buy the best set of clubs.
What say you?
In this last part of my series on resource mistakes, I’ll take a look at an inherent conflict that plagues many information management (IM) and IT projects. This conflict stems from one simple statement:
The best consultants are not merely order takers–nor should they be.
I’ll let that one sink in for a minute because it tends to rub some people the wrong way. Many people erroneously believe that consultants should always just do what they’re told to do. Clients are paying us good money and, especially in this economy, who has the temerity to say no.
Here are four good reasons that the best consultants will not simply fall in line when a client asks them to do something entirely inappropriate:
Let’s explore each.
Most consultants carry errors and omissions (E&O) insurance, defined as “business liability insurance for professionals such as insurance agents, real estate agents and brokers, architects, third party administrators and other business professionals.” While E&O contracts do not define the explicit tasks that a consultant can and cannot do on any particular gig, most have some type of limits. In other words, consultants don’t have carte blanche to perform whatever task they–or their clients–deem appropriate. I personally have never had to show a copy of an E&O contract to a client, but I have refused to delete production data without a formal request because of it.
Forget for a minute about what consultants are legally allowed to do. Let’s talk about what they should and shouldn’t do. I have no problem with coming in to save the day, as I have done more than a few times in my consulting career. I enjoy solving problems. But there are limits to what I–and other conscientious consultants–feel comfortable doing. I can think of an instance in which an end-user intentionally purged hundreds of thousands of financial records in a system–sans permission. He intimated to me that he wanted to get them back without letting others know. While this wasn’t possible, that was beside the point: others may have run reports based on incomplete information and I would have felt compelled to let those potentially affected know.
Consultants are always worried about billing. We don’t run hedge funds; we’re always chasing the money. Rare is the client that always pays on time. Consultants who continue to do questionable things for particular end-users significantly increase their risk of not being paid, especially if and when a senior executive finds out what’s been going on. Of course, the consultant can always say, “I was following orders.” That may or may not fly but, to many, it’s just not worth the risk.
Finally and perhaps most important, consultants’ reputations are their currency. For any one of us, it only takes on dissatisfied client to mar an otherwise impeccable track record. While these fleas come with the dog, a consultant forced to do unnatural things on a high-profile disaster will always be associated with that project. Based upon my experience, it’s rare that an end-user will say something along the lines of, “Our project failed miserably, but it had everything to do with us and nothing at all to do with the consultants. Our bad.”
Look, no one is advocating outright defiance because a consultant just doesn’t feel like doing something entirely reasonable. But expecting consultants to walk off a plank is an enormous mistake. To paraphrase Jack Nicholson in A Few Good Men, “You want us on that wall. You need us on that wall.”
What say you?
In my previous two posts, I discussed some of the perils associated with staffing information management (IM) projects. Waiting until the last minute and finding the lowest cost resource can often lead to trouble. In this post, I’ll take a look at arguably the single most destructive thing that an organization can do on IT and IM projects: silencing dissent.
Why Organizations Silence Dissent
For many reasons, organizations often try to quite those who raise legitimate issues. To be sure, intraorganizational politics often weave its ugly head into the mix. Perhaps a VP has his reputation on the line and needs an IM project to go live at a certain point. Other times, individual executive bonuses are on the line. I have also seen departmental myopia at work. People who work in one department often don’t want to hear about the issues that affect other departments. The lack of a steering or oversight committee or formal IT/data governance function exacerbates this issue.
I can cite many examples from my career of how these problems have manifested themselves. For example, I once worked at a large retail outfit rife with internal data issues, affecting multiple areas of the organization. I broached issues to superiors who essentially told me to keep quiet. I had no other choice. After I left the organization, within two years the organization was under investigation, its stock price plummeted 90 percent, and the CEO was forced to resign.
Why Dissent Matters
Whether internal or external (in the way of consultants), those that broach issues are typically not troublemakers. They know the downstream effects of continually ignoring a problem. What’s more, particularly when batch programs are involved affecting large transactional tables, a minor issue can become a major one over time.
Beyond fixing individual problems, however, failing to recognize–much less address–known issues sends a pernicious message throughout the organization: We don’t care. It encourages others to ignore issues, gradually eroding data quality and integrity and, in time, confidence in the overall systems of record in an organization.
Of course, none of this may register with bottom line-obsessed executives, particularly in publicly-traded companies. To that end, consider the same bottom line. At some point, data-oriented issues can no longer be ignored (read: audits, regulatory changes, and lawsuits). The costs to fix previously-identified issues are often exponentially higher than if they had been addressed earlier.
Look, there’s a proper way to raise issues. Those that use diplomacy, tact, and respect are more likely to have their issues heard. However, that does not ensure that they will be considered, much less acted upon. What’s more, there’s always the chance that the employee or consultant is crying wolf, broaching an issue that really doesn’t exist.
Still, isn’t it worth the risk of investigating it–or at least hearing the person out?
What say you?
TODAY: Mon, April 24, 2017April2017