How can I resolve a huge backlog of over 1,000 man-days without blocking new change requests?

Question

Context

As new and junior product owner have to deal with a backlog made now of 33 changes and and effort of 1000 man-days - mind that I act as product owner, but I am not in IT department and I have no leverages on IT.
We ended up in this situation because there is not enough budget/capacity to manage both BAU and the major project consisting into the replacement of our CRM tool.

It was decided by business to sacrifice and slow down till a complete freeze the BAU. Of course, business is anyway complaining now, after their own decision because they see no changes delivered.

We use an internal IT factory, although some changes on our CRM tool are left to the vendor and require just business and functional analysis from our side.

The backlog receives in average 3.3 new requests per month with an average effort of 34.5 man-days. The system is young and still unripe, so it is reasonable to expect this rate of request for at least 12/24 months minimum.

We have a restricted budget of 400 man-days per year with no chances of increase.

My action plan

What I would do and will propose to business is:

1. review thoroughly the list of changes requested and do a costs/benefits evaluation to cut off all is pointless
2. List item re-define priorities for the remaining changes in the list
3. define the "pace" and quantity of deliverables IT can work on based on their real capacity
4. All new changes coming eventually, must be re-prioritized in the backlog (this we already do).
5. I will tighten up the approval of new requests (left to a CAB) becoming more strict and demanding complete business cases and financial analysis.

Any other suggestion is welcome. I am sorry if this question of mine is not strictly related to Project Management, but I am sure that best practices from that field can suite my needs, and managing BAU is quite like managing a huge project :)

Answer 1

Increase Resources or Set Expectations Lower

I'm not sure what your actual question is, because from a project management perspective you have only three core sliders (also known as the "iron triangle") that you can adjust:

1. Cost
2. Schedule
3. Scope

What you seem to be talking about is scope management as the adjustable slider, which you can tune to accommodate current budgetary and scheduling constraints. So, yes: if you can't increase budget or extend schedule, the only lever left is removing scope to fit within your other constraints.

From a planning standpoint, you'll need to aggressively prune or de-prioritize incoming requests because because they're entering the system at roughly 342% of your annualized time/labor budget, e.g.:

# Convert `hrs/req * reqs/mo * mos/yr / annual_budget` to a percentage.
Integer((((34.5 * 3.3) * 12) / 400).round(2) * 100) #=> 342

As a practical matter, than means you're taking in more work each year than you can perform in three years! That's obviously unsustainable, so something has to give. If the business won't increase your budget or resources, then a Product Owner should guide them into determining what they're willing to give up to live within their self-imposed constraints.

Whether you prune existing backlog or new backlog doesn't change the math here. Either cut work down to fit the organization's constraints, or increase the project's budget/capacity for work. There is no realistic third option.

Answer 2

Although I support what Todd wrote, there is more under the surface than above. So my answer based on my experience as a program director is as followe.
The "golden" triangle is a myth (yes its there on an economic/math basis) but we are talking about social systems here.
So as Todd pointed out you will have no chance to succeed on the given parameters. Wether its managements search for a scape goat or the so called "death march syndrome" in IT projects is of pure academic interest. So I would go for a paradox intervention. The scheme could be:

• Let different peer groups (end-user-groups ,management, IT, vendor,..) cluster the existing requests in three categories (give them max 2 weeks time to result)

  • A .. we need to survive, keep the business running
  • B .. brings additional revenue, customers, margin
  • C .. helps end users, nice reports for mgmt, fancy stuff other companies have - sum it up as nice to have
  • The important thing max 20% are A, max 30% are B and the rest C (number of requests - adapt % down if to many split independent things/ cluster connected requests)

• Parallel while the A/B/C clustering is done in the organization calculate price tags (if not already on the items) having cost, duration to finish, cost/gain = simplified business case, what else you need inyour organization.

• Do a 3h workshop (max 12-14 relevant persons from ALL groups) and let them rank ONLY within the A and B category (If they want to place a B to A as long as an A moves to B its ok)
• Put the price tags on the items start with A1 then A2 and stop when 85% of the available budget is spent. Confront the group with the result, seek their reactions & feedback.
• Present those results to management and get their approval
• Repeat this process again - minimum every year for all still open (not started) and new requests - forget about C requests keep them for historical reasons (reference/ documentation).
  
  Thats how I would tackle the challange.
  Why only 85% budget - The rest is iron reserve for risks, cut downs, ...
  Why simplified business cases -> because the more complex they are the more they lie, nobody can look into the future even if someone tries to tell you.
  Its more important to get a common view on the expected business scenario than thousands of hard figures put into spreadsheets. The question imho fits perfect for project management.

Answer 3

I agree with Barnaby, your action plan is good. Let me add some suggestions I recently wrote in an article that from my experience may be useful:

• Order on Value, Dependencies and Risk. It is up to the Product Owner to decide the most valuable items that need to be on top of the backlog. To do that, it is good to consider the highest value items, the biggest risk and the major dependencies. Based on these considerations, the items can be ordered to maximise the value of the Product.
• Use a Story Map. It allows to put Product Backlog Items both in a sequential order, as well as visualising alternatives. I strongly recommend User Story Mapping, by Jeff Patton.
• Reduce the scope. Choose a specific and measurable goal to focus the product backlog. Remove the items that do not help to meet that goal. It looks radical but it ensures the backlog is focused. And if it is complemented with a product road map, you can capture other items that do not serve the goal but are important, and are not forgotten,
• Eliminate Zombie items. We've seen this several times: adding items to the backlog requested by a stakeholder that we know won't be able to be implemented any time soon. In fact, following the first point, there will be (as Barnaby has commented) some work included in the Product Backlog that will never take place. Product Backlog should be as small as is possible to reduce that waste. Deleted or archived, those items should be removed from the backlog, allowing more time/resources to be focused on the features that will be implemented.

I hope it helps.

Answer 4

Your action plan is already good, but there are a couple of other things you may want to consider.

Firstly, be very transparent about how you are prioritising. Make your approach to the cost/benefit analysis public and share it widely.

This will help when the inevitable questions arise about your priority order.

Secondly, you may want to consider a cull of the existing backlog.

For example, if something has a low cost/benefit analysis it may mean it can never reach the top of the backlog due to the constant arrival of new change requests.

In this situation it is better to remove the item from the backlog and inform the requester that their work will never take place. This avoids the situation where people believe by getting their request on the backlog that it make it inevitable that the request will be acted on. It will also reduce the clutter of the backlog and make it easier to maintain.

Answer 5

Thank you all for the kind feedback. I found several hints in each answer, useful to deal with the huge backlog and business.

I already applied a different classification of changes, introducing concepts of major, normal and standard, which may seem basics for the most of you, but were not used so far.
This, together with a value vs. effort prioritization (same proposed in different ways Codebreaker007 and Barnaby) should help me to really cull requests in backlog.

On the long remaining list of normal changes some more weighted scoring will be needed. Given the low maturity of business on this kind of exercise I will go rather for a "buy change" strategy.