what do you consider "done"?
| 1:37 pm on Aug 26, 2013 (gmt 0)|
So, you make a contract with an outside contractor. You have the following milestones in the contract:
- milestone 1: System A
- milestone 2: System B
- project completion: System C
What are your definitions of "milestone" and the work being "done"?
Do you consider 80% of the specified functionality being "done" or do you expect 100%? (I'm not talking about 100% bug free in rigorous testing, but basic things like 100% of links going where they are supposed to go, etc.)
At milestone 1, do you expect System A to look pretty much like the mockups provided, or do you accept that the contractor still needs to do quite a bit more to move elements around and make it pretty?
| 8:47 pm on Aug 26, 2013 (gmt 0)|
I work a lot with subcontractors.
If the above are a separate systems, and you pay based on milestone being reached, then I expect at each milestone the finished product, that passes "confidence test" (i.e. no bugs with straight forward expected functionality, but may find bugs if trying to break the system).
In this case if they walk away after you have paid for System A - you do have System A completed.
If the milestones are checkpoints of the one bigger system, then I treat them in a bit more relaxed way, more like "are we on track or are we late", and would expect functionality to be done, but perhaps may have more bugs as the proper testing may happen when the whole system is finished.
If I know the subcontractor, I may build in my past experience with them into milestone definition. If I have not worked with them before, then I would be more strict on milestone deliveries.
I would rather be more strict with the contract, and then I could be (if I wish) more relaxed when deciding whether the milestone is reached or not, or even pay up at the milestone with some kind of temporary "waiver" if everything was not delivered to the expected/defined standard.
|At milestone 1, do you expect System A to look pretty much like the mockups provided, or do you accept that the contractor still needs to do quite a bit more to move elements around and make it pretty? |
As I said, I would expect the finished system. But you could break this into two milestones 1a and 1b, where 1b would be "make it pretty" or have "make it pretty" included in milestone 3 or even as a separate milestone at the end. It should be defined somewhere though!
| 10:11 pm on Aug 26, 2013 (gmt 0)|
OK, glad I'm not the only one thinking that way!
Although it wasn't explicit in the contract (my bad for not making it clearer there), there were definitely conversations (verbal and e-mail) along the lines of "we need System A done for milestone 1 so we can integrate it with our legacy system and do all the translations before going live."
Also, since systems B & C require the functionality of system A, it seems pretty obvious to me that system A has to be pretty much functional if one is going to try to develop B & C.
| 12:03 am on Aug 27, 2013 (gmt 0)|
I think there are two aspects:
a) contractual milestones (for payment schedule)
b) milestones required within the overall development project plan - these may not be all tied to payment schedule, but if you have third party (or your own) dependencies that require that milestone is completed first, and want a very tight contract, you may look into building a some kind of penalty clause for failure to deliver on time (but be realistic on building up slack without telling subcontractor there is one, as almost every dev project overruns, the question is just how much for)
I am not clear whether you are looking to not to pay them (yet) for the milestone or the problem is that their delay causes you delay on other fronts so you want them first to complete System A before starting with System B.
I work with multilingual systems and from my experience you cannot really translate elements before the system is made pretty as the width of some element may result in a different translation phrase being required (original one may not fit later on).
<added>I also find useful to have defined tests I will run at the end of each milestone, so called "acceptance test", e.g.
- all navigation links lead to defined destination
- the layout as per mockup bar changes agreed in writing during the development phase
- functionality x performing y
This then tells exactly what you are expecting as a part of the milestone. Wording "system A completed" may mean different thing to different people.
| 12:28 am on Aug 27, 2013 (gmt 0)|
Yup, pretty much still on the same page. :)
In this case, it's both a & b. And yes, there is a late penalty clause. The contractor is the one who set the milestone date, knowing full well about the late penalty clause.
The whole point is we're not trying to beat the guy up about the money- we just want completed work so we can start the work that we need to do on our end.
| 12:23 pm on Aug 27, 2013 (gmt 0)|
I also find useful to have defined tests I will run at the end of each milestone
A pre defined test plan isn't "useful" it is essential.