A long-time client thought they had a very straightforward product development challenge ahead of them. They started a project over a year and half ago, expecting to finish in less than a year. The purpose of the project was to incorporate two existing products together to produce a new offering, whose value to the customers would be more than the sum of each component. One of the products to be incorporated is theirs, the other one is from an external partner.
The idea was great. The project implementation, however, was too optimistic. Shortly after the project started, I had a conversation with one of the directors of my client and pointed out the issues they may face if they tried to fast-forward a few basics of product development that involved external partners. He thought the team was on top of the situation and they had it under control.
Just recently, I received a phone call from him. The project had derailed, it was delayed way beyond its target date and the management had started to panic. With that, my involvement in the project started.
A quick observation of the status revealed that the following basics were violated:
- No clear agreement between my client and the external company on the requirements from the external company. The existing agreement is very high level and can be interpreted in different ways. The external company is very accommodating and is willing to work the issues out, which makes the situation better. However, the lack of clear definition is creating extra work on both sides, delaying the project and incurring higher costs – Not a good thing!
- There is no agreement on the verification of each company’s product to ensure the two will work together. Both parties verify as they go but the final verification can only be done at the full system level. This “big bang” approach is causing the teams miss issues until full integration and verification. At this stage, it is more difficult and costly to pinpoint the root cause and fix the issue.
- A definition of “done” was missing. This caused the teams to spin their wheels, continuously adding yet another feature, just because they could. Without a commonly understood definition of project completion, the team was disengaged and internal disagreements emerged.
- The client has an effective product development process, which provides a high level of guidance and empowers the team to make their own decisions. There are control points in place to ensure the quality and effectiveness of decisions. However, the process is taken for granted by the management. Its intent and tools are not well-understood by the team. With too much freedom but without a good understanding of the intent, some decisions led to unnecessary work and friction among the team members.
- A small project team operated on “everybody does everything” principle. While this is fine in a small and high powered team as the one on this project, some clarity in responsibilities and accountabilities was still needed.
I spent my first week on the job to rectify the above five areas. The focus was on the definition of “done,” and clarifying the process and responsibility issues in the team. With those obstacles cleared, the next step was to specify a pragmatic approach to address the requirements and verification issues. Since the project has progressed to the point where everything can be verified at the system level, there is no point in retroactive sub-system verification. With the participation of the team, we specified the next steps in verification to meet the “done” state. This exercise helped the team to focus its efforts and energize to get it done. Next, we identified who was responsible for what and resolved differences of opinions, which mostly reflected personal preferences.
In short, the first week was challenging and very productive. Now, the team sees the light at the end of the tunnel and is motivated to get there. There are other challenges ahead of us to meet the objectives and we will take it one step at a time.
Ferhan Bulca, Ph.D. 