Comments on: Ever-Changing Business Requirements http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html Dealing with software projects in real life Fri, 10 Feb 2012 19:07:34 +0000 hourly 1 http://wordpress.org/?v=3.3 By: Pawel Brodzinski http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1991 Pawel Brodzinski Tue, 27 May 2008 22:19:00 +0000 http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1991 Andreas, to some point you can try to hide your nice agile software development methodology under some heavy old-school technique shown to the customer. But you just won't have the customer playing actively in your agile process. It'll be a bit lame.<br/><br/>By the way, can you tell a bit more how the process were organized? How iterations were planned? Did you manage to gain some attetion from the customer before deploying the whole thing? Andreas, to some point you can try to hide your nice agile software development methodology under some heavy old-school technique shown to the customer. But you just won’t have the customer playing actively in your agile process. It’ll be a bit lame.

By the way, can you tell a bit more how the process were organized? How iterations were planned? Did you manage to gain some attetion from the customer before deploying the whole thing?

]]> By: Pawel Brodzinski http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1990 Pawel Brodzinski Tue, 27 May 2008 22:14:00 +0000 http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1990 Mike, I think your approach is the most reasonable one. Unfortunataly you can't always convince a customer to follow the Pareto principle. Sometimes you just have to do whatever client needs even when you believe it doesn't make much sense. They pay and they expect. Mike, I think your approach is the most reasonable one. Unfortunataly you can’t always convince a customer to follow the Pareto principle. Sometimes you just have to do whatever client needs even when you believe it doesn’t make much sense. They pay and they expect.

]]> By: Andreas http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1989 Andreas Tue, 27 May 2008 08:39:00 +0000 http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1989 i agree, however you can if you want pick and mix, you can manage the strictly software side/development using agile principles and manage the client using a structure method..it works i've tried it before. i agree, however you can if you want pick and mix, you can manage the strictly software side/development using agile principles and manage the client using a structure method..it works i’ve tried it before.

]]> By: Mike Ramm http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1988 Mike Ramm Tue, 20 May 2008 06:20:00 +0000 http://blog.brodzinski.com/2008/05/ever-changing-business-requirements.html#comment-1988 I think I am fond of "Manage it" approach but I would call it "Prioritize and manage". It's funny how well Pareto principle fits in this situation. There are two implications of this principle:<br/>1. 20% of the requirements bring 80% of customer's satisfaction, so focus on them.<br/>2. 20% of the requirements need 80% of your effort, so try to avoid them (e.g. negotiate them with the customer).<br/><br/>Following these rules you can prioritize your requirements. There are "good" ones (cheap and effective) and "bad" ones (expensive and with little importance to the customer). When you focus on the good ones and negotiate with the customer to exclude or postpone the bad ones, your project will be successful. I think I am fond of “Manage it” approach but I would call it “Prioritize and manage”. It’s funny how well Pareto principle fits in this situation. There are two implications of this principle:
1. 20% of the requirements bring 80% of customer’s satisfaction, so focus on them.
2. 20% of the requirements need 80% of your effort, so try to avoid them (e.g. negotiate them with the customer).

Following these rules you can prioritize your requirements. There are “good” ones (cheap and effective) and “bad” ones (expensive and with little importance to the customer). When you focus on the good ones and negotiate with the customer to exclude or postpone the bad ones, your project will be successful.

]]>