Building 747s: A study of Traceability

Early in my career I was part of a project team that handled a variety of one-off projects.

The nature of the work meant that we were usually engaged mid-project and were expected to handle the Business Analysis and Project Management roles until project close.  We engaged in weekly team calls to discuss organizational goals and upcoming projects. 

“We’re building 747s in flight,” my manager would say proudly each time a concern was raised about how a project was to be handled.  

These conversations happened at a time before I identified as a Business Analyst and long before I had ever read the BABOK.  Even so, I distinctly remember wondering why these projects had to be done in flight.  Didn’t it make more sense to land the plane, figure out what we needed, start building, and then take off?

How did we get here? 

How did we get 30,000 feet in the air and not know where we were going?

I wish I could say those were the only times in my career where I was dropped into a project mid-flight with no parachute and the expectation that I could help build the plane before it landed or crashed, but that’s not true.  Whether it was through a new job, being brought in as an opportunity to organize what already exists, or simply realizing that the project in flight needs a BA, I have finished significantly more projects than I have started. 

When I am brought in mid-flight to a project I want to know “How did we get here?” When asked that way, I usually end up with blank stares or finger pointing as answers.  Instead, I’ve started asking “Do we have traceability for these requirements?”  This still gets me blank stares, but at least the finger pointing decreases. 

Traceability is the first task of Requirements Lifecycle Management, according to the BABOK.  The implication here is that not only is Traceability important, but it is the base on which all other tasks of the Requirements Life Cycle are managed.  So why does no one ever know if we have any?

Perhaps it comes from becoming a BA by circumstance instead of design.  Perhaps it’s because it has never been done that way before.  Perhaps it’s because the project team was so close that everyone was aware of all the requirements throughout the entirety of the project. 

---

---

Most likely it’s because people don’t know what traceability is and even if they do, it seems daunting.

Most things written about traceability are scholarly and technical.  They explain about numbering requirements and creating a matrix and documentation…It doesn’t need to be that complicated.

Instead, think of traceability as a list that needs to be checked at every step of the project, just like pilots have a checklist that they perform before getting in the plane each and every time.  They examine the plane from all angles, make sure all the equipment is working, and familiarize themselves with the plane before they ever leave the ground.  Even while in the air, the pilot is still performing checks.

Because most project I do are mid-air, I trace all the requirements backwards in order to understand where we are.  Sometimes the requirements may be as simple as “we need two wings”; or they may be significantly more complicated as we discuss thrust, lift, air speed, air pressure, and molecular structure of the metal.  Any project should have enough information that a BA thrown into it can use the checklist to review requirements during prototyping, solution design, User Acceptance Testing, and every other step of the project. 

Why is this important?

Imagine being brought into a project in flight, perhaps during UAT, and being presented with the fuselage of an airplane. The project was to build a 747.  Common sense says that airplanes have wings.  Looking through the artifacts, the original requirements say that the airplane should have wings.  The users were expecting wings. So why did the airplane get built without wings? How did we get here?  This is where the blank looks and finger pointing start.

But the truth is it doesn’t matter how we got here.  To move forward, the project needs to take some steps backward or the user is going to be presented with a half solution that requires workaround processes.  Either way, the end user isn’t happy and project deadlines are stretched because, along the way, someone forgot the wings and no one checked. 

In one instance, I was brought on to a project for which I was not the original BA, and was asked to sign off on test cases.  After evaluation, I determined there wasn’t enough information for me to sign off, despite growing pressure to complete this stage of the project.  The vendor with whom I was working could not trace the test cases to any of the requirements. Not only did I not write the original requirements, I couldn’t even find the original requirements.  Yet I was being asked if it was ok to move on to the next phase.  To have confidence in the next stage, I had to reinterview stakeholders, complete and organize information to provide a full picture, and review the test cases. The turbulence was manageable, but could’ve led to a crash landing. 

I did fly an actual plane once.  My instructor walked me through each step as I did it.  He told me how I was supposed to hold my hands, which gauges I needed to look at, and how to tilt the nose of the plane.  When he felt confident that I understood everything I was supposed to do, he let me fly on my own for a while before he instructed me in the last step of the process, landing.  Only when we were on the ground did he tell me that landing is the most dangerous part of flying.

With proper traceability, business analysis can be as easy as flying a plane.