In his presentation at Prodacity, Jonathan Mostowski, a seasoned expert with over 20 years of experience in government acquisitions, shares his extensive knowledge and practical insights on modernizing and innovating in government procurement processes. If you are involved in government contracting, acquisitions, or are interested in the intersection of technology and government processes, this video is a must-watch!

Jonathan Mostowski (00:09):

Okay, we're going to go ahead and get started. As I said, for those of you who just walked in, I have some slides because I was made, it was required, so that's why there's slides. So I don't care if I don't get through them. Please feel free to interrupt if you have questions, I'll repeat them because I think we're got some viewers from outside the room. But other than that, I'll just start off with a little bit of introduction, a little bit of an introduction just for credibility's sake.

(00:34):

So I've been in this game for about 20 years. I was a contracting officer at the National Geospatial Intelligence Agency for a little over 13. We were directed to implement Safe, be Safe. Nobody really knew what it was, but they were certain you couldn't do it under the federal acquisition regulations. I owned all the application service contracts, and so it was kind of my job to figure out how to do it, and I did after a lot of failed attempts like Edison, I guess, I finally stumbled across a couple models that actually worked and from there I got asked to co-author the Tech FAR Handbook, which was the first publication on how to buy Agile under the FAR and then shortly after recruited to U.S. Digital Service in the early days back when it was a lot of fun.

(01:15):

And then I ended up staying for four and a half years unexpectedly, went over to Defense Digital Service for three of those years and then left to go help do a tech startup. And now I'm doing consulting full-time I was joined along the way working with government agencies and companies that are trying to figure this stuff out. So I like to do that. I like to talk to people. So if you have questions after this, feel free to follow up. I just enjoy the topic a lot because as I mentioned before, I'm a nerd. So nerds like to talk about things they know.

(01:45):

So let's get going. So let's start with the big picture. So we've talked a bit about bureaucracy. We just had a conversation on a book written by friends of mine all about hacking your bureaucracy. And for a long time my title was Bureaucracy Hacker, but I'm going to make maybe a contrary statement. I don't think bureaucracies are inherently bad. You actually need bureaucracies to run large organizations. Anyone who's been in a startup, which I talked to a few people, you're in startups, when you first join a startup and there's like 10 of you, you don't need a lot of rules, right? This is Joe. Joe's not going to do anything stupid. He's an owner of the business. But when you start scaling, you get to a hundred, 200 people. Suddenly you might not know Joe, and Joe might've gotten through the hiring and emotional criteria just fine, but he thinks taking a limo to dinner is a good idea. So you have travel rules.

(02:36):

So when is bureaucracy bad? It's bad when it impedes your ability to deliver on the mission. And Adam gave a great lecture last night, if you didn't see it, it was incredible. But he really talked about how the bureaucracy that we're operating in is sort of unchangeable. It's by design. I think that's a great point. And so we have to just affect the things we can affect, control your own environment as much as you can. And so how do we do that? We have to understand our environment. Well, one thing I understand is that most people actually want to do good. Most civil servants and military folk want to do the right thing. They're there for a reason and it's usually not a paycheck because they could probably do better elsewhere. And where you really see it is you got the frontline people. They care because it actually affects their day-to-day life, like hand jamming all this information into spreadsheets is a pain in the. They don't want to do it. They know there's an easier way.

(03:29):

And then you've got leadership who stands up on top and it's like saying all the right words. "We're going to do AI, we're going to do acquisition better." They care if for nothing else because they're public facing, they have to care. Then you got the squishy middle, the people who are worried about the career arc, and I don't want to look bad, and the best way for me not to look bad is to not make my boss look bad. So that's really where the work happens, right? Because you can convince the frontline person, but they don't have any money. You can convince the senior person who might theoretically have the money, but really has no control over where it goes. It's getting into that middle layer and getting buy-in.

(04:03):

