Prioritisation and Scheduling
In this article I tackle the problem of projects being re-scheduled and delayed, and put forward a new approach to prioritisation and scheduling that involves the business units taking a shared ownership of these activities.
There has been some simplification within this article to a) focus on the core concept and b) remove any company identifiable references.
Executive Summary
The old approach for the delivery team to action prioritisation and scheduling was not working for the business as too many projects were significantly delayed. The new approach involves the business units taking a shared ownership of prioritisation and scheduling with a number of benefits including flexibility, agility, and improved output across all business units.
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:
Business units would “club-together” for more common features and functionality, and
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.
Figures 1: Representation of capacity allocation process
Figure 1.1, Available capacity ready to be allocated to business units. The blue and pink "blocks" represent different delivery sub teams units of capacity.
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.
Figures 2: Representation of possible scheduling in a Kanban manner
Figure 2.1, As new priorities for the business unit emerge, they can decide where to fit them in.
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.
Figures 3: Representation of possible scheduling in a Sprints
Figure 3.1, Representation of capacity allocation by business units. Each business unit is represented by a different colour. Scheduling is mapped out according to known projects so teams can work together and stop-start is avoided. Deadlines are also taken into consideration.
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”.
Related Articles