From the last exciting episode: You've got an existing application that needs to be upgraded/replaced. The issues of "What language should we use?" and "Can I do the work?" have been resolved. The questions remaining are "How long will it take?" and "How much will it cost?"
It depends..."
Naturally, the sooner the better, but unless there is a hard and fast deadline, such as the start of a pro sports season (I had that happen once), or the termination of an input data stream (had that happen once, too), whether the answer to first question is "three months" or "nine months" is for the most part inconsequential. The app hasn't been touched for a decade, a few more months won't make any difference.
The magnitude of the cost, on the other hand, is considerably more critical. One amount may be a reasonable investment for a brand spanking new version; three times that amount (roughly equated to the difference between three months and nine months) may make the effort economically unfeasible.
So..... "How much will it cost?"
And the answer is "it depends."
I've been using Visual FoxPro since it went into testing at Microsoft in 1994. Together with my work in previous versions of FoxPro (and dBASE), I have an extensive database of my historical costs for several hundred development projects. Given the proper specification, I can tell you, to the penny, how much an application will cost and how long it will take.
"Given a proper specification"'.... Therein lies the rub.
What goes into such a document? If you have an exact description of the desired system:
- How many forms, reports, processes
- How many controls on each form,
- The business logic associated with each form and each control,
- How many data elements on each report,
- Flow charts of the logic used for each process, and
- The number of tables, and the number of fields per table,
then I can tell you exactly how much it will cost.
The problem is that in the last 20+ years, nobody has - when they initially contact me - a complete specification. Most don't even have a rough idea of what they're looking for. After some introductory remarks, people tend to jump into details, such as complaints about a specific screen that performs poorly in the existing system, or nuances about a feature that needs enhancement.
It's much like a homeowner calling a builder, and, after a brief discussion of some possibilities, pulling out swatches of living room carpeting, paint chips for the upstairs hall, and light fixture brochure, and then jumping into details about finishes. Several hours and two meetings later, the homeowner wants to know how much the house will cost, without ever having answered questions about square footage or number of bedrooms.
So given that there isn't a description of the system you're looking for, what are our options?
The first is to write a complete functional specification, describing each item listed earlier. This enables me to be able to tell you exactly how much the system will cost, together with a firm delivery date. For static systems, those with well-defined requirements and capabilities, this is a viable option. I've built dozens of specifications for systems from scratch, ranging from a couple of months to a couple of years, and have a tried-and-tested template.
However, most upgrades/conversions aren't as cut and dried as a brand new system, and yours is certainly one of them. You've already indicated that there are components of the existing system that aren't being used any longer. Other existing functionality needs to be changed or enhanced, but you're not quite sure what the new implementation will look like. Developing a written specification in this scenario could well increase the cost and definitely will take longer than Plan B.
Plan B? What *is* Plan B?
Stay tuned.
|
