Agile Project Portfolio Management? How to fund your projects

This is the fifth article in our agile project portfolio management series. The first article explored the concept of project portfolio management and how it relates to projects that are executed with agile delivery methods. The second article discussed demand management, and the third was about categorizing your project backlog. The last article was about evaluating your portfolio. Originally this article would be about portfolio alignment, but when I started writing it I felt that a piece of the puzzle was missing. Namely funding. That is why I decided to write this article first, and save alignment for the next.

We already established in the previous articles that you can only evaluate and select a meaningful project portfolio when you know the available funds and people for your portfolio. Since you do not know upfront which projects you are going to select, and you also want to have the flexibility to accelerate, kill or de-prioritize existing projects it is an essential part of Agile project portfolio management to implement funding on an initiative or strategic goal level, and NOT on a project level.

A company that has the size where project portfolio management adds the most value is typically organized into business units and/or cost centers; each cost center must contribute project spending or people (the primary cost element) to the new effort. This creates a number of problems, including:

1. The project budget process is slow and complicated; it takes many individual budgets (one per cost center) to create the project budget.

2. It drives teams to make detailed decisions far too early in the project. Teams are forced to come up with plans that are just guesses; if they can’t identify all the tasks, how can they estimate how many people are needed, what skills they should have, and for how long?

3. The assignment of people to a project team is a temporary thing; the organization assumes people will come back into the cost center for future assignments. If they don’t, other planned projects will suffer.

4. The model drives cost center managers to make sure everyone is fully allocated. However, running projects at hundred percent utilization is an economic disaster. Any small amount of unplanned work will cause delays, which will be even worse because of the time spent on re-planning.

5. The model prevents individuals and teams from working together for longer than the duration of just the one project. This has a negative effect on knowledge acquisition, team performance, and employee engagement.

Once the project is initiated, the challenges continue. The actual needs of the business change quickly, and the reality has not much to do anymore with the assumptions that the project made. However, the projects cannot adapt to the changing priorities, because their budgets and people are fixed for the project duration.

The result is that the organization is unable to adapt to the changing business needs without the overhead of re-budgeting and reallocating people. Overhead kicks in; economics suffer. The cost of delay (the cost of not doing the thing you should be doing) increases.

But we are not done. For example, software development projects cannot happen without takings risks. By its very nature, development is extremely difficult to estimate because it contains a large degree of technical uncertainty. And everyone knows that most things take longer than planned. Moreover, even when things go really well, stakeholders may want more of a specific feature. That takes longer, too.

Project-based funding hinders forward progress, culture, and transparency.

When a schedule overrun occurs for any reason, it is necessary to analyze the variances, re-budget, and re-plan. Resources are scrambled, and reassignments of people occur. Other projects are negatively impacted.

The “blame game” sets in, pitting project managers and Product Owners against each other and financial analysts against the teams. Any project overrun has a budgetary impact. The casualties are transparency, productivity, and morale.

So ideally you would fund initiatives or strategic goals (see for example the Strategic Bucket Model in the previous article). You could fund larger programs as well, but I am not a big fan of programs on an execution level. Just do not fund single projects.

Unfortunately, the reality in most companies is that funding is on a project level. So when you are not able to change this have a look at my article Agile Project Budgeting to see how you could minimize the negative impact of project level funding. But be warned, as will be clear from the following articles, the added value and success of Agile project portfolio management is depending on implementing funding on strategic goal or initiative level, and not on a project level.

The next article in this series will be about portfolio alignment. In other words, selection, prioritization, and balancing of the set of projects that will be executed. We will also cover some queuing theory because a big issue in many companies is executing many projects in parallel. In other words, selecting too many projects.

Sunday, May 14, 2017

Agile Project Portfolio Management? How to fund your projects

Other articles in this series