Subscribe
Share
Share
Embed
In Series 2, Episode 2, we discuss the role of the Department of Veterans Affairs (VA) Technology Acquisition Center’s (TAC’s) Engineering Service Division in the acquisition process, as well as tips for developing requirements documents and much more valuable, technical insight.
Come for a peek behind the federal acquisition curtain as we gain insights from acquisition professionals at the US Department of Veterans Affairs and dissect varying relevant topics. In this five-episode series we will explore topics such as proposal evaluations, innovation, debriefs, and more!
TAC Talks is premiering Tuesday, September 29th!
The Department of Veterans Affairs does not endorse or officially sanction any entities that may be discussed in this podcast, nor any media, products or services they may provide.
[Music]
Charles Ross (CR): Welcome to the Technology Acquisition Center Podcast, which we affectionately call TAC Talks. Join us as we discuss highly relevant and compelling acquisition topics with highly esteemed industry professionals and attempt to share information with you, the 1102 workforce, program officials and our contractor friends. We hope that you find these topics and discussions helpful. So, turn up the volume on your ear buds and get ready for TAC Talks.
CR: Hello and Welcome to another Episode of TAC Talks! My name is Chuck Ross a Service Director here at the Technology Acquisition Center. And we have a great discussion for you today that I hope you will find informative regarding the role of the TAC's Engineering Services Division, in support of the Acquisition process. For those of you listening today who might not be familiar with the TAC's Engineering Service Division, I'll give you a quick overview of the important role that that division plays in TAC Acquisitions. Since we are the Technology Acquisition Center it follows that all of our acquisitions are related to the many and diverse technologies employed by the VA. These technologies include, but are not limited to, hardware, software, servers, data centers, software applications, cloud hosting and many more. Some software applications are things such as, conference reservation systems, mobile apps for Clinicians and Veterans, and Enterprise wide Financial and Electronic Health system records. The Engineering Services Division is here to provide technical support to these often-complex acquisitions. So, with me today is Jon Smolenski. He is the TAC's Engineering Service Director and today we are going to walk thru the role of the TAC Engineering Service Division. Thanks for joining me today, Jon!
Jon Smolenski (JS): Thanks, Chuck! As Chuck said, I lead the Engineering Services Division here at the TAC, which is made up of approximately 24 senior level engineers with significant experience spanning all different IT domains including Agile, Software as a Service, cloud Technologies, as well as Cybersecurity to name a few. My team is tasked with providing technical support to the TAC's Contracting professionals throughout the Acquisition Lifecycle. And specifically, focusing on the requirements refinement process, market research process and technical evaluation process. So in a nutshell, my team works with our business partners to build out their technical requirement documentation. Works with both contracting and the business partners during the market research process responding to technical questions ahh, and further refining the technical documentation and then act as technical advisors during the technical evaluation process. We're very unique in the sense, that we act almost as a broker
between the requirements owners and the acquisition teams to ensure that the requirements are well defined and ultimately lead to successful contract awards. My team offers many different levels of support ranging from working with Program Managers from the Office of Information Technology that are very well versed in their technical domains, provide really sound requirements to often times, supporting Clinicians in Medical Centers that know they need a certain type of technology or system and look to my team to help them build out the requirements so that vendors can understand those requirements and provide the appropriate and innovative solutions. What we do is not a perfect science it's more of an art which requires balancing the customers' requirements with the FAR regulations, as well as the acquisition strategy and contracting team guidance, to provide the most benefit to the VA and ultimately Veterans and their families. Engineering, solving problems you didn't know you had, in ways you don't understand.
CR: Thanks, Jon that's a great overview and it sounds as though like this is a valuable service that the TAC offers to its requirements community, differs a little bit from other contracting organizations throughout the Federal Government. So, these are actual Engineers that are in your division, correct?
JS: Correct. Most of them are either Electrical Engineers, Computer Engineers, or we have quite a few General Engineers, that have worked in previous Federal agencies, Army, ahh, other organizations that have supported programs at all different levels through their careers.
CR: I imagine this is a valuable service for the requirements community. Ahh, most of the TAC's requirements owners are Doctors, Clinicians, ahh, Programmers or Developers and quite frankly contracting is not their ah number one job function. So, when they have an acquisition and they need help with that, ahh, I imagine that being, that leveraging your division's talent ahh, goes a long way. So, with that, when a requiring owner has a requirement and they come to the TAC, what is the first thing that, that you guys do to work with them in the process?
JS: First of all, I just want to tell the listeners that not everything we talk about today is going to apply to every Acquisition. Each requirement is unique in its own way and is typically handled independently. The things that we're going to go through today are general tips based on lessons learned we've seen from over the years, that hopefully you can take back and maybe incorporate into your requirement processes. So, typically my division starts with supporting our business partners with elaborating the requirements documents. Since most of the time we focus on performance work statements we're going to focus solely on that for our tips today. Another thing we really do, try to do in the Engineering group is integrate ourselves with all of our requirement stakeholders, so we can fully understand where they're coming from and what their organizational needs are, what the IT needs are, to help us really to define the requirements. Through each of our support areas I'm going to highlight some tips
not only for our VA business partners, but as well as our industry partners who may be interested or already are working with the VA. I'm sure everyone is familiar with the saying to an optimist the glass is half full, to a pessimist the glass is half empty. Well, to an engineer, the glass is twice as big as it needs to be. So, we tend to have a unique spin on how we process requirements to help make sure we get the solutions that we need. Our first tip, that I'd like to bring up today, is we always need to make sure that we're writing requirements for our PWSs on a performance-based, ahh, process. What that means is we need to specify our requirements in terms of what a system or solution needs to do, as opposed to how we want it done. We really need to be careful to not over specify and limit the innovative solutions that industry can bing, bring to the table. For example, I need a system that will, ahh, ingest excel data, do some type of processing and provide me a bunch of dashboards uh that show all of the metrics that I need. As you can see, we're telling industry what we need done as opposed to how they need to do it. This will allow us to get innovative solutions back from industry and really gives the VA flexibility in choosing the best solution for the evaluation criterion for the requirements. So, we can have multiple vendors proposed for this type of requirement. One could offer to, utilize Microsoft Excel to do the work, another Microsoft Power Business Intelligence and another could use a Salesforce based solution. And really the, the flexibility we gained from what needs to be done as opposed to how is that we can really allow our industry partners to come up with very innovative solutions using cutting edge technology to really fulfill the needs of the VA. The next tip I would like to offer is that we're in a world now where we need to be very agile and in the past we tended to document every possible requirement uh, for not only the base year, but all of the out years as well. This is really difficult to do looking five years into the future for a contract. As quickly as technology changes and priorities change across the VA, this model wasn't proving to be extremely effective. So, we fully support the move to more agile approach to allow VA and industry teams to work collaboratively throughout the execution of the solution to rapidly adapt, change, reprioritize things like that. This approach also allows for these continuous feedback iteration loops with vendors and our customers to, to really get a solution built that's exactly as the end user needs. For example, VA wants a solution that modernizes an already existing VA system. By developing the requirements in an agile manner, you could really acquire a development Scrum team that would work continuously with their government partner in a very agile manner, constantly refining the ba, backlog items, adding in new backlog items, reprioritizing that list as time goes on, legislation may change. We can rapidly kind of pivot to make sure that we adapt and that our development team is always focused on what is most important to the government in the VA today. As opposed to, here's a list of the 20 requirements, please start at the top and work your way down, which is kind of how we did things in the past. So this, this approach not only gives the government and industry, uh a really, uh, a significant amount of flexibility to be able to adapt and continue to provide value added solutions and again, this approach may not work for every IT solution, but it's something that you can take back and discuss with your teams to hopefully uh, provide more benefit to the VA.
CR: Now, Jon have you seen a uh, an improvement in delivery and quality of product since moving to this agile approach for requirements?
JS: Good question Chuck. Uh absolutely, the feedback we've received from all of our business partners has been really, really good, uh, they have not only more interaction points with industry uh, as they go through the development process, but we're able to control more what exactly the focus is as we go through that, that development life cycle. Um, you know it does take a lot more uh manpower and resource on the government part to ensure that they are integrated with the vendor, uh Scrum teams and Sprint teams, things like that, but it also allows us to ensure that we're constantly moving in the right direction that we're meeting the deadlines, the milestones, and the deliverables of each of those acquisitions. Uh, but as I said, uh I think it's been overwhelming the amount of praise we've received from our customers moving to this type of approach because they are getting better systems and better solutions uh, for the VA.
CR: We could probably do an entire podcast on Agile uh, contracting. Uh, I know one thing that I've noticed is that em, you know you're able to determine points of failure earlier on in the development process I believe as opposed to the old waterfall methodology and, and just that, in and of itself provides much value to the VA and controlling costs and you know not going down the entire contract before you realize uh, a point of failure. Do you have any other tips that you want eh to mention?
JS: That, that was a great segue into my last tip, Chuck. So, my last tip really focuses on being sure to include checkpoints, deliverables, tied to the payment schedule. In the past, we've seen cases where an acquisition would be awarded, and really there was no involvement or status until the deliverables came due whether that was six months or twelve months down the road. And at that point it's kind of late to go back and change things. So, coupled with the, the, new Agile methodology that we're moving forward with, coordinating with our contracting teams and putting eh deliverables and milestones in place that tie directly to pricing. It allows us to really have checkpoints, as you mentioned, to monitor progress, make sure we're on track meeting those milestones and goals for whatever the solution may be. Uh, uh you know an example uh, I worked with a customer in the past on a technical evaluation and we were walking through the deliverables and he was telling of a previous experience that he was very unhappy because his customer or I'm sorry his vendor provided him the deliverables and they weren't exactly what he wanted. Uh, unfortunately, you know the way the contract was structured, that was the deliverable, the vendor was done, and they moved on to the next segment. So, we kind of kicked around some ideas for him talking about possibly getting draft documents uh 15, 30 days in advance to allow him and his team to review the progress, review the substance, in the context of those documents. Uh, that was something that he was really excited about. We applied that across the board in his uh, requirements document and followed up with me months later, saying how much it improved not only the deliverables he was getting and the output, but also the relationship with the vendors. It was much more symbiotic relationship. They communicated a whole lot more to make sure they were both on the same path. And uh, honestly, you know, we try to apply that same type of concept across all the requirements that we process here at the TAC.
CR: Very good. Uh, now I know there's quite a bit of, ah, involvement with your team in, um, monitoring any ah, changes to industry or the current market trends and that you guys are involved in um the RFI process and it seems as though a lot of RFI's, Requests for Information, ah they get issued. Ah, what is your role with supporting the contracting team and the customer when information is received as a result of those RFIs?
JS: The RFI process is extremely important, like you said, identifying what possibilities are out there, what vendors can perform the work and get a lot of feedback for how we're doing with our requirements development process. So first, my team will work with the customer, to identify questions to ask of the vendors. So, we already have our requirements document in shape that we think is appropriate to go out to industry. Next we come up with these important questions to, to not only gather technical feedback, but to also identify areas, the gaps we may have been missing, items we may not have thought about, new technology that may be in place, that we can take back and address if it's appropriate for the requirements. So we, we do all that working with the customer, getting the questions answered, er or actually get any questions written and answered, and then, once we receive the feedback from industry, processing it answering the questions, rolling the feedback into the requirements document, if necessary, ah and ultimately supporting contracting, seeing if uh the acquisition strategy we have in place is appropriate. So some of the tips that we, uh, from a lessons learned that we've had in the past; again, these are both for VA and industry, and one of the most important areas obviously is asking the right questions within the RFI. Oftentimes we assume we already know the best solution when we're writing the requirements document, and, and, you know we haven't necessarily engaged industry and seeing the new technology and what's available. Um, but then we realized once we see the feedback from the RFI responses, that there are more innovative solutions out there. And taking that feedback, building it back into the PWS, whether that's a shift in mindset or direction or requirements or just tweaking little bits here and there uh to get to the same goal. It, it's really the critical piece of this. And oftentimes you know the questions ah that we ask, are not necessarily as specific as we would like. So, we really tried to work with our customers to get very specific ah hard hitting, impactful questions and a, a few questions uh just to give our listeners an understanding of what I mean. So please provide your methodology for incorporating user centered design into your developmental approach. So, we're not just asking what their approach is to a certain task. We're really looking at what is their user centered design approach within the overall development process. How do they communicate and collaborate with the end users, and how do they take that iterative nature of user centered design and roll it into their development process and hopefully, by being specific, we can pull those pieces out.
Another example would be, please provide your summary of your experience with testing in a DevOps model, including continuous testing and automated testing. And again, you know, we would like their overall approach for testing, ah but specifically focused on continuous testing and automated testing, which are very important to the VA. A few other examples, uh describe your experience and expertise with VA modernization initiatives such as EHRM or FMBT. So specifically, we're looking for vendors work with programs that in the past you know and how they plan to support us on this requirement. Ah, we can see the level of involvement they had and the, the technical portions that they've worked on. And then lastly, is there anything described in the PWS that may be driving costs higher than needed for successful completion of the project? So, this is not necessarily technical in nature, but we're trying to highlight areas that a vendor or an industry may possibly think would prohibit us from being successful. So, are there items within here that could be significant cost drivers that we may not have understood when we first wrote the requirements? And again, we, we take all the feedback we get from industry very seriously. We, we ensure that you know we're doing our due diligence with our requirements to make sure we're fair and consistent and that we do, do the best, uh best effort for the VA to get the best solutions. So those are some specific questions, ah, to, to get the answers that we're looking for and really the RFI process, with what the feedback we receive really helps to drive the acquisition strategy.
So, one other thing, we are always sure to ask if the vendors think there's anything else that could help us provide a better, more complete solution. Oftentimes, there's things we overlook, because, again, we feel that we've done this in the past, and maybe we know the appropriate path forward. But there's always things out there that to be better, make better requirements and ultimately make better solutions. Not only is it gonna help bolster the requirements, currently in the PWS, it's going to address gaps that we've overlooked. Ah, so the feedback mechanism to me is very critical ensuring that we have clear, concise, and complete requirements before we go out for the solicitations.
CR: Very good. Now John, my experience with engineers is they ah they like to work with the product, they like to test it out, they like to kick the tires so to speak. And I know demos are something that a lot of our engineers like to employ into the acquisition strategy, ah when they're working with the customer. Ah, what are your thoughts on demos and ah, do you like them? Or do you see them as ah, do you see any roadblocks with them?
JS: Absolutely. I, I think the more of the technology that we can see prior to contract award, I think the better. Ah, if industry comes to the table and they have innovative and unique solutions that can fill a need, a need that we haven't necessarily thought of, we're, we're all ears. I think the more as technology rapidly continues to change ah, or you know, pretty much all SaaS-based now, cloud based, uh these types of technology have, have rapidly proliferated in the last few years, and seeing all the different types of software now that is, uh you know, in the cloud, different ways of using that software, interfacing and interacting with it, I think are all really critical. And not only does it help us build requirements and solutions for the acquisition we're currently working on, but it helps to educate the team in general. You know, as I said, technology is changing so rapidly you really have to stay on top of the trends to make sure that you continue to be a subject matter expert and provide value added to an organization like the TAC.
CR: Great, and we know, or those of you that might not know uh, the TAC was initially brought together as a result of the base realignment and closure at Fort Monmouth, so there's a lot of engineering expertise that came over to the VA from uh, the Army and uh, a lot of those engineers have years and years of hands-on engineering experience that uh they're leveraging. But it also sounds like there's more to the job than just having an engineering degree and some, and some experience. Uh, it sounds like the engineers really need the ability to communicate well orally and in writing. Uh, what are some of the qualities that you're looking for uh in engineers to uh, staff the TAC engineering division?
JS: Great, great question. Uh, as you mentioned, I think most of the engineers within our group have significant number of years uh experience. They've all been in charge of either groups of other engineers or large programs, uh very cutting-edge technology. Uh, things I look for: being proactive, being able to communicate, understanding the technology and really a thirst for learning. Um, you know, this is one of those fields that you can't necessarily sit back and pretend you know all the technology, you really have to be active in staying up to date with current market trends and technology trends and where industry is going, where the Government and the VA is going, and making sure you can translate all of that tech speak so that as a contracting office uh we can provide the best contracting to uh get the best solutions for the VA.
CR: Great, well that's a little plug for maybe some future announcements that uh the audience might see out there for the TAC engineering division, but um I think that's uh, very important because uh, we do have a really great engineering group, but uh they also are uh, getting in the years of experience where uh there will be some openings here, at the TAC.
JS: One last tip, before we move on from, from the RFI stage uh more for industry than our internal VA partners, I would highly encourage everybody listening to please uh stay away from providing broad capability statements and marketing literature uh when you respond to the, our RFIs. Try to be very specific in your responses to the requirements and the questions we ask uh because everything you provide back; we really take to heart in trying to develop the best requirements we can. Please be as innovative as you can in your solutions. Question why we're doing certain things uh, and really try to give us your perspective, benefits and disadvantages of the approaches so that we can take all that back and really come up with the best solution possible.
CR: Alright great information Jon. Let's get back to the acquisition process. So now that the RFI results have been analyzed, and the customer and contracting office are trying to develop the acquisition strategy and how they want to evaluate the proposals, um can you share some tips on creation of the evaluation criteria, and the engineer's involvement with that?
JS: Absolutely, and to me Chuck, this is probably one of the most important stages and critical stages for our involvement in the entire process. Moving into the technical acquisition lifecycle, we're going to go through some tips now for our internal VA customers, as well as our industry responding to the solicitations, and really the first step in all of this is developing evaluation criteria that are very impactful and specific. Often, we as the VA, tend to ask industry to respond and provide approaches to all the task areas in a PWS, which really restricts how they can respond. We have page limits. We have things like that. It's just, it's, it's not appropriate. For example, providing a 10-page limit and asking industry to provide detailed responses for a complex IT solution requirement is not going to allow them to really detail their innovative solutions within 10 pages. So, we really need to be mindful of things like that. It's not only going to create more work for us as an evaluation team to try to understand what they're providing, but also is going to greatly prohibit them from really focusing in on the, on the details in the requirements, giving us those innovative solutions and demonstrating that overall benefit and value to the government. So really, coming up focusing on the critical elements of your requirement and using those as the basis for your evaluation criteria. That's probably the best tip I can give as far as developing evaluation criteria, focus on the pieces that are really going to make the biggest impact for your system, or your solution, or your product, and that's where your evaluation should center around. And again, this is, you know, it could be just a written volume as you're uh you're looking for responses to a written volume, or it could be evaluation criteria for a demonstration or a code challenge or some other type of in person, uh innovative evaluation. But overall, really try to be as specific as possible to really get the most bang for your Buck.
CR: Great! So now the evaluation criteria is determined, solicitation is issued, uhh TAC engineer's role is finished, right, or not so?
JS: Not quite yet, so our, our group really eh acts as advisors to our customer technical evaluation team, so we really embed ourselves with our customers to ensure that we are getting the most value for the VA and, and so that we can enforce all of the contracting eh strategy that we put in place, making sure we're tying things back to the evaluation criteria and kind, just ensuring that everything is going the way it should and is appropriate. So first and foremost, some tips for how industry can respond better to our solicitations. So really, we, we, these are all based off of lessons learned that we've seen in the past ten years. Read the instructions very carefully to really understand what the VA is expecting from your submission. We as part of the solicitation we include deadlines, page counts, font sizes which all can have a significant impact on your proposal. We've had many, many cases where the deadline comes, we receive uh proposals after that deadline, and unfortunately, we can't use them and evaluate them at that point. So, we highly suggest trying to submit your proposals early, ensuring that the systems work uh and if not, reach out to the contracting team to make sure they are aware of it. If, if it's an internal issue to really get those uh proposals in on time. Additionally, if we ask for 20 pages, please submit 20 pages. Uh often times we get 25-page proposals the last five pages have to be truncated and we cannot evaluate them as part of the submission. So, often times we lose some really key elements of an offerors proposal because the instructions were not followed. So that, that would be my first tip, make sure you read and really understand all of the prop, solicitation direction and if not reach out to contracting team so that you can understand it better. Secondly, and, and really this is uh, to me the most important tip I can provide for industry responding is to be sure to address each and all of the evaluation criteria in the solicitation. Uh we we've had some really good proposals over the years that give us really detailed, highly effective, super innovative solutions, but then they completely omit responding to one of the evaluation criteria and depending on the acquisition that could make you deficient, which would immediately uh, prohibit you from winning that acquisition. So really focus on addressing each and all of the evaluation criteria. They are all very important uh, that's not to say you shouldn't address anything else in the, in the requirements document because there are other areas that you may provide uh, some significant benefit. But really the focus is ensuring that you address each and all of those evaluation criteria. Uh, and eh honestly, it's difficult sometimes uh, because there are page limits and restrictions and things like that, so you are forced to really pack a powerful punch with your solutions into small uh page, counts to ensure that we understand what you're doing um and again, tying back the overall understanding of the problem and feasibility really goes a long way. So, as you go through the evaluation criteria and address each of those, the more detail and the more you can demonstrate that you understand the problem of the requirement and show that, your, your approach is a highly feasible approach that will go very, very long way for the evaluation.
Next, we'll talk about past performance. This is another thing that we see quite often that ah we, we struggle with. So typically, it's stated in the solicitation, ah past performance evaluated separately from the technical volume. So, when we evaluate proposals, we see often significant portions of those proposals that highlight their past performance, how they've worked with certain technologies in the past, or how they've developed solutions for other organizations. But they don't necessarily tie back to the requirements for our acquisition that we're currently working on. So, to us, that that's past experience. You haven't really demonstrated that what you did for these other organizations and other systems you're going to do for this requirement in hand currently. Ah, so we would ask that you be very specific, you can still document what you've done in the past, how you did it, but you really need to tie those items back to the current requirement. Ah, and, and that is super, super critical because it shows that again, you not only understand the problem, what's being asked ah in the solicitation, but that you, you've already demonstrated you have a feasible approach and you're going to apply it to the current requirement. Ah, that that is very important, and, and like I said, we see this all too often and it's tricky, a very tricky area to evaluate. Um, if, if you just tie back then you'll really be showing that you understand ah the approach and you have a feasible solution.
Another critical tip that I want to highlight was, oftentimes we see responses that are very generic in nature they contain textbook definitions, or really, they just regurgitate the government's requirements back to, to ah, the evaluation team. Um, almost all of the technical evaluation teams are really comprised of subject matter experts. Ah, they can see this language from a mile away and not only does it show that maybe you don't fully understand the problem, um, but that you didn't spend the time to, to really detail your innovative solutions, ah, for each of those requirements. So, we would just ask, be specific, provide enough detail ah so that the evaluation teams can really understand your approaches, and providing a table, this is another area that we see quite often. We get a table that shows all the government requirements and really it's just a checkbox table that, that's not demonstrating to the evaluation team that, you know, you really fully understand the requirements and that you can provide a feasible solution. So really spend the time. Make sure that you're, you're bringing something beneficial to the table in meeting each of the, the requirements and addressing each of the evaluation criteria. It, it will not only make your lives a lot easier, but it also makes the evaluation go much, much more smoothly. And then just, just a couple more tips to wrap up. Uh so, often times in technical volumes we see they contain significant portions of marketing material. While this, this is good, and we understand where industry is coming from, you want to showcase what you've done, what you're capable of doing. It oftentimes takes up critical space that really could be used for providing more details in your solution. Uh, so kind of coupled with the, the tip I gave before. Really tie back that experience in those capabilities and that functionality, tie it all back to the current requirement. Showcase how what you've done in the past, what you're capable of doing, can really meet the solution that we currently have at hand. Another important tip be consistent. We, we, we understand that uh all of our industry partners have uh, unique structures, and it's not necessarily one individual that's writing the proposal. Uh, please ensure that someone goes through for consistency. We've seen a lot of cases with contradictory statements, uh, and it really puts the evaluation team in a difficult position uh, because we don't necessarily know that you understand the requirements if we're seeing two different uh directions on the same uh, type of requirement of the same type of response. If you're not sure uh, with assumptions, another, another important area, uh, don't make uh, an assumption, because if it ends up being invalid, then the entire proposal is probably going to be invalid. Uh, if there's something you're, you're not necessarily sure if you should go down the path for in responding to a solicitation, reach out to the contracting team, try to get clarification beforehand. Uh, don't let that bad assumption lead you down the bad path.
CR: These are really good tips Jon. Uh, so um, before we let you go today, we're going to the mail bag. This is from Elizabeth and she's from another government agency and uh, she's asking, uh, I think she's a program manager with another government agency, and she's asking if there's any uh, good training that you would recommend out there to uh, stay sharp on um, you know, digital acquisition or um, it looks like DevOps type uh, requirements development?
JS: I mean there, there, there's a wealth of knowledge uh, just being able to look at some of the resources that we have available to us on through the Internet, uh, YouTube, uh, Pluralsight as a training tool. You know, obviously Learning Tree and a lot of the other training sites that have been around for a long time, they really stay up to date with current market trends and technology trends. Uh, so seeing what kind of modules and training they're providing is, is a good way to keep pace with what technology is doing. Uh, again, it, it really comes down to what your organizational needs are. What your group needs are. Um, as our engineering group, for example, uh, we tend to canvas our engineers to see what they're seeing as far as market trends and technology trends, and then we reach out to see what vendors can provide training for those different types of solutions so that we are constantly up to date with what's going on. and can provide the best services possible. You know there's a wealth of resources out there. Uh, there's numerous sites uh, that, that can give really, really good overviews and detailed instructions on you know what Dev OPS and Dev SECOPS are, how to implement them in your organization, and can really give you a methodology for deploying something like that if you'd like to do that. Agile methodology, same thing, user centered design. Uh, those seem to be really the big focus areas now for us that our customers are moving into with the requirements. And, and honestly, they're, they're, they're really critical and they really boil down to communicating, collaborating and, and really being proactive.
CR: Right and from a digital service perspective, I know you're uh, engineers are uh, most of them, if not all of them have their DITAP certification. And I know for a fact that TAC uh has a large percentage of its contracting employees with DITAP certification as well. So, that is always something that Elizabeth, uh, if your agency offers that, that you could pursue.
JS: Absolutely, and you know really as an engineering group, to kind of wrap this all up, we really strive to ensure that we as the VA have provided enough information in detail uh, through our requirements technical documentation to allow vendors to really come in with their innovative solutions. You know, we know there's a lot of time and effort associated with responding to solicitations and RFIs, and we really do our best to kind of, streamline that process uh, to do the best we can for the VA. Um, you know, we're always looking for more efficient and effective ways. Uh, we appreciate the feedback we get from both our VA and industry partners. Uh, and really, I just want to thank everybody. And if you have feedback, please reach out. Uh, we, we'd love to hear what you have to say.
CR: That's right. Um, we'll close the mailbag for today, but if anybody out there has questions for us at TAC Talks, feel free to email me at Charles.ross@va.gov. Jon, I want to thank you for being here today with us. Um, I think it, really gave a good overview of the, the valuable asset that the TAC provides to its customers um, in the Engineering Services Division. Uh, so with that said, um, I appreciate all of our listeners out there once again, and uh feel free to uh, email us, like I said, with any questions that you might have for our next segment. And until then, please stay well and uh, I hope you enjoyed this episode of TAC Talks.
[Music Outro]
CR: As always, we must remind you the Department of Veteran's Affairs does not endorse or officially sanction any entities that may be discussed in this podcast, nor any media, products, or services that they may be providing. We thank you for listening to this episode of TAC Talks and hope you found it helpful as well as enjoyable. You may direct any questions or feedback to me, Chuck Ross at charles.ross@va.gov. And remember, if you are passionate about government acquisition, are a continuous learner and enjoy fruitful dialogue then keep tuning into TAC Talks.
[Music]