About this podcast episode

Don’t spend 💰 $10 million for a 💵 $1 million solution on your next procurement 👇

Today, John Stenbeck, a best-selling author and a leader in the (U.S.) Government contracting space talks about how to define agile procurements.

John and Bill share examples and personal stories that help assess the right delivery approach for federal procurements.

In this podcast, you will learn the following:

✅ The procurement process

✅ An agile decision-making process

✅ The procurement team’s perspective

✅ The contractor’s perspective

✅ Delivering successful proposals for complex systems

🎉 Concrete examples to deliver the best solutions

Transcript

(transcripts are auto-generated, so please excuse the brevity)

Intro clip

Bill Raymond: Let’s just talk a little bit about that from taxpayer’s perspective.

Bill Raymond: How do you come up with that balance, allowing the complexity and the uncertainty while also having some firm language in your contract?

The CURE

John Stenbeck: You got to have a way to evaluate that. I’ve never met a brigadier general, I’ve never met an admiral, I’ve never met a Secretary of State or a Secretary of Health and Human Services who wanted to spend $10 million for a $1 million solution. Yet that happens a lot now.

Intro

Speaker: Welcome to the Agile in Action Podcast with Bill Raymond. Bill will explore how business disruptors are adopting agile techniques to gain a competitive advantage in this fast-paced technology driven market.

Bill Raymond: Hi and welcome to the podcast.

Bill Raymond: Today, I’m joined by John Stenbeck, CEO of Great PM, enterprise agility expert and a four-time Amazon number one bestselling author, including the book we’ll discuss today, is titled Agile Government Contracting.

Bill Raymond: Hi John. How are you today?

John Stenbeck: I’m doing well. Thank you, Bill. Glad to be here.

Bill Raymond: Great. I’m looking forward to this conversation with you today. I think this is one of our first government-focused podcasts of many that are coming up this year, so I’m excited to have you on. But before we get started, could you share a little bit about yourself?

John Stenbeck: I started my career as an accountant, believe it or not, became a manufacturing engineer, along the way I ended up as a project manager and then 10 years ago, actually 11 years ago now I think about it, I wrote my first book and sadly in a certain sense it did very well. So then I was enticed to write another book. And at this point I just released the book that you mentioned, Agile Government Contracting. It’s my 10th book. And the 4th time I’ve had a book that’s become an Amazon number one bestseller. So, I’m trying to share good ideas and apparently some of them catch.

Bill Raymond: Yeah, absolutely. Which is how we reached out to you. So when we get into this conversation, I want to talk to you about agile contracting and procurement. But I think it’s probably a good idea if we set the stage for the real basics here.

When we’re talking about government

Bill Raymond: When we’re talking about this topic and we talk about government, specifically what are you talking about?

John Stenbeck: Great question. You know, it’s funny because a lot of people skip that kind of first fundamental question, so I appreciate you asking that. The book is really focused pretty tightly in the federal government space but the lessons in it apply across the spectrum in government agencies, big institutions and honestly, even large corporations.

John Stenbeck: It sounds weird to say that the government might be in the forefront of innovating and leading with enterprise agility but as the largest purchaser of goods and services in the world, there’s a desperate need for them to do better. I think you would agree with me, as a taxpayer, we’d like to see the government spend efficiently and effectively all those dollars that we give them.

John Stenbeck: And so, when I think about agile government procurement, it really is the idea of how do we extend lean principles in a government environment that’s highly regulated. The reason we chose to address the federal government regulations is more than any other government environment, right?

John Stenbeck: There’s 3,700 pages of federal acquisition regulations that control everything down to almost your heartbeat and how much you’re allowed to breathe as a contracting officer. But the reality is that we face existential threats, national security threats because of the speed of technology, the speed of the marketplace, the speed of innovation and development going on.

FAANG

John Stenbeck: And so the government has to get more agile in the military sector at least because of national security. In the services to constituents, the dissatisfaction amongst taxpayers and constituents has risen sort of exponentially because we now have all been affected by what we like to call FAANG: Facebook, Apple, Amazon, Netflix and Google.

