Category Archives: Project Assurance

Proper Project Planning is Key to Procurement Project Prosperity! Part 2

In Part 1 we noted that we wrote about the importance of Project Assurance, and how it was a methodology for keeping your Supply Management Project on Track, ten years ago and that this typically ignored area of project management is becoming more important than ever. Given that the procurement technology failure rate, as well as the technology failure rate as a whole, hasn’t improved in the last decade, and is still as high as 80% (or more) depending on the study you select, that’s a problem. Especially when, for many companies, theses projects typically start in the million dollar range. (Even if the annual license is only 100K, by the time you multiply that by 3, the minimum term any vendor will give you, the annual maintenance fee by 3, and then add the implementation, integration, training, and ongoing integration maintenance costs and ongoing training costs, it’s well over 1M.)

But we also noted whereas there might have been a time when this was enough to tip the odds of success in your favour, it’s not quite enough anymore. Given the complexity of modern procurement (which hasn’t had as many complex problems to deal with simultaneously in over two decades) and modern technology (which is now AI enabled, AI backed, AI powered, AI enhanced, and or AI driven, even if it isn’t), when most organizational users are still struggling with basic technology (not enabled, backed, powered, enhanced, or driven by [fake] AI bullcr@p).

We told you we were going to dig into the project steps and help you understand what you need to do to get it as right as you can and greatly increase your odds of success. But first, there is one critical action you need to make that is common to all steps that is critical for your Procurement Project Prosperity and that is:

  • Engage an independent expert to guide you through the entire process and help where needed, including assurance.

As noted, this individual

  • cannot be an internal resource, even from a different department, as they are still subject to the internal pressures from the C-Suite (fast, cheap, etc.) that might be counter-productive to project success (that is critical for eventually obtaining the ROI you purchased the platform for in the first place)
  • cannot be a vendor representative as their only goal is to get you to buy more, or at least keep your subscription at the initial purchase level (which likely contained seats you never used, SKUs you don’t use enough to justify, and third party feeds/integrations you aren’t taking advantage of)
  • cannot be an implementation team representative, even if they are a third party consultancy, as the odds are that consultancy has a preferred partnership with the vendor and will be biased towards keeping the vendor and doing whatever is easiest (and thus most profitable for) the vendor to keep getting their implementation referrals

Now, what’s the difference between helping and pure assurance? In addition to making sure each step is accomplished effectively, this person is also guiding you through the creation of the necessary artifacts of each step to ensure success. This person is helping you define the goals, not just ensuring the goals are met. The person is simultaneously a project guide and a project evaluator, bringing the Procurement Best Practices and Technology Knowledge that your organization doesn’t have, and helping you identify the right intersection to take you forward on your journey.

And this goes well beyond just helping you write an RFP (although this is a key step, which is why the doctor has been telling you to get expert RFP help for your Procurement technology RFP for close to two decades, because a bad RFP is one of the leading causes of project failure).

This is because, as we noted ten years ago in our original Project Assurance Series (Part I, Part II, Part III, Part IV, and Part V), project success depends on more than just getting the technical specifications right. Project success also depends on getting the talent right — as it is the people who will have to use the new system. And project success also depends on getting the transition right —- if the changeover is not smooth, significant disruptions to daily operations can occur. And, equally important, they also depend on an often overlooked 4th “T” —- tracery. Organizational success depends on selecting a superior strategy and seeing it through until the desired results are achieved (or the organization changes the strategy). (And since you don’t know what you don’t know, the small cost of engaging an expert, relative to the overall project cost, will generate a return far, far greater than the technology ever will.)

Tracery, which stems from late Middle English, can be defined as a “delicate, interlacing, work of lines as in an embroidery” or, more modernly, as a “network”. Implementing a strategy requires effectively implementing all of the intersecting “threads” that are required to execute the strategy to success. If any one aspect is overlooked, the project can fail. And if you can’t even see all the threads, it should be easy to understand how most projects essentially fail as soon as they begin and why you need a master weaver if you want to beat the odds and actually succeed.

Come back for our next installment where we will dig into the six traditional project steps outlined in our original series and dive into what your independent, third party, Procurement technology project guide (who will be independent from you, your vendor, and the vendor’s third party implementation team) needs to do.

Proper Project Planning is Key to Procurement Project Prosperity! Part 1

Ten years ago we wrote about the importance of Project Assurance, and how it was a methodology for keeping your Supply Management Project on Track (Part I, Part II, Part III, Part IV, and Part V).

We told you that Project Assurance, which takes a proactive approach and tries to identify issues, and implement mitigations, before they arise, involves the organization periodically stopping to objectively assess project failure points as they arise, typically with the help of an outside third party who can be completely objective, to identify what is and is not being done well and what could cause failure later if not adequately addressed now.

In traditional Project Assurance, there are six health assessments at six critical points in every project (for each of the six initial project phases defined by the classic waterfall project methodology). In particular, there is an assessment at each of the following steps:

  • Strategy (Pre-Presentation)
  • Acquisition (Pre-Vendor Selection)
  • Planning (Pre-Design)
  • Design (Pre-Acceptance)
  • Development (Pre-Testing)
  • Testing & Training (Pre-Acceptance)

And that the right assurance expert can help you with

  • expectation management during the strategy development
  • narrowing the procurement gap during the acquisition phase
  • aligning the troops during the planning phase
  • delineate the disconnect during the design phase
  • evaluate for acceptance during the development phase
  • tame the transition during the testing and training phase

And we stand by these posts and the importance of a third party expert helping you with the assurance ten years later, because we feel that if more companies adopted the methodology, we might not be in the situation a decade late where we still have a ridiculously high failure rate in procurement technology projects (as well as technology projects as a whole), that, depending on the study quoted, still exceeds 80% in some cases.