And the best way to get buy-in is to show them where it's been done before without an issue because people are risk averse and have a fear of change. They think modern technology approaches are dangerous. New cybersecurity, open source code, agile delivery. They imagine just a bunch of engineers in a dark room with Red Bull and computers just willy-nilly typing whatever they want. But the funny thing is the GAO has been writing almost every year for the last decade that waterfall acquisitions fail 90% of the time by cost, schedule and performance. So they're envisioning a world where they're not taking risk by doing probably the most risky thing where there's only a 10% chance of success. And you can use that to your advantage because you can show them, well, here's other places we've done this and it's been successful.

(04:49):

And then we get to these procurement people. God help us. The no people. That's kind of the mentality. Why do we think of the contracting officer like that? I was kind of saying before, they're the tail that wags the dog. Most of the time, they have no idea. All these conversations that industry has had with the requirement owner, they don't really understand the requirement owner's problem. They had this thing dropped on their desk and they're told to do it and they're risk-averse. Why are they risk-averse? Well, about 20 years ago when I got into contracting buying laptops off of BPA, the most awful job in the world, what was I told? I was told my job is to prevent fraud, waste, and abuse. And I was personally and professionally liable for anything that I did. Holy shit. I was a kid. I wasn't making any money. I had a mortgage and I'm going to go to jail?

(05:34):

One of my CEOs told me you should really get liability insurance for this job. I said, "Absolutely not. I can barely pay my mortgage." But that's the mentality. And so people come into contracting and they look to their CEOs and their CEOs do things a certain way and they're like, "Okay, I'm going to do exactly what they do. I don't want to get in trouble." There's no innovation there. And I personally think, and I have since the beginning that contracting isn't really the job. That's the paperwork that you have to do to do the job.

(06:04):

The real job of a contracting officer is to be a business advisor. And a business advisor is a professional who deeply understands their craft and understands what their customer's buying. So they're part of this solution and their jobs not to say no.  It might be no, but we can do it this way. It is to help get to the mission. That's the whole point of a contracting officer. And people don't necessarily have that philosophy. A big part of those of you that are selling into the government is finding those contracting officers that think that way and they are out there.

(06:36):

All right, so just a little bit of context here. I keep looking up there, it's right in front of me. I'm not used to it. Okay, so contracts, we were talking a little bit about bureaucracy and a startup versus a scaled business or a scaling business. Contracts didn't used to be that complex. It was basically just like, we don't want this person giving a hundred million dollar contract to their brother. That's the kind of thing we want to stop. But then people screw up and they take advantage and we make a rule and then somehow they screw up that rule. So they make another rule and another rule. And now we have 2,368 pages of rules in the FAR.

(07:11):

Fun fact, the FAR really only tells you no about three times. The rest of it is supposed to be instructions on how you can do things. But just like programming a VCR back in the nineties, those instructions are a bit confusing. You have to understand them, but they really are a pathway to do things. People just assume I got to do it the way people always did it. But the fact is there's all kinds of pathways within the FAR to get things done.

(07:33):

So things started getting complex, not just because of all the rules, but technology was changing. You didn't actually have to be that creative when you had two years lead time to write your requirement, you had a year to run in the acquisition and five to 10 years to deliver because you probably weren't going to be in that job anymore. It was just basically this is the start to finish. We're going to hand it to the contractor. They're going to lay out a map and they're going to follow that map. 90% of the time they don't. But that's what we believed when we put the contract in place.

(08:00):

But technology kind of threw a monkey wrench in that. Open source code, what do we do with it? Is it safe? Are we allowed to use it? Open architectures. We don't want to be open. We want to protect our data. It started creating a lot of complexity. And then recently, and I say recently, over 10 years ago, people started getting it, right? We got to be more efficient. We got to keep up with our adversaries around the world. We've got to be able to keep up with industry. And so you started to see these pockets come up. US Digital Service, 18F Kessel Run, AFWERX. So there are pockets out there. And it's not just in the DoD, believe it or not. There's other agencies, I work with other agencies that are trying really hard to get this right. We hear of the big ones like VA and CMS that have been doing this for a long time, but the other agencies are trying to come along.

(08:50):