John Stenbeck: And the FAANG factor is that we now expect everything overnight, exactly the way we want it and shipping for free. And so that’s the yardstick that we measure the performance of all organizations including governments and institutions as well as commercial enterprises again. Sowe have to deal with that.

Disruption by design

John Stenbeck: Another factor that those five have really pioneered and it’s been followed by a number of other businesses that we can all think of, but it’s the disruption by design business model. So it’s targeting the most vulnerable, the most profitable, the most accessible point in any given ecosystem or product line or security weakness.

John Stenbeck: And so, dealing with that in the government space is a really big deal and it induces a lot of complexity, a lot of uncertainty, a lot of risk. And that brings us to the idea that it’s non-linear. There’s a, you know, we call it a cone of uncertainty, and the bigger something is or the farther out into the future, the actual delivery is that will occur, the more non-linear distortion impacts the decisions being made, especially early on. And so we need a way to manage that because everything the government does almost is huge and long term and so it’s subject to all of those various factors. Does that make sense?

Bill Raymond: Absolutely it does and I think, for our conversation as well, just to bring this down to when we’re talking about procurement, we’re actually talking about the end product, right? The thing that you’re trying to build or the services that you’re requesting, it will be that delivery element that’s going to be delivered in some agile format rather than some more project management style, waterfall style format. Is that correct?

John Stenbeck: Well, what’s really interesting, you bring up the, you know, there’s a traditional linear waterfall kind of project management approach, and we are talking about the delivery ultimately of both products or services as a product. There’s all kind of those three various things that we’re delivering.

John Stenbeck: About probably in the typical world, and I would say also in the government world, it used to be the 80-20 rule. 80% of what we did was so standard, so typical, so vanilla we’ll call it, that the waterfall, linear, traditional approach of project managing was fine. But 20% of it has the complexity, then risk, the uncertainty that we have to deal with enough to where using the old fashioned approaches, right, those linear waterfall approaches don’t deliver the results that we want.

John Stenbeck: One of the examples that I’ve shared with audiences and with clients that I think really highlights this is when you think about the government procuring a battleship, it’s a big investment, it’s a big acquisition. It’s got a long timeframe. But you know, the welding of the hull and the shape of the hull and the putting in of the decks and all itself’s, pretty standard, straightforward, vanilla stuff.

John Stenbeck: But they use the same planning and delivery approach for all of the computer technology too. And so what the result is they build the battleship and the final step of the government accepting it and paying the final invoices and stuff to the provider is that they have to do sea trials. So they launched this battleship that was designed eight years ago, has been in the building process for the last five years, they take it out and do the sea trials and it passes, checks all those boxes, and then that project is final, and the provider gets paid for the battleship, and the very next thing we have to do is bring the battleship back into the dock and tear out all the computer systems because the computer systems that were specced eight years ago were state of the art eight years ago and they’re trash today.

John Stenbeck: All that has to be pulled out and reinstalled. It’s a huge amount of waste, And we have the ability to say, okay, let’s provide enough cabling, enough pipes, if you will, enough plumbing so that the systems can, you know, be connected together. But let’s not spec a 286 13 megahertz CPU eight years in advance, because now we have quad processing, you know, 60 gillion Megahertz kind of processors, which is what we need. So we spend just a huge amount of money doing stuff like that.

Bill Raymond: So could you share with us how someone in procurement might think about when this is an agile project or when this is a more traditional project?

Standardized tools or methodologies

Bill Raymond: I think you gave a great example there with the computer systems because that makes sense. It almost sounds like that could have been two different procurements or at least two different ways to manage the effort so that you had some people maybe doing some more agile work with the software development and other people doing the more traditional. But is there some sort of a standardized process by which someone in a government procurement facility might think about how they should decide when this is a more agile project?

John Stenbeck: I would say there are kind of standardized tools or methodologies or approaches, I’m not sure there’s exactly a standardized process because it varies a great deal when you’re dealing with a weapon system versus a healthcare delivery system versus, you know, an information delivery system or something like that.

John Stenbeck: But what they share in common is that the first, I’ll call it assessment tool, that your listeners should be thinking about if they want to be able to embrace the, of let’s be smarter about our acquisitions, about our procurements. The first tool to think about is what we refer to as a radar diagram or a spider diagram.

