Session E-PROC

Managing the Application
Development Process

Whil Hentzen

Hentzenwerke Corporation


Designing Specifications for Custom VFP Applications

Writing code is the cool part of our job, but it’s not the only part of the development cycle. If you neglect the rest of the process, you may find yourself out on the street. This session looks at the front end of software development, starting with the initial request from a user, continuing on with the formation of a contract for specification development, through the delivery of a proposal that contains complete functional specifications.

An Argument for Fixed Price Work

Skill level of developers run the gamut from highly skilled to completely incompetent.  Customers have no way to determine the difference, and, as a result, highly skilled developers can’t charge proportionately more. Suppose you’re ten times more productive than the guy down the road - not an unreasonable assumption. Now suppose that developer charges, say, $40 an hour. Can you charge $400 an hour?  Not likely.  So, given your higher skill level, how do you make more money?  It follows that if you posses a higher skill level, you can deliver the same product for less money, or deliver more product for the less money, or deliver more product for the same money as the other guy.

As a result, if you quote applications with a fixed price, you can potentially make more money per unit of time than if you bill hourly.

Doing work on a fixed price basis requires three components.  First, a detailed specification that defines exactly what will be delivered.  Second, a mechanism for determining the cost for producing the application.  And third, a set of tools for efficiently producing it.

This session covers the first component - how to produce a detailed specification that will define what will be delivered, and how to work with the customer to make it.  The second session will show you how to determine your cost for the application that you have designed.  The rest of the sessions at FoxTeach will provide you with the third component - the set of tools for efficiently producing it.

Preparing the Customer for the Specification Process

Some customers are reluctant to pay for the design of an application, arguing that (1) the guy down the road will do it for free, or (2) that the design is part of the sales process and thus the cost should be born by the vendor.  How do you counter these arguments?

First, the relationship with a customer begins when they first ask for work to be performed.  At this point, it’s time to define the terms under which you will work.  This typically can be done with an Engagement Letter that defines the process of developing a specification, the charges that the customer will incur, and describes what the specification will cover.  At this point, the customer can decide whether they want to continue or not.

By describing the contents of a specification to the customer at this point, they will learn that what the guy down the road means by specification - three sheets of paper thrown together while watching Jay Leno the night before - and your specification - a complete design document that is sufficiently detailed to allow a programmer to produce and a tester to test with minimal follow-up questioning.

An analogy to blueprints for buildings or machinery is also useful in explaining why the specification carries a price and why it’s not a trivial process.

Components of a Specification

Cover Letter

Executive Overview

General Interface Notes

Specific Interface Notes

Functional Specifications

Menu Structure

Description of a Typical Screen

Description of a Typical Process

Description of a Typical Report

Typical Utilities

Technical Specifications