[symfony-users] Re: OT: RAD contract issues
Lukas Kahwe Smith wrote: > Georg Gell wrote: >> Lukas Kahwe Smith schrieb: >>> Georg Gell wrote: Lukas Kahwe Smith schrieb: > Georg Gell wrote: > > Well in order to really leverage the benefits from agile development, > one must really build a trust relationship with the client. Otherwise > you do not benefit from throwing out things not deemed useful during > prototyping etc. All in all the entire fixed price model does not really > apply anymore. Do you really have many clients that pay you per hour just trusting you? >>> Sure, I have some projects that are paid per hour/day. But sure most >>> projects are fixed price. >>> >> Hi, it seems that i have led us even more OT with my answers. Basically >> I would like to know how to make the contract with your clients when you >> are working with a fixed price and RAD, just in case something goes >> wrong. How are you doing it? > > You make the scope small enough that you know you can complete it. The > best would be a few small projects in the beginning to get the client > into how things work and that he can expect to get more than the narrow > scope of the contract defines. > > However even the narrow scope of a RAD project will include quite a lot > compared to a traditional project. And again you will have the > opportunity to deliver more depending on client participation. One more thing, ensure that you define a simple process for changing the project scope. Like defining that client input inside your trac (wiki or ticket) are sufficient in making changes to the scope, when you accept the change via a simple process as well. regards, Lukas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: OT: RAD contract issues
Georg Gell wrote: > Lukas Kahwe Smith schrieb: >> Georg Gell wrote: >>> Lukas Kahwe Smith schrieb: Georg Gell wrote: Well in order to really leverage the benefits from agile development, one must really build a trust relationship with the client. Otherwise you do not benefit from throwing out things not deemed useful during prototyping etc. All in all the entire fixed price model does not really apply anymore. >>> Do you really have many clients that pay you per hour just trusting you? >> Sure, I have some projects that are paid per hour/day. But sure most >> projects are fixed price. >> > > Hi, it seems that i have led us even more OT with my answers. Basically > I would like to know how to make the contract with your clients when you > are working with a fixed price and RAD, just in case something goes > wrong. How are you doing it? You make the scope small enough that you know you can complete it. The best would be a few small projects in the beginning to get the client into how things work and that he can expect to get more than the narrow scope of the contract defines. However even the narrow scope of a RAD project will include quite a lot compared to a traditional project. And again you will have the opportunity to deliver more depending on client participation. regards, Lukas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: OT: RAD contract issues
Lukas Kahwe Smith schrieb: > Georg Gell wrote: >> Lukas Kahwe Smith schrieb: >>> Georg Gell wrote: >>> >>> Well in order to really leverage the benefits from agile development, >>> one must really build a trust relationship with the client. Otherwise >>> you do not benefit from throwing out things not deemed useful during >>> prototyping etc. All in all the entire fixed price model does not really >>> apply anymore. >> Do you really have many clients that pay you per hour just trusting you? > > Sure, I have some projects that are paid per hour/day. But sure most > projects are fixed price. > Hi, it seems that i have led us even more OT with my answers. Basically I would like to know how to make the contract with your clients when you are working with a fixed price and RAD, just in case something goes wrong. How are you doing it? regards Georg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: OT: RAD contract issues
Georg Gell wrote: > Lukas Kahwe Smith schrieb: >> Georg Gell wrote: >> >> Well in order to really leverage the benefits from agile development, >> one must really build a trust relationship with the client. Otherwise >> you do not benefit from throwing out things not deemed useful during >> prototyping etc. All in all the entire fixed price model does not really >> apply anymore. > > Do you really have many clients that pay you per hour just trusting you? Sure, I have some projects that are paid per hour/day. But sure most projects are fixed price. >> Basically you define a budget, you define an initial scope and you keep >> your client in the loop. Its the PM's just to ensure that the must >> have's will always fit in the budget, even as you add new features and >> throw out others. I suggest keeping a wiki that is updated immediately >> as the specs evolve. > > Just wondering how many projects exist that have more budget than just > for the bare must-haves? I should definitely get a dot com bubble > company as a client ;-) Most projects have a few nice to haves. But the key point is that even must haves can change during an agile project. >> One key thing to state in the contract and make very clear from the >> start is that client participation is key to the quality of the results. >> This means that the client has to budget much higher costs on his side, >> since he has to make sure that all the relevant people have sufficient >> amount of time to provide feedback. > > Good point, what are the arguments to make my client want to have more > budget on his side? They are all making overtime already. Yes, due to the short feedback loops and the tight integration of the client they get the feature set of version 3.0 as their 1.0 release. Traditionally the client can only provide real world feedback after a x.0 release. So a 1.0 application never meets real world requirements. This is where agile methods shine. regards, Lukas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: OT: RAD contract issues
Georg Gell a écrit : > I am > working as a project manager in a large company, and I have problems > using RAD there. A nice reading that helped me to understand some of the benefits and limitations of agile project development and management, Getting Real : http://gettingreal.37signals.com/ (Free PDF by the guys behind 37signals and RoR) ++ -- Nicolas Perriaulthttp://www.clever-age.com Clever Age - Conseil en architecture technique GSM: +33 6 60 92 08 67 Tél: +33 1 53 34 66 10 Clever Age vous invite à ses petits-déjeuners http://www.clever-age.com/actualites/petits-dejeuners/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: OT: RAD contract issues
Lukas Kahwe Smith schrieb: > Georg Gell wrote: > > Well in order to really leverage the benefits from agile development, > one must really build a trust relationship with the client. Otherwise > you do not benefit from throwing out things not deemed useful during > prototyping etc. All in all the entire fixed price model does not really > apply anymore. Do you really have many clients that pay you per hour just trusting you? > Basically you define a budget, you define an initial scope and you keep > your client in the loop. Its the PM's just to ensure that the must > have's will always fit in the budget, even as you add new features and > throw out others. I suggest keeping a wiki that is updated immediately > as the specs evolve. Just wondering how many projects exist that have more budget than just for the bare must-haves? I should definitely get a dot com bubble company as a client ;-) > One key thing to state in the contract and make very clear from the > start is that client participation is key to the quality of the results. > This means that the client has to budget much higher costs on his side, > since he has to make sure that all the relevant people have sufficient > amount of time to provide feedback. Good point, what are the arguments to make my client want to have more budget on his side? They are all making overtime already. > As a result the overall turnover for you is much reduced with agile > development. The project is usually shorter, client involvement means > less work for you. On the up side you obviously deliver faster, making > the chances better that your client will rake in nice profits that he > will probably like to reinvest partially into your services. Oh and if > you are not willing to provide the services, others will. So you dont > really have a choice these days. *I* can see it's advantages and *I* am willing to provide this service, but nobody wants it (I must admit they are engineering and production companies, used to have the basic requirements before they start working) regards Georg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
[symfony-users] Re: OT: RAD contract issues
Georg Gell wrote: > Hi everyone, > > this is a little off topic, but I am reading the symfony book atm, it > was mentioned in the book that symfony is very useful for RAD and code > refactoring, as the newer customers often change the requirements. > Technically I am quite used to RAD and I see it's advantages, but I am > working as a project manager in a large company, and I have problems > using RAD there. > The main issue is that if you don't define the exact specifications > before, you cannot give a serious quote on the amount that the project > is going to cost. And if you make it easier for the customer to change > the requirement during the realization, how can you define when the > target is reached? Meaning how can you finish a RAD project in time and > within budget, if you have no defined target, and the client can always > wish for more? > How to you guys/gals cope with this problem? How do you make the > contract, when you are going to use RAD? Is it just that you are so good > and the clients pay so well that you have never thought about it? Well in order to really leverage the benefits from agile development, one must really build a trust relationship with the client. Otherwise you do not benefit from throwing out things not deemed useful during prototyping etc. All in all the entire fixed price model does not really apply anymore. Basically you define a budget, you define an initial scope and you keep your client in the loop. Its the PM's just to ensure that the must have's will always fit in the budget, even as you add new features and throw out others. I suggest keeping a wiki that is updated immediately as the specs evolve. One key thing to state in the contract and make very clear from the start is that client participation is key to the quality of the results. This means that the client has to budget much higher costs on his side, since he has to make sure that all the relevant people have sufficient amount of time to provide feedback. As a result the overall turnover for you is much reduced with agile development. The project is usually shorter, client involvement means less work for you. On the up side you obviously deliver faster, making the chances better that your client will rake in nice profits that he will probably like to reinvest partially into your services. Oh and if you are not willing to provide the services, others will. So you dont really have a choice these days. regards, Lukas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~--~~~~--~~--~--~---