So I talked about innovation. This is my personal, I don't want to call it a definition because I don't think it meets the definition of a definition, but this is my personal mantra of innovation. Innovation is assuming anything can and should be done differently. It involves a deep understanding of the rules, regulations and policies, procedures, and case law that surrounds the thing you want to change. And it requires responsible risk taking. And see, the catch is you can't do the third one without the second one. And this is what people miss. They're just like, "I want to do things differently." "Cool. How do you want to do it?" "Oh, I want to do this thing. All right, here's why you can't do that."

(09:28):

Now my job and people like me, our job is to explain how you can do what you're trying to do. What's the intent? And so it's nerd stuff, man. If you're writing code, you got to understand code. You just have to know your craft. It's like anything else. And with this kind of philosophy, I've been able to apply it all across acquisitions, but I've also applied it in lots of other ways with helping businesses grow because people kind of get stuck in their box because they don't understand the playing field. How far can you go to the right and left before you go off the bridge? What are your boundaries? And those boundaries are usually really far, especially in acquisitions. No pun intended. If you caught that.

(10:08):

All right, so how does that apply to acquisitions? Well, it's process and innovation. And this is interesting to me because when we talk about acquisition innovation, most people get really stuck on the pre-acquisition part. How do we run acquisitions better? It's actually not that hard. We make it hard, but it's not that hard. And I think there's a lot of work out there that has demonstrated this can be done better. So I'm not going to spend a lot of time on that. We've seen it, right? Like the CSOs, the OTAs, the SBIRS, the way the Air Force is using the SBIRS, there's lots of stuff out there. There's strategic integration, bringing the team together. How do we bring tools into the process?

(10:46):

But what I really want to focus on for a moment is the outcome oriented. I think this is so important. Megan mentioned it last night and I love that she said in the way she put it, she said, outcome versus outputs. And so when we structure a contract pre and for execution, historically we have this iron triangle for contracting. We have cost, period of performance, and scope. And only a contracting officer can change those things. So shall it be, so shall it's done, right? So those are the rules. And that doesn't change. And I'm not proposing we change it. That's right.

(11:17):

But what we've done historically is we've tied the technical requirements to those contractual requirements. We had integrated master schedules. I've had a 500-page system requirement document tied to the contract. So if you wanted to change from and to the, that was a contract modification. That takes time and it's not a high priority one. So it's going to sit there. We put our shall statements and 50 pages, statements of work. You want to change one thing in there, your priority changed, your user isn't happy? Cool, contract modification, more cost, more time. That's the only way you're going to do it. And so how do we separate those?

(11:55):

Well, what we do is we say, "Tech folks, you live inside that triangle, but instead of attaching your schedule, your backlog, which was normally a bunch of shall statements in a statement of work, those are your documents. You can change those anytime you want. As long as you don't increase the period of performance, you don't increase the time and you don't change the scope. And that scope piece is where everybody gets hung up. What's the scope? That's why we use statements of objectives now primarily as opposed to statements of work. Here's our overarching objective. And performance work statements, the process the vendor's going to use. Most times I have the vendors write the performance work statement. How would you deliver it? I don't want to compare apples to apples. I want to compare apples to oranges to bananas and pineapples. Let's see what industry can bring and solve our problems.

(12:37):

This works really well. Statement objectives are easy to write. They're much shorter and it gives a lot more flexibility. So continue that down this path here. So why should it be less complicated? Well, again, because we're buying the outcome, we're buying the repeatable process for the delivery of a functional product. We're buying the factory. That's where that term software factory came from. Maybe people don't love it anymore, but the original idea of a software factory was that phrase I just said, we're buying. If you read Shell Silverstein, a homework machine. We just want to put my requirement in. I want a process to occur. I'll pay for that process, but I want an output. I want an output. But I'm not going to tell you what that is. That output is going to be worked at the technical level. It's going to meet a definition of done.

(13:22):

