Also consider the following - All code/IP is locked into escrow until both parties confirm delivery (protects you and them at the same time). - Fixed contracts are just that a contract based on fixed units of work. Any deviation whatsoever is a separate contract and don't just "give freebies" away as it can backfire on you given you're setting a tone / assumed & reasonable agreement precedent. - Place financial milestone rewards. Don't wait holding the "code" bag at the end, have the customer pay for each milestone as this will give both parties an exist strategy should the wheels start coming off.. Also bake in a % of the total cost (5%) as a carrot for final delivery + Severity #1 free to show customer you are sticking around for the long haul. - Identify a communication plan upfront. "We agree to have 1x meeting each XXX days...etc" if you ever go to Small Claims Tribunal for non-payment these sort of agreements hold more water than you think. As in situations like that you're trying to prove the customer had lost the faith and you were there all along. - FK YOU PAY ME....https://vimeo.com/22053820 watch and learn.. this guy made me laugh but after retaining a lawyer for small jobs here & there.. his wisdom won me more $$ back then previous.. The amount of times customers would just fade away after I did the work made me almost broke at one stage in 2010. - Be clear what IP/Copyright you own before and after. I accidentally got in hot water with Aust Govt after I used a design i made on my portfolio. Turns out copyright law says I own all artwork unless done by govt ...its as if they did that deliberately .. but it caught me by surprise and from there onwards i carve the IP/Copyright cake upfront and cleanly that way no more of these "but i own the IP" shenanigans. Plus it reinforces trust some more around who gets what and why. - Make the customer pay for the discovery and delivery... its one thing to say "here's a brief overview of what i need now how much" as you can charge the client for the discovery phase as well as delivery. It also is a good milestone PRIOR to doing any "Agile" ... as that "feature" list doesn't make itself :)
My 2c. --- Regards, Scott Barnes http://www.riagenic.com On Sat, Aug 3, 2013 at 10:03 AM, Richard Jones <[email protected]>wrote: > Thanks Paul for advice, > > This is really useful information. > > Richard > > > > ------------------------------ > From: [email protected] > To: [email protected] > > Subject: RE: Estimate Time and Cost before signing a contract > Date: Sat, 3 Aug 2013 09:32:02 +1000 > > > Richard, > > > > Great advice there from Greg. > > > > I do a lot of lump sum fee work, but as an independent project manager in > property development and construction (coding my own web project ideas is a > hobby yet to pay any dividends) > > > > In terms of how you go about it I suggest – > > > > 1. Write your scope / role in broad but concise terms to provide to > the client (but this is just as much for your own benefit as follows); > > > > 2. List your deliverables and describe them. I guess for software you > need to describe the functionality / limits of functionality to be achieved > as well; > > > > 3. Determine your lump sum amount by listing in a spreadsheet, in > sequence, every step and item of work you need to achieve the end result, > and estimate your number of hours for each, then apply your hourly rate. > The more you break this down, the more realistic it will be with respect to > the real cost to do the work, and the less dependent the amount will be on > the accuracy of your hour estimates for each item. If you know the client > and they are straight forward people consider providing this to them and > asking if that’s the way they see the task as well. As many times as I’ve > had to cut the estimate to meet expectations or get the job I’ve also had > good sensible clients say they believe more time would be required overall. > Of course they may use your list to get prices from someone else but at > least that helps prevent a less competent person getting the work by > failing to identify all the work items required; > > > > 4. Work out the things to advise that will change the cost and the > parameters you need them to work within ie; respond to my queries within 1 > business day, provide a client rep responsible for that, reprice if project > duration > X months through no fault of your own, no allowance for any > matter becoming protracted etc. Use these qualifications in your offer. > > > > Lump sum fees can be very uncomfortable for you and the client (and > ruinous to your financial wellbeing) if you don’t manage it every step of > the way through the job. Maintain a good relationship with the client, > don’t be talking fees all the time or much at all, try to accommodate > errors and stuff-ups on their part generously, but when the scope changes > be quick to say Yes, I can do that, it’s a great idea, and here’s an > estimate of costs to implement it (include reworking costs). > > > > Paul .. > > > > > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Richard Jones > *Sent:* Saturday, 3 August 2013 6:52 AM > *To:* ozDotNet > *Subject:* RE: Estimate Time and Cost before signing a contract > > > > Thanks Greg, > > > > Very good advice provided, Greatly appreciated. I will review what you > have written and come to a decision. > > > > Richard > ------------------------------ > > Date: Fri, 2 Aug 2013 22:47:56 +1000 > Subject: Re: Estimate Time and Cost before signing a contract > From: [email protected] > To: [email protected] > > Hi Richard, > > > > Fixed price quotes can be a great way to make good money and to lose hard > earned money, you have to take care and make sure you know what you are > getting yourself into. > > > > Businesses like them, because they know their maximum exposure. > > > > I find that there a far too many clients, who think that they can estimate > software development time, but they have little (no) true experience in > software development. > > > > Some thoughts… > > > > Make sure that scope is clear with at least one bullet point for every > deliverable that you know they are expecting and also clearly state that > anything not listed in the deliverables will be cost plus later. > > > > This also helps them make sure that they have asked for everything they > want / expect. I also typically have a list of non-deliverables, where we > have discussed some feature and agreed that it would be included in a later > version. > > > > Make sure that the contract is not a one way street, if you are expected > to take the risk on a late delivery, you should also get the reward of > getting it in early. If the client is asking you for a fixed price, then > you should have the option to do the work where, when and how you like. > This also ties the client into waterfall development, once you give them a > version for test / review, there will be a stack of change requests coming > in AT THEIR COST! > > > > I have found that some projects more than double in size with the change > requests, that is why they have to be managed. Take care doing a few for > free, or you will set up an expectation. > > > > Look out for clauses like: “Must be easy to use”, “Must be documented to > our standard”, “Must be fully commented”, “Must follow our coding > standard”, “Must be approved by our standards group”, “Must be approved by > our DBA”, “Must interface with our un-documented system”, these are all > open ended non-objective unclear requirements. > > > > My standard way of sizing a project is loosely based on (very loosely) > function point counting, I count the number of database tables and simple > screens and multiply this by a factor that I have worked out over the years > of my realistic productivity, then I add on a margin for complex logic, > complex screens, client liaison time, documentation, testing and general > stuffing around that all projects have. > > > > Number one piece of advice, if you feel you don’t have enough information > to make a meaningful estimation, then do your best (worse case) guess and > at least double it. > > > > After I have done this, I look at the number and ask if it feels right or > not, if not I adjust it. When you come to a final number, round it to a > number that is not quite so analytical, the last two or three digits should > always be zeros. > > > > If they say sign now or loose the contract, you say, that is fine, I will > sign after I complete the analysis at $X per hour, if they don’t like that, > you have to make the call on risk / reward ratio. > > > > Your analysis time should be charged or you are setting up an expectation > that you will do work for free. > > > > Follow every conversation with an email to the client sponsor, CC to who > you were talking to “As per my conversation with Fred, you need xyz and do > not need abc. This will be provided with an increase in the project scope > of X days and Y dollars. Please confirm your agreement by return email.”. > > > > Good luck > > Regards > > Greg Harris > > > > > > On Fri, Aug 2, 2013 at 7:51 PM, Richard Jones <[email protected]> > wrote: > > I have been asked by a potential client to work out time and cost estimate > before I have signed a contract to perform the work. They indicated they > didn't want a recruitment company. > > > > To me this seems a bit strange, as I have never experienced this before, I > have usually signed a contract got in and did the work, however, this is > different. They have indicated to me that they think this type of work will > take 3 months, however, they would like me to confirm/demonstrate time and > cost. > > > > Has anyone had this type of work?, any helpful comments/suggestions would > be grateful. > > > > > > > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 2013.0.3392 / Virus Database: 3209/6544 - Release Date: 08/01/13 >
