Over the span of the last 21 years, as a technology strategist, software developer, guest lecturer and management consultant, I have advised some of the world’s most powerful individuals, companies and organizations on technology matters. My principle aims have been to advise these clients on how to use and implement technology strategically, to foster greater organizational efficiencies, develop a high-performing innovation culture and achieve unprecedented revenue results. The culmination of my technology endeavors has resulted in successes throughout a variety of contexts; they have also resulted in many challenges and failures. The obstacles and difficulties that I encountered when implementing technology in multiple contexts is the experiential foundation that supports my litigation consulting services as a computer and technology expert through Thomson Reuters Expert Witness Services (TREWS).
Through my trials and tribulations of implementing and developing technology across multiple lines of business and geographical locations, I have learned much about technology and its interplay with the human condition. My experiences have allowed me to become intimately aware of the core fundamental aspects that are common to all technical deployments, as well as how they will eventually be received by the end users who will be impacted. One such commonality, which is the hallmark of nearly all software and hardware technology programs, projects and initiatives, is that of business requirements. Business requirements are the pervasive underpinnings of nearly all technical programs, projects and strategic initiatives.
I would like to briefly introduce the importance of business requirements in this blog. The relevance of business requirements and the method in which business requirements are captured cannot be overstated. The very essence of many civil litigation disputes that I have been involved in as an expert witness within the technology and intellectual property law area involve, to some extent, a thorough investigation of how business requirement gathering activities were executed.
Every organization’s technology system, program, project or strategic initiative is grounded in a series of technical requests that the sponsoring consumer or business has made to an in-house technologist or an external technology implementer. These requests can be complex or simple in nature. These requests can also be documented in a formal or casual manner. The collective body of all these requests is termed as “business requirements.” Although a running list of a business’s requests provides value from a historical perspective, it is of little value without being realized. The capturing and categorization of business requirements is just one of the initial steps needed for an organization to become greater. Routinely, the execution of business requirements necessitates the need to install or implement technology to address the organization’s needs.
Business requirements can have a variety of different sub-categories that further delineate what the requirements are related to. For example, business requirements can be divided into several sub-categories that are termed as “strategic requirements,” “functional requirements,” “technical requirements,” and “organizational requirements.” These sub-categories provide some prima facie detail regarding what the requirement may be related to; however, these sub-categorizations are only partially informative. Further detail is required for requirements with these sub-categories to become meaningful.
Fundamentally, these sub-categories segment the requests from the sponsoring business to the technical developers and allow everyone to compartmentalize the entire body of business requests into logical business requirement buckets. This classification helps the technical developers review, prioritize and program software code to address these business requirements. The end result is ideally a software application or technical solution that addresses the business’s needs and wants. However, in practice, there are several challenges that result in this process, which are heated points of dispute in many civil litigation cases involving software, hardware and other technology development initiatives. I know this first hand, because over the past several years, I have served as an intellectual property/technology expert witness in several complex civil technology and intellectual property disputes.
As a technologist, I was quite familiar with the issues that were being discussed and disputed in the legal cases that I was working on while an expert witness. Whether these matters were related to Enterprise Resource Planning (ERP) software applications, Customer Relationship Management (CRM) programs or hardware storage devices, I was very comfortable with the technologies at the core of each case. However, what became quite apparent to me very quickly, was how unfamiliar the litigators, arbitration judge and other interested parties, such as insurance companies, were of the technical issues that were at the heart of the disputes.
I found that the majority of my time on these cases was expended in educating the attorneys for the client that I was serving as the expert for, as well as the arbitration judge who was assigned to the cases. Although I enjoyed the process and it made for many interesting discussions that taxed all my mental faculties, the time and energy expended was intense.
To circumvent such long discussions in the future and to maximize the client/attorney and attorney/expert conversations, I decided to write primers about various fundamental aspects of technology that are involved in much civil intellectual property and technology law litigation today. My goal was to provide enough education that a litigator who is unfamiliar with technology concepts could, within 24 hours, be prepared to depose a technology expert on software requirements with confidence or defend their technology expert. So, something to keep in mind next time you’re an expert witness … it’s not just the judge or jury you need to explain things to, it’s also the litigators. And anything you can do ahead of time – whether it be something you’ve written or just links to online resources – can help maximize everyone’s time.
Nick H. Kamboj is the former Strategy Guest Lecturer at The University of Chicago Booth School of Business, where he also taught The Executive Program in Information Technology (EPIT) to CEOs, CIOs and other C-Suite Executives from 2004 to 2014. Nick has held management, leadership and executive positions respectively at Microsoft, Xerox and Accenture, where he implemented and managed technology strategic initiatives. Nick serves as a legal expert for Intellectual Property (IP) infringement and civil litigation cases, and has served as a frequent lecturer on technology strategy matters for the U.S. Department of Homeland Security. Nick has won numerous awards, including Microsoft’s Most Valuable Player Award.