The stupid question is the question not asked | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
getting your clients to sign off on a comprehensive business case that doesn't change, ever, is probably going to result in unhappy clients. If nothing else, the business environment is probably going to change between specification and delivery. The point behind getting a signed business case isn't that it shouldn't ever change. The idea is that it can't be changed lightly, and there is an understanding that altering the business case is going to change your estimate of time and may even require you to re-write code. If I am given a business case, I can make a reasonable projection of how long the project will take and what resources it will require. If the business case changes -- and especially if that change requires re-work -- those projections must change, as I will never be able to meet the original deadline. By having a signed business case (or "deliverables" document), you CYA: the client has an understanding that they are essentially altering the contract.
radiantmatrix
require General::Disclaimer; "Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy In reply to Re^4: OT: Project clients
by radiantmatrix
|
|