Of course, everybody's going to have to accept it, but it makes it a lot simpler to articulate to industry what you're trying to buy. That's a little bit different if you're buying a commercial product, which we should be doing more of. But in that case, again, we're not defining the specific salient characteristics of that specific product. We should be describing the outcome. The product should meet the outcome.

(13:44):

So as I mentioned, there's all sorts of ways we've been creative. CSOs, so if you don't know, CSOs came out of the 2016 NDAA when OT got reborn and DIU was a big part of that and it was this couple of things they added to it. They added that it was also for prototypes because it used to just be for basic and applied and advanced research. They added end prototypes. Super important because DIU said, "Well, when you're developing software, an MVP is like a prototype," which isn't exactly true, but for the purposes of legislation in the statute, it was a great use of words.

(14:16):

But they also recognized that other transaction authorities outside the FAR, unfortunately, or fortunately, all the contract types are inside the FAR. All the acquisition approaches are inside the FAR. So they were kind enough to add the commercial solutions opening. What does it look like? They modeled it right after the BAA, the Broad Agency Announcement FAR part 35, which is research and development contracting, which by the way is the most fun kind of contracting and I did it for a while. So OTAs and CSOs, CSOs are now done under FAR contracting primarily by GSA. The main difference between the two is that under OTAs you can kick people out anytime you want. That's a good thing. That's a good thing for industry. You want to get kicked out early if you're not going to win, you don't want to put in a lot of documentation. We'll talk about down-selects in a minute and it's good for evaluators.

(15:03):

But under FAR based contracting the CSOs, you can do an advisory down-select. So basically you can say you're probably not going to win, up to you if you want to keep submitting content and coming to orals and doing code challenges or whatever, but we're telling you you're probably not going to win. And so most times industry will get the hint and bow out gracefully. That reduces risks of protests. I would save that for a longer presentation since most of you are not contracts people, but it does decrease the risk of protests as well.

(15:31):

All right, so we talked about some of this stuff already, but market research is a big one. Most people when they think FAR contracting, they're actually thinking FAR 15, which is contract by negotiations. Fun fact, the whole section besides the title doesn't even talk about negotiations. They talk about discussions. FAR 15 is actually great, it's really well written. It's a good way to run an acquisition. Unfortunately that's where all the really big acquisitions were done. That's where all the really big protests were won and lost. And so that's where all the case law is that tells you how you got to do it to avoid future protests. And that's why it's complicated.

(16:06):

As I mentioned, there's lots of other sections of the FAR where it's a lot easier. The good thing is FAR 15 is the only part that really talks about limitations on communications with industry. All the other, 8.4, 12, 13, 35, yeah, 16.5, none of those sections, you all know what those are, right? Of course. I could have said any number so it wouldn't have mattered. I just made all that up. But none of those sections really limit you. In fact FAR Part 10 is market research and the whole section is about actually engaging with industry.

(16:39):

So not only should contracting officers and program officers take advantage of that, there's no instructions on how to do it. It just says do it. It gives you some recommendations. But you are allowed to have one-on-one conversations with industry. You're allowed to do it. You should do it because when you get a whole bunch of industry people in a room and you talk about a requirement, they're not going to raise their hand and say it's, they're not going to tell you where you did something stupid. And they're certainly not going to ask a really good question because they're afraid someone's going to steal their secret sauce.

(17:07):

But you can pull them in one-on-one and have a conversation with them. It might be more them talking to you, but you can talk to them. You can have that conversation and you should. It makes a huge difference.

(17:17):

Down selections. I love down selections. Why do I love down selections? Has to do with protests, has to do with what I just talked about and I kind of say it this way. The amount of effort from industry and evaluators should be commensurate with each offer's likelihood of success. It's a lot of words. What does it mean? It means if you're one in N number of proposals, you shouldn't have to spend a hundred thousand dollars of B&P dollars to compete on this thing. Yes, sir.

Speaker 2 (17:44):

Can you say, I don't know what DTS is? Is that Defense Travel System?

Jonathan Mostowski (17:48):

It is Defense Travel System.

Speaker 2 (17:50):

Can you tell more about how down selection is relative to DTS?

