I was brought in to deliver a project on-time with less than 2 months remaining. While the project scope and deliverables were clear, getting to the solution was not.
R&D was required to get some of the features delivered and that was expected to take up a significant amount of time. The team was cross functional and dispersed – from vendors to in-house application development folks to network and server infrastructure folks within Canada and the USA. There was no time for detailed planning. The deadline was non-negotiable and the project had to be delivered by the due date.
It appeared that delivering on time was a tall order and the team was wondering how in the world they would get it all done.
Taking stock
The first order of the day to determine where all the tasks lay within the process. In order to do that I first created a simple visual board with process steps as columns and each deliverable within the process steps. (Can’t share the details on the board due to confidentiality) The next step was to break down these features into tasks. During this process, I learnt that the team was unable to focus on their current tasks due to dynamically changing priorities and requests. The team needed to be isolated from the noise. So the feature requesters were asked to send requests to me which I put down on the board. The sponsor and I then had frequent sessions to determine priorities.
Improving on the go
This led me to create an two additional queues – Input and Selected. With new feature requests flying in fast, we needed a way to protect the team from constantly shifting priorities. The Kanban board helped achieve that. It also helped the customer see where each feature and task lay in the development process. One additional benefit of the board was that all stakeholders were able to send in their feature requests and I did not have to say no. The consistent communication to all customer stakeholders was that the features would be prioritized by the sponsor into the “Selected Queue” in the decreasing order of importance. Features and tasks will be pulled into the downstream processes based on availability.
After the first week of adjustment, this process worked like a charm. Tasks started getting done at a faster pace. Throughput increased. We were getting a lot further ahead and more importantly we were incorporating change requests too. This made all the difference – the customer team was happy that we not only did not say no to change requests but also embraced them and got what made sense done. We also divorced the build and feature releases.
We also used the board for weekly updates. The management team got together every week around the board to discuss status and priorities. A copy of the board was periodically sent to the team dispersed in various locations. As they completed tasks, we kept it updated. It did not take long for the Done column to fill up. Bottom line: The project was delivered on time. The Kanban board was a significant contributor to the project’s success. The senior leadership team is now looking forward to using the Kanban board for our next project.
