Darryl Collins
darryl at whittleconsulting.com.au
Thu Dec 8 22:02:47 CST 2011
Heh.. Outstanding. And I totally agree - many times I have ended up making much more mulla than the original spec as the stakeholders are unable to agree on much. Person X will request this feature, Person Y want something else. You add both, and then their manager will make changes again - or remove the said functions. Good for the invoice, but it can be frustrating. Indeed for one client I almost never deleted any feature they had been requested and built, I would merely turn if 'off' or made it invisible. It was fairly common for a 'deleted' function to be reinstated in a month or two at the insistence of someone in the organisation. Fun stuff. I always document who requested what and when - and often even show it as a line item on the invoice for those hours. This makes any discussion about budget overruns easier to deal with I find. Sure, there maybe some heat and fire from the accounting dept, but at least I am not in the firing line ;) Live and learn... -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller Sent: Friday, 9 December 2011 2:41 PM To: Access Developers discussion and problem solving Subject: Re: [AccessD] Requirements (was: I should be able to do this-resolved) Referring back to my original whine about this problem, in the absence of a definition of calendar-years, how was I supposed to know there might be a difference between the real world and the world of pension-funds? A pension-fund specialist or programmer of apps in this field might have known to ask this question, but I didn't, nor did any of the requirements-people deem it worth mentioning. Granted, now that I've been severely bitten and savaged by this, I know enough to ask about the definition of a year. But even granting that, what about the definition of a month? How to handle leap-years? How many Requirements-meetings shall be consumed discovering these anomalies? Thank God that I have subsequently learned that Gathering and Verifying Requirements is a (and perhaps The Most) billable item on the ultimate invoice; and that any subsequent changes to the Requirements document is also billable vis-a-vis the Development spec. The beauty part of this arrangement is that when some flunky wants this to work that way instead of the previously-accepted spec, I get to say, "Ok, but it's going to cost you another $10+K. Are you sure you want to make this change?" Which adroitly punts the ball to her or him, and forces her or him to justify the change in specs. Even more elegant, all such requests for change are directly traceable to the person who requested them. LOL. Twice bitten, thrice shy, as it were. "You want to fork with me? Go ahead, it's all billable, directly to you! So there, MoFo." Go ahead, stretch your middle-management muscles, but your bosses will know precisely whom to blame for the OverRuns. A. On Thu, Dec 8, 2011 at 3:02 PM, Asger Blond <ab-mi at post3.tele.dk> wrote: > Oh what a wonderful statement! > Asger > > -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com