Monthly Archives: September 2024

Stop Wasting Your Time With Contract Management

The Mandarin (Yes, The Mandarin) recently posted a great article on why you should stop wasting your time with contract management

As the author clearly states, every department, state and federal, in which I have worked has a set of policies and directives on contracting and contract management. Almost every contract has a contract management plan. Yet we continue to get it badly wrong.

He quotes a recent review of Home Affairs which got a shellacking about their utter inability to reasonably prepare for the end of a contract (as well as other Procurement issues). It’s as he says, when it comes to preparation for contract termination, which should be part of a well formed contract management plan, it’s almost always “too little, too late”.

Contract Management isn’t working, and more importantly, neither are contract management platforms. (Making a colleague of mine who poo-poo’d them almost two decades ago as not worth your time, because they didn’t do any more than what a high schooler could do with some scripting and an access database, a visionary genius.)

So why do we get it so wrong? The author starts off by saying we think about contracts the wrong way, which we do (and there’ll be more on that later), especially since many approach it as a matter of performance and punishment since the contractor or vendor just needs to do what they promised and whatever performance or punishment framework included in the contract will encourage the contractor or vendor to deliver on time.

And, at the end of the day, most organizations just see it as a reporting and control framework, driven by compliance. When, as the author points out, it is supposed to be about outcomes, and, even more importantly, as the author points out, it should be a tool for managing the value chain.

The author then recommends that you fix things by:

  • owning the business outcomes
  • understanding and measuring mutual obligations
  • measuring, reporting, and managing the entire business, not just the odd contract
  • making what’s required visible and clear
  • not treating relationship management and contracting as mutually exclusive
  • using performance measures you understand

Which is all good advice, but not going to fix the fundamental problems. The fundamental problem is that it’s not contract management, it’s project fulfillment (even if you are just buying stuff).

This means that before you can do a contract you have to:

  • first develop a detailed project plan including requirements, desired outcomes, and timelines
  • identify what sub-plan you want to farm out to one (or more) vendor(s, but that requires a lot more planning and possibly subcontracting)
  • create the contract schedule with this plan as well as milestones, reporting requirements, and mutual obligations
  • decide what performance incentives or penalties you want to include to speed up performance and/or prevent late deliveries/completion
  • decide what matters (most) to you and what you are going to require around vendor geography, personnel, sustainability, etc. requirements
  • evaluate the risk and define appropriate mitigation (out) clauses
  • hand it off to legal to complete the Ts & Cs
  • then do a Procurement event
  • then complete it in negotiation, pushing the plan into your project management system once counter-signed

It’s project and relationship management at the end of the day, the rest is just document management, making CMS something that you can do with a high school student and an Access database, since its not where the contract is or how its indexed, but how it’s accessed and used on a daily basis, which should be through the project management system.

And that’s why Project Assurance is so critically important.

Don’t know what that is? Read my original and current series on Project Assurance:

So You Admit You Might Be a Dead-Company Walking. How Do You Avoid the Graveyard? Part 2

In short, as per Part 1, you

  1. keep admitting to every mistake you are making and do something about it, then
  2. continue by looking for cost-effective opportunities for improvement and pursue them and finally
  3. never, ever, ever forget the timeless basics.

Today, we’ll continue by describing what you do when you identify, and admit to, the second mistake we chronicled in our two part introduction to our “dead company walking” (Part 1 and Part 2) series (where we helped your potential customers identify problems that signify you are a SaaS supplier they should be walking away from).

2) A Shiny Exterior is More Important Than a Modern Engine

i ) Flip Your Focus from UX first to Solution First

Too many companies right now think the “lack of adoption” problem is a lack of usability problem because all their founders knew was SAP Ariba or monolithic Jaggaer or decade old GEP smart, which aren’t the most usable of applications for certain tasks, and definitely not usable by anyone but core buyers.

Many successful companies have been started, grown, and acquired or merged into bigger companies for the past two decades to be better, easier, and/or more affordable than SAP Ariba, Emptoris (acquired by IBM, sunset in 2017, one of the first big players), Jaggaer (which was SciQuest until the 2017 rebranding), Coupa, etc (including Procuri, acquired by Ariba; Iasta, acquired by Selectica, merged with b-Pack, rebranded Determine, acquired by Corcentric; EC Sourcing, acquired BidMode then was acquired by Simfoni, etc.). And ten times as many have started for the same reasons and no longer exist (without [nearly as] successful exits). Usability is only part of the problem.

For an application to be adopted it has to

  • be easy to use to the point where it
  • is easier and faster to use it than to circumvent it
    (or to keep doing what the user is doing now) and, most importantly,
  • solve the user’s core problem.

This last reason is why a lot of fake-take, sorry, intake, solutions are going to be ultimately abandoned. Simply making it easy for a user to request something and then showing an animated graphic of the request being forwarded to Bob and then, the next day, showing an animated Bob opening the request once he’s read it DOES NOT solve a user’s problem where they need a product or service to do their job. Unless the platform allows Bob to process and fulfill that request more efficiently and effectively than the current methodology, and, most importantly, gives full visibility into what actions Bob has and is currently undertaking, along with an ETD of when the user will have the request fulfilled, the intake application is worse than not having anything at all. This is because the user still has to message or call Bob to find out what’s going on until Bob manually indicates that he has accepted the request, fulfilled the request, and when (and where) the product or service will arrive.

ii) Design Open API first with full data and process control

