“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…”
Procedures, formal processes, best practices or whatever you want to call them, exist for a reason, and that is to facilitate getting things right the first time. Few would argue with this from an intellectual perspective. However, time and time again, we see organizations shortcut critical steps in the systems development life cycle – requirements definition, system testing, change management, post implementation review, etc. – and focus almost exclusively on coding and production roll out. Despite the number of times that this manifests a poor result, we keep doing it. It is important to invest in these critical steps in the systems development life cycle.
- Thoroughly and formally document requirements. 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.
- Develop a formal unit and system testing process. 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.
- Develop a formal change management plan. Change management, depending on the complexity of the change, consists of communicating the change (reason for change, benefits, what to expect) prior to implementation, formal training to the extent required and post implementation follow-up to ensure customer satisfaction. We always encourage development teams to take post implementation review very seriously. The job is not done until the customer says it’s done per the documented specifications. This is why Step 1 of documenting requirements is so important. If the requirements and expectations are not well-documented, customer dissatisfaction is a real possibility.
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.