More often than not when teams have had poor results or have failed to deliver it’s usually it was because they were focused on the wrong things.
It was never due to a lack of effort, commitment or desire. Often it’s due to a poor understanding of the problem or the challenge that they were facing.
It’s very simple, if you don’t know what the problem is how can you solve it.
Also with the strict time pressures that we all now work under, the temptation to just start working on the solution before the problem is fully understood is common place and compounds the situation.
If Leadership is about ensuring we our doing the right things then its Leadership, which is accountable for fixing this problem
Its Leadership than needs to take the step back and ensure that the direction the team is following will lead to success.
At one company the on time delivery rate for projects was 26%, with an average delay rate of over 3 months
This meant that for every project requested by the business they had less than a 1 in 3 chance of it being delivered on time, and a 2 in 3 chance it would be over 3 months late.
Given that many of these projects were needed to improve business processes or to help launch new products, this really was poor performance.
The first attempts to fix the problems was to get the developers to code faster as clearly it was their fault that projects were not delivered on time.
This had little to no effect, the delivery rate did increase but only up to 35%, which still meant that 65% of deliveries were late.
Our Business Partners were extremely frustrated with this performance as it meant that they could not plan accurately as they never knew whether they would receive their projects on time or not.
There was a general feeling in the team that we couldn’t do any better as this had been the level of performance for the last couple of years
Given my belief that “every team can be successful if they focus on what’s important” we carried out a detailed analysis into the end-to-end process to try and identify where the delays were being introduced.
We captured as much data as was possible, start and end date of each stage, the duration of each stage and the key hand over points between the various teams involved.
As soon as we captured enough data we was started to carry out analysis to try and identify problems and then potential solutions.
What we identified was several common themes.
- Many projects were late before we even started to build them.
- The build teams were unaware of what dates had been committed to, so they were unaware they couldn’t meet that commitment.
- As the deliveries were invariably late, when they finally were delivered the business partners were unavailable to test them, which pushed the go live dates back even further.
Looking at the data it was clear that our action regarding getting the developers to develop quicker was never going to be the solution, as slow development wasn’t the problem. We were focusing on the wrong thing!
The main issues were that we were making commitments before we had any idea how long it was going to take us to deliver the solution or what resources were available.
The development teams were not involved in the overall project estimation process.
So they were delivering to dates that were important to them and not the business or in line with the go live date.
A lack of clear planning on how long it would take to deliver the projects meant that we were planning unrealistic testing dates with the business.
We also had some small issues regarding rework, where the development teams had not fully understood the requirements.
Given all these issues we had I would say that we were lucky to deliver 26% on time.
It was clear that we had some significant opportunities to improve performance.
We took the bold step of explaining the situation to the business and to get their buy-in we stated that with some changes in the process and their support we were committing to increase the on-time delivery of the enhancements into live to 80% within a 6 month period.
In order to meet this goal of 80% the whole end-to-end planning process was changed.
- The development teams would sign off that they fully understood the requirements.
- They would then create estimates on how long it would take them to deliver the projects, only when the blueprints had been signed off by the business
- It would be agreed with the business when they would be available to test, based on these new delivery date
- The committed go live date was based on the above information.
- The go live dates could only be changed if agreed with the Business Partners and providing it was due to the Business Partners non-availability.
Once these process changes were implemented we continued to monitor and review the process. We also increased the management attention, reviewing the data weekly, to ensure that the changes implemented were correctly followed and were leading to the performance improvement that we were planning for.
By the sixth month we had increased the on-time delivery to 81%.
This was an excellent result.
A beneficial side effect of the whole process was that we had also increased significantly the communication with the business. Which gave the Business more control over the process, if one of the critical projects was going to be late, they were informed before hand and could potentially work with the teams to re-plan priorities based on their priorities to ensure that their needs were met.
Initially when we tried to solve the project on time delivery rate we focused on the trying to speed up the development but as I have shown this wasn’t the problem so we were focusing on the wrong things.
Once we truly understood what the problems were that were stopping us form being successful, we were able to focus on them and turn poor performance into excellent performance, in a short period of time.
by Gordon Tredgold