Why You Need a Project Portfolio

ArgonDigital - enterprise automation experts

Share This Post

The goal of business case development–and it’s a very reasonable one–is to move away from having decisions about which projects to run based on the whims or argumentativeness of individual executives and towards a more objective decision-making process. The problem is that many organizations make the mistake of treating all projects as the same.

In these companies, you’ll find that projects are required to pass a hurdle rate or commit to a specific rate of return to get approved. For example, they may need to have a 10% ROI. Of course, there are rarely any consequences if the project fails to meet that target in the end, because almost any project by that point has had so many people involved that it’s easy to shift the blame for not meeting the target onto someone else or better yet leave it vague and undetermined. So the result is that the business case gets “massaged” until it hits that magical number, approvals are done through the usual executive politics, and the business case ends up being meaningless.

This is the problem that portfolio management is meant to solve.

The key insight you need to “get” portfolio management is that it addresses this flaw by recognizing that every project has a different profile for ROI, and that’s OK. It is not reasonable to expect huge benefits from a network infrastructure upgrade, but every so often it needs to be done or the company grinds to a halt. On the other hand, a new product development project may have only a 25% chance of being a hit in the market, but if it succeeds it could drive the company’s growth for decades.

Portfolio management treats projects like stocks in an investment portfolio. Some stocks will go down. Hopefully most will go up. A few will go up a lot. Yes, it helps to increase the chances of each individual stock going well, but even more important is to have the right mix of stocks. Instead of asking each project to hit a 10% ROI, you take on a number of different types of projects and aim to have an average of 10% ROI across your project pool.

A typical CIO will be managing projects with many of the following characteristics:

  • Regulatory/Compliance projects, where changes must be implemented or someone goes to jail.
  • “Keep the lights on” projects, where investment is needed to keep things running smoothly (say, updating an internally developed program so that it works with the latest version of Windows).
  • “Parity” projects which deliver capabilities that match the offerings or service of competitors, so that the company doesn’t fall behind.
  • Process or service improvement projects that can, or at least should, provide predictable gains in the time a process takes, the quality of service delivered, customer retention and more.
  • Innovation projects that offer a very high return if they are successful, but are also a high risk.

Depending on the company, there may be other categories of spending, such as projects to drive brand awareness or ensure operational safety for workers. With a project portfolio, you allocate a certain amount of your spending to each category of project, and then define the criteria used to assess each type. For example:

  • Regulatory: does it meet the regulatory criteria (yes/no), if so what is the minimum-cost solution.
  • Process excellence or incremental product improvement: usually we look for a predictable, clear ROI from efficiencies and effort reduction.
  • Innovation: Might need to have the potential of a very high ROI, returning ten, twenty, or even a hundred times the investment, but we accept that most of these projects will fail.

Each category of project gets a share of the overall project budget. This will vary from company to company. One company might put 5% of its budget into innovation-type projects, whereas a startup might put 80%. That mix is going to be determined at an executive level based on the company’s strategy.

Portfolio management won’t remove politics and debates entirely from the project initiation process, and I don’t think it should–human insight and judgement will always be needed. But it will make sure you aren’t neglecting a critical type of project, that your spending reflects your overall enterprise needs, and that projects are assessed realistically against targets that make sense for them and against similar kinds of projects, rather than a one-size-fits all standard.

More To Explore

b2b auto pay

B2B Auto Pay: Automation Use Cases

Migrating a B2B “Auto Pay” Program Companies migrating to SAP often have daunting challenges to overcome in Accounts Receivable as part of the transition. You might have different divisions running

ArgonDigital | Making Technology a Strategic Advantage