Category Archives: Best Practices

Building a Good Solution ABSOLUTELY Requires a Good RoadMap

A few weeks ago we tackled the subject of How Does a Vendor Build a GOOD Solution? and outlined seven key steps. SI received some feedback, and most of it revolved around the roadmap and how it should only look three months out!

So we have to address this insanity!

First of all, name ONE great or revolutionary technological invention that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE great piece of software that solves a significant business problem that no other system that came before solved that was invented with three months effort. You can’t, because there isn’t one.

Now name ONE Billion dollar enterprise software platform that went to market with an MVP in 3 months that became a powerhouse that a large swath of businesses are using. You can’t, because there isn’t one.

All you can do in three months is a crap an app that is a piece of crap. Now, you might be able to make a big splash on the app store or in the consumer shareware market, but enterprise software is a complex piece of enterprise technology that requires years of development … and years of planning!

Secondly, remember what a roadmap actually is. It’s a graphical document that shows all of the roads you have available to you, how fast you can travel down them, and where they will take you. It’s not a detailed travel plan!

Similarly, in technology, a roadmap lists out all the things you would like to do, what it might take to get there, and what options could take you there. It is NOT a detailed functional specification or a development plan for the next three to five years (which should be the length of time you should be thinking through). (Also remember that, historically, great inventions came from research labs where the researchers were thinking three, five, and even ten years out and had years to develop groundbreaking developments!)

There are a number of reasons you need to be thinking three years out (even if your plans completely change nine months in), but the most critical reason is this:

If you plan for three months, or go for speed over quality (assuming you can always fix it later) your teams take shortcuts, build crap infrastructure, and add technical debt faster than you can ever eliminate it! (It’s almost as bad as vibe coding your way to an MVP, and then realizing you can never support an enterprise stack on it and have to go back and rebuild it from the bottom up after you’ve wasted months of effort and tens of thousands (or more) on AI credits. (Alex Turnbull gives a good summary in this LinkedIn post.)

When you start thinking about where your enterprise application might need to go, even if you choose not to go in that direction, you understand what processes you will eventually need to support and how you will need to build the foundational data model, workflow and orchestration engine, integration capabilities, internationalization support, and other core foundational features to either build that out or integrate that capability in the future. You’ll have a better idea of what you’ll need in the stack, what you’ll need for the platform, and what the best development environments for your team will be. (Having to change out any of these is very time consuming and expensive should you make a mistake early on.)

For (an easily understood) example, if you think invoice processing sucks (because you only looked at three vendors as you are too clueless to do market research, like many vendors that started during COVID because they all of a sudden realized that the business back-office should be capable of running 100% online, distributed, and remote), what else are you likely going to do after that. (Unless you’re a world leader in invoice processing technology, no one is going to buy just that!) In other words, are you going to support invoice analysis and predictive payment analytics, payment platform integration, contract and PO data extraction and matching, enhanced procurement (platform) support, etc. All of these capabilities will dictate data model, orchestration, and stack requirements.

Again, the point is not to plan out a detailed release schedule, but understand where your customers might ask you to go, where you want to go, where you want to hire a guide (to provide you with the expertise you need), and where you might want to hire a service to take your customers there (because a certain capability is best done by a specialist). This, along with constant monitoring of customer functionality uptake, customer feedback, and user forums will give you the complete picture you need to create the high level development plan for the year and the detailed functional specification for the final release of the next quarter (which might be built incrementally using agile methodology).

To put this in terms non-technical people will understand, you can’t build a twenty-story high-rise on a foundation for a two-story house. By thinking ahead, you’re building a solid foundation, and when you start building, you’re building the frame for the twenty-story high-rise that you can then build out and complete floor-by-floor once you know what the tenants you are signing on want on their floor.

By thinking at a high level years into the future, you are visualizing how you are going to fit into and evolve with the organizational ecosystem you want to sell into, and you are making good architectural decisions as you will be able to build that understanding of what you’ll need to support!

Moreover, as one commenter pointed out, and we noted above, watching how users work with the system is key! That not only helps you understand the depth and configurability of workflow process management required, the breadth of the data models that will be needed, and what systems they will want interfaces to (based on what they use before and after), but how to design a good UX based on now they work and what they are adopting! (It should be noted that designing a good UX, including a good UI, can be harder than the model and controller algorithms — which, if you need advanced analytics, optimization, and higher performance, might take a PhD to get right — because it doesn’t matter how good the application core is if no one uses it!)

Roadmaps are key. That’s how your Chief Software Architect and Chief Technology Officer build great applications. It ensures that once you select a destination, they know the route they have to navigate to get there!

It’s Not Outcomes. It’s Capability.

And that’s why outcomes is a dirty word! (Part I and Part II)

More specifically, it’s about capability, knowledge, the ability to be self-sufficient, and continual improvement.

Our rant focussed on the fact that the entire point of “outcome”-based pricing was to not only lure you away from more affordable products and services (especially if you were willing to do just a little bit more yourself), but take away your self-sufficiency, capability, and even knowledge and ensure your entire existence slowly became 100% dependent on the vendor for key processes. That you’d have no choice but to keep using them because you lost the capability to take the function back in-house. That you’d be the next mark in the grift that keeps on taking.

A big problem with “outcomes”, and another reason that it is a dirty word, is that it’s always focussed on “metrics” that have an impact on “the bottom line” today in a manner that the C-Suite can see on the balance sheet. Since the point of a business is to make profit, all of the “outcome”-pricing vendors argue that it’s the right approach.

While you should get “results”, that’s not the only thing you should be measuring, and it should not be the focus of your measurements. Because when you focus only on “results”, the focus is whatever gets you the best results, and, more exactly, what gets you the best results TODAY. That means you will make decisions that will jeopardize the potential for mid, and definitely long, term results in exchange for better results today that will please the client, your boss, the C-Suite, and/or the shareholders.

A great example of the danger of “outcome”-focus is classic sourcing — and the introduction of e-auctions (which are surging again because people forget the long-term impacts of auction over-use) that kicked our space off!

When awards are reduced to lowest price, and the volumes are large enough that a few contracts can sustain a struggling supplier, especially in tough economic times, suppliers will often sacrifice almost all of their margin just to get an award. This results in a great, immediate, win for the buyer, who can show a huge savings on the balance sheet, but it’s actually a huge risk. If the supplier sacrifices too much margin and costs rise too quickly, their viability is at risk. If they unexpectedly go out of business, the buyer has to find new supply quickly, and if the market becomes tight, this could skyrocket costs or even result in costly stock-outs or, even worse, production line shutdowns. The savings not only disappear over night, but costs increase. And even if the supplier doesn’t go bankrupt, when you go back to market, after a few years, if inflation was low, you might save 1% to 2%, but typically the best case scenario is you find someone who can match the price. However, what typically happens is that the price increases, sometimes by a lot! Why? Because the focus was on getting the best price now, versus coming up with a plan to ensure prices, or at least production costs, continued to decrease over time. Instead of looking for a supplier who would continually invest in better technology, renewable materials and energy, process improvement, etc. to keep costs down, you look for a supplier who’ll cut every corner they can to get a good price now. If you do a strategic engagement and find the first type of supplier, and enter into a long term contract where they know they can continue to invest in improvement, they’ll likely come back with a solution, and a contract, that guarantees a continual cost decrease year-over-year. This would actually benefit you more because not only you would you be able to claim an “outcome” every single year, but you know you have a supplier you can count on to deliver! (And you won’t have to explain the cost increase next time you go to market.)

In order to be a successful business, you don’t have to just profit this year, but you have to profit next year, and the year after that, and the year after that, and so on.

What this really means is that you need to be:

  • instituting processes that will allow you to not only be more efficient, but get more efficient (with experience) over time,
  • implementing supporting technologies that help you continually increase efficiency, including automation solutions that requires less and less exception management
  • increasing your knowledge and capability, so you can always make the best decisions, use the best solutions, and know when a third party can be more efficient or more cost effective (because it’s either a part-time position that’s not worth the hire internally or a function that’s not core to your business and you’d rather it be managed externally until such time as it makes sense to reclaim the function)
  • identifying metrics that focus on capturing process improvement, increasing capabilities, capturing knowledge (for future generations of HUMAN employees), and that result in improvement year-over-year

and NOT focussing on destructive one-time outcomes (that will hurt you later, and possibly a lot more than you realize).

You Really Don’t Need to Read Another State of Procurement Report for Five Years!

Just read this 34 part series and you can ignore the 10+ surveys / studies / reports that will be collectively released by every major ProcureTech consultancy and analyst firm this year (which will likely include, but not be limited to: Capgemini, Deloitte, Everest Group, EY, Hackett, McKinsey, PwC, and many, many more)! We say this with certainty because we reviewed all of the reports they put out for the last 5 years and the vast majority of the content was the same year-after-year and firm-after-firm. You can practically count on any survey/study that tackles barriers, risks, and concerns to overlap with the following at least 80%, and that these will be the most significant barriers, risks, and concerns. In fact, in five years, only one concern will have changed, and that’s the tech-du-jour, because that’s all that was really different between 2025, 2020, 2015, etc.

You’re welcome!

You Don’t Need To Read Another State of Procurement Study for the Next 5 Years!

Top Barriers to Success

Breaking Down The Major Procurement Risks with High or Moderate Impact

Primary Concerns for Procurement Leaders

BONUS

Don’t Focus on Spend …

In a recent LinkedIn post by Celia SGAR, she made a very important point on a key requirement for good Procurement advice.

Focus on Impact, Not Spend!

Now, her advice, governance, assessment, and relationship breakdown was focussed on Supplier and Vendor Management, because otherwise you’re wasting your time reviewing the same suppliers over and over again, but the reality is that it’s good advice that should be applied across the Source-to-Pay and Category Management lifecycle and the only way you’re going to get good results in today’s turbulent trade tussles.

Right now, the typical focus when analytics is first implemented is to find the top suppliers and top categories. Then, you’re supposed to measure those suppliers and source any of these categories not currently under contract or coming up for contract in six months. Then you’re supposed to track those over the next year, match all of the invoices, and report on the savings. Which will end up being less than you expect because the reality is that most organizations know 8 to 9 of their top categories and 8 to 9 of their top suppliers without any analysis, those are the suppliers they are managing, and those are the categories that are being “sourced”, “spot bought”, or a combination of both based on what the organization feels is best.

But this typically isn’t where the biggest opportunities are! The biggest opportunities are in the suppliers providing critical components who aren’t being managed, the categories from the next tier that are not managed because the organization doesn’t realize they’ve went from tail to mid-tier, and the categories where extensive market research has not been done to not only understand market price but should cost.

Contract Management needs to focus on reviewing contracts that don’t have standard terms and conditions, don’t have risk management clauses for emerging and newly identified risks, and don’t have regular measuring, monitoring, and reporting clauses from both sides.

In other words, teams start off on the wrong focus, and continue on the wrong focus all the way through sourcing, contracting, and supplier management because they focus on spend, not impact.

And when it gets to supplier management, by not identifying which suppliers present the most risk due to supplier instability, part criticality, regional uncertainty, trade wars, sanctions, etc, the organization is overlooking, the organization is exposing themselves to risks with severe impact potential by not managing those suppliers first and foremost.

So, if you want to get Source to Pay right, focus on impact, not spend. Not only will you save more, but you’ll be more efficient, and more resilient, overall.