Jonathan Mostowski (17:56):

Yes, actually I can. So I actually led, for four miserable years of my life, it was a great opportunity. I led the modernization effort at DoD for defense.

Speaker 2 (18:04):

Are you responsible for DTS?

Jonathan Mostowski (18:05):

No sir. I was responsible for the modernization of DTS, implementing a commercial solution, which subsequently, recently has been killed because of bureaucracy.

Speaker 2 (18:17):

[inaudible 00:18:19].

Jonathan Mostowski (18:18):

But I've been long gone. Defense Travel System is the perfect example of archaic, bad systems that were built. Exactly how the government asked it. The contractor did nothing wrong. They did absolutely nothing wrong. And believe me, I've read every document associated with Defense Travel System. They built, to spec, exactly what the government asked for. So how did we modernize it? And I'm going to just pretend that it hasn't been canceled since I left. But while I was there, this was a great moment in time.

(18:52):

So how do we do it? So first thing we did is I came in at the direction of the DEPSECDEF and studied the problem for two weeks was like, "okay, what are the problems?” Same problems there always are, communication, people and process. That's always the problem. It's rarely technology. In this case, it was also technology. One cool thing is the contract actually had a modernization CLIN [Contract Line Item Number] on it that they weren't using. Go figure, right? You could tell, anyone who's ever traveled under DTS knows they haven't been using the defense or modernization CLIN.

(19:21):

So we did a pilot under the modernization. We did a selection under that existing contract, brought in Concur Commercial Solution, not the GSA one that you use if you ever did civil government work, they did a pilot. Really simple. We took the big huge travel regulations, we shortened it down to five pages, basic travel, CONUS, less than 30 days, that kind of stuff. We did a pilot, it worked. And so then we used a consortium and ran a down selection for a commercial travel solution. We did a five-page white paper, I think it was. And then we did orals and then we did price negotiation. Yes sir.

Speaker 2 (20:00):

Can you describe how you got the consortium? Was that something you assisted or just organized?

Jonathan Mostowski (20:08):

One of my fantasies is I'm going to create a consortium. So there's a lot of consortiums out there and this one existed, it was C5 consortium. So we went through Army Picatinny to the C5 consortium. My personal problem with consortiums is anybody can join a consortium. You don't have to be good, you have to have $500 and can fill out a form. That's what it takes. And so when they run these acquisitions, anybody can apply. And I actually went to them and I said, “Hey, I would like to help you evaluate vendors by a certain criteria. Create a subset of your consortium that.” “Absolutely not, that violates our consortium agreement with our members.” So I'd like to create one that actually does that, but that's neither here nor there.

(20:47):

So we went to them, gave them our requirement. They took way too long, right? It went through all the, this is why I don't generally care for the way the consortiums work, went through all the maturations it would’ve if I just went to a CO. The only advantage is we didn't have to find a CO willing to do this.

Speaker 4 (21:00):

Was it an OT consortium?

Jonathan Mostowski (21:01):

It was an OT consortium, yeah. So yeah, so we did a down select. We ended up ending up with Concur. Not that it was baked, it just, they did the pilot and they had all the requirements. Okay, any other questions on this or anything else? We'll move on here. So streamline documentation, make things easier. Reduction in paperwork. Why don't we use forms? Why do we ask vendors to write out big long papers? I actually did this using OT authority where we used a Google form and we're like, "Upload your repositories, give us screenshots, do this, where have you worked?" And we made our down selection process just through that. So then we had conversations with the two or three vendors we selected from there, which why OT is good.

(21:45):

Tools and templates are great. I might talk about this on another side, but I don't have a lot of time so I'll throw it in here. Acquisitions is going to totally change. Orals, I think have orals on here. Yeah, I don't know. Anyway, orals are going to become the future of acquisitions. Why? Because AI is replacing the need to be able to write proposals really well. No offense to proposal writers, you probably use them, right? It's like, "Hey, I could just jam this in here real quick and re-say it for me and that's totally fine." And why the hell isn't the government using it to generate requirements? Here's my bulleted list of objectives. ChatGPT, make me a paragraph.

Speaker 5 (22:20):

... You're going to start.

Jonathan Mostowski (22:20):

So this is happening. I know lots of companies, I'm sort of talking to a lot of companies that are building software specifically for this problem. They're actually trying to remove the burdensome effort of writing proposals right now. It's like, "Hey, we'll serve you up the 80% solution. You do the 20%, which is what AI should do. It should have the human do the human part of it, but get rid of all that manual stuff." So orals are going to make a huge difference.

(22:46):

It also makes a huge difference because a lot of companies have professional proposal writers that are really good at telling a story. And I do a lot of oral coaching for companies and I'll sit down with the team and they're required to be the people who are going to perform in the first session and most of them have never read the proposal. Maybe they gave a paragraph three months ago, but they never read what's actually being submitted. And a lot of times that's the case. So you're buying a piece of paper, you're never actually meeting the people that are going to deliver. And so orals are going to change everything. It's not going away.

(23:18):

Code challenges are cool, they're fun. It's a great way to evaluate a team's process and how they deal with stress and how they can write code. But what I always tell government agencies is, do you understand code? Do you know what the difference between good code and bad code? If you don't, why are you wasting their time? You could just get the visual, you could evaluate the UX maybe, but you can't evaluate the code, don't waste your time. So either hire someone who understands code or hire a contractor to be a subject matter expert on your code evaluation. So I do not think code challenges are replacing proposals. I think that'll be a useful tool for organizations that are set up to actually properly evaluate it.

(23:56):

All right, we're running short on time here. What's important. On the training and education? So we have the DITAP program. I helped create it. I still teach it. I think it's an awesome course. A lot of people come out of that actually understanding us from the CO level. What we don't really have is standardized training for cores and product owners. So many times in agencies, I see product owners or program managers last night when they went to bed and magically they made a wish upon a star and they're a product owner. No training, they don't understand how to do it. And now they have all the responsibility theoretically of being the single empowered person to make technical decisions.

(24:31):

They don't know what the hell they're doing. And it causes complete ruckus. Most of the times when I see Agile programs fail, the product owner doesn't understand their job. The only other reason, general other reason, is a senior leader doesn't understand the product owner's job and they keep sticking their nose in it and telling them what's more important. So getting the right training, leadership, product owners I think is super important. I talked a lot about that.

(24:53):

Oh actually no, I will mention this. So integrated product teams isn't a new thing. It's been around forever. And when we do Agile, we're all about this tight-knit team. So I work with the SEC supporting their acquisitions and one of the things we do is we start way early. We bring the whole team together. I sit down, I do workshops with them on a product vision. I do workshops on their statements of objectives. And every single time all the owners of the requirement are in complete disagreement about what they're buying. So just imagine if they didn't get that kind of white glove treatment, what they would've sent out there. Someone would've been disappointed with the solution.

(25:30):

Regulatory reviews. I had a great conversation the other night about just sort of a lot of the ambiguity in terms. Commercialization and SBIRs, what the hell does that mean? I know what it means and I know how to use it, but a lot of people are like, "Commercialization. Is that a certain percentage of my sales are to commercial business?" No, you can just sell it to anybody else not using SBIR funds that meets the definition, but it's a very confusing word.

(25:50):

So we need to actually clean up a lot of language, that’s long-term stuff. The Hill's super open to it. So I do a lot of conversations with them trying to fix that. I think I'm out of time. Oh, good. I'm out of slides. Look at that.

Speaker 6 (25:59):

[inaudible 00:26:01].

Jonathan Mostowski (26:01):

No, no it doesn't. All right, well thank you everybody. I appreciate you coming. Like I said, if you have any questions, I think I have my... Look at that slide. That's a piece of crap. John Most on LinkedIn. Feel free to connect and I'm happy just to talk through if you're having an issue or whatever. But I appreciate you all coming. Thanks.

Speaker 7 (26:18):

Thank you.

‍