Dates are important. Without dates how can anything be planned? However, due dates have been know to increase in importance in the delivery of software solutions. Sometimes the due date becomes such an overwhelming creature of importance that the date is more important than following best practices, more important than verifying that what is built is correct, more important than the solution team gaining a proper understanding of the work they are attempting to perform. There are situations where dates are declared as met, yet the successfully met date includes a delivered solution that is not sufficient for its intended purpose. In reaching such a cognitively dissonant circumstance, lines have been crossed that should not have been crossed. For some intangible reason, it often seems that as those lines are approached it is voices from the data design or database management group that are the ones pointing out to peers and managers when things have seemingly lost touch with reality and the amount of tasks to be done have exceeded the amount of time left before a due date. Within organizations, these database folks are often viewed as the "purveyors of doom." Perhaps it is something about the job, or simply about the mentality of those who fall into such lines of work. But while others might broach such a subject, likely it first will pop up from the mouths on the data-side of the efforts. Likewise, it appears that many developers believe they can complete work more quickly than they actually do.
Projects consumed by a due date often follow a similar pattern. First, corners are cut; there's no time for documentation; testing is diminished; then work-arounds are established to get functionality in place. There is mention of things that will be addressed in a second release; but as items are added to that second release, no one is actually documenting those proffered tasks. Next, even though signs of time slippage exist, project managers take an optimistic view, perhaps even convincing themselves all really is well. Finally, a lawyerly game of semantics is embarked upon. Words are parsed very carefully to point out to users that everything is well, and even if things are missed it is simply as expected. If it was not spelled out explicitly in the contract, or requirements, or whatever document was used, it's simply too bad, it will not be there. Language is an ambiguous tool, and when sought specifically ambiguity is easily found. In general, sticking to the "letter of the law" might sound like a good practice, but the problem that often occurs concerns vague, gray issues within the requirements that ultimately prove most vital to successful functionality.
Yes, dates are important; but saying that a date has been met should literally have value and meaning for everyone. Sadly, few organizations are proficient at accurately estimating and few organizations are skillful at effectively managing project scope. Until organizations can take pride in their estimating and scope management, they should be careful in contracting project work. Either there needs to be a reasonable amount of float for any delivery dates, or else there needs to be a means to time-box deliverables so that one is not endeavoring to force ten pounds of stuff into a five-pound bag. Customers and solution-providers each need to be successful. Success can be achieved by working realistically towards the desired outcome, not parsing requirements language, pointing fingers, and looking to assign blame. Harsh black-and-white contractual scenarios only work well when little ambiguity exists. Recognizing the pervasiveness of ambiguity and allowing flexibility in aspects of solution delivery are crucial in establishing a successful customer engagement.