Maintaining traceability is hard, but someone has got to do it. Wait…
Why? Who says?
Well, for one thing, you might want to know if the eggs you just put in the fridge last night came from that batch that you just heard was declared infected by salmonella. Or maybe you don’t care so much and just throw the eggs in the trash. But what about the state’s emergency preparedness? They’d like to know where those eggs were sold and have the hospitals in that area on alert with additional personnel… no?
The concept of traceability comes in many flavors depending on the context in which it is used. Often, that concept is expressed through other words. Let’s think for a second about genealogy, ancestry, and pedigrees. As an individual, we carry a genetic, a social, and a cultural heritage and those links to our genetic lineage, to the country we grew up in, or the family and social dynamics we experienced in our past are determinants for who we are today. Disciplines such as psychology utilize these links to help us understand who we are, how we function, and most importantly, how to leverage all this information to our advantage, today.
Since IT is such a big part of what we do, let’s look at traceability in that domain. It starts with an organizational need that IT can satisfy. We involve users to get their requirements and understand what we need to build. There may be many layers of decomposition of these requirements, and many layers of integration of IT components, depending on the size and complexity of the IT solution. Eventually, we deploy the IT solution onto an operational network, but not before it passes testing.
One of the questions that testing answers is “Does the IT solution do what it is supposed to do?” and the answer to that question comes in the form of a traceability matrix (of some sort) that shows the link from the original user need, through its decomposition into smaller and smaller chunks (the downward branch of the “V” in the diagram) and how each chunk fared in testing (the upward branch of the “V” in the diagram). In other words the “V” represents the trace and it’s how we know how well the IT solution satisfies the need.
Now, you may have heard that all too often, an IT solution has already missed the mark by the time it’s delivered and that consequently, traceability is not needed; but that is simply not true. There are other mechanisms that allow us to embrace change and still know and understand exactly what we are building while being agile! That will be another article.
Another area where traceability is essential is in establishing the link between the strategy set forth by an organization and how well the organization is executing that strategy. In the federal government, there are many layers of communication and management between the legal mandate handed down to an agency by congress (or the president) and the government employee facing the public. And the methods used to ensure that each federal employee has a clear role in executing the agency’s strategy and is held accountable for his work, have no standard to abide by and vary greatly with each agency.
How well the original legal mandate gets implemented by the agency has become increasingly questioned and so it should. As we witness aberrances in how taxpayer money is spent, whether it is needless travel, stockpiling supplies with “use or lose” money, or duplication of work, we are increasingly aware that something is not working right. And so are various government watchdog organizations such as GAO, OMB, OPM, and some of the OIGs in various agencies.
Clearly, and quickly, we must think about what innovative approach we can come up with to ensure that the Executive Branch agencies are indeed executing the legal mandate they are responsible for. Could the solution be really as simple as traceability?