Project Opportunity using OutSystems technology (13 Sep 2011)

Project Opportunity using OutSystems technology (13 Sep 2011)

Please note: This is a strictly informative reference to an OutSystems-technology opportunity relayed here for the benefit of the Community. OutSystems has no involvement and does not endorse implicitly or explicitly the promoter of this project. Should you decide to pursue this opportunity, it is your responsibility to ensure the soundness and viability of the proposal.
These RFPs are nice to know about, but the very nature of the requests goes against the Agile Platform methodology. How are you going to respond to a fixed-bid request using Agile methodology? I sure can't!

You are absolutely right, of course, Justin.  But at the end of the day, the Agile Platform is best served by being married with an agile development approach, it doesn’t preclude the use of Waterfall.

We find that some newcomers to the technology don’t immediately buy into the agile aspect of it… some of them actually react negatively to explicitly being offered a two-prong combo of agile+OutSystems (two novelties in one go is too much). In this case, we normally win them over to Agile organically, when during a (theoretically) waterfall project the MO from the developers is actually agile and they just see that it works for future engagements. :)
Miguel -

I've gotten to the point where I refuse to quote prices. I charge per iteration, and if the work is 3 or less iterations I'll say "three or less iterations", but past that, I give no guarantee. You are right, a lot of people won't play ball. I have to take a very firm stance. I say to customers, "look, you remember all those other vendors who said '2 months and $10,000' and it was 4 months and $50,000? Well, I won't tell you anything more than 3 - 4 weeks of work and $3,000 - $4,000, because I have no way of knowing." Once customers think back to all the times that they went over budget and over schedule, they realize that those kinds of contracts aren't worth the paper they are printed on, and that with my approach, they actually can fine-tune their costs very easily.

This is good to think about, now I know what my article for TechRepublic will be in two weeks!

I very much look forward into reading that particular article then, Justin! :)

Keep them coming,



You are able to provide a estimate, but only when a complete software requirements specification can be supplied to you.

Here is how we calculate an estimate....

  1. Requirements gathering: Obtain software requirements specification (SRS) document from client (this is your blueprint), or gather requirements from client and create a use case product feature backlog.
  2. Feature prioritisation: Work with your client to prioritise your product feature backlog, this determine which features are needs and wants (ie which features you need to developed right now and which features can be scheduled for later).
  3. Schedule Release Plan: Now that you have prioritised each feature in step 2, group the features into a "Release sprint milestone". A sprint is usually 1-2 weeks, and your release cycle should be ~30-60 days, (depending on the size of your project) -  Short release are always  better!
  4. Calculate Estimate: Calculate the total number of hours it will take to develop each use case feature, then add the total number of hours of each features in your release sprint milestone to calculate the final total number of hours for each release, times this by your hourly rate and there you have your estimate :)

Note: If the SRS is incomplete, or a SRS can not be supplied, it would probably best not to provide a estimate as you might be quoting too high or too low, it is very risky! 

To those following this thread, you owe it to youself to read Justin's latest article (pointed from his thread at)