Category Archives: Product Management

Procurement Produces Platinum when Engaged Early

We all know the statistic that 80% of the cost is defined the first 20% of product design, and that engaging Procurement early can significantly attack and reduce these costs considerably. But leading organizations are learning that engaging Procurement during New Product Design (NPD) is not early enough. Real success comes from engaging procurement during the Market Needs Analysis and New Product Definition phase.

Engaging Procurement after the product specs and initial design has been more or less determined limits Procurement’s capability to add value and extract cost. Once you’ve decided on a 9.7″ tablet with 64 GB of memory and a 5.1 MP camera limits Procurement to going to market for 9.7″ casing, 64 GB of memory. and 5.1 MP cameras and boards that support processors that can stay cool in a 9.7″ tablet. You’ve already limited the universe of potential. Moreover, you haven’t really defined what the real value is from a customer point of view (specs, reliability, brand value, sizzle), why, and how Procurement could add to
it.

Procurement really needs to be involved from the inception of a new product introduction project. It needs to be both a sounding board and the voice of reason to help the organization zero in on the right mix of what will sell and keep the costs in line with market expectations (or at least market acceptance). Value to the organization is maximized when profit is maximized — which is maximized when profit per unit times number of units is maximized. This requires balancing cost with consumer values, not just optimizing cost, which is all that can be done if Procurement is not engaged until the final design / pre-manufacturing stage of the product lifecycle.

So, for real results and greater success, engage Procurement early and engage Procurement often. Sometimes the perceived market requirement isn’t worth the cost, and other times it is.

For more information on the product lifecycle, as well as some of the results Procurement can deliver not only early, but at each phase, you can check out Source One’s latest paper on Strategic Sourcing Throughout the Product Lifecycle. It’s a quick read, and if you want to go deeper, they have hundreds of projects they can draw on if you reach out to them.

Societal Sustentation 52: Project Management

Good project management is the key to success. After all, without good management, the chances of a project over-running its resource allocation (of time, people, and money), if not failing, increase significantly. So, despite the fact that project management is a sustentation, it can also be a damnation. Especially if you can not manage the project.

One has to remember that project management has evolved over the last six decades or so to manage traditional types of projects that produce structures and goods against well-understood designs and project plans, starting with the need to effectively manage complex engineering projects in areas that include construction, defence, aviation, and shipbuilding.

When project management was being defined, the ENIAC was still in operation, Procurement was placing an order against a printed catalogue, and a company imported a small number of commodities in which they had contacts and expertise. There were no complex software projects, no complex Just-in-Time supply chain projects, and no automated factory mega-projects (which resulted in some of the biggest supply chain failures in history).

Where software development is concerned, there is a rough definition of what is desired, but the beginning and end is a best estimate that is no more accurate than a wild guess in some cases, the resources required (while defined as software architect, developer, network specialist, etc.) are not well understood (as a non-skilled software architect cannot define what makes, or identifies, a good software architect), and the amount of money required is relatively unknown (due to uncertain work effort requirements, unknown support requirements, etc.).

And that’s just software. When it comes to supply chain, the difficulty is intensified. There’s the management of the sourcing, the management of the negotiation and contracting cycle, and the management of the procurement. But before that, there’s identifying the right supplier, which requires detailed understanding of the product technical requirements and the supplier production capabilities. There’s identifying the expected costs, based upon understanding material costs, labour costs, energy costs, tariffs, and overhead. There’s managing the supplier relationship. There’s dealing with disruptions and disasters. And taking corrective actions.
In other words, supply chain projects don’t have well-defined beginnings. Don’t have well-defined endings. Don’t have well-defined workflows. Aren’t limited to a fix set of resources. Don’t always have a well-defined team. And don’t always have a well-known cost (even if there is a target one).

But that doesn’t mean there is no hope. There are steps you can take to maximize project success.

1. Document all the steps.

For example, if it’s a sourcing project, outline a detailed process from needs identification, through sourcing plan, supplier identification, sourcing, contracting, and supplier management. Each of these steps have been done before, and, on a step-by-step basis, the complexity, necessary timeframes, and risks can be fairly well estimated. If the expected time-frame is more time than you have, then you have to either simplify the project, or increase the risk.

