How to Build a Snowman

- or -

Why has my project gone over budget?


This is part of the In-Depth Analysis explanation of the Evaluation & Development Process.


This topic will put heavy emphasis on the biggest obstacle in custom software development... Adequately discussing what you need accomplished without leaving out the details that you take for granted.


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?


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.

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?



Assume the Programmer Knows Nothing About Your Business


The above example directly relates to how you would explain to a programmer what you need your software to accomplish. It's easy to take for granted certain aspects of what you do in your "world". When explaining things to an "outsider", it's easy to forget that you may be discussing something that the other person won't fully understand, and that you may omit critical pieces of information that, to you, are as obvious as how to make toast. Consequently, when explaining what you would like accomplished in the software design, you need to try to take yourself back to when you, yourself, first started learning about your "world". 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. It will save time... and it will save money.


Although the above example may seem extreme since some people don't actually believe that programmers 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 working in your "world" 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.



Be Prepared for the Estimated Cost of Your Project to Double... or More


The likely reality is that, when you are provided with an estimated budget for your project, you should be prepared for the final cost to be significantly higher, as well as an increased length of time to completion. This is entirely due to the inevitable fact that you have unintentionally omitted important information during the evaluation process, which will ultimately add time to the project in order to compensate. Being aware of this will, at least, provide you with a more realistic expectation of the project's eventual cost and time.


If all aspects of your requirements are not explained completely, down to the smallest detail, the programmer may mistakenly draw the wrong conclusions as to what you expect. This will result in missing or incorrect functionality in the final product. It can also easily cause the project to go over budget and also result in delays. This problem exists in the design of absolutely every software program that anyone has ever made, and it will always exist. Our goal, with your help, is to keep these inevitable situations to a minimum.


We clearly recognized this inherent characteristic within the software industry, and we don't try to hide it from our customers by not giving you fair warning. In order 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 (as per the above).
  • When possible, we like to interview the actual users. This has often proven to be invaluable as the intended users of the software may have more practical experience than the person in charge of acquiring the software.
  • 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 focus on expandability ans, as such, make most mid-stream changes a lot easier. In other words, if you need to add or change something, it typically won't mean scrapping huge chunks of the program in order to accommodate any changes.



Back to the Evaluation & Development Process.


LinkedIn Icon Twitter Icon Facebook icon