You may not be a fan of science fiction. Does that mean your procurement department is grounded in objective reality? Here is a quote: “IoT procurement is the place where good projects go to be euthanized. ” It is not mine, it comes from someone with zero skin in the game. No skin at all, in fact.
The enterprise vendor trap starts with a simple premise; We should only work with “Tier 1” vendors. In order to grade the quality of vendors we will set up a kind of interview or competency test, based on our priority matrix. Each of those little brain emissions results in an exercise in compliance, not project execution. When you engage an IoT vendor, their timeline often starts at 6 months (feasibility, R&D, prototype, pilot, real-world testing, small scale deployment, client feedback, rework, full scale deployment). And they don’t have a warp drive, yet.
The documentation circus is designed to mitigate the risk of buying the wrong thing from the wrong vendor. It is the same as a HR team thinking a 6 minute, open question, form filling exercise will weed out the weak. Conversely, it fills your company with the kind of people who take six minutes to fill in a useless form. Top talent never applies, because they take 10 seconds to cost/benefit a time commitment to an opposing conclusion.
The issue is that corporate actors like covering their backsides. Key staff tend to move on from most projects within 2 years. The “best” people get called for “firefighting duties” on higher (systemized and validated) value current projects, while the less favored dregs remain in steerage, filling in excel sheets and status reports. This leaves your procurement “vendor selection” process drifting in space without propulsion, indefinitely.
IoT vendors are optimized for discovery, prototyping, iteration and speed. They boldly go where no one has gone before. They know exploring takes time and a well stocked galley. You cannot be on the hook for six months of R&D spend, while seeking out strange new worlds and new civilizations. Meanwhile, procurement’s focus on “security,” and “risk analysis documentation” for events that have not happened, reads like the rider for Motley Crue in 1985.
“Air-gapped” sandboxes, test benches and pilot projects are concepts that don’t readily fit the standard “three competing quotes” excel sheet, with its three months of tiered meetings and three incompatible futures. The conception is limited to buying “devices.” Unfortunately, competing hardware and software goals cannot be stacked like office chairs. Blindly reaching for the “ERP integration” medusa, is drowning an embryonic project in a quicksand of competing non-priorities.
Another move (we had it last week), was the “framework compliance” illusion. Does your product have FCC, CE, ISO, GDPR, ITIL? This is installing seatbelts on a hydrogen car which exists only on AutoCAD. Procurement doesn’t want to “own” outcomes, it is optimized for preventing bad decisions. One document leads to another, as every rich lawyer knows.
What the smarter teams do is run a parallel process, but this requires a certain degree of “respect” (which we know is a fraught term in this context). The first track is a skunkworks type model; small, fast, informal, focused on real hard work and real data. This is where your devs, tech geeks and hardware guys hang out, hiding under the creativity bypass.
The second track follows the corporate digestibility framework, assisting procurement with their documentation, security, compliance, risk analysis, staged ownership gateways and decision point elements. Proofs bend rules, powerpoints do not. You’re saving upfront time cost by leveraging extended timelines for form filling and bureaucracy.
Procurement is not out to kill innovation. They’re targeted on irreversibility. What they’re interested in primarily is payment and ownership. Nothing shows these attributes like a product which already exists, runs, and people are already using. You can sell as many Microsoft office licences as you like, nobody will bat an eyelid. Maybe we should do a post on; “how to sell temporary systems to serious people”?
One last thought, because it closely parallels the enterprise procurement process. At one time software projects were not standardized. Then along came a slew of competing methodologies. The PMI and Prince2 models became crowd favorites. Then they became too document focused and hidebound. Agile filled a gap, but it was too loose. Now, PMI (process) and Agile (mindset) methodologies combine speed, iteration and flexibility with documentation and matrix accountability. You can combine projects, documentation and iteration. It has already been done.