John Stenbeck: And so I think most of us have seen that, right? It’s got various axis and we use a six axis spider diagram when we’re doing this. And we start with the simplest or most quantifiable variable at the top, we’ll call it the 12 o’clock position.

Variables

John Stenbeck: And then we work our way around in a clockwise fashion, getting to the more and more you know, the variables that have more and more vagueness or uncertainty associated with them.

John Stenbeck: So, the first variable we talked about is how big of a team are we dealing with? You know, if I’m doing a project that’s got a team of seven or eight people, it’s a very different level of complexity, uncertainty and risk than if I’m dealing with a project that’s got a team of 700 people, right? So we scale that and the farther we move out from the center, the bigger the team is. The second variable we like to talk about is the development team. And when I say development here, I don’t mean just the software development team. It could be the construction team, it could be the architect team, all the various teams that are involved with whatever the development. But how widely are they diffused? Are they all co-located in the same area? Much lower complexity than if they’re a global team in different time zones with different native languages and different cultural expectations. So again, the farther out you move, the more risk, the more uncertainty, the more complexity is being automagically, if you could well being introduced to the environment.

John Stenbeck: The third thing that we look at is what are the security considerations or the compliance considerations? Is this a hospital situation where if it’s done wrong, it’s going to cost somebody their life? Is this a security situation where we’re going to, you know, subject our national interest to a risk from a foreign invader or you know, and that is similar to am I a big company and I’ve got competitors, who are trying to get one up on me. So that’s the third variable we’re going to consider. Then we talk about what’s the solution end game look like? What’s the technology envelope look like and how complex is that? And then we look at that from the technology side, this the very next one.

John Stenbeck: We look at it from the business side. Because not only do I now have a new technology or a new solution or a new procedure in a hospital, how am I going to roll that out? I don’t want to create user fatigue by rolling out too many things too often to where they give up on listening. But I also don’t want to get so slow on my rollouts that I lose the competitive advantage or by failure to do so, people are dying. So there’s a balance and we identify that.

John Stenbeck: And then the last thing we talk about is the disruptor risk. Coming back to that FAANG comment I made earlier. Is there a disruptor, a state-sponsored actor or hacker group, whatever those other that might want to disrupt? What we’re doing so they can beat us to the customer, or you know, and I’ll use the political environment is there a Republican disruptor for a constituency that the Democrats want? Or vice versa. Is there a Democrat disruptor for a Republican consistency? And they’re always trying to do that. So you can apply this always, but that first thing is what’s the environment look at? And the way that we use that tool with our clients is that we’ll meet with the team that’s responsible for delivering this and we’ll have the conversation and we’ll map that out.

John Stenbeck: Now, we’re always outsiders to the team’s environment, so we have to rely on the team to really have the insider knowledge. So as we discuss this with them and we’re marking the spots on those various variables, on each of those axes of that spider diagram, we’re noting what, well, if the executives meant this, it’s more risky. If the executive meant that, it’s less risky.

John Stenbeck: And so we’ll identify those kinds of things. And when we get done putting a dot on each of those six axis, we connect the dots and the size of the area that’s encompassed by the connecting of those dots, the bigger that area is, the more complexity, the more uncertainty, the more risk is just inherent in the environment that we’re working in.

John Stenbeck: The smaller it is, the less it is. So the smaller it is, the more of an argument you can make for just using a traditional serial linear waterfall approach, because it’s pretty controllable and predictable. But as that gets bigger and I have to deal with more complexity, uncertainty, and risk, the more of an argument can be made that we can justify the added overhead of using these agile techniques because the added overhead is going to reduce complexity, uncertainty and risk.

The decision tree

John Stenbeck: So now, once we’ve done that and we have validated with our executive leadership, whoever the vision champion is that we’ve understood what they want and they’ve understood how we’re seeing it, right? And we have that connection. And then the next tool that we like to use is a decision tree. And a decision tree is pre formatted, pre prepared for a particular environment. So the decision tree for an information technology solution project is going to be different than the decision tree for something that has hardware components or the construction project or the healthcare service or whatever.

