2.2.3: MECE Structuring and Component Inventorying

MECE Structuring and Component Inventorying 

Before a portfolio manager can prioritize anything, they need an honest, complete list of what already exists. This sounds simple, but most organizations don't actually have one. Old projects linger long after anyone remembers why they started. Duplicate initiatives run side by side under different names. Nobody notices until someone finally asks a basic question. What are we actually working on right now?

Why an Inventory Comes Before Everything Else

It's tempting to skip straight to scoring and prioritizing. That feels like the real work. But scoring a list that's wrong doesn't produce a wrong answer that's easy to spot. It produces a confident-looking answer built on bad information, which is worse, because nobody questions it. A governance board that approves a prioritized list has no way of knowing the list was rotten from the start.

This is why component inventorying has to happen first, not as an afterthought squeezed in before the real analysis. A portfolio manager who skips this step is optimizing a fiction.

Key Definitions: The MECE Principle

MECE stands for mutually exclusive and collectively exhaustive. Mutually exclusive means no two categories in the inventory should overlap. A project should not accidentally get counted twice under two different names. Collectively exhaustive means the categories, taken together, should cover everything with nothing left out. No project should slip through uncounted simply because it doesn't fit neatly into an existing bucket.

Applying MECE to a project inventory means every component ends up in exactly one category, and the full set of categories leaves nothing unaccounted for. That sounds obvious written out. In practice, most organizations violate both halves of it at once, without realizing they're doing it.

MECE and Its Roots at McKinsey

The MECE principle didn't start in portfolio management. It came out of McKinsey, the consulting firm, back in the late 1960s. Consultants needed a way to break down messy, complicated business problems into pieces that made sense and didn't overlap. MECE became the standard tool for that, and it's still taught to every new McKinsey consultant today. It has since spread far beyond consulting into finance, strategy, and portfolio work of every kind.

Portfolio managers borrow this same discipline when they build a component inventory. A messy, overlapping list of projects is exactly the kind of problem MECE was built to fix. Applying it turns a confusing pile of initiatives into a structure a governance board can actually trust.

Building the Clean-Slate Inventory

A useful way to start, especially in an organization with no existing prioritization model, is a clean slate approach. This means throwing out any assumptions about what the portfolio contains and rebuilding the list from scratch, based only on what can actually be confirmed.

The process usually works in a few steps. First, build a full inventory of every approved and in-progress project, pulling from every department rather than trusting one central list that may already be outdated. Second, build a matching inventory of available resources, since a project inventory means little without knowing what capacity exists to support it. Third, apply clear categorization criteria to sort through what's been found.

That sorting step is where most of the real value shows up. It means looking for duplicate initiatives quietly doing the same work twice under different names. It means looking for interrelated projects that should be managed together rather than tracked as separate, unconnected efforts. It means looking for poorly performing projects that are draining resources without producing real value. It means looking for projects on what amounts to a death march, meaning they're no longer feasible no matter how much more time or money gets thrown at them. And it means looking for projects with weak strategic alignment, ones that never should have been approved in the first place and have simply never been challenged.

A Clean-Slate Sweep

Picture a mid-size company with forty active initiatives on paper. A clean-slate inventory finds that six are actually the same initiative logged twice under different names. Four are propping up a product the company quietly stopped selling last year. Three have been stuck at "almost done" for over eighteen months with no realistic path to finishing. None of those thirteen should carry into the next scoring exercise. What's left is a smaller, honest list the portfolio manager can actually prioritize with confidence.

This kind of screening isn't glamorous work, and it's often skipped in favor of jumping straight into execution. But skipping it just moves the problem downstream, where it gets harder and more expensive to fix.

The Five Failure Patterns in a Portfolio Inventory

The categorization step above tends to surface the same handful of problems again and again, regardless of industry. Naming them clearly makes them easier to catch during a review. Table \(\PageIndex{2}\): Common Inventory Failure Patterns lays out five recurring problems found during a portfolio cleanup, along with a plain example of each.

Table \(\PageIndex{1}\): Common Inventory Failure Patterns  

Pattern	What It Looks Like
Duplicate	Two teams building the same reporting dashboard, each unaware the other exists
Interrelated	A data migration project and a security upgrade tracked separately, even though one cannot finish without the other
Poorly performing	A three-year-old initiative still consuming budget with no measurable output to show for it
Death march	A project everyone privately agrees will never launch, but nobody has formally closed
Weak alignment	A pet project approved years ago that no longer connects to any current strategic goal

Spotting these patterns is what separates a real inventory from a list that simply restates whatever a spreadsheet already said. It also directly protects against the bullwhip effect, where a small distortion early in planning, like one uncaught duplicate, ripples outward and gets amplified as it moves through scoring, budgeting, and resourcing later on.

Myth

A common assumption is that every historically approved project automatically deserves a spot in the new inventory. In reality, past approval isn't a guarantee of anything. Every component has to be checked against current strategy, not grandfathered in just because someone signed off on it years ago.

That's exactly the kind of blind spot a reliable inventory is meant to catch, and the cost of missing it can be far larger than a single outdated project.

Reliable Inventory Is a Million Dollar Question

It's tempting to assume a company always knows what it actually has. In practice, that assumption is often wrong, and getting it wrong can cost real money.

The API Audit

A top consulting firm was once brought in to audit a large company's technology footprint. Executives estimated the company had around 200 APIs in use. Developers, closer to the actual codebase, guessed the real number was closer to 4,000. When the audit finished, the true count came back at over 8,000 active services.

Nobody had been lying. The gap simply grew over years of teams building things independently, with no central inventory anyone fully trusted. Duplicate services did the same job under different names. Old services nobody used anymore were still running and still costing money to maintain.

This is the same failure mode MECE is meant to catch, just at a much bigger scale than a typical project list. If a company can be off by a factor of forty on something as trackable as its own software services, it's easy to see how a portfolio's project inventory can drift just as far from reality without anyone noticing.

The lesson for a portfolio manager is direct. A trustworthy inventory isn't a nice-to-have step before the real work starts. It's often where the real savings are hiding. Cutting duplicate or abandoned components can free up more money than any clever prioritization formula applied afterward.

A rigorous inventory, built with MECE discipline and checked against the failure patterns above, is what makes everything downstream trustworthy. Scoring models, roadmaps, and governance decisions are only as good as the list of components they're built on.