Everyone focuses on the UX and UI first because that’s what the users (and executives) see, believing that a great demo will get them the sale. And while, sadly, it will get them some sales from executives with no Tech IQ whatsoever, it doesn’t mean it will get them the renewal, especially after the product fails to be adopted because it doesn’t actually let the users work the way they need to work.

It’s not the UI, it’s the ability to capture the data and run the processes in an acceptable manner, and this is not possible if the UI or workflow is wrong. And you’ll never get it (completely) right the first time. But if you build a solid backend that is fully (Open) API driven for data and process control, it will be easy to programmatically alter the workflow, and modify or rebuild the UI (with external help who won’t even have to know more than the API calls) later to be more appropriate.

Too many companies sacrifice a proper software foundation in their rush to MVP and a sale, and this is what cripples them (sometimes to the point of failure). Think of building software like building a real building. If you only build the foundation for a 2 story house, you’ll never be able to build a 20 story apartment building. But if you build the foundation for a 20 story apartment building, you can build out 2 stories of units to start, sell those, and then build out the rest (when you can show off the demo units and drum up a lot of interest).

iii) Then Design a UX on top that customers use – with their help

Work with beta customers, plural, on enhancements and new modules and get their input on what their core processes are and what would make a UI more usable. While you should never design for any specific customer, you should design to meet the 80% common needs, and, where possible, include as many configuration / customization options in the product (workflow and data collection) as possible (but not the codebase, it has to be software switches, you don’t want multiple code branches in production, ever).

Your chances of success improve greatly if multiple customers will say it solves their problems and they use it daily. It’s not about them loving it, it’s about them using it. That’s the key.

iv) If extra $$$ remain, farm out the eye candy development

It doesn’t hurt to have the application look new and shiny, but that’s secondary to having it work in a modern fashion that will leave your new users with tears of joy the first time they use it (because they thought that no solution could tackle their complex procurement, sourcing, logistics, new product design, supplier management, etc. challenges). So if you have a few extra dollars, once you’ve figured everything out about usability and configurability, then you can hire a UX guru to make it sparkle. (But always remember that a solution that actually works shines on its own.)

Stay tuned for Part 3!

Yes Jon, “We’re Always Right, No Questions Please” is the new Big X and Big Analyst Firm Mantra

This originally appeared on LinkedIn. Archiving it here for posterity (and accessibility).

Dear Jon THE REVELATOR, we need to answer your comment handling inquiry in Censorship in the Procurement World with a quadrant, because they (the Big X and Big Analyst Firms) won’t understand the discussion otherwise.

Personal Not Personal
No Claim 1. Delete 2. Ignore
Valid Claim 3. Insult, Respond 4. Debate

1. If the response has no claim and is personal, such as “You’re an @ssh0l3 and a gr!nch!“, you can delete. Flame wars are for Facebook and X, not business networking platforms.

2. If the response has no claim and is not personal, such as “Hey, I like the colour blue too!“, then you just ignore it, even if you feel it is totally irrelevant. Maybe it’ll distract from the core message or core conversation in the presence of a weaker mind, but take the high road, even if you are preying on that weaker mind as your next sucker, err, client.

3. If the response has a claim, but also has an insult, respond appropriately. e.g. if you get something like, “You’re dumber than a doorknob for not believing in our messiah, Gen-AI, because early results haven’t disproven that intelligence won’t emerge someday if we just give it more cores and more data.”, then it’s okay to respond with something like “Dear disillusioned cultist, if you look at the underlying science, i.e. the math and algorithms, you’ll see that it fundamentally doesn’t even support the capabilities being claimed now and cannot support support the emergent intelligence you so claim. P.S. Please don’t drink the punch at the X-mas party, your employer is almost bankrupt and since it doesn’t want to fold, it has to cut it’s biggest costs somehow …”

4. If the response is just a claim to the contrary with a reasonable argument, such as “your methodology is no better than anyone else’s, and may in fact be worse, as success rates as a whole have not improved and, in fact, for technologies in your hype cycle, have actually gotten worse so you shouldn’t be claiming to be able to provide visionary leadership to tech leaders“, then it’s a perfectly valid comment and question, should not be deleted, and the poster should respond with whatever evidence they have to back up their bold claims. (And if they are just two wild and crazy guys who are all in all just inept strangers in a strange land, so be it! The truth must come out!)

Basically, what we’ve done with your leadership is to just expose the truth about these Big X and Big Analyst cults, who seem to all subscribe to the “𝐖𝐞’𝐫𝐞 𝐚𝐥𝐰𝐚𝐲𝐬 𝐫𝐢𝐠𝐡𝐭, 𝐧𝐨 𝐪𝐮𝐞𝐬𝐭𝐢𝐨𝐧𝐬 𝐩𝐥𝐞𝐚𝐬𝐞” mantra, as I’ve had multiple comments deleted by all of them too!

(And the comments I made didn’t even contain a single mention of f6ckw@ds or tragic quadrants!)

Before You Get All Excited To Learn About Trends for Fall Conference Season

Read SI’s Expose on “Future Trends” from a decade ago, which exposed these “future” trends as artifacts from the past that are polished annually and presented to you on a silver platter.

As per our post last week, with the exception of:

  • Gen-AI being the new fluffy magic cloud
  • Fake-take (sorry, intake) being the new dangerous and dysfunctional dashboards

Very little has changed in the past decade. As a result, do you need to be spending 5K to 7K on a conference to hear the same old, same old that you can read about here on Sourcing Innovation and over on Procure Insights for free?

And if you just want a vacation, take one. You can take a much longer, and better, one if you don’t go to an overpriced conference at an overpriced hotel in the center of an overpriced city.