Customized Software - Evaluation

This topic will put heavy emphasis on the biggest obstacle in custom software development ...

Please excuse this silly example, but it does make a point ...
How would you explain how to build a snowman to an alien from another planet? It could take hours, if not days ...

You:    You need to keep your hands warm so ...
Alien:  What are hands?
You:    These things. Now, put on mittens to stay warm.
Alien:  What are mittens?
You:    They are made of wool, and ...
Alien:  What is wool?
You:    It comes from sheep.
Alien:  What are sheep?
You:    They are animals that are raised on farms and eat grass.
Alien:  What are ...

As you can see, we haven't even gotten to making the first snow ball yet, let alone explain where snow comes from. So why is this relevant? This directly relates to how you would explain to a programmer what you need the software to accomplish. We all take certain aspects of our business for granted. It's how we are able to learn and then move on to new things. When explaining things to people, we easily forget that we may be saying things that the other person won't fully understand. Consequently, when explaining what you would like accomplished, you need to try to take yourself back to when you, yourself, first started learning about your business. This is not an easy thing to do. Regardless, clearly articulating your requirements in detail is the most critical role that you will play in contributing to the development of your custom software.

Although the above example may seem extreme since most people don't believe that programmers really are from another planet, it is still a drawn out process for a software developer to fully evaluate your requirements. The primary obstacle being "assumptions". You, having been in your business for some time, must try to explain what you need done without leaving out any details - the sort of details that you take for granted. If all aspects of your requirements aren't explained completely, down to the smallest detail, the programmer may mistakenly draw the wrong conclusions. This results in missing or incorrect functionality in the final product. It can also easily cause the project to go over budget. This problem exists in the design of absolutely every software program that anyone has ever made and will always exist. That's why there are "versions". Our goal is to keep these inevitable situations to an absolute minimum, with your help.

We clearly recognized this inherent characteristic within the software industry, and we don't try to hide it from our customers. To eliminate this problem as best we can, we make every effort to keep this sort of miscommunication from happening. To do this we practice the following guidelines ...

• Make you aware of the necessity of thoroughly communicating your ideas.
• When possible, we like to interview the actual users. This has often proved invaluable.
• Keep you involved in every key step of the development process.
• Start with conceptions on paper, which are followed by prototypes before proceeding with final development.
• Our design standards that focus on expandability also make most mid-stream changes a lot easier.