“There is never time to do it right, but there is always time to do it over.”
This quote, known as “Meskimen’s Law,” makes the point that, so often, people are unwilling to take the time to follow a process or procedure that is well known to be effective because it is too time consuming or difficult. The ensuing result is often a failed deliverable in some form, requiring rework, often multiple times. Faced with this situation, we’ll often say, “If only we had done it right the first time…”
Too often, the requirements’ definition phase consists of conference room discussion and email chains with no formal documentation whatsoever. This can easily lead to a very inconsistent and incomplete understanding of requirements, and the requirements stage is arguably the most important stage of the effort. Without a solid and well-documented set of requirements, a successful delivery will be an accident, at best.
Requirements should be co-developed by IT and the business owner of the project, leveraging the business knowledge of the owner and the technical expertise of IT so as to allow for a deliverable that meets the business requirement, is well positioned to interface with other related systems, and is efficient to maintain.The Agile development methodology has become very popular in recent years and, although it can be tedious, the writing of “user stories” (short stories that describe in detail the functional requirements of the system — a hallmark of the Agile process) has proven very effective in documenting requirements. The development of these stories simplifies the estimation process for time and cost, allows for small testable system delivery increments and enables a better chance of on-time delivery.
Again, testing is a process that is often short-changed, thus requiring time consuming rework and frustration. Establishing a formal test plan and process, both for unit testing by developers and system testing by end users will save significant time on the backend by reducing rework due to missed or incorrect functionality discovered in production.
The activities described above take time, effort and discipline, but done well they will save far more time on the back end. They will also undoubtedly manifest a better result, minimize frustration and promote better teamwork in the long run. Think about Meskimen’s Law next time you’re ready to start a project, and don’t let yourself fall victim to this very common trap. If you would like to learn more about systems development or would like to schedule a consultation, contact Hartman Executive Advisors today.