Something you can try on your next fixed bid project
Depending on your company’s commitment to agile principals you might find yourself on a classic fixed bid project. A while back, at a previous employer, I found myself in just such a position. Usually fixed bid suggests a strict command and control with a Big Upfront Design approach to the project and architecture. Despite these circumstances we wanted to value embracing change over contract negotiations and run the project using agile practices. We presented the scope such that the customer "bought" a fixed number of story points per iteration that they could spend however they chose. With that “guiding principle” we ready to start the project. [Predictably in inception the customer applied all points to all iterations.]
From my experience establishing trust between consulting company and customer is key to be successful in this situation. Once its established, contracts almost don't matter anymore. The interesting part is always, “How can we get the customer there?” We didn’t have the trust we needed early on so we decided to defer any “hard” conversations until we had some trust established. At first we simply added everything that emerged as a new story and put it at the end of the master story list. We didn't stop to discuss the contract at the time - just implemented stories and focused on team health. After a few iterations the product owner started to worry about the stories at the end of the list and when they would be implemented. I reminded him that he could select them at any time and put them into the next iteration. Our delay seemed to have paid off: By the time our Product Owner was asking these questions the team was out of the forming stage and seeing increases in their velocity each iteration. Since we had some success to fall back on, I began to suggest that some of the stories planned for the next iteration were not absolutely necessary for a successful release. Then I suggested that we had some completely new features at the end of the list that might be more valuable than the ones in scope. He wanted to discuss the idea. Now we could begin adaptive planning discussions...
What we tried:
The project manger (me) and the product owner got into a room and discussed the new stories one on one. Because our velocity was increasing so we could afford to add some stories to the next iteration. The Product Owner removed some stories from scope as well. Surprisingly, this lead to a net neutral result.
What we learned:
1) It was good to delay these meetings. By the time we had them our PO was in the mindset that he was working with a great team and was getting good performance for his investment. Had we started to question the value of stories in scope earlier he would have assumed I (the PM) was doing classical scope management. 2) The first meeting was only the two of us. Initially this made it easier to avoid unproductive behaviors - such as the need to save face in front of others. We were able to be rational and take a long term view.
So, how did things turn out?
Over time we (the whole team customer and development team) became more comfortable with this process and were able to have these meetings before each IPM. They continued to lead to a neutral result over all. Therefore, we were able to keep contract issues out of the way of the team. They could focus on creating a great application even under a fixed bid arrangement. After a couple more iterations the project started to run very smoothly. By later iterations the team was hyper-performing and completing 1.5x more story points per iteration than the original assumption. Due to our focus on quality code, our releases generally went well and saw very few bugs in production. By the end of the project the customer was happy and was content with the application - even though they received a very different application they thought they had originally purchased. My company we made our revenue target for the project. Both parties walked away with what they were expecting. I consider this an exceptional win for a fixed bid project.
From my experience establishing trust between consulting company and customer is key to be successful in this situation. Once its established, contracts almost don't matter anymore. The interesting part is always, “How can we get the customer there?” We didn’t have the trust we needed early on so we decided to defer any “hard” conversations until we had some trust established. At first we simply added everything that emerged as a new story and put it at the end of the master story list. We didn't stop to discuss the contract at the time - just implemented stories and focused on team health. After a few iterations the product owner started to worry about the stories at the end of the list and when they would be implemented. I reminded him that he could select them at any time and put them into the next iteration. Our delay seemed to have paid off: By the time our Product Owner was asking these questions the team was out of the forming stage and seeing increases in their velocity each iteration. Since we had some success to fall back on, I began to suggest that some of the stories planned for the next iteration were not absolutely necessary for a successful release. Then I suggested that we had some completely new features at the end of the list that might be more valuable than the ones in scope. He wanted to discuss the idea. Now we could begin adaptive planning discussions...
What we tried:
The project manger (me) and the product owner got into a room and discussed the new stories one on one. Because our velocity was increasing so we could afford to add some stories to the next iteration. The Product Owner removed some stories from scope as well. Surprisingly, this lead to a net neutral result.
What we learned:
1) It was good to delay these meetings. By the time we had them our PO was in the mindset that he was working with a great team and was getting good performance for his investment. Had we started to question the value of stories in scope earlier he would have assumed I (the PM) was doing classical scope management. 2) The first meeting was only the two of us. Initially this made it easier to avoid unproductive behaviors - such as the need to save face in front of others. We were able to be rational and take a long term view.
So, how did things turn out?
Over time we (the whole team customer and development team) became more comfortable with this process and were able to have these meetings before each IPM. They continued to lead to a neutral result over all. Therefore, we were able to keep contract issues out of the way of the team. They could focus on creating a great application even under a fixed bid arrangement. After a couple more iterations the project started to run very smoothly. By later iterations the team was hyper-performing and completing 1.5x more story points per iteration than the original assumption. Due to our focus on quality code, our releases generally went well and saw very few bugs in production. By the end of the project the customer was happy and was content with the application - even though they received a very different application they thought they had originally purchased. My company we made our revenue target for the project. Both parties walked away with what they were expecting. I consider this an exceptional win for a fixed bid project.
