We're pitching on the web and digital marketing for the South African division of a Fortune 500 company. The RFP is over 150 pages long and the proposal will no doubt take days to complete.
Almost everything in the RFP points to risk-minimisation, with clauses such as a $50,000 penalty should the launch date for the new website be missed, for example.
Now if this was a normal project, the website would probably only cost about $50,000, but considering all the overhead that we'd have to carry to satisfy their risk aversion (more staff, etc), and also the very stiff penalties that delays could incur, I'm thinking that we'll have to charge a lot more than we normally would.
Does anyone have experience dealing with companies like this?
> We're pitching on the web and digital marketing for the South African > division of a Fortune 500 company. The RFP is over 150 pages long and > the proposal will no doubt take days to complete.
If you're spending time discussing their project, you should be incorporating this into your cost. We almost always charge them to go through a formal proposal process. This is what we call an ITER-ZERO phase, and we charge for this process, because our aim is to provide more value to their project through our discussions with them.
One could argue that a consultancy could take the risk and do it for free, but if you're reviewing their documentation and making any suggestions as to how to improve upon their proposed solutions... then they get to walk away with that for free. You could then argue that you just save your new ideas until you win the contract, but perhaps this is an important selling point for you.
In our case, it's been part of our selling process and because of how busy we've been over the past few years, it's been a good way to filter out potential clients that aren't willing to pay to have someone give them a meaningful analysis of their project proposal. ...and I can speak from experience. There are many companies that will pay you for this process. You just need to ask them to do it.
> Almost everything in the RFP points to risk-minimisation, with clauses > such as a $50,000 penalty should the launch date for the new website > be missed, for example.
I would review this very carefully. Given that they want to minimize the risks, I would have a lawyer review this and propose changes. For example, is their a $50k bonus for delivering it early? This isn't unheard of.
> Now if this was a normal project, the website would probably only cost > about $50,000, but considering all the overhead that we'd have to > carry to satisfy their risk aversion (more staff, etc), and also the > very stiff penalties that delays could incur, I'm thinking that we'll > have to charge a lot more than we normally would.
Without knowing more about their project, I can only offer so much advice. Mainly, try to avoid providing a flat bid on projects. Stick to ballpark estimates and insist on a time and materials contract or a hybrid of short 1-2 week iterations with a cost for each, depending on the deliverables within each iteration.
Anyhow... running late to work.... but wanted to send over some of my thoughts from my experience in these situations.
Cheers,
Robby
-- Robby Russell Founder and Executive Director
PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting
> > We're pitching on the web and digital marketing for the South African > > division of a Fortune 500 company. The RFP is over 150 pages long and > > the proposal will no doubt take days to complete.
> If you're spending time discussing their project, you should be > incorporating this into your cost. We almost always charge them to go > through a formal proposal process. This is what we call an ITER-ZERO > phase, and we charge for this process, because our aim is to provide > more value to their project through our discussions with them.
> One could argue that a consultancy could take the risk and do it for > free, but if you're reviewing their documentation and making any > suggestions as to how to improve upon their proposed solutions... > then they get to walk away with that for free. You could then argue > that you just save your new ideas until you win the contract, but > perhaps this is an important selling point for you.
> In our case, it's been part of our selling process and because of how > busy we've been over the past few years, it's been a good way to > filter out potential clients that aren't willing to pay to have > someone give them a meaningful analysis of their project > proposal. ...and I can speak from experience. There are many > companies that will pay you for this process. You just need to ask > them to do it.
> > Almost everything in the RFP points to risk-minimisation, with clauses > > such as a $50,000 penalty should the launch date for the new website > > be missed, for example.
> I would review this very carefully. Given that they want to minimize > the risks, I would have a lawyer review this and propose changes. For > example, is their a $50k bonus for delivering it early? This isn't > unheard of.
Agreed. The contract should be inventively beneficial for both parties.
> > Now if this was a normal project, the website would probably only cost > > about $50,000, but considering all the overhead that we'd have to > > carry to satisfy their risk aversion (more staff, etc), and also the > > very stiff penalties that delays could incur, I'm thinking that we'll > > have to charge a lot more than we normally would.
> Without knowing more about their project, I can only offer so much > advice. Mainly, try to avoid providing a flat bid on projects. Stick > to ballpark estimates and insist on a time and materials contract or > a hybrid of short 1-2 week iterations with a cost for each, depending > on the deliverables within each iteration.
I agree to avoiding flat bidding. It is never accurate enough bidding a project up front. We have it written into our contract we get bonuses for delivering features early and make less for delivering features late on an iteration by iteration basis. The client has embraced this method and it creates a tension and motivation for every iteration.
Now big business can't fly by the seat of its pants on an iteration by iteration basis, so we give epoch estimates. These are blocks of related features and about how many iterations they will take. The client has to understand they are not that accurate, due to the nature of an agile process, the requirements WILL change. Building up something from the ground up, you learn more than top down. So, we will re-estimate upon client request. There defiantly needs to be some level of trust between the client and contractor to make this work though. You can't add every scenario into the contract.
Anyhow... running late to work.... but wanted to send over some of my
Unfortunately this is one of those where its explicitly mentioned that there's no fee payable for the proposal, and if we don't like it, tough. The detail of the RFP is insane - we are expected to provide costings, staffing, etc, etc, etc for the next 3 years (the duration of the contract). I feel like I'm quoting on redesigning their central database, where the world would end for 100,000 employees if we got it wrong.
Half of me is saying "forget it, its too much effort, and we won't get it because we're not corporate enough", and the other half is saying "do it, you might learn something!"
Cheers Nick
On Jun 15, 3:31 pm, Robby Russell <r...@planetargon.com> wrote:
> > We're pitching on the web and digital marketing for the South African > > division of a Fortune 500 company. The RFP is over 150 pages long and > > the proposal will no doubt take days to complete.
> If you're spending time discussing their project, you should be > incorporating this into your cost. We almost always charge them to go > through a formal proposal process. This is what we call an ITER-ZERO > phase, and we charge for this process, because our aim is to provide > more value to their project through our discussions with them.
> One could argue that a consultancy could take the risk and do it for > free, but if you're reviewing their documentation and making any > suggestions as to how to improve upon their proposed solutions... > then they get to walk away with that for free. You could then argue > that you just save your new ideas until you win the contract, but > perhaps this is an important selling point for you.
> In our case, it's been part of our selling process and because of how > busy we've been over the past few years, it's been a good way to > filter out potential clients that aren't willing to pay to have > someone give them a meaningful analysis of their project > proposal. ...and I can speak from experience. There are many > companies that will pay you for this process. You just need to ask > them to do it.
> > Almost everything in the RFP points to risk-minimisation, with clauses > > such as a $50,000 penalty should the launch date for the new website > > be missed, for example.
> I would review this very carefully. Given that they want to minimize > the risks, I would have a lawyer review this and propose changes. For > example, is their a $50k bonus for delivering it early? This isn't > unheard of.
> > Now if this was a normal project, the website would probably only cost > > about $50,000, but considering all the overhead that we'd have to > > carry to satisfy their risk aversion (more staff, etc), and also the > > very stiff penalties that delays could incur, I'm thinking that we'll > > have to charge a lot more than we normally would.
> Without knowing more about their project, I can only offer so much > advice. Mainly, try to avoid providing a flat bid on projects. Stick > to ballpark estimates and insist on a time and materials contract or > a hybrid of short 1-2 week iterations with a cost for each, depending > on the deliverables within each iteration.
> Anyhow... running late to work.... but wanted to send over some of my > thoughts from my experience in these situations.
> Cheers,
> Robby
> -- > Robby Russell > Founder and Executive Director
> Half of me is saying "forget it, its too much effort, and we won't get > it because we're not corporate enough", and the other half is saying > "do it, you might learn something!"
Nick,
At ADS we normally stay away from RFP's as the prospect can take whatever ideas you give them and use them with someone else. Responding to RFP's take a LOT of time and effort which, unless you can recover the cost, might be lost. I know some companies have template responses that they can use which makes the process simpler, however for us smaller folks, it is just a lot of grind work. Good luck.
> Unfortunately this is one of those where its explicitly mentioned that > there's no fee payable for the proposal, and if we don't like it, > tough. The detail of the RFP is insane - we are expected to provide > costings, staffing, etc, etc, etc for the next 3 years (the duration > of the contract). I feel like I'm quoting on redesigning their central > database, where the world would end for 100,000 employees if we got it > wrong.
> Half of me is saying "forget it, its too much effort, and we won't get > it because we're not corporate enough", and the other half is saying > "do it, you might learn something!"
We've turned away some _really_ large projects because of concerns like this. Sometimes it's okay to step back and evaluate the whole thing. Do you really want to be working on the same project for three years? How does the rest of your team feel about it?
Good luck with your decision making process!
Robby
-- Robby Russell Founder and Executive Director
PLANET ARGON, LLC Ruby on Rails Development, Consulting & Hosting
Have you spoken with the person in charge of the tendering process? I'm on a mailing list for local public sector notifications, and almost every alert I see has clauses for delivery guarantees, company history, professional indemnity etc. Most of them are boiler plate entries that can be negotiated down/away once you have established a relationship with a real person handling the project.
Sound advice from Robbie by the way - think about what you want to be doing in 2-3 years time and ask yourself if this project fits into those plans.
Also, if they're not willing to pay for your proposal (yet they have $50K penalty clauses) it makes the whole scenario smell 'off' to me - be careful!
k
On Jun 15, 5:13 pm, Robby Russell <r...@planetargon.com> wrote:
> > Unfortunately this is one of those where its explicitly mentioned that > > there's no fee payable for the proposal, and if we don't like it, > > tough. The detail of the RFP is insane - we are expected to provide > > costings, staffing, etc, etc, etc for the next 3 years (the duration > > of the contract). I feel like I'm quoting on redesigning their central > > database, where the world would end for 100,000 employees if we got it > > wrong.
> > Half of me is saying "forget it, its too much effort, and we won't get > > it because we're not corporate enough", and the other half is saying > > "do it, you might learn something!"
> We've turned away some _really_ large projects because of concerns > like this. Sometimes it's okay to step back and evaluate the whole > thing. Do you really want to be working on the same project for three > years? How does the rest of your team feel about it?
> Good luck with your decision making process!
> Robby
> -- > Robby Russell > Founder and Executive Director
I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
I have graduated from university on 2006, and done my military service this year. Now I'll start working on a IT company in Turkey which mainly focuses on mobile applications.
Even though I am not a software expert & engineer, I really impressed by rails last year. Since that time, I am trying to create my application.
When I were a student, I always learned that I should draw ER diagrams, Data Flow Diagrams, UML diagrams etc. to be certain that the project is understood correctly by everybody in the same way. And it is always said that these documentation steps are very very critical for the success and sustainability of the project.
However, even though I've read at least 2 rails books, I never see an ER diagram or UML diagram. So the question is, in the business life, do you use these steps? Or these steps are not usable in practice? How do you design your application?
Any readings or books for this stage of rails development will really help me.
I don't have any experience working on this type of project, but I do have experience in huge organizations. And my advice would be to very very careful about what responsibilities you take on. When big projects fail, it's often due to corporate politics, or just a complete lack of understanding of the business goals or actual needs being met by the project.
As a developer it will be your job to cut through the bullshit and get what you need. But if the project is not well-conceived, or there's any kind of internal conflict, you may well become the scapegoat for the whole thing blowing up.
The first order of business is to get some sense of the real people involved. If you don't feel comfortable with them then get out now! It's understandable that they would want risk mitigation on their end, but also consider risk mitigation from your end. If they think a 150- page RFP is enough for you to deliver a successful product, then that's a big red flag to me.
On Jun 14, 10:59 pm, Nick Coyne <nic.co...@gmail.com> wrote:
> We're pitching on the web and digital marketing for the South African > division of a Fortune 500 company. The RFP is over 150 pages long and > the proposal will no doubt take days to complete.
> Almost everything in the RFP points to risk-minimisation, with clauses > such as a $50,000 penalty should the launch date for the new website > be missed, for example.
> Now if this was a normal project, the website would probably only cost > about $50,000, but considering all the overhead that we'd have to > carry to satisfy their risk aversion (more staff, etc), and also the > very stiff penalties that delays could incur, I'm thinking that we'll > have to charge a lot more than we normally would.
> Does anyone have experience dealing with companies like this?
I've found the real value of formal diagrams to be in creating them -- like a mathematician writing out a proof, it really forces you to think through the design. It's also an OK way to try to get a grip on source code that I'm not familiar with.
As a tool for business communication, though, I've not encountered one which I particularly like. Even moderately complicated designs end up being either 1) a mess of tangles, and/or 2) a spray of disparate clumps. There is just enough technical information in the diagram to require some skill to read it (thereby limiting the audience and creating potential confusion), yet not enough to catch implementation details (thereby missing out on the biggest value of being technical). For business communication, I prefer to use tools like FIT (http://fit.c2.com/) and lots of demonstrations.
Most of my design -- particularly with a framework with "natural paths" as strong as Rails -- is sketched out with arbitrary boxes and arrows. I've learned that if I put too much more effort into it, I'm going to over-architect the solution, and I'll actually end up being less productive. Worse, sometimes I'll put so much effort into the boxes and arrows that I'll forget that my contract is with the customer, not with the boxes and arrows. Once I have the few sketched out boxes and arrows, I let the design emerge from the customer requirements and the practice of writing unit tests: I build things as I need new functionality or need to decouple code for testing.
Robert Fischer IT Firefighter Smokejumper Consulting
> I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
> I have graduated from university on 2006, and done my military service > this year. Now I'll start working on a IT company in Turkey which mainly > focuses on mobile applications.
> Even though I am not a software expert & engineer, I really impressed by > rails last year. Since that time, I am trying to create my application.
> When I were a student, I always learned that I should draw ER diagrams, > Data Flow Diagrams, UML diagrams etc. to be certain that the project is > understood correctly by everybody in the same way. And it is always said > that these documentation steps are very very critical for the success > and sustainability of the project.
> However, even though I've read at least 2 rails books, I never see an ER > diagram or UML diagram. So the question is, in the business life, do you > use these steps? Or these steps are not usable in practice? How do you > design your application?
> Any readings or books for this stage of rails development will really > help me.
+1 on this, particularly if there is already a lot of attention being paid to how to manage the failure of the project. It's not uncommon for contractors to be brought in because the project has become anathema to the employees, or even because the project is understood to be doomed but is still unable to be stopped. In this case, you may be brought in to take the fall.
This isn't always the case: in fact, my experience is that it's pretty rare -- but it happens, so it's best to be warned.
Robert Fischer IT Firefighter Smokejumper Consulting
dasil003 wrote: > I don't have any experience working on this type of project, but I do > have experience in huge organizations. And my advice would be to very > very careful about what responsibilities you take on. When big > projects fail, it's often due to corporate politics, or just a > complete lack of understanding of the business goals or actual needs > being met by the project.
> As a developer it will be your job to cut through the bullshit and get > what you need. But if the project is not well-conceived, or there's > any kind of internal conflict, you may well become the scapegoat for > the whole thing blowing up.
> The first order of business is to get some sense of the real people > involved. If you don't feel comfortable with them then get out now! > It's understandable that they would want risk mitigation on their end, > but also consider risk mitigation from your end. If they think a 150- > page RFP is enough for you to deliver a successful product, then > that's a big red flag to me.
> On Jun 14, 10:59 pm, Nick Coyne <nic.co...@gmail.com> wrote:
>> We're pitching on the web and digital marketing for the South African >> division of a Fortune 500 company. The RFP is over 150 pages long and >> the proposal will no doubt take days to complete.
>> Almost everything in the RFP points to risk-minimisation, with clauses >> such as a $50,000 penalty should the launch date for the new website >> be missed, for example.
>> Now if this was a normal project, the website would probably only cost >> about $50,000, but considering all the overhead that we'd have to >> carry to satisfy their risk aversion (more staff, etc), and also the >> very stiff penalties that delays could incur, I'm thinking that we'll >> have to charge a lot more than we normally would.
>> Does anyone have experience dealing with companies like this?
On 6/15/07, Nick Coyne <nic.co...@gmail.com> wrote:
> Thanks for the suggestions.
> Unfortunately this is one of those where its explicitly mentioned that > there's no fee payable for the proposal, and if we don't like it, > tough. The detail of the RFP is insane - we are expected to provide > costings, staffing, etc, etc, etc for the next 3 years (the duration > of the contract). I feel like I'm quoting on redesigning their central > database, where the world would end for 100,000 employees if we got it > wrong.
Are you staffed for a project like this?
Half of me is saying "forget it, its too much effort, and we won't get
> it because we're not corporate enough", and the other half is saying > "do it, you might learn something!"
One of the most important things I've learned is to get a feel for clients and projects, and turn down the ones that give me a bad vibe. This is hard to do early on, and we took a few projects for bad clients. They were good learning experiences, but also pretty painful.
I get a bad feeling from what I've heard so far about this project. Sounds like the client wants someone they can abuse. It also sounds like they have deep pockets. If you want to try the project, and you have really skilled staff (or can staff up), I would ask for a lot of money - like US$400,000 for the initial build cycle and a few hundred thousand a year after that. After all, they want to take $50k back if the project is late, and lateness is almost a given with a difficult client.
Pick a price that gives you a ton of padding if you get the project. And if you don't get it, you're probably better off. :)
> On Jun 15, 3:31 pm, Robby Russell <r...@planetargon.com> wrote: > > On Jun 14, 2007, at 9:59 PM, Nick Coyne wrote:
> > > We're pitching on the web and digital marketing for the South African > > > division of a Fortune 500 company. The RFP is over 150 pages long and > > > the proposal will no doubt take days to complete.
> > If you're spending time discussing their project, you should be > > incorporating this into your cost. We almost always charge them to go > > through a formal proposal process. This is what we call an ITER-ZERO > > phase, and we charge for this process, because our aim is to provide > > more value to their project through our discussions with them.
> > One could argue that a consultancy could take the risk and do it for > > free, but if you're reviewing their documentation and making any > > suggestions as to how to improve upon their proposed solutions... > > then they get to walk away with that for free. You could then argue > > that you just save your new ideas until you win the contract, but > > perhaps this is an important selling point for you.
> > In our case, it's been part of our selling process and because of how > > busy we've been over the past few years, it's been a good way to > > filter out potential clients that aren't willing to pay to have > > someone give them a meaningful analysis of their project > > proposal. ...and I can speak from experience. There are many > > companies that will pay you for this process. You just need to ask > > them to do it.
> > > Almost everything in the RFP points to risk-minimisation, with clauses > > > such as a $50,000 penalty should the launch date for the new website > > > be missed, for example.
> > I would review this very carefully. Given that they want to minimize > > the risks, I would have a lawyer review this and propose changes. For > > example, is their a $50k bonus for delivering it early? This isn't > > unheard of.
> > > Now if this was a normal project, the website would probably only cost > > > about $50,000, but considering all the overhead that we'd have to > > > carry to satisfy their risk aversion (more staff, etc), and also the > > > very stiff penalties that delays could incur, I'm thinking that we'll > > > have to charge a lot more than we normally would.
> > Without knowing more about their project, I can only offer so much > > advice. Mainly, try to avoid providing a flat bid on projects. Stick > > to ballpark estimates and insist on a time and materials contract or > > a hybrid of short 1-2 week iterations with a cost for each, depending > > on the deliverables within each iteration.
> > Anyhow... running late to work.... but wanted to send over some of my > > thoughts from my experience in these situations.
> > Cheers,
> > Robby
> > -- > > Robby Russell > > Founder and Executive Director
As Robert hinted at, Rails developers tend to shy away from UML and the like. Do some research on Agile development and you'll get an idea of how many Rails teams like to operate. Agile and UML don't necessarily have to conflict, but in practice, they often represent really different philosophies.
(Of course, there are plenty of Rails coders out there who think they're being Agile by not managing their projects at all. I probably used to fall into that camp. But that's another story.)
Cheers, Jon
On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
> I've found the real value of formal diagrams to be in creating them -- > like a mathematician writing out a proof, it really forces you to think > through the design. It's also an OK way to try to get a grip on source > code that I'm not familiar with.
> As a tool for business communication, though, I've not encountered one > which I particularly like. Even moderately complicated designs end up > being either 1) a mess of tangles, and/or 2) a spray of disparate > clumps. There is just enough technical information in the diagram to > require some skill to read it (thereby limiting the audience and > creating potential confusion), yet not enough to catch implementation > details (thereby missing out on the biggest value of being technical). > For business communication, I prefer to use tools like FIT > (http://fit.c2.com/) and lots of demonstrations.
> Most of my design -- particularly with a framework with "natural paths" > as strong as Rails -- is sketched out with arbitrary boxes and arrows. > I've learned that if I put too much more effort into it, I'm going to > over-architect the solution, and I'll actually end up being less > productive. Worse, sometimes I'll put so much effort into the boxes and > arrows that I'll forget that my contract is with the customer, not with > the boxes and arrows. Once I have the few sketched out boxes and > arrows, I let the design emerge from the customer requirements and the > practice of writing unit tests: I build things as I need new > functionality or need to decouple code for testing.
> Robert Fischer > IT Firefighter > Smokejumper Consulting
> Mustafa Ekim wrote: > > Hey everybody,
> > I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
> > I have graduated from university on 2006, and done my military service > > this year. Now I'll start working on a IT company in Turkey which mainly > > focuses on mobile applications.
> > Even though I am not a software expert & engineer, I really impressed by > > rails last year. Since that time, I am trying to create my application.
> > When I were a student, I always learned that I should draw ER diagrams, > > Data Flow Diagrams, UML diagrams etc. to be certain that the project is > > understood correctly by everybody in the same way. And it is always said > > that these documentation steps are very very critical for the success > > and sustainability of the project.
> > However, even though I've read at least 2 rails books, I never see an ER > > diagram or UML diagram. So the question is, in the business life, do you > > use these steps? Or these steps are not usable in practice? How do you > > design your application?
> > Any readings or books for this stage of rails development will really > > help me.
On Tue, 2007-06-19 at 11:39 -0500, Jon Dahl wrote: > As Robert hinted at, Rails developers tend to shy away from UML and > the like. Do some research on Agile development and you'll get an idea > of how many Rails teams like to operate. Agile and UML don't > necessarily have to conflict, but in practice, they often represent > really different philosophies.
> (Of course, there are plenty of Rails coders out there who think > they're being Agile by not managing their projects at all. I probably > used to fall into that camp. But that's another story.)
> Cheers, > Jon
> On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
> I've found the real value of formal diagrams to be in creating > them -- > like a mathematician writing out a proof, it really forces you > to think > through the design. It's also an OK way to try to get a grip > on source > code that I'm not familiar with.
> As a tool for business communication, though, I've not > encountered one > which I particularly like. Even moderately complicated > designs end up > being either 1) a mess of tangles, and/or 2) a spray of > disparate > clumps. There is just enough technical information in the > diagram to > require some skill to read it (thereby limiting the audience > and > creating potential confusion), yet not enough to catch > implementation > details (thereby missing out on the biggest value of being > technical). > For business communication, I prefer to use tools like FIT > (http://fit.c2.com/) and lots of demonstrations.
> Most of my design -- particularly with a framework with > "natural paths" > as strong as Rails -- is sketched out with arbitrary boxes and > arrows. > I've learned that if I put too much more effort into it, I'm > going to > over-architect the solution, and I'll actually end up being > less > productive. Worse, sometimes I'll put so much effort into the > boxes and > arrows that I'll forget that my contract is with the customer, > not with > the boxes and arrows. Once I have the few sketched out boxes > and > arrows, I let the design emerge from the customer requirements > and the > practice of writing unit tests: I build things as I need new > functionality or need to decouple code for testing.
> Robert Fischer > IT Firefighter > Smokejumper Consulting
> Mustafa Ekim wrote: > > Hey everybody,
> > I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
> > I have graduated from university on 2006, and done my > military service > > this year. Now I'll start working on a IT company in Turkey > which mainly > > focuses on mobile applications.
> > Even though I am not a software expert & engineer, I really > impressed by > > rails last year. Since that time, I am trying to create my > application.
> > When I were a student, I always learned that I should draw > ER diagrams, > > Data Flow Diagrams, UML diagrams etc. to be certain that the > project is > > understood correctly by everybody in the same way. And it is > always said > > that these documentation steps are very very critical for > the success > > and sustainability of the project.
> > However, even though I've read at least 2 rails books, I > never see an ER > > diagram or UML diagram. So the question is, in the business > life, do you > > use these steps? Or these steps are not usable in practice? > How do you > > design your application?
> > Any readings or books for this stage of rails development > will really > > help me.
> So, any recommendation about books about Agile development, or XP > programming or extreme project management ?
> I've read about agile development philosophy and now I feel better. > Thanks Jon.
> On Tue, 2007-06-19 at 11:39 -0500, Jon Dahl wrote: > > As Robert hinted at, Rails developers tend to shy away from UML and > > the like. Do some research on Agile development and you'll get an idea > > of how many Rails teams like to operate. Agile and UML don't > > necessarily have to conflict, but in practice, they often represent > > really different philosophies.
> > (Of course, there are plenty of Rails coders out there who think > > they're being Agile by not managing their projects at all. I probably > > used to fall into that camp. But that's another story.)
> > Cheers, > > Jon
> > On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
> > I've found the real value of formal diagrams to be in creating > > them -- > > like a mathematician writing out a proof, it really forces you > > to think > > through the design. It's also an OK way to try to get a grip > > on source > > code that I'm not familiar with.
> > As a tool for business communication, though, I've not > > encountered one > > which I particularly like. Even moderately complicated > > designs end up > > being either 1) a mess of tangles, and/or 2) a spray of > > disparate > > clumps. There is just enough technical information in the > > diagram to > > require some skill to read it (thereby limiting the audience > > and > > creating potential confusion), yet not enough to catch > > implementation > > details (thereby missing out on the biggest value of being > > technical). > > For business communication, I prefer to use tools like FIT > > (http://fit.c2.com/) and lots of demonstrations.
> > Most of my design -- particularly with a framework with > > "natural paths" > > as strong as Rails -- is sketched out with arbitrary boxes and > > arrows. > > I've learned that if I put too much more effort into it, I'm > > going to > > over-architect the solution, and I'll actually end up being > > less > > productive. Worse, sometimes I'll put so much effort into the > > boxes and > > arrows that I'll forget that my contract is with the customer, > > not with > > the boxes and arrows. Once I have the few sketched out boxes > > and > > arrows, I let the design emerge from the customer requirements > > and the > > practice of writing unit tests: I build things as I need new > > functionality or need to decouple code for testing.
> > Robert Fischer > > IT Firefighter > > Smokejumper Consulting
> > Mustafa Ekim wrote: > > > Hey everybody,
> > > I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
> > > I have graduated from university on 2006, and done my > > military service > > > this year. Now I'll start working on a IT company in Turkey > > which mainly > > > focuses on mobile applications.
> > > Even though I am not a software expert & engineer, I really > > impressed by > > > rails last year. Since that time, I am trying to create my > > application.
> > > When I were a student, I always learned that I should draw > > ER diagrams, > > > Data Flow Diagrams, UML diagrams etc. to be certain that the > > project is > > > understood correctly by everybody in the same way. And it is > > always said > > > that these documentation steps are very very critical for > > the success > > > and sustainability of the project.
> > > However, even though I've read at least 2 rails books, I > > never see an ER > > > diagram or UML diagram. So the question is, in the business > > life, do you > > > use these steps? Or these steps are not usable in practice? > > How do you > > > design your application?
> > > Any readings or books for this stage of rails development > > will really > > > help me.
ERD's are almost mandatory for medium to large scale data models. As soon as you get beyond say 10 tables and a single developer (no hard and fast rule), it's like trying to navigate without a map.
The reason you may not have heard of them is most examples and talks are about simple systems, you're unlikely to see the inner workings of some enterprises's system. Eg the Agile Rails book just models a very simple Order - OrderLine - Product relationship.
Conversely one of the apps I'm working on has 116 models at current count. At one company we had an ERD that could wallpaper an entire wall 3-4m wide... typically a developer would know their specific area inside out but would refer to the diagram to see other areas of the system.
It's a good habit to get in, modelling ERD's. UML's I find less so, as using Rails/ActiveRecord your UML diagram would look very similar to your ERD, except you have the additional methods exposed within your models.
Just follow your nose, with time and experience you'll figure out the best approach that works for you..
> As Robert hinted at, Rails developers tend to shy away from UML and the > like. Do some research on Agile development and you'll get an idea of how > many Rails teams like to operate. Agile and UML don't necessarily have to > conflict, but in practice, they often represent really different > philosophies.
> (Of course, there are plenty of Rails coders out there who think they're > being Agile by not managing their projects at all. I probably used to fall > into that camp. But that's another story.)
> Cheers, > Jon
> On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
> > I've found the real value of formal diagrams to be in creating them -- > > like a mathematician writing out a proof, it really forces you to think > > through the design. It's also an OK way to try to get a grip on source > > code that I'm not familiar with.
> > As a tool for business communication, though, I've not encountered one > > which I particularly like. Even moderately complicated designs end up > > being either 1) a mess of tangles, and/or 2) a spray of disparate > > clumps. There is just enough technical information in the diagram to > > require some skill to read it (thereby limiting the audience and > > creating potential confusion), yet not enough to catch implementation > > details (thereby missing out on the biggest value of being technical). > > For business communication, I prefer to use tools like FIT > > (http://fit.c2.com/) and lots of demonstrations.
> > Most of my design -- particularly with a framework with "natural paths" > > as strong as Rails -- is sketched out with arbitrary boxes and arrows. > > I've learned that if I put too much more effort into it, I'm going to > > over-architect the solution, and I'll actually end up being less > > productive. Worse, sometimes I'll put so much effort into the boxes and > > arrows that I'll forget that my contract is with the customer, not with > > the boxes and arrows. Once I have the few sketched out boxes and > > arrows, I let the design emerge from the customer requirements and the > > practice of writing unit tests: I build things as I need new > > functionality or need to decouple code for testing.
> > Robert Fischer > > IT Firefighter > > Smokejumper Consulting
> > Mustafa Ekim wrote: > > > Hey everybody,
> > > I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
> > > I have graduated from university on 2006, and done my military service > > > this year. Now I'll start working on a IT company in Turkey which mainly > > > focuses on mobile applications.
> > > Even though I am not a software expert & engineer, I really impressed by > > > rails last year. Since that time, I am trying to create my application.
> > > When I were a student, I always learned that I should draw ER diagrams, > > > Data Flow Diagrams, UML diagrams etc. to be certain that the project is > > > understood correctly by everybody in the same way. And it is always said > > > that these documentation steps are very very critical for the success > > > and sustainability of the project.
> > > However, even though I've read at least 2 rails books, I never see an ER > > > diagram or UML diagram. So the question is, in the business life, do you > > > use these steps? Or these steps are not usable in practice? How do you > > > design your application?
> > > Any readings or books for this stage of rails development will really > > > help me.
I haven't heard of ERDs before. Do you have a good resource for learning about them? Are they easy to be automatically generated? What does "ERD" stand for?
Robert Fischer IT Firefighter Smokejumper Consulting
> ERD's are almost mandatory for medium to large scale data models. As > soon as you get beyond say 10 tables and a single developer (no hard > and fast rule), it's like trying to navigate without a map.
> The reason you may not have heard of them is most examples and talks > are about simple systems, you're unlikely to see the inner workings of > some enterprises's system. Eg the Agile Rails book just models a very > simple Order - OrderLine - Product relationship.
> Conversely one of the apps I'm working on has 116 models at current > count. At one company we had an ERD that could wallpaper an entire > wall 3-4m wide... typically a developer would know their specific area > inside out but would refer to the diagram to see other areas of the > system.
> It's a good habit to get in, modelling ERD's. UML's I find less so, as > using Rails/ActiveRecord your UML diagram would look very similar to > your ERD, except you have the additional methods exposed within your > models.
> Just follow your nose, with time and experience you'll figure out the > best approach that works for you..
> On Jun 19, 12:39 pm, "Jon Dahl" <jond...@gmail.com> wrote:
>> As Robert hinted at, Rails developers tend to shy away from UML and the >> like. Do some research on Agile development and you'll get an idea of how >> many Rails teams like to operate. Agile and UML don't necessarily have to >> conflict, but in practice, they often represent really different >> philosophies.
>> (Of course, there are plenty of Rails coders out there who think they're >> being Agile by not managing their projects at all. I probably used to fall >> into that camp. But that's another story.)
>> Cheers, >> Jon
>> On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
>>> I've found the real value of formal diagrams to be in creating them -- >>> like a mathematician writing out a proof, it really forces you to think >>> through the design. It's also an OK way to try to get a grip on source >>> code that I'm not familiar with.
>>> As a tool for business communication, though, I've not encountered one >>> which I particularly like. Even moderately complicated designs end up >>> being either 1) a mess of tangles, and/or 2) a spray of disparate >>> clumps. There is just enough technical information in the diagram to >>> require some skill to read it (thereby limiting the audience and >>> creating potential confusion), yet not enough to catch implementation >>> details (thereby missing out on the biggest value of being technical). >>> For business communication, I prefer to use tools like FIT >>> (http://fit.c2.com/) and lots of demonstrations.
>>> Most of my design -- particularly with a framework with "natural paths" >>> as strong as Rails -- is sketched out with arbitrary boxes and arrows. >>> I've learned that if I put too much more effort into it, I'm going to >>> over-architect the solution, and I'll actually end up being less >>> productive. Worse, sometimes I'll put so much effort into the boxes and >>> arrows that I'll forget that my contract is with the customer, not with >>> the boxes and arrows. Once I have the few sketched out boxes and >>> arrows, I let the design emerge from the customer requirements and the >>> practice of writing unit tests: I build things as I need new >>> functionality or need to decouple code for testing.
>>> Robert Fischer >>> IT Firefighter >>> Smokejumper Consulting
>>> Mustafa Ekim wrote:
>>>> Hey everybody,
>>>> I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
>>>> I have graduated from university on 2006, and done my military service >>>> this year. Now I'll start working on a IT company in Turkey which mainly >>>> focuses on mobile applications.
>>>> Even though I am not a software expert & engineer, I really impressed by >>>> rails last year. Since that time, I am trying to create my application.
>>>> When I were a student, I always learned that I should draw ER diagrams, >>>> Data Flow Diagrams, UML diagrams etc. to be certain that the project is >>>> understood correctly by everybody in the same way. And it is always said >>>> that these documentation steps are very very critical for the success >>>> and sustainability of the project.
>>>> However, even though I've read at least 2 rails books, I never see an ER >>>> diagram or UML diagram. So the question is, in the business life, do you >>>> use these steps? Or these steps are not usable in practice? How do you >>>> design your application?
>>>> Any readings or books for this stage of rails development will really >>>> help me.
> I haven't heard of ERDs before. Do you have a good resource for > learning about them? Are they easy to be automatically generated? > What > does "ERD" stand for?
> Robert Fischer > IT Firefighter > Smokejumper Consulting
> Rowan Hick wrote: >> Mustafa,
>> ERD's are almost mandatory for medium to large scale data models. As >> soon as you get beyond say 10 tables and a single developer (no hard >> and fast rule), it's like trying to navigate without a map.
>> The reason you may not have heard of them is most examples and talks >> are about simple systems, you're unlikely to see the inner >> workings of >> some enterprises's system. Eg the Agile Rails book just models a very >> simple Order - OrderLine - Product relationship.
>> Conversely one of the apps I'm working on has 116 models at current >> count. At one company we had an ERD that could wallpaper an entire >> wall 3-4m wide... typically a developer would know their specific >> area >> inside out but would refer to the diagram to see other areas of the >> system.
>> It's a good habit to get in, modelling ERD's. UML's I find less >> so, as >> using Rails/ActiveRecord your UML diagram would look very similar to >> your ERD, except you have the additional methods exposed within your >> models.
>> Just follow your nose, with time and experience you'll figure out the >> best approach that works for you..
>> On Jun 19, 12:39 pm, "Jon Dahl" <jond...@gmail.com> wrote:
>>> As Robert hinted at, Rails developers tend to shy away from UML >>> and the >>> like. Do some research on Agile development and you'll get an >>> idea of how >>> many Rails teams like to operate. Agile and UML don't necessarily >>> have to >>> conflict, but in practice, they often represent really different >>> philosophies.
>>> (Of course, there are plenty of Rails coders out there who think >>> they're >>> being Agile by not managing their projects at all. I probably >>> used to fall >>> into that camp. But that's another story.)
>>> Cheers, >>> Jon
>>> On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
>>>> I've found the real value of formal diagrams to be in creating >>>> them -- >>>> like a mathematician writing out a proof, it really forces you >>>> to think >>>> through the design. It's also an OK way to try to get a grip on >>>> source >>>> code that I'm not familiar with.
>>>> As a tool for business communication, though, I've not >>>> encountered one >>>> which I particularly like. Even moderately complicated designs >>>> end up >>>> being either 1) a mess of tangles, and/or 2) a spray of disparate >>>> clumps. There is just enough technical information in the >>>> diagram to >>>> require some skill to read it (thereby limiting the audience and >>>> creating potential confusion), yet not enough to catch >>>> implementation >>>> details (thereby missing out on the biggest value of being >>>> technical). >>>> For business communication, I prefer to use tools like FIT >>>> (http://fit.c2.com/) and lots of demonstrations.
>>>> Most of my design -- particularly with a framework with "natural >>>> paths" >>>> as strong as Rails -- is sketched out with arbitrary boxes and >>>> arrows. >>>> I've learned that if I put too much more effort into it, I'm >>>> going to >>>> over-architect the solution, and I'll actually end up being less >>>> productive. Worse, sometimes I'll put so much effort into the >>>> boxes and >>>> arrows that I'll forget that my contract is with the customer, >>>> not with >>>> the boxes and arrows. Once I have the few sketched out boxes and >>>> arrows, I let the design emerge from the customer requirements >>>> and the >>>> practice of writing unit tests: I build things as I need new >>>> functionality or need to decouple code for testing.
>>>> Robert Fischer >>>> IT Firefighter >>>> Smokejumper Consulting
>>>> Mustafa Ekim wrote:
>>>>> Hey everybody,
>>>>> I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
>>>>> I have graduated from university on 2006, and done my military >>>>> service >>>>> this year. Now I'll start working on a IT company in Turkey >>>>> which mainly >>>>> focuses on mobile applications.
>>>>> Even though I am not a software expert & engineer, I really >>>>> impressed by >>>>> rails last year. Since that time, I am trying to create my >>>>> application.
>>>>> When I were a student, I always learned that I should draw ER >>>>> diagrams, >>>>> Data Flow Diagrams, UML diagrams etc. to be certain that the >>>>> project is >>>>> understood correctly by everybody in the same way. And it is >>>>> always said >>>>> that these documentation steps are very very critical for the >>>>> success >>>>> and sustainability of the project.
>>>>> However, even though I've read at least 2 rails books, I never >>>>> see an ER >>>>> diagram or UML diagram. So the question is, in the business >>>>> life, do you >>>>> use these steps? Or these steps are not usable in practice? How >>>>> do you >>>>> design your application?
>>>>> Any readings or books for this stage of rails development will >>>>> really >>>>> help me.
We will have to make a few hires, and also call in partners for some parts of the work, but we think we can make it work. Whether we can convince the client is another story :) Realistically though, we think most of the people pitching will be in a similar position.
> Pick a price that gives you a ton of padding if you get the project. And if > you don't get it, you're probably better off. :)
We're not going to be shy with pricing. It seems they're expecting to pay a lot, and for the level of paperwork, documentation and systems that they require we'll make sure its worth our while.
> And don't do ANYTHING without a good lawyer.
Definitely!
Cheers Nick
On Jun 19, 5:06 pm, "Jon Dahl" <jond...@gmail.com> wrote:
> On 6/15/07, Nick Coyne <nic.co...@gmail.com> wrote:
> > Thanks for the suggestions.
> > Unfortunately this is one of those where its explicitly mentioned that > > there's no fee payable for the proposal, and if we don't like it, > > tough. The detail of the RFP is insane - we are expected to provide > > costings, staffing, etc, etc, etc for the next 3 years (the duration > > of the contract). I feel like I'm quoting on redesigning their central > > database, where the world would end for 100,000 employees if we got it > > wrong.
> Are you staffed for a project like this?
> Half of me is saying "forget it, its too much effort, and we won't get
> > it because we're not corporate enough", and the other half is saying > > "do it, you might learn something!"
> One of the most important things I've learned is to get a feel for clients > and projects, and turn down the ones that give me a bad vibe. This is hard > to do early on, and we took a few projects for bad clients. They were good > learning experiences, but also pretty painful.
> I get a bad feeling from what I've heard so far about this project. Sounds > like the client wants someone they can abuse. It also sounds like they have > deep pockets. If you want to try the project, and you have really skilled > staff (or can staff up), I would ask for a lot of money - like US$400,000 > for the initial build cycle and a few hundred thousand a year after that. > After all, they want to take $50k back if the project is late, and lateness > is almost a given with a difficult client.
> Pick a price that gives you a ton of padding if you get the project. And if > you don't get it, you're probably better off. :)
> And don't do ANYTHING without a good lawyer.
> --Jon
> Cheers
> > Nick
> > On Jun 15, 3:31 pm, Robby Russell <r...@planetargon.com> wrote: > > > On Jun 14, 2007, at 9:59 PM, Nick Coyne wrote:
> > > > We're pitching on the web and digital marketing for the South African > > > > division of a Fortune 500 company. The RFP is over 150 pages long and > > > > the proposal will no doubt take days to complete.
> > > If you're spending time discussing their project, you should be > > > incorporating this into your cost. We almost always charge them to go > > > through a formal proposal process. This is what we call an ITER-ZERO > > > phase, and we charge for this process, because our aim is to provide > > > more value to their project through our discussions with them.
> > > One could argue that a consultancy could take the risk and do it for > > > free, but if you're reviewing their documentation and making any > > > suggestions as to how to improve upon their proposed solutions... > > > then they get to walk away with that for free. You could then argue > > > that you just save your new ideas until you win the contract, but > > > perhaps this is an important selling point for you.
> > > In our case, it's been part of our selling process and because of how > > > busy we've been over the past few years, it's been a good way to > > > filter out potential clients that aren't willing to pay to have > > > someone give them a meaningful analysis of their project > > > proposal. ...and I can speak from experience. There are many > > > companies that will pay you for this process. You just need to ask > > > them to do it.
> > > > Almost everything in the RFP points to risk-minimisation, with clauses > > > > such as a $50,000 penalty should the launch date for the new website > > > > be missed, for example.
> > > I would review this very carefully. Given that they want to minimize > > > the risks, I would have a lawyer review this and propose changes. For > > > example, is their a $50k bonus for delivering it early? This isn't > > > unheard of.
> > > > Now if this was a normal project, the website would probably only cost > > > > about $50,000, but considering all the overhead that we'd have to > > > > carry to satisfy their risk aversion (more staff, etc), and also the > > > > very stiff penalties that delays could incur, I'm thinking that we'll > > > > have to charge a lot more than we normally would.
> > > Without knowing more about their project, I can only offer so much > > > advice. Mainly, try to avoid providing a flat bid on projects. Stick > > > to ballpark estimates and insist on a time and materials contract or > > > a hybrid of short 1-2 week iterations with a cost for each, depending > > > on the deliverables within each iteration.
> > > Anyhow... running late to work.... but wanted to send over some of my > > > thoughts from my experience in these situations.
> > > Cheers,
> > > Robby
> > > -- > > > Robby Russell > > > Founder and Executive Director
> So, any recommendation about books about Agile development, or XP > programming or extreme project management ?
> I've read about agile development philosophy and now I feel better. > Thanks Jon.
> On Tue, 2007-06-19 at 11:39 -0500, Jon Dahl wrote: > > As Robert hinted at, Rails developers tend to shy away from UML and > > the like. Do some research on Agile development and you'll get an idea > > of how many Rails teams like to operate. Agile and UML don't > > necessarily have to conflict, but in practice, they often represent > > really different philosophies.
> > (Of course, there are plenty of Rails coders out there who think > > they're being Agile by not managing their projects at all. I probably > > used to fall into that camp. But that's another story.)
> > Cheers, > > Jon
> > On 6/18/07, Robert Fischer <robert.fisc...@smokejumperit.com> wrote:
> > I've found the real value of formal diagrams to be in creating > > them -- > > like a mathematician writing out a proof, it really forces you > > to think > > through the design. It's also an OK way to try to get a grip > > on source > > code that I'm not familiar with.
> > As a tool for business communication, though, I've not > > encountered one > > which I particularly like. Even moderately complicated > > designs end up > > being either 1) a mess of tangles, and/or 2) a spray of > > disparate > > clumps. There is just enough technical information in the > > diagram to > > require some skill to read it (thereby limiting the audience > > and > > creating potential confusion), yet not enough to catch > > implementation > > details (thereby missing out on the biggest value of being > > technical). > > For business communication, I prefer to use tools like FIT > > (http://fit.c2.com/) and lots of demonstrations.
> > Most of my design -- particularly with a framework with > > "natural paths" > > as strong as Rails -- is sketched out with arbitrary boxes and > > arrows. > > I've learned that if I put too much more effort into it, I'm > > going to > > over-architect the solution, and I'll actually end up being > > less > > productive. Worse, sometimes I'll put so much effort into the > > boxes and > > arrows that I'll forget that my contract is with the customer, > > not with > > the boxes and arrows. Once I have the few sketched out boxes > > and > > arrows, I let the design emerge from the customer requirements > > and the > > practice of writing unit tests: I build things as I need new > > functionality or need to decouple code for testing.
> > Robert Fischer > > IT Firefighter > > Smokejumper Consulting
> > Mustafa Ekim wrote: > > > Hey everybody,
> > > I am 24 years old boy, Mustafa Ekim, from Istanbul / Turkey.
> > > I have graduated from university on 2006, and done my > > military service > > > this year. Now I'll start working on a IT company in Turkey > > which mainly > > > focuses on mobile applications.
> > > Even though I am not a software expert & engineer, I really > > impressed by > > > rails last year. Since that time, I am trying to create my > > application.
> > > When I were a student, I always learned that I should draw > > ER diagrams, > > > Data Flow Diagrams, UML diagrams etc. to be certain that the > > project is > > > understood correctly by everybody in the same way. And it is > > always said > > > that these documentation steps are very very critical for > > the success > > > and sustainability of the project.
> > > However, even though I've read at least 2 rails books, I > > never see an ER > > > diagram or UML diagram. So the question is, in the business > > life, do you > > > use these steps? Or these steps are not usable in practice? > > How do you > > > design your application?
> > > Any readings or books for this stage of rails development > > will really > > > help me.