But we also recognize that, given the complexity of both modern Procurement (which hasn’t had so many issues to deal with simultaneously in over two decades), and modern technology, project assurance isn’t enough to save a project that isn’t planned right from the get go. (You just don’t have time to identify and fix all the problems once things get underway and you have the army of grunts simultaneously doing the implementation, all the integrations, and training as they try to rush an enterprise project that used to take two years and get it done in 9 months so they can promise payback within a year (which never happens when they do this — but that would be a different rant).

So, in this short series, we are going to dive into the project steps and help you understand what you need to do to get it as right as you can and greatly increase your odds of success.

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.

Procurement Trend #14. Shorter and More Complex Product Life-Cycles

Eleven anti-trends from the pre-internet pundits still remain, and as much as we’d like to not give yet another reason for LOLCat to hate futurists, we must continue to make sure that no good deed goes unpunished and since the futurists’ advice is still as good as it gets, we must break it all down until you can look past the shiny new paint job and realize that it’s still a twenty year old Skoda you are being sold.

So why do so many historians keep pegging shorter and more complex product life-cycles as a future trend? I honestly can’t fathom this as the video console, cellphone, and apparel industries have been in this mindset for over two decades, but maybe it is because the futurists, who finally realized that the internet has given everyone a need for speed, are finally catching on or because:

  • consumers in some verticals, like electronics, expect major new releases each year
    because they’ve been conditioned by the manufacturers and the marketers to, and
  • they expect every release to contain more new and exciting features than the last one
    even though they don’t even use half of the current features, and
  • they also expect each new product to be smaller, lighter, faster, and more powerful than the one before …
    even though they’ll then complain about lack of battery life, screen resolution, or something else when you have are faced with an impossible choice between two incompatible feature requests.

So what does this mean?

Annual Release Cycles

No matter how good Procurement is doing, it has to do it better, faster, cheaper and keep doing it better, faster, and cheaper (relatively speaking) every year. To do this, it’s going to have to institutionalize its knowledge and process in a workflow driven sourcing suite with integrated analysis and optimization that will tell it if its method is still appropriate, the market is ripe for the preferred event structure, and the costs are optimized.

Constant Innovation

The product has to keep improving, which means the organization and its suppliers have to keep innovating and Procurement needs to manage that innovation. Knowledge management, team management, and project management is just the beginning. When the team hits a dead end, Procurement is going to have to bring an innovation methodology like TRIZ, FORTH, or Design Thinking to the table to help it get past the finish line.

New Market Identification

At some point the incremental improvement in the new product is going to be so minimal that it’s going to lose value to the market and if the organization doesn’t phase the product out, the market will. So the organization not only has to constantly identify potential new versions of its products, but new markets for which it can design new products for. Preferably blue oceans, but open seas are a good start.

Procurement Trend #27: Inter-Departmental Collaboration

Twenty-four trends remain
Together they bring disdain
We’re trapped in the mundane
They are Lucifer’s bane
… and we cannot rest until they are slain!

We cannot give up. We cannot give in. We must shed light on the darkness that each and every false prophecy brings. Only then can we move forward.

The journey is long and hard, but at the end of this thirty part series, you should not only understand why so many historians are still talking about the false trends we debunked in our Future of Procurement series, what you need to do to prevent staying in the past with your organizational “peers”, but what you need to do to not only stay in the present but start marching towards the future, which is coming faster than you think.

So why do so many historians keep pegging this as a future trend? There are a number of reasons, but among the top three today are:

  • Stakeholders are multiplying
    as Supply Management spreads
  • Stakeholder review and participation is increasing in importance
    as more knowledge work is being outsourced
  • Fiefdoms still exist in large(r) corporations
    as many organizations still measure your worth by the number of people under you or the budget you control and not the value you bring to the organization.

Multiplication of Stakeholders

Team management skills are now at a premium. A Supply Management leader not only has to manage a cross-functional team to be successful, but a team where each department being represented is typically at odds with each other and itching for a full-contact rugby match. (It wouldn’t be unrealistic to suggest that your organization might want to start by bringing in a career kindergarten teacher.)

Project Management skills are also becoming more important by the day, as the Supply Management team will need to maintain appropriate focus in each of the cross-functional team members to insure that things get done when they need to get done to keep each sourcing event and procurement project on schedule.

The Knowledge Economy

While often overlooked, knowledge management and collaboration portals will soon become a key part of your organization’s technology infrastructure. Your organization needs to capture all input and organizational knowledge (before it walks out the door), track all relevant issues, and make sure all of the relevant information not only gets in the hands of who needs it, but when external parties are involved, capture their knowledge, decisions, and processes (and not just output) as well in case it needs to be reconstructed or redeployed later on.

Fiefdoms

Off with their heads! Well, figuratively at least. If your organization has one or more fiefdoms, then your organization has someone unwilling to relinquish control, even if that is what is required for the greater good. In this case, your organization has to fight the urge to try and fix the problem with more training or yet another reorganization (which is typically very, very disruptive) and simply do what the kings of old did when they had problems with the dukes — and take off their heads!

If, and only if, the leader can be reformed, give her another management position within the company (and possibly initiate some inter-departmental collaboration at the same time as she will more than likely be more than willing to work with her old department). But if he’s stuck in his ways and can’t be reformed, bite the bullet, give him a fair severance package, and push him out into the outside world. Just like a ship that’s dropped anchor can’t sail, a company with a lead filled sandbag can’t rise above the clouds, no matter how much hot air that individual puts out on a daily basis!