The nature of this industry means that occasionally we work with clients to develop a Decisive Competitive Edge on their competition, as such our clients sometimes wish to remain anonymous.

Our client – one of the UKs leading Financial Services’ organisations – had a problem. They made a commitment to their stakeholders, and worse – the market, that an app would be launched for their corporate customers. In fact, this app was so important that a few of their customers had expressed that if it was not made available for their staff to use, they would take their business elsewhere. The delivery of the app had been promised for June 2021, and by March the best estimate they had for delivery was the end of the year. Our client called and asked for our help.

We began our contact with this client with a short study period (two to three days) which offered our consultant a better understanding of their current ways of working. After all, if you are going to change the outcome of an event (in this case, significantly reduce the lead-time and bring forward the due date), the question you should always ask is: ‘What are you going to do differently?’

When we study projects, we look to unearth practices that are impeding flow and reducing capacity. So, we look for the approach which is being taken towards prioritisation – whether the priority rule is being followed. Next, we gather data on how many pieces of work are in progress and the rate of completion of the work. Following that, we will look at how planning is being done, particularly if the team is overplanning; this takes away important time from delivery. We also look at whether the plans are helping in execution. We want to know how long the project is being measured for and whether it highlights recovery actions quickly. Most organisations issue a RAG (red, amber, green) status every couple of weeks. This will illustrate that everything is fine, until it isn’t…

Despite the project being Agile in design, it suffered the same challenges as many traditional designs; and a few more which are specific to the Agile world. Our data gathering demonstrated that there were seven different methods to prioritise work (the worst case we’ve seen is twenty-four!) which naturally meant there was no consistent method to keep work in the same order. Managers argued that the priorities must continually change but it simply wasn’t the case. The consequence of this belief was that team members were multi-tasking on a grand scale, frequently starting and stopping new pieces of work. This resulted in huge amounts of Work-In-Progress (WIP) which allowed teams to load up ‘sprints’ with work in the wrong order; and then, not having completed all of it, put it back into the backlog and start a new batch of work for the next fortnight!

Planning was no better… One problem was that tasks were being sized too small. In fact, they had 350 tasks all planned out which meant that when a change was made to the scope (which occurred frequently), then all 350 tasks had to be replanned. Another problem within planning was that it was being completed by the wrong people using the wrong method. Typically, the scrum master built the plan and sent it out to be checked. With teams already being busy, the plan was rarely challenged despite issues being present.

Managers felt that the answer was to hold their team’s feet to the fire through enforcing strict due dates. However, this seemed to make things worse. Parkinson’s Law dictates that work expands to fill the time it is given. This means there was rarely an on-time finish; more frequently it resulted in a late delivery.

We began building a short-term plan. A few months is long enough before accuracy of estimation is lost. We included the whole team which allowed for real clarity on the deliverables and a group approach to estimation. With a consistent approach to sizing (nothing above 15-20 days) we soon had a good plan with the priorities understood, outcomes clear and work that was sized so we could benefit from frequent finishes.

The next step, and arguably the most important step, was task management. Again, we released small chunks of work with a simple rule: ‘if you can’t finish the work, then don’t start it’. We allocated a Task Manager to ensure that the work could be started and finished. There was also a rule specifying that if someone got blocked, they were to stop and find help – not start another piece of work. Soon we saw that work started to fly through the system.

Finally, we tackled measurement. A move away from the traditional RAG status prompted a transition to daily measurement. A simple question was put to each team member: ‘what is the remaining duration for your piece of work?’. This allowed us to aggregate the small durations of the wider project and get early visibility over what tasks were running late and where action needed to be taken to get back on track.

The result? Not only was the project brought in earlier than its predicted finish date at the end of the year, but it also finished on the original due date! This delighted both stakeholders and clients; they got what they wanted with no reduction in scope.

Managing projects is common sense (most people can articulate what needs to be done), but it isn’t often common practice. If you work in a project environment and the challenges our client was facing feel familiar (high multitasking, poor due date performance, contradicting priority systems…) you would benefit from Goldratt UK’s years of experience in the sector. You can arrange a phone conversation with an industry expert by emailing [email protected].

© 2022, Goldratt UK