![\"DoD\"](\"https:\/\/www.jamasoftware.com\/media\/2023\/05\/2023-05-18-digital-transfomation-dod-1.jpg\")
<\/p>\n<\/p>\n
Looking back on a technology career that started nearly 45 years ago gives me an opportunity to reflect on the evolution of technology trends. Most notably, for me, the usability and interfaces to that technology. Let me explain\u2026<\/p>\n
I started out as a young man in the Marines repairing and calibrating avionics equipment, and general test instrumentation. After boot camp (basic training) the Marines saw fit to send me to a half dozen electronic schools to learn my craft. Every piece of equipment I touched had a physical reference, and user\u2019s manual, but for the most part, if you knew what function a piece of gear was supposed to provide, you probably didn\u2019t need a manual very often. For example, if I knew how to use a Tektronix oscilloscope, I probably didn\u2019t need any instruction on how to use an o-scope from Hewlett Packard or Phillips. Just about everything I needed to know was obvious and accessible on the front panel (the user interface).<\/p>\n
Over the next 15 years that paradigm stayed relatively consistent. I would see different types of equipment, work on different \u2018things,\u2019 but it was rare that training or anything other than an occasional manual was needed to be productive. Physical interfaces tended to \u2018tell all\u2019 about what I could do, or what I needed to do with a piece of electronic equipment.<\/p>\n
It was about this time that I made a mid-career switch. It had become obvious (to me, at least) that software was going to be in EVERYTHING. Consequently, I went back to school for a Computer Science (CS) degree to help in gaining access to that world. With CS degree in hand, I took a position writing test software on a classified program for an aerospace giant. It was interesting at one level when I could see the end results of my efforts, but it could be laborious at times. I shared a large cubicle with two teammates, and we were heads down grinding on code for most of the day. I know some find this immensely rewarding, but I was not one of them.<\/p>\n
Whilst I knew this wasn\u2019t my calling in life, the introduction to a software development organization gave me exposure to tools supporting the software development lifecycle (SDLC). Disciplines like requirements management, configuration & change management, and architectural modeling. Plus, the software development process itself: Waterfall, Spiral, Iterative, Agile to name a few. The code may be the ultimate deliverable, but there are a lot of moving parts to get the code out the door. Of course, not every team believed in all of those \u2018other\u2019 disciplines: I had one teammate that had a sign over his desk that read, \u201cDocumentation is for wimps!\u201d I also remember a cartoon at that time that read something like (manager speaking to developers): \u201cYou start writing the code while I go upstairs and see if they have any requirements.\u201d<\/p>\n
I\u2019ve spent the bulk of the past 20 years of my work life supporting and working with Federal DoD programs \u2013 the large System Integrators, and direct with programs at military installations around the country. In that time, I\u2019ve seen the transformation of segments of programs\/projects being focused on a singular discipline (e.g., requirements, code, test, etc.) to the point where they are taking the big picture view; that systems and software development is really a team sport. Instead of each discipline developing their own assets\/artifacts and \u2018throwing them over the wall\u2019 the work is now being attacked in a cohesive and coordinated fashion. Essentially, a digital transformation where we\u2019ve gone from just ensuring that each discipline has tooling to support their own work, to the point where each segment of the development lifecycle prioritizes the ability to link and trace to the upstream and downstream activities.<\/p>\n
In the earliest of days of tracing assets across all disciplines the tool vendor who could supply an environment that supported all facets of development, and link those assets together had an advantage. However, over time, the end user became more sophisticated. They did not want to lock themselves into a single vendor with tools that were \u2018good enough,\u2019 they wanted a best-of-breed product for each of those disciplines.<\/p>\n
I think that\u2019s the primary reason that I\u2019m excited to be part of the team at Jama Software\u00ae. I spent 16+ years being that single vendor with tools that were integrated and were \u2018good enough.\u2019 Now, I have a product that arguably is the centerpiece of the most important of disciplines, requirements management. For without accurate requirements, on time, on budget, and meeting the needs of the end user (or warfighter) is a difficult undertaking.<\/p>\n
At Jama Software\u00ae<\/sup>, we support Live Traceability\u2122 \u2013 the ability to link and trace outside our domain of requirements, to the other best-of-breed tools that support things like coding, change management, architectural modeling, testing, etc. Jama Connect\u00ae<\/sup> does not lock you into a single vendor but gives you the ability to continue to use the products you currently have in your arsenal. Live Traceability gives your team the ability to see the most up to date and complete up and downstream information for any requirement, no matter what state of development it is in or how many siloed tools and teams it spans.<\/p>\n Being a part of the Jama Connect team has allowed me to work with the most intuitive of all tools in my career. When I say intuitive, I mean I didn\u2019t need any training to get up and running to be productive. Additionally, Jama Connect is a cloud-based product (self-hosted is also available), so no need to worry about getting your IT team engaged. If a Jama Connect project is properly set up, it should expose the bulk of the functions needed for a person working in the requirements discipline. Notice I did not say \u2018requirements manager.\u2019 Systems\/Software development is a team sport, and more roles than just a requirements manager\/SME will need access to the requirements. It is rather easy for a non-requirements person to access the tool, explore its functions, and be productive with limited or no training.<\/p>\n I continue to support Aerospace & Defense programs in my role at Jama Software. In addition to Jama Software offering a great requirements management tool, they are industry experts, and provide expert thought leadership and best practice guidance to their clients. This level of knowledge is a key distinguishing factor when searching for a requirements management tool. I am very happy to be part of this extremely energetic, client-focused company and truly looking forward to this next phase of my career.<\/p>\n <\/p>\n
\n<\/div>\n