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.

 

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.

 

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 bring you closer to the estimated cost. Alas, you're still going to overlook a few things - and "little" things may, or may not, be costly to implement after the project is started. Plus, you may also realize you want functionality that you hadn't initially considered until after the project is underway or even after it's completed.

 

 

Be Prepared for the Estimated Cost and Time 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 due to the reasons previously mentioned. Being aware of this probability will, at least, provide you with a more realistic expectation of the project's eventual cost and time. When given the estimate for completion, you will be encouraged to assume that doubling it will provide you with more probable numbers - although, even that is uncertain.

 

This inevitability exists in the design of absolutely every software program ever made, and it will always exist. Our goal, with your help, is to keep these inevitable situations to a minimum, while still projecting overages.

 

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 reduce time and cost overages 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.