6 Replies Latest reply on Feb 28, 2014 7:28 AM by DanielShanahan

    How do you handle revisions and/or change orders


      It is my conviction that a proposal is never complete and change orders are inevitable. Currently, I build in roughly 10 hours of development time for change orders. I have this in my proposal:



      "New Leaf Data, LLC and the client made every effort to describe, illustrate, and understand the needs of the data system during the discovery phase. Nonetheless, it is common that during the development process other needs and/or requirements surface. These are project revisions."



      I'm not sure this is the best way (or even if there is a "best" way). How do you handle revisions/change orders?

        • 1. Re: How do you handle revisions and/or change orders

          I have a similar disclaimer on my estimates. What I do is build a contingency (typically, 10% of the estimate hours) into the project. If I screw up, it comes out of contingency. If the customer brings extra scope, it's a scope revision and additional hours. Might sound harsh, but I've found that scope creep will kill you if you don't make it clear up front that "extra stuff will cost extra".



          • 2. Re: How do you handle revisions and/or change orders

            Thanks Mike.


            How do you determine if something is a mistake on your part or is out of scope?  Seems like it could be a gray area (though I could be over thinking this).

            • 3. Re: How do you handle revisions and/or change orders

              No, you're not over-thinking it. There are absolutely gray areas at times. So here are a few things to think about:


              First, there needs to be lots of communication with the client. Explain the scope, ask questions, explain the scope, and then ask questions about the scope again. As I'm sure you're aware, most clients aren't as savvy on computery stuff as we are (if they were, they wouldn't need us). Conversely, we don't always fully understand what they mean when they ask for something because we don't do their jobs day in and day out. So there has to be lots of communication and clarity. I find it helps if we explain a little bit about how things work in a database application - not so much their eyes glaze over, but enough so they get an idea of what's involved. Helps them feel better about fronting all that money. (Sometimes, it's counterproductive; some clients just want you to do the work and go away, so you have to feel the client out on that.)


              Secondly, put it in writing. Emails are fine, but there need to be follow-up communications to everything that's agreed upon. If it ain't in writing, it didn't happen. (Helps avoid the "But in that meeting, you said ..." syndrome.)


              Now, what does all that have to do with figuring out whose "fault" a change is? Primarily, it avoids the "But I thought..." problem. Assumptions are deadly. In my experience, most disagreements over change orders stem from exactly that problem: Differing expectations that arise from assumptions that were made on either or both sides. If I assume a feature is supposed to do X, and the client is thinking it's going to do Y, then you have the makings of a disaster. If everyone's on the same page up front, then that possibility is minimized. (You can never truly eliminate it; you're dealing with human beings and we're not telepathic.)


              So things that typically fall in my area are: (1) Features that are needed, but I forgot to put in the scope (getting better about that); (2) Shorting the estimate (getting better about that too); (3) faulty implementation that has to be fixed later (which is rare, but hey, I still screw up sometimes). Scope creep is usually of the nature of, "Hey, it'd be nice if ..." or "Well, we just heard from our CEO, and he wants it to do ..."


              Finally, and probably most importantly, give grace. I find that being really rigid about nitpick little things contributes to the client being rigid about nitpick little things in return. You have to draw boundaries, but I've found that throwing in little "extras" without charge contributes to good feelings and tends to help the client feel better about change orders when they need to happen.


              The most fundamental rule in business is the same as the rule in other sorts of relationships: How would I want to be treated if I were the other person? Tends to work really well. Be firm, be fair, be generous, meet needs. Make money!  





              • 4. Re: How do you handle revisions and/or change orders

                Thanks Mike.  That is helpful information.

                • 5. Re: How do you handle revisions and/or change orders
                  Stephen Huston

                  I agree fully with Mike, but would add a couple of thoughts about defining the scope of the project in terms of functionality. I find that a written Specification Document is my method of choice for defining a quote's parameters. I have created such documents to accompany written quotes, and they range from a couple of pages up to about 20 pages. A section of the spec doc is on Functionality, and lists all functionality that the client has specifically requested as part of the project. There is also a statement in the quote section that any  additions to the Functionality section will result in appropriate increases to the hours to be billed.


                  That's my solution to "Feature Creep" -- which will kill you if not controlled.


                  My last inhouse developer position was, by definition, one of dealing with feature creep -- dozens of hours per week just to keep up with new reports and functionality that a staff of 100 wanted added to a system that had been built on the fly over the course of a decade! If you're on the payroll, no problem; otherwise, you need for them to know what the quote includes and make it clear that what's not included in the written specs is extra -- to be determined....


                  The Functionality section also provides the developer with a significant checklist for measuring one's progress towards the goals and completion of the project.