Prioritisation and Scheduling

Problem

Within the delivery team, projects were too often being re-scheduled and sliding a long way past their initial completion date.  While the “blame” was put upon the team, from an outsider’s perspective it was clear this was not correct

Typical issues that needed to be resolved included:

• Any project prioritisation agreed quickly "expired" as agreements were too easily overridden,

• New priorities or business critical needs took over, often being highly distracting,

• Those with “loud” voices took the resource from more deserving departments,

• Little assessment of business value or benefit was given to prioritisation,

• While some departments received the most attention, others were left severely wanting,

• As project timelines slide, scheduling multiple teams and coordinating effort became increasingly difficult,

• "Dead" projects would continue as prioritises when they should really be reassessed,

• The quantity of output was high, but the business value was low.

A New Approach

Continuing with the same approach, even with tighter controls was not going to deliver the fundamental change needed to the business.  With Lean Portfolio Management techniques in mind, I considered how to change the process, but within the environment I was operating.  This meant not all the techniques could be used.  Focusing on the prioritisation and schedule elements I needed to move away from the delivery team owning these activities to a practice where the business units took a shared ownership.  This meant that any impact of changing priorities was felt by delivery and business teams.

The approach I implemented offered the organisation:

• A delivery commitment to business units based on their need for next quarter,

• A defined capacity allocation for a business unit to schedule work within however they see fit,

• One business units change of prioritises will have little impact on others,

• Any change in direction based on needs or business as usual, BAU, within the quarter is possible,

• The business need drives the work allocation to the delivery team, not an arbitrary schedule dictate what and when,

• Ensures appropriate output for all business units,

• Scheduling becomes a shared task with the business/business owner, or product manager, whatever is applicable.

At regular intervals, normally quarterly, the available capacity is shared with all business units.  It was important for the business to see total available capacity and not just assume more was available.  Those needing more were given more, those needing less had less.  Importantly this is a shared process and one where the entire business needs are reviewed and “resource trading” can take place.  Two unexpected but notable benefits with the process were:

1. Business units would “club-together” for more common features and functionality, and

2. During capacity planning all business units could learn of others needs which resulted in them seeing the benefit to them of others getting some work done quicker.

On occasions where capacity was limited, it became a business decision to increase through contractors or over-sourcing.

Figure 1.2, The allocation session takes place with all business units.  Capacity after allocation to business units.  Each business unit has an agreed delivery capacity for the next quarter.

When the allocation was agreed, scheduling was done at a business unit level.  The backlog can be allocated in an Agile Kanban or Sprint style.  If higher priority needs come in during the quarter, they easily slotted in with only the one business unit affected.  Scheduling was now a shared process, as was the effects of changes.

Scheduling was set to be monthly as this was found to be the most suitable and convenient timeframe.

Figure 2.2, As new priorities for the business unit emerge, the business unit can decide where to fit them in.  When "allocation" runs out some project are subject to delay, this is decided with the business unit.

Figure 3.2, Each business unit can prioritise work based on their prioritises in a sprint style board.

Figure 3.3, As new prioritises emerge they can be "slotted" into the business units own sprint board.

The main task for the scheduling manager was to even out the capacity allocation so work was neither stop-start nor bulked together.  This was much easier than the continuous “chopping-and-changing”.