John Stenbeck: But the idea of a decision tree that says what are the key variables that need to be considered? And if the answer is one thing you go this way, the answer is another thing you go that way. And having that pre-mapped out so you can now have that discussion with the team and answer those questions, with a little bit of investment of energy you can create a tool that works to help the team connect with and inform each other, inform the stakeholders and then identify metrics, you know, things that we can use to measure and govern progress, because ultimately we want to make sure we’recreating adequate progress, creating adequate results for the amount of time, money and energy we’re putting into it.So those are two key tools that we use.

Bill Raymond: Thank you for that. That’s really an interesting process. So first you’re kind of sizing it and understanding how complex it is and then you’re going through this decision tree to find out how you manage it.

John Stenbeck: To choose a management approach, right? Are we going to use the traditional approach? Are we going to use an agile approach? Are we going to use a LEAN approach or are we going to use a continuous delivery approach, right? Because all of those are different. And in different circumstances one will add more value than another. But we tend as human beings to kind of default to what we’ve always done. And so these tools real are more about have we really thought about the various options. And that’s a big challenge for the government. And in the government space, because we’re kind of relating this to government, part of that is, can we articulate this early on with the contracting officer, the legal representative,every aspect, every significant stakeholder of the team represented so that legal can say, well, you might want to go that way, but that’ll violate, you know, this and you’ll end up in jail, or the contracting officer might say yeah, but we don’t have the right kind of dollar. You know who thinks about the kinds of dollars, unless you’re in procurement and in government. Because there are, there’s so many different kinds of buckets of money they call them, right, or pools of money they can use.

John Stenbeck: And it depends on which way it’s funded, whether you’re allowed to do X or Y or Z. And so having a decision tree that makes you walk through that, because you might be smarter off to say, wait a minute, let’s put a temporary pause and let’s go back to the stakeholder and see if we can access a different kind of dollars so that we get a better result for the same amount of money.

Bill Raymond: We do have a large audience of people listening to this podcast that are on the contractor side, the people that are going to the government and saying, this is how we propose that we will deliver the work. And you and I have both seen this, I’ve certainly been in these contracts where they just list out every single deliverable and they expect you to give a timeframe for when those deliverables occur.

Bill Raymond: And very often this is a highly complex technical solution and you’re just thinking to yourself as you’re writing it, why am I responding in this way? Because once we get started on this project, we know that things are going to change because they’re going to see how the system works or going to start building and realize there are all these extra elements and components. And what happens with, if you will, the traditional waterfall approach, for example, and again, anyone that knows this podcast, I’ve been in project management for 25 years. I’m not talking negative about project management. What I’m just saying is that there is a difference. With project management you line everything up, and in typical government words, you might have certain deliverables. Then those deliverables mean you get paid and sometimes you can’t deliver that thing until some base technology is in place, and that base technology could change continuously.

Bill Raymond: So I guess what I’m interested in understanding is on the government side, the people that are actually working on these procurements, how do they recognize the differences between these two types of contracts? You just explained, you know, how you can come to the conclusion that it is an agile project and you also talked about how you can then define what some of those deliverables are, but on the procurement side, how do you adjust your mindset for when you’re actually creating this new procurement for someone to respond to?

John Stenbeck: Well, I think the first thing we should all acknowledge, and it’s kind of the dirty little secret in government procurement, but contractors, and you point out they’re a very important stakeholder in this ecosystem. And there is an old adage amongst contractors that is sad but true. And the old adage is bid it low and watch it grow. And what contracting officers have to understand and what they have to help their program managers and more importantly, the government customer or the program sponsor to understand, is that you can’t accurately define what we call a CLIN, a contract line item, right? So CLIN is contract line item number, but you can’t identify a CLIN for every single thing five years in advance. And if you’re building something that’s going to take that long, a battleship, an information system overhaul or something, you can’t know how much the computer technology’s going to change more than, you know, eight or 10 months out. It really is what it feels like, much less five years down the road.

John Stenbeck: So we have to acknowledge that. And then once we acknowledge that, then it’s a matter of, okay, let’s bring the team together. And I said that the thinking has to become whole team thinking, right? We need somebody who accurately represents the contractor voice because the contractor can’t actually be sitting around this table.

