7 ms·

Out of curiosity, how do you define a solid scope ahead of time? What kind of details do you go into? What if the client asks you to tweak a feature that's wi

by byw 16y ago

Out of curiosity, how do you define a solid scope ahead of time? What kind of details do you go into? What if the client asks you to tweak a feature that's within the scope, but ends up taking up significant amount time?

jacquesm 16y ago
A solid scope in a mid sized or large project is usually determined by a design specification that all parties sign off on. Just preparing such a specification is a project in its own right and that's why for smaller jobs it usually isn't done that way but much more loosely defined. For me the most important bits are: - does all this fall within my current competence (in other words, do I have to learn something new or not) - is the project comparable to something I've done before or is it virgin territory - how clear is the customer able to communicate their vision of the things they want from me - do they already have artwork / wireframes or is it that I'm supposed to be the 'main contractor' contracting out those aspects that I can not do myself - are all the interfaces the system has to the outside world clearly defined and documented and/or accessible through existing apis? - is there a realistic expectation as to the amount of work that we are talking about and the amount of time alloted for documenting, coding, testing & debugging - are there hard deadlines associated with the project or not - what do they expect in terms of after-sales when the project has been delivered (do their people take over?, do they help with building?) - can we agree on a rough block diagram of how the system will be put together and do I feel confident about each of those blocks in terms of complexity and an estimate as to how much time it will take to realize that block For me the 'deal breakers' if the customer wants fixed price are mostly their vision, communications issues and the knowledge about external hook-ups. If any one of those gives me a bad vibe then I'll probably either refuse the job or I'll tell the customer that it is not possible to execute this job fixed price unless they come up with solutions for those issues. > What if the client asks you to tweak a feature that's within the scope, but ends up taking up significant amount time? That is a very tricky situation. I think that both parties are somewhat to blame if such a situation arises, if it is 'within scope' then a tweak should not end up costing significant amounts of time that indicates a less than general attitude towards coding things, on the other hand there should be some penalty for changing the design after it has been nailed down and agreed on, even if it is within the scope since it will require re-work of at least some portion of the design. I'd probably negotiate a reasonable adjustment of the price in that case (also to dissuade from further tweaks, or to get paid for them), and a note to the effect that the deadlines will be pushed back as a direct consequence of this. I'd also want that documented in email with the consequences clearly stipulated.
- byw 16y ago
  Those sound like some solid advice. I'll bookmark it. Thanks! :) Approximately how much time do you spend in this planning phase? As for the specification, what kind of things do you include in it?

by byw 16y ago

jacquesm 16y ago

A solid scope in a mid sized or large project is usually determined by a design specification that all parties sign off on. Just preparing such a specification is a project in its own right and that's why for smaller jobs it usually isn't done that way but much more loosely defined. For me the most important bits are: - does all this fall within my current competence (in other words, do I have to learn something new or not) - is the project comparable to something I've done before or is it virgin territory - how clear is the customer able to communicate their vision of the things they want from me - do they already have artwork / wireframes or is it that I'm supposed to be the 'main contractor' contracting out those aspects that I can not do myself - are all the interfaces the system has to the outside world clearly defined and documented and/or accessible through existing apis? - is there a realistic expectation as to the amount of work that we are talking about and the amount of time alloted for documenting, coding, testing & debugging - are there hard deadlines associated with the project or not - what do they expect in terms of after-sales when the project has been delivered (do their people take over?, do they help with building?) - can we agree on a rough block diagram of how the system will be put together and do I feel confident about each of those blocks in terms of complexity and an estimate as to how much time it will take to realize that block For me the 'deal breakers' if the customer wants fixed price are mostly their vision, communications issues and the knowledge about external hook-ups. If any one of those gives me a bad vibe then I'll probably either refuse the job or I'll tell the customer that it is not possible to execute this job fixed price unless they come up with solutions for those issues. > What if the client asks you to tweak a feature that's within the scope, but ends up taking up significant amount time? That is a very tricky situation. I think that both parties are somewhat to blame if such a situation arises, if it is 'within scope' then a tweak should not end up costing significant amounts of time that indicates a less than general attitude towards coding things, on the other hand there should be some penalty for changing the design after it has been nailed down and agreed on, even if it is within the scope since it will require re-work of at least some portion of the design. I'd probably negotiate a reasonable adjustment of the price in that case (also to dissuade from further tweaks, or to get paid for them), and a note to the effect that the deadlines will be pushed back as a direct consequence of this. I'd also want that documented in email with the consequences clearly stipulated.

byw 16y ago
Those sound like some solid advice. I'll bookmark it. Thanks! :) Approximately how much time do you spend in this planning phase? As for the specification, what kind of things do you include in it?