Primarily medium to large business applications built on Internet and client-server technologies.

Although most companies make good use of many off-the-shelf applications, from word-processing and spreadsheets to accounting, and enterprise-wide applications like Customer Relationship Management, Enterprise Resource Planning, etc., virtually all have areas of need not met by these applications. Every organization is unique in many ways—perhaps in the specific services or products it offers, in how it is managed, or how it relates to customers, and so on. Each one has certain areas where it operates in its own way, for its own reasons, distinct from everyone else. It is in these areas where custom software can be very effective in controlling costs, enhancing revenue opportunities, and improving the efficiency and reliability of business processes. These are the areas where we understand how custom software can really benefit an organization, and where we have been successful creating effective, reliable applications.

We have deliberately chosen to work in a wide range of industries. Your one-of-a-kind needs are what interest us—our professional pleasure comes from giving you software that is from beginning to end a bullseye for you—not some compromise based on modifying an off-the-shelf application.

Like every business undertaking, software development has its own patterns of risk. Recognizing and dealing with risk is a normal and essential aspect of creating software.

Although each project has a unique risk profile, here are typical types of risk encountered in software development:

• Finished application does not fit the needs of users
• Inadequate performance
• Development cost exceeds the value of expected benefits
• Application not ready in time to meet critical needs
• Unreliable or buggy operation
• Too difficult to use, non-intuitive, requires training
• Cost of ongoing support greater than expected

These kinds of risk are addressed in two ways.

First of all, the whole purpose of development methodologies and project management disciplines is to facilitate successful outcomes without falling prey to these risks. This is discussed in detail in the Principles, Development process, Project management and Rules of programming sections of this website.

Secondly, each project has its own unique set of risks, which should be explicitly addressed from the beginning. The development plan should identify these risks and describe how they will be evaluated and avoided. For example, suppose that for a given application there is potential for a "fatal" performance problem related to network architecture or database structure. In this case, small testbed applications should be built early so that actual performance can be measured before significant resources are invested. If risks like this are identified in advance, steps can be taken to guide development around potential problems without unnecessary waste of resources.

There are many aspects to project cost, but let’s take it from this point of view: “For a given finished product, how can I as the client minimize total cost?”

Here are some of the more effective things you can do:

• Help get the requirements right. If you have time, do your best to state in your own terms all of the requirements for the new software. In any case, give especially good support to the developers during the requirements phase of the project. This is the most important step in the development process—everything that follows depends on it.
• Refrain from making unnecessary changes. Once there is a clear conception of “version 1” of your software, avoid asking for changes to this version unless absolutely necessary. It's usually more cost-effective to accumulate ideas for enhancements and changes and then deal with them after the first version has been in use for a reasonable period of time.
• Avoid artificial deadlines. As developers we will give you at each stage of the project our best estimate of the time required to complete the remaining steps. Sometimes there is a belief that a way to “get things done” is to simply set a deadline and insist that everyone live with it. This can not only lead to greater cost but can also lower the quality of the software. This is especially true during the requirements and external design phases of the project. The entire team—meaning your stakeholders as well as our developers—needs time to communicate accurately, digest, reconsider and explore the best options for your software. This is not wasted time nor does it indicate a lack of discipline. It is the least expensive way to arrive at solutions that go beyond the obvious—innovations whose marginal cost is low but whose marginal utility is great.

Probably the most fundamental things are to stay involved, stay close to the project, and don’t give up on your vision of what the application should be.

Sometimes managers believe that once a project is pointed in the right direction, they can pull back a little and “everything will be all right.” Everything may be all right, but even it is, many small issues and decisions arise over the course of the project, and you should be aware of these. Small inputs from you on a regular basis can, by the end of the project, make a big difference in the finished product.

From time to time there will be a feature in your application that someone, perhaps a developer, perhaps one of your stakeholders, will resist or want to change. Sometimes it should change, but other times the only motivation is “to make things easier” for the developers. If it’s an important feature, someone needs to be the advocate for the overall quality and integrity of the finished application. This is something you should do when it seems appropriate.