Getting Control of Distressed Projects

This is the first post in a series by one of our partners, Steve Andrews at Fountainhead Solutions, and how he used Kanban and Lean development techniques to rescue a distressed project for one of his clients.  Steve helped the team to implement Kanban using VersionOne Enterprise Edition.

Background

This particular project for a large client was a custom development project that had been in progress for about a year. The development team reanged in size from 10-15 team members. There was one project manager who was onsite with the client in Europe, a core development team in the U.S., and three developers in India.

The team used a typical waterfall development model. An analysis phase preceded the development phase. The analysis phase was supposed to take 2-3 months but ran over that time. The scope grew beyond the initial understanding of both the client and the development team. While the analysis phase ran over through the fault of both the client and the team, the end dates were not pushed out to align with that reality as new scope was added. As a result, the development team was pressured to deliver more-than-anticipated functionality in a less-than-anticipated timeframe. The development deadlines were missed, and since testing was bolted on at the tail-end and compressed, the quality of the developed solution was inadequate.

The development team was operating in an interrupt-driven manner because the project manager did not manage the client to protect the development team from distractions. The typical pattern was that she would get yelled at by the client about the quality issues and then she would just pass that through to the development team. So whatever was the crisis of the moment was what received the attention. The development team was never able to focus on a problem and drive it to completion before the next problem interrupted their work.

By the time we got involved, the relationship between the client and the development team was damaged and the client was refusing to pay. The solution was unusable by their users from functionality, reliability and performance standpoints. The project had run over budget by hundreds of thousands of dollars. The schedule was blown by months. Neither the client nor the team could afford the fallout of a failed project, so it had to be turned around.

Getting Control

The first thing to do when confronted with this type of assignment is don’t panic. In this particular case, the client was very agitated and had zero confidence in the developer. The client was blaming the team and the team was blaming the client. Morale was poor, and it was getting worse because management was demanding that the team work harder to fix the problems. One of the worst things you can do is to dig your heels in and keep doing more of what got you in the situation in the first place.

Experience has shown that the best way to start removing the emotion from these types of situations is to work with the data and facts. It is important to understand the root causes of how the situation arose in order to best craft the path forward, but initially it is not helpful to present the team with all the things they should have done differently. That only inflames the situation further.

In this particular case, the main fact was that the product quality was terrible. This was supported by the number of reported defects. We had to get the product to a point where the users could actually do their jobs. And the only way we could start to do that was to create the environment for the development team to be able to focus on one problem at a time.

In the next posts I’ll discuss how we got this project back on track and ended up delighting the customer. At a high level, the actions we took fell into the following categories:

• Put quality first
• Control the flow of work with a pull system and constraints
• Decouple planning and development cadences

The post Getting Control of Distressed Projects appeared first on VersionOne Blog.