Agile as an Excuse?

It seems that Agile is too often used as an excuse to avoid careful planning and preparation. In this post we are going to review the root cause of this phenomenon.

The majority of large government agencies and non-government organisations operate based on the annual financial cycle. It means that each year their portfolios receive a financial allocation.

The allocation means that the funds are held for a particular part of the portfolio (sometimes called sub-portfolio), a program or a project. Carry-over projects are usually able to use funds straight away but new projects and programs are still required to go through an approval process. Access to the yearly budget is very important for portfolio managers as without it they won’t be able to deliver critical changes.

The challenge here is that during the prioritisation, which typically happens 2-6 months prior to commencement of a new cycle, portfolio managers have only a rough idea of how much they would be able to spend based on known inflight and pipeline projects profile. However, they are aware that significant overspend or underspend of funds in a current financial year is likely to influence the prioritisation results. If this happens it could be very hard to increase the allocation of funds in the future. Financial prioritisation is always a big political game in large organizations.

is npt Also, the top-down approach would be based on reported portfolio performance, which often has a level of optimism bias.

There are two main approaches to manage planning for project budgets and prioritise allocation: top-down and bottom-up.

Organisations with a mature scheduling level are able to complete bottom-up planning and manage project prioritisation based on corporate constraints:
• Critical resources;
• Interdependencies;
• Corporate services;
• Enterprise risks;

However, if the level of maturity is not quite at the required level yet, the portfolio managers could only rely on the top-down approach which typically has much lower accuracy and also brings the following challenges:

• The top-down approach is normally based on some unique models/spreadsheets that a Portfolio manager would bring to an organisation. Whilst it is possible to align individual spreadsheets, it is could be  very hard to track changes if there are not in the corporate standards.   
• Also, the top-down approach would be based on the reported performance of projects, which not linked to delivery schedules.

After the allocation is approved, the next critical step for portfolio managers is to initiate pipeline projects as soon as the financial year commenced. It guarantees that the allocation would be locked against these projects. Usually, in case or reprioritisation, in-flight projects have higher priority against pipeline initiatives.

After formal approval is granted these projects and programs are sometimes put on hold or progress very slowly. Program managers often hesitate to baseline schedules despite the fact these projects already have formal commitments. They just don’t have a reliable delivery schedule at this time yet. In some cases, schedule development even commences after the approval, not before.

Then, around the third quarter of the financial year, it becomes clear that projects forecast accuracy is not at the expected level. Some of the programs have significant underspent, others – report overspent. Portfolio managers are lucky if these underspends and overspends could compensate each other. However, more often project delivery delays result in overall portfolio underspend. When it is discovered it is too hard to spend the planned allocation. Even though the portfolio has pipeline initiatives, typically the expenditure at the initiation and planning phases of delivery is quite low and these projects are likely to consume next year’s budgets rather than solve this near horizon issue.

Once, one of my colleagues, a senior project manager, complained that he was assigned to a new project at the end of the financial year. After initial discovery, he realised that the main target for this project was to find a way to spend outstanding allocated funds. What was going to be delivered was a secondary priority. I also have seen a similar pattern in some portfolios. When after a first quarter there was a high risk of portfolio overspend, in second quarter funds were levelled and in a third quarter, a significant risk of underspent was discovered.

Organisations are looking for solutions to solve this challenge.

Generally speaking, there are two main ways to improve financial predictability: to mature existing approaches or to implement fundamentally new delivery methods. Often it is translated as to mature Waterfall delivery or to implement Agile, as an alternative.

Let’s review specifics of Agile delivery in the context of the challenge we just discussed:

• Agile projects don’t have a baseline against which the results could be measured;

• Project delivery is based on non-quantitative “values” rather than quantitative benefits.

While these two points actually present a disadvantage of Agile delivery, the underperforming portfolios are now able to use Agile as a “shield” and explain that original commitments haven’t been delivered as the priorities have changed. They measure portfolio success only based on expenditure with much improved results.

If Agile is able to solve the allocation challenge, then the simplest Agile framework is likely to be chosen as an alternative to Waterfall. Scrum, which was never designed for project delivery, seems to be the most popular Agile method as it could be implemented relatively quickly and is quite sufficient to be used as the “shield”.

Many projects using Scrum today don’t have real needs or opportunity to deliver changes every week or even every month. They just use it as an excuse to avoid careful planning and preparation.

Not all portfolio managers choose Agile just to solve the allocation issue. They consider Agile as a better alternative to Waterfall for other reasons. There are quite a few reasons why Agile could improve project delivery but it seems that many organisations are just confused by consulting companies promoting Agile. The companies promise improvement of delivery by comparing non-mature Waterfall with mature Agile. In reality, if an organisation wasn’t able to reach the desired level of project delivery with Waterfall methods, it is very likely that they also could not reach mature Agile. In fact, Agile requires a higher level of discipline.

As a result, many organisations landed with a “Hybrid” model, despite the fact that “Hybrid” project delivery frameworks have not been thoroughly developed yet. Let’s take this gap into consideration and stop ignoring it. “Hybrid” should not be just used as an excuse to avoid careful planning and preparation for allocation challenges.