2. Crystallize and clarify all the risks — and mitigations.

What are the risks in the project from a supply disruption point of view? Liability point of view? Supplier point of view? Contract point of view? Make sure the risks are clear, the potential repercussions clearer, and the mitigations the organization can, is, and will take perfectly comprehensible.

3. Implement Effective Change Management

Document all the hiccups that occur (for future learning), and when something happens that requires a change in process or timeline, be sure to document it, the change, and work out the updates to the plan. Don’t play it by ear or wing it, because it’s easy to mis a beat against background noise or get caught on a wire. Make the effort to manage the project, and your project management skills will improve.

4. Get Training

There is a very big Project Management Body of Knowledge (PMBOK) offered, and certified, through PMI and a lot of organizations that are expert in project management, including a few niche consultancies well versed in best practice in best practice supply chain management in the areas of sourcing, procurement, contract management, etc. Engage one and get the knowledge your organization needs to manage better software projects.

5. Use a Tool

Some modern suites offer integrated supply management project management capability and if your suite, or custom assembled best-of-breed platform doesn’t, there are best of breed providers focussed purely on sourcing and procurement project management, like Per Angusta. Get a solution, and use it.

Per Angusta: Purchasing CRM

Per Angusta is an interesting SaaS company in the Procurement space. While most Procurement companies focus on the Sourcing or Procurement process, or supplier management, Per Angusta focuses on the workflow that ties it all together — a workflow that is typically managed in Microsoft Excel Spreadsheet Hell.

In particular, Per Angusta is a SaaS platform built to manage sourcing pipelines, track savings for organizational validation, and make Procurement’s impact visible to the organization — which, as per Sigi Osagie (the master of Procurement Mojo), is the key to building your Procurement Brand.

One of the unique things about the Solution is that the Sourcing Project Management Tool is not only designed to manage the sourcing workflow, but to integrate with your best-of-breed sourcing and procurement tool either out of the box (and, out of the box, integrates with Rosslyn Analytics, HICX, Market Dojo, and other Per Angusta partners) or through the API that is being released shortly.

The solution contains all of the basic project management capabilities you would expect, as well as a few unexpected ones including, but not limited to, deep configuration capability, a supplier data repository, and even Slack integration. Moreover, the strengths of the solution are exactly what you need — flexible project definition and the ability to track deep negotiation details. The platform can track projects of different expense types, document proposed negotiation strategies, and document the requirements of each stage: need definition, sourcing, negotiation, and signature. This is a very powerful capability as it allows the Procurement team to demonstrate that over 80% of the costs are locked in during the design and sourcing phases, and that very little savings can be obtained if the stakeholder waits until the (end) of negotiations and the contract phase to engage Procurement.

The Per Angusta platform is one that is worth exploring in detail, and for a very in-depth review, you can check out the recent piece over on Spend Matters Pro co-authored by the doctor and the prophet.

Organizational Damnation 53: Engineering

So far in our series, we’ve addressed Marketing, Legal, Logistics, and Human Resources. However, as you might have guessed, these are just a few of the organizational damnations Sourcing has to deal with on a daily basis.

Today we add Engineering to the list of organizational damnations that Sourcing has to deal with on a daily basis.

Why Engineering? Why is a department staffed by Engineers and Scientists who, unlike Sales and Marketing aren’t inclined to stretch the truth beyond all recognition; unlike Legal, are inclined to speak plain English; and, unlike HR, are not inclined to find new and innovative ways to suck the life force out of you, a source of eternal Procurement damnation?

Engineers are rigid stubborn perfectionists.

Let’s break this down.

Each engineer has a process, a design, a set of approved raw materials, and that is the process, the design, and the set of approved raw materials. Trying to convince them that there is another process, an alternate design, or other raw materials that might be usable is like trying to force molasses to flow up a glacier. Like doctors, who only want a specific operating tool from a specific supplier, they are rigid.