John Stenbeck: But that we have to accurately represent that voice. We need the legal folks on the government side to say, no, that this is legally doable or not. And a big mistake folks make is they wait till after they’ve defined and decided what they want and when they want and all that stuff and they’ve tried to go to contract and then the legal people get invited in and they say, well, I don’t know what you were thinking, but you can’t do that.

John Stenbeck: Right? So we need to include them. The contracting officers largely, the training they get is, exactly how to apply the federal acquisitions regulations. Right. We call ‘em the FAR, right? How to apply the FAR to stop all progress is really kind of the way they’re trained. It’s preventative, it’s a checklist. It’s not an enabler and yet we’re in an environment 20% of the time. I’m going to come back to that, right? The Pareto principle, the 80-20 rule, we always have to keep that in mind. If it’s in the 80%, what I’m saying doesn’t apply. But if it were in that 20%, and maybe it’s 30% these days because of the speed of technology and everything, but there’s that first evaluation, is this in that category where learning and development have to go hand in hand? And if we do, if we have to develop a baseline technology, if we have to figure out how to apply a baseline technology, if we have to integrate how we’re going tochange the thinking model or the culture at the hospital so that we do things differently so that, you know, people get better services for more effective dollars spending or something like that, right?

John Stenbeck: Then we’re going to have to take that into account. So we need this whole team early on in the planning. And that whole team has to be willing to say look, here’s the threshold of where we can reasonably and accurately define contract line items. And beyond that, we have to identify bigger things, something bigger than a contract or a big contract line item that’s broader than that, and the way that it will then be dissected when we get farther down the road and we know better, right?

John Stenbeck: Using the battleship example. We might define a contract line item that says there’s 80 million in the budget for the technology, but we’re not going to define it as an XT 13 megahertz computer.

John Stenbeck: When we’re within 10 months of the structure being built and now we need to start installing the actual technology, then we’ll define that because then we’ll know what’s actually come about and what makes sense on the horizon so we don’t have to throw away and replace all of that. Did that make sense?

Bill Raymond: It made absolute sense. Thank you for that. I mean, that is one of the biggest problems with an agile project if you’re working on gaining funding upfront, if you will. Because you know, if anyone listening to this podcast that is in agile teams, one of the things that you do is you say, Hey, we were thinking about doing this feature and let’s go get funding for that.

Bill Raymond: But when you’re working on a government contract, very often you’re getting that funding upfront and you’re doing all this work to get it upfront. Now, of course, you can do scope changes and you can file for more funds if it makes sense. But it does kind of take away a little bit of that agility component I think.

John Stenbeck: Yeah. In line with that, right, you might have to have multiple vendors who are competing early on with, you know, proof of concept, right, or preliminary drafts or testing sets of outcomes, and you’re going to go through a down select process, right? Where you’re going to go from 50 bids to five competitors, and then we’re going to down select to four competitors.

John Stenbeck: Then we’re going to downselect to three competitors. Then we’re going to down select to the final option that we do, and we have to build that in to the acquisition process and the acquisition thinking, so that learning and development can occur. And at each down select all of the learning that’s occurred becomes common property to all of the remaining competitors so that everybody can then figure out, we want every time, we want the down select, we want the remaining competitors to have the advantage of everything that’s been learned by everybody to, you know, improve their option, their idea as much as possible. And I think in today’s day and age, today’s world, with as much as things are changing, as fast as they’re changing, if we don’t find a way to do that, we don’t stand a chance and we think it’s very doable.

John Stenbeck: When we wrote the book, we documented 74 specific citations, sections of the federal acquisitions regulations that allow for these kinds of things. The use of council for convenience, allows the use of down selects and all these various things so that you can structure and I like where you started this conversation, what’s the process, that so many people look past that, forget that. Think that it’s a one-off process every time. No, it should be a well thought out matured process. Does It does get tailored? Yes. But are the core bones of the process there and how we tailor it, right, that’s what we’re talking about.

Bill Raymond: We’ve been looking at this from so many different lenses, I really appreciate this because so far we’ve been looking at it from the lens of the procurement person - how do you decide,and the procurement team, I guess I should say, it’s not a person, there’s people that are asking for the funds, there are regulations that are requiring these funds be found. Then there’s procurement people that do that work with the individuals that will be receiving the end product. And we have the contractors and we’ve been talking about them quite a bit. And we’ve also been talking about regulations.

