Mind-Reader - people who develop database/systems are not mind-readers. They need clear, concise instructions and definitions to develop the system how the client wants.  A lot of time, prototypes are presented or detailed examples of desired inputs and outputs, as well as detailed processing instructions.  This makes development easier for the developer because it takes the guesswork out of the process.

Co-designer - in many cases, if not all, the people who want the system designed act as co-designers during the process. They can sit with the developer and help guide the design process how they want it.  When the developer is given simple/cryptic instructions and then left alone to design the system on his/her best guess, the results are usually not in the best interest of the client.

Scheduling - because of the time constraints put on both parties, if dedicated time is not set aside (usually 2-4 hours per session), then the development process seems to drag on because the developer creates something close but not exact, then parties have to meet to discuss the tweaks. It sometime seems to turn into a spiraling vortex and dragging on and on.

Also, waiting on other parties for input or feedback who are not readily available, can cause delays and design snags not anticipated.

Changing of the Scope - many times, because the client sees what a good designed system can do, many other things come to mind what they want the system to produce. This not only causes twist and turns in the development process but can cause design snags that slow up the process.  Once the system is designed and new things come along or changes to the original scope, the design has to modified from the original to accommodate the new items.  This obviously wastes the time spent on the original design.

95/5 Rule - Usually, the major part of system design takes as long as the last items because of the complexity of what is desired towards the end of the process. Because every system is custom designed to the client’s specs, their end product is not a copy of other client’s system and must be developed almost from scratch.

Unfamiliar with the Development Process - people who don’t develop for a living may not realize that the developer designs to predetermined set of steps. This is done for a number of reasons - to make it easier for the end-users to follow in case they need to make changes after the developer is gone, to make it easier for other developers to understand the design in case something happens to the original developer, etc.

Many times in the development process, the developer must create sub-objects as a basis for the main objects. This can be tedious and time-consuming but must be done similar to building a good foundation for a house.  And if the scope changes for whatever reason, the objects have to be modified from the ground up, wasting valuable time.

Unrealistic Deadlines or Commitments - A lot of times, clients want the perfectly designed system and they want it yesterday. Because the design process proceeds in a systematic manner, many times a man-made deadline is difficult to commit to because of all the issues stated previously.

So developing a system is much like building a custom-made house. Unless detailed, precise design specifications and processes are provided, then the client will be at the mercy of the developer’s best guess.  If the guess is close but not completely accurate, then a lot of time is wasted in tweaks, updates, additions, changes, etc. before the final product is ready.