The King and the Castle
Once upon a time there was a king that wanted a new castle. The king hired the best castle builder in the land to build the castle. Prior to starting to build the castle, the king got an architect to construct the plans for the castle and the plans were drawn up quickly. These plans were then used to create the castle. The king went back to the original castle while the new castle was being built. When the king went to visit the castle after a week of building some things were not correct with what the king had wanted. The king explained this to the builder and the builder assured the king that he could make the adjustments while continuing to build the castle. The kind found this to be a rather difficult feat, but never the less, accepted the answer and went back to the castle.
Now, the king went back to see the finished castle and was greeted in anger by what the king saw. The castle was completed and of the best quality, but didn't have the rooms where the king wanted and were also not the correct size. The king stormed off and refused to live in the castle and went back to the original castle. The builder went on his way to the next job, without pay for the job.
Moral: There is the moral that the builder (developer) can be the best in the business but if the architect (requirements analyst) doesn't document what is truly wanted then the castle (software) will be of quality, but not of value to the customer since it is not what the customer wanted. Another moral to be gained from this is change is not always so easy in the middle of a process such as the builder assuring the castle can be adjusted to what the king wants after the king first seeing what was built. Although, the builder doesn't adjust it to the king's needs since he has already built the framework and once concrete is set, it is set. This can be paralleled in software development and analysis in that once a certain portion of the development has been completed, it is difficult to make huge changes since the code has already been written with the other ideas and objectives in mind.
Another moral to be learned is that just because you are the client doesn't mean that you shouldn't answer questions. For example, when the king has doubts that the builder can adjust the castle to accommodate what the kind has explained to the builder he should say something instead of trusting the builder. In the software world, if the analysis doesn't sound correct or the builder doesn't seem correct then the client should voice their concerns. More than likely, these feelings of projects going in wrong directions are usually correct and if the concern in incorrect there is not much at loss but a very minimal amount of time for discussion on this concern. Another moral is that the planning shouldn't be a quick affair that the client has not approved. The analysis should be a fairly lengthy process, with the majority of the time devoted up front and done at a careful pace. Trying to scratch these ideas up quickly will only result in incorrect documentation of what is desired in the application. One final moral is the idea that the king stormed off from the castle and didn't provide the builder with any compensation for the builder's efforts. This is true in all aspects of business. If the client doesn't receive the product that they desire then their will be resistance to paying since it is not what the customer wanted. Customer satisfaction is one of the most important emphases in a goods and services market and if the satisfaction isn't there, then the business could be decreasing its chance for revenue and making a profit. The software application analysis and development businesses must be sure to be cognizant of this as they work through all phases of the software development lifecycle.
These stories are adapted examples written in my class, IS 6840 (formerly MSIS 488).
© Vicki L. Sauter. All rights Reserved.