This is because they are also stubborn. In order to accept new processes, new designs, or alternative raw materials, they would have to accept that there are better processes, better designs, and better raw materials, and that they exist today. If they believe that they are at the top of their game, they will believe that better processes, better designs, and better raw materials have not been discovered yet and even if they are discoverable today, it won’t be by Procurement or the supplier Procurement is bringing for joint innovation, at least not without a lot of time and effort on their part — that they don’t have. Don’t read this to imply that they are arrogant, because they don’t mean to be (unlike ivory tower PhDs), it’s just that good engineers and scientists invest the majority of their time keeping up with their field and honestly believe that they have a much better idea than you, and they are usually right in that assumption. Since it’s not often that Procurement will actually stumble across a better way, and, moreover, since the past track record of Procurement and suppliers — before Procurement was seen as a strategic department and top talent brought in to staff the department — was poor, Engineering will naturally assume that Procurement’s zany idea of the day will be another dead end and will be stubbornly resistant to it.

And, finally, they are perfectionist. The cost model might say 98% reliability is good enough because, in practice, only 1% of units will break down before the warranty period expires and the cost of flat out replacement will have little impact on profit margin, but Engineering will say otherwise. They will insist on selecting the supplier with 99% reliability even though that will increase costs 30% and it makes no sense because it is a consumer electronic device which will cause no injury when it fails and which will have little negative impact beyond temporarily inconveniencing the consumer who will have to call in, get a replacement shipped, and send back the defective unit in the box that arrives. An Engineer takes pride in producing the best quality product possible, even if that would bankrupt the organization in the process.

Their insistence on being the best will be one of the worst damnations Procurement has to face. After all, how can you fault someone for wanting the best? And you can’t even dislike them because, unlike some departments, Engineering is not filled with blood-sucking leeches, sociopaths who figured out how to screw people legally, or evil creatures that take pleasure in your pain. But yet they will cause you anguish in every sourcing project you undertake.

As each and every post in this series explains, Procurement is truly corporate damnation.

For those of you new to the profession, welcome to hell. (And enjoy the archive knowing that we’re only halfway through our journey.)

Societal Damnation 52: Project Management

I’m sure you’re asking — what’s damning about project management? Isn’t good project management the key to success? After all, without good management, the chances of a project over-running its resource allocation (of time, people, and money), if not failing, increase significantly. Well, yes, it is. Provided you can manage the project.

One has to remember that project management has evolved over the last six decades or so to manage traditional types of projects that produce structures and goods against well-understood designs and project plans, starting with the need to effectively manage complex engineering projects in areas that include construction, defence, aviation, and shipbuilding.

When project management was being defined, the ENIAC was still in operation, Procurement was placing an order against a printed catalogue, and a company imported a small number of commodities in which they had contacts and expertise. There were no complex software projects, no complex Just-in-Time supply chain projects, and no automated factory mega-projects (which resulted in some of the biggest supply chain failures in history).

And, more importantly, projects were focussed on the production, or acquisition, of a single structure, product, or report. They had a defined beginning, a defined end, used well understood resources, required people with well-understood skill-sets, could be scheduled with reasonable certainty, and required a comprehensible amount of money.

Where software development is concerned, there is a rough definition of what is desired, but the beginning and end is a best estimate that is no more accurate than a wild guess in some cases, the resources required (while defined as software architect, developer, network specialist, etc.) are not well understood (as a non-skilled software architect cannot define what makes, or identifies, a good software architect), and the amount of money required is relatively unknown (due to uncertain work effort requirements, unknown support requirements, etc.).

And that’s just software. When it comes to supply chain, the difficulty is intensified. There’s the management of the sourcing, the management of the negotiation and contracting cycle, and the management of the procurement. But before that, there’s identifying the right supplier, which requires detailed understanding of the product technical requirements and the supplier production capabilities. There’s identifying the expected costs, based upon understanding material costs, labour costs, energy costs, tariffs, and overhead. There’s managing the supplier relationship. There’s dealing with disruptions and disasters. And taking corrective actions.

In other words, supply chain projects don’t have well-defined beginnings. Don’t have well-defined endings. Don’t have well-defined workflows. Aren’t limited to a fix set of resources. Don’t always have a well-defined team. And don’t always have a well-known cost (even if there is a target one).

Project Management hasn’t kept up. Sourcerors are often making it up as they go. And they’re damned every step of the way.