Taxpayer’s perspective

Bill Raymond: But let’s also talk a little bit about this because with agile projects there’s a lot of complexity, but there’s also a lot of uncertainty. And you used a simple example of the computer system being eight years out of date in a naval ship, and you could have done more work on that over a period of time and you might have been able to upgrade. But let’s just talk a little bit about that from the taxpayer’s perspective. So I see this contract that has been selected as sort of being an agile or complex project, and I don’t see the typical line items that show what’s going to be delivered that maybe show up in a waterfall project. It may be a little bit more vague. From that perspective,how do you, I don’t think a procurement officer would want to be questioned on that either.

Bill Raymond: So how do you come up with that balance, allowing the complexity and the uncertainty while also having some firm language in your contract?

John Stenbeck:

The CURE

John Stenbeck: And I think it’s the idea of a phased development model. And we have to understand that in phase one you can’t know exactly what the best solution is in phase five. You also, quite frankly, in phase one, very seldom know a completely accurate or have a completely accurate diagnosis of what the real problem is. You know, what’s the old saying that a problem well stated is half solved. And when we’re talking about the size and the complexity and uncertainty and all these things, right? One of the acronyms we’re you know, famous for using with our clients is you got to find the CURE complexity, uncertainty, risk, evaluation. Right?

John Stenbeck: And that’s why when you were talking process, I talked about the spider diagram and the decision tree, right?

John Stenbeck: You got to have a way to evaluate that. But then, like you were saying, right, okay, so how does the taxpayer know they’re not taken for a ride, quite frankly. And I’ve never met, I’ve never met a brigadier general, I’ve never met an admiral, I’ve never met a Secretary of State or a Secretary of Health and Human Services who wanted to spend $10 million for a $1 million solution. Yet that happens a lot now.

John Stenbeck: So the first thing we have to do is kind of acknowledge that the system as it currently operates is not giving us good value. It’s broken. So how do we fix that? Well, we’re going to have to do some things differently. That’s going to take some learning and some retraining. And, we’ve proven that in these environments where there’s a lot of challenges, there are a lot unknowns, a lot of moving variables you can only learn your way forward.

John Stenbeck: But that doesn’t mean I can’t frame what my ultimate objectives are. And part of the process has to be early on defining what the metrics will use, what they will be to measure, making adequate progress given the amount of time and money we spent.

John Stenbeck: Because when, you know, I’m fond saying this to clients, right? When’s the best time to kill a project that’s going to fail anyhow? After you’ve spent one year and $1 million, or after you’ve spent 10 years and $10 billion? And the answer’s obvious, right? If it’s going to fail anyhow, kill it early. So the very first thing we have to do early on is identify what are the absolute must haves.

John Stenbeck: If it can’t do X, Y and Z, we don’t want it. It doesn’t solve our core problem. Okay. Now, it may not be the apparently most efficient development approach, but it is by far the most effective development approach to say, okay, how can we discover as early as possible whether we can actually do X, Y and Z and let’s move those.

John Stenbeck: They call it shift it to the left on the schedule, which as a project manager you’ll be familiar with. Right? Move it earlier and figure out what are the tests, what are the metrics that we can do? What can we do early on?

John Stenbeck: I spent some time in the aerospace and astro space arena, where we were developing things that fly or go into outer space. And that whole process is… right… you develop the mockup, then you develop the prototype, then you develop the testing sets. And along the way you’re getting closer and closer to the solution, but you’re also breaking things and figuring out that doesn’t work or this won’t fit, or that doesn’t jive, or whatever that case may be.

John Stenbeck: And you do all of that before you build the final flight set that you actually are going to deliver, that somebody’s life is going to be relying on in the execution of that mission. And so I think we have to accept that a lot of what we do today, and it may not feel that way at first, but when you think about it, a hospital or a hospital system or a patient care system is so big and so complex and there’s so many moving variables, and just the introduction of AI and databases and all the things that we can do to help better understand the patient, help the patient better understand themselves so they can make lifestyle choices and behavioral changes, right? There’s a huge opportunity there, but we can’t know seven or eight years in advance exactly how to do that. There’s still too much learning going on about how do we leverage the social media, the internet channels, and all those things so that we can have more face time, more connection to the patient and get the patient more viscerally connected to what the medical diagnosis means and how they can do something to improve that. Because overall, that then leads to a lower cost of care and a better life. Right? As another example.

