Editor’s Note: This post is from regular contributor Norman Katz, Sourcing Innovation’s resident expert on supply chain fraud and supply chain risk. Catch up on his column in the archive.
As a consultant, and given my areas of specialty, I never always & fully know what to expect when I am engaged by a client, as there is always something new to discover. But before I accept any assignment, I perform due diligence to ensure I’m the right person for the job. My due diligence involves a detailed discussion as to the problems the organization is having, technology environment, geographic location, etc. Sometimes I can steer the organization towards a different – and better – solution path, removing me from consideration. It doesn’t pay the bills but it’s the ethical thing to do.
I’m often left with the decision about whether I’m the right person for the job because I know better than the perspective client what my skills and talents are. If I’m not familiar with certain software or hardware, or the problem lies in a situation or industry I’ve not experienced, I’ll tell the perspective client this. It won’t necessarily negate my chances of selected as the solution provider, because experience has told me that as long as I can quickly acclimate myself to something and have (closely) related experience, I’ve got a good chance of getting the project.
I believe it’s absolutely necessary, in all fairness, to set the expectations as realistic as possible from before the beginning (during the “interview” stage). In no way do I want to surprise a client with what I don’t know during an engagement, after being paid monies leading up to that point.
Some former colleagues of mine asked me into a company they were trying to help; the discussion would center on implementing several unused modules of their Enterprise Resource Planning (ERP) system, and that some data migration and creation would be required. Now, I’ve helped clients with everything from QuickBooks® to SAP®, and with hardware platforms such as Unix®, Linux®, Windows®, AS/400®, and IBM Mainframe. I’m able to do this because I work with my clients’ technology staff or technology provider service companies in concert with my own technical skills. However, despite expertise in some areas, it would likely be more correct to label me an ERP generalist.
I went in and met with the company, and it wasn’t too far into the discussion that I realized they had been told I was something of a “knowledge expert” on their particular ERP system, and the conversation went down from there, as I informed the meeting attendees that while yes, I could perform the work needed (and had done so before in other ERP systems), certain criteria had to be met on their end, such as did they have administrative access to their database and the import/export module. (I had done my homework on their ERP system before I went in.) For each question I asked, the company operating officer and lead technology person had no idea, and neither did my colleague.
Well, I had two choices: hang my colleague for the misrepresentation in front of everyone, or take the bullet myself, and I opted for the latter rather than the former, because that’s the kind of person I am. Later at lunch with my (now former) colleague, I was criticized for my sales pitch: I should just shut up and take the work and then explain the nuances and details later. (Never mind that it’s those nuances and details that are important to understand up front to ensure I was right in accepting the assignment in the first place!)
One definition of fraud describes it as a breach of confidence, and misrepresenting ones’ skill set is, in my opinion, fraud.
Regardless of what line of work you are in, (purposeful) misrepresentation is fraud, pure and simple.
I’ve probably turned down more assignments than I’ve accepted in my consulting career, but when you compromise your integrity and dignity, you lose your credibility because eventually your fraud will be revealed, and by that time it’s too late.