http://jpnair.wordpress.com Just another WordPress.com weblog Wed, 16 Jan 2008 13:56:06 +0000 http://wordpress.com/ hourly 1 http://jpnair.wordpress.com/2007/12/30/is-agile-suitable-for-fixed-bid-projects/#comment-3 jpnair Wed, 16 Jan 2008 13:56:06 +0000 http://jpnair.wordpress.com/2007/12/30/is-agile-suitable-for-fixed-bid-projects/#comment-3 Poongundran, Appreciate the point raised about scope creep. I am fully with you, in that scope creep will raise its head every once in a while. Here, we need to differentiate between a scope 'change' and scope 'creep'. No matter what methodology we adopt, we have to get the right product in place, in terms of functionality (and then get it to work perfectly). This means that we should provide allowance for scope 'change'... that's something we might not be able to avoid. But scope 'creep' is something that we can avoid, by removing lower priority items of similar size when you are injecting high priority items. So, bottomline, there is no point in fighting against useful scope change. Even if we win legally (based on the contract terms), there is no satisfaction of having delivered the right product/application, end of the day. But we must be careful that the scope 'change' does not translate to scope 'creep'....some lower priority item/s must go. Poongundran,
Appreciate the point raised about scope creep. I am fully with you, in that scope creep will raise its head every once in a while. Here, we need to differentiate between a scope ‘change’ and scope ‘creep’. No matter what methodology we adopt, we have to get the right product in place, in terms of functionality (and then get it to work perfectly). This means that we should provide allowance for scope ‘change’… that’s something we might not be able to avoid. But scope ‘creep’ is something that we can avoid, by removing lower priority items of similar size when you are injecting high priority items.
So, bottomline, there is no point in fighting against useful scope change. Even if we win legally (based on the contract terms), there is no satisfaction of having delivered the right product/application, end of the day. But we must be careful that the scope ‘change’ does not translate to scope ‘creep’….some lower priority item/s must go.

]]> http://jpnair.wordpress.com/2007/12/30/is-agile-suitable-for-fixed-bid-projects/#comment-2 Poongundran Krishnamurthi Thu, 10 Jan 2008 06:31:28 +0000 http://jpnair.wordpress.com/2007/12/30/is-agile-suitable-for-fixed-bid-projects/#comment-2 The detail analysis of Agile Methodology fitting into the fixed bid projects looks good. However, I've my own reservation for the allocation of 15-20% contingency towards the prediction of Change Request on that cycle. The best part of Agile is scope defined, short and sweet (sweat too) execution model. If you assume that there will be some changes in the scope, its understood that the scope is not defined clearly. Also, as there is a room provided to allow the scope creep, it might lead to nazi concentration camp and end up in re-drafting the SOW. Still, the model you proposed is definitely workable provided the scope creep doesn't cross the saturation level. Nice one! The detail analysis of Agile Methodology fitting into the fixed bid projects looks good.
However, I’ve my own reservation for the allocation of 15-20% contingency towards the prediction of Change Request on that cycle.
The best part of Agile is scope defined, short and sweet (sweat too) execution model. If you assume that there will be some changes in the scope, its understood that the scope is not defined clearly. Also, as there is a room provided to allow the scope creep, it might lead to nazi concentration camp and end up in re-drafting the SOW.
Still, the model you proposed is definitely workable provided the scope creep doesn’t cross the saturation level.
Nice one!

]]>