Case study

Bill Raymond: That’s a great example and you also have some great examples in your book, I was curious if you want to share what that looks like. Because it kind of walks through the whole procurement process and it goes through how you could deliver both on, a project that is more, if you will, waterfall-focused while also delivering on the more complex agile type projects.

John Stenbeck: You know, it’s interesting until you ask that question just this moment, I had never thought about it this way. When we were writing the book, right? You create the table of contents, you create the subtopics, you create the bullets under each subtopic and then you write, it’s as waterfall as waterfall can be.

John Stenbeck: But we decided that, right, it’s fine and dandy to have the esoteric, you know, thou shalts kind of things in the book. But what the contracting officers really needed was an example with actual government forms and that kind of stuff. And so we said, okay, well, we’ll create a case study as part of this book. And when we first started that, you know, I thought we were talking maybe 15 or 20 pages. and the learning and development cycle kicked in, the agile because it was a lot more complex than we realized to really make it so it was useful. The end result was 109 page case study with the actual government forms and examples.

John Stenbeck: So we chose to use, we created, we called it REAL right? The robotically enabled assisted logistics system. We felt like, okay, we want to interface between technology and the physical real world. So we decided that the case study would involve the rollout of a robotically technology enabled logistic systems for warehouse management. Because the government’s got a lot of warehouses with a lot of stuff in it. And when a hurricane hits, FEMA has got to be able to figure out how to get all that stuff moved to the right location at the right time, right? So we thought, okay, this would be an example that a lot of folks could relate to. And it gave us the ability to address information system issues, constructing issues, other kinds of physical system issues. And so we built that into the case study and then we actually filled out the contract line items and the user stories and the disclosures and the, you know, right down the line. And it turned out to be a whole lot more than we had anticipated when we started, because we didn’t want to short change the people who were looking for a real answer. And I think that maybe relates it. There’s a lot of times when, you know, and I hate to almost say it because I think it, well, not what I’m going to say, actually likes it. I think a lot of government folks get unfairly characterized in the media or by the comedians and stuff, as is never-do-wells or not trying to do well.

John Stenbeck: And that’s never been my experience of them. Right? The government contracting officers, the military folks, the healthcare folks, they want to do the best but they’re kind of in this strait jacket. So we felt like we need to deliver a solution that they can really use right there as it is and not have to spend hours more developing it for themselves.

John Stenbeck: So we put that added time and energy into it and I think it was four and a half or five months of development time to get that to where we said, okay, we feel proud of this, and we feel it’s comprehensive enough and complete enough and has all the necessary forms and ideas and details in there.

John Stenbeck: So it could really help. I didn’t mean this to sound like an advertisement for the book, but you know, we really put a lot of energy into that case study.

Bill Raymond: No, and I know you did, and I think it’s actually a great read, even if you aren’t in procurement, because it gives you the, it gives you the flip side, right? It gives you how the procurement team needs to look at these. And there’s, so, as you said, there’s so many rules you need to follow and yeah, sometimes when you are working on government contracts, I mean, I guess for me, all the time I’ve worked, any time I’ve worked on a government contract, it has felt a little bit slower. It has felt a little bit more like wish we could go a little bit faster, but you have to look at it from their perspective. They have to sometimes work with the system you built for 10, 15 years.

Bill Raymond: And they have to maintain it, and there’s security and there’s risk, and there’s all these things that they need the staff for it, perhaps. There are so many things that go on behind the scenes that take more time, as you said, to avoid things like bribes, to avoid state-sponsored actors getting into the system.

Bill Raymond: So there is a lot more there and it’s very much appreciated. And I feel like what your book does is it kind of gives you both perspectives. and so I thought you actually, it was time well spent working on those 109 pages.

John Stenbeck: Well thank you. Appreciate that. Because man, I’ll tell you, when we were doing it, I was not happy. It was hard work getting there and as you point out from your experience, my experience too, and I think the experience of a lot of your listeners, and this is where, if you’re in the government space, you’ll recognize it.

