How to Screw Up a Procurement Job Interview

Recently we published two guest posts from Charles Dominick of Next Level Purchasing on Assessing a Procurement Team’s Skills and Training a Procurement Team, but these were not his first. Nor his only good work. Five years ago we ran this post targetted not at procurement organizations, but procurement professionals who want a better job based on a great post on 5 [Common] Ways to Screw Up a Purchasing Job Interview that he published over on his Purchasing Blog.

Charles’ must read advice indicated that the following WILL screw up your interview:

  • taking an interview late in the processas all future candidates are compared to the one once that candidate is identified
  • not being prepared for the most common interview questionwhich, succinctly, is tell me about yourself

     

  • not distributing eye contactwhen being interviewed by multiple people
  • saying anything negativeas you will not be seen as the proactive team player they want to hire and
  • using slang inappropriatelyas there is no guarantee that an interviewer is going to understand what you mean, and if you say you are hotter than a fox in a forest fire for the job, and the interviewer isn’t familiar with that phrase and a strong PETA advocate …

In addition, the following will also screw up the interview:

  • not dressing appropriatelyeven if the company has a very laid back atmosphere in the workplace, don’t show up in shorts, a Hawaiian shirt, and sandals (as they need to know that you can make a good impression in front of a supplier)
  • over-stating your skills, experience, or knowledgeas you will be interviewed by the best and brightest and they will find you out
  • not knowing the market for the common Procurement categoriesif the job is in the electronics component division and you know nothing about the state of the semiconductor market, that’s not going to look good when they ask if you have any ideas to control costs in that market
  • not knowing what the company doesif they are an engineering company that primarily makes electronic components for personal entertainment and the automotive sector, but you only know them for their video game division, that’s not going to look good when they ask how you plan to reduce costs in the automotive division
  • not knowing the competitionand this is doubly damaging if you walk into the offices with the product or logo of direct competitor anywhere on your person.

Technological Sustentation 91: Proprietary Madness

Not only do you have to deal with IP and Patent Madness, which we recently discussed, again, but you also have to deal with proprietary madness that is likely to drive us all mad (and may someday push the doctor over the edge, into the land of the crackpot, where at least one blogger in the space is already dwelling).

Just what is proprietary madness? It’s mega-corporations, especially in software and electronics, taking the rights of ownership to extreme. Started, and continued, by the current and former Technology heavyweights, including the likes of IBM, Microsoft, and SAP, it’s not only the creation of company specific standards for software and hardware interfaces, its the restriction of the specification of those interfaces to approved partners and suppliers, limiting the supply of support services and related products to a handful of vendors. This not only drives up the price of those products and services to well above the market average price for support services for software and products with open and published specifications, but can make it difficult, if not impossible, to get support when demand is high or related products if one of the few vendors who can produce products shuts down.

Those of you with SAP know exactly what we’re talking about. Unlike Oracle, which publishes its core schema, and does not change it between minor versions, SAP does not publish its score schema, does not guarantee any stability between bug updates between minor versions, such as between 4.7.1 and 4.7.2, instead requiring you to go through its proprietary NetWeaver interface, which you will, of course, have to acquire to actually support any customizations (and likely build applications in the Portal). And learning the portal is no easy task. One of the most complete books on it is 700 pages alone! And that’s just the beginning …

And while there is nothing wrong with proprietary technology, as a company needs some assets in order to survive, the lengths at which some companies go to keep it secret and protect it, in a world where data needs to be shared and products need to be utilized in conjunction with other products makes development (and the supply chains that rely on that development), a nightmare.

So what can you do?

1. Make Open Source / Open Systems a priority.

When doing your weighted evaluation of a provider, penalize any provider with proprietary systems, and severely penalize providers with highly guarded proprietary systems that cannot be maintained by anyone but the provider. Give this a weighting of three times more than your gut thinks it should be weighted.

2. Demand the ability to do full data dumps to an open standard, such as XML, or a text format, such as CSV, whenever you want.

And do them at least quarterly, if not monthly, and do incremental full data backups at least weekly, if not daily. If the system stops working for you, you need to migrate, and even if the system does work, you will still need to integrate that data into your (virtual) data warehouse to support analysis and other processes.

3. Migrate away from proprietary vendors at first opportunity.

It doesn’t matter how much you paid, or how bad you think you will look by trying to replace the solution that was the right solution when you bought it, because it will always cost you more in the long run — with costly maintenance, custom development, and manpower to manually integrate data dumps into third party solutions — and that’s worse than admitting there’s a better solution than what you have. Moreover, chances are when you bought that big, monolithic, proprietary solution, there wasn’t a more open alternative, so you didn’t really do anything wrong and a good Procurement department always looks for ways to improve processes and platforms.

So, Do You Throw Provider RFX Templates Out with the Packaging?

This post originally ran two years ago. (Link) SI is repeating this post because the majority of organizations still have issues with RFX templates of all shapes and sizes for all types of purchases.

So, do you throw provider RFX templates out with the packaging? That depends. If you have lazy, uneducated, or inexperienced Supply Management personnel (because your Procurement department was staffed like the Island of Misfit Toys), then you want to delete them as soon as you get them because, if a template exists for the product or service you want, it will be sent out more-or-less as is and you’ll get a specification that is two sizes too large, two sizes too small, or very irregular and not at all a good fit for your organization.

On the other hand if you have educated, experienced, go-getting Supply Management personnel who take the time to properly construct an RFX, going through the steps outlined in our many RFX series here on SI, then they do have a use. Specifically, as a check-list after the RFQ has been completely drafted to make sure that nothing was missed. Sourcing is complex these days and it’s hard even for an expert to include every relevant detail every time when time and resources are so scarce. There’s a reason that even hospitals and clinics use checklists, because it greatly decreases the chance of a (serious) error being made. If a vendor, that built a template as a result of analyzing dozens of events, included something in an RFX template, then, at least at one point in time, it was very relevant and, as such, should not be excluded from an RFX until a senior buyer confirms that the market or standard operating conditions have changed and that the question, cost component, or requirement is no longer relevant.

So, these templates do have their uses, as long as they are editable by senior buyers. Because, as explained in the last paragraph, over time, some parts of the template will become irrelevant and other questions, cost components, or requirements will become very relevant and need to be in all RFXs related to that product or category. If the senior buyers can completely customize the templates to the categories, products, and services of the organization and configure the tool so that no template is used out-of-the-box (until a senior buyer confirms that it is still accurate enough out-of-the-box), then the templates, and template features, have a use.

But as-is, the templates in many template libraries are probably still less useful than calling a supplier over the phone and saying you need a quote for customized circuit boards and doing three-bids-and-a-buy blind.

In other words, templates have a use, which is why the doctor encourages most vendors to have a library of templates that can be used as starting points, but their use, until customized by a senior buyer, and reviewed regularly, is that of a post-RFX creation checklist. Nothing more. And not understanding this can get your organization in serious trouble in its sourcing events.