Endorse Maximize your ROI, minimize your project risk Consulting
Due Diligence Is Not Just For Lawyers
A dictionary definition for the phrase due diligence is defined as “The care that a prudent person might be expected to exercise in the examination and evaluation of risks affecting a business transaction”.
Most of us do not have “Esquire” appended to our names but that does not exclude us from performing our due diligence in our work regardless of the profession. We know that a lawyer, an accountant or a surgeon requires a fair degree of due diligence. Can you imagine a surgeon who is working on your brain to remove a tumor and slices into the left side of your scalp when he should have done so to the right? That’s when you need a lawyer!
So how does due diligence apply to the rest of us folks? Well let’s focus on a new application that is in its final stages in the development cycle and is expected to be in production shortly.
System Test seems to be going well. Only a few serious bugs have surfaced and a small number of insignificant bugs crept in as well. Things are looking good as far as the schedule is concerned. Your testing is now complete and the stage is set for the users to begin their acceptance testing before rolling the application into production. Your project resources are now earmarked for the next project in the queue.
Everyone is all smiles as the user phase of testing begins with a high degree of confidence. As your users begin to exercise the system, their smiles start to fade. You wonder is the room temperature too hot or too cold? Being attentive to their needs, you inquire how the testing is progressing.
When you approach your lead client who looks puzzled, she asks you how they can re-sequence the data under different scenarios. You return the puzzled look asking for more of an explanation. Being the clever person that you are, you quickly realize that what is being asked for is not part of the system. You very diplomatically convey to your client that the functionality mentioned was not part of the initial requirements. Your client reaches into her bag for a copy of the requirements and quickly flips to page 19, paragraph 2. Red faced and feeling a bit warmer than usual, you say “I’ll get back to you”.
So what does this have to do with due diligence? Here is the definition once more; “The care that a prudent person might be expected to exercise in the examination and evaluation of risks affecting a business transaction”.
In the early phases of the project you may have to ask your self if due diligence was exercised. How or why was this requirement overlooked? Are there other requirements that are missing but have not surfaced yet?
The recovery but at what price Humans make mistakes, right? This is why they put erasers on pencils (no help for the surgeon though). The task now is how to incorporate the missing functionality and get the application ready for production as quickly as possible. You now face a real dilemma since your budget was not expecting a “maintenance” cycle so early in the process plus your resources are already slated for the next big project.
Management wants to know how the functionality was missed as well as what the time and costs are to remedy the situation. Your root cause analysis determines that the business and technical requirements were reviewed; however, there was never a traceability effort to see if they were aligned with each other.
It becomes apparent that due diligence was not fully exercised in the review process. Checking requirements for ambiguity alone is not enough. Traceability of requirements from project objectives to project goals, down through the technical requirements which leads to the detail features is one sure way of ensuring full coverage.
The Requirements Traceability diagram (below) displays how a project's requirements from the objectives down through the lower level detail may occur. Notice the red circle with a question mark. This indicates a misaligned set of requirements; specifically a Business Requirement with no corresponding Technical Requirement which is the scenario in the above case.
Now that you have determined how the requirement was missed, what will this mishap cost you to recover? The chart below represents the different development phases and the skill sets required for each phase. You will notice that the first phase Requirements has involvement from just the Business Analyst and the Project Manager.
The missed requirement was found in the User Test (1) phase which involved the entire team. To implement this change, it will require your team to go back to the Requirements (2) phase and repeat each of the phase steps that follow to bring you back to the point of fault detection. This will most likely set your timeline back a number of weeks and wreak havoc on your budget. You can probably forget about scoring points with your client too.
Looking to the future, you incorporate requirements traceability as part of your best practices. Now, a hypothetical situation appears in your next project. During the requirements review, a business requirement was found to not have a corresponding technical requirement. Eureka! You’ve just found a potentially damaging flaw early in the process where the only resource impacted is the business analyst. Quite a contrast to the earlier example which affected the entire team let alone the budget and timeline.
Ken Pohl is the president and founder of Endorse Consulting which specializes in minimizing the risk to a project’s ROI by mitigating potential problems before they arise. His many years of developing and implementing data warehousing, business intelligence and CRM systems has provided a wealth of knowledge as proven techniques. These techniques translate into real world not from a book “best practices”.