John Stenbeck: But honestly, if you’re not in the, if you’re in the industrial space, you’re the contractor side of supplying to the government, customer supplied materials or customer supplied decisions in either environment leads to huge delays in both commercial and government environments. And that’s one of the biggest variables.

John Stenbeck: And part of the reasonthat happens, I think, is we don’t have a structure. You’ve told them, hey, in February 1, I’m going to need to know this decision. And then they don’t give it to you until May 1, and then they want to know why the schedule slipped or you’re over. So being able to build that communication system really so that we can connect and get timely information and relate it to why it’s important for a timely decision is hugely important. In fact, there’s interesting research on what they call decision latency, out there and if any of your listeners are going, yeah, man, that’s just killing me. Do you know Google search decision latency. There’s some very good research and writing out there on just how expensive it is to have those delayed decisions.

Bill Raymond: Yeah, that’s absolutely. I think we’ve all experienced that in our lives and if you haven’t, then you will.

John Stenbeck: Yeah. If you have, and you’re very young and very new and you will.

Resources

Bill Raymond: So learn about it now. But speaking of learning, if anyone wants to learn more about agile procurement processes in the government what are some of the things that you might suggest people look into?

John Stenbeck: Oh man, that’s another great, you know, and I get called to a lot of podcasts and they don’t always have good questions, but I appreciate.

John Stenbeck: So, resources, right. Let’s talk about resources for your audience, for your listeners that they can turn to. If they’re not really familiar with the basics of agile they really want to understand that.

John Stenbeck: I would go and Google Mike Cohn. He’s a wonderfully, he’s a combination of true expertise, engaging delivery and funny as heck, right? So great, great resource. And this, now, this can be a personal advertisement, my book Agile Almanac book one is another great resource for those basics about agile.

John Stenbeck: If you want to know more about enterprise agile I would turn to the SAFe.SAFe as their acronym, but it’s Scaled Agile Framework. Go to their website, they have just a tremendous volume of free information available and some very good diagrams that you can click on and it drills you down into very good information to really start to help you to understand how an enterprise ecosystem is very different in achieving agility compared to basic agile.

John Stenbeck: We wrote the Agile Almanac book two, right? Book one and book two to address that also. So maybe those are two resources. Of course, I think our new Agile Government Contracting book is a great resource. We also have started a LinkedIn group Agile Government Procurement LinkedIn group and certainly they’re welcome to join us therefor sharing ideas and the like.

Bill Raymond: Wonderful. Thank you. And if anyone wants to reach you how might they do that?

John Stenbeck: Okay. So sort of reaching out to you and saying, Hey, would you get me an introduction to John, which they could do but they can reach me on LinkedIn. Notice that it is John Stenbeck, by the way, not John Steinbeck. If you put that I in there, it terribly confuses Google who you’re looking for.

John Stenbeck: Or they could visit our website which is great pm like project manager greatpm.com. And those would be two easy ways to be able to reach out to me and I’ll be happy to help in any way I can.

Bill Raymond: Yeah. Well that’s wonderful. Thank you. And I will make sure that the links for your Linkedin, for Great PM and all the other resources that you just listed are also provided in the agileinaction.com website. And also if you’re listening to a podcast app right now, just go to the details, the show notes, and you’ll see the links there.

Bill Raymond: And John, people normally don’t say, reach out to Bill on the podcast and I guess I don’t say it enough, if you do want to reach out to me to talk to John or any other guest, feel free to contact me. You’ll find my contact link right there on the agileinaction.com website.

Bill Raymond: John Stenbeck, this has been a great conversation, I really appreciate the time you took today. Thank you so much.

John Stenbeck: And thank you for being way better than the average podcast host.

Bill Raymond: You are welcome.

Outro

Speaker: Thank you for listening to the Agile and Action Podcast with Bill Raymond. Subscribe now to stay current on the latest trends in team, organization, and agile techniques. Please take a moment to rate and comment to help us grow our community. This podcast is produced in affiliation with Cambermast LLC, and our executive producer is Reama Dagasan.

Speaker: If there is a topic you would like Bill to cover, contact him directly at bill.Raymond@